Administering Siebel Communications Server for Siebel Email Response

This chapter describes how to configure and run the components for Siebel Communications Server. It includes the following topics:

Siebel Server Requirements for Siebel Communications Server

To use Siebel Communications Server in your enterprise, note the following basic requirements relating to Siebel Server:

The Siebel Server installation must include the Communications Management (CommMgmt) component group.
After installation, the Communications Management component group must be enabled.

For information about using Siebel Server load balancing with Siebel Communications Server and about the architecture of Siebel Communications Server, see Siebel CTI Administration Guide.

This topic contains the following information:

Server Components for Siebel Communications Server

This guide includes information about the following server components in the Communications Management component group:

Communications Inbound Receiver (CommInboundRcvr). Receives inbound work items and, in some deployments, queues them for Communications Inbound Processor processing. Work items can include email messages for Siebel Email Response. For more information, see Administering Communications Inbound Receiver.
- For real-time work items, such as email messages for most deployments of Siebel Email Response, Communications Inbound Receiver processes the work items it receives. Communications Inbound Processor is not used.
- For nonreal-time work items, such as email messages for some high-volume deployments of Siebel Email Response, Communications Inbound Receiver queues the work items it receives for further Communications Inbound Processor processing.

Communications Inbound Processor (CommInboundProcessor). For deployments of Siebel Email Response supporting nonreal-time work items, processes inbound work items that Communications Inbound Receiver queues. For more information, see Administering Communications Inbound Receiver and Administering Communications Inbound Processor.
Communications Outbound Manager (CommOutboundMgr). Processes outbound communications for email, fax, wireless message, or page channels. This component directly supports communication requests or supports them through Siebel Workflow. This component also supports outbound capabilities for Siebel Email Response and for the Send Email, Send Fax, and Send Wireless Message commands. For more information, see Administering Communications Outbound Manager.
Page Manager (PageMgr). Sends pages. The Send Page command uses this component. Some workflow processes in Siebel Workflow also use this component. For more information about setting up and using Page Manager, see Siebel Business Process Framework: Workflow Guide.
Email Manager (MailMgr). Sends email. Some workflow processes in Siebel Workflow use this component. For more information about setting up and using Email Manager, see Siebel Business Process Framework: Workflow Guide.

Synchronizing Batch-Mode Server Components

Communications Inbound Receiver, Communications Inbound Processor, and Communications Outbound Manager are batch-mode components. You need to synchronize batch-mode server components between the Siebel Gateway and the Siebel database when you perform any of the following actions:

Create new server components.
Create new component jobs.
Modify existing server components.
Delete server components.
Enable server components.
Disable server components.

For more information about synchronizing batch-mode server components, see Siebel System Administration Guide.

About Setting Up Siebel Communications Server for Siebel Email Response

Siebel Communications Server supports many communication channels that you use to communicate with customers by using server components such as the Communications Inbound Receiver, the Communications Inbound Processor, and the Communications Outbound Manager.

Note: If you change the number of tasks or threads for a server component, then make sure that the Maximum Tasks parameter is greater than or equal to the number of response groups multiplied by the number of threads. A thread is represented by a task and three subtasks.

This topic contains the following information:

About Setting Up Siebel Communications Server for Real-Time Email Processing

When you use real-time email processing, you use only the Communications Inbound Receiver server component to receive and process email. For information about enabling real-time processing, see Enabling Real-Time Email Processing.

Communications Inbound Receiver monitors email accounts (email addresses) by using communications driver profiles to check for inbound messages. When Communications Inbound Receiver detects an inbound email, it receives the email message and sends the message through the Workflow Process Manager for processing.

After the email is processed and an activity is created, the message is stored in the Siebel database (if the message is less than 16 KB) or the Siebel File System (if the message is larger than 16 KB). The Server Request Broker component receives inbound requests from some other component. For example, when you submit profile or response group changes, the Server Request Broker component executes these commands.

