• View Communities
    • Citrix Developer Network
      The place for unfiltered straight talk on Citrix products. Blogs, code downloads, best practices, APIs, and more can all be found here.
    • Citrix Ready Community Verified
      Does it work with Citrix? Application compatibility questions are a thing of the past with the new Citrix Community Verified site.
    • Blogs
      Learn the latest from the Citrix employees who are building application delivery infrastructure technologies.
    • Blogosphere
      The Citrix Blogosphere is a window into the thousands of conversations taking place about Citrix and Application Delivery.
  •  Sign In
The Citrix Blog
Personal Blog
Ed York
Blogs
Profile
Related Tags
architecture
xenapp
Version 1 by Ed York
on Jun 26, 2009 17:15.

 
compared with
Current by Ed York
on Jul 10, 2009 09:24.

 
Key
These lines were removed. This word was removed.
These lines were added. This word was added.

View page history


There are 4 changes. View first change.

 This is the second part of a four-part series on automating the execution of workflows within Citrix Workflow Studio.  In the [first blog|http://community.citrix.com/blogs/citrite/edy/2009/06/19/Using+Powershell+to+automate+workflow+execution+within+Citrix+Workflow+Studio] 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).
 !1_GlobProps0.JPG|align=left!\\
 \\
  
 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.
 !2_GlobProps3.JPG|align=left!\\
 \\
  
 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.  !3_GlobProps4.JPG|align=left!\\
  
 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*. 
 !8_JobWizard1.JPG|align=left!\\
 \\ !9_JobWizard2.JPG|align=left!\\
 \\
  
 *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).
 {code}
 #Set variables for the workflow
 $strWorkflowName = "Workflow1"
 $strParam1Name = "Name1"
 $strParam1Value = "Value1"
 $strParam2Name = "Name2"
 $strParam2Value = "Value2"
  
 #Add the Workflow Studio snap-ins to the current Powershell session
 Get-PSSnapin -registered | Add-PSSnapin
  
 #Get reference to the Workflow Studio runtime
 $rt = Get-WorkflowRuntime
  
 #Get reference to the deployed workflow
 $workflow = get-deployedworkflow -workflowruntime $rt -workflowname $strWorkflowName -includeschedule
  
 #Create hash table of parameter values to pass into workflow
 $params = @{$strParam1Name = $strParam1Value; $strParam2Name = $strParam2Value}
  
 #Schedule the workflow to run immediately
 schedule-workflow -workflowruntime $rt -workflowstrongname $workflow.WorkflowStrongName
 -workflowparameters $params -runimmediately
 {code}
 \\
 *Example:*
 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|http://community.citrix.com/blogs/citrite/edy/2009/06/19/SQL+Server+Activity+Library+for+Citrix+Workflow+Studio] and leverage yourself for communicating with a SQL Server database.  The beginning point of our workflow is shown below. 
 !4_WFSDesigner.JPG|align=left!\\
 \\
 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.
 !5_SQLCommandBefore.JPG|align=left!\\
 \\
 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.
 !6_GlobProps2.JPG|align=left!\\
 \\
 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.
 !7_SQLCommandAfter.JPG|align=left!\\
 \\
 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).
  
 {code}
 #Set variables for the workflow
 $strWorkflowName = "Workflow1"
 $strParam1Name = "gEmployeeID"
 $strParam1Value = "101"
 $strParam2Name = "gPhoneNumber"
 $strParam2Value = "555-123-4567"
  
 #Add the Workflow Studio snap-ins to the current Powershell session
 Get-PSSnapin -registered | Add-PSSnapin
  
 #Get reference to the Workflow Studio runtime
 $rt = Get-WorkflowRuntime
  
 #Get reference to the deployed workflow
 $workflow = get-deployedworkflow -workflowruntime $rt -workflowname $strWorkflowName -includeschedule
  
 #Create hash table of parameter values to pass into workflow
 $params = @{$strParam1Name = $strParam1Value; $strParam2Name = $strParam2Value}
  
 #Schedule the workflow to run immediately
 schedule-workflow -workflowruntime $rt -workflowstrongname $workflow.WorkflowStrongName
 -workflowparameters $params -runimmediately
{code}\\
  {code}
 \\
 *Final thoughts:*
 If you want to try out these Powershell scripts yourself, you'll need to follow the setup instructions as outlined in the [first blog|http://community.citrix.com/blogs/citrite/edy/2009/06/19/Using+Powershell+to+automate+workflow+execution+within+Citrix+Workflow+Studio] 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\!
  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|http://community.citrix.com/blogs/citrite/edy/2009/06/19/Using+Powershell+to+automate+workflow+execution+within+Citrix+Workflow+Studio]
 Passing parameters into a workflow within Citrix Workflow Studio (_this one_)
 Executing workflows for Citrix Workflow Studio within a .NET windows application
 Executing workflows for Citrix Workflow Studio within a ASP.NET web application
  [Automating workflow execution for Citrix Workflow Studio using a .NET windows application|http://community.citrix.com/blogs/citrite/edy/2009/07/01/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|http://community.citrix.com/blogs/citrite/edy/2009/07/02/Automating+workflow+execution+for+Citrix+Workflow+Studio+using+an+ASP.NET+Web+application]
 \\