Advanced Subworkflow Handling

Applies to version: 2021.1.x and above; author: Mike Fitzmaurice

WEBCON BPS offers several ways to handle parallel activity. If the scenario involves a single task assigned to multiple people, a few task configuration settings are all that is needed. But when entire sets of activities, instructions, and decision logic must take place in parallel, subworkflows are necessary.

The vast majority of subworkflow scenarios are easily handled with out-of-the-box functionality, but there are a few situations that have arisen that warrant special coverage – and special treatment.

The Problem

Consider the workflow below. The path named Start executes an automation that starts several subworkflows. The workflow then waits at the Wait until all new sub-workflows are finished step until all workflows end positively, any end negatively, or it is clear that there are no subworkflows to wait for. There are paths to follow for each of these possible outcomes.

In particular, if any subworkflows ended negatively, the workflow will follow the Failure Found path back to the initial step.

This ought to seem familiar to people versed in WEBCON BPS. But even seasoned application builders might not realize two things:

1. If a sub-workflow finishes with a negative outcome, the step immediately moves the workflow along the Any subworkflow finished negative path. By design, it will not wait for any remaining subworkflows that may be still in progress. If the parent workflow needs to gather information from those subworkflows, that could be a problem.

2. If a subworkflow ended negatively, causing the workflow to return to the initial step, a user can again send it along the Start path; doing so will create a new set of subworkflows. Except that when the workflow reaches the Wait until all new sub-workflows are finished step, it will immediately move to the Failure Found path, because there is already a subworkflow that ended negatively.

The step does not differentiate between previously-completed subworkflows and newly-launched subworkflows.

For the majority of workflows, a single set of subworkflows executed once is enough. But for workflows that need to “keep trying until everything succeeds,” or in cases where there are several points at which a set of subworkflows must be created and examined, the default behavior is not enough.

The Solution

Fortunately, WEBCON BPS provides a way to solve this quite readily using a technical field, an automation action, an extra path, and a SQL query.

• Part One: The Technical Field

Create an extra field to be used by the parent workflow of type Date and enable time selection under Advanced configuration.

• Part Two: The Automation Action

You will need to start your subworkflows using one or more Start a subworkflow or Start a subworkflow (SQL) automation actions. Add a Change value of single field action above those actions and have it set the value of the technical field you created in Part One to the built-in NOW function:

You’ll use this technical field to make sure the Wait for sub-workflows step examines only workflows started after this date/time value.

• Part 3: The Extra Path

Create a path that leads from your Wait for sub-workflows step and loops back to that same step. In the illustrations above and below, this path is named Again.

• Part 4: The SQL Query

Finally, in the Wait for sub-workflows step, under Subworkflows settings, choose Advanced settings (instead of Basic Options). In the query editor window, enter the following:

IF EXISTS (SELECT * FROM WFElements WHERE WFD_WFDID = {WFD_ID}

AND WFD_StatusId = 1

AND WFD_TSInsert >= '{custom_datetime_field}')

SELECT {loopback_path}

ELSE IF EXISTS (SELECT * FROM WFElements WHERE WFD_WFDID = {WFD_ID}

AND WFD_StatusId = 3

AND WFD_TSInsert >= '{custom_datetime_field}')

SELECT {failure_path}

ELSE IF EXISTS (SELECT * FROM WFElements WHERE WFD_WFDID = {WFD_ID}

AND WFD_StatusId = 2

AND WFD_TSInsert >= '{custom_datetime_field}')

SELECT {success_path}

ELSE

SELECT {no_subworkflows_path}

{custom_datetime_field} should be replaced with a form field token corresponding to the technical field you created in Part One and populated in Part Two. It should be formatted as ISO (which is the default). You can find that token in the Expression editor’s Values tab.

{loopback_path}, {failure_path}, {success_path}, and {no_subworkflows_path} represent the paths leading away from this step. You can get their tokens from the Expression editor’s Objects tab.

See the illustration below for details:

How it Works

The possible values for WFD_StatusId are 1 for “in progress,” 2 for “ended positively,” and 3 for “ended negatively.” Therefore, the above query reads, in English, as:

1. First, if any subworkfows are (still) in progress, loop back and wait for the next event.
2. Otherwise (since we know nothing is running) if there are any failures, follow the failure path.
3. Otherwise (since we already know nothing is running and nothing failed), if there were any successes, follow the success path.
4. Otherwise, the only option left is that there were never any subworkflows, so follow the no-subworkflows path.

In all cases, the query only examines subworkflows that were started after the date recorded in the technical field created in Part One and populated with a value in Part Two.

The query executes once when the workflow enters the step, and assuming that the loopback logic is there, again each time a subworkflow ends.

The default for this step, Basic Options, has this loopback logic built in. When we use a manual SQL Query, however, we must explicitly loop back to the current step if we find any WFD_StatusId values of 1. If we only checked for WFD_StatusId values of 2 or 3 for, we wouldn’t know whether subworkflows are still running or whether there aren’t any subworkflows – but we’d assume the latter.

In Conclusion

As mentioned before, not every workflow needs to start and manage subworkflows, and even fewer workflows manage multiple sets of subworkflows. But such scenarios do exist, are important, and can be handled by WEBCON BPS using the technique covered in this article.

Incidentally, that WEBCON BPS doesn’t do parallel branching is by design. Other platforms’ implementations of parallel branching logic rarely handle per-path status tracking, permissions, audit trails, subsititutions, etc. – and if they do, their implementations are anything but easy.

A strength of WEBCON is that the platform allows for bypassing these limitations with a little bit of extra work. Because a further strength of WEBCON BPS is that the platform itself is regularly enhanced, this author hopes that this article will one day no longer be needed. In the meantime, this technique works – use it if you need it.