About Setting Up Siebel Communications Server for Nonreal-Time Email Processing

When you use nonreal-time email processing, Communications Inbound Receiver monitors email accounts (email addresses) by using communications driver profiles to check for inbound messages. For information about enabling nonreal-time processing, see Enabling Nonreal-Time Email Processing.

When Communications Inbound Receiver detects an inbound email, it gets the email from the email server, converts the email into event data, and creates a server request for the Server Request Broker component to inform Communications Inbound Processor of the new event. Communications Inbound Processor uses workflows to process and route the event. Communications Outbound Manager uses communications driver profiles to handle outbound communications to customers.

You set up communications drivers and profiles to connect the Siebel Server to your email server.

Communications drivers. Drivers specify the protocol to use to access the email server, and driver parameters control the behavior of each driver. For example, the Internet SMTP/POP3 Server driver logs in to the POP3 server and checks for new email at an interval that you set in the PollingInterval driver parameter.

You can use the same communications driver for different purposes. For example, you can use the same communications driver to perform the following tasks:

Monitor multiple email accounts (addresses).
Monitor email addresses for other departments in your organization, such as a marketing outbound campaign.

Although you can use the same communications driver for multiple purposes, make sure that you set up a unique email address and response group for each group and purpose.

Note: Changes that you make to a communications driver’s parameters affect everyone who uses that driver. Therefore, it is recommended that the person in your organization who maintains communications drivers makes or approves all changes.

Communications driver profile. A driver profile specifies a specific mailbox for monitoring and rules (profile parameter overrides) for the way the driver behaves while monitoring that mailbox.

Communications drivers and profiles for Siebel Email Response enable Communications Inbound Receiver to monitor mailboxes for inbound messages. Other communications channels, such as voice, use different communications drivers and profile types.

Each communications driver profile for Siebel Email Response processes both incoming and outgoing email. Therefore, you must configure each driver profile for both.

To set up Siebel Communications Server for Siebel Email Response:

Set up your communications driver parameters to establish defaults for all profiles that use the driver.
Create a communications driver profile for each email account that Siebel Email Response monitors. This process includes creating profile parameter overrides. For more information, see Process of Setting Up Communications Driver Profiles.
Create at least one response group. This process includes creating input arguments and associating a profile with the response group. For more information, see Process of Setting Up Response Groups.

About Starting Server Components

For the Communications Inbound Receiver and the Communications Inbound Processor server components, a single component instance has multiple subtasks that run at the same time as the server component task. The Communications Inbound Receiver and the Communications Inbound Processor server component tasks and subtasks must be running before Siebel Email Response can process incoming email. Therefore, you must start all Communications Inbound Receiver and Communications Inbound Processor server component tasks and subtasks. For more information about enabling component groups when you configure the Siebel Server, see the Siebel Installation Guide for the operating system you are using and Siebel System Administration Guide.

Before starting any Communications Inbound Receiver or Communications Inbound Process component tasks, note the following guidelines:

If you try to start the same Communications Inbound Receiver or Communications Inbound Processor component task twice, then the second attempt is rejected. However, the first instance is running as usual. You can always increase the number of subtasks for each component task if you have a high volume of incoming email messages.
One component task can have multiple associated subtasks, and the subtasks route the email. The component task acts like a controller to coordinate its subtasks.

Note: The preconfigured number of maximum threads is five. If you change the number of threads for a server component, then make sure that the Maximum Tasks parameter is greater than or equal to the number of response groups multiplied by the number of threads. A thread is represented by a task and three subtasks.

If you change the Siebel Email Response setup after you implement Siebel Email Response, then you must stop and restart the Communications Inbound Receiver and the Communications Inbound Processor server components for your changes to take effect.

For some changes, you must stop and restart these server components only if you want your changes to take effect immediately. For example, for changes to a workflow process take effect, you can submit them without stopping these server components. For information about submitting profile changes, see Submitting Changes for Communications Driver Profiles. For information about submitting requests, see Resubmitting Failed Email.

