Interface table error management
Interface tables can be used for inbound and outbound data exchange. Errors can occur when writing inbound data from an interface table to a queue or outbound data from a queue to an interface table.
If an error is encountered by the cron task that pulls an outbound message from a queue, the message remains in the queue until the error condition is addressed. Errors may occur for the following reasons:
- The interface table does not exist.
- There is database error due to lack of space.
- The message content, as defined by the object structure, was altered but the interface table was not recreated to reflect the new message format.
When an outbound message reaches an interface table, it is the responsibility of the external application to retrieve that data and manage errors based on their integration implementation.
The cron task that writes inbound messages to a queue can encounter errors for the following reasons:
- The JMS queue is deactivated or free space is not available.
- The enterprise service or external system name is not valid.
- The enterprise service is not enabled for the external system.
- The external system is not enabled.
When an error occurs during inbound interface table processing, the polling program writes the exception trace in the IMPORTMESSAGE column of the MXIN_INTER_TRANS queue table. For the first error in the MXIN_INTER_TRANS queue table, the system sends an email notification to the administrator. You can resolve the error condition by updating the row of data in MXIN_INTER_TRANS, for example, correcting the value of the external system name, or by updating the configuration data in the application, for example, marking the enterprise service as enabled.
After the cron task processes subsequent records in the MXIN_INTER_TRANS queue table, it switches to an idle state that is based on the defined cron task processing intervals. When processing resumes, the cron task tries to process the records in error, as well as new records added to the MAX_INTER_TRANS queue table.
After sending an error notification, the cron task does not send notification of additional errors if the queue table contains one transaction that is marked in error. It is assumed that the person who was notified of the initial error sees and corrects additional errors when the queue table is examined. After all current errors are corrected, the cron task sends a notification when it encounters a new error.
Any errors that occur after the cron task successfully writes an interface table message to an inbound queue are managed by the error handling process for the queues.