What is a relationship?

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:

Example: 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 101, each box represents a participant in a relationship called CustIden.

Figure 101. 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:

Lookup relationships

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 102 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 102. CustLkUp lookup relationship definition

Note:
Because a lookup relationship does not indicate which attributes are being related, its participants use a special type called Data. For more information, see Participant type.

Example: 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 103 shows.

Figure 103. Relationship data for the CustLkUp lookup relationship

Table 77 shows the subtasks for creating a lookup relationship.

Table 77. Subtasks for creating a lookup relationship
Subtask For more information
1. Defining a lookup relationship in Relationship Designer Express. Defining lookup relationships
2. Customizing mapping code to maintain the lookup relationship. Using lookup relationships
3. Testing the lookup relationship to verify that it is implemented correctly. Testing a lookup relationship

Identity relationships

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

Simple identity relationships

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.

Example: Suppose the CustIden relationship (see Figure 101) 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 104, 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 104. 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 105 shows.

Figure 105. 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 78 shows the subtasks for creating a simple identity relationship.

Table 78. Subtasks for creating a simple identity relationship
Subtask For more information
1. Defining a simple identity relationship in Relationship Designer Express. Defining identity relationships
2. Customizing mapping code to maintain the simple identity relationship. Using simple identity relationships
3. Testing the simple identity relationship to verify that it is implemented correctly. Testing an identity relationship

Composite identity relationships

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.

Example: 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 106, 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 106. OrdrLine composite identity relationship definition

Example: Suppose the Clarify application (represented by the participant ClarOrder in Figure 106) 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 107 shows.

Figure 107. Relationship data for the OrdrLine composite identity relationship

Table 79 shows the subtasks for creating a composite identity relationship.

Table 79. Subtasks for creating a composite identity relationship
Subtask For more information
1. Defining a composite identity relationship in Relationship Designer Express. Defining identity relationships
2. Customizing mapping code to maintain the composite identity relationship. Using composite identity relationships
3. Testing the composite identity relationship to verify that it is implemented correctly. Testing an identity relationship

Copyright IBM Corp. 2004, 2005