A member on the Automate Forums recently asked a question about how to have user input drive the starting of other tasks. After some thought, I realized that the solution to this problem provided an excellent example of how Automate BPA Server’s workflow capabilities not only provide an easy way to accomplish such tasks, but separates the logic of such decisions into a clear and easily understandable process.
The Problem
The goal was to create a task that gave a user a choice within a dialog, and using that choice, trigger (or start) another task. In Automate 6, this can be accomplished by using one of Automate’s dialog steps (for example, a Message Box), choosing “Start Another Task” option in the Buttons tab, and pointing to the desired managed task. Another way is to set a variable based on the dialog choice, and that value could be evaluated using an IF block that used Start Another Task or Trigger Task steps. Automate BPA Server, however, does not have the concept of starting or triggering another task from the agent that the task is running on because all task objects are stored on the server. This means there is no direct access to the steps of another task. What is necessary is a slightly different way of looking at task flow and execution from a single task perspective into a multiple task one.
The Solution
Automate BPA Server’s workflows provide an excellent way to accomplish such things. The pattern is to create a task that gathers the information necessary to figure out what the user wants to do on the agent, then hand-off the actual processing of this choice at the workflow level.
Sharing Information
Much like Automate 6, variables are a big part of creating robust and “intelligent” tasks that can make decisions. But in Automate BPA Server, variables take on a much larger role when used as “Shared Variables”. These variables are declared at the workflow level, and tell the workflow to track and share the contents of the variable between all objects in the workflow. This means you can create and alter a variable in Task A running on Agent A, and if it’s declared as a Shared Variable, the variable’s values can be accessed and altered in Task B running on any agent in the same workflow. We’ll use this capability to alter the path of our workflow and to start different tasks.
Creating the “Task Launcher” Workflow
For the purposes of this example, we’re going to assume that we’ve already broken down our overall work processes into three tasks: Task A, Task B and Task C. We also have another task, Task D, that we use for error purposes. We’ll tie all this together in a new workflow. Start by creating a new workflow in the SMC and call it “Task Launcher”. Click Edit to open the Workflow Designer. Here is where we will create our new Automate BPA Workflow.
Once we’re done, the workflow will contain five tasks (four of which are our “process” tasks we made before), a task to allow the user to choose a process, an evaluation object, and the proper links to tie them all together.
Creating the “Pick A Process” task
First we need to create the “Pick A Process” task. Drag a new Task object from the Objects section of the Workflow Designer onto the workflow area to the left. Click Rename from the toolbar and call the task “Pick A Process”. Then double click the task to open the Task Builder.
The task’s job is simply to present the user with a dialog asking which process they’d like to run (with each choice corresponding to Task A, B or C). The choice is stored in a variable called UserChoice. We can easily accomplish this with two steps:
- Create Variable step set to use the name UserChoice, and with the “Treat As Parameter” Advanced option set
- Choice Dialog action with the name of each process (each one number 1, 2 or 3 respectively) and set to populate variable UserChoice.
You may be thinking “Why use the ‘Treat As Parameter’ option”? Setting this value tells the task to not fail if the variable has already been created. This becomes important when we get to the usage of the Shared Variables.
Click “Update And Close” to save the changes to the server and return to the Workflow Designer.
Adding the Shared Variable
Now that we’ve created the task that is going to create and populate the UserChoice variable, we need to inform the workflow that we want this variable to be accessible to the entire workflow and all the objects contained within it. To do so, click the Shared Variables tab of the Debug Windows near the bottom of the Workflow Designer, right-click and choose Add (Figure 1). Type in “UserChoice” and click OK. Now we can reference this variable throughout the workflow, and all tasks in the workflow can access and alter the variable. We’re going to take advantage of this capability by evaluating the contents of the variable once it is returned from the “Pick A Process” task.
Drag an “Evaluation” object onto the workspace to the right of the “Pick A Process” object. Single-click the “Pick A Process” object and drag the green Success arrow onto the Evaluation object, linking them together. Next, double-click the Evaluation object.
The Evaluation object is a powerful component of any workflow, since it allows the progression of the workflow to change based on the results of an expression or variable value. The object works a lot like the IF action in the Task Builder. For our purposes here, we’re only interested in the value of the UserChoice variable, so choose the “Value” option and enter “UserChoice” into the dialog.
Assigning Results
Now is the time to make the Evaluation object do something. If the Workflow Designer’s Repository window is not already open, open it now by clicking the Repository button. Expand the Tasks section to reveal Task A, B, C and D. Drag each one from the repository onto the workspace to the right of the Evaluation object, leaving enough space to make links between the evaluation object and each Task object.
Next, drag a Result arrow from the Objects section to the right of the Evaluation object. Drag the left-hand side of the arrow to the Evaluation object until it connects. Drag the right-hand side of the arrow to the Task A object until it connects. Then, double-click the link to set its properties. We want to tell the workflow that this link should be followed only if the result of the evaluation object is the value 1. Therefore, choose the “Value” option and enter the number 1. Repeat this process for the other two Tasks, changing the value to 2 and 3 for each respective link. At this point, you should have something that looks like Figure 2.
Running the Workflow
Click the Run button and watch it go to town.
What exactly is happening here? First, any variables that have been declared as “shared” in the workflow are allocated and set to their initial values. Then, the workflow starts the “Pick A Process” task on the specified agent. The task executes, displaying the dialog asking the user to choose a process. Once the user selects an option, the task step updates the UserChoice variable with the new value. The task ends, and the shared variable is harvested from the agent and put back into the workflow. The workflow then executes the Evaluation object, which returns the value chosen by the user (for example, if the user chose Task B, then the value would be 2). The workflow goes through all of the Result links, and follows each link that has a result of 2.
Benefits
Because the progression of the workflow has been separated from the task, the workflow allows a lot of other capability not available in a traditional Automate task. For example, Task A, B or C could be set to run on different agents than the one that “Pick A Process” ran on. Or, by creating additional Shared Variables the Evaluation object can handle a more complicated expression to decide which, if any, of the tasks should be executed. You can even add a “Default’ result link to run a different task if the user choice falls outside of an expected range. And, of course, because this is a workflow, the end-points of the result links don’t necessarily have to be tasks at all; they can also be Conditions or secondary Evaluation objects.
Conclusion
The ability to use shared variables within an Automate workflow provides an abundance of new functionality to take tasks that were once limited to one monolithic process running on one machine to a fully integrated but decoupled, multi-machine environment. In addition, it provides a high-level view of an entire process, instead of being mired in the specifics of code. Using these concepts to allow user interaction to dictate the flow of a workflow process is but one example of the superior functionality that Automate BPA workflows provide.
Applies to: Automate BPA Server 7