Task Failures at the Email Process Level

When a task fails, the following events occur:

An email message is sent to the email address in the Administrator Email Address field of the response group.
The administrator checks the log files that are attached to the email and identifies possible causes of the server component task failure.
If the cause is a workflow step error, then the administrator fixes the workflow.
If the cause is a profile error, then the administrator verifies that the profile for the response group is valid.

The administrator manually restarts the server component task.

Main Tasks and Subtasks

Each time you start an instance of Communications Inbound Receiver, Siebel Email Response starts one main task and five subtasks. The main task is assigned the first (lowest) task number (for example, 1318). The five subtasks are assigned the next numbers in sequence (for example, 1319, 1320, 1321, 1322, and 1323). The main task manages the subtasks and the message queue. The subtasks process inbound messages by pulling the inbound messages from the queue and passing them to the appropriate workflow.

Communications Inbound Processor has only one main task.

Administering Communications Inbound Receiver

The Communications Inbound Receiver server component receives and processes inbound work items, such as email messages. Depending on your deployment, it might queue them for further Communications Inbound Processor processing. The short name for this component is CommInboundRcvr.

This topic contains the following information:

Event Processing for Real-Time and Nonreal-Time Processing

For both real-time processing and nonreal-time processing, inbound email is saved as event data to the local disk in a file with the .EVT file extension. Message content and attachments are also saved to the Siebel File System. For more information, see Activity Attachments Stored for Incoming Messages.

How the inbound event is then processed depends on whether you use real-time processing or nonreal-time processing:

Real-time processing. In real-time processing, in which Communications Inbound Receiver performs all event processing, additional files are created on the local disk that represent different states of processing or represent error conditions. For more information about the processing of these files, see Events and Communications Inbound Receiver.
Extensions for these files include the following:
- XEVT. Events that are ready for workflow processing.
- ERROR. Events that generated known errors and that can be retried.
- CRASH. Events that failed for unknown reasons and must not be retried.

Nonreal-time processing. In nonreal-time processing, Communications Inbound Receiver writes event data to the Siebel database (in the S_CM_INBND_EVT table) and to the Siebel File System, and submits a request to Server Request Processor and Server Request Broker. Communications Inbound Processor retrieves this request and processes the event.
You can track nonreal-time events that are submitted to Communications Inbound Processor using the Communications Inbound Events view of the Administration - Communications screen. You can manually resubmit events that are not fully processed due to transient errors from this view. You cannot track real-time events.
Valid status for events in the Communications Inbound Events view include:
- Queued. Communications Inbound Receiver submitted the event for Communications Inbound Processor processing.
- CIP Processing. Communications Inbound Processor received the event and is currently processing the event.
- Error. Event processing failed due to a known error. You can resubmit the event for processing using the Submit Request command in the applet menu.
- Fatal. Event processing failed due to an unknown error and must not be resubmitted.

Running Communications Inbound Receiver

When the Communications Management component group is enabled, the Communications Inbound Receiver component starts automatically. For any computer on which you do not want to run Communications Inbound Receiver, configure the Siebel Server to not start it. Communications Inbound Receiver restarts automatically if the Siebel Server fails and is brought back up.

Communications Inbound Receiver is a batch-mode server component, although it also has characteristics of other component types. It relies on the services of the Server Request Broker and Server Request Processor server components. These components must be running on the Siebel Server for communications to process successfully. As a batch-mode component, Communications Inbound Receiver has requirements. For more information, see Synchronizing Batch-Mode Server Components. For more information about configuring, starting, and stopping Siebel Server components, see Siebel System Administration Guide.

To provide greater availability and reliability for your deployment of the Communications Inbound Receiver server component, you can update active response groups and individual profiles loaded in active response groups without stopping and restarting the server component as follows:

Update profiles by using the Submit Profile Changes command for the profile.
Update response groups (and all profiles in the response group) by using the Submit Response Group Changes command for the response group.

