/
Appendix 3 - Task Workflow Agents

Appendix 3 - Task Workflow Agents

Task workflows execute system housekeeping tasks such as removing files or cleaning up database tables. The Task Workflow agents are:

Data Hub Task Agent

The Data Hub Task agent is explained in detail in Data Hub Task Agent.

Data Veracity Task Agent

The Data Veracity Task Agent is explained in detail in Data Veracity Task Agent.

Python Task Agent

The Python Task Agent runs Python scripts and is configured in two tabs – General where the code is entered and MIM where MIM values can be freely assigned. 

General

The Python collection agent configuration - General tab

In the General tab, you enter the selected code string that needs to be executed in a task workflow. You can Validate the input code and confirm your choice by clicking on the OK button.

Setting

Description

Setting

Description

Code Area

This is the text area where you enter your code, see https://infozone.atlassian.net/wiki/x/31D8F for further information. Entered code is color-coded depending on the code type and a pop up menu is available for input assistance. Below the text area, there are line, column, and position indicators, see https://infozone.atlassian.net/wiki/x/H9D9F.

Interpreter

Select which https://infozone.atlassian.net/wiki/x/LtD8F you want to use. If no selection is made the interpreter that has been set as default in the https://infozone.atlassian.net/wiki/x/yzX9F will be used.

MIM

The MIM tab of the Python Task Agent

You can assign MIM values and edit entries using the Add, Edit, Remove, Up, and Down buttons. When you click on the Add button the Add MIM dialog box will open and you can insert the relevant MIM values. 

The Add MIM dialog box

Setting

Description

Setting

Description

Assigned

Select the target assignee to which the MIM will be bound. 

Name

Enter the name of the MIM value

Type

Select the data type, you can choose from the following supported data types: any, boolean, date, double, int, long, and string. 

SQL Agent

The SQL agent executes an SQL statement or script in the database specified by a database profile.

image-20260130-015303.png
SQL agent configuration - single SQL statement
image-20260130-015419.png
SQL agent configuration - multiple SQL statements
image-20260130-015548.png
SQL agent configuration - SQLSCRIPT

 

Setting

Description

Setting

Description

Database

Click Browse... to select a Database profile.

For further information about how to configure a Database profile, see Database Profile.

SQL Statement

Enter a PL/SQL script or SQL statements.

Note!

Multiple SQL statements must be separated by semicolon (;). For a single SQL statement omit the semicolon (;) at the end.

For Oracle and SAP HANA database, multiple SQL statements must be grouped within a block, separated by semicolon (;).

Refer to your respective database documentation for information on support of multiple SQL statements.

Script Agent

This agent runs a shell script or other executable located on the filesystem of an EC. The workflow will stop when it receives an exit code from the script. If the script returns a non-zero exit code, the workflow will abort. Output to stdout will appear in the debug output from the agent.

Warning!

It is strongly recommended that you run script task workflows on a separate EC. Running script task workflows on the same EC as other workflows may cause unpredictable errors and loss of data.

During a short time before exec() runs the actual script, fork() allocates the same amount of memory for the script as used for the EC. If the memory is not available, the EC will abort with an out-of-memory error and must then be restarted.

Script agent configuration

Setting

Description

Setting

Description

Script Name

Enter the absolute path and name of the script file or executable that will perform the task.

You may omit the path if it is not required by the shell. For instance, to remove files or directories you can simply enter rm or rmdir.

Parameters

Enter the arguments and options expected by the script. The value will be passed as-is to the shell, except for carriage return characters, which will be handled as a blank spaces.

To call the script without options parameters, leave this field blank.

Unit Test Runner Agent

This task agent executes unit tests. You can customize the queries and define the exact location where the reports are saved. 

unit test runner.png
Unit Test Runner Agent configuration

Setting

Description

Setting

Description

Test Discovery Settings

Workflow Package

This is an optional field where you can select a workflow package to run unit tests from.

Query

