Execution Settings

Select Enable to enable setup of the execution parameters.

Distribution

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

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.

Machine Load - Starts the workflow on the EC group with the lowest machine load. 

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.

Debug Type

Select Event to enable debug output, such as 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 Event Notifications(3.3).

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.

Throughput Calculation

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.

Execution Settings

Select Enable to enable setup of the execution parameters.

Distribution

A workflow executes on an EC group. You can specify these EC groups, or the 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.

Execution Context Type

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

The following options exist:

Normal - 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 the system will consider all available ECs as possible targets.

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

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

Queue Size

The number of unprocessed entries (backlog) that the workflow can store in a buffer before the collector is slowed down. The workflow and its back-end systems might slow its processing activity when the number of requests rises. To avoid congestion, while the records or decoding tasks are in the queue, the queue intake is delayed to limit the backlog from growing too fast. Default value is 1000.

The value that you enter here is the size of each route's queue in the workflow.

Queue Strategy

Blocking queue

This is the default method.

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

Queue Worker Strategy

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

Threads

The number of workflow threads. The default value is 8.

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

Processed UDRs Count Interval (min)

Select this option to specify the interval period in minutes for counting the number of processed UDRs. The default value is 1. The maximum value permitted is 1440 min (one day).