Configuring Parameters for Communications Inbound Receiver

You can specify values for the following parameters for the Communications Inbound Receiver server component:

Administrator Email Address (alias AdminEmailAddress). Specify a value for the Administrator Email Address parameter to provide an administrator email address to send messages to when inbound communications processing errors occur and no such address is defined for the response group.
Default Administrator Address (alias DefaultAdminAddress). Specify a value for the Default Administrator Address parameter to provide an administrator email address to send messages to when server errors, such as a broken database connection, occur.
Event Queue Directory (alias EventQueueDirectory). Specify a value for the Event Queue Directory parameter to provide the name of the directory in which to store queued events. Use this parameter to specify a value to override the default location in the bin/queued directory.
Maximum Tasks (alias MaxTasks). Specify a value for the Maximum Tasks parameter to configure the maximum number of tasks for this component. (This parameter is part of the Process Management subsystem.)
Note: Maximum Tasks must always be a value greater than the value of Max Threads.
Max Threads (alias MaxThreads). Specify a value for the Max Threads parameter to configure the maximum number of threads for this component. The value that you specify determines the number of threads that Communications Inbound Receiver can create at the same time to process email. When specifying the value for MaxThreads, consider the CPU capacity available on the computer that hosts Communications Inbound Receiver.
SMTP Server Name (alias SMTPServer). Specify a value for the SMTP Server Name parameter to provide the name of the SMTP server that is used to send email to the administrator.
SMTP Server Port (alias SMTPServerPort). Specify a value for the SMTP Server Port parameter to provide the port for the SMTP server that is used to send email to the administrator.

Activity Attachments Stored for Incoming Messages

For each inbound email message that Communications Inbound Receiver or Communications Inbound Processor processes, an activity record is created by using the Email - Inbound activity type. The original email content is saved in the form of one or more attachments to this activity record.

The entire original email message content (the entire MIME-encoded message that the POP3 or IMAP server receives) is saved in an attachment file named Original_Msg.txt.

If the original message is more than 16,000 characters long (including any HTML markup), then the full message is saved as another attachment named SiebelLongEmailBody.txt (for plain-text messages) or SiebelLongEmailBody.htm (for HTML messages).

If the original message is less than 16,000 characters long (including any HTML markup), then you can save the SiebelLongEmailBody attachment by setting the Save Email Body as Attachment user property for the Mail Agent Activity business component to TRUE.

Additional files might be created and saved as attachments to the activity, depending on the existence of embedded message content and on the setting of the Parse Embedded Messages parameter for the communications driver. For more information about this parameter, see Parameters for Internet SMTP/IMAP Server Driver and Internet SMTP/POP3 Server Driver.

Note the following behavior for different settings of the Parse Embedded Messages parameter:

When Parse Embedded Messages is FALSE, the following behavior applies:
For each embedded message, a single attachment file is created that contains the entire MIME embedded message. This file is named EmbeddedMsgpartspecifier.eml, where partspecifier represents the file’s placement in the original message’s structure, for example, EmbeddedMsg01.eml, EmbeddedMsg3.4.eml, and so on. You can open these files using any application that can read an EML file, such as Microsoft Outlook Express.

When Parse Embedded Messages is TRUE (the default), the following behavior applies:
- For a plain-text email message, all text components are saved in one or more attachment files. These files are named textplainpartspecifier.txt, where partspecifier represents the file’s placement in the original message’s structure, for example, textplain01.txt, textplain3.4.txt, and so on.
- For an HTML email message, all HTML components are saved in one or more attachment files. These files are named texthtmlpartspecifier.htm, where partspecifier represents the file’s placement in the original message’s structure, for example, texthtml01.htm, texthtml3.4.htm, and so on.
- Any attachments to the original email message are also saved as attachments to the activity record. These files have their original file names.

Events and Communications Inbound Receiver

