Four new workflow features were implemented in version 8.0.0, giving you new ways to build your workflows, with additional new possibilities.
Split bar
This new action bar is like a dummy action. It does not synchronize parallel actions at all. This feature replaces the usage of a DO_NOTHING custom action, for example; it also has a pause feature, like regular synchronization bars. Another purpose of this new split bar is to be the begin block action of an activity block feature, as illustrated below.
To create a split bar, you have to check the following new setting on the synchronization bar:
Once this option is checked, the appearance of the bar will change as follows:
Activity block
This new feature will execute the synchronization only for all the actions within the block. This also helps with regrouping parallel actions.
This new feature was added to resolve cases where multiple levels of synchronization bars would sometimes prevent another synchronization bar from executing because it would detect an ongoing parent action.
Here’s an example of an activity block:
The activity block would be from the split bar to the synchronization bar. To define this activity block, we would need to select the beginning of the activity block on the synchronization bar.
Additional information
-
The start of a block action can be of any type; in this example, we use the new
split barfeature. -
The end of a block action must be a synchronization bar.
Scheduled system action
This new feature can be used to automate some of the system actions in your workflow processes to run at a specific frequency or number of times until a condition is met such as an agent that checks or listens for some data then stops when the data is found.
For example, we can use it with the EXECSQL action that will execute a select query for certain information. Once this information is found, we proceed with the rest of the workflow.
In the following image, while the SELECT 1 FROM USERS query doesn’t return a result, it will loop back onto the select.
New options are added to each system action to control the looping of your action:
-
The first added option is the Delay/Start time:
This lets you control the time between each self-loop of the action. It determines both the start time and the delay at the same time.
-
The second added option is the following:
This option is complementary to the first added option (Delay/Start time). It lets you determine if you want to take the delay into consideration the first time the action is reached.
-
The third added option is the following:
This feature determines if you want to keep each of the loops in the history of the actions. By default, this parameter is unchecked, since this feature can quickly populate the follow-up form with numerous actions.
This feature can be used to test the flow of actions during development, but we recommend leaving it unchecked when the workflow is pushed to production.
Automatic cancellation of timeout system action
Previously, if the WorkflowGen website or engine service stopped, due to a power failure, for example, ongoing system actions would be stuck on a status: Running infinitely. This was also the case for other reasons a system action could not be completed, being stuck on the status: Running infinitely.
This new feature brings new control over these kinds of situations for system actions. Now, when a system action reaches the execution time limit after it was launched, these actions will be cancelled and flagged as an execution error by the system. The default exception can also be triggered.
The default execution time limit is 600 seconds (10 minutes). This can be configured by modifying the value of the EngineServiceSystemActivitiesTimeOut parameter in the web.config file.
Now, when using this new feature and an exception transition, a system action can be automatically relaunched if it reaches the execution time limit, as in the following example:
The EXECSQL system action will be cancelled and relaunched automatically if the execution delay of 10 minutes is reached.
We could also have pointed the transition to a manual action if we wanted to add a type of validation to relaunch the action or close it.