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

Scenario for Communications Inbound Receiver Events

This topic gives one example of how the Communications Inbound Receiver Events may be used. You may use Communications Inbound Receiver Events differently, depending on your business model.

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

Processing Typical Communications Inbound Receiver Events

The following process describes a typical Communications Inbound Receiver event. This process is represented graphically in Figure 5.

1. The driver generates an event for Communications Inbound Receiver.
2. The Communications Inbound Receiver creates an .evt file that stores the driver event.
3. The 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.  Processing Typical CIR Events

Managing Errors During Communications Inbound Receiver Email Processing

The following process describes a processing error during Communications Inbound Receiver email processing. This process is represented graphically in Figure 6.

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

Figure 6.  Processing Events with Workflow Errors

Managing Database Failures During Communications Inbound Receiver Processing

The following process describes what happens when a database goes down during Communications Inbound Receiver processing. This process is represented graphically in Figure 7.

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

Figure 7.  Processing Events when the Database is Down

Managing Crash Errors During Communications Inbound Receiver Processing

The following process describes what happens when a crash error occurs during Communications Inbound Receiver processing. This process is represented graphically in Figure 8.

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

Figure 8.  Processing Events After a Crash Error

Typical Processing of an Event that Previously Caused a Crash

The following process describes the typical processing of an event that previously caused a crash. This process is represented graphically in Figure 9.

1. The 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 9.  Typical Processing of an Event That Caused a Crash

Second Crash Error

The following process describes what happens the second time an event causes a crash. This process is represented graphically in Figure 10.

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

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

Figure 10.  Processing an Event That Causes a Second Crash