Process Actions in the Universal GUI related to navigating through screens don't perform too well. A user can navigate faster through the GUI manually. One of the reasons for this are the many HTTP calls that are triggered after a Process Action is executed. A bit similar to the concept of Refresh after Execute for Tasks, it would help if there is a setting available for each Process Action in which it can be determined whether or not to immediately perform the next Process Action.
An example:
A Process Flow that performs Open Document > Change Filter > Go to Row should only retrieve the Data after the required (set of) Row(s) is determined with the Go to Row Process Action.
Can something like this be added to the Platform soon?
In our application we use tasks with process flows, which open a certain document. In a lot of cases we have to use a filter action after opening the document to only show the data which is needed. Because these are two different actions, the application has to do a ‘select’ two times. It would be nice if there was a possibilty to directly apply a filter in the open document action, so that there is only one ‘select’ needed. This would help our performance.
We are considering a solution where the runtime would automatically merge subsequent process actions into a single merged follow-up action.
Only actions on the same subject which may affect the current data set in the UI would be merged.
- Open document (only as first-merged action)
- Activate document (only as first-merged action)
- Activate detail (only as first-merged action)
- Zoom detail (only as first-merged action)
- Change filters
- Change prefilters
- Clear filters/restore filters/default prefilters
- Change sort order
- Refresh
- Go to row
- Go to first/previous/next/last row
A process action with a process step towards an action type that is not in the list above will cause the process action to be the last merged process action.
The merged process actions must be a lineair chain. A process action with more than one subsequent step will be the last merged process action.
The steps between merged process actions may only be ‘Always’ or ‘Success’. Since the merged actions is performed as a single action at the same time, the UI will not be able to distinguish between success or failure of individual aspects such as applying sorting, going to a specific page for a row or changing prefilters and will consider them successful for the merged steps. A process action with a subsequent step that is not ‘Always’ will be the last merged process action.
The merging of actions stops when a process action has an output variable mapping - this would be able to affect subsequent action input and as such cannot be merged. The process action with the output variable mapping will be the last merged process action.
The merging of actions stops when there is process logic - this may both affect action input and which steps are executed. The process action with process logic enabled will be the last merged process action.
The output variables are all based on the last merged process action and the success and status code is based on the action as a whole. This means you would not be able to distinguish between the ‘open document’ failing or the ‘go to row’ not being able to find the row.
This solution would automatically work for existing process flows and require no changes by developers as long as the flows follow the rules above.
We’d love to hear all of your input on this.
The merging of actions stops when a process action has an output variable mapping - this would be able to affect subsequent action input and as such cannot be merged. The process action with the output variable mapping will be the last merged process action.
The merging of actions stops when there is process logic - this may both affect action input and which steps are executed. The process action with process logic enabled will be the last merged process action.
We have implemented custom flow monitoring for all of our process flows. To log actions and the current state of process variables we use dynamically assigned process logic. It seems we would have to rework this to make this merging of actions possible even though this monitoring process logic never changes which steps are taken.
Would this merging of process actions still work if we only assigned our monitoring to the last merged process action? If so, we can change our dynamic code to only assign the monitoring to these last merged actions. If not, we would require a substitute for our flow monitoring as described in this idea:
This depends a bit on how intelligent the merging of the process actions will be. If the process actions do not use any input variables that may be modified by the process logic it may still allow merging.
Only applying the logging logic at the last process action is not trivial - you’d need to replicate the algorithm in your own dynamic assignment logic to determine what will and what won’t be merged. It may be easier to simply tag certain process actions to exclude them from receiving monitoring logic. If only the last process action in a merged chain has the monitoring logic it should work out.
First-class logging features of process flows as you pointed out would indeed be the easiest solution.
Hi Arie,
This change will not be bound to a specific Thinkwise Platform release version.
Work has been done, both for Indicium and Universal and significant progress has been made, but since the current focus is on porting existing platform features, we’ve not officially marked this idea as ‘Working on it’ because the horizon for release of this idea is still quite vague.
When we can commit to being able to actually finish up and release this idea, we’ll update the status.