Email Repository Overview

Purpose: You can use the Correspondence History table in Order Management System to store and review emails that you have received from or sent to your customers.

Outbound emails: You can also use the Correspondence History table to store outbound emails that you send to customers, such as backorder and soldout notices and shipment confirmations. However, because the text of each type of outbound email does not vary from customer to customer, the system does not save the text in the Correspondence History Detail table; no text is available for review at the screens where you can work with correspondence history, such as the Work with Email by Order Number Screen. The Write Outbound Email to Email Repository (H99) system control value specifies whether to save information on outbound emails.

If you use the Outbound Email API, the same type of information is also stored for the Outbound Email XML Message (CWEmailOut), based on the setting of the Write Outbound Email to Email Repository (H99) system control value. See the discussion of the Outbound Email API for more information.

In this chapter:

• Reviewing and Working with Emails

• Summary of Emails Repository Setup

• Email XML Message (CWEmail)

- Email Message: Sample XML

Reviewing and Working with Emails

Emails are stored in the Correspondence History table. You can review correspondence history related to a particular:

• order: Work with Email by Order Number Screen

• sold-to customer: Work with Email by Customer Sold To Number Screen

• ship-to customer: Work with Email by Customer Ship To Number Screen

• bill-to customer: Work with Email by Customer Bill To Number Screen

You can scan for and review emails related to a particular:

• order in order maintenance and standard order inquiry

• sold-to, ship-to, bill-to customer: in order maintenance, standard order inquiry, or the appropriate customer maintenance screens

The Email Presentation (I01) system control value indicates whether to condense email messages in correspondence history by deleting blank lines or line breaks between paragraphs.

Purging emails: You can use Purging Email History (MPCH) to purge Correspondence History records older than a specified date.

Summary of Emails Repository Setup

Purpose: The setup required within Order Management System for the email repository consists of:

System control values:

• Assign Unreferenced Email (H93): Specifies whether the system should attempt to assign an unreferenced email to a customer based on matching email address, and whether to leave an email unassigned if more than one customer has the matching address.

• Email Presentation (I01): Specifies whether to include all blank lines, include one line space between paragraphs, or wrap all text in emails coming into Order Management System.

• Write Outbound Email to Email Repository (H99): Specifies whether outbound emails such as soldout notices, backorder notices, and shipment notifications, or the Outbound Email XML Message (CWEmailOut), are saved in the email repository.

Secured feature: The Changed Routed Email (B08) secured feature controls the ability to change or delete previously routed emails through the Work with Routed Emails screens.

Working with Integration Layer Processes (IJCT): Set the EMAIL process to the queue manager and queues you have set up on the external email server.

This process has an inbound program only. The EMAIL_OUT process generates the Outbound Email XML Message (CWEmailOut), and other outbound email notifications are generated by different processes. See Working with E-Mail Notification Templates (WEMT) for an overview.

Working with Email Category (WEMC): Optionally, set up one or more email categories. If the Write Outbound Email to Email Repository (H99) system control value is selected, you will need an email category of NTF (notification); however, the system creates this category automatically the first time you use the Working with Email Category menu option.

Communication settings: You need to perform advanced queue setup for communication with the external email system.

CWMessageIn Web Service

You can use the CWMessageIn Web Service to route CWEmail messages. In this situation, the target for each inbound message must match the Inbound program name for the integration layer process queue, as specified at the Integration Layer Process Queue Screen.

Web service authentication? Use the Working with Web Service Authentication (WWSA) menu option to define a valid user for basic web service authentication.

If you are using the CWMessageIn RESTful web service: You POST inbound CWMessageIn messages to the web service’s URI, or endpoint, of the RESTful service. The individual URL for the CWMessageIn RESTful service uses the following format: http://server:port/SerenadeSeam/sxrs/application/CWMessageIn, where server:port identifies the application server where the RESTful service is located and CWMessageIn is the name of the web service to call.

If you are using the CWMessageIn SOAP-based web service: The endpoint specified in the CWMessageIn.wsdl file is where you need to post messages in order for the CWMessageIn web service to process them. The endpoint is typically set to http://server:port/CWDirectCPService/services/CWMessageIn, where server:port identifies the application server where the wsdl is located and CWMessageIn is the name of the web service to call. The CWMessageIn SOAP-based web service requires that inbound messages be embedded in SOAP envelope tags.

Email XML Message (CWEmail)

 

The CWEmail message is used to send emails to Order Management System from an external email system, such as Microsoft Outlook. When the system receives a CWEmail message from an external source, the system creates a Correspondence History record, matching the email to the related customer, order, or vendor based on the information provided in the message. If insufficient information is included in the email message, then the system attempts to match the email with a sold-to customer based on the email address in the message.

