When attributes in a source and destination business object contain equivalent data that is represented differently, the transformation step employs a relationship. A relationship establishes an association between data from two or more business objects. Each business object is called a participant in the relationship.
The data that you typically transform using relationships are:
Suppose application A uses sequential integers for customer IDs, and application B uses generated customer codes. TashiCo has a customer ID of 806 in application A and A100 in application B. To transfer customer ID data between applications A and B, you can create a relationship among the application A customer business object, the generic customer business object, and the application B customer business object, based on the customer ID attributes.
This relationship establishes an association between customers from application A and application B, based on the key attributes of their customer business objects. In Figure 79, each box represents a participant in a relationship called CustIden.
Figure 79. Relationship with three participants
Relationships are classified into the following categories based on the type of data in the participant and the number of instances of each participant that can be related:
A lookup relationship relates two pieces of non-key data. For example, in a Clarify_Site to Customer map, you might transform attributes whose values are represented by codes or abbreviations, such as SiteStatus, using a lookup relationship. In a lookup relationship, there is one participant for each application-specific business object.
The CustLkUp relationship in Figure 80 establishes a lookup relationship between customer status codes from Clarify and SAP applications. Each box represents a participant in the CustLkUp lookup relationship. Notice that this relationship has two participants, one for each application-specific business object.
Figure 80. CustLkUp lookup relationship definition
Suppose that the Clarify application represents an inactive customer with a site status of Inactive while in SAP the corresponding value is 05. Although these customer status codes are different, they represent the same status, as Figure 81 shows.
Figure 81. Relationship data for the CustLkUp lookup relationship
Table 58 shows the steps needed to create a lookup
relationship.
Table 58. Steps for creating a lookup relationship
Creation step | For more information | |
---|---|---|
1. | Define a lookup relationship in Relationship Designer Express. | "Defining lookup relationships" |
2. | Customize mapping code to maintain the lookup relationship. | "Using lookup relationships" |
3. | Test the lookup relationship to verify that it is implemented correctly. | "Testing a lookup relationship" |
An identity relationship establishes an association between business objects or other data on a one-to-one basis. To maintain a one-to-one relationship, each business object must have a key; that is, the object contains at least one attribute (a key attribute) whose value uniquely identities the object. If both business objects contain a key, they can participate in an identity relationship.
The WebSphere business integration system supports the following kinds of identity relationships:
Both kinds of identity relationships involve relating business object attributes. Therefore, each participant in an identity relationship has a business object as its participant type. For more information on participant types, see "Participant type".
A simple identity relationship relates two business objects through a single key attribute; that is, each business object contains a single value that uniquely identifies the object. Suppose the CustIden relationship (see Figure 79) is further refined to establish an association between customers from the Clarify and SAP applications, based on the key attributes of their customer business objects. In Figure 82, each box represents a participant in this customer identity relationship. Notice that this relationship has a participant for each application-specific business object and the generic business object.
Figure 82. CustIden simple identity relationship definition
The TashiCo company is identified with a key value of A100 in the Clarify application while this same company is identified with a key value of 806 in the SAP application. Although these application IDs are different, they represent the same customer, as Figure 83 shows.
Figure 83. Relationship data for the custIden simple identity relationship
Therefore, the following maps use a simple identity relationship to maintain the transformations between the key attributes:
Table 59 shows the steps needed to create a simple identity
relationship.
Table 59. Steps for creating a simple identity relationship
Creation step | For more information | |
---|---|---|
1. | Define a simple identity relationship in Relationship Designer Express. | "Defining identity relationships" |
2. | Customize mapping code to maintain the simple identity relationship. | "Using simple identity relationships" |
3. | Test the simple identity relationship to verify that it is implemented correctly. | "Testing an identity relationship" |
A composite identity relationship relates two business objects through a composite key. As the term "composite" indicates, a composite key is a key that consists of several attributes. Values for all attributes are needed to uniquely identify the object. A composite key consists of a unique key from a parent business object and a nonunique key from a child business object.
Suppose a particular order from TashiCo in the Clarify application is identified with a key value of 8765. This same order in the SAP application is identified with a key value of 0003411. Because these two order numbers uniquely identify the same order, their key attributes are related with a simple identity relationship. However, an order also contains order lines. If all participating applications identify these order lines with a unique value, a simple identity relationship can maintain their transformations.
However, it is often the case that an application uses only the line number to identify an order-line item. That is, each order contains a line item identified with 1, with any subsequent items numbered 2, 3, and so on. These line numbers do not uniquely identify the order-line items. To uniquely identify such items, the application uses a composite key that consists of the order number (from the parent order business object) and the line number (from the child order-line business object).
In Figure 84, the OrdrLine relationship establishes a relationship between order lines from the Clarify and SAP applications, based on their composite key attributes: the unique key attribute of their parent order business object combined with the order-line number in their child order-line business object. Each box represents a participant in the OrdrLine composite identity relationship. Notice that each participant has two attributes.
Figure 84. OrdrLine composite identity relationship definition
Suppose the Clarify application (represented by the participant ClarOrder in Figure 84) uses sequential integers to identify order-line items, while the SAP application uses the line number to identify these items. The Clarify application uniquely identifies each order-line item. Therefore, the maps between the Clarify application-specific business object and the generic Order business object (represented by the participant CWOrder) can use a simple identity relationship to maintain the transformation of the order-line items.
However, the SAP application (represented by the participant SAPOrder) identifies order-line items with their line number. Its items are not uniquely identified: every order contains a line item identified with 1, with any subsequent items numbered 2, 3, and so on. To uniquely identify the third order-line item of Order 0003411, you need to use a composite key, which includes both the order number (0003411) and the item number (3). Therefore, the maps between the SAP application-specific business object and the generic Order business object must use a composite identity relationship to maintain the transformation of the order-line items.
The third line item from the TashiCo order (8765) is identified in the Clarify application with the simple key value of 1171. However, this same line item is identified in the SAP application with a composite key value of 0003411 (order number) and 3 (line number). Although these order lines are identified differently, they represent the same order line item, as Figure 85 shows.
Figure 85. Relationship data for the OrdrLine composite identity relationship
Table 60 shows the steps needed to create a composite identity
relationship.
Table 60. Steps for creating a composite identity relationship
Creation step | For more information | |
---|---|---|
1. | Define a composite identity relationship in Relationship Designer Express. | "Defining identity relationships" |
2. | Customize mapping code to maintain the composite identity relationship. | "Using composite identity relationships" |
3. | Test the composite identity relationship to verify that it is implemented correctly. | "Testing an identity relationship" |