Page Comparison

A workflow executes on an EC, or groups of ECs. You can specify these ECs, or the system can select them automatically.

The following options exist:

Sequential - Valid only if ECs are defined. Starts the workflow on the first EC/EC group in the list. If this EC/EC group is not available, it proceeds with the next in line.

Workflow Count - Starts the workflow on the EC running the fewest number of workflows. If the Execution Contexts list contains at least one entry, only this/these ECs/EC groups will be considered.

Machine Load - Starts the workflow on the EC with the lowest machine load. If the Execution Contexts list contains at least one entry, only this/these ECs/EC groups will be considered. Which EC to select is based on information from the System Statistics sub-system.

Round Robin - Starts the workflow on the available ECs/EC groups in turn, but not necessarily in a sequential order. If ec1, ec2 and ec3 are defined, the workflow may first attempt to start on ec2. The next time it may start on ec3 and then finally on ec1. This order is then repeated. If an EC is unavailable, the workflow will be started on any other available EC.

Select an execution context type that the workflow should execute on.

The following options exist:

EC - This setting enables execution of the workflow on one or more ECs. If several ECs/EC groups are added to the Execution Contexts list, the selected Distribution is considered. If no EC/EC group is selected will consider all available ECs as possible targets.

ECSA - This setting enables execution of a stand-alone workflow that is independent of the Platform.

When ECSA is selected you must configure the workflow to execute on a specific ECSA/ECSA group.

To add an EC/EC group, click Add and select an item in the drop-down list.

Blocking queue

The default method in .

Ordered Routing

To be able to preserve the order of incoming UDRs, this option should be used in combination with Ordered Services in the Service tab.

To maintain the order of the UDRs as the agent sees it from the source, you can use the function ordered routing. This ensures that you retain the routing order, even if the work is divided over several threads. When using this function you must define how to catch the order of the UDRs. This can be done with APL in the Services tab in Workflow Properties.

1. Via the 'input' value, typically by instanceOf checks for each routed type,
2. Use ordered.addInteger(si, i) etc with values from session defining fields. Hashing will select partition. Alternatively use ordered.setPartition(si, N) to explicitly chose a partition.
   void route(order.SessionIdentifier si, any input) {....}

By selecting Queue Worker Strategy, you can determine how the workflow should handle queue selection, which may be useful if you have several different collectors.

You have the following options:

RoundRobin

The RoundRobin strategy works in the same way as the InsertionOrder strategy, except that each workflow thread will be given its own starting position in the routing queue list. This means that as long as the number of workflow threads is equal to, or greater than, the number of routing queues, no queue will suffer from starvation.

Faster routes will get more load than slower ones. This option provides pretty fair distribution.

Use this strategy if the number of workflow threads is equal to, or greater than, the number of routing queues, and it is desirable to prioritize faster routes before slower ones. 

RoundRobin is the default strategy.

DedicatedAndRoundRobin

In the DedicatedAndRoundRobin strategy, each queue has one thread dedicated to it by default. The number of workflow threads (given in the Threads column) minus one, serve the queues in round robin fashion. The number of threads indicates the maximum number of threads that can collect from a queue at any one time. One workflow thread guarantees the order of the UDRs in the workflow.

InsertionOrder

With the InsertionOrder strategy, queues are selected in route insertion order. As long as there are queued UDRs available on the first queue, that queue will be polled. This means that routes with later insertion order may not receive as many UDRs as they have capacity for, and get no or little throughput. This type of condition may be detected by looking at the Queue Throughput for workflows in the System Statistics view.

Only use this strategy, if this is not an issue.

This is the preferred choice when you work synchronously with responses and process small amounts of UDRs at any given time (which is not the same as low throughput).

contains an algorithm to calculate the throughput of a running workflow. It locates the first agent in the workflow configuration that delivers UDRs, usually the decoder and counts the number of passed UDRs per second. If no UDRs are passing through the workflow, the first agent delivering raw data will be used. The statistics can be viewed in the System Statistics.

If a MIM value other than the default is preferred for calculating the throughput the User Defined check box is selected. From the browser button a MIM Browser dialog is opened and available MIM values for the workflow configuration is shown and a new calculation point can be selected.

Since the MIM value shall represent the amount of data entered into the workflow since the start (for batch workflows from the start of the current transaction) the MIM value must be of a dynamic numeric type, as it will change as the workflow is running.