5Configuring Communications Drivers and Profiles for Email
Configuring Communications Drivers and Profiles for Email
This chapter provides information about configuring communications drivers and profiles. It includes the following topics:
About Setting Up Parameters for Communications Drivers
Siebel Email Response uses the Internet SMTP/POP3 Server driver or Internet SMTP/IMAP Server driver to send and receive email messages. These drivers have several parameters that define their default behavior. Organizations might have multiple mailboxes to monitor such as customersupport@example.com, sales@example.com, and marketing@example.com. These mailboxes can share common parameters. For example, these mailboxes might have the same SMTP server parameter and POP3 or IMAP server parameter (mail.example.com). For more information, see How Communications Drivers Process Email Messages.
Administrators can set default driver parameters for the Internet SMTP/POP3 Server driver or Internet SMTP/IMAP Server driver, instead of setting these values for each profile that they create. If, however, the administrator has another mailbox (such as support-japan@example.com) that is on a different SMTP server and POP3 or IMAP server (such as japan.example.com), then the administrator must create profile parameter overrides for the Internet SMTP/POP3 Server driver or Internet SMTP/IMAP Server driver only for the support-japan@example.com profile.
The most common driver parameters that an administrator might change are parameters that are relatively consistent for most of an organization’s mailboxes, such as those for the SMTP server and POP3 or IMAP server, or parameters that you change occasionally for all profiles. For example, if an administrator is troubleshooting the communications setup and wants to enable debug logging, then the administrator changes the LogDebug parameter to True.
The administrator can set up a backup SMTP server, and define a parameter specifying the host name or IP address of the computer on which the backup SMTP server is running, as appropriate for your network configuration. This parameter is used when you implement a failover strategy for your SMTP server that handles outbound email or fax communications.
Communications Drivers Provided with Siebel Business Applications
Some communications drivers provided with Siebel Business Applications include:
Internet SMTP/IMAP Server. Supports Internet mail servers that support the SMTP protocol for outbound email, fax, or wireless messages or the IMAP protocol for inbound email (for Siebel Email Response). This driver supports both plain-text and HTML email. For more information, see Email Servers That Oracle Validates, and Managing Integrations with Email and Fax Servers.
Internet SMTP/POP3 Server. Supports Internet mail servers that support the SMTP protocol for outbound email, fax, or wireless messages or the POP3 protocol for inbound email (for Siebel Email Response). This driver supports both plain-text and HTML email. For more information, see Email Servers That Oracle Validates, and Managing Integrations with Email and Fax Servers.
Modem-based TAP Paging. For Siebel Paging, supports paging over a modem using the Telocator Alphanumeric Paging (TAP) protocol for outbound communication requests. (The Send Page command does not use this driver.) For more information, see Modem-Based TAP Paging Driver.
-
Note: Siebel Paging is included with all base applications of the Siebel Business Applications.
FTP. Supports File Transfer Protocol (FTP). Siebel Marketing uses this driver to send contact lists to vendors who are contracted to execute campaigns. For more information, see FTP Driver.
For information about files and database records for communications drivers and about developing new drivers, see Siebel CTI Administration Guide.
Email Servers That Oracle Validates
The Internet SMTP/IMAP Server and Internet SMTP/POP3 Server drivers are provided with Siebel Business Applications and are validated to work with several third-party email servers. For more information about currently supported third-party email servers and related products, see Siebel System Requirements and Supported Platforms on Oracle Technology Network and the third-party vendor documentation. For information about using the Internet SMTP/IMAP Server or Internet SMTP/POP3 Server driver to integrate Siebel Communications Server with email servers, see Managing Integrations with Email and Fax Servers.
The Internet SMTP/IMAP Server and Internet SMTP/POP3 Server drivers are compliant with the following RFC standards:
1894: delivery status notification
1939: POP3 (Internet SMTP/POP3 Server driver only)
2045 - 2049: MIME
2821: SMTP
2822: text message syntax
3207: SMTP session encryption using SSL
-
Note: Configure your email servers appropriately to work with Siebel applications. For example, for security reasons, your SMTP server might restrict from which originating computers outbound email messages can be relayed. In this scenario, you must configure the SMTP server to allow message relay from the Siebel Server computers running the Outbound Communications Manager server component.
About Profiles for Communications Drivers
You initially configure a communications driver by setting default parameter values for the driver in the Communications Drivers and Profiles view.
You can make a communications driver available to serve a particular purpose by creating one or more profiles that reference the driver. For each profile, you can specify parameter values to override the parameters of the referenced driver or to provide values that not specified.
Administrators can specify in the Communications Drivers and Profiles view the Siebel responsibilities and organizations that can see the profiles that users specify in some of the contexts of use. For more information, see Contexts of Use for Communications Driver Profiles.
Profile visibility applies to the Send Email window (in the Siebel native email client) and Send Fax window, to email reply features for Siebel Email Response, and to outbound communication requests. Users can see only those profiles that are associated with both their responsibilities and their organizations, or the profiles they create themselves.
If your company includes multiple organizations, then administrators can associate each profile with a responsibility and an organization. For example, Siebel Email Response might use this association to find the contact for an inbound email message.
Contexts of Use for Communications Driver Profiles
Administrators or (in limited contexts) users can create communications driver profiles. They can specify communications driver profiles for use by administrators and users in many communications-related contexts in the Siebel application.
Administrator Contexts for Using Profiles
Administrators specify profiles in the following contexts:
When defining response groups for inbound communications to support Siebel Email Response.
When configuring mobile devices associated with employees, contacts, or others. This configuration supports wireless messaging. These profiles are associated with device addresses for each mobile device for each person.
User Contexts for Using Profiles
In general, users specify profiles in the following contexts:
When specifying a default email or fax profile in the Outbound Communications view of the User Preferences screen. The profile specifies the message sender.
To specify the sender when sending outbound communications using the Send Email command (for the native Siebel email client) or the Send Fax command.
When configuring mobile devices associated with the user. This configuration supports wireless messaging. Profiles are associated with device addresses for each mobile device for the user.
Specialized users specify profiles in the following contexts:
When defining communications templates for use with outbound communication requests.
When defining contact lists for vendor campaign execution in Siebel Marketing.
If the capability is provided to them, then users can create profiles for their own use by using the My Profiles view in the Communications screen. User-defined profiles support particular features, such as the Send Email or Send Fax command, for which the users can directly specify the profile to use.
In any of the user contexts, an user can see only the profiles that meet one of the following conditions:
The responsibility associated with the profile is one of the user’s responsibilities and the organization associated with the profile includes the user’s current position.
The user created the profile.
Process of Setting Up Communications Driver Profiles
For Siebel Email Response, communications driver profiles map to individual accounts or mailboxes on a server. For example, customersupport@example.com or info@example.com are valid accounts to which you can map a profile.
Because you can use the same driver for many different profiles, you must create a unique profile to differentiate each of your email server accounts. For example, customersupport@example.com and info@example.com must have separate profiles. Although you can use any name, it is recommended that you use the email address as the profile name to make each profile easier to identify.
You can determine the email profiles that are available in the From drop-down list on an email reply by associating profiles with responsibilities. For example, you might want your support representatives to send replies only from customersupport@example.com and your marketing representatives to send replies only from info@example.com. Create a responsibility for each group and associate each profile and agent with the appropriate responsibility.
Each profile has parameter overrides that assign unique behaviors to it. A common parameter override is Mail Password. This topic provides basic information for creating a communications driver profile.
To set up a communications driver profile, perform the following tasks:
Repeat these tasks for each Siebel Email Response mailbox.
Creating Communications Driver Profiles
You first create a communications driver profile. After you create the profile, you assign overrides to the profile. For more information, see Assigning Parameter Overrides to Communications Driver Profiles.
To create this profile, you use the information that you gather during the planning process. For more information, see Setup Information for Siebel Email Response.
This task is a step in Process of Setting Up Communications Driver Profiles.
To create a communications driver profile
Navigate to the Administration - Communications screen, then the Communications Drivers and Profiles view.
In the Communications Drivers list, select Internet SMTP/POP3 Server or Internet SMTP/IMAP Server.
In the Profiles list, create a new record, and complete the necessary fields.
The fields are described in the following table.
Field Description Name
Type the name of the profile (the mailbox that you want to monitor). It is recommended that you use the email address of the profile name.
Organization
Select an organization to associate with the profile.
If your company has only one organization, then do not change the default value.
If your company has multiple organizations, then click the select button and select the appropriate organization in the Pick Organization dialog box.
When an email sender has contact records that exist in multiple organizations, Siebel Email Response can use the organization ID on the receiving profile to look up the sender. You must add an input argument named Lookup Sender By Organization to the response group and set the value to True. This value also determines the profile that shows in the drop-down list.
Responsibilities
Select the responsibilities for this profile in the Responsibilities dialog box.
Responsibilities determine the email profiles that show in the From drop-down list on an email reply. Only the email profiles that are associated with these responsibilities show for users whose personal profiles contain the same responsibilities.
The profile is visible to a user in the profile’s context of use. For example, in Siebel Email Response and in the Send Email and Send Fax commands, the profile is visible if it meets one of the visibility criteria. For more information about the visibility criteria, see Contexts of Use for Communications Driver Profiles.
Assigning Parameter Overrides to Communications Driver Profiles
You assign parameter overrides to the profile. To assign these overrides, you use the information that you gather during the planning process. For more information, see Setup Information for Siebel Email Response.
Some driver parameters have no default value. If a parameter is required, then you must assign the value as a profile parameter override when you create the profile.
If you use the Internet SMTP/IMAP Server or Internet SMTP/POP3 Server driver in an environment that supports multiple email servers, then you must create different profiles for this driver. Each profile includes a different value for the SMTP Server parameter, which identifies the name of the server.
This task is a step in Process of Setting Up Communications Driver Profiles.
To assign parameter overrides to a communications driver profile
Navigate to the Administration - Communications screen, then the Communications Drivers and Profiles view.
In the Communications Drivers list, select Internet SMTP/POP3 Server or Internet SMTP/IMAP Server.
Click the Profiles view tab, and select the appropriate profile.
In the Profile Parameter Overrides list, create a new record, and add the necessary parameter override fields:
In the Name drop-down list, select the name of the driver parameter for which you want to change the value.
If you cannot see the entire name in the drop-down list, then move your cursor over it to make the full name appear. For descriptions of driver parameters, see Parameters for Internet SMTP/IMAP Server Driver and Internet SMTP/POP3 Server Driver.
- Complete the Value field.
Enabling Cryptographic Protocols for Communications Drivers
Cryptographic protocols include SSL (Secure Sockets Layer) or TLS (Transport Layer Security). To configure cryptographic protocols for communications drivers and for communication between servers, complete the following procedures:
This task is a step in Process of Setting Up Communications Driver Profiles.
Enabling SSL or TLS Connection for Communications Drivers
The procedure in this topic describes how to enable SSL or TLS connection for communications drivers. In this procedure, you define parameters that relate to the communications drivers.
When you define the parameters, including SMTP Account Name and SMTP Account Password, an attempt is made to execute the AUTH LOGIN command at the start of the SMTP session. If the AUTH LOGIN command fails, then the session is terminated, a log file error message is generated, and the message is not sent. This occurrence is not a permanent fatal error for the driver, so the existing retry logic for Communications Outbound Manager applies, and another attempt is made to send the message at a later date.
To enable SSL or TLS connection for communications drivers
Navigate to the Administration - Communications screen, then the Communications Drivers and Profiles view.
In the Communications Drivers list, select Internet SMTP/POP3 Server or Internet SMTP/IMAP Server.
Click the Driver Parameters view tab, and complete the fields in the following table.
| Field | Description |
|---|---|
Enable SSL for IMAP |
If you select Internet SMTP/IMAP Server in Step 2 , then type a value of True to enable SSL. |
Enable SSL for POP3 |
If you select Internet SMTP/POP3 Server in Step 2, then type a value of True to enable SSL. |
Enable SSL for SMTP |
Type a value of True to enable SSL. |
Enable TLS for IMAP |
If you select Internet SMTP/IMAP Server in Step 2, then type a value of True to enable TLS. |
Enable TLS for POP3 |
If you select Internet SMTP/POP3 Server in Step 2, then type a value of True to enable TLS. |
Enable TLS for SMTP |
Type a value of True to enable TLS. |
IMAP Server Port |
If you select Internet SMTP/IMAP Server in Step 2, then change the IMAP port to 993 for secure SSL or TLS connections. Change the IMAP port to 143 (or your email server port for IMAP) for nonsecure connections. Nonsecure connections are not recommended. The email server uses its self-signed preconfigured certificates. The default value for this port is 143. |
POP3 Server Port |
If you select Internet SMTP/POP3 Server in Step 2, then change the POP3 port to 995 for secure SSL or TLS connections. Change the POP3 port to 110 (or your email server port for POP3) for nonsecure connections. Nonsecure connections are not recommended. The email server uses its self-signed preconfigured certificates. The default value for this port is 110. |
SMTP Account Name |
Type the value for the SMTP account name. |
SMTP Account Password |
Type the value for the SMTP account password. |
SMTP Backup Account Name |
Type the account name for the backup SMTP interface that requires user authentication. |
SMTP Backup Account Password |
Type the account password for the backup SMTP interface that requires user authentication. |
SMTP Server Port |
Change the SMTP port to 465 for secure SSL or TLS connections. Change the SMTP port to 25 (or your email server port for SMTP) for nonsecure connections. Nonsecure connections are not recommended. The email server uses its self-signed preconfigured certificates. The default value for this port is 25. |
Setting Server Parameters for SSL or TLS
To ensure secure transactions between the Siebel Server and the email server, it is highly recommended that you set the SSL (Secure Sockets Layer) or TLS (Transport Layer Security) server parameters in the procedure in this topic. This procedure describes how to set these server parameters to enable cryptographic authentication. After completing this procedure, restart the Siebel server to implement the parameter changes. For more information about the parameters for SSL and TLS, see the Siebel Installation Guide for the operating system you are using and the topics in Siebel Security Guide about configuring encryption for Siebel Enterprise or Siebel Server.
To set the SSL or TLS server parameters
Navigate to the Administration - Server Configuration screen, then the Servers view.
In the Servers list, select the Siebel Server.
Click the Parameters view tab.
Set the SSL or TLS parameters in the following table.
| Parameter | Description |
|---|---|
CA certificate file name |
Type the URL to the Cryptographic Authentication (CA) certificate file. You must set this value to enable CA of email messages. An example of this URL is |
Certificate file name |
Type the URL to the certificate file. |
Peer Authentication |
Type a value of True. This parameter enables Cryptographic Authentication.
Note: To enable authentication, you
must at a minimum set the CACertFileName and PeerAuth parameters.
|
Private key file name |
Type the URL to the key file. |
Private key file password |
Type the password of the key file. |
Validate peer certificate |
Type a value of False. This parameter enables authentication of the certification files. |
Submitting Changes for Communications Driver Profiles
You submit any profile changes. When you submit profile changes, you unload the profile and profile configuration settings from all response groups that are loaded with the profile. You also load the profile in all of the response groups that you configure with the profile.
Submit profile changes in the following situations:
If you change only the parameters (or the underlying driver parameters) on a communications driver profile that at least one response group currently loads.
-
Note: If you attempt to submit profile changes for a communications driver profile that a response group does not load, then your action has no effect.
If you remove a profile from a response group and you want only the profile to unload without unloading and reloading all of the other profiles. Remove the profile from the response group and then submit profile changes so that the response group unloads the profile.
If you want to move a communications driver profile between response groups. You must remove the profile from one response group and submit the change, and then add the same profile to another response group and submit the change. By submitting profile changes, you cause the communications driver profile to stop executing in one response group (the response group that you move the communications driver profile from) and start executing in the other response group (the response group that you move the communications driver profile to).
This task is a step in Process of Setting Up Communications Driver Profiles.
To submit changes for communications driver profiles
Navigate to the Administration - Communications screen, then the Communications Drivers and Profiles view.
In the Communications Drivers list, select Internet SMTP/POP3 Server or Internet SMTP/IMAP Server.
Click the Profiles view tab.
In the Profiles Menu drop-down list, select Submit Profile Changes.
Process of Setting Up Response Groups
A response group includes input arguments that define the behaviors for one or more profiles. Communications Inbound Receiver processes each item by using the input arguments in the response group. When Communications Inbound Receiver starts, it searches for all active response groups and starts them. Because Siebel Workflow manages Siebel Email Response functionality, response groups use the Workflow Process Manager business service and the RunProcess method for Siebel Email Response work items as defaults.
You begin the process of setting up a response group by creating the response group. Then, you assign input arguments that tell Communications Inbound Receiver how to monitor incoming email for all profiles in the response group. Input arguments enable you to define auto-acknowledgment messages, error messages, and business component fields. Each response group method has different input argument settings.
After making any changes to a response group or profile, you must submit the response group changes so that these changes take effect. Then you associate the response group with profiles (email addresses). The input arguments that you assign to the response group control the processing of all email that is sent to these profiles.
To set up response groups, perform the following tasks:
Creating Response Groups
First, create a response group.
This task is a step in Process of Setting Up Response Groups.
To create a response group
Navigate to the Administration - Communications screen, then the All Response Groups view.
In the Response Groups form, create a new record.
Using information you gather during the planning process, complete the necessary response group fields in the following table.
| Field | Description |
|---|---|
Name |
Type the name of the response group. |
Service Name |
Do not change the default value of Workflow Process Manager. |
Method Name |
Do not change the default value of RunProcess. |
Administrator Email Address |
Type the email address to which a notification is sent when server errors occur. |
Description |
Type notes about this response group. You can describe the behaviors that apply to all profiles in this response group. |
Adding Input Arguments to Response Groups
Next, add input arguments to the response group. To add input arguments, you use the information that you gather during the planning process. For more information, see Setup Information for Siebel Email Response.
The following table shows the input arguments for response groups.
Table Input Arguments for Response Groups
| Input Argument | Type | Description |
|---|---|---|
ProcessName |
None |
The name of the workflow process that processes Siebel Email Response inbound messages (for example, Email Response - Process Message). This input argument is required. Change the value to Email Response - Process Service Request for keyword-based response groups. |
ProcessInstanceId |
String |
The unique ID of this instance of the process. |
RowId |
String |
The unique ID of the response group in the Siebel database. |
Catalog Name |
String |
The name of a catalog to use. |
Disable Send Acknowledgement |
True or False |
A value to indicate if an acknowledgement message is sent. The default value is False. If you change this input argument to True, then no acknowledgement message is sent. |
Enable Assignment Manager |
True or False |
A value to indicate if Assignment Manager is disabled. The default value is False. |
Enable Lookup Sender By Organization |
True or False |
A value to indicate if sender lookup by organization is enabled. The default value is False. |
Enable Test Mode |
True or False |
A value to indicate of test mode is enabled. The default value is False. |
MsgDefaultLanguageCode |
None |
The assumed language for email messages sent to mailboxes that the response group monitors. |
RealTime |
True or False |
The default value is True. This value enables processing of email messages in real time. |
This task is a step in Process of Setting Up Response Groups.
To add input arguments to a response group
Navigate to the Administration - Communications screen, then the All Response Groups view.
In the Response Group list, select the response group for which you want to make changes.
Click the Input Arguments view tab.
In the Input Arguments list, click Generate Defaults.
Default input arguments appear on the Input Arguments list.
Default input arguments are based on the business service method. For information about the Siebel Email Response process properties that are used as input arguments, see About Modifying Process Properties for Siebel Email Response.
Select the eMail Response - Process Message workflow, and add the Catalog Name input argument:
In the Input Argument list, create a new record.
In the Name field, enter Catalog Name.
-
In the Value field, enter the catalog name.
For information about creating this catalog and its categories, see Setting Up a Catalog for Siebel Email Response.
Add other new input arguments:
Create a new record.
Enter the name and value of the input argument.
You must enter the exact name of the input argument. For information about the names of the input arguments, see Business Service Methods for Siebel Email Response
To delete an input argument record, click Delete.
Associating Profiles with Response Groups
Next, associate the profiles with the response group. To associate the profiles with the response group, you use the profiles that you gather during the planning process. For more information, see Setup Information for Siebel Email Response.
This task is a step in Process of Setting Up Response Groups.
To associate profiles with a response group
Navigate to the Administration - Communications screen, then the All Response Groups view.
In the Response Group list, select the response group for which you want to make changes.
Click the Profiles view tab.
In the Profiles list, create a new record.
The Add Communication Profiles dialog box appears, listing existing profiles.
In the Add Communication Profiles dialog box, select the profiles.
Only created profiles appear on the list. For information about adding more profiles, see Creating Communications Driver Profiles.
Click the drop-down arrow to view and select additional profiles.
Click OK to associate the selected profiles with the response group.
The profiles appear in the Profiles list.
Submitting Changes for Response Groups
Most of the changes that you can make to a response group do not automatically take effect. For a change to take effect, you must click Submit Response Group Changes in the Response Groups menu drop-down list. Deleting a response group automatically takes effect.
The types of changes that you can make are:
Adding or deleting a profile
Changing an input argument
Changing a workflow
If you make changes to the response group input parameters, then add a profile to the response group, or remove a profile from the response group, you must submit the response group changes for the changes to take effect.
This task is a step in Process of Setting Up Response Groups.
To submit changes for response groups
Navigate to the Administration - Communications screen, then the All Response Groups view.
In the Response Group list, select the response group for which you want to make changes.
In the Response Group form, verify that the Server field value is the Siebel Server name and the Startup field value is Active.
In the Response Groups menu drop-down list, select Submit Response Group Changes.
Starting Response Groups
You can automatically or manually start a response group. After you start a response group, the response group is in effect and its input arguments can control email processing.
When Communications Inbound Receiver starts, it looks at the Startup and Server field to determine if a response group must be started. When the Startup field for a response group changes from blank to Active, Communications Inbound Receiver picks up the change, and the response group is automatically started.
Each response group has one component task. For two or more response groups, two or more component tasks are automatically started. Communications Inbound Receiver can start multiple component tasks, one task for each response group. Each task has multiple subtasks, representing a workflow thread that can process inbound messages.
This task is a step in Process of Setting Up Response Groups.
To manually start a response group
Navigate to the Administration - Communications screen, then the All Response Groups view.
In the Response Group list, select the response group that you want to start.
In the Response Group form, verify that the Server field value is the Siebel Server name and the Startup field value is Active.
In the Response Groups menu drop-down list, select Submit Response Group Changes.
How Communications Drivers Process Email Messages
This topic contains some information about email directories and driver parameters as well as an overview of how the communications drivers process email messages.
This topic contains the following information:
Email Directories and Driver Parameters
When the Internet SMTP/POP3 Server driver or Internet SMTP/IMAP Server driver starts, it creates the following directories:
Failed
Incoming
Loopback
Processed
Sent
By default, these directories are placed in the bin subdirectory of the Siebel Server installation directory if they do not exist. If you do not want to store messages in the bin subdirectory, then you can specify a different location by changing the values for the communications driver parameters. To change the locations where messages are stored, navigate to the Administration - Communications screen, then the Communications Drivers and Profiles view. In the Driver Parameters list, choose one of the following parameters for the directory location that you want to change, and enter a directory path in the Default Value column:
Failed Email Directory
Incoming Email Directory
Loopback Email Directory
Processed Email Directory
Sent Email Directory
The following parameters control processing of incoming and outgoing messages:
Delete Processed Messages
Save Sent Messages
Return Attachments
Process If Loopback Detected
You can change processing for these email messages by changing the default value of a driver parameter. For more information about the parameters in this topic, see Parameters for Internet SMTP/IMAP Server Driver and Internet SMTP/POP3 Server Driver.
Output Parameter Values for Communications Drivers
During email processing, the Internet SMTP/POP3 Server driver or Internet SMTP/IMAP Server driver passes output parameter values to the Communications Inbound Receiver and Communications Inbound Processor server components. From these server components, these values are passed to the Siebel Email Response workflows in the form of properties for the EventFields property set. The following table provides a list of the output parameter values and a description of how you can modify email handling behavior by accessing these values in the EventFields property set.
Table Output Parameters for Communications Drivers
| Parameter Name | Description |
|---|---|
Attachments |
The number of nonsupplemental attachments that are found. The default value is 0. |
CcList |
The value of the CC: header field. This parameter must be semicolon delimited if it includes multiple recipients. |
DsnAction |
This parameter uses the RFC1894 protocol. For more information, see: http://www.faqs.org/rfcs/rfc1894.html. |
DsnContent |
This parameter uses the RFC1894 protocol. For more information, see: http://www.faqs.org/rfcs/rfc1894.html. |
DsnFinalRecipient |
This parameter uses the RFC1894 protocol. For more information, see: http://www.faqs.org/rfcs/rfc1894.html. |
DsnOriginalEnvelopeId |
This parameter uses the RFC1894 protocol. For more information, see: http://www.faqs.org/rfcs/rfc1894.html. |
DsnStatus |
This parameter uses the RFC1894 protocol. For more information, see: http://www.faqs.org/rfcs/rfc1894.html. |
FileCharset%d |
The character set of the attachment file. |
FileIsInline%d |
If an incoming attachment file does not have an associated name, then the attachment file is considered inline. The user interface displays the attachment in the rich edit control and not in the attachment pane. |
FileIsSupplemental%d |
If the incoming attachment file is a supplemental file that the driver creates, such as the original message.txt file, then this parameter is True. Otherwise this parameter is False. |
FileName%d |
The name of the attachment file. You can specify this parameter in the MIME type or as synthesized by using the type and subtype of the attachment. |
FilePath%d |
The physical location of the attachment file on the local hard disk. If the response group that loads the driver does not process email in real time, then this parameter is the location of the file on the Siebel File System. |
FileSubtype%d |
The MIME subtype of the attachment file. |
FileType%d |
The MIME type of the attachment file. |
HasAttach |
This parameter is True if the number of attachments is greater than or equal to 1. |
HTMLBody |
This parameter is set if the incoming email text is HTML only or is multipart or alternative with HTML. |
In-Reply-To |
The value of the In-Reply-To: header field. This parameter uses the RFC2822 protocol. For more information, see: http://www.faqs.org/rfcs/rfc2822.html. |
IsDeliveryStatusNotification |
If the incoming email is a delivery status notification as specified by the RFC1894 protocol, then this parameter is True. Otherwise, this parameter is False. For more information, see: http://www.faqs.org/rfcs/rfc1894.html. |
Keywords |
The value of the Keywords: header field. This parameter uses the RFC2822 protocol. For more information, see: http://www.faqs.org/rfcs/rfc2822.html. |
LocalFileToGlobal%d |
This parameter facilitates moving generated local files to the Siebel File System. For more information, see About Moving Generated Local Files to Siebel File System. |
LoopbackCandidate |
This parameter facilitates moving generated local files to the Siebel File System. For more information, see About Moving Generated Local Files to Siebel File System. |
Message-ID |
The value of the Message-ID: header field. This value is also used as the DriverTrackingID for the Siebel Communications API. For more information, see: http://www.faqs.org/rfcs/rfc2822.html. |
MsgClass |
This parameter is obsolete. |
OrigMsgFile |
If the response group that loads the driver does not process email in real time, then this parameter is the location on file on the Siebel File System. The incoming MIME type is saved in this local file. |
Prefix |
For a forwarded message, this parameter is Fwd or Fw. For a message that is in reply to another message, this parameter is Re. Otherwise, this parameter is empty. |
Priority |
This parameter is a number from 1 to 5 with 1 designating the highest priority and 5 designating the lowest priority. The default value is 3. This parameter is extracted from the X-Priority or the X-MSMail-Priority if available. |
Received |
The date that the email is retrieved from the POP3 or IMAP server. |
ReceiverAddress |
The email address that is extracted from the From Address communications profile input parameter. For example, the ReceiverAddress for Example Support <support@example.com> is support@example.com. |
ReceiverName |
The proper name that is extracted from the From Address communications profile input parameter. If there is no proper name, then this parameter is set to the ReceiverAddress parameter. For example, the ReceiverName for Example Support <support@example.com> is Example Support. |
References |
The value of the References: header field. This parameter uses the RFC2822 protocol. For more information, see: http://www.faqs.org/rfcs/rfc2822.html. |
SenderAddress |
The email address that is extracted from the From: header field. For example, the SenderAddress for John Smith <John@Smith.net> is john@smith.net. |
SenderAddrType |
This parameter is always empty. The workflows do not use this parameter. |
SenderName |
The proper name that is extracted from the From: header field. If there is no proper name, then this parameter is set to the SenderAddress parameter. For example, the SenderName for John Smith <John@Smith.net> is John Smith. |
SenderReplyNames |
If the Reply-To: header field has a value, then this parameter is that value delimited by semicolons rather than commas. If Reply-To: has no value, then this parameter is the same value as the SenderAddress parameter. |
Sent |
The date from the Date: header field. |
SiebelChannelProfile |
Media Manager generates this parameter. |
SiebelChannelType |
Media Manager generates this parameter. |
SiebelChannelTypeString |
Media Manager generates this parameter. |
SiebelDriverNotifyWhenDone |
Media Manager generates this parameter. |
SiebelWorkItemID |
Media Manager generates this parameter. |
Subject |
The value of the Subject: header field. |
Temp%d |
If this parameter is True, then the person who accesses the file must assume ownership of the disk-based file, and in most cases the workflow that processes the incoming message must delete the file after it is stored in the Siebel File System. |
text/html charset |
The IANA character set of the HTMLBody parameter. This parameter is the value of the charset parameter of the Content-Type: header field. |
text/plain charset |
The IANA character set of the TextNote parameter. This parameter is the value of the charset parameter of the Content-Type: header field. |
TextNote |
The text/plain message body text of the incoming message. |
ToList |
The value of the To: header field. This parameter must be semicolon delimited if it includes multiple recipients. |
About Moving Generated Local Files to Siebel File System
This topic describes how to direct Communications Inbound Receiver to move driver-generated local files to the Siebel File System. The processing of driver events can occur on a remote Communications Inbound Processor server only if you set the RealTime input parameter for the response group to False and nonreal-time processing applies.
To enable workflows executing on a remote Communications Inbound Processor server to access driver-generated local files, Communications Inbound Receiver monitors EventFields with the following code:
LocalFileToGlobalXXX=tag|FiletoReplace
where:
XXX must start at 0 and increase contiguously.
FiletoReplace is the file that is moved to the Siebel File System.
This code is the key to a tag-value pair with FiletoReplace replaced with the actual Siebel File System file name that is generated when the file is moved to the Siebel File System.
For example, the driver generates the following EventFields:
LocalFileToGlobal0=OriginalMsgFile|C:\OriginalMsgFile.txt
OriginalMsgFile=C:\OriginalMsgFile.txt
In this example, the local file C:\OriginalMsgFile.txt is moved to the Siebel File System. If this file receives the name ABCDEFG on the Siebel File System, then the EventFields is modified as follows before submitted to the workflow for processing:
OriginalMsgFile=ABCDEFG
Overview of the Processing Flow of Inbound Email Messages
When the Internet SMTP/POP3 Server driver or Internet SMTP/IMAP Server driver starts, it creates required directories, such as a directory for incoming email. The driver also creates a thread that polls the POP3 or IMAP server. The PollingInterval driver parameter controls the frequency with which the driver checks the POP3 or IMAP server for messages.
If messages exist for the POP3 server, then the driver retrieves and processes them one at a time, up to a maximum for each session equal to the value in the POP3 Batch Size driver parameter. If the current session with the POP3 server terminates abnormally, then all messages previously retrieved, processed, and deleted during the current session are restored, retrieved, and processed again the next time that the driver connects to the POP3 server. The smaller the value of the driver parameter, the fewer duplicate messages are created and processed if a restart occurs.
Messages in a session are processed as shown in the following steps:
A retrieve command downloads and saves a message to the directory for incoming email.
For the POP3 server, the retrieve command is POP3 RETR. The name of the temporary file for the message is POP3_A_B_C_D_E_F.tmp. For more information about the files that the processing flow creates, see Attachments Created When Inbound Email Is Received.
A delete command deletes the message from the POP3 or IMAP server.
For the POP3 server, the delete command is POP3 DELE. If the delete command fails, then the message that is stored in the directory for incoming email is erased because it is retrieved again in the next POP3 or IMAP session.
Note: Do not set up other email clients to access the mailboxes that Siebel Email Response monitors because the email driver deletes the messages from the POP3 or IMAP server when Siebel Email Response processes them. These deleted messages are not visible to another client.The disk-based message is parsed. The parsing produces the following files in the directory for incoming email:
OriginalMessageText_A_B_C_D_E_F_G.txt.
Any attachments parsed from message are given unique names as follows: ATT_A_B_C_D_E_F_G.dat.
Any remaining text or HTML fragments are converted to attachments and are given unique names as follows: ATT_A_B_C_D_E_F_G.dat.
Caution: Any errors that occur in the workflows can place the ATT_A_B_C_D_E_F_G.dat files in the directory for incoming email. If this placement occurs when the Communications Inbound Receiver is not running, then the workflow that the Communications Inbound Receiver invokes fails to process a message event.To determine if you can delete an ATT_A_B_C_D_E_F_G.dat file in the directory for incoming email, stop the Communications Inbound Receiver, and then look at the contents of all the queued Communications Inbound Receiver events in all response groups to make sure that the ATT_A_B_C_D_E_F_G.dat files are no longer referenced.
If an error occurs when the message is parsed, then the following events occur:
The temporary file is moved to the directory for failed email and any created attachments are deleted.
The POP3 or IMAP session is immediately terminated with a quit command so that the error message is permanently deleted from the server.
If the Loopback Detection Interval parameter value is greater than zero, and the message sender is currently blocked, then the following events occur:
If the Process If Loopback Detected parameter value is False, then the message is moved to the directory for loopback email.
If the Process If Loopback Detected parameter value is True, then the driver’s Loopback Candidate flag is set to True, and the message continues processing.
If the message is not moved to the directory for loopback email or flagged as a loopback candidate, then the temporary file is processed as follows:
If the Delete Processed Messages parameter value is True, then the temporary file is deleted.
If the Delete Processed Messages parameter value is False, then the temporary file is moved to the directory for processed email.
The primary message text, header information (subject, to, cc, date, and so on), Loopback Candidate flag, and references to the attachments are passed to the driver's creator (usually Communications Inbound Receiver).
The Internet SMTP/POP3 Server driver or Internet SMTP/IMAP Server driver does not delete the OriginalMessageText file and all the attachments. The workflow that the Communications Inbound Receiver invokes deletes all the attachments.
Attachments Created When Inbound Email Is Received
The Internet SMTP/POP3 Server driver or Internet SMTP/IMAP Server driver creates several different files as a result of processing inbound and outbound email messages. Some of these files are temporary, and some can be permanent depending on the profile parameters. All numbers in the file names are in Hexadecimal format.
Siebel Email Response generates internal attachments when it receives plain text or HTML email. These internally generated attachments appear in addition to any external attachments that the email sender associates with the email. No internally generated attachment is sent with a Reply, Reply to All, or Forward message.
SMTP_A_B_C_D_E_F.tmp
When the driver is used to send a message, it creates one file with the naming convention SMTP_A_B_C_D_E_F.tmp where:
A is the process ID of the application that loads the driver.
B is the Siebel Communications API handle of the driver.
C is the Siebel Communications API handle of the service.
D is the time when the service is created.
E is the number of messages that this service sends.
F is the number of milliseconds that elapsed since the application was started.
This file is the encoded MIME message that is sent to the SMTP server for delivery. This file is created under the bin/sent directory unless you specify the Sent Email Directory profile parameter. This file is deleted after the message is sent from the disk to the SMTP server unless the Save Sent Msg profile parameter is set to True.
POP3_A_B_C_D_E_F.tmp
When the driver is used to retrieve a message from a POP3 server, it creates a file to store the incoming message with the naming convention POP3_A_B_C_D_E_F.tmp where:
A is the process ID of the application that loads the driver.
B is the Siebel Communications API handle of the driver.
C is the Siebel Communications API handle of the service.
D is the time when the service that received the message is created.
E is the number of messages that are received during the current POP3 session.
F is the number of milliseconds that elapsed since the application was started.
This file is the MIME message that is retrieved from the POP3 server. This file stores the incoming message and is always created in the bin/incoming directory unless you specify the Incoming Email Directory profile parameter. If the Delete Processed Messages profile parameter is False, then these messages are moved to the bin/processed directory after they are processed, otherwise they are deleted.
After a MIME message is downloaded to the bin/incoming directory, it is parsed and the results are usually passed to the Communications Inbound Receiver. This file is not reprocessed when the Communications Inbound Receiver is restarted. Therefore, if an application failure occurs, then one or more of these files might be placed in the bin/incoming directory. You can delete these files without consequence. The messages that the POP3_A_B_C_D_E_F.tmp files represent are re-retrieved and not lost.
ATT_A_B_C_D_E_F_G.dat
When the driver is used to retrieve a message, it creates a file to store attachments that are parsed from the incoming message with the naming convention ATT_A_B_C_D_E_F_G.dat where:
A is the process ID of the application that loads the driver.
B is the Siebel Communications API handle of the driver.
C is the Siebel Communications API handle of the service.
D is the time when the service that received the message is created.
E is the number of messages that are received during the current POP3 or IMAP session.
F is the number of attachments that are found so far in the message.
G is the number of milliseconds that elapsed since the application was started.
When the message is parsed, all non-inline message parts and textual parts of the message are used to create the attachment files in the bin/incoming directory.
Another special instance of this type of file is created when an embedded message is found in the message that is parsed. Embedded messages cause the creation of one of the following two types of files:
A file with the internal name of EmbeddedMsgX.xml that contains the embedded message header and all plain text parts of the mail. The purpose of this file is the same as the purpose of the OriginalMessageText_A_B_C_D_E_F.txt file.
A file with the internal name EmbeddedMsgX.eml that contains the MIME message of the embedded message. You can open this file with Microsoft Outlook Express. This file is created only if the Parse Embedded Messages profile parameter is explicitly set to False, and the EmbeddedMsgX.xml file is not created.
OriginalMessageText_A_B_C_D_E_F_G.txt
When the driver is used to retrieve a message, it creates a file to store the header and textual data from the incoming message with the naming convention OriginalMessageText_A_B_C_D_E_F.txt where:
A is the process ID of the application that loads the driver.
B is the Siebel Communications API handle of the driver.
C is the Siebel Communications API handle of the service.
D is the time when the service that received the message is created.
E is the number of messages that are received during the current POP3 or IMAP session.
F is the number of attachments that are found so far in the message.
G is the number of milliseconds that elapsed since the application was started.
The OriginalMessageText file contains the MIME format of the message that the Internet SMTP/POP3 Server driver or Internet SMTP/IMAP Server driver receives. The original message header and all text/plain message parts that are not inside an embedded message part and not marked as inline are written to a file in the UTF-8 character set.
The Siebel Email Response workflows delete the ATT and OriginalMessageText files. If ATT or OriginalMessageText files exist in the bin/incoming directory, then the Communications Inbound Receiver process terminated abnormally or the email events that created these files are not yet processed. Do not manually delete these temporary files until you verify that none of the email events under the bin/queued directory reference the temporary files.
Current_A_B.ids and Previous_A_B.ids
To avoid retrieving duplicate messages when a POP3 or IMAP session is abnormally terminated, the unique message-ids associated with each processed message are stored (to keep track of previously retrieved messages) in two files with the naming conventions Current_A_B.ids and Previous_A_B.ids where:
A is the POP3 or IMAP server name.
B is the POP3 or IMAP account name.
The Current index file stores all the message IDs that are passed to the Communications Inbound Receiver for workflow processing in the current POP3 or IMAP session. If the session terminates abnormally, then the quit command is not executed and the delete commands for the current session are not executed. To avoid re-retrieving the messages from the previous session, the driver checks for a Current index file on startup, and if this file exists, then it is appended to the Previous index file. Before a message is retrieved from the POP3 or IMAP server, the Previous index file is checked to see whether that message is already processed.
You can delete these files, but if a POP3 or IMAP session terminates abnormally and you delete these files, then messages with a POP3 Batch Size less 1 might be duplicated. These files never are large because they are erased each time a POP3 or IMAP session terminates normally. In addition, they are never larger than a certain number of bytes (POP3 Batch Size multiplied by 128).
POP3SMTP_A_B_C_D_E.log or IMAPSMTP_A_B_C_D_E.log
Each service instance can also create a log file if you set the LogDebug profile parameter to True. The error logging level determines the amount of tracing data in this log file. This log file is always created in the same directory as all the other Siebel log files. The naming convention of this file is POP3SMTP_A_B_C_D_E.log or IMAPSMTP_A_B_C_D_E.log where:
A is the process ID of the application that loads the driver.
B is the Siebel Communications API handle of the driver.
C is the Siebel Communications API handle of the service.
D is the time when the service that received the message is created.
E is the number of milliseconds that elapsed since the application was started.
Attachments Created When Outbound Email Is Sent
When sending an outbound email message, an internally generated attachment is created for an outbound email message with a size greater than 16 KB (about 15,000 characters). This internally generated attachment is named SiebelLongEmailBody and is stored with the email activity record in the Siebel application but is not sent with the outbound message.
The following table describes the formats for this attachment. Regardless of its size, the attachment contains the entire email in the body of the message without any internally generated attachments. This attachment is created so that any message greater than 16 KB can be stored in the Siebel File System. A Siebel database maximum of 15,000 characters exists for any email. Additionally, this attachment is sent to the email recipient in the body of a single email message. Users can see the entire text of the email in the Outgoing Message form.
You can generate a SiebelLongEmailBody attachment file for an outbound email message with a size less than 16 KB by setting the Save Email Body as Attachment user property for the Comm Outbound Email business component to True.
Table Formats of Outgoing Email Attachments
| Default Message Format | Attachment Created for Email Greater than 16 KB |
|---|---|
HTML |
SiebelLongEmailBody.htm |
Plain Text |
SiebelLongEmailBody.txt |