Oracle Waveset 8.1.1 Deployment Reference

Workflow Action Variables

Table 1–2 Workflow Action Variables

Workflow Action Variable  

Description  

name

(Optional) inherited from WorkflowComponent. Action names are typically null. 

id

Identifies each action by a unique numeric ID. This is currently the index into the action array of the activity. 

title

(Optional) Used to calculate a title for this action in the Workflow summary diagram. By default, the title is name, but this variable can include information such as variable values. 

manual

Indicates whether the action is manual (flag). This value has priority over all other action type fields. 

request

Used to calculate the request string for a manual action’s work item. This text is displayed in the product interface, should be brief, and should clearly describe what is requested of the user (for example, Approve Role Engineering, Supply account ID, and Answer a question. If no request is supplied, Waveset uses the result of the title. If there is no title, Waveset generates a string based on the name and/or title of the Activity.

requester

Used to calculate the requester string for a manual action’s work item. This text is displayed in the product interface. It should be the name of a user or administrator that is considered to be the originator of the request. When null, Waveset assumes that the requester is the subject that launched the workflow case. 

description

Used to calculate the description string for a manual action’s work item. This text is displayed in the product interface. It is typically larger than the request string. 

timeout

Specifies one of the following options:

  • For manual actions, defines the maximum number of minutes that Waveset waits for this action to be performed. If the timeout is reached, the workflow executor considers the action completed. Variables must be used to determine the control flow after a timeout

    The workflow engine sets the WF_TIMEOUT variable to true in the scope of this activity if the item was completed due to timeout.

  • Specifies an expression that yields a timeout value.

expression

Specifies the root of the expression tree that defines the action. If this value is set, it takes priority over the subprocess, and application fields. 

subprocess

Specifies one of the following options:

  • Specifies the name of a subprocess to invoke. This can either be an internal or external subprocess. If external, it can be a type-qualified name, for example, TaskDefinition:example or Configuration:example.

  • Specifies a rule that generates a subprocess name. The returned object can be a String or an ObjectRef. If a String, it can identify an internal or external process such as subprocess.

application

Specifies the name of an application that is to be called. This can either be the abstract name of a built-in application, or may be a fully qualified class name of a class that implements the WorkflowApplication interface. 

The names of the built-in applications are defined by WorkflowExecutor. 

owner

If the action type is manual, this field must hold the name of the owner for whom the WorkItem will be created. 

It can be an Administrator name, or use variable reference syntax (for example, $(ADMIN_NAME)). 

delegator

Specifies an expression used to calculate the delegator string for a manual action’s work item. This text is displayed in the GUI, it should be the name of a user or administrator that is considered to be the delegator of the request. 

name

Specifies an expression that will calculate the work item name. Usually the name will be a randomly generated unique identifier, but in some cases it is desirable to pre-compute the name so that it may be used in email notifications, embedded in a URL that will jump directly to the work item. 

trackingId

Specifies an expression that will calculate the work item name. Typically, the name will be a randomly generated unique identifier, but in some cases you might want to pre-compute the name so that it can be used in email notifications, embedded in a URL that will jump directly to the work item. 

localForm

Manual actions can define a form object that can be used by the work list application to prompt the user for the variables expected to be returned when the action is complete. 

There are three ways to specify a form: 

  • set a self-contained form in _localForm

  • set a reference to a form in _formRef

  • have an XPRESS rule that generates a name.

formRef

Specifies a reference to an object containing a Form to use when editing the work item for a manual action. 

formRule

Specifies a rule that will generate the name of a form or a Form object itself. 

arguments

For all action types, a list of arguments can be specified. These are similar to Variables, but they live in a different namespace, sort of like a local Action variable so you don’t have to worry about collision with variable names. 

variables

A list of locally defined action variables used by manual actions. This is needed when iteration is being used. 

returns

A list of declarations of action return values. This defines a mapping between variables defined within the action result, and variables defined in the activity/process. 

This needs more thought, but its the only reasonably simple way I could come up with to perform the mapping without having variable chaos, or introducing path expressions to reference variables created in other scopes (for example, activity.action.variable) 

iteration

Specifies an object that defines optional iteration settings for the action. 

results

Specifies a list of result declarations for this action. 

hidden

Indicates that the action is to be hidden from the workflow summary diagram. (Boolean) 

condition

Specifies an optional conditional expression. If this is set, the value of the expression must be true, in order to execute the action, if false, the action is ignored. 

checkError

Indicates whether the action will be run. When true, the action will be run only if the value of WF_ACTION_ERROR is null. This is shorthand for a very common <Condition>. 

comments

(Optional) Contains arbitrary comments. 

syncExec

Indicates that the WorkItem created for a manual action should have the synchronous execution flag set. As a result, when the owner checks in a change to the work item, the workflow should be advanced synchronously rather than scheduled for background execution. 

This is true for “wizard” style workflows where a workflow controls a sequence of pages. 

exposedVariables

For manual actions, lists the variables that are to be included in the work item. The names can be GenericObject path expressions. If this list is null, then all variables are included. 

editableVariables

Lists variables that can be edited in the work item and assimilated back into the case (manual actions only). If this list is null, then any variable in the exposedVariables list is considered editable. If exposedVariables is null, then all workflow variables are editable.

Use to avoid collisions where many variables must be exposed to multiple approvers, but each approver is allowed to modify only a subset of the variables. 

Views

Lists variables that contain views. Inclusion of a view on this list causes Waveset to refresh the view when the work item is refreshed. 

ignoreTimeout

Typically, when a work item times out and is deleted while the user is viewing or editing the item, Waveset throws an exception and displays an error page. Occasionally, though, Waveset uses a work item only to display (not edit) summary information. These work items can have a short time-out to allow the workflow to continue processing. 

Setting this option to true causes the Work Item View handler to avoid throwing an exception. It does not affect the behavior of the process. 

authType

Specifies an authorization type to be assigned to the WorkItem that is created for a manual action. Use this variable if you want work items to be authorized differently (for example, granting someone the rights to approve Resource requests but not Organization request.). 

itemType

Specifies a user-defined type name for the WorkItem created for a manual action. Use this variable to assign custom categories of work items (for example, “approval” or “wizard”). 

targetId

Optional. Contains the Waveset ID of the object being acted on by the work item. 

targetName

Optional. Contains the Waveset Name of the object being acted on by the work item. 

targetObjectClass

Optional. Contains the objectclass name of the object being acted on. 

What is an Application Action?

Application actions permit you to invoke more complex Java calls than you can invoke with script actions.

What is a Manual Action?

A manual action is part of the workflow process definition that defines a manual interaction. When the Workflow Executor processes a manual action, Waveset creates a WorkItem object in the Repository. The work item must be marked complete before the workflow can proceed. You must associate an owner with a Manual Action. An owner can be an expression that determines an owner.

Because most manual actions are used to solicit approvals, the work item table is located under the Approvals tab of the Administrator Interface. Any manual action that belongs to a workflow is represented by a WorkItem object in the Repository. The WorkItem view contains a few attributes that pertain to the WorkItem object itself, as well as values of selected workflow variables copied from the workflow task. These include attributes, such as owners of pending approvals, and the form used to approve the WorkItem. Waveset incorporates ManualActions in the standard workflow and allows approvals for organizations, roles, and resources.

You can assign a time-out to a manual action.