Oracle Alert leverages the Workflow Notification Mailer to send alert e-mail messages and process responses.
The Workflow Notification Mailer is a Java program provided by Oracle Workflow that performs e-mail send and response processing using the JavaMail API. Oracle Alert leverages the Workflow Notification Mailer to send alert e-mail messages and process responses.
Before implementing Oracle Alert response processing, check that the Workflow Notification Mailer is set up and that its configuration meets your alert requirements. In particular, ensure that the Workflow Notification Mailer has inbound processing enabled and has an e-mail account for receiving messages on an IMAP4 compliant mail server. You may also want to check that the From and Reply-to Address mailer configuration parameters are set to appropriate values for alert messages. See: Setting Up a Notification Mailer.
The Workflow Notification Mailer uses three folders in its e-mail account for response processing: one to receive incoming messages, one to store processed messages, and one to store discarded messages. When the Workflow Notification Mailer logs into its IMAP e-mail account, it checks the inbox folder for messages. If a message exists, the notification mailer reads the message, checking for an identifying string called the notification ID (NID) line. If the NID line contains an Oracle Alert message handle, the Workflow Notification Mailer identifies the e-mail as an alert response message. See: Message Handles.
Attention: An alert recipient must use Reply-with-Original or Forward to include the original message with her or his response so that Oracle Workflow and Oracle Alert can locate the message handle and interpret the response.
The Workflow Notification Mailer also verifies that From address of the response message matches the e-mail address for the recipient of the original alert. Otherwise, the notification mailer moves the message to the discard folder and treats it as an unsolicited message. In some cases the notification mailer sends a warning back to the sender of the response message. For more information about how the notification mailer handles unsolicited messages, see: Inbound Notification Mailer Processing.
The Workflow Notification Mailer uses a Java-based e-mail parser to interpret the text of the message and create an XML representation of it. Then the Workflow Notification Mailer places the XML message, in the form of a business event called oracle.apps.alr.response.receive, on an Oracle Workflow Business Event System agent called WF_NOTIFICATION_IN. Finally, the notification mailer moves the e-mail message to its processed folder.
Note: If the parser finds a string of text in the message that matches a tag pattern specified in the mailer configuration parameters, the Workflow Notification Mailer immediately moves the message to the discard folder instead. You can use tags to identify unusual messages such as bounced, returned, or auto-reply messages in order to skip unnecessary invalid response processing and avoid a perpetual loop of invalid warning messages and bounced or auto-reply messages. See: Tags.
Oracle Workflow provides an agent listener named Workflow Inbound Notifications Agent Listener that runs on the WF_NOTIFICATION_IN agent to continue processing for messages placed on that agent. When the Workflow Inbound Notifications Agent Listener dequeues an oracle.apps.alr.response.receive event message from WF_NOTIFICATION_IN, it executes a seeded Oracle Alert subscription that processes the response.
Oracle Alert reads the XML response message and tries to match the first word or the first 30 continuous characters of the response to any of the defined valid responses. After determining whether the response is valid or invalid, Oracle Alert submits the Alert Action Processor concurrent program to perform the appropriate actions. See: Processing Alert Response Actions.
If the actual response matches a valid response, then the Alert Action Processor performs the actions defined for that valid response. After the Alert Action Processor performs the actions for that valid response, Oracle Alert closes the response so that no other responses are processed for that message.
If the actual response does not match any of the valid responses in that response set, the Alert Action Processor performs the actions associated with the invalid response. The Alert Action Processor performs the invalid response actions each time Oracle Alert receives an invalid response within the response days specified in the original message action.
You must run the No Response Action Processor concurrent program to check for alert messages whose specified response days have passed without receiving a valid response. After the specified response days have passed, if Oracle Alert never received any response to the alert message or if it received only invalid responses, the No Response Action Processor performs the no response follow-up actions for each message and closes responses for all messages in that response set. See: Processing No Response Actions.
The Workflow Notification Mailer uses this event to handle an incoming alert response message.
| Internal Name | oracle.apps.alr.response.receive |
| Status | Enabled |
| Owner Name | Oracle Alert |
| Owner Tag | ALR |
| Customization Level | Limit |
Oracle Alert provides one default subscription to the oracle.apps.alr.response.receive event. When this event is received, this subscription processes the response and performs the appropriate actions as specified in the alert definition. The subscription is enabled by default. The following table lists the properties defined for this subscription.
Subscription Properties
| Subscription Property | Value |
|---|---|
| System | <local system> |
| Source Type | External |
| Event Filter | oracle.apps.alr.response.receive |
| Phase | 50 |
| Status | Enabled |
| Rule Data | Key |
| Action Type | Custom |
| On Error | Stop and Rollback |
| PL/SQL Rule Function | alr_mlr_package.response |
| Priority | Normal |
| Owner Name | Oracle Alert |
| Owner Tag | ALR |
| Customization Level | Limit |
By uniquely identifying each message that is associated with a response set, Oracle Alert can determine which response set a message is linked to, and perform the appropriate response actions.
Oracle Alert automatically attaches a message handle - a unique identifier - to each message that is associated with a response set. A message handle is composed of a number that identifies the Oracle Alert installation where the message originated, and a number that identifies the message itself. The format of a message handle as it appears in an alert message is:
<Oracle_Alert_installation_number>.<message_number>.<Oracle_ID>.<organization_ID>
For example:
2.347.3.5
The message handle is visible to the message recipient as a number at the end of the message.
Note: The Oracle Alert installation number, which you can review in the Response Processing tabbed region of the Oracle Alert Options form, is set to 1 by default.
In an alert message sent by the Workflow Notification Mailer, the message handle is included within an identifying string called the notification ID (NID) line. The NID line uses the following format:
NID[<message_handle>/0000@<mailer_node_name>]
where <message_handle> is the Oracle Alert message handle and <mailer_node_name> is the mailer node name used to identify the notification mailer that should process the message.
You can review a complete record of the exceptions found and response actions performed in Oracle Alert, if you save history for your response processing alert. When you define a response processing alert, the value you enter in the Keep _ Days field of the Alerts form determines the amount of history you save. The number you enter in this field should be in addition to the number of response days you enter in the Action Details block of the Actions window.
For example, if you want Oracle Alert to save history for 7 days after it performs the response actions, enter 7 plus the number of follow-up response days you specified for the alert message.