A notification activity in a workflow process consists of a design-time message and a list of message attributes. In addition, there may be a number of runtime named values called item type attributes from which the message attributes draw their values.
The Workflow Engine moves through the workflow process, evaluating each activity in turn. Once it encounters a notification activity, the engine makes a call to the Notification System Send() or SendGroup() API to send the notification.
The Send() API or the SendGroup() API is called by the Workflow Engine when it encounters a notification activity. These APIs do the following:
Check that the performer role of the notification activity is valid.
Identify the notification preference for of the performer role.
Look up the message attributes for the message.
If a message attribute is of source SEND, the Send() or SendGroup() API retrieves its value from the item type attribute that the message attribute references. If the procedure cannot find an item type attribute, it uses the default value of the message attribute, if available. The Subject and Body of the message may include message attributes of source SEND, which the Send() or SendGroup() API token replaces with each attribute's current value when creating the notification.
If a message includes a message attribute of source RESPOND, the Send() or SendGroup() API checks to see if it has a default value assigned to it. The procedure then uses these RESPOND attributes to create the default response section of the notification.
'Construct' the notification content by inserting relevant information into the Workflow notification tables.
Update the notification activity's status to 'NOTIFIED' if a response is required or to 'COMPLETE' if no response is required.
Note: If a notification activity sends a message that is for the performer's information only (FYI), where there are no RESPOND message attributes associated with it, the notification activity gets marked as complete as soon as the Notification System delivers the message.
Note: In the case of a voting activity, the status is updated to 'WAITING' instead of 'NOTIFIED'. See: Special Handling of Voting Activities.
Raise the oracle.apps.wf.notification.send event. When this event is processed, a notification mailer generates an e-mail version of the notification if the performer role of a notification has a notification preference of MAILTEXT, MAILHTML, MAILHTM2, or MAILATTH, and sends the e-mail to the performer. For roles with a notification preference of SUMMARY or SUMHTML, a summary e-mail is sent when the oracle.apps.wf.notification.summary.send event is raised. See: Implementing Notification Mailers.
Note: The notification mailer does not send e-mail notifications to roles with a notification preference of QUERY or DISABLED. Users with a notification preference of QUERY only access their notifications through the Worklist Web page. Users whose notification preference has been set to DISABLED must correct their e-mail address and reset their notification preference before a notification mailer can send them e-mail notifications.
Users who view their notifications from the Worklist Web page, regardless of their notification preferences, are simply querying the Workflow notification tables from this interface.
A notification recipient can perform the following actions with the notification:
Respond to the notification or close the notification if it does not require a response. See: Processing a Notification Response.
Forward the notification to another role. See: Forwarding a Notification.
Transfer ownership of the notification to another role. See: Transferring a Notification.
Request more information about the notification from another role, or respond to such a request with more information. See: Requesting More Information About a Notification.
Ignore the notification and let it time out. See: Processing a Timed Out Notification.
Note: You can use the WF: Notification Reassign Mode profile option to determine whether users can reassign notifications by forwarding (also known as delegating) the notifications, transferring the notifications, or both. See: Setting the WF: Notification Reassign Mode.
After a recipient responds, the Notification Details Web page or a notification mailer assigns the response values to the notification response attributes and calls the notification Respond() API. The Respond() API first calls a notification callback function to execute the notification activity's post-notification function (if it has one) in VALIDATE mode. In this mode, the post-notification function can validate the response values before accepting and recording the response. For example, if the notification requires an electronic signature, the post-notification function can run in VALIDATE mode to verify the response values and inform the user of any errors before requiring the user to enter a signature. If the post-notification function raises an exception, the response is aborted. See: Post-notification Functions.
Next, Respond() calls the notification callback function to execute the post-notification function in RESPOND mode. The post-notification function may interpret the response and perform tightly-coupled post-response processing. Again, if the post-notification function raises an exception, the response is aborted.
If no exception is raised, Respond() marks the notification as closed and then calls the notification callback function again in SET mode to update the corresponding item attributes with the RESPOND notification attributes values. If the notification message prompts for a response that is specified in the Result tab of the message's property page, that response value is also set as the result of the notification activity.
Finally, Respond() calls WF_ENGINE.CompleteActivity() to inform the engine that the notification activity is complete so it can transition to the next qualified activity.
If a recipient forwards a notification to another role, the Notification Details Web page calls the Notification System's Forward() API.
Note: The Notification System is not able to track notifications that are forwarded via e-mail. It records only the eventual responder's e-mail address and any Respond message attributes values included in the response.
The Forward() API validates the role, then calls a notification callback function to execute the notification activity's post-notification function (if it has one) in FORWARD mode. As an example, the post-notification function may verify whether the role that the notification is being forwarded to has appropriate authority to view and respond to the notification. If it doesn't, the post-notification function may return an error and prevent the Forward operation from proceeding. See: Post-notification Functions.
Forward() then forwards the notification to the new role, along with any appended comments.
Note: Forward() does not update the owner or original recipient of the notification.
If a recipient transfers the ownership of a notification to another role, the Notification Details Web page calls the Notification System's Transfer() API.
Note: Recipients who view notifications from an e-mail application cannot transfer notifications. To transfer a notification, the recipient must use the Notifications Web page.
The Transfer() API validates the role, then calls a notification callback function to execute the notification activity's post-notification function (if it has one) in TRANSFER mode. As an example, the post-notification function may verify whether the role that the notification is being transferred to has appropriate authority. If it doesn't, the post-notification function may return an error and prevent the Transfer operation from proceeding. See: Post-notification Functions.
Transfer() then assigns ownership of the notification to the new role, passing along any appended comments. Note that a transfer is also recorded in the comments of the notification.
If a recipient requests more information about the notification from another role, the Notification Details Web page calls the Notification System's UpdateInfo() API, or a notification mailer calls the Notification System's UpdateInfo2() API.
The UpdateInfo() or UpdateInfo2() API calls a notification callback function to execute the notification activity's post-notification function (if it has one) in QUESTION mode. As an example, the post-notification function may verify that the request is directed to a role that has appropriate authority to view the notification. If it doesn't, the post-notification function may return an error and prevent the request for more information from being sent. See: Post-notification Functions.
If no error is returned, the API then sends the request for more information to the designated role. Note that a request for information is also recorded in the comments of the notification.
If the recipient of a request for more information responds with answering information, the Notification Details Web page calls the Notification System's UpdateInfo() API if the responder is logged in individually or the UpdateInfoGuest() API if the responder is logged in as the GUEST user, or a notification mailer calls the Notification System's UpdateInfo2() API.
The UpdateInfo(),UpdateInfoGuest(), or UpdateInfo2() API calls a notification callback function to execute the notification activity's post-notification function (if it has one) in ANSWER mode. As an example, the post-notification function may validate the answering information. If such validation fails, the post-notification function may return an error and prevent the answer from being sent. See: Post-notification Functions.
If no error is returned, the API then sends the answering information back to the recipient role of the original notification. Note that an answer to a request for information is also recorded in the comments of the notification.
Timed out notification or subprocess activities are initially detected by the background engine. Background engines set up to handle timed out activities periodically check for activities that have time out values specified. If an activity does have a time out value, and the current date and time exceeds that time out value, the background engine marks that activity's status as 'TIMEOUT' and calls the Workflow Engine. The Workflow Engine then resumes by trying to execute the activity to which the <Timeout> transition points.
A voting activity by definition is a notification activity that:
Has its roles expanded, so that an individual copy of the notification message is sent to each member of the Performer role.
Has a message with a specified Result, that requires recipients to respond from a list of values.
Has a post-notification function associated with it that contains logic in the RUN mode to process the polled responses from the Performer members to generate a single response that the Workflow Engine interprets as the result of the notification activity. See: Voting Activity.
Once the Notification System sends the notification for a voting activity, it marks the voting activity's status as 'NOTIFIED'. The voting activity's status is updated to 'WAITING' as soon as some responses are received, but not enough responses are received to satisfy the voting criteria.
The individual role members that each receive a copy of the notification message can then respond or forward the notification, or request or respond with more information, if they use e-mail or the Worklist Web pages to access the notification. They can also transfer the notification if they use the Worklist Web pages.
The notification user interface calls the appropriate Respond(), Forward(), Transfer(), UpdateInfo(), UpdateInfo2(), or UpdateInfoGuest() API, depending on the action that the performer takes. Each API in turn calls the notification callback function to execute the post-notification function in VALIDATE and RESPOND, FORWARD, TRANSFER, QUESTION, or ANSWER mode, as appropriate. When the Notification System finishes executing the post-notification function in FORWARD or TRANSFER mode, it carries out the Forward or Transfer operation, respectively. When the Notification System finishes executing the post-notification function in QUESTION or ANSWER mode, it sends the request for more information to the designated role or the answer to the requesting role, respectively.
When the Notification System completes execution of the post-notification function in RESPOND mode, the Workflow Engine then runs the post-notification function again in RUN mode. It calls the function in RUN mode after all responses are received to execute the vote tallying logic.
Also if the voting activity is reset to be reexecuted as part of a loop, or if it times out, the Workflow Engine runs the post-notification function in CANCEL or TIMEOUT mode, respectively. The logic for TIMEOUT mode in a voting activity's post-notification function should identify how to tally the votes received up until the timeout.