Return to Navigation

Script Reference

The following section provides a reference to the scripting language used in the Email Response Processor configuration file.

Note: The complete sample ReplyProcess.script and BounceProcess.script scripts, which you can modify to suit your needs, are located in <PeopleTools_install_dir>/JavaApps/CRM/OMK/ERPx, where x is the identifier of each Email Response Processor instance created.

This section describes the conditions you can specify in the ReplyProcess.script configuration file. In each case, the proper syntax for the condition is included, along with an example of its use.

Note: Only the Reply Process checks conditions on received emails. The Bounce Process assumes that the popUsers parameter contains only mailboxes designated as bounce mailboxes and that these mailboxes contain only bounced email messages.

inSender

The inSender condition looks for the specified string within the From field of the email.

The inSender syntax is as follows:

inSender ([boolean ignoreCase] "String")

For example:

inSender ("jsmith@demo.com")

inRecipient

The inRecipient condition looks for the specified string within the To field of the email.

The inRecipient syntax is as follows:

inRecipient ([boolean ignoreCase] "String")

For example:

inRecipient ("jdoe@peoplesoft.com")

inSubject

The inSubject condition looks for the specified string within the Subject field of the email.

The inSubject syntax is as follows:

inSubject ([boolean ignoreCase] "String")

For example:

inSubject ("Returned Mail")

inBody

The inBody condition looks for the specified string within the body of the email.

The inBody syntax is as follows:

inBody ([boolean ignoreCase] "String")

For example:

inBody ("unsubscribe")

inHeader

The inHeader condition looks for the specified string within the header of the email.

The inHeader syntax is as follows:

inHeader ([boolean ignoreCase] "String")

For example:

inHeader ("Reply-Processor")

inAll

The inAll condition looks for the specified string within the body or the header of the email.

The inAll syntax is as follows:

inAll ([boolean ignoreCase] "String")

For example:

inAll ("unsubscribe")

contactNotFound

The contactNotFound condition is true if the sender of the message cannot be identified.

The Email Response Processor tries to determine contact information from the magic number if it is present. If no magic number is found and the parameter getContactFromSender is set to on, the email address is used instead. If both methods fail, the contact is considered to be unidentified.

Note: The Email Response Processor uses only the main addresses, not the alternative email address, to determine contact information.

The contactNotFound syntax is as follows:

if
	contactNotFound
		then 
			{
			<action>;
			}

For example:

if 
	inRecipient("abuse")
then 
		if
			contactNotFound
		then	
			{
			forward("hosting_rp_error@demo.com");
			delete;
			}

boolean IgnoreCase

In each condition described previously, the boolean IgnoreCase element is optional. If set to false, the matching is case-sensitive; otherwise, case is ignored. The default value is true.

For example:

inSender (false, "mjones@demo.com")

would find “mjones@demo.com” but not “MJones@Demo.com”.

Checking for Multiple Conditions

You can use all of the string checking conditions to check for the occurrence of any or all of several strings in the same command. To do this, insert all or any before the condition and provide a comma-separated list of strings for which to search. For example:

all inBody (true, "String 1", "String 2")

checks if “String1” and “String2” are in the body of the message, using a case-insensitive match. Substituting any results in a check for either of the two conditions.

Note: This type of checking is more efficient in both speed and memory usage than combining multiple individual conditions with the AND or OR keywords.

This section describes the syntax for actions performed upon the email message if the specified conditions are met.

delete

Deletes the message from the mailbox. Note that although the message is removed from the POP server, the remainder of the script is still executed for the message.

If the message is not deleted, it will remain on the server. This means that the next time the Email Response Processor is run, it will perform the specified actions on the message again.

Note: Be sure to test your Email Response Processor configuration carefully to ensure that only those messages you intend to delete are removed.

forward (address)

Forwards the message to the address specified.

