Overview

Documentation

Description

This module contains an action to register and execute follow up microflows. These microflows start whenever the creating microflow cascade is terminated. The FollowUp Microflow will run in system context and in it's own transaction. The transaction of the generating microflow is finished when the follow up microflow starts.

Typical usage scenario

• Running a Microflow after another execution to make sure the transaction of the calling microflow is already finished. (For example if events in systems like Kafka need to be created but you need to make sure that all the data is already in the database.
• Creating recursive batch processing logic where each batch has it’s own transaction.

Features and limitations

• Register a microflow that runs after the current execution.
• Pass an object to this microflow
• Create a log for this execution (can be toggled on and off)
• If log is existing, it can be reexecuted from the overview if there was an error.
• define timeout. If this time is exceeded before the calling microflow terminates, follow up microflow will not be executed and the system will throw an exception (This will not interrupt the calling microflow, if logging was enabled, the execution can be manually triggered from the overview.).

Configuration

You don’t need to configure this module, but you can adjust the size of the used threadpool by changing some constants. The constants are:

• ThreadPoolCorePoolSize – Define an amount of threads that should be kept in the threadpool. These threads will never be destroyed. By default, this is set to 0.
• ThreadPoolLimit – Define a maximum amount of threads. If more jobs are added to the threadpool, they will be queued and are waiting for an available thread. By default, this is set to 0 which means unlimited. Limit the number of threads to have full controll over the performance of your application.