Actions enable necessary control over a process flow. Follow the below steps to add Actions to a Process Flow.
In Web Process Designer, in the Repository View panel, click Actions.
Select the required action and drag it to the Canvas area.
Click the action element and the properties of the element are displayed in the Activity Properties panel.
- Change the required properties and then click in the canvas area to save the properties.
The below table depicts the list of actions that can be used to control the process flow.
Action | Description | |
|---|---|---|
Call
| This action is used to call another process flow (sub-flow) synchronously. You need to specify the following properties while adding the Call action to a process flow: flowId: Name of the process flow (sub-flow). You can override its value dynamically during the execution of the process flow. To override the flowId, you can either use custom plugin activity or put-context-var before the Call action. You can use the following code in the custom plugin activity to override the flow id: context.setActivityParameter("Call1","flowId", "192168001158117188341381200001");where, Call1 is the name of the call activity and 192168001158117188341381200001 is the ID of the child process flow. Name: Name of the call action. resultCtxVarName: Name of the context variable that contains the status of the sub-flow - Executed, Aborted, Queued, or Waiting. Using Call action you can select the Parent process flow itself to be executed as a child process flow. In this case, the process flow will run in an infinite loop. You should use some condition to stop the process flow after certain recursion. If the condition fails, you can kill the process flow from the System Monitoring. | |
Checkpoint | This action is used to resume the execution of a process flow from its current state, if the Kernel stops unexpectedly or if the process flow aborts for any reason. The Checkpoint action saves the process flow state (context variable, checkpoint info, state name, etc.) in the respective recovery and/or rerun files. When the Kernel is restarted, it checks for the recoverable process flow by scanning all the existing process flow files and starts the particular process flow from its last recovery checkpoint. If the process flow aborts due to any reason, and when you rerun it, the process flow checks for the rerun files of that particular process flow instance and starts the process flow from its last rerun checkpoint. Checkpoint should not be used within JTA block. It should be used before or after the JTA block. You need to specify the following properties while adding the Checkpoint action to a process flow: Label: The label displayed for the Checkpoint action. Name: Name of the Checkpoint action. Configuring abpm.transaction.abort.checkpoint.failure propertyIn the event of a failed checkpoint or an error occurring while generating a recovery file, you can make sure that the process flow continues to run by configuring the property abpm.transaction.abort.checkpoint.failure. To achieve this, you need to set the value for this property to No. With this configuration, the system marks the process flow as non recoverable at that checkpoint and continues with the execution of the process flow. By default the value of this property is set to yes. Follow the steps below to configure this property:
If the first checkpoint fails and the second checkpoint gets executed successfully, the process flow is marked as recoverable. | |
Delay | This action is used to pause the propagation of a process flow for a given time. The Delay action pauses the propagation of a process flow but the asynchronous activities, which were started earlier, keep running in parallel. You need to specify the following properties while adding the Delay action to a process flow: Label: The label displayed for the Delay action. Name: Name of the Delay action. Time: Time in seconds till which the execution of process flow is paused. | |
JTA-Begin/ JTA-End | These actions are used to create a JTA block. JTA block is used to create a set of activities within a process flow. When all the activities in a JTA block are completed successfully, the data is committed, and the process flow control can move beyond the JTA block to the next activity. If any of the activities in the JTA block fails to complete successfully, the rollback function is called, the whole process flow is stopped, and error is logged. JTA is applicable only when source or target is a database. You need to specify the following properties while adding these actions to a process flow: Label: The label displayed for the JTA-Begin/End action. Name: Name of the JTA-Begin/End action. | |
JTA-RollBack | This action is used to call the rollback function at any point in a process flow. The JTA–RollBack function is always used within a JTA block. You need to specify the following properties while adding the JTA-RollBack to a process flow: Label: The label displayed for the JTA-Rollback action. Name: Name of the JTA-Rollback action. | |
Put-Context-Var | This action is used to declare one or more context variables with values assigned to it at any point in the process flow. A context variable is declared when this action is executed while running the process flow. Put-Context-Var is generally used to set the value of any field of an activity used in a process flow, during the execution of the process flow. For example, you can set/overwrite the subject of the mail source activity during the execution of a process flow. Another example can be appending current date stamp at the end of the name of a file, created as a target, during the process flow execution. You need to specify the following properties while adding the Put-Context-Var action to a process flow: Edit Context: Displays a condition screen to add a new context variable or edit or delete the existing context variables. Label: The label displayed for the Put-Context-Var action. Name: Name of the Put-Context-Var action. Type: Displays the type of action selected. This is a read-only field. | |
Set-Child-Context | This action is used to set the value of Process Flow Context Variable or Activity Context Variable from the parent process flow to the child process flow. Set-child-Context must be used before the Call action. You need to specify the following properties while adding the Set-Child-Context action to a process flow: Activity: Name of activity in the parent process flow, whose 'Activity Context Variable' value will be used to set the child context variable specified by the Child Key. If the name of the activity is not specified, then the 'Process Flow Context Variable' specified by the Key will be used. ChildActivityName: Name of the activity of the child process flow whose value will be set. If the name of the activity is not specified then the 'Process Flow Context Variable' specified by Child Key will be set. Childkey: Name of the Context Variable of the child process flow whose value will be set. ChildName: Name of the Call or Spawn action to call or spawn the child process flow. Set-child-context uses the ChildName to find out the call or spawn action and the corresponding process flow to set the context variable. Key: Name of the context variable of the parent process flow whose value will be used to set the child context variable specified by the Child Key. Label: The label displayed for the Set-Child-Context action. Name: Name of the Set-Child-Context action. | |
Set-Parent-Context | This action is used to set the value of the 'Process Flow Context Variable' or 'Activity Context Variable' from the child process flow to the 'Process Flow Context Variable' or 'Activity Context Variable' of the parent process flow, which initiated the child process flow by the call/spawn action. You need to specify the following properties while adding the Set-Parent-Context action to a process flow: Activity: Name of the activity of the child process flow, whose 'Activity Context Variable' value specified by the Key will be used to set the parent process flow variable specified by the Parent key. If the name of the activity is not specified, then the 'Process Flow Context Variable' specified by the Key will be used. Key: Name of the context variable of the child process flow whose value will be used to set the parent context variable specified by the Parent Key. Label: The label displayed for the Set-Parent-Context action. Name: Name of the Set-Parent-Context action ParentActivityName: Name of the activity of the parent process flow whose 'Activity Context Variable' specified by the Parent Key will be set. If the name of the activity is not specified, then the 'Process Flow Context Variable' specified by the Parent Key will be set. ParentKey: Name of the Context Variable of the parent process flow whose value will be set. | |
Spawn | This action is used to call another process flow (sub-flow) asynchronously. You need to specify the following properties while adding the Spawn action to a process flow: flowId: Name of the process flow (sub-flow). You can override its value dynamically during the execution of the process flow. To override the flowId you can either use the custom plugin activity or put-context-var before the Spawn action. You can use the following code in the custom plugin activity to override the flow id: context.setActivityParameter("Spawn1","flowId", "192168001158117188341381200001"); where, Spawn1 is the name of the spawnactivityand 192168001158117188341381200001 is the ID of the child process flow. Name: Name of the Spawn action. resultCtxVarName: Name of the context variable that contains the status of the sub-flow - Executed, Aborted, Queued, or Waiting. Signal: Name for the signal generated by the asynchronous process flow (sub-flow). This property is applicable only when the Wait for Childproperty is set to true. Wait for Child: Specify whether the parent process flow's end event will wait for the completion of child process flow or not. If this property is set to true, the parent process flow end event will wait till the child process flow is completed. During this period, parent process flow will be in the running state. Once the child process flow is completed, it raises the signal specified in the Signal property and then the end event is executed. If the value is set to false, then the parent process flow does not wait for the child process flow to be completed. | |
Synch | This action is used to raise a signal to process engine when an asynchronous activity is completed. You need to specify the following properties while adding the Synch action in a process flow: Label: The label displayed for the Synch action. Name: Name of the Synch action. Signal: Name of the signal that is specified in the signal properties of the Synch action. | |
Trace | This action is used to log a message that can be used for debugging or error log purposes. You can check the values of the variable at runtime in a process flow. This action uses Adeptia Server logging framework. You need to specify the following properties while adding the Trace action to a process flow. Label: The label displayed for the Trace action. Log Level: Log Level is the level at which the message is to be logged. It can be logged at DEBUG, INFO or ERROR levels. Logging level for trace action should not be higher than the logging level of the process flow. For example, if you have selected 'INFO' logging level in the process flow, you should select 'INFO' or 'ERROR' in the trace action. If you select 'DEBUG' logging level in the trace action, the trace message will not be logged in the process flow log. Similarly, while viewing the process flow log, if you select the logging level lower than the logging level of trace action, you cannot see this trace message in the process flow logs. Message: Message that is logged when the trace action is executed. To print the value of the variables in the logs, type $$variablename$$ in the message field. Name: Name of the Trace action. | |
Wait | This action waits for the certain variable value to be changed in a process flow 'context' to a predefined value for a given timeout. Basically, process engine waits for some event to happen then it moves forward. This action is related to the polling of a variable and setting some variable in the context. If the user is polling for any context variable value then var, value and resultCtxVarName fields are mandatory in the Wait action. You need to specify the following properties while adding the Wait action to a process flow: Label: The label displayed for the Wait action. Name: Name of the Wait action. pollinginterval: Time interval in seconds the wait action will poll for the above specified variable value. resultCtxVarName: Name of the context variable that contains the status of the Wait action - Executed, Aborted, Queued, or Waiting. timeout: Timeout duration in seconds. value: Value of the context variable. var: Name of the context variable for which the Wait action 'waits'. | |