Siebel Email Response Administration Guide > Completing Basic Setup Tasks > How Real-Time Events Flow Through the Communications Inbound Receiver >

Possible State Transitions


There are a number of possible state transitions for events. These possible transitions are described in Table 10.

Table 10.  State Transitions for Events
Transition
Reason for Transition

.evt -> .xevt

Before a message is processed by a workflow, it is renamed to have an ".xevt" extension so that if a crash occurs it will be possible on CIR restart to tell which messages were "in-process".

.xevt -> Event deletion

If a workflow processes an event with no errors the event is deleted from the disk.

.paused -> .evt

Every five minutes the queue directory is scanned for ".paused" files, if found, they are renamed to ".evt" and processed again. When the CIR begins processing a response group, it looks on the disk for any messages with a ".paused" extension. These Events were paused when the CIR was previously stopped. These events are renamed and reloaded and processed as normal ".evt" files.

.xevt -> .paused

If a transitory error occurs, (for example, if a database goes down) while an event is being processed it will be "paused" and reprocessed within five minutes.

.evt -> .paused

If a transitory error occurs before an event can be processed, it is "paused" by renaming to ".paused". Within five minutes, another attempt will be made at processing the event.

.xevt -> failed event deletion

If an event cannot be deleted after it has been processed, an error message is logged and an email is sent that warns the administrator of the impending re-processing of an event. This is will happen because when the server restarts, the ".xevt" event will be requeued as a ".retry.evt" event.

.xevt -> .error

If a workflow returns an error while processing an event, the event is given a ".error" extension.

.xevt -> .failed

If a non transitory error occurs while processing an event, the event is given a ".failed" extension.

.xevt -> .retry.evt

When the CIR begins processing a response group, it looks on the disk for any messages with a ".xevt" extension. These events were "in-process" when the CIR terminated abnormally so it cannot be determined whether or not they are directly responsible for the crash. To avoid discarding events that did not cause the crash, the events are requeued with a ".retry.evt" extension. However, if the server crashes while processing the ".retry.evt" event, it is possible to determine that the message h as already been party to one crash, which indicates that it may have caused the crash. This can also help to avoid infinite requeing of such events.

.retry.evt -> .retry.xevt

An event that may have previously caused a crash is renamed to have a "retry.xevt" extension before being reprocessed by a workflow.

.retry.evt -> .crash

An event that was party to two abnormal CIR terminations will be renamed to ".crash".

retry.xevt -> .error

An event that may have previously caused a crash, which then causes a workflow error is renamed to "*.error".

Siebel Email Response Administration Guide