Configuring Parallel Execution

In Autotest various areas of test cases and the test plan can execute in parallel, or concurrently.

Maximum concurrency is configured in Settings View and configuration is done per group node directly in the Test Plan by selecting a Parallel Mode.

There are three parallel modes available:

• Sequential mode indicates that the children of the node should run on-by-one in sequence.
• Parallel indicates that the immediate children of the node should all run in parallel.
• System Parallel indicates that all children of the node recursively should be executed in individual sequences per system.

Sequential mode

In sequential mode, the nodes execute sequentially in the order they appear in the test plan. This is exactly as the legacy behavior (the behavior prior to OmniFi v7.6). Note that if any higher level of the test plan defines a different parallel mode (Parallel or System Parallel) it is not guaranteed that the sequence will execute alone, just that the nodes of the group will execute one-by-one in order.

In sequential mode the user is in full control over the order of execution. This is useful when you have complicated implicit dependencies, e.g. you enter transactions and perform various operations on them in sequence. The Autotest tasks aren’t explicitly dependent on each other, but the order of the actions they perform in the underlying system is important.

Parallel mode

In parallel mode, all immediate child nodes of the group node are executed in parallel. Any sub-nodes of those immediate children are executed sequentially or according to its own parallel setting.

With Parallel user cannot control the order of execution of the immediate children, but can control the order within the immediate children, which makes Parallel effective when executing many smaller units with no explicit or implicit dependencies.

In a case where we run rate reconciliation where the data source used is database-based we are not particularly concerned with loading the WSS application server, using parallel will provide a very high degree of concurrency.

Parallel mode is also useful in migration scenarios, where there are dependencies between the systems.

System Parallel mode

System Parallel mode is a hybrid between sequential and parallel behavior. The sub-branch of a group node with System Parallel setting is transformed into multiple sequences, one per system, running in parallel to each other.

Unlike Sequential and Parallel, the System Parallel transformation is performed recursively, i.e. it affects all nodes on all levels below the node on which it is applied. This means you can have significant benefits using System Parallel on existing test plans and test cases.

Applying System Parallel on a node such as this:

Produces the same result as applying Parallel and transforming the test case manually:

Note that the order within each system branch is retained. The reports creating import sheets appear before their respective Data Processing tasks in the transformed tree because they appear in that order in the test plan.

The reason we chose to apply System Parallel on the “Trade units” root level instead of the test case level is that System Parallel is more efficient the higher level it is applied to. Intuitively this is because it has access to more tasks to try to schedule in parallel. With System Parallel applied to the “Trade units” root level, the next test case in the “Trade units” group can start to execute while the reconciliation is still running.

If System Parallel was instead applied on the test case level, the entire test case including the reconciliation would have to be finished before the next test case can start.

🚧

Reconciliation tasks don’t use any login and underlying system and can execute in parallel with each other and any other task (to the limit determined by the Settings -> Execution -> Max concurrency setting).

Although the reconciliation in the transformed tree appears to run in parallel with the REF/TARGET tasks, it is reconciling on the output from the Data Processing tasks and will wait for its dependencies to finish before starting to execute.

Explicit dependencies

An explicit dependency is where a task B is configured to use the output of another task A. For task B to start task A must have finished. This type of relationships are always respected by Autotest when executing.

This can be illustrated in an example where we have a test case with four explicit dependencies:

1. *REF – Import Trades uses the output from REF – Create Import Sheet.
2. *TARGET – Import Trades uses the output from TARGET – Create Import Sheet.
3. Reconcile Trades use the output from *REF – Import Trades
4. Reconcile Trades use the output from *TARGET – Import Trades

Explicit dependencies limit the maximum concurrency within a test case; Regardless of the parallel mode applied in the above scenario no more than two tasks can run in parallel.

Test cases with many explicit dependencies parallelization can be optimized automatically. Since the graph of explicit dependencies in the above example includes all tasks, applying Parallel or System Parallel on the test case will result in the exact same execution.

Implicit dependencies

