Configure Participants and Processes

Configuring Participant and Process Objects

The Flows Modeler is used to configure process definition information, which is is used in the runtime execution of instances of that process. This page shows how to configure process information for correct operation.

Configuring a BPMN Process if you have a BPMN Participant

If your process diagram contains a BPMN Participant (because you have added a participant or a laneset onto the diagram, the process information is defined inside the participant)

Participant Name: This is the name of the participant.

Participant ID: Generated by default to be a unique BPMN object ID for the BPMN Participant, this can be changed to a more meaningful “static ID” if required (useful for debugging).

Process ID: Generated by default to be a unique BPMN object ID for the BPMN Process, this can be changed to a more meaningful “static ID” if required (useful for debugging).

Process Name: Meaningful name for the business process specified in the model.

Executable: Check if this process definition is executable. Leave unchecked if it is incomplete or just descriptive.

Instance Name: 🆕 This will be used to create the runtime instance name when the process is started. The instance name can contain substitution parameters for any Flows for APEX process variables that will have been set before or during processing of the process Start Event. The Instance Name is evaluated during execution of the Start Event after any variable expressions have been evaluated.

Substitution syntax is &F4A$<process variable name>.

If the process instance was started from the API and a process name was specified there ( using the p_prcs_name parameter), the instance will use the parameter value until the Start Event is processed, at which time the instance name from the process diagram will replace it.

Documentation: Documentation for the participation and process can be included here.

Other Parameters: See below.

Configuring a standalone BPMN Process (without a BPMN Participant)

If your process diagram contains a standalone BPMN Process (without being paty of a participant or a laneset), the process information is defined in a different format as its own object.

Process ID: Generated by default to be a unique BPMN object ID for the BPMN Process, this can be changed to a more meaningful “static ID” if required (useful for debugging).

Process Name: Meaningful name for the business process specified in the model.

Executable: Check if this process definition is executable. Leave unchecked if it is incomplete or just descriptive.

Instance Name: 🆕 This will be used to create the runtime instance name when the process is started. The instance name can contain substitution parameters for any Flows for APEX process variables that will have been set before or during processing of the process Start Event. The Instance Name is evaluated during execution of the Start Event after any variable expressions have been evaluated.

Substitution syntax is &F4A$<process variable name>.

If the process instance was started from the API and a process name was specified there ( using the p_prcs_name parameter), the instance will use the parameter value until the Start Event is processed, at which time the instance name from the process diagram will replace it.

Element Documentation: Documentation for the process can be included here.

Other Parameters: See below.

Common Process Configuration Parameters

Whether your process is defined standalone or part of a participation, there are additional process configuration parameters included in the process diagram.

Execution

Is Callable: Select this if the diagram can be embedded into another process and can be called by a Call Activity in another diagram.

If the diagram is callable, the In/Out Variables section is displayed. Use this to detail the ‘in’ and ‘out’ process variables that are required by the process when it is called. This is used to aid correct use of the diagram when it is specified in a call activity in the using process diagram.

Is Startable: Select this to show which users or groups can start this process. While not currently used by the Flows for APEX engine to restrict sprocess start, this information can be accessed by external applications through the flow_startable_diagrams_vw view.

If selected, the Potential Starters section is displayed. This allows you to specify Potential Starting Users, Potential Starting Groups, and any users to be excluded when groups are evauated in Excluded Starting Users.

Each of these parameters can be specified using settings for:

• a static definition (can contain a colon separated list of users or groups)
• the name of a process variable containing a list of users or groups
• a SQL query returning a list of users or groups
• a PL/SQL expression returning a list of users or groups
• a PL/SQL function body returning a list of users or groups

Logging: 🆕 Specifies the minimum logging level to be used when this process is executed. This level can be increased on an instance by instance basis at process creation time, but cannot be lower than the level defined here.

Use this parameter to define a minimum logging level required to keep an audit trail of activities erformed during instance execution. For example, your financial or security relevant processes might set this at a higher level than routine processes.

See Event Logging and Auditing for more information on logging and auditing.

Background Task Session

Much of a process instance execution is performed as part of a users APEX session. When an APEX user completes a process step, and the next process step is a non-user step (such as a gateway, a script task, or a service task) those steps are executed as part of the current APEX user’s session synchronously. Control doesn’y return to the user until those synchronous steps are completed. Next steps that are user tasks may result in a new task appearing in the user’s (or another user’s) task list. However, some tasks are not completed synchronously, and result in a step which waits for some event, for example a timer or an incoming message, where the task execution is performed by some background process - such as the Oracle database scheduler or AQ.

When steps are executed asyncronously, Flows for APEX usually needs to create an APEX session in which to execute the step. If this information is not included in process variables set up by the preceding process step, Flows for APEX will look in the process definition for information on how to set up the APEX session. You need to specify a valid application ID, page ID, and username that can be used to create the APEX session.

Default Business Admin: 🆕 If your process sets up APEX Human Tasks and the potential owner and business admin is specified from the Flows for APEX workflow, you can likewise specify a default business admin to be used on APEX Human Tasks in case the user task definition does not include this. This helps to prevent orphan APEX Human Task instances being left if a Flows for APEX workflow is terminated or reset as it enables Flows for APEX to be able to connect as a business admin and cancel the no-longer-required task.

Scheduling Information

The process definition also allows you to specify the instance priority and the required process completion date / time or due on.

Priority: This sets the process instance priority. Priority is defined on a five point scale, with the same values as APEX Human Task and APEX Workflow priorities:

• 1 - Urgent
• 2 - High Priority
• 3 - Medium Priority
• 4 - Low Priority
• 5 - Lowest Priority.

Process priority is available during execution of process steps using the pseudo-process variable PROCESS_PRIORITY, which can be used to set task priorities of individual tasks in the process.

The Process Priority can also be altered during process execution using the flow_api_pkg.flow_set_priority API call. You could do this if a process changes priority or if it is unlikely to completer by its required completion time and you want to prioritise any outstanding steps.

Due On: This sets the required process completion time, as a timestamp. While this is currently not used to automatically re-prioritise slow running tasks, you could use this to, for example, increase process priority or expedite processing so that processes meet their required completion date.

Settings:

Each of these parameters can be specified using settings as:

• a static definition
• the name of a process variable containing the required value
• a SQL query returning the required value
• a PL/SQL expression returning the required value
• a PL/SQL function body returning the required value