See Email Message: Sample XML for a sample message and see Email Repository Overview for an overview.

Attribute Name	Type	Length	Comments
Message
source	alpha	25	Identifies the source of the XML message.
target	alpha	25	Identifies the target of the XML message. RDC indicates the XML message is sent to Order Management System.
type	alpha	25	Identifies the type of information in the XML message. CWEmail indicates the message contains an inbound email.
Email
company	numeric	3	The company where the Correspondence History record will be created.
order	numeric	9	The order number related to the email. If the order number passed is valid, the Correspondence History record is assigned to the order, and each of the types of customers associated with the order. The sold-to customer is always associated, and the bill-to and ship-to customers are also associated with the email if they are on the order.
order_ship_to	numeric	3	The number representing the order ship-to address; requires that the order number be identified.
vendor	numeric	7	The number representing the vendor associated with the email. If order number and purchase order number are also passed, the vendor, order, and purchase order must represent a valid combination.
customer_sold_to	numeric	9	A number to identify the sold-to customer associated with the email. If the message does not include a sold-to customer number, the Assign Unreferenced Email (H93) controls whether the system can attempt to match the email with an existing sold-to customer based on the order number specified, or the email address included in the email. If the email has been forwarded, the system checks the body of the message for an originating email address. Not all emails are related to sold-to customers. For example, an email from a vendor might not be related to a sold-to, ship-to, or bill-to customer, or to an order. If an order number is also specified, requires that the order number and customer number represent a valid combination.
customer_ship_to	numeric	3	A number to identify the ship-to customer associated with the email. Requires that the sold-to customer be identified, and that the sold-to number and order number represent a valid combination.
customer_bill_to	numeric	7	A number to identify the bill-to customer associated with the email. If an order number is also specified, requires that they represent a valid combination.
po	numeric	7	A number to identify the purchase order number related to the email. If the message includes both the order number and the purchase order number, or a vendor and a purchase order number, they must represent a valid combination. If the message includes just the purchase order number, but the purchase order references an order number, the Correspondence History record will be assigned to that order number and related sold-to customer.
email_category	alpha	3	A code used to group emails for reporting and analysis. Must be a valid email category.
invoice	numeric	7	A number to identify the Invoice Header related to the email. If an order number or customer sold-to number is also specified, they must represent a valid combination.
user_code_1	alpha	1	A user-defined field, available to pass a flag or status code for storage in the Correspondence History record.
user_code_2	alpha	10	A user-defined field, available to pass a code for storage in the Correspondence History record.
user_code_3	alpha	20	A user-defined field, available to pass a long code or other information for storage in the Correspondence History record.
user_number	numeric	13	A user-defined field, available to pass a long number for storage in the Correspondence History record.
user_date	numeric	7	A user-defined field, available to pass a date for storage in the Correspondence History record.
order_cross_reference	alpha	30	An alternate code to identify an order. If this cross reference matches the Alt ord for an order, the email is assigned to the order, and each of the types of customers associated with the order. If an order number or customer sold to is also specified, they must represent a valid combination.
customer_cross_reference	alpha	15	An alternate code to identify a sold-to customer. If this cross reference matches the Alternate customer number for a sold-to customer, the email is assigned to the customer. If an order number or customer sold to is also specified, they must represent a valid combination.
from	alpha	50	The originating email address. The system can use this email address to search for a matching sold-to or ship-to customer, based on the setting of the Assign Unreferenced Email (H93) system control value.
to	alpha	50	The destination email address.
cc	alpha	50	The email address to receive a copy of the email.
subject	alpha	78	The contents of the Subject line for the email. Any email identifiers included in the subject line are deleted.
attachment	alpha	1	Indicates whether the email included an attachment. Valid values are: • Y = there was an attachment • N = there was no attachment The attachment is not included in the Correspondence History record.
display_name	alpha	50	The customer’s email alias, that is, the name that appears in place of the actual email address in some email applications.
email_date	numeric	7	The date the email was originally generated.
email_time	numeric	6	The time the email was originally generated.
body	alpha		The actual text of the email. Codes, images and formatting are deleted or replaced with plain text equivalents; see Symbol and Special Character Conversion in Emails for more information.

Email Message: Sample XML

A sample of the Email XML Message (CWEmail) is presented below.

<Message source="email" target="rdc" type="CWEMail">

<EMail company="555" customer_sold_to="6" from="kbottger@example.com" to="rdc@example.com" attachment="Y" display_name="Karen Bottger " email_date="10082006" email_time="093153" body="Hi Mary, Attached is the user reference you requested. I hope you find this documentation useful. If you have any questions, please let me know.~~ ~~Regards,~~Karen Bottger~~Technical Writer~~CommercialWare Inc.~~ ~~" />

</Message>