An activity is a unit of work that contributes toward the accomplishment of a process. An activity can be a notification, a function, an event, or a process. A notification activity sends a message to a workflow user. The message may simply provide the user with information or request the user to take some action. A function activity calls a PL/SQL stored procedure or some external program to perform an automated function. An event activity receives, raises, or sends a business event. A process activity is a modelled workflow process, which can be included as an activity in another process to represent a sub-process.

Activities are organized beneath their respective Processes, Notifications, Functions, or Events headings in the navigator tree. You can create, edit, and delete activity definitions in the navigator tree, and drag an activity from the tree into a Process window to create a new usage of that activity in a process diagram. Each activity is depicted as an icon in a process diagram

Oracle Workflow provides an item type called Standard that includes generic activities you can use in any process you define. For example, some of the activities perform standard functions such as comparing two values. See: Standard Activities.

Oracle Workflow also provides an item type called System:Error that includes standard error processes and activities you can use to create a custom error process. You can assign an error process to a process activity. If an error occurs, the error process informs Oracle Workflow how to handle the error. See: Error Handling for Workflow Processes.

Notification Activity

When the workflow engine reaches a notification activity, it issues a Send() API call to the Notification System to send the message to an assigned performer. You define the message that the notification sends. The message can be an informative note or it can prompt the performer for a response. When a performer responds to a notification activity, the Notification System processes the response and informs the Workflow Engine that the notification activity is complete so that it can continue processing the next eligible activity. See: To Create a Notification Activity.

You specify the performer of a notification activity when you include the notification activity as a node in the process. You can either designate the performer to be a specific role or an item type attribute that dynamically returns the name of a role. A role can correspond to a single user or contain multiple users as members. See: To Define Nodes and Roles.

When you define a notification activity, you can also optionally:

• Check Expand Roles to send an individual copy of the notification message to each user in the role. The notification remains in a user's notification queue until the user responds to or closes the notification.

  Important: You should expand roles to send out a broadcast-type message that you want all users of that role to see.

  If you do not expand the role for a notification activity, Oracle Workflow sends one copy of the notification message to the assigned performer role and that notification is visible in the notification queue of all the users in that role. If one user in that role responds to or closes that notification, the notification is removed from the notification queue of all other users in that role.

• Specify a post-notification function that the Workflow Engine executes in response to an update of the notification's state after the notification is delivered. The Workflow Engine runs the post-notification function in the following modes:

  • VALIDATE, RESPOND, and RUN - When a notification recipient responds to the notification.

    The Workflow Engine initially runs the post-notification function in VALIDATE mode which allows you to validate the response values before accepting the response. Then the Workflow Engine runs the post-notification function in RESPOND mode to record the response. Finally, 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.

  • FORWARD - When a notification recipient forwards the notification.

  • TRANSFER - When a notification recipient transfers the notification.

  • QUESTION - When a notification recipient requests more information about the notification from another user.

  • ANSWER - When a request recipient responds with more information about the notification.

  • TIMEOUT - When the notification times out.

  • CANCEL - When the notification activity is reset to be reexecuted as part of a loop.

  For example, if you wish to restrict the roles that a notification can be forwarded to, you can specify a post-notification function that the Workflow Engine executes in FORWARD mode when the notification recipient attempts to forward the notification. The post-notification function would audit the role and either allow the forward to occur or reject it with an error. See: Post-Notification Functions and Notification Model.

  To create a post-notification function, you should use the same PL/SQL API required for function activities. See: Standard API for PL/SQL Procedures Called by Function Activities.

  By both checking Expand Roles and specifying a post-notification function, you can create your own custom vote tallying activity. See: Voting Activity.

Function Activity

A function activity is defined by the PL/SQL stored procedure or external program that it calls. Function activities are typically used to perform fully automated steps in the process. As a PL/SQL stored procedure, a function activity accepts standard arguments and can return a completion result.

If you pass a parameter for the stored procedure, you can expose that parameter as an activity attribute. The activity attribute's value can be set when you define that activity as a node in your process. Note that these activity attributes are available only to the current activity and are not global like item type attributes. See: To Define Activity Attribute Values.

