WebSphere Business Integration Adapter business objects can be hierarchical: parent business objects can contain child business objects, which can in turn contain child business objects, and so on. A cardinality 1 container occurs when an attribute in a parent business object contains a single child object. A cardinality n container object occurs when an attribute in the parent business object contains an array of child business objects.
The connector supports both cardinality 1 and cardinality n relationships between business objects. In each type of cardinality, the relationship between the parent and child business objects is described by the application-specific text of the key attribute of the child object.
An illustration of this relationship for a cardinality 1 container is shown in Figure 4. An illustration of a cardinality n relationship for business objects for Clarify CRM would look the same as Figure 4 except that the container attribute would contain an array of child business objects.
Figure 4. Business object for Clarify CRM cardinality 1 containment
In each individual business object, the first attribute is the object key. Each subsequent attribute is either a container attribute or a simple attribute that does not contain a child business object.
An individual business object for Clarify CRM can represent one or more Clarify CRM database tables. For a business object that represents only one database table, the key attribute refers to the object ID of the Clarify CRM table or to another field in the Clarify CRM table that is used as the key. Each additional simple attribute within the business object represents a field in the table.
For an individual business object that represents multiple database tables, the business object key refers to the main table that the object represents. Each additional simple attribute within the business object represents a field in either the primary table or another table. The relationship between tables is contained in the attribute application-specific text in the business object definition.
In Clarify CRM, relationships between database tables are contained in named relations. Named relations are defined by Clarify CRM and are implemented as columns in the database tables. Clarify CRM application-specific business objects use named relations to provide the connector with information about how the business object relationships correspond to Clarify CRM tables.
WebSphere Business Integration Adapter business objects for Clarify CRM can use named relations in two ways:
When one or more relations are specified, the connector creates the relations between objects as part of Create or Update operations. For specific information on combining preprocessing and use of a relationship, see Troubleshooting.
Application-specific text can use either named relations or inverse relations to join tables. An inverse relation is typically used in a child business object to point back to the parent business object.
When designing a business object definition that references multiple Clarify CRM tables, you should make a design decision about the structure and purpose of the business object. For example, if a business object definition for a table includes a few attributes for another table, defining a single business object for the two tables may be sufficient. However, if a business object definition includes many important attributes from another table, you may want to create a child business object definition for the second table rather than locating attributes for both tables in the same business object definition. In addition, if the business object already references other child business objects, creating another child business object to represent a new table makes the business object structure consistent.
If you are creating a business object that will be used primarily for Create operations, organizing attributes for different tables into child business objects may be a logical approach. However, if the business object will be used primarily for Retrieve operations or event notification, it may be simpler to pass along information about multiple tables in one business object.
Figure 5 shows an example individual business object with attributes that reference a primary database table and attributes that reference additional tables by means of named relations.
For information on modifying a business object to add attributes that reference other tables, see "Specifying relations between objects".
Figure 5. Business objects related to multiple Clarify CRM database tables