Previous	Next		Contents	Index	Glossary

1. Oracle Workflow provides an example configuration file, called wfmail.cfg. If you are using the standalone version of Oracle Workflow, the file resides in your Oracle Workflow server directory structure, under the subdirectory res. For the version of Oracle Workflow embedded in Oracle Applications, the file resides in the resource subdirectory under $FND_TOP on your server. The file also resides on your PC in the <drive>:\<ORACLE_HOME>\wf\data subdirectory.

2. The content of the configuration file is formatted as follows:

#Description

PARAMETER1=<value1>

#Description

PARAMETER2=<value2>

...

Any text preceded by # is not interpreted and can be used for including comments. List each parameter name on the left side of the equal sign (=) and specify a value for each parameter on the right.

3. The parameters are as follows:

• CONNECT--(Required) The information to connect to the database account where the Oracle Workflow server is installed, using the format, username/password@connect_string (or alias).

• ACCOUNT--(Required) The information to connect to the mail account that the program uses to send notification messages. For MAPI-compliant mail programs, the account information is the mail account profile name and mail account password. For Sendmail, the account information would be the full file path of the mail spool file where incoming messages are stored, such as /var/mail/applmgr3. Note that this should correspond to the account from which you start the Notification Mailer, in this example, applmgr3.

Attention: If you want to start the Sendmail version of the Notification Mailer, you must also specify the full path of the Sendmail executable directory in your PATH environment variable.

Attention: If you are using the version of Oracle Workflow embedded in Oracle Applications, and want to start the Sendmail version of the Notification Mailer concurrent program, then the Account parameter must be set to the account from which you start the Concurrent Manager.

• NODE--(Required) The node identifier name. You can have multiple workflow databases route messages through the same mail account. By defining a unique node name for each Notification Mailer configuration file running against each database, responses can be routed back to the correct database without requiring database connection information to be included in the message. The node name is included with the outgoing notification ID. The default name is wf.

• FROM--The value that appears in the From: field of the message header when a notification message is delivered to a user. The default is Oracle Workflow.

• SUMMARY_ONLY--(Required) Indicate whether this Notification Mailer processes only notifications assigned to users/roles with a notification preference of 'SUMMARY' or whether it only processes notifications for users/roles with a notification preference of 'MAILTEXT', 'MAILATTH', or 'MAILHTML'. Valid values are Y or N. The default is N. You should set up at least two Notification Mailers, one where SUMMARYONLY=Y and one where SUMMARYONLY=N if any of your workflow users or roles have a notification preference of 'MAILTEXT', 'MAILATTH', 'MAILHTML', or 'SUMMARY'. See: Setting Up Users and Roles from a Directory Repository: .

If you set SUMMARYONLY=Y, then the Notification Mailer will shut itself down after it polls the database and delivers any appropriate notification summaries. You must therefore schedule the Notification Mailer to run at the frequency you want notification summaries to be delivered. We recommend you run the summary Notification Mailer once a day, since the summary includes all open notifications. For Oracle Workflow running in the standalone environment, this would involve creating an operating system script, such as a cron job in UNIX, to schedule the Notification Mailer. For the version of Oracle Workflow embedded in Oracle Applications, this simply involves scheduling the Notification Mailer concurrent program in the Submit Request form.

• DIRECT_RESPONSE--Specify N or n to send plain text notifications requiring a templated response to users with a notification preference of 'MAILTEXT' or 'MAILATTH'. Specify Y or y to send plain text notifications requiring a direct response to users with these preferences. The default is N.

For the templated response method, users must reply using a template of response prompts and enter their response values between the quotes following each prompt. For the direct response method, users must enter their response values directly as the first lines of a reply. See: Reviewing Notifications via Electronic Mail.

• AUTOCLOSE_FYI--Indicate whether this Notification Mailer automatically closes notifications that do not require a response, such as FYI (For Your Information) notifications, after sending the notifications by electronic mail. Valid values include Y or N. The default is Y.

If the value is N, all FYI notifications will remain open in the Notifications Worklist until users manually close these notifications.

• ALLOW_FORWARDED_RESPONSE--Indicate whether to allow a user to respond to an e-mail notification that has been forwarded from another role. Valid values include Y or N. The default is Y.

If the value is N, the Notification Mailer will check if the "From:" e-mail address of the notification response exactly matches the e-mail address of the recorded recipient role (or the e-mail address of a user in that role). If the two e-mail addresses match exactly, meaning the notification was not forwarded or was forwarded according to a valid routing rule, the Notification Mailer treats the response as a valid response. If the two e-mail addresses do not match exactly, meaning the notification was simply forwarded using the e-mail Forward command, the Notification Mailer does not process the response and treats it as unsolicited mail.

If the value is Y, the Notification Mailer never checks the "From:" e-mail address of the notification response and always allows the response to be processed.

Warning: Note that there are limitations when you set ALLOW_FORWARDED_RESPONSE to N. For example, suppose a notification is sent to a distribution list mail alias that does not have a USER/ROLE relationship in the Oracle Workflow directory service. If any user from the distribution list responds to the notification, the Notification Mailer will always treat their notification response as unsolicited mail, because the "From:" e-mail address, which is an individual user's e-mail address, will never match the distribution list mail alias.

• IDLE--The number of seconds to wait before checking for messages to send. The value must be an integer greater than or equal to zero. The default is 30.

• LOG--The name of a log file to record activity. A valid value would be a filename. This parameter is valid only for the standalone version of the Notification Mailer. For the concurrent program version of the Notification Mailer, the activity output goes to the concurrent manager log file.