When Communications Inbound Receiver is started, it loads the communications drivers that its processing response groups require. Each response group can use multiple communications profiles. Each communications profile requires a communications driver. The communications driver retrieves messages and passes them to Communications Inbound Receiver in the proper format.

The communications drivers pass tag-value pairs, which define the content of the incoming messages, to Communications Inbound Receiver. Any attachments that are associated with the incoming message are stored on the email server. References to these attachments are included in the name-value pairs that the communications drivers pass to Communications Inbound Receiver. The workflows that Communications Inbound Receiver invoke delete all file attachments when these attachments are no longer needed.

Communications Inbound Receiver takes the incoming message data and serializes it to a disk-based queue. The disk is used instead of memory for the following reasons:

Persistence. If the computer fails, then the queued events are not lost.
Memory. Storing on disk reduces Communications Inbound Receiver memory requirements.
Capacity. Disk space is essentially unlimited, so the queue size is unbounded.

Events are stored in folders underneath the queued directory. The folders are named after the response group that generates the events. Events are in the UTF-8 character set, which translates 16-bit Unicode characters into 8-bit characters. Each event always has a file name prefix of CIR.

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

Event States

The disk-based events have special file extensions that represent the event’s current state. The following table shows these file extensions and corresponding states.

Table Event States for Email Response

File Extension	Event State
.evt	An event that is queued and waiting for processing by a work queue thread (normally a workflow).
.xevt	An event is that is currently being processed by a work queue thread. (A workflow is executing.)
.paused	An event that is executing when a transitory error (like a database failure) occurs. An event with this extension is reprocessed every five minutes.
.error	An event that causes a workflow error. An event with this extension is reprocessed every five minutes.
.retry.evt	An event that is queued for a second time because an abnormal termination of Communications Inbound Receiver interrupts the initial processing. The abnormal termination might be related to the processing of this event.
retry.xevt	An event that is queued for a second time and is currently being processed by a work queue thread. (A workflow is executing.)
.crash	An event that is processed by the workflow during two abnormal Communications Inbound Receiver terminations. It is likely that the processing of this event is causing the abnormal termination. You can reprocess this event by changing the .crash file extension to .evt and reloading the response group. To enable the event execution without reloading the response group, rename the event with the .paused extension.
.failed	An event for which a non-transitory error occurs during processing. You can reprocess this event by changing the .failed extension to .evt and reloading the response group. To enable the event execution without reloading the response group, rename the event with the .paused extension.

State Transitions

The following table describes the state transitions for events.

Table State Transitions for Events for Email Response

Transition	Reason for Transition
.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.

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.

The following figure illustrates event processing. Each of the subtopics in this topic explains one letter notation in this illustration.

Typical Communications Inbound Receiver Events

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

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

The figure in Event Processing 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:

The driver generates an event for Communications Inbound Receiver.
Communications Inbound Receiver creates a .evt file that stores the driver event.
Communications Inbound Receiver renames the .evt file to .xevt immediately before workflow execution.
The workflow returns an error that causes the event to be renamed from .xevt to .error.
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.
Within five minutes, the event is renamed from .error to .evt and requeued.

The figure in Event Processing 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:

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

The figure in Event Processing 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:

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

The figure in Event Processing 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:

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

The figure in Event Processing 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:

Communications Inbound Receiver renames retry.evt to retry.xevt immediately before workflow execution.
A failure occurs during workflow execution.
When Communications Inbound Receiver restarts, the retry.xevt file is found and renamed to .crash.
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.

The figure in Event Processing 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.

Errors Encountered While Processing Events

Any error encountered while processing events never results in the termination of the Communications Inbound Receiver component. All errors are logged and email messages are sent for the following conditions:

An event deletion failure.
A workflow error.
An event that is in-process during two abnormal Communications Inbound Receiver terminations.
An event that causes two workflow errors.
An event that causes one workflow error and is in-process during an abnormal Communications Inbound Receiver termination.

Logged Event Types and Subtypes