As an external program, a function activity is able to enqueue payload information into an Oracle Advanced Queuing outbound queue for some external agent to dequeue and consume. The external agent can similarly enqueue updated attributes and a completion result into an inbound queue that the Workflow Engine consumes and processes.

Event Activity

An event activity represents a business event from the Business Event System within a workflow process. Include event activities in workflow processes to model complex processing or routing logic for business events beyond the standard event subscription actions. See: Managing Business Events.

An event activity can either receive, raise, or send a business event.

Receive Event Activity

A Receive event activity accepts an event sent from the Event Manager. You can send an event to launch one particular new process or continue one particular existing process identified by a specific item type, process name, and item key. You can also send an event to continue one or more existing processes based only on a business key attribute.

A Receive event activity can be marked as a Start activity for a process, meaning it is always enabled to receive events. Alternatively, a Receive event activity can be placed within the process, so that it is only enabled to receive events after the process transitions to that activity.

You can define a Receive event activity to accept only one specific event, to accept only an event that is a member of a specific event group, or to accept any event.

When an event subscription sends an event to a workflow process, the Workflow Engine performs the following processing:

• Sets any parameters in the event message parameter list as item type attributes for the process, creating new item type attributes if a corresponding attribute does not already exist for any parameter.

• Sets the subscription's globally unique identifier (GUID) as a dynamic item attribute so that the workflow process can reference other information in the subscription definition.

• If the event was originally raised by a Raise event activity in another workflow process, the item type and item key for that process are included in the parameter list within the event message. In this case, the Workflow Engine automatically sets the specified process as the parent for the process that receives the event, overriding any existing parent setting. See: SetItemParent.

• Searches for receive event activities that are eligible to accept the event. For an activity to be eligible, the event must match the activity's event filter, and the activity must either be marked as a Start activity or have a status of 'NOTIFIED', meaning the process has transitioned to the event.

  Note: If the event was sent to one or more existing workflow processes based on a business key, rather than to one particular workflow process, then to be eligible an activity must have an event filter that matches the event, a status of 'NOTIFIED' , and a #BUSINESS_KEY attribute that matches the event key. See: Event Subscriptions.

• If an event arrives at a Start activity to launch a new process instance, the Workflow Engine also searches for all other receive event activities that are marked as Start activities and that do not have any incoming transitions, regardless of their event filter. For these activities, the Workflow Engine sets the activity status to 'NOTIFIED' so that they will be ready to receive an event if any more events are sent to this process. This feature lets you design a workflow process that requires multiple events to be received when you do not know in advance the order in which the events will arrive.

• Stores the event name, event key, and event message in item type attributes, as specified in each eligible activity node's event details.

• Marks all the eligible event activity nodes with a status of 'COMPLETED' and continues the thread of execution from each of those nodes.

If an event activity has already received an event and another matching event is sent to the process, then the On Revisit flag for the activity determines whether the Workflow Engine reexecutes the activity. See: To Define Optional Activity Details.

Use a business key to identify which workflow processes should receive an event when the event applies to one or more processes that are already started and are awaiting input to continue. For example, a workflow process initiated for a purchase order with the number PO123 may be awaiting input such as credit card authorization from another workflow or from an external interface, through an event named po.credit.authorization. The authorization event should only continue the workflow process instance associated with the PO123 purchase order; it should not continue any other purchase order processes.

To achieve this purpose, the receive event activity in the purchase order workflow process should be defined to accept only the po.credit.authorization event and should include an activity attribute named #BUSINESS_KEY with a value of PO123. The other workflow process or external system that raises the event must set the event key to PO123. Additionally, either the event subscription to the po.credit.authorization event must use the WF_RULE.Instance_Default_Rule rule function, or the subscription must be defined with the Launch When Business Key Matches option. With this configuration, when the event arrives, it will continue only the workflow process instance associated with the specific purchase order number PO123 through the #BUSINESS_KEY activity attribute.

Raise Event Activity

A Raise event activity retrieves information about the event and raises the event to the Business Event System, which will then execute subscriptions to the event. The activity retrieves the event name, event key, and event data as specified in the node's event details. The event details can be dynamically determined at runtime using item type attributes. You can also specify the event name as a predefined constant for the event activity node.

