This is the second part of a four-part series on automating the execution of workflows within Citrix Workflow Studio. In the first blog of the series, I discussed the basics for using Powershell to automate the execution of workflows. In this blog, we will expand on that topic to discuss how we can pass parameters into the workflow, making our workflows much more dynamic and flexible for supporting different types of situations.
Understanding Global Properties
The key to passing parameters into a workflow is to use the global properties of the workflow. You access the global properties within the Citrix Workflow Studio Designer by navigating to Workflow->Manage Global Properties from the file menu (shown below).
The Manage Global Properties dialog allows you to specify the global properties of the workflow. Essentially, all you need to do here is to define the names of the global properties and their property type (String, Boolean, Integer, etc.). I personally like to pre-fix my global properties with the letter “g” to make them easily identifiable when assigning them to activities. You can also optionally define a default value for a global property if you want to.
Then within your workflow, you bind the global properties to the activities within the workflow. When you edit a bindable property for an activity, you’ll get an editor such as is shown below. On the left-hand side, select Global Properties within the drop-down. The global properties should all be listed and easily identifiable by the letter “g” in front of the name (if you named them this way). Just select a global property and add it to the text editor to use it.
When global properties are defined for a workflow, you define the values of the global properties when scheduling a job within the Workflow Studio Console.
Creating a Powershell Script that passes parameters into the workflow
If you want to automate the execution of the workflow with Powershell, the Powershell script can also set the values of the global properties to pass into the workflow being executed.
To pass parameters into the workflow, the Powershell script will have a structure similar to below. This sample script shows how to pass two parameters into the workflow. What we are doing here is creating a hash table that represents the name/value pairs of the global properties. This hash table is then provided as a parameter into the schedule-workflow cmdlet. Please note that the schedule-workflow cmdlet should be all on one line (it was split on two lines here for better readability).
To illustrate how the passing of parameters works, let’s use the SQL Server Activity Library within our workflow. This is an activity library that you can download and leverage yourself for communicating with a SQL Server database. The beginning point of our workflow is shown below.
In this workflow, we are using the SQLExecute activity for executing an UPDATE command on a SQL Server database. The initial SQL UPDATE command is shown below. Since we are hardcoding the Employee ID and Phone Number into the SQL statement here, the initial usability of this workflow is pretty limited. It would be much better if we could make this SQL statement adaptable for different employee IDs and phone numbers.
To make this SQL statement more dynamic, we need to create global properties to represent the Employee ID and Phone Number. Notice the prefix “g” we are using to denote the global properties. This will make them easy to find when applying them to an activity.
Once the global properties are defined, we can use them within the SQLExecute activity. In the screen shot below, the SQL Command is updated to reference the global Employee ID and Phone Number properties created above.
Our workflow is pretty dynamic now. We can pass the Employee ID and Phone Number as parameters into the workflow. When the workflow is executed, it will use the passed in values as part of this SQL statement.
The Powershell Script to automate the execution of this workflow is shown below. Please note that the schedule-workflow cmdlet should be all on one line (it was split on two lines here for better readability).
If you want to try out these Powershell scripts yourself, you’ll need to follow the setup instructions as outlined in the first blog of this series.
In the final two blogs of this series, we are going to take these Powershell scripts to the next level by converting them to an actual C# program. As you’ll soon see, you’ll use the information contained in these first few blogs to understand how the C# programs actually work. Stay tuned!
Blogs in this series:
Using Powershell to automate workflow execution within Citrix Workflow Studio
Passing parameters into a workflow within Citrix Workflow Studio (this one)
Automating workflow execution for Citrix Workflow Studio using a .NET windows application
Automating workflow execution for Citrix Workflow Studio using an ASP.NET web application