Filter
Top Products
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
4 Adapter for i2 User Guide