i2 business object structure

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.

Note:
This business object credential information is in addition to the Application Username and Password connector configuration properties provided for authentication at the global level.

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:


Configuring metaobjects for polling

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.

The attributes (instanceId, connectionId, username, password, wrapper business object name, and operation name) within the metaobjects have a static default value. 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.

In the following diagram, the metaobject named i2MO_AddBid is used to configure the instanceId CA_Instance, for the Bidding operation addBid, which is set on the wrapper business object named IBM_Bidding_BO. The values shown are default values for the attributes (connectionId, username, and password).


Using metaobjects for stateful operations

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.

Note:
While a series of stateful operations are being processed, if the i2 connector crashes the state of these operations is not maintained.

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.

Example 1 of 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".

Note:
Lines beginning with -->Request processing, indicate how to make the request.
  1. Start Bidding--Based on the LaneId, start a series of stateful operations:

    -->Request processing, using Bidding_StatefulRequest with "Begin" and connectionId i2Bid.

  2. Send Bid1--Send a bid for the LaneId with the BiddingAmount (8):

    -->Request processing, using BO_Bid with BiddingAmount.

  3. Send Bid2--Send a bid for the LaneId with the BiddingAmount (35):

    -->Request processing using BO_Bid with BiddingAmount.

  4. Send Bid3--Send a bid for the LaneId with the BiddingAmount (20):

    -->Request processing using BO_Bid with BiddingAmount.

  5. Send OptimizeBids--Send a request to get the current winning bid:

    -->Request processing using BO_OptimizeBids.

    Result: The request is processed and the winning bid business object is returned (35).

  6. Send Bid4--Send a bid for the LaneId with the BiddingAmount (40):

    -->Request processing using BO_Bid with BiddingAmount.

  7. Send OptimizeBids--Send a request to get the current winning bid:

    -->Request processing using BO_OptimizeBids.

    Result: The request is processed and the winning bid business object is returned (40).

  8. End Bidding--Send Bidding_StatefulRequest with connectionId "i2Bid" requesting the end of this series of stateful operations:

    -->Request processing on Bidding_StatefulRequest with "Request=End".

Note:
The connectionId is what associates a series of stateful operations with each other; therefore, for each series of bids a different connectionId should be provided. The broker can also allow the i2 CIS agent to generate the connectionId, which will be returned on the "Request=Begin" request call on the i2 connector. Using the returned connectionId, the broker can request a series of stateful operations.

Example 2 of stateful operations

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:

Note:
Lines beginning with -->Request processing, indicate how to make the request.
  1. Start Customer Add--Start a series of stateful operations using i2SecContext_StatefulRequest:

    -->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.

  2. Send Security Context--Send the business object with the security context credential information, with the connectionId being the same as returned from the stateful operation. This is set in the MO_Instance of this business object:

    -->Request processing using Security_Context business object

  3. Send Customer Add--Send the business object to add a customer using the same connectionId:

    -->Request processing using Customer_Add business object, using the same connectionId provided by the stateful operation request.

  4. End Customer Add--End this series of stateful operations using i2SecContext_StatefulRequest by submitting the business object with "Request=End" and the same connectionid.

Copyright IBM Corp. 1997, 2003