The workflow configuration is a central part of the 
GUI. This is where all workflows are designed and configured by adding agents and connecting them to each other to form a data flow.
The workflow configuration operates in three modes:
Design mode – where workflows are created and configured
Monitor mode – where workflows are started or stopped and the status of its individual agents is monitored
Profiling mode – same as monitor mode but with graphical information on where most of the time is spent in the workflow
A workflow that is fully configured will have access to all modes. This is determined when a workflow is opened and saved. If the workflow is not fully configured or deleted, the Monitor and Profiling modes are disabled.
Workflow Group Configuration
The Workflow Group configuration enables management of workflows.
A workflow group can consist of one or several workflows, each with a diverse setup of scheduling, load balancing, and event notifications. Workflow groups enable you to configure these as a single entity.
Groups are either of type batch or real-time, which means that batch and real-time workflows cannot be mixed in the same group.
The example below shows a workflow group consisting of two batch workflows with a dependency (the first one must finish before the second can start).
A workflow group configuration with three batch workflows
Grouping of workflows can be useful in the following scenarios:
There are dependencies between workflows within one line of business (e.g. collection, processing and forwarding) which can be managed through prerequisites, and the workflows need to be executed in a certain order.
To limit the resource usage when executing groups with multiple workflows in parallel, you can control the maximum number of simultaneously running workflows.
If there is a need to complete all collection before beginning the processing step, this can be achieved by creating a collection group and a processing group that belong to a super group.
To simplify the monitoring as the groups show their status in the Execution Manager.
Runtime Modification of the Workflow Configuration
includes two mechanisms by which an operator can modify a workflow that is already running.
While a workflow is executing, it is possible to change the configuration of certain agents in their respective Configuration tabs which is available in the Monitor mode of the Workflow Designer.
These changes will be automatically sent to the running workflow and provisioned into the agent that is being reconfigured.
In this case, the changes are applied without affecting the execution of the workflow.
The example below shows how this is performed for the TCP/IP Agent of an active Workflow. In this scenario, the IP address used for listening on incoming requests is changed.
Example of runtime update of a TCP/IP agent configuration
Runtime Modification of Workflow State
includes a mechanism through which it is possible – while the workflow is running – to send a signal to an agent to instruct it to perform some action without affecting the active workflow.
The example below shows how this capability is used to instruct an Aggregation agent to execute the instructions within the command block for all sessions that have a timeout condition configured. This can be used, for example, to implement the capability to force a hard-flush of sessions in a Charging Gateway deployment.
Executing command block from monitor mode in the graphical user interface:
Example of runtime modification of a workflow state through the Aggregation agent
A command block can also be executed from the command line interface, by using the wfcommand. This enables the workflow logic to be executed based on input from the Command Line Interface.
Configuration Import and Export
All, or part, of the configuration related to a installation can be managed using the System Export/Import feature.
Exporting configuration objects with this mechanism will create a compressed XML file that contains selected configuration. Exported information can also be protected through a one-way encrypted password.
Using the export and import feature, it is possible to develop and test all functionality on one system, then export it and later import it into another environment. This feature can be combined with the external references feature that allows definition of all configuration parameters in a text file which gives the possibility to use one configuration export file across all environments which all have their individual parameter file.
The following example shows the system import/export sub-system, creating a full configuration export:
Example of full configuration export
In addition to configuration data, the export/import function includes the capability to export runtime data from, for example, ECS and Archive systems.
Parameters are available to the system import command in order to specify system behavior during the import. It is now possible to suppress all workflow scheduling until the import has finished in order, as well as a synchronized restart of all workflows.
Profiles in Workflow Table
The Workflow Table can be configured with:
Manually entered values, e.g. directories, regular expressions, hosts, ports
External References, pointing to values in property files
Configuration profiles selected through the GUI, such as Database, Dup UDR, Aggregation and Inter Workflow profiles, as illustrated below:
Workflow table including selected configuration profiles
Import and Export of Workflow Table
When managing multiple environments (e.g. test, pre-production and production) it can be beneficial to export the different workflow tables to CSV-format. This allows one configuration export to be valid across several environments in combination with importing the appropriate CSV-file containing the specific configuration. Also, when managing many rows in the table, it can be a good idea to import/export the table to a CSV-format (for easy editing in Excel).
External References
External References enable loading with configuration values that originate from a properties file that is external to the workflow configuration.
This allows system administrators to have specific files on test and production servers, and when an export is made from the test deployment, no changes are necessary when deploying the configuration to the production installation.
The example below shows a properties file containing mapping of values and variables used in profiles, APL code and the workflow table.
Properties file containing mapping of values and variables used in
The image below depicts the External References Profile where properties files are selected and the variable names from the file are mapped to internal variable names.
An External References profile example
The local key variables can then be mapped in the workflow instance table by activating External References in the relevant cells.
Workflow table showing External References files usage