When incoming messages are logged on the email server, a logged event type and subtype are created for each event. You can filter the quantity and detail of logged messages. The following table describes the logged event types for Siebel Email Response.

Table Event Types for Email Response

Event Type	Description
EMR_Performance	Set to 2 or higher to see performance logging.
EMR_Tracking	Set to 2 or higher to see information that is useful for tracking the flow of driver events.
EMR_Data	Set to 2 or higher to see detail about the actual event data.
EMR_Log	Use for general purpose logging.
LogEvent	Use for logging information about the events.

The following table describes the event subtypes for event types.

Table Event Subtypes for Email Response

Event Subtype	Description
LogDebug (5)	Logs debug information including function entry and exit points.
LogDetail (4)	Logs all information except function entry and exit points.
LogError (1)	Logs all errors.
LogFatal (0)	Logs terminal errors.
LogInfo (3)	Logs information that is helpful for performance issues.
LogWarning (2)	Logs messages that warn of possible issues.

To change the log level, you can enter the following srvrmgr command:

change evtloglvl LogEvent=X for comp CommInboundRcvr

where: X is one of the numbers in parentheses in the previous table.

Administering Communications Inbound Processor

The Communications Inbound Processor server component processes inbound work items, such as email messages, that Communications Inbound Receiver previously received and queued. The short name for this component is CommInboundProcessor.

Note: Communications Inbound Processor is used for nonreal-time event processing, but not for real-time event processing. For more information about real-time processing and nonreal-time processing, see Processing Incoming Email.

Running Communications Inbound Processor

When the Communications Management component group is enabled, the Communications Inbound Processor component starts automatically. For any computer on which you do not want to run Communications Inbound Processor, configure the Siebel Server to not start it. Communications Inbound Processor restarts automatically if the Siebel Server fails and is brought back up.

Communications Inbound Processor is a batch-mode server component. It relies on the services of the Server Request Broker and Server Request Processor server components. These components must be running on the Siebel Server for communications to process successfully. As a batch-mode component, Communications Inbound Processor has requirements. For more information, see Synchronizing Batch-Mode Server Components. For more information about configuring, starting, and stopping Siebel Server components, see Siebel System Administration Guide.

Administering Communications Outbound Manager

This topic describes how to administer the Communications Outbound Manager server component. The alias for this component is CommOutboundMgr.

Communications Outbound Manager processes outbound communications for email, fax, wireless message, or page channels. It supports outbound capabilities for Siebel Email Response and for the Send Email, Send Fax, and Send Wireless Message commands. It also supports communication requests, whether users directly create and submit them, or Siebel Workflow creates and submits them. For more information, see Defining Outbound Communication Requests

For this server component, you can configure a parameter that specifies how Siebel bookmarks are generated, and you can configure a logging parameter. Otherwise, this component uses generic parameters and you do not need to configure it. For more information, see Configuring Communications Outbound Manager and Configuring Shared or Separate Logging.

This topic contains the following information:

Running Communications Outbound Manager

When the Communications Management component group is enabled, the Communications Outbound Manager component is started automatically. For any computer on which you do not want to run Communications Outbound Manager, configure the Siebel Server to not start it.

Communications Outbound Manager is a batch-mode server component. It relies on the services of the Server Request Broker and Server Request Processor server components. These components must be running on the Siebel Server for communication requests to dispatch successfully.

Note: If a messaging system server, such as an email server, is restarted, then the Communications Outbound Manager server component that connects to it must also be restarted.

As a batch-mode component, Communications Outbound Manager is subject to requirements. For more information, see Synchronizing Batch-Mode Server Components. For more information about configuring, starting, and stopping Siebel Server components, see Siebel System Administration Guide.

If Communications Outbound Manager is not synchronized, as appropriate, then users who submit outbound communication requests might receive the following error message:

Unable to find definition for component CommOutboundMgr

For more information about monitoring communication requests and server requests, see Monitoring Outbound Communication Requests and Monitoring Outbound Communication Requests as Server Requests.