To enable the Email Response Processor to forward mail to another domain, you might have to include that domain in the relay control of the SMTP mail server. (For example, if your domain is xyz.com and you are forwarding mail to forward@demo.com, you must add demo.com to the relay control of your SMTP mail server(s).)

Note: If the Email Response Processor is forwarding email to a mailbox with business rules associated with it (for example, Kana), be sure to test thoroughly to ensure that mail is properly processed.

reply (string file)

Replies with the contents of the specified file. The original message is quoted after the included text.

ignore

Ignores the message. The action is still logged, unlike those messages that do not fit any of the rules.

Note: All preceding actions in the script are executed, but all following actions are ignored.

This section describes the syntax for actions performed upon the database if the specified conditions are met.

update (field, value)

Updates the specified profile field with the specified value. The fieldname must be in table.column format, and the value is the proper value for the field. The syntax differs depending on whether a basic profile field or a custom profile field is updated.

Basic Profile Field Update:

The format for field is BASIC.XXXX, where XXXX is a valid basic profile field name (exactly as it appears in the PeopleSoft Online Marketing Client, including spacing and case). The value should be a valid value for the field type. No SQL format is allowed.

Example:

update ("BASIC.Do Not Email", "Y");

If the Basic profile field type is Multiple Choice, the format is:

update("fieldname", "<semicolon separated code list>");

For example, 

update("BASIC.MultiChoice1", "code1;code3;code6");

If the field type is Date, the date format is 'YYYY-MM-DD'; for example: 

update("BASIC.Birth Date", "1968-02-03" );

If the field type is Time, the format is "HH:mm" in 24 hour format. For example: 

update("BASIC.Time 1", "14:25" );

The system checks to see if the basic profile field name is supported. If it is not supported, the systems reports an error at initialization.

Custom Profile Field Update:

For a custom profile field, the following format is used:

update (field, value)

The field name must be in table.column format, where table is a valid custom profile table. The value must be in proper SQL format.

For example:

SQL Server:

update (APP_YOUR_CUSTOM_TABLE.YOUR_COLUMN, "value")
update (APP_YOUR_CUSTOM_TABLE.ROW_LASTMANT_DTTM, "getdate()" );

Oracle:

update (APP_YOUR_CUSTOM_TABLE.YOUR_COLUMN, "value")
update (APP_YOUR_CUSTOM_TABLE.ROW_LASTMANT_DTTM, "sysdate" );

DB2:

update (APP_YOUR_CUSTOM_TABLE.YOUR_COLUMN, "value");
update (APP_YOUR_CUSTOM_TABLE.ROW_LASTMANT_DTTM, "current_timestamp");

It is recommended that you also update the ROW_LASTMANT_DTTM column along with the column and value you wish to change, as this will enable other applications or database extracts to capture changes made by the Email Response Processor.

logSoftBounce

Logs in the database that the current email bounce is a soft bounce.

logHardBounce

Logs in the database that the current email bounce is a hard bounce.

You can configure the system to set the DO_NOT_EMAIL flag for recipients of hard bounces. This configuration parameter is set on the Global Options page.

See Setting Global Options.

logUnknownBounce

Logs in the database that the current email bounce is an unknown bounce (that is, the system cannot determine if the bounce is hard or soft).

logBounce

Logs in the database that an email message has been bounced against a specified contact. The contact is identified from the magic number (or from the Sender field if the magic number is not present and the getContactFromSender parameter is set to true). If the contact cannot be obtained, the corresponding information is logged in the logfile.

Note: This is a legacy action from pre-8.95 versions of Online Marketing. It will log the bounce as an unknown bounce type.

You can define an error-handling block for an operation or group of operations by enclosing the operation between the keywords try and onError. For several operations, enclose the operations between curly braces.

For example, the following statement attempts to update the Do Not Email field of the BASIC profile. If the operation fails, the message is forwarded to another email address.

try
	update ("BASIC.Do Not Email", "‘Y’");
onError
	forward (error@demo.com);