Additionally, the activity retrieves the names and values of any activity attributes defined for it and sets these attributes as parameters in the parameter list for the event message. If the event message is later received by another process, the Workflow Engine sets the event parameters as item type attributes for that process. See: Event Message Structure.

The activity also automatically sets the item type and item key for the current workflow process in the parameter list for the event message. If the event message is later received by another process, the Workflow Engine uses that item type and item key to automatically set the process that raised the event as the parent for the process that receives the event. See: SetItemParent.

If you want to raise the new event using the event data and parameter list from an existing event message, you can define a special activity attribute named #EVENTMESSAGE2 for the raise event activity. Set the existing event message as the value of the #EVENTMESSAGE2 attribute, which must be an attribute of type event. If this attribute is defined, the activity retrieves the event data and parameter list from the specified event and sets them into the new event message before it is raised.

For example, if the process previously received an event and you want to raise a new event with that event data, you can define the #EVENTMESSAGE2 attribute for the raise event activity and set its default value to the item attribute where the received event is stored.

Send Event Activity

A Send event activity retrieves the event name, event key, event message, outbound agent, and inbound agent, as specified in the node's event details. If no correlation ID is initially specified in the event message, the correlation ID is automatically set to the item key of the process. Then the Send event activity sends the event directly from the outbound agent to the inbound agent. The event details can be dynamically determined at runtime using item type attributes. You can also specify the event name, outbound agent, and inbound agent as predefined constants for the event activity node. See: To Create an Event Activity and To Define Event Details for an Event Node.

Process Activity

A process activity represents a collection of activities in a specific relationship. When a process activity is contained in another process it is called a subprocess. In other words, activities in a process can also be processes themselves. There is no restriction on the depth of this hierarchy. See: To Create a Process Activity and Subprocesses.

#ONDEMANDATTR Attribute

When you create a top-level runnable process activity, you can use a special process activity attribute with the internal name #ONDEMANDATTR to enhance performance for the process. By default, when a work item is initiated, Oracle Workflow creates a runtime copy of each item attribute that is defined for that item type. The Workflow Engine refers to these runtime copies whenever an item attribute is referenced during execution of the work item. However, depending on the process logic, an item type may contain many item attributes that are not used during execution of a particular work item. You can define the #ONDEMANDATTR activity attribute for a process activity to specify that Oracle Workflow should create runtime copies of item attributes only when the process sets values for those item attributes. Otherwise, the Workflow Engine simply references the default values specified for the item attributes in the design-time workflow definition.

The Workflow Engine simply checks for the presence of the #ONDEMANDATTR attribute to determine how to proceed. To create runtime copies of item attributes only on demand, define the #ONDEMANDATTR attribute for the appropriate process activity. The attribute can be of any type and does not need to contain any particular value. To create runtime copies of all item attributes when the process is created, do not define this attribute for the process activity.

If you define a default value for the #ONDEMANDATTR activity attribute, you must define the default value as a constant value. Do not define the #ONDEMANDATTR attribute to take its default value from an item attribute.

See: Item Type Attributes andItem Attributes.

Activity Cost

Each function activity and event activity has a cost associated with it. The cost is a value representing the number of seconds it takes for the Workflow Engine to execute the activity. If you do not know how long it takes for the Workflow Engine to perform the activity, you can enter an estimated cost and update it later as you accumulate more information about its performance. Generally, you should assign complex, long running activities a high cost.

The valid range for cost is 0.00 to 1,000,000.00.

In normal processing, the Workflow Engine completes the execution of a single activity before continuing to a subsequent activity. In some cases, an activity might take so long to process that background processing would be more appropriate.

You can define your Workflow Engine to defer activities with a cost higher than a designated threshold to a background process. The engine then continues processing the next pending eligible activity that may occur in another parallel branch of the process.

The default threshold for the Workflow Engine is 50 hundredths of a second. Activities with a cost higher than this are deferred to background engines. A background engine can be customized to execute only certain types of activities. You can set the workflow engine threshold through SQL*Plus. See: Setting Up Background Engines, To Set Engine Thresholds, and Deferring Activities.