54
Siebel Email Administration Guide Version 8.1/8.2
Administering Siebel Communications Server for Siebel Email Response ■ Siebel
Server Requirements for Siebel Communications Server
132
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” on page 136.
■
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” on page 136 and “Administering Communications Inbound
Processor” on page 147.
■
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” on page 147.
■
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 Name Server 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.
37
Administering Siebel Communications Server for Siebel Email Response ■ About
Setting Up Siebel Communications Server for Siebel Email Response
Siebel Email Administration Guide Version 8.1/8.2
133
■
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” on page 133
■
“About Setting Up Siebel Communications Server for Nonreal-Time Email Processing” on page 134
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” on page 152.
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.
47
Siebel Email Administration Guide Version 8.1/8.2
Administering Siebel Communications Server for Siebel Email Response ■ About
Setting Up Siebel Communications Server for Siebel Email Response
134
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” on page 153.
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 an eMarketing
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” on page 50.
47
Administering Siebel Communications Server for Siebel Email Response ■ About
Starting Server Components
Siebel Email Administration Guide Version 8.1/8.2
135
■
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” on page 57.
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” on page56. For information
about submitting requests, see “Resubmitting Failed Email” on page293.
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.
34
Siebel Email Administration Guide Version 8.1/8.2
Administering Siebel Communications Server for Siebel Email Response ■
Administering Communications Inbound Receiver
136
■
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” on page 137
■
“Running Communications Inbound Receiver” on page 137
■
“Configuring Parameters for Communications Inbound Receiver” on page 138
■
“Activity Attachments Stored for Incoming Messages” on page 139
50
Administering Siebel Communications Server for Siebel Email Response ■
Administering Communications Inbound Receiver
Siebel Email Administration Guide Version 8.1/8.2
137
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” on page 139.
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” on page140.
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.
53
Siebel Email Administration Guide Version 8.1/8.2
Administering Siebel Communications Server for Siebel Email Response ■
Administering Communications Inbound Receiver
138
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” on page 132. 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.
43
Administering Siebel Communications Server for Siebel Email Response ■
Administering Communications Inbound Receiver
Siebel Email Administration Guide Version 8.1/8.2
139
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” on page 205.
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.
36
Siebel Email Administration Guide Version 8.1/8.2
Administering Siebel Communications Server for Siebel Email Response ■ Events and
Communications Inbound Receiver
140
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.
Related Topics
“Event States” on page 141
“State Transitions” on page 142
“Event Processing” on page 143
“Errors Encountered While Processing Events” on page 146
“Logged Event Types and Subtypes” on page 146
Documents you may be interested
Documents you may be interested