• SHUTDOWN--The name of a file that cues the Notification Mailer to shut down. This lets you safely shut down the Notification Mailer without killing the process. The Notification Mailer always looks for the shutdown file in its current working directory before looking for notifications to process. If the file exists, then the Notification Mailer shuts down. You must remove the shutdown file to restart the Notification Mailer again. The default filename is shutdown.

For the standalone version of Oracle Workflow, the Notification Mailer's current working directory is the directory from which you start the Notification Mailer. For the version of Oracle Workflow embedded in Oracle Applications, the current working directory is the $APPLCSF/$APPLLOG directory. If you have not set the $APPLCSF environment variable, then place the shutdown file in the $FND_TOP/$APPLLOG directory.

• FAILCOMMAND--The command to run if the Notification Mailer encounters a fatal error.

• DEBUG--Indicate whether to print debugging information in the log. Valid values include Y or N. The default is N.

• TEST_ADDRESS--Indicate a test e-mail address to direct all outgoing e-mail notifications. The test address overrides each recipient's e-mail address so that you can test a workflow process without having to change each recipient's e-mail address to access the test notifications.

• REPLYTO--(Required) A default e-mail address to reply to, if the e-mail account that processes responses is different from the e-mail account that sends outgoing notifications.

• HTMLAGENT--The base URL that identifies the HTML Web Agent that handles HTML notification responses. This URL is required to support e-mail notifications with HTML attachments. The default URL is derived from the Workflow Web Agent specified in the Global Preferences web page, but you can override this default by entering a different value for this parameter. See: Setting Global User Preferences.

• DISCARD--The name of the mail folder or full path name of the mail file to put discarded messages. A '-' preceding the name causes the Notification Mailer to truncate the folder or file on startup. The default is -discard.

• PROCESS--The name of the mail folder or full path name of the mail file to put processed notification messages. A '-' preceding the name causes the Notification Mailer to truncate the folder or file on startup. The default is processed.

• UNPROCESS--The name of the mail folder or the full path name of the mail file to put unprocessed notification messages. A '-' preceding the name causes the Notification Mailer to truncate the folder or file on startup. The default is unprocessed.

• TAGFILE--The full path and name of a tag file. The tag file lists strings of text found in unusual messages and the status you want to assign to a message response if it contains any of those strings. Unusual messages include bounced or returned messages, auto-reply messages such as those sent by vacation daemons, mass mailing lists, and so on. Since different mail systems vary in how they identify bounced, undeliverable, or otherwise invalid messages, you can use a tag file to specify how your mail system identifies those stray messages and how you want the Notification Mailer to handle those messages should it come across them.

Attention: Only a message response that contains a notification ID is checked by the tag file. If the Notification Mailer receives a message response that does not contain a notification ID, it moves the message response to the discard folder and sends a 'Warning' message to the sender that it received unsolicited mail. See: Workflow Warning Mail Message.

The format used in the tag file is

		Status "Matching string"

where Status can be the value: ERROR, IGNORE, or UNAVAIL and "Matching string" is the text to look for in the From: line, Subject: line, or body of the message. The Notification Mailer handles a message assigned one of these status values as follows:

• IGNORE--moves the message to the discard folder and continues waiting for a valid reply to the open notification. The notification's status is still OPEN and its mail status is still SENT.

• ERROR--moves the message to the discard folder and initiates an error process, if one is defined. The notification's status is still OPEN, but its mail status and activity status are updated to ERROR. Ideally, the workflow administrator corrects the problem and resends the notification by updating its mail status to MAIL.

• UNAVAIL (or any other user defined tag)--moves the message to the discard folder and continues waiting for a reply to the notification since the notification's status is still OPEN, but its mail status is updated to UNAVAIL. This status is purely informative, as no further processing occurs with this notification.

The Notification Mailer can also assign an INVALID status to a message response, if the returned response value is not a valid value in the assigned lookup (result) type. In this case, it moves the message to the discard folder, and sends an 'Invalid' message but does not alter the notification's status or mail status, so that it continues to wait for a valid reply. See: Workflow Invalid Mail Message.

Attention: It is important that you uniquely identify bounced messages and auto-replies from normal responses in the tag file. If you do not identify bounced and auto-reply messages, the Notification Mailer can mistake these as invalid responses, send an 'Invalid' message and continue to wait for a reply. In both cases a perpetual loop would occur where the Notification Mailer keeps sending out an 'Invalid' message and the 'Invalid' message bounces back or is auto-replied.

As an example, if you want to mark all message responses that contain the string "-- Unsent message follows --" in the subject or body of the message as an error, you can include the following line in your tag file:

		ERROR "-- Unsent message follows --"

Attention: If a message response matches more than one string in the tag file, it gets tagged with the status of the first string it matches in the file. That is, the Notification Mailer performs a top to bottom comparison against the tag file. Due to this behavior, you should prioritize your strings listing the ERROR tags first, followed by the UNAVAIL and then IGNORE tags.

Oracle Workflow provides an example tag file called wfmail.tag. For the standalone version of Oracle Workflow, the file resides in your Oracle Workflow server directory structure in the subdirectory res. For the version of Oracle Workflow embedded in Oracle Applications, the file resides on your server in the resource subdirectory under $FND_TOP.

• RESET_FAILED--Indicate whether this Notification Mailer should reset all notifications with a mail status of FAILED to a mail status of MAIL when the Notification Mailer is started. Valid values include Y or N. The default is N.

If the value is Y, the Notification Mailer will reset all FAILED notifications to a mail status of MAIL on startup and then attempt to process these notifications as usual.

See: Response Processing

See: Modifying Your Message Templates

See: Defining Rules for Automatic Notification Processing