Configuring Communications Outbound Manager

For Communications Outbound Manager, you can configure a parameter that specifies how Siebel bookmarks are generated, configure a parameter that specifies whether logging must use shared or separate files, and configure logging levels. For more information about configuring logging for server components, see Siebel System Administration Guide.

Configuring Siebel Bookmarks

To support the Attach Bookmark setting for advanced communications templates, the Siebel administrator must specify a value for the WebServer server component parameter for Communications Outbound Manager.

This parameter specifies a string that identifies the Web server and Application Object Manager to include in the URL. The URL has the following form:

http://web_server/application_object_manager

To access the bookmarked record, the recipient users must have access to the specified Web server and Application Object Manager. For more information about using the Attach Bookmark setting for advanced templates, see Fields for Templates.

Configuring Shared or Separate Logging

An administrator can review log files for the Communications Outbound Manager component to monitor its performance and to monitor user activities that invoke this component.

Depending on how you configure the Communications Outbound Manager server component, a single log file might be generated for all requests, or a separate log file might be generated for each request (the default). The parameter that modifies this setting is called LogUseSharedFile.

Log files are written to the log subdirectory of the Siebel Server installation directory.

Set LogUseSharedFile according to how the server component is generally used as follows:

For miscellaneous uses, including supporting the Send commands, sending auto-acknowledgement messages and replies for Siebel Email Response, and sending several outbound requests to a small number of recipients, you can set LogUseSharedFile to TRUE to reduce clutter in your log directory.
For high-volume outbound communication requests, however, you can leave this parameter set to FALSE to generate a single log file for each request that you can analyze. LogUseSharedFile is FALSE by default.

The log file names vary according to how you set LogUseSharedFile as follows:

When a single log file is generated for all requests, the file name is in the form CommOutboundMgr_xxx.log, where xxx is the ID number for the main Communications Outbound Manager task.
When a separate log file is generated for each request, the file names are in the form CommOutboundMgr_xxx.log, where xxx is the ID number for the Communications Outbound Manager task applicable to the specific communication request.

The Outbound Communications Manager business service, run on the Siebel Server, uses the same naming convention to generate log files in the same location.

Configuring Log Levels for Communications Outbound Manager

An administrator can set logging levels for Communications Outbound Manager to specify the degree of detail captured in the logs. Logging levels include:

CommSrvrError (level 1). Lowest level of logging. The most severe errors are logged. Level 1 is the default.
CommSrvrWarning (2). Moderate level of logging. More detail than level 1 is logged. Use this level for production.
CommSrvrTrace (3). Moderately high level of logging. More detail than level 2 is logged.
CommSrvrDebug (4). Highest level of logging. All errors and warnings and other events are logged. Use this level for testing purposes.

To configure log levels for Communications Outbound Manager

Navigate to the Administration - Server Configuration screen, then the Servers view.
Specify the Siebel Server on which Communications Outbound Manager runs.
In the Components list, select the record for the Communications Outbound Manager component.
Click the Events tab.
Select the record for the CommServer event type.
Specify one of the values described in this topic.

Specifying Siebel Server for Communications Outbound Manager

If you have more than one Siebel Server, and you want all outbound communications that are processed using a particular communications driver or profile to use a specific Siebel Server, then you can configure a parameter to specify the server name. You set the value of the Siebel Server driver parameter (generally, using a profile parameter override) to the name of the Siebel Server that is to handle the delivery of the outbound communications.

This parameter supports outbound communications sent (using the Communications Outbound Manager server component) using communications drivers that support outbound communications.

Note: The value of the Siebel Server parameter must exactly match the actual name of the Siebel Server.

As with other driver parameters, you can either specify a default value or provide an override value for a particular communications profile. For more information about the driver parameters, see Managing Email, Fax, and Other Communications Products

