Siebel Email Response Administration Guide > Completing Basic Setup Tasks > Starting Siebel Email Response Server Tasks >

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.

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.

Managing 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. 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.

Managing Database Failures During Communications Inbound Receiver Processing

The following process describes what happens when a database goes down during Communications Inbound Receiver processing.

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.

Managing Crash Errors During Communications Inbound Receiver Processing

The following process describes what happens when a crash error occurs during Communications Inbound Receiver processing.

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.

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.

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.

Second Crash Error

The following process describes what happens the second time an event causes a crash.

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.

Stopping Communications Inbound Receiver and Communications Inbound Processing

If necessary, you can shut down the Communications Inbound Receiver and Communication Inbound Processor server components. For information on shutting down Siebel Server components, see Siebel System Administration Guide.