Enter the unit test run query

All

Select this option to enter "all" into the query field.

Add folder...

Select this option to enter the add folder code into the query field.

Add name...

Select this option to enter a unit test.

Report Settings

Report

Enter the target directory where the reports will be saved.

Interpreter Settings

Profile

Select the Interpreter profile.

Migrate Sessions Agent

This task agent allows you to convert an existing Aggregation Profile that stores session data in the database from Binary to JSON format without data loss.

The JSON format offers better readability, easier debugging, and allows direct querying of session data in the database.

MigrateSessionsAgentConfig.png

Note!

This migration is currently supports only for SAP HANA databases.

Note!

Before using the Migrate Sessions agent, ensure the following:

  • The aggregation profile uses SQL storage with the Binary (BLOB) session field type.

  • The database is SAP HANA.

  • No workflows are actively using the aggregation profile during migration.

  • You have a recent backup of your database.

Setting

Description

Setting

Description

Name

The name of the Migrate Sessions agent.

Aggregation Profile

Select the Aggregation Profile you want to migrate. Only profiles that meet all prerequisites (SQL storage, Binary format, SAP HANA) are accepted. If a profile does not qualify, a validation error is shown.

Dry Run

Enable this checkbox to perform a test run before the actual migration. A dry run estimates how long the migration will take without making any changes to your data. This is recommended before running the full migration, especially for large tables.

Sample Size

When Dry Run is enabled, this field controls how many rows are sampled for the time estimation. The default is 1000 rows. A larger sample gives a more accurate estimate but takes longer.

Running a Dry Run

To run a dry run.

  1. In the agent configuration, select the Aggregation Profile to be migrated.

  2. Check the Dry Run checkbox. The info panel shows the dry run process.

    DryRunProcess.png

  3. Set the desired Sample Size (default: 1000).

  4. Save and click Run to execute the task workflow. Check the Enable Debug checkbox, and select the Migrate Sessions agent in a debug panel. Click Start.

  5. After the dry run completes, the dry run result task report in the debug panel includes:

    • Total rows in the table.

      TotalRowsinTable.png

    • Size statistics — The average Binary (BLOB) size versus the JSON size per row.

      DryRunSizeStatistics.png

    • Timing statistics — The average time per row for reading, deserialization, serialization, and database writes.

      DryRunTimingStatistics.png

    • Estimated total migration time broken down by the phases.

      DryRunEstimated Total Migration Time.png

Use these results to plan when to schedule the full migration. No changes are made to the original table during a dry run.

DryRunResult.png

Running the full migration

Once you are satisfied with the dry run results, you can run the full migration.

Note!

Before running the full migration, ensure that there is sufficient storage space to store the migrated data in JSON. Performing a dry run will give an estimate of the average session size.

  1. In the agent configuration, uncheck the Dry Run checkbox. The info panel shows the migration process.

    MigrationProcess.png

  2. Save and execute the task workflow.

Important!

The profile is locked during migration to prevent concurrent access. Other workflows using this profile will not be able to run until the migration completes.

  1. The migration runs in three phases:

    1. Phase 1 — A temporary Session_Json column (CLOB) is added to the table.

    2. Phase 2 — Each row is read, the binary session data is converted to JSON, and the result is written to the new column. This is done in batches of 1000 rows with progress reporting.

    3. Phase 3 — The original Session column is renamed to Binary_Session (kept as a backup), and the Session_Json column is renamed to Session.

    After all phases complete successfully, the aggregation profile's Session Field Type is automatically updated from Binary to JSON.

  2. Once the migration completes:

    FullMigrationResult.png

    • The Aggregation Profile now uses JSON session field type. You can verify this in the profile's Storage tab under Session Field Type.

      MigratedAggregationProfile.png

    • The original binary data is preserved in the Binary_Session column as a backup.

    • All workflows using this profile will now read and write session data in JSON format.

    • No workflow configuration changes are needed. The format switch is handled automatically.