To understand the types of relationships that the WebSphere business integration system supports, you must understand how IBM implements the following concepts:
As Table 61 shows, a relationship is a two-part entity, consisting of a
repository entity and a run-time object.
Table 61. Parts of a relationship
Repository entity | Run-time object |
---|---|
Relationship definition | Relationship instance |
You define a relationship to the WebSphere business integration system with a relationship definition. Relationship definitions identify each participant and specify how the participants are related. In Figure 79, CustIden is the relationship definition and it includes information about the three participants, Application A, Application B, and Generic Customer.
The system stores relationship definitions in the repository. The Relationship Designer Express tool provides dialogs to help you create the relationship definitions. Using this tool, you also store the completed relationship definition in the repository.
The relationship definition provides the following information about the relationship:
A relationship definition is simply a template, or description, of the relationship; it is not an actual business object. Therefore, the name of the relationship definition should not be the name of the associated business object.
The relationship database holds the relationship tables for a relationship. The relationship uses these relationship tables to keep track of the related application-specific values. For more information, see "Relationship tables".
To access the relationship database at run time, the system must have the following information:
By default, the relationship database is the WebSphere business integration system repository; that is, Relationship Designer Express creates all relationship tables in the repository. Relationship Designer Express allows you to specify the location of relationship tables in either of the following ways:
For more information, see "Global default settings".
For more information, see "Advanced settings for relationship definitions".
The relationship definition is a template for the run-time instantiation of the relationship, called the relationship instance. During map execution, the system creates instances of the relationship based on the relationship definition and using the values from the actual business objects being transformed.
For example, the relationship data for the CustLkUp lookup relationship (see Figure 81) shows that a customer status of Inactive in a Clarify application is the same as a customer status of 05 in an SAP application. Although these status codes are different, they represent the same customer status and therefore are in the same relationship instance, as Figure 86 shows.
Figure 86. One Relationship instance for the CustLkUp relationship
A relationship instance is represented in the Mapping API by an instance of the Relationship or IdentityRelationship class.
To locate a relationship instance, the system requires the following information:
A relationship table is a database table that holds the relationship run-time data for one participant in a relationship. InterChange Server Express stores relationship instances in relationship tables, with one table (sometimes called a participant table) storing information for one participant in the relationship. For example, for the CustLkUp lookup relationship in Figure 80, InterChange Server Express requires two participant tables, as shown in Figure 86.
When you create a relationship definition, Relationship Designer Express automatically creates the table schemas that the relationship requires; that is, it creates the relationship tables with the necessary columns for each participant. At run time, these tables hold the data for the relationship instances.
To access a relationship table at run time, the system must have the following information:
Because a relationship table is associated with a participant, the name of this table is defined as part of the participant definition. By default, any relationship table has a name of the form:
RelationshipDefName_ParticipantDefName
Relationship Designer Express allows you to customize the name of a relationship table as part of the process of creating a participant definition.
For more information, see "Advanced settings for participant definitions".
The name of the relationship database is set as part of the relationship definition. By default, the relationship database is the system repository. For more information, see "Advanced settings for relationship definitions".
In map-transformation steps, relationship tables are managed using methods in the Relationship, IdentityRelationship, and Participant classes. Some Mapping API methods automatically manage relationship tables. You can also explicitly access these relationship tables to obtain this relationship data.
The WebSphere business integration system uniquely identifies each relationship instance by assigning it a unique integer value, called a relationship instance ID. This instance ID allows the system to correlate the participant values. In general, given any participant in a relationship, you can retrieve the data for any other participant in the relationship by specifying the relationship instance ID.
For example, for the relationship between customer status codes of a Clarify application and an SAP application, the WebSphere business integration system assigns a relationship instance ID to each relationship instance of the
lookup relationship. Figure 87 shows how instance ID 47 associates the Clarify customer status of Inactive with the SAP customer status value of 05. Notice that this relationship is basically the same as the one in Figure 86, with the addition of the relationship instance ID.
Figure 87. A lookup relationship with relationship instance IDs
Figure 87 shows the use of relationship instance IDs in a lookup relationship. Instance ID 47 associates the two application-specific participants, ClarLkUp and SAPLkUp.
The WebSphere business integration system also uses a relationship instance ID for the relationship between participants in an identity relationship. In the CustIden relationship (see Figure 82), this instance ID associates the customer IDs stored in the SiteID attribute of the Clarify_Site business object, the CustomerID attribute of the generic Customer business object, and the RefID attribute of the SAP_Customer business object. Figure 88 shows how the relationship instance data for each participant of the CustIden relationship is associated using the relationship instance ID.
Figure 88. A customer identity relationship with relationship instance IDs
In Figure 88, the relationship table for the CWCust participant is included for clarity, though the table is not strictly necessary. In fact, relationship tables for the participant representing the generic business object in any relationship are necessary only if you want to generate a generic ID for the associated attribute in the generic business object. The relationship in Figure 88 generates a generic ID (07) for the CustomerID attribute in the generic Customer business object.
You can simplify your relationship definition and increase performance by eliminating the relationship tables for the participant that represents the generic business object. You do this by checking the managed option for the participant when you create the relationship definition. See "Advanced settings for participant definitions" for more information about this setting.
Figure 89 shows how relationship instance data is associated in the CustIden relationship when the Managed setting is specified for the CWCust participant.
Figure 89. An identity relationship Instance with no generic table
The WebSphere business integration system stores the relationship instance ID in the relationship table for each participant. As Figure 87 through Figure 89 show, each relationship table in a relationship has a column that contains the relationship instance ID. ICS Express automatically creates the instance ID column when it creates the table schema.
A relationship contains participants, which describe
the entities participating in the relationship. As Table 62 shows, a participant is a two-part entity, consisting of a
repository definition and a run-time object.
Table 62. Parts of a participant
Repository entity | Run-time object |
---|---|
Participant definition | Participant instance |
The relationship definition contains a list of participant definitions. For instance, the CustIden relationship definition in Figure 82 associates customer business objects in Clarify and SAP and contains these participant definitions: SAPCust, CWCust, and ClarCust.
The WebSphere business integration system stores participant definitions in the repository. The Relationship Designer Express tool provides dialogs to help you create the participant definitions. Using this tool, you also store the completed participant definition in the repository.
The participant definition provides the following information about the participant:
A participant definition is simply a template, or description, of the participant; it is not an actual business object. Therefore, the name of the participant definition should not be the name of the associated business object.
Like the attributes in a business object definition, the participants in a relationship definition have an associated type. The participant type specifies the kind of data associated with instances of the participant. The participant type can be one of the following:
Relationships with participants of this type establish an association between entire business objects. In this case, you specify the attributes of the business object that relate the participant to the other participants in the relationship. The attributes you choose, usually the key attributes of the business object, become the participant instance identifiers.
In the participant definition, Data represents a supported attribute data type, such as String, long, int, double, float, or boolean. You specify Data as the type for participants in relationships that establish associations between specific attributes in business objects. Participants in lookup relationships have a participant type of Data.
For information on how to define the type of a participant, see "Creating relationship definitions".
For every participant, ICS Express creates the following database entities:
By default, Relationship Designer Express assigns names of the following form to the participant's table and stored procedure: RelName_ParticipantName_X, where RelName is the name of the relationship definition, ParticipantName is the name of the participant definition, and X is T for the participant table or SP for the stored procedure. By default, Relationship Designer Express creates the relationship tables in the WebSphere business integration system repository.
Relationship Designer Express allows you to customize the names of the participant table and stored procedures. For more information on naming the participant table and stored procedures, see Advanced settings for participant definitions.
The participant definition is a template for the run-time instantiation of the participant, called the participant instance. During map execution, the WebSphere business integration system creates instances of the participant based on the participant definition and the attribute values from the actual business objects being transformed.
The WebSphere business integration system stores participant instances as a column in the participant's relationship table. For example, for the CustIden relationship in Figure 82, the ClarCust participant has a column called SiteID in its participant table to hold the values of its participant instances. The SAPCust participant has a RefID column in its participant table to hold the values of its participant instances.
Each participant instance contains the following information:
A participant instance is represented in the Mapping API by an instance of the Participant class.