OL Connect 2022.1 extends the runtime parameters functionality to Workflow subprocesses, as well as to the DataMapper’s conditions and loops. These new features will reduce the number of tasks and scripts you have to write to access information provided by other modules.

DataMapper changes

Runtime parameters were already available in the DataMapper. They allow the data mapping configuration to specify which values it expects to receive – in addition to the data – from any application that calls the DataMapper. However, whenever you wanted to use these runtime parameters inside conditions or loops, you had to resort to using JavaScript:

Now, in both the Condition and the Repeat steps, the Based on list allows you to pick any of the defined runtime parameters without having to use JavaScript:

Of course, you can still access the parameters via JavaScript if you want to perform some additional processing, but in most cases, just picking their name from the list will do the job. This simple change will reduce the number of scripts in your data mapping config and make maintenance that much easier.

Workflow subprocesses

The most significant improvement for Runtime Parameters is found in a Workflow process’s ability to pass them to a subprocess. Let’s imagine a process that receives an AJAX request and, based on its parameters, calls one of two subprocesses. The subprocesses use information from the original request in order to produce some JSON output that will then be returned to the calling application.

Each subprocess defines a couple of local variables. Starting with OL Connect 2022.1, these local variables become the runtime parameters in which the calling process can store dynamic values before it calls the subprocess. By default, the default value defined for each variable in its corresponding subprocess is used:

But of course, you can assign any variable value to the runtime parameter, effectively replacing the default value with one of your own choosing:

In the past, you would have had to store your values in JobInfos prior to calling the subprocess. But you’d probably have to first open up the subprocess to be reminded of which value is expected to be stored in which Jobinfo. And then in the subprocess, you would have had to store those JobInfos into the subprocess’s local variables.

And you would have to go through those steps every time you called a subprocess. Making one simple mistake in any of the calling processes (i.e. storing the values in an incorrect JobInfo) could lead to very hard to find bugs.

This very simple change to the Gosub task’s user interface makes it much easier to work with subprocesses and eliminates all those error-prone extra steps.