An identity relationship establishes an association between two or more business objects on a one-to-one basis. That is, for a given relationship instance, there can be only one instance of each participant. You typically create an identity relationship to transform the key attributes in a business object, such as customer or product ID. For more background information, see "Identity relationships"..
InterChange Server Express supports the kinds of identity relationships shown in Table 65..
Kinds of Identity relationshipsIdentity relationship type | Description | For more information |
---|---|---|
Simple identity relationship |
Relates two business objects through a single key attribute | "Using simple identity relationships" |
Composite identity
relationship |
Relates two business objects through a composite key (made up of more than one attribute) | "Using composite identity relationships" |
To define an identity relationship using Relationship Designer Express, perform the following steps:
Guideline: Create a participant definition for each business object to be related. Identity relationships require participants for the generic business object as well as the application-specific business objects.
For identity relationships, the participant type is a business object. Every identity relationship has a participant with a participant type of the generic business object plus one participant for each application-specific business object.
To do so, expand the associated business object in the Participant Types window, select an attribute, and drag it onto the business object in the main Relationship Designer Express window. The attributes you select become the basis of the relationship between the business objects.
For identity relationships, the attributes are usually the key attributes of each business object definition. The type of the key determines the kind of identity relationship:
Initially, the Advanced Settings window displays the relationship definition settings, as Figure 96 shows.
Result: This setting tells InterChange Server Express to process the relationship as an identity relationship by setting a uniqueness constraint on the relationship instance ID and the key attributes for each participant. This action guarantees a one-to-one correspondence between all participants in each relationship instance.
Result: This action tells Relationship Designer Express not to create relationship tables for the generic business object. When you maintain the relationship with the maintainSimpleIdentityRelationship() method, the WebSphere business integration system uses the relationship instance IDs stored in the application-specific relationship tables to transform the relationship attributes.
When you create identity relationships, the business objects you are relating often have child business objects. For instance, some customer business objects have child business objects for storing address information. A child business object can participate in the kinds of relationships that Table 66 shows.
Table 66. Relationships for child business objects
Condition of child business object | Kind of relationship | For more information |
---|---|---|
The key for the child business object uniquely identifies the child beyond the context of its parent | Simple identity relationship |
"Coding a child-level simple identity relationship" |
The key for the child business object does not uniquely identify it beyond the context of its parent | Composite identity
relationship |
|
To maintain the child business objects during an Update operation as part of the identity relationship | Parent/child relationship |
"Managing child instances" |
If the child is a multiple-cardinality child business object, you can change the index to make the participant reference a specific child. To do so, select the child's key attribute, right-click, and select Change Index from the Context menu. If the source and destination children in a map correspond one to one, the index is not significant and you do not need to change it. However, if the map transforms the children in any other way, you can enter a specific index number. For example, if the child business objects represent addresses and the third source address corresponds to the first destination address, you can change the indexes to 2 and 0, respectively.