For event notification, the connector detects events written to a queue by an application rather than a database trigger. An event occurs when the Telcordia Service Delivery application generates messages and stores them on the Telcordia message queue.
The connector uses the pollForEvents() method to poll the Telcordia queue at regular intervals for messages. When the connector finds a message, it retrieves it from the Telcordia queue and examines it to determine its format. If the format has been defined in the connector's static object, the connector passes both the message body and a new instance of the business object associated with the format to the configured data handler; the data handler is expected to populate the business object and specify a verb. If the format is not defined in the static meta-object, the connector passes only the message body to the data handler; the data handler is expected to determine, create and populate the correct business object for the message. See "Error handling" for event failure scenarios.
The connector processes messages by first opening a transactional session to the input queue. This transactional approach allows for a small chance that a business object could be delivered to a collaboration object twice due to the connector successfully submitting the business object but failing to commit the transaction in the queue. To avoid this problem, the connector moves all messages to an in-progress queue. There, the message is held until processing is complete. If the connector shuts down unexpectedly during processing, the message remains in the in-progress queue instead of being reinstated to the original input queue.
Optionally, to support applications that want feedback on the requests they issue, the connector for Telcordia will issue report messages back to the applications detailing the outcome of their requests once they have been processed.
To achieve this, the connector will post the business data for such requests synchronously to InterChange Server. If a collaboration object successfully processes the business object, the connector will send a report back to the requestor including the return code from InterChange Server and any business object changes. If the connector or the collaboration object fails to process the business object, the connector will send a report containing the appropriate error code and error message.
In either case, an application that sends a request to the connector for Telcordia will be notified of its outcome.
If the connector for Telcordia receives any messages requesting positive or negative acknowledgement reports (PAN or NAN), it will post the content of the message synchronously to InterChange Server and then incorporate the return code and modified business data in to a report message that will be sent back to the requesting application.
The table below shows the required structure of Telcordia messages sent to
the connector to be processed synchronously.
MQMD field | Description | Supported values (use the logical OR operator to support multiple values) |
---|---|---|
MessageType | Message Type | DATAGRAM |
report | Options for report message requested | You can specify one or both of the following:
You can specify one of the following to control how the correlation ID of the report message is to be set:
|
ReplyToQueue | Name of reply queue | The name of the queue to which the report message should be sent. |
replyToQueueManager | Name of queue manager | The name of the queue manager to which the report message should be sent. |
Message Body |
| A serialized business object in a format compatible with the data handler configured for the connector. |
Upon receipt of a message as described in the table above, the connector will do the following:
The table below shows the structure of the report that is sent back to the
requestor from the connector.
MQMD field | Description | Supported values (use the logical OR operator to support multiple values) |
---|---|---|
MessageType | Message type | REPORT |
feedback | Type of report | One of the following:
|
Message Body |
| If the collaboration object successfully processed the business object,
the connector will populate the message body with the business object returned
by the collaboration object. This default behavior can be overridden by
setting the DoNotReportBusObj property to true in the
static meta-data object.
If the request could not be processed, the connector will populate the message body with the error message generated by the connector or the collaboration object. |
Upon initialization, the connector checks the in-progress queue for messages that have not been completely processed, presumably due to a connector shutdown. The connector configuration property InDoubtEvents allows you to specify one of four options for handling recovery of such messages: fail on startup, reprocess, ignore, or log error.
With the fail on startup option, if the connector finds messages in the in-progress queue during initialization, it logs an error and immediately shuts down. It is the responsibility of the user or system administrator to examine the message and take appropriate action, either to delete these messages entirely or move them to a different queue.
With the reprocessing option, if the connector finds any messages in the in-progress queue during initialization, it processes these messages first during subsequent polls. When all messages in the in-progress queue have been processed, the connector begins processing messages from the input queue.
With the ignore option, if the connector finds any messages in the in-progress queue during initialization, the connector ignores them, but does not shut down.
With the log error option, if the connector finds any messages in the in-progress queue during initialization, it logs an error but does not shut down.
If the connector property ArchiveQueue is specified and identifies a valid queue, the connector places copies of all successfully processed messages in the archive queue. If ArchiveQueue is undefined, messages are discarded after processing. For more information on archiving unsubscribed or erroneous messages, see Error handling in Creating or modifying business objects.