A few best practices to keep in mind
If you’re not using PMG Data Workflows by now, what are you waiting for? Data Workflows, a.k.a. InProc Workflows, bring tremendous power to your solutions.
InProc workflows make it easier than ever to access the capabilities of the Workflow Engine anywhere in the Platform – another way PMG delivers “Workflow Anywhere”. That includes app pages, forms, reports, and workflow APIs.
By design, Data Workflows run quickly and return a result in real-time. And while that opens up all kinds of possibilities for your solution, it also means there are certain considerations you need to… consider… when using and configuring them.
Design decisions that you normally wouldn’t think twice about for a traditional workflow should be rethought when building a Data Workflow. And, there are best practices you want to follow when configuring them in order to maximize speed.
First, and perhaps most obvious: Because Data Workflows are meant to be FAST, they should not contain actions that can wait an indefinite amount of time. So generally speaking, you don’t want to use these actions in your InProc Workflow:
-
-
- Human Actions (Approval, Task, Choice)
- Wait for Message
- Timer
- Call Workflow
- Synchronize Gate
- Parallel Iteration
- Wait for Database Value
- Wait for Email
- OLA and SLA
-
Second: As with most things in life, sometimes exceptions need to be made. For example, if you absolutely must have some kind of delay in a Data Workflow, use a Delay action as opposed to the traditional Timer.
The Delay action is the replacement for the Timer action in InProc workflows. It can delay for up to 60 seconds, which is the max you would want to delay the output result.
Third, and sort of another exception: If you need to invoke other workflows, use the Run Workflow action or a Workflow Function instead of the Call Workflow action.
Run Workflow is like Call Workflow in that you can select a workflow to run, but it gives you the option to configure how it will run – InProc or in the Workflow Engine per usual. As with any subworkflow setup, you can configure a setting for whether or not the parent workflow will wait for it.
Fourth: We’ve talked about Workflow Functions previously. They’re workflows exposed in the Designer as actions, with configurable input and output parameters. Similarly to the Run Workflow action, Workflow Functions can be set to run InProc for blazing fast results. (Of course, they’ll still need to be configured first on the Workflow Function page.)
So, there you go with some best practices for using Data/InProc Workflows. Hang tight for Part 2 of InProc Workflow Tips, coming soon to a theatre newsletter near you!
