Table-Driven Workflow Instancing

The Workflow Table can be used to instantiate multiple workflows interfacing similar sources and targets. Although almost every configuration aspect can be parameterized, the start/end-point identifiers (e.g. IP addresses, directories, login, passwords, etc.) are normally the most important.

The example in the figure shows the Workflow Table tab in the Workflow Properties, where additional instances of the template workflow can be added. The parameters that are going to be available in the Workflow Table are configured in this tab as follows:

• Configuration parameters denoted as final are not shown in the Workflow Table and the final values from the template workflow are used in all workflow instances.

• Configuration parameters denoted as default are shown in the Workflow Table and have the value from the template workflow set as default.

• Configuration parameters denoted as per workflow are shown in the Workflow Table and are not set and should be set manually for each workflow.

Using the Workflow Table tab to add workflow instances

Workflow Execution Scheduling

MediationZone provides support for manual, real-time and scheduled execution of any kind of workflow group holding processing functions (i.e. collection, processing, distribution, or any combination thereof):

• To perform a manual execution, a group is executed through the Execution Manager.

• Real-time workflows are always active after they have been activated. If such a workflow terminates, it can either be manually re-activated, it can be re-activated by the scheduler or it can stay in state abort.

• For scheduled execution of groups, the frequency of collection and delivery of information can be configured based on a period schedule (e.g. collect all files from a certain directory every 15 min). This schedule is based on day plans and can be configured to run every day, a specific weekday or a specific day of the month. On each day the activity can be specified to run only once or periodically at different intervals between different times.   

Execution scheduling GUI

Workflow Execution

The Execution Manager provides a graphical interface to manage the execution of workflow groups and the monitoring of their status and schedule. It also provides views of running workflows and detailed views of the contents of the workflow groups including throughput and other statistics.

Below is an example of the Execution Manager, showing a number of workflow groups and their current status and scheduling.

Example of workflow group scheduling info in Execution Manager

Workflow Execution Suspension

A Suspend Execution configuration enables you to apply a restriction that prevents specific workflows and/or workflow groups from running in a specific period of time.

In the example below, five workflows are grouped. Note that these are not workflow groups used for defining prerequisites or execution criteria, but rather groups only for the purpose of disabling and enabling at certain points in time.

Grouped workflows to be suspended

The selected workflows are configured to be disabled over a weekend with a scheduled disabling and enabling of groups. This can be useful to disable workflows ahead of time when maintenance windows are planned.

Execution of workflows has been disabled for period of time

Shared In-Memory Table Lookup during Workflow Execution

During execution of business logic, many workflows are dependent on retrieving data from a persisted storage, such as a database, by looking up data in own in-memory table. Each workflow instance will load/release its own lookup table during a workflow startup/shutdown. Therefore in the case of execution of many workflow instances, multiple loads/releases of the table will occur with unnecessarily high memory consumption.

An alternative is to create a shared in-memory lookup table that is loaded and used by several workflows within same Execution Context as illustrated in the figure below.  

Shared in-memory table lookup

Error Handling

Many types of error handling can be implemented using the workflow properties. Automated re-transmissions can be executed according to the preferred behavior, e.g. make a specified number of retries before aborting the re-transmission attempts as configured in the example below.

All retries will be logged and after the final retry the erroneous file will be sent to the error correction system (ECS) together with the specified file attributes, e.g. timestamp, source file name, etc.  

Configure number of retries before aborting