This is a high level (theoretical) discussion about workflow design. I will create two different how-to posts following this describing how to create workflows that follow this model as well as a post on how to design your environment to support those workflows. So what am I talking about when I say ‘segregation of work’? I am talking about running one set of code (trusted / foundational Opalis code) on a special set of actions servers and all other code on a different set of action servers. Let’s refer to the first set of workflows as ‘Logic Policies’ and the second set as ‘Worker Policies’.
Reasons for Segregation
Resilient Workflow Environment.
- In theory the foundational Opalis objects (Custom Start, Trigger Policy, Publish Policy Data and Links) should never cause unexpected behaviors or affect other policies running on the action server. All other code (including my own) is innately not as safe because it ‘does something’ (Monitor a file, Connect to an external system, etc.). Furthermore, if for some reason an Opalis Policy dies unexpectedly (hopefully this would only ever happen to a ‘worker policies’) the default action is to re-run the Policy. So, we can design our ‘worker policies’ around this. ‘Worker policies’ that modify a system (such as begin a Virtual Machine creation, or add a line to a file) should have detection built into them to see if their ‘action’ succeeded (or still needs to be run), this way when the ‘auto restart’ you will not have duplication. ‘Worker policies’ that simply are collecting information to feed back to the ‘Logic Policy’; because of this they do not need the same ‘action detection’ (in theory it doesn’t matter how many times you collect the data as long as you only return it once).
- The other huge advantage to writing policies this way is that you end up having one set of action servers that runs the ‘long running’ policies and a different set of action servers running the ‘short, do one action’ type policies. This helps us a lot when trying to do maintenance (like pushing out new Integration Packs) because the drain-off will be quicker on your ‘worker’ action servers and this is probably where you’ll be wanting to do the maintenance.
Well Defined Purpose for Policies
- By following this model you come out with a nice model for workflows. You have Logic Policies with logic choices in them calling worker policies which each do one logical unit of work. Additionally, since each ‘worker policy’ is a single logic step, you can run unit tests on them. If each ‘worker policy’ tests correctly then you simply evaluate the logic in the ‘logic policies’ to ensure that the logic is correct.
Contain the logic for a workflow
- If data collection policy returns data point X do Y, if not do Z
- Loop action policy until it returns success
Should only run ‘foundational’ Opalis Objects
- Custom Start
- Trigger Policy
- Publish Policy Data
- When called perform a set of actions that together are classified as a ‘Workflow’
- Can be multi-tiered (Logic policies can call Logic Policies)
Must be tested from a ‘Tester Policy’.
- Create a policy that has a trigger policy that calls the top level orchestration or decision tree policy providing the testing parameters for the custom start
- Turn logging on in all sub-policies
- Start the ‘tester policy’
- When fed the correct input parameters in its custom start it orchestrates a logic workflow by calling other logic policies and worker policies in a set order.
- Used to decide what values to pass to an Orchestration Policy
Should be designed to do one unit of work.
- Build Virtual Machine
- Evaluate A group of disks and return the one with the highest free space
- Refresh a SCCM Client’s local policy and return the status of an advertisement
- If the worker policy modifies something it should first run a detection to see if it has already been run