The i2 IBM business object is the IBM representation of the i2 message. Each type of message has a corresponding IBM business object.
The business objects are generated using the WebSphere Business Integration Adapter utility XML ODA, which reads the XML schema files for these types and generates the corresponding IBM business object. (See Generating business objects using the i2 ODA and Chapter 3, "XML data handler" in IBM WebSphere Business Integration Adapters Data Handler Guide.)
The i2 business object is a wrapper business object that encapsulates a metaobject, an operation, and input and/or output data (one or the other, both, or none) types or formats for the operation. The Top Level Object Wrapper includes in the metaobject (MO_Instance) the attribute values for the instanceId, connectionId, username, and password. The username and password are provided for authenticating with a different user during request processing.
There is one wrapper business object for each operation. For more information, see Generating business objects using the i2 ODA.
The following diagram shows the parts of a wrapper business object. A description of each part follows the diagram.
The following diagram illustrates a sample business object IBM_Bidding_BO, which has three child business objects. In the diagram:
The connector uses i2 metaobjects to register its interest in specific operations with the CIS agent so that polling can take place. You need to configure one metaobject for each operation of interest.
The metaobject name always starts with i2MO. Each metaobject holds information about the instance that supports the operation and the wrapper business object name for the operation. You need to add a dummy verb to all the metaobjects.
All of the attributes within the meat-object require a static default value. The attributes are within the metaobjects have a static default value.
The polling meta-bject has the following business object level application specific information:
For registering the same operation on a different instance, you either have to change the default value and restart the i2 instance or configure another metaobject for the new instance.
Polling subscriptions can be unregistered by altering the polling meta-object property. A new attribute unregister that accepts Boolean values is used to determine whether the adapter should unregister for this operation when the adapter is shut down. Connections created with the unregister operations value set to false will not be destroyed.
Events can be redelivered when the AutoAcknowledge property is set to false. This allows for the adapter to enable the i2 message bus to retain the event until it is successfully sent to the integration broker. This, in conjunction with enabling the adapter to keep its registration for events, will provide guaranteed message delivery.
Stateful operations allow the i2 connector to maintain the session state throughout a series of operations. These grouped operations are treated as multiple service calls or requests from the perspective of the i2 connector.
To use a stateful operation with the i2 connector, the integration broker requests a stateful connection using the metaobject BO_StatefulRequest that indicates the start and end of a series of stateful operations. The connection is maintained for the stateful operations by associating the connection with a connectionId. This connection is managed for all requests made with the aforementioned connectionId.
The following diagram shows the metaobject BO_StatefulRequest.
The valid values for the Request attribute are "Begin" and "End," signaling to the i2 connector to begin a series of stateful operations with the credential information provided in the MO_Instance. The connectionId can be provided or be generated by the i2 CIS agent. Using the connectionId that is returned from this request, the business processes making subsequent calls to the i2 connector can make stateful operation calls. The application-specific information "Type=Stateful" allows the i2 connector to determine that this business object is a request to start or end the series of stateful operations associated with the enclosed connectionId.
The following examples illustrate using metaobjects for stateful operations.
An auction application has a bidding system that uses an i2 CIS adapter to perform some of its auction services. The i2 CIS adapter has stateful operations to keep track of each bid by different users and also return the current winning bid at any time during the bidding process.
To use the i2 connector to make stateful calls and return the winning bid, the integration broker needs a business object to signal the beginning and end of the series of stateful operations (bids). It also needs a business object to submit a bid and another to return the winning bid.
Within the broker the integrator can create a business object based on the metaobject "BO_StatefulRequest", called Bidding_StatefulRequest. The following diagram shows this metaobject.
Here is an example of how these requests could be made using a broker's business process flow:
A bid has a "LaneId" and a "BiddingAmount, represented by the business object BO_Bid. A call is made to request the current winning bid using the "BO_optimizeBids" business object, which has the "LaneId" as an input business object and the winning bid as the output or returned business object. The returned business object has the "LaneId" and "WinningAmount".
-->Request processing, using Bidding_StatefulRequest with "Begin" and connectionId i2Bid.
-->Request processing, using BO_Bid with BiddingAmount.
-->Request processing using BO_Bid with BiddingAmount.
-->Request processing using BO_Bid with BiddingAmount.
-->Request processing using BO_OptimizeBids.
Result: The request is processed and the winning bid business object is returned (35).
-->Request processing using BO_Bid with BiddingAmount.
-->Request processing using BO_OptimizeBids.
Result: The request is processed and the winning bid business object is returned (40).
-->Request processing on Bidding_StatefulRequest with "Request=End".
An application requires a special security context to be used by calling clients of the customer configuration processes. An i2 CIS adapter provides a stateful operation that creates and stores the security context for later use by a subsequent call.
The integrator can use the i2 connector to help process these stateful operations using the security context created and provided by the i2 CIS adapter.
A business object called "i2SecContext_StatefulRequest" is created based on the metaobject "BO_StatefulRequest". The following diagram shows the i2SecContext_StatefulRequest metaobject.
Here is an example of how these requests could be made using a broker's business process flow:
-->Request processing using i2SecContext_StatefulRequest with "Begin".
Result: Since the connectionId was not set in this business object, after the request call, the returned object will contain the connectionId for which these stateful operations need to be associated.
-->Request processing using Security_Context business object
-->Request processing using Customer_Add business object, using the same connectionId provided by the stateful operation request.