Here you configure how the execution of the workflow is distributed across the available EC groups.

The following options exist:

Sequential - Starts the workflow on the first EC group in the list, if you choose the sequential option and only configure one EC group then the workflow will not run if the EC group is not available. If this EC group is not available, it proceeds with the next in line.

Workflow Count - Starts the workflow on the EC group running with the fewest number of workflows.

Round Robin - Starts the workflow on the available EC groups in turn, but not necessarily in a sequential order. If ecg1, ecg2 and ecg3 are defined, the workflow may first attempt to start on ecg2. The next time it may start on ecg3 and then finally on ecg1. This order is then repeated. If an EC group is not available, the workflow will be started on any of the other listed EC groups.

Select Event to enable debug output (e g output from a debug call in the APL code) to appear in the Workflow Monitor .

Select File to save debug results in $MZ_HOME/tmp/debug. The file name is made up of the names of the workflow template and of the workflow itself, for example: MZ_HOME/tmp/debug/Default.radius_wf.workflow_2. Only debug events are written to the file. To save to file all the events that are shown when you select to monitor events in the Workflow Monitor, you must add an event notifier to the relevant Agent Message Event with file output. For further information, see /wiki/spaces/MD/pages/3218049.

If you save debug results in a file, and you restart the workflow, this file gets overwritten by the debug information that is generated by the second execution. To avoid losing debug data of earlier executions, set Number of Files to Keep to a number that is higher than 0 (zero).

Number of Files to Keep : Enter the number of debug output files that you want to save. When this limit is reached, the oldest file is overwritten. If you set this limit to 0 (zero), the log file is overwritten every time the workflow starts.

Default.radius_wf.workflow_2    (current debug file)
Default.radius_wf.workflow_2.1  (newest rotated file)
Default.radius_wf.workflow_2.2
Default.radius_wf.workflow_2.3
Default.radius_wf.workflow_2.4
Default.radius_wf.workflow_2.5
Default.radius_wf.workflow_2.6
Default.radius_wf.workflow_2.7
Default.radius_wf.workflow_2.8
Default.radius_wf.workflow_2.9
Default.radius_wf.workflow_2.10 (oldest rotated file)

Default.radius_wf.workflow_2
             |
             V
Default.radius_wf.workflow_2.1
             |
             V
Default.radius_wf.workflow_2.2
             |
             V
             :
             :
             |
             V
Default.radius_wf.workflow_2.n
             |
             V
          Deleted

Default.radius_wf.workflow_2.1279102896375
Default.radius_wf.workflow_2.1279102902908
Default.radius_wf.workflow_2.1279102907149

With this drop-down you can select where to store transaction state information. currently only the Default Handler option is available, which means that the transaction data will be stored in the platform database; Derby, Oracle or PostgreSQL.

Throughput Calculation

Usage Engine 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. 

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.

A workflow executes on an EC group. You can specify these EC groups, or the Usage Engine system can select them automatically. 

The following options exist:

Sequential - Starts the workflow on the first EC group in the list. If this EC group is not available, it proceeds with the next in line.

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

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

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

Set the workflow execution type.

You can also create an EC group using the Add button.

Blocking queue

The default method in Usage Engine.

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.

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).

Usage Engine 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.

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.