Status updates
No status updates are made to the i2 applications. Typically, the event status, for example, SUCCESS, FAIL, UNSUBSCRIBED, is written to the application’s event store. Since no event store is maintained for i2, the status update strategy is not relevant for the i2 connector. Error messages, if any, are logged to the i2 adapter log file. For more information, see Chapter 5, “Troubleshooting and error handling”, on page 27.
Event retrieval
For the i2 connector, polling is single threaded. The connector uses i2 metaobjects to register the operations of interest with the CIS agent for polling. These metaobject names have the i2MO prefix and store information about the operation and the corresponding IBM wrapper business object name for the specified operation and type. The attributes for the metaobject are specified as static default values. Default value is an attribute property, which can be set at the business object design time. For information on the wrapper business object structure and attribute properties, see Chapter 3, “Understanding business objects for the connector”, on page 11 and Chapter 4, “Generating business objects using i2 ODA”, on page 17.
The steps involved in retrieving a subscription message are as follows:
1.The i2 connector registers the operations with the CIS agent after reading the i2MO metaobject information. The information in the metaobjects is cached by the i2 connector with the first poll call.
2.Each poll call is issued from the integration broker based on the connector property PollFrequency. In case there were any registration failures in the first poll call, the i2 connector tries to register the same operation with the subsequent poll calls.
3.With all the poll calls, the i2 connector checks on the output of the operations that it has registered with the CIS agent. If there is any output from any of the operations, it retrieves the output in the form of a CIS record. The i2 connector retrieves the PollQuantity (connector property) number of messages for each poll call for each registered operation.
Example: If the PollQuantity is set to 5 and there are 5 registered operations, each poll call will result in checking the output 25 times. If the PollQuantity is not set, a default of 1 message is retrieved for each poll call for each operation.
4.The retrieved XML message is converted to a business object. The business object is set as the child attribute in the wrapper business object for the operation. The instance ID from which this output was retrieved is set as the instance ID in the metaobject attribute of the wrapper. For more information, see Chapter 3, “Understanding business objects for the connector”, on page 11.
5.The connector sends the wrapper business object to the integration broker for further processing.
Processing verbs (operations)
Operations are i2’s equivalent for verbs and are defined by the XML structure provided by i2 for each port. For more information, see Chapter 3, “Understanding business objects for the connector”, on page 11, and Chapter 4, “Generating business objects using i2 ODA”, on page 17.
Processing service call requests
When the i2 connector receives a service call request from an integration broker to perform an operation in an application, the request takes the form of a wrapper business object. The wrapper business object encompasses the instance ID
4Adapter for i2 User Guide