Note: If an outbound communication request includes multiple templates, and this parameter value exists for the delivery profile associated with any of the templates, then you cannot specify a different value for this parameter for the profiles of any of the other templates in the same request.

Specifying Component Name for Outbound Communication Requests

When you create an outbound communication request, you can specify the name of the server component that is to process the request.

The default component name is CommOutboundMgr (for Communications Outbound Manager). If you configure new server components that are based on CommOutboundMgr, then you can give them other names. Then, when you create requests, you can provide the applicable component name in the Component Name field for the request.

When Siebel Server load-balancing is in effect, you can create multiple components using the same name. You might create the same name for a subset of your total set of Siebel Servers.

If different Siebel Servers use different Siebel runtime repositories, then you can use this mechanism to make sure that a specified set of Siebel Servers process certain types of requests. For more information about the description for the Component Name field, see Fields for Outbound Communication Requests.

Outbound Communications for Siebel Mobile Web Client

Outbound communications sent from Siebel Web Client are processed immediately. When you are connected to the local database and disconnected from the enterprise database, communications sent from Siebel Mobile Web Client are saved until you synchronize. The Communications Outbound Manager server component then processes them for delivery.

Starting Server Components

Depending on your server architecture and business requirements for processing email, start the following server components for Siebel Email Response:

Communications Inbound Receiver
Communications Inbound Receiver and Communications Inbound Processor (if you use nonreal-time email processing)
Communications Outbound Manager

If you make any changes (other than profile or response group changes) to your Siebel Email Response setup after implementation, then you must stop and restart these server components so that your changes take effect. If you make profile or response group changes, then you can submit them without stopping the server components. For more information about enabling component groups when you configure Siebel Server, see the Siebel Installation Guide for the operating system you are using and Siebel System Administration Guide.

This topic contains the following procedures:

Automatically Restarting Server Components

If Communications Inbound Receiver or Communications Inbound Processor fails, then a new process is started automatically for the server component if the AutoRestart component parameter is True. The new process looks through all the response groups in the Siebel database and picks those records in which Startup is Active and Siebel Server is the current Siebel Server name. (The Siebel Server field cannot be blank.) Then the new process starts a Communications Inbound Receiver or Communications Inbound Processor component task for each record.

You can access the status page for Communications Inbound Receiver by navigating to:

http:\\hostname:55555

where: hostname is the name of the Siebel Server on which Communications Inbound Receiver is running.

To verify Communications Inbound Receiver or Communications Inbound Processor auto-restart

Navigate to the Administration - Server Management screen, then the Servers view.
In the servers list, select the appropriate server, and click the Tasks view tab.
In the Tasks list, query for the components named Communications Inbound Receiver or Communications Inbound Processor.
If the Status field value is not Active, then refresh the view by clicking another view tab and then clicking the Server view tab.
When the value in the Status field changes to Active, auto-restart is complete.

Enabling Real-Time Email Processing

If you are processing inbound email in real-time mode, then start only Communications Inbound Receiver. Complete the procedure in this topic to enable real-time email processing. For information about real-time email processing, see Real-Time and Nonreal-Time Processing.

To enable real-time email processing

Navigate to the Administration - Communications screen, then the All Response Groups view.
In the Response Groups list, select the response group for which you want to enable real-time processing.
Click the Input Arguments view tab.
In the Name field, enter the RealTime input argument, and in the Value field enter True.
This value is the default for this input argument.

Enabling Nonreal-Time Email Processing

If you are processing inbound email in nonreal-time mode, then you start both Communications Inbound Receiver and Communications Inbound Processor. Complete the procedure in this topic to enable nonreal-time email processing. For information about nonreal-time email processing, see Real-Time and Nonreal-Time Processing.

To enable nonreal-time email processing

Navigate to the Administration - Communications screen, then the All Response Groups view.
In the Response Groups list, select the response group for which you want to enable nonreal-time processing.
Click the Input Arguments view tab.
In the Name field, enter the RealTime input argument, and in the Value field enter False.