After I gained a bit of experience with Workflow, I began to attempt to tackle more complex processes. While developing these, I ended up with a sprawling mess of a canvas, duplicate evaluations and actions, and path lines jumping all over the place and each other. It was at that point that another, more experienced Workflow developer showed me the importance of modular processes, how to configure them, when to use them, and the difference between model types.
First helpful rule: if using the “fit to screen” zoom button renders the Workflow tiny and indecipherable, then you could likely benefit from some linked or embedded models. We’ll go over the different types shortly.
Second helpful rule: the easiest way to simplify the sprawl of a workflow is to group components into Embedded Rule Model components. Embedded Rule Models are like using folders to sort a stack of random documents on your desk into a nice, neat filing system.
The Embedded Rule Model
So let’s take a look at some basics. In this example, the components following the form’s Search path can be grouped into an Embedded Rule Model component.
In an even more efficient example below, there are over 80 components being grouped inside Embedded Rule Models, which would have otherwise cluttered the main canvas.
Notice that the “Remove Item” component is not inside an embedded model – this component does not seem to work as expected while inside an embedded rule model.
Embedded Rule Model component notes, for consideration:
- Variables are not confined internally to the model, making input/output mapping unnecessary
- Multiple paths may be configured by creating multiple End components inside the model. The name of the End component will be the name of the external path
- Form Builder components are not allowed inside these models
The Embedded Model
While Embedded Rule Models are great for cleaning our canvas and making the visual flow of things easier to read and work with, one downside to that component is that any variables produced or initialized inside that model will pollute the variable cloud outside the model as well. The Embedded Model allows for output mapping and the variables are quarantined inside. Only variables that are mapped out escape the model. Note that the Embedded Model does not allow for split outcome pathing.
Any values that you want passed out of the Embedded Model component must be added to the “Output Data” configuration (right-click, edit component menu). Afterwards, any variables added to the Output parameters must be mapped inside the model itself at the End components.
The Linked Model
Models are nearly independent entities within a parent Workflow. In any recent versions of Workflow, new projects have a secondary model added by default – “Critical Errors”. Additional models may be added using the “New Model” button and placed in logical hierarchy in the project tree in the left panel. Models added in this fashion may be exported and then imported into other workflow projects, intact. These models may also be invoked directly.
This button will add a new model to your project.
We are able to use these models on our Workflow canvas by using the Linked Model component. For a quick link, simply drag the model from the left panel onto the canvas where you want it. Otherwise, drag a new component from the toolbox, and link the model via the dropdown in the component options.
Input mapping for this component is required for any input variables, but output mapping is optional. Like the Embedded Model component, any defined output values must also be mapped in the End component configurations for any endpoints inside the model.
Because of the input and output mapping capability, this component is useful for repeatable actions such as adding an item to an Altiris filter. We could use a single model for the filter configuration, and reuse that model anywhere an item needed to be added to a filter, whether it was for software delivery, patch management, security policy, etc. Each instance of the Linked Model component can be configured with mapping specific to the circumstances of its parent’s logic model. Any adjustments needed for the filter process could be done in one place, one time.
The Dynamic Linked Model
The Dynamic Linked Model component allows you to configure the Workflow in such a way that, given data for evaluation, this component will determine dynamically which model to load. This can be very useful for projects that give a user a catalog of choices, for example, and based on the selection, we can use this component to load the model that was selected, all using just one evaluation component.
This component requires a model be selected as a template. What this means is that the input/output data configuration will need to match that template model’s configuration in order to be used by the component.
Hopefully this will help a bit with designing efficient and readable Workflows. I’m certain that at some point, someone has had to come in behind me and either make adjustment to (at best) or completely gut workflows I’ve created, and thought, wow, what was this guy thinking? That is to say, even if you’re personally able to follow and read your workflow, someone else may have a horrible time of it if it’s a sprawling disaster like my first ones were.
The input/output mapping requirements are the same as the Linked Modelcomponent’s, above.