DID Sources and modularity

Information systems can usually be subdivided into one or more logically and physically separated subsystems. The ITP/SDK for iSeries supports this kind of subdivision by the possibility to create a DID Source per subsystem. Multiple DID Sources can then be combined into one or more DIDs. The connections between those subsystems are described in the mechanism of importing and exporting Entries.

The concept of DID Sources and modularity, and the mechanism of import and export can best be introduced by the following example where the individual subsystems and DID Sources have no knowledge of any other subsystem or DID Source except for the interface. They have to connect to:

With the DID Sales in this example ITP Models can be build that:

• Create a document with the data of the customer
• Create an overview of the orders listed for the customer
• Create invoices and reminders for the customer
• Create an invoice for a particular order
• Create an overview of all non-satisfied invoices for the customer
• Create an overview of all non-satisfied invoices in the system

In the SDK Entries are by default always local to the DID-source they are defined in. To be able to import an Entry in another DID Source the Entry must first be explicitly tagged as "export allowed" by using option "15=Export" on the panel Work with Entries or by manually setting the export attribute of the Entry.

To actually import an Entry from another DID Source the function key F22 = Import must be used on the panel Work with Entries. This function then prompts the panel Import Entry on which the name of the Entry to import and the DID Source it is to be imported from must be entered. It is possible to use function key F4 = Prompt on the panel Import Entry to first select a DID
Source from all DID Sources registered in the SDK and then select an Entry from all the Entries tagged as "export allowed" in that DID Source.

Note

Entries can be imported from any DID Source registered in the ITP/SDK for iSeries even if they are not linked to the same DID the DID Source that does the import is linked to.

A link between the DID and a DID Source can be deleted even when there are still Entries imported from that DID Source into another DID Source still linked to the DID.

The fact that Entries are used in a DID that are imported from a DID Source not linked to the DID is not detected unless a "Check DID" is done on the DID from the panel Work with DIDs.

Imported Entries are the same as Entries defined in the DID-source itself with some restrictions:

• Imported Entries may not be registered as Main entries (and thus changing the Screen field definitions is not allowed).
• It is not possible to create Subentries for the Imported Entry.
• Attributes of imported Entries cannot be changed, and thus they cannot be exported and no offsets may be recalculated.
• Imported Entries cannot be copied or re-generated.
• No data retrieval program may be generated for the imported Entry.
• It is not possible to work with the Field definitions of the imported Entry.

It is allowed to change the Formal parameters of an Imported Entry but this is something that generally should not be done! The only reason to allow this is in case the Formal parameters of the original exported Entry are changed to prevent a required delete and re-import of the Entry. Multiple Aliases that are used many times as Subentries could be defined for the imported Entry, and there is no function to synchronize imported Entries in the SDK. So to prevent a lot of work one could simply change the Formal parameters of the imported Entry according to the changes of the original exported Entry.