Table 11. State Transitions for Events for Email Response
|
|
.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. |