Skip to main content

Per request of @Vincent Doppenberg & Rene Jochem

We’ve build more than a few systemflows to act like if it is a asynchronous processflow. These systemflows will do some stuff when it finds a record in a certain table, for example the recalculation of prices within an (larger) offer, which can take a while to complete due to fetching stuff like current prices from the outside world. The systemflow will scan every 5 seconds to see if there is something it can do and for a very large percentage of its lifespan it will find nothing to do. With enough applications on a server this will cause harsh spikes on them.

What we were and still are looking for are asynchronous process flows, that for example are triggered by the end users push on a button (within the Windows GUI) in which the process flow will act like a systemflow does and needs no more user interaction so that the user can either log out or do something completely different with the application.

rgds Ricky

We have solved this challenge by building a service bus queue. This gives us the possibility to simply queue actions to be executed, the queueing action can be done via any interaction: Handlers, process flow etc.

Our queue has various possibilities build in that allows us to allow parallel processing, limit the amount of threads and in some cases force the queue to be processed as FiFo.

When I say queue it's not a singular queue, every event/trigger/group has its own queue with a global limit of max threads to avoid overwhelming the server.

New→Open
Open→Working on it!

We’ll introduce a checkbox setting on System Sub Flows to allow for asynchronous, user-invoked execution. Note that this feature will come with some remarks: 

  • The user-invoked System Flows will be run in the ‘user’ context instead of the ‘pool user’  context for scheduled System Flows, this impacts the tsf_user function and session variables.
  • The user-invoked System Flows will NOT take into account a disabled Multiple running instances setting, meaning that it is always possible to run multiple at the same time if user-invoked.
  • A-synchronous System Flows will ONLY work in a 3-tier Architecture with Indicium
  • Output cannot be mapped on a parent Process Flow

​@Arie V wrote:

  • The user-invoked System Flows will be run in the ‘user’ context instead of the ‘pool user’  context for scheduled System Flows, this impacts the tsf_user function and session variables.
  • The user-invoked System Flows will NOT take into account the Multiple running instances setting

​@Arie V, so by default it will run in parallel for the application, but sequential for the user? Or all sequential? Care to elaborate on why multiple running instances are not (yet???) supported?

​@Ricky I get the confusion, have updated my original post a little bit. What I was meaning to say is that a scheduled System flow will not start in parallel if the same System flow is still running and the checkbox for Multiple running instances is unchecked. However, for user-invoked (non-scheduled) System Flows this check won't happen and in fact the same System flow can run in parallel if invoked multiple times or if coinciding with a scheduled run of the same System flow.

Developers should be aware of this behavior and make sure that parallel System flow runs won't alter the same data twice. 

​@Arie V many thanks, this is what I was hoping for!

Working on it!→Next release
Terms & ConditionsCookie settings