Standard behavior for the event notification

Table 117 lists standard features for event retrieval and notification.

Table 117. Standard features for event notification

Category and name Description Supported?
Connector Properties
Event distribution The event retrieval mechanism includes a filter that processes only events that are associated with the connector making the poll call. This feature requires adding a ConnectorId field to the event table so that multiple connectors can use the same event table. Each connector also requires a ConnectorId connector property. This property sets the identifier for a particular instance of a connector and allows the connector to pick up only the events assigned to it. See "Event distribution".
_ Full
_ Partial
_ No
_ N/A

PollQuantity The connector uses the PollQuantity connector property to specify the maximum number of events the connector will process for each poll call. If possible, the connector should limit the number of rows retrieved in the poll call to PollQuantity. (For example, in SQL Server, use the set rowcount option.) See "Retrieving event records".
_ Full
_ Partial
_ No
_ N/A

Event Table
Event status values Where applicable, the values are used for event status are described in Table 117.
_ Full
_ Partial
_ No
_ N/A

Object key The object key column must use name-value pairs to set data in a new business object. For example, if ContractId is the name of an attribute in the business object, the object key is: ContractId=45381. The connector should support multiple name-value pairs separated by a delimiter. The delimiter is configurable (PollAttributeDelimiter) and should default to a colon (:). See "Object key".
_ Full
_ Partial
_ No
_ N/A

Object name The object name field should be set to the exact business object name. See "Standard contents of an event record".
_ Full
_ Partial
_ No
_ N/A

Priority Priority is 0-n, with 0 being the highest priority. The connector polls and processes events in order of priority. Note that no decrementing is done, which could, in rare circumstances, lead to low priority events being shut out (not processed). See "Processing events by event priority".
_ Full
_ Partial
_ No
_ N/A

Miscellaneous Features
Archiving An event is archived once the connector has processed it, whether or not the event was successfully delivered to InterChange Server. The event status is kept in the archive table and is one of the following:
  • Success. The event was detected, and an object was created and sent to InterChange Server.
  • Unsubscribed. The event was detected, but the connector did not have a subscription for that event/verb combination, so the event was not sent to InterChange Server.
  • Error. The event was detected, but the connector encountered an error in trying to process the event, either in the process of building a business object or in posting the object to InterChange Server.
_ Full
_ Partial
_ No
_ N/A

CDK method gotApplEvent() The connector should call gotApplEvent()only from within pollForEvents().
_ Full
_ Partial
_ No
_ N/A

Delta event notification An event can be created that represents only the changes to a hierarchical business object, such as the addition or deletion of order lines, without creating an update event for the entire business object. [Not currently an IBM Standard]
_ Full
_ Partial
_ No
_ N/A

Future event processing The mechanism for specifying a future date or time at which an event should be processed. The connector does not process the event until that date or time. [Not currently an IBM Standard]
_ Full
_ Partial
_ No
_ N/A

In-Progress event recovery When restarted, a connector checks the event table for events that have a status of IN_PROGRESS. If any exist, the connector does one of the following:
  • PropValue = FailOnStartup: Logs a fatal error and sends an email notification.
  • PropValue = Reprocess: Submits the events to InterChange Server.
  • PropValue = LogError: Logs an error but does not shut down.
  • PropValue = Ignore: Ignores these entries in the event table.

This behavior is configurable via the InDoubtEvents connector property. Use the Notes field to describe exactly how the connector handles this feature.

_ Full
_ Partial
_ No
_ N/A

Physical delete event The connector creates an empty business object with the Delete verb, with key values populated and the rest of the attributes populated with CxIgnore, and sends the object to InterChange Server. See "Processing Delete events".
_ Full
_ Partial
_ No
_ N/A

RetrieveAll The connector retrieves the entire hierarchical business object during subscription delivery. See "Retrieving application data".
_ Full
_ Partial
_ No
_ N/A

Smart filtering Duplicate events are not saved in the event store. Before storing a new event as a record in the event store, the event detection mechanism queries the event store for existing events that match the new event. The event detection mechanism does not generate a record for a new event in these cases:
  • The business object name, verb, key, status, and ConnectorId (if applicable) in a new event match those of another unprocessed event in the event store.
  • The business object name, key, and status for a new event match an unprocessed event in the event store. In addition, the verb for the new event is Update, and the verb for the unprocessed event is Create.
  • The business object name, key, and status for a new event match an unprocessed event in the event store. In addition, the verb in the unprocessed event in the event store is Create, and the verb in the new event is Delete. In this case, remove the Create record from the event store.
_ Full
_ Partial
_ No
_ N/A

Verb stability The connector should send a business object with the same verb that is in the event table. See "Getting the business object name, verb, and key".
_ Full
_ Partial
_ No
_ N/A

Copyright IBM Corp. 1997, 2003