Siebel Email Administration Guide > Administering Siebel Communications Server for Siebel Email Response > Events and Communications Inbound Receiver >

Event Processing

This topic gives one example of how you can use Communications Inbound Receiver events. You can use Communications Inbound Receiver events differently, depending on your business requirements.

Events are stored in a subfolder in the bin/queued directory. The subfolder name is based on the response group name. You can override the root directory, bin/queued, using the EventQueueDirectory server parameter for Communications Inbound Receiver.

Figure 5 illustrates event processing. Each of the subtopics in this topic explains one letter notation in this illustration.

Figure 5. Event Processing

Typical Communications Inbound Receiver Events

The following process describes processing of a typical Communications Inbound Receiver event:

1. The driver generates an event for Communications Inbound Receiver.
2. Communications Inbound Receiver creates a .evt file that stores the driver event.
3. Communications Inbound Receiver renames the .evt file to .xevt immediately before workflow execution.
4. The workflow executes without any errors and the .xevt file is deleted.

Figure 5 illustrates this process in the illustration lines with a notation of A.

Errors During Communications Inbound Receiver Email Processing

The following process describes a processing error during Communications Inbound Receiver email processing:

1. The driver generates an event for Communications Inbound Receiver.
2. Communications Inbound Receiver creates a .evt file that stores the driver event.
3. Communications Inbound Receiver renames the .evt file to .xevt immediately before workflow execution.
4. The workflow returns an error that causes the event to be renamed from .xevt to .error.
5. An email is sent to the administrator, and the following error is logged: Error invoking method %1 on event %2. Event will be reprocessed within %3 seconds.
6. Within five minutes, the event is renamed from .error to .evt and requeued.

Figure 5 illustrates this process in the illustration lines with a notation of B.

Database Failures During Communications Inbound Receiver Processing

The following process describes what happens when a Siebel database fails during Communications Inbound Receiver processing:

1. The driver generates an event for Communications Inbound Receiver.
2. Communications Inbound Receiver creates a .evt file that stores the driver event.
3. Communications Inbound Receiver renames the .evt file to .xevt immediately before workflow execution.
4. The workflow returns an error, and Communications Inbound Receiver determines the Siebel database is down.
5. Communications Inbound Receiver renames the .xevt file to .paused.
6. Within five minutes, the event is renamed from .paused to .evt and requeued.

Figure 5 illustrates this process in the illustration lines with a notation of C.

Failure Errors During Communications Inbound Receiver Processing

The following process describes what happens when a failure error occurs during Communications Inbound Receiver processing:

1. The driver generates an event for Communications Inbound Receiver.
2. Communications Inbound Receiver creates a .evt file that stores the driver event.
3. Communications Inbound Receiver renames the .evt file to .xevt immediately before workflow execution.
4. A failure occurs during email processing.
5. When Communications Inbound Receiver restarts, the .xevt file is found and renamed to .retry.evt.
6. The following warning message is logged: Event %s may have caused crash, requeueing event for one retry.
7. The event is requeued for processing.

Figure 5 illustrates this process in the illustration lines with a notation of D.

Typical Processing of an Event that Previously Caused a Failure

The following process describes the typical processing of an event that previously caused a failure:

1. Communications Inbound Receiver renames retry.evt to retry.xevt immediately before workflow execution.
2. The workflow executes without error and retry.xevt is deleted.

Figure 5 illustrates this process in the illustration lines with a notation of D1.

Processing of an Event that Caused a Second Failure

The following process describes what happens the second time an event causes a failure:

1. Communications Inbound Receiver renames retry.evt to retry.xevt immediately before workflow execution.
2. A failure occurs during workflow execution.
3. When Communications Inbound Receiver restarts, the retry.xevt file is found and renamed to .crash.
4. An email is sent to the administrator, and the following error message is logged: Event %s may have caused crash, change .crash extension to .evt to requeue on restart.

Figure 5 illustrates this process in the illustration lines with a notation of D2.

NOTE:  The event is not reprocessed because it is assumed to have caused the failure. To reprocess the event, change the .crash extension to .evt.