Actions

   Journey Manager (JM) The transaction engine for the platform.  |    System Manager / DevOps  |  All versions This feature is related to all versions.

A collaboration job consists of a number of steps and actions. Each action executes an instance of an action service or a job function. There are a number of predefined actions that you can use. You can also create GroovyGroovy is a powerful scripting language which runs on the Java Virtual Machine. Across theTemenos Journey Manager platform, Groovy is used to create services in Manager. These services are primarily used to create plug-in style systems that interact with Manager. actions and expiry services to implement customer requirements. You can view all actions associated with the collaboration job. A Action can have one or more action properties.

An action can be assigned to a different user. However, more often a single user is assigned to work on several actions. To achieve a seamless transition between the actions, the "redirectNext": true property is used to show next action to the same user upon the completion of the previous action.

An action can be anonymous. In this case, you should set the "name": "Task Type", "value": "Anonymous" property.

• In Progress - the action is active and in progress. The action will be retried (looping), if needed.
• Completed - the action has been completed.
• Expired - the action is expired when a step is automatically expired by the system. Any actions that are In Progress (Pending, Assigned, Invoked, Ready or In Progress) will be marked as Expired. This include action associated with tasks that are in the Assigned state or job actions that are in the Invoked state awaiting a callback from a 3rd party system.
• Cancelled - the action is manually canceled by an administrator, who cancelled a job or transaction, or a user, who clicked cancel on a form task.
• Error - the action has a critical or unrecoverable error and requires an operator's or administrator's intervention before it can be run again.
• Invoked - the action that is a part of an Asynchronous execution where you have a Job Action and a Job Action Wait pair. The Job Actions processing (invoking a 3rd party service) has completed successfully, so it is awaiting a callback from a 3rd party system and, therefore, it can move to the completed status.
• Pending - or paused, the action is waiting for an external event to move it forward.
• Assigned - the Job Task Assign Action process has successfully created and assigned a task to a user, group or email (anonymous). The task is awaiting user submission to be completed which then executes a callback on the collaboration job.
• Ready - the action will be executed next time the scheduled job runs.

Manager allows you to use various actions, such as a simple, auto retry, or wait actions, that are processed differently.

Simple Actions

A job controller processes a simple action as described below:

Normal Case

An action service completes an action and sets the its status as Completed. Then, a job controller proceeds to the next action or a step.

Error Case

An action service may stop processing an action, depending on errors:

• Transient Errors - the errors that can be retried automatically, for example, in case a web service is down, by configuring the retry time interval of action services.
• Hard Errors - the errors that can't be fixed by retrying, for example, a bug in the source code. In this case, you may want to stop a collaboration job until the error is fixed and then run the collaboration job manually.

Polling Case

An action service can implement polling or looping logic to check if a certain event has occurred, for example, whether a receipt has been generated. If the event has occurred, the service sets the action status as Completed and the job controller proceeds to the next action or step. If the event has not occurred, the service sets the action status as In Progress.

Expiry Case

You can configure an action to expire by setting an expiry time, so the action status will be set as Expired. You can also configure a step to expire.

Auto Retry Actions

An action with the Error or In Progress statuses can implement the retry (looping) behavior, when it is retried each time a job controller service runs. By default, the job controller service tries to retry an action after a five minute delay, but you can change it by updating the actionRetryDelayMins service parameter. To illustrate it with an example, let's assume your action calls a web service. If the web service is down for a couple of minutes, the action instance status will be set as Error and the next time the action will be run is set as the current time plus 5 minutes. The next time your action is executed, the web service is running, so the action completes and its status is set as Completed. This concludes the life cycle of your action.

You can always write a custom job action in Groovy script to specify the next time it runs.

Wait Actions

A wait action implements a callback to handle asynchronous events, such as a user completing a task. A Job Task Wait Action service is paired with a single step having one or more Job Task Assign Action. The Job Task Assign Action creates a task and assigns it to a user or a group. The user completes the task by submitting it, which could be within hours, days or even weeks after the task was assigned. The submission triggers a callback, which enables the collaboration job to complete.

The examples below show how to use different actions within various steps.

Example 1 - Task Step - Standard Mode Processing

The state changes associated with the actions in a task step are illustrated in the diagram below.

Job Thread 1

1. Runs the Job Task Assign action immediately.
2. Creates and assigns the task submission.
3. Links the task submission to the action instance.
4. Sets the Task Assign Action status to Assigned.
5. Runs the Task Wait processing. As the Action 1 task isn't complete the Action Status of the Task Wait to Pending and Job Thread 1 terminates. No processing is done on the collaboration job where the current action is in Pending status.

Assigns User Action 1 - Task Submission Thread

1. It generates a callback.
2. Changes the Task Assign action status from Assigned to Completed.
3. Changes the Task Wait action status from Pending to Ready.
4. As a result, the Task Wait is now available for processing.

Job Thread 2

1. Completes the Task Wait processing.
2. Changes the Task Wait status to Completed.
3. Completes the application review step.
4. Routes to the next step to be processed.

Example 2 - Multiple Tasks Step - Standard Mode Processing

The Job Task Wait Action service can wait on more than one Job Task Assign action services to complete. The diagram below shows a step with three assigned tasks that run in parallel. This can be created using the same form assigned to different users or groups.

Job Thread 1

1. Creates all of the action instances and the 3 associated tasks are created and are given an action status of Assigned.
2. Stops when it gets to the Task Wait and sets the status to Pending.

Assigned User Action 1 - Task Submission Thread

1. Callback triggered that changes the Action 1 status to Completed and Changes the Task Wait status to Ready

Job Thread 2

1. The Task Wait Processing is run which check to check whether Tasks Complete or not.
2. If complete, the Task Wait action status is set to Completed. The step is completed and processing the next step is done.
3. If not complete, the Task Wait action status is set to Pending.

Example 3 - Form Bundle - Process Immediate Mode

Form bundles can create multiple Task Assign action instances that are assigned back to the original submitter.

User Thread 1 - User Submits Initial Form

1. Creates all of the action instances and the 3 associated tasks are created and assigned to the same user, they are given an action status of Assigned.
2. Stops when it gets to the Task Wait and sets the status to Pending.

User Thread 2 - Same User Submits Credit Card:

1. Callback triggered that changes the Action 1 status to Completed and Changes the Task Wait status to Ready
2. Immediately Runs Task Wait processing is run which check to see Are Tasks Complete:
3. No: The action status for the Task Wait is set to Pending.
4. Yes: The action status for the Task Wait is set to Completed. The step is completed and processing the next step starts.

Actions can assign a group to a collaboration job. The example below shows how to assign the Job Reviewers group to a collaboration job.

"actions": [
    {
        "name": "Create Task",
        "type": "Job Task Assign",
        "properties": [
            ...
            { "name": "Task Assign Group",  "value": "Job Reviewers" },
            ...
        ]
    }
]

Next, learn how to view collaboration job steps.