Business object processing

This section provides an overview of how the connector processes business object requests and application events. For more detailed information, see Business object verb processing.

Processing business object requests

When the connector receives a request to perform an application operation, the connector processes hierarchical business objects recursively; that is, it performs the same steps for each child business object until it has processed all individual business objects. The order in which the connector processes child business objects and the top-level business object depends on whether the child business objects are contained with or without ownership and whether they are contained with single cardinality or multiple cardinality.

Note:
The term hierarchical business object refers to a complete business object, including all the child business objects that it contains at any level. The term individual business object refers to a single business object, independent of any child business objects it might contain or that contain it. The term top-level business object refers to the individual business object at the top of the hierarchy that does not itself have a parent business object.

Business object retrieval

When an integration broker asks the connector to retrieve a hierarchical business object from the database, the connector attempts to return a business object that exactly matches the current database representation of that business object. In other words, all simple attributes of each individual business object returned to the integration broker match the value of the corresponding field in the database. Also, the number of individual business objects in each array contained by the returned business object match the number of children in the database for that array.

To perform such a retrieval, the connector uses the primary key values in the top-level business object to recursively descend through the corresponding data in the database.

Business object RetrievalByContent

When an integration broker asks the connector to retrieve a hierarchical business object based on values in non-key attributes in the top-level business object, the connector uses the value of all non-null attributes as the criteria for retrieving the data.

Business object creation

When an integration broker asks the connector to create a hierarchical business object in the database, the connector performs the following steps:

  1. Recursively creates each single-cardinality child business object contained with ownership into the database.
  2. Processes each single-cardinality child business object contained without ownership.
  3. Creates the top-level business object in the database.
  4. Creates each single-cardinality child business object that stores the parent/child relationship in the child.
  5. Creates each multiple-cardinality child business object.

Business object modification

When an integration broker asks the connector to update a hierarchical business object in the database, the connector performs the following steps:

  1. Uses the primary key values of the source business object to retrieve the corresponding entity from the database.
  2. Recursively updates all single-cardinality children of the top-level business object.
  3. For single-cardinality child business objects that store the relationship in the parent, sets each foreign key value in the parent to the value of the primary key in the corresponding single-cardinality child business object.
  4. Updates all simple attributes of the retrieved business object except those whose corresponding attribute in the source business object contain the value CxIgnore.
  5. Sets all foreign key values in each child that stores the parent/child relationship in the child (both multiple-cardinality and single-cardinality) to the primary key value of its corresponding parent business object.
  6. Processes all arrays of the retrieved business object.

Business object deletion

When an integration broker asks the connector to delete a hierarchical business object from the database, the connector performs the following steps:

  1. Deletes the single-cardinality children.
  2. Deletes the multiple-cardinality children.
  3. Deletes the top-level business object.

Processing application events

The connector handles the Create, Update, and Delete events generated by the application in the manner described below.

Create notification

When the connector encounters a Create event in the event table, it creates a business object of the type specified by the event, sets the key values for the business object (using the keys specified in the event table), and retrieves the business object from the database. After it retrieves the business object, the connector sends it with the Create verb to the integration broker.

Update notification

When the connector encounters an Update event in the event table, it creates a business object of the type specified by the event, sets the key values for the business object (using the keys specified in the event table), and retrieves the business object from the database. After it retrieves the business object, the connector sends it with the Update verb to the integration broker.

Delete notification

When the connector encounters a Delete event in the event table, it creates a business object of the type specified by the event, sets the key values for the business object (using the keys specified in the event table), and sends it with the Delete verb to the integration broker. All values other than the key values are set to CxIgnore. If any of the non-key fields are significant at your site, modify the value of the fields as needed.

The connector handles logical and physical Delete operations that are triggered by its application. In the case of physical deletes, the SmartFiltering mechanism removes all of the business object's unprocessed events (such as Create or Update) before inserting the Delete event into the event table. In the case of logical deletes, the connector inserts a Delete event in the event table without removing other events for the business object.

Retrieving business objects for event processing

A Retrieve can be done in two ways on a business object for event processing. The first is a Retrieve based on key attributes in a business object. The second is a Retrieve based on both key and non-key attributes. In this case, the business object needs to support the RetrieveByContent verb and must use name_value pair for the object keys.

Note:
If the object key does not use name_value pair, the keys in the object key field should follow the same order as the keys in the business object.

Copyright IBM Corp. 1997, 2003