.evt to .xevt

Before a workflow processes a message, an event is renamed with a .xevt extension so that if a failure occurs, on Communications Inbound Receiver restart it is possible to tell which messages were in-process.

.xevt to event deletion

An event is deleted from the disk if a workflow processes the event with no errors.

.paused to .evt

Every five minutes the queue directory is scanned for .paused events. Found events are renamed with the .evt extension and processed again. When Communications Inbound Receiver begins processing a response group, it looks on the disk for any messages with a .paused extension. These events were paused when Communications Inbound Receiver was previously stopped. These events are renamed with the .evt extension, reloaded, and processed again.

.xevt to .paused

An event is paused and renamed with the .paused extension if a transitory error (for example, a database failure) occurs while the event is being processed. Within five minutes, the event is reprocessed.

.evt to .paused

An event is paused and renamed with .paused extension if a transitory error occurs before an event can be processed. Within five minutes, another attempt is made to process the event.

.xevt to failed event deletion

If an event cannot be deleted after it is processed, then an error message is logged and an email is sent warning the administrator of the impending reprocessing of an event. When the server restarts, the .xevt event is requeued as a .retry.evt event.

.xevt to .error

An event is given a .error extension if a workflow returns an error while processing the event.

.xevt to .failed

An event is given a .failed extension if a non-transitory error occurs while processing the event.

.xevt to .retry.evt

When Communications Inbound Receiver begins processing a response group, it looks on the disk for any messages with a .xevt extension. These events were in-process when Communications Inbound Receiver failed abnormally so it cannot be determined if they are directly responsible for the failure.

To avoid discarding events that do not cause the failure, the events are requeued with a .retry.evt extension. However, if the server fails while processing the .retry.evt event, then it is possible to determine that the message is already party to one failure, which indicates that it might have caused the failure. This determination can help to avoid infinite requeueing of such events.

.retry.evt to .retry.xevt

An event that might have previously caused a failure is renamed with a retry.xevt extension before workflow processing.

.retry.evt to .crash

An event that is party to two abnormal Communications Inbound Receiver failures is renamed with a .crash extension.

retry.xevt to .error

An event that might have previously caused a failure, which then causes a workflow error, is renamed to with an .error extension.