Relationships: A closer look

To understand the types of relationships that the WebSphere business integration system supports, you must understand how IBM implements the following concepts:

Relationships

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

Relationship definition

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.

Tip:
For more information on how to use Relationship Designer Express to create relationship definitions, see "Customizing the main window"..

The relationship definition provides the following information about the relationship:

Relationship definition name

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.

Relationship database

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:

Relationship instance

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:

Relationship tables

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.

Note:
For an identity relationship, InterChange Server Express automatically populates the relationship tables. For a lookup relationship, you must populate the relationship tables with data. For more information, see "Populating lookup tables with data"..

To access a relationship table at run time, the system must have the following information:

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.

Relationship instance ID

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 two application-specific participants, ClarLkUp and SAPLkUp. 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

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.

Participants

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

Participant definitions

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:

Participant definition name

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.

Participant type

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:

For information on how to define the type of a participant, see "Creating relationship definitions"..

Participant table and stored procedures

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..

Participant instances

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.

Copyright IBM Corp. 2003