WebSphere Business Integration Adapter business objects are 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 references a single child object. A cardinality n container object occurs when an attribute in the parent business object references an array of child business objects.
The connector supports both cardinality 1 and cardinality n relationships between business objects.
Infranet has the following container types:
You must define a WebSphere Business Integration Adapter Portal Infranet application-specific business object so that it maps to the Infranet flist for the corresponding storable object with all required attributes and relationships. The relationship between an flist and a business object is a one-to-one relationship.
During processing, the connector compares a business object to the corresponding flist for the Infranet object, and it throws an exception if the structures do not match. It is possible to define a WebSphere Business Integration Adapter business object that is a subset of the flist structure, but the converse is not supported.
For each Infranet container type, an application-specific business object is created as needed. Typically, a storable class becomes a top-level business object. A container of type substruct may become a cardinality 1 child business object, and a container of type array may become a cardinality n child business object. However, if a subcontainer is not important and the parent opcode is sufficient to manipulate the children, a child business object is not needed.
Figure 7 shows how the structure of a WebSphere Business Integration Adapter business object and an Infranet flists might correspond. See the Portal Infranet documentation for information on Infranet flists.
Figure 7. Structure business objects and flists
Figure 8 shows an example of a possible coordinating between the Infranet /account storable class and the Portal_Account hierarchical business object. The NameInfo array in the storable class becomes a cardinality n child business object in the top-level business object, and the Balances substruct becomes a cardinality 1 child business object.
Figure 9 shows a possible correspondence between the NameInfo array and the Portal_Contact child business object. The NameInfo array contains an array named Phones, which becomes a child business object whose parent is the Portal_Contact business object.
Figure 9. Corresponding of an flist array to a child business object
Note that specific attributes are needed for some flists and opcodes and not for others. In this case, an additional utility application-specific business object may be used as a verb parameter. This object does not correspond any persistent data; it describes only some mandatory fields for the flist. For more information on utility business objects, see "Connector utility business objects".