Implicit dependencies are dependencies between tasks that aren’t explicitly described in Autotest, but where the order is relevant for the business logic and the underlying TRM system. An example is entering, moving and expiring a transaction in a series of Data Processing tasks. The various tasks aren’t connected via explicit dependencies, but the order is critical. Implicit dependencies are expressed only as order of tasks in Autotest, and since their relationships are implicit, Autotest execution is not able to optimize the parallelization automatically.

In scenarios with many implicit relationships, consider using System Parallel mode which makes the basic assumption that the order of tasks is important, but only per system.

Combining different parallel settings

A different parallel mode can be set per group node in a tree, with varying effects. The general rule is that you cannot lower concurrency further down in the tree; If the parent group uses the Parallel setting, a child level cannot avoid running in parallel with its siblings.

Concurrency can, however, be increased on a lower level. System Parallel is generally recommended to set on a high level (close to the root) in the tree for maximum effect. System Parallel assumes that tasks should execute in the order they appear, per system. Tasks using the same system but where there aren’t any implicit dependencies can be optimized beyond what System Parallel will do automatically by introducing a Parallel group on a lower level.

In a scenario where you would reconcile migration of static data from one system to another:

System Parallel alone transforms this into two parallel streams, one for each system, followed by all reconciliations running in parallel. The total concurrency exceeds 2x, which although a perfectly decent result, can be improved upon by introducing a parallel group:

With System Parallel transformation, this translates into:

By the introduction of a parallel folder to contain independent tasks the total concurrency has increased from 2-3X to 6-8x.

Viewing actual concurrency

The actual concurrency achieved when running a test case can be limited by several factors, including global concurrency limits and explicit dependencies.

To determine how well this example test case is parallelized:

The Task Log view includes useful statistics:

Duration (Sequential)

This is the sum of all task durations included in the log.

Duration (Parallel)

This is the sum Max(Ended) – Min(Started) for each Execution Id included in the log. Since logs on a group level can contain task logs from different executions this approximates the actual execution time of the test case.

Concurrency

This is the relationship Duration (Sequential) / Duration (Parallel). It approximates the total concurrency and describes how well the test case is parallelized.

If any part of the test case is re-executed, that part did in fact not run in parallel with the original execution, and the Duration (Parallel) and Concurrency fields reflect that.

If for example the TARGET leg and the reconciliation is re-executed, the Concurrency decreases to 1.0 because the TARGET leg was manually executed separately from the REF leg:

Manual task concurrency

In terms of parallelization, manual tasks are somewhat different because they require manual intervention.

Manual tasks are often used as prologue or epilogue to automated sequences. An example of the later is that you must manually push imported static data entities to FINAL in the SDM flow.

Manual tasks in Parallel mode

In parallel mode concurrency is limited by the Max Concurrency and System Concurrency settings. Manual tasks are allocated on a virtual system “NONE” and the concurrency is limited by the System Concurrency setting. For example, with the following configuration, Manual task B can only start after Manual task A has finished if System Concurrency is set to 1:

Setting a system concurrency of 1 averts the risk of having multiple manual tasks popping up at the same time.

Manual tasks in System Parallel mode

In System Parallel mode the sequence within each system is important. A manual task used as a prologue of epilogue to an automated sequence is allocated to the system used of an automated task depending on its relative position within the current folder (group or test case) according to the following rules:

1. Manual tasks inherit the system from the previous task in the same folder. The manual task runs after the previous task in the same folder, which allows the manual task to act as an epilogue to the automated sequence.
2. If there is no previous task in the same folder, manual tasks inherit the system from the next task in the same folder. It runs before the next task in the same folder can start, allowing a manual task to act as a prologue to an automated sequence.
3. If there are only manual tasks in a folder, they run sequentially on the “NONE” system.

📘

Manual tasks can only inherit system from tasks in the same folder. Sub-groups are not expanded to find additional tasks.

Note also that manual tasks can inherit the system from reconciliation tasks. Reconciliations run on individual virtual systems and only depend on the source tasks they reconcile. This allows you to use manual tasks as a prologue or epilogue to a reconciliation, e.g. if you need to manually copy a file for before running the reconciliation.