Follow on Twitter
Post to Twitter
I'm pleased to announce that Workflow Studio 2.0 is now available:
Download Workflow Studio 2.0 (MyCitrix login required)
This release has a number of great new features and is a seamless upgrade from version 1.x. Here are some of the key new features:
- Native XenApp activity libraries (and many other additional activities)
- Remote runtimes
- Simplified management interface
- Enhanced security features
- Simplified installation and configuration
- Improved SDK
- Simplified workflow Designer
- Globalization support
I will post some more blogs over the next few days with more details on the above features and will also be updating the CDN site with many new articles, so subscribe to the Workflow Studio blog and head over to the Workflow Studio CDN site and subscribe for updates on CDN as well.
Feel free to leave feedback in comments or email me directly.
Workflow Studio will be included with XenApp Feature Pack 2
Learn more about Citrix XenApp 5 Feature Pack 2
- Official Press Release - http://citrix.com/English/NE/news/news.asp?newsID=1857726
- XenApp 5 Feature Pack 2 release Web Site - http://citrix.com/xenapp/featurepack2
- XenApp 5 Feature Pack 2 Executive Video - http://citrix.com/xenapp/fp2/video
- XenApp 5 Feature Pack 2 Release Webinar - http://citrix.com/xenapp/fp2/techtalk
- XenApp Expert Series videos for this release - http://citrix.com/xenapp/fp2/expertseries
- XenApp 5 Feature Pack 2 Blogs- http://community.citrix.com/blogs/tag/xa5fp2
- Download XenApp technology previews - http://citrix.com/xenapp/techpreviews
- XenApp Product Page - http://citrix.com/xenapp/
Follow XenApp on 
| 
| 
| 
Just in case you haven't seen the posts by Ed York and Michael Bogobowicz on Workflow Studio recently I wanted to call them out. In addition to providing some excellent activities and workflows for you, there are posts that explain the process of creating activities and workflows around XenApp, Provisioning Server, and SQL.
Michael wrote a workflow that automates the update of vDisks in Provisioning Server using the CLI tools:
http://community.citrix.com/display/wf/PVS+Automatic+vDisk+Update+Script
Ed has written up two excellent blog series on Workflow Studio:
- Workflow Studio SDK - This first series of posts detail Ed's experiences using the Workflow Studio SDK to build and debug custom activities and are an excellent place to start if you want to build your own activities:
http://community.citrix.com/x/YIUJB
Ed followed this series up with a post on building an activity to get a list of applications from XenApp using the MFCOM SDK and this activity and source code are available for download:
http://community.citrix.com/x/KgE-B
Ed also wrote a couple of activities that work with SQL Server:
http://community.citrix.com/x/2IJiB
- Automating Workflow Studio - The second series of posts is on automating workflows. Ed has posts that explain how to use the PowerShell interface to start a workflow and pass parameters to it. He then goes on to explain how to build your own front-end for starting these workflows:
http://community.citrix.com/x/ToNiB
As a reminder, all community posts on activity libraries and workflows will show up right in the Workflow Studio product under the Community tab so you don't even have to go out to the site to look. RSS feeds are also available on the Community site if you want to get notified in your favorite RSS reader.
I just recently posted a SQL Server activity library to the Citrix Developer Network (CDN). The SQL Server activity library allows you to execute SQL statements (SELECT, INSERT, UPDATE, DELETE, etc.) on a Microsoft SQL Server database as part of a workflow within Citrix Workflow Studio. The activity library, setup instructions, and full source code can be downloaded here.
I actually needed this type of library for a Workflow Studio project I'm currently on. I coded the activity library to be general enough for anyone to use within their own environments. The environment I've been using with this activity consists of Workflow Studio 1.1 and SQL Server 2005. I haven't tested with other versions of SQL Server, but I am providing the full source code to this library in case you need to tweak anything.
There are two activities within the SQL Server activity library:
- SQLSelect activity - used to run SELECT queries on a database. The output of this activity is a collection containing the query results. Since the output is a "collection" type object, you can loop through this collection within Workflow Studio using the For Each Object activity and dump the collection contents to an XML file via the ExportToXML activity.
- SQLExecute activity - used to run INSERT, UPDATE, and DELETE queries on a database. The output of this activity is a string containing the number of records affected by the SQL statement.
There are five properties that need to be set on the SQLSelect/SQLExecute activities:
- Database Server - SQL Server machine hosting the database
- Database Name - Name of the database to connect to
- SQL Command - SQL statement to execute on the database
- SQL Username - SQL Server username for connecting to the database
- SQL Password - SQL Server password for connecting to the database
The SQL Command property will be set differently based on which SQL activity you are using. The SQLSelect activity will expect a SELECT statement here. The SQLExecute activity will expect an INSERT, UPDATE, or DELETE statement here (essentially any non-SELECT query).
The SQL Server activity library was developed using the Workflow Studio SDK:
If you need to review the code and make changes, I highly recommend reviewing my previous blog series on using the Workflow Studio SDK. This blog series will help you get your Visual Studio development environment up and running so you can make changes to the code.
For the programmers out there, the activities themselves leverage the standard ADO.NET objects for connecting to a SQL Server database and executing a command. If you are familiar with ADO.NET, then the code should be fairly straightforward to walk through.
Finally:
When you check out the CDN you'll see the full setup and usage instructions so I didn't restate them here. The SQL queries you execute can be static (using hard-coded values) or dynamic (based on the bindable properties of other activities within the workflow). This makes this activity pretty flexible to use in any kind of situation or query you may encounter. Have fun and I hope this helps you out as well!
A great way to learn how to use the Workflow Studio SDK is to look at code examples that you can try and implement yourself. The Activity Developer's Guide provides a few simple activities to help get you started. If you are looking for a more robust activity sample to set up and review, I just recently posted a sample activity called AppList to the CDN site for you to download. The AppList activity, setup instructions, and full source code can be downloaded here.
What is the AppList activity?
The AppList activity is a sample activity based on MFCOM that retrieves the list of applications that are published within a XenApp 4.5 farm. This activity communicates with a XenApp 4.5 server, so you'll need a XenApp 4.5 farm in order to run and test this activity. Even if you do not have a XenApp server handy, you can at least review the source code to get more details of how to code your activities.
The output of this activity is a collection of application objects, where each application object contains details about a published application in the farm. By returning a collection of objects, you can use the other activities within Workflow Studio to loop through this collection or output the entire collection contents to an XML file (see picture below).
Sample workflow
In the workflow pictured above, the "AppList" activity retrieves the list of published applications. The output of this activity is then tied to the "ExportToXML" activity to export the contents to an XML file. The XML file will contain a list of the applications published within the XenApp farm along with their various attributes (executable path, description, window size, audio setting, etc).
The screen shot below shows a sample XML file that is generated. The first application listed here is "Notepad", along with various attributes for how Notepad was published. If you want a quick way of archiving how all of your applications are published, this is a nice and simple way of doing so without having to visit the properties of each published application within the Access Management Console.
How is this sample useful?
I've spent most of this blog explaining what this activity does. But the real reason for posting this activity is the source code. Feel free to open the source code inside Visual Studio to get an idea of how this type of activity is coded. Take a look at the MFCOM code for pulling back the list of published applications. MFCOM is a pretty robust API and I only tapped into a few objects to make this activity happen. You can do so much more with it to perform other actions on XenApp. In the near future I hope to provide more blogs about this particular example and explain the various sections of the code. In the mean time, feel free to try to get it up and running, step through the code, and experiment (test environments only please!).
What is MFCOM?
For those of you not familiar with MFCOM, MFCOM is the name of the API provided by XenApp for performing various administrative actions on a XenApp farm via code. MFCOM (MetaFrame Component Object Model) has been around for quite some time across several different releases (XenApp, Presentation Server, and MetaFrame). When you use MFCOM, you'll quickly realize that a lot of the actions that you can normally do within the Access Management Console you can also do with MFCOM API calls.
MFCOM has a client/server architecture where the MFCOM client is the client machine running your MFCOM program and the MFCOM server is the XenApp Server itself. In the case of our Workflow Studio activity discussed here, the Workflow Studio machine is considered the MFCOM client. MFCOM clients communicate with MFCOM servers via DCOM calls. When you install MFCOM on your Workflow Studio machine, the installation will have you specify the XenApp server you want to communicate with via DCOM. You do not need to make any updates or changes to your XenApp server as the server-side MFCOM components are already implemented by the XenApp installation.
Additional Resources:
If you want more information on the Workflow Studio SDK, feel free to check out my SDK blog series.
If you want to step through the AppList source code while running the activity within Workflow Studio, you should check out this post on how to set this up.
It's now time to wrap up this series on the Workflow Studio SDK and talk about a pretty handy topic for debugging the activities that you create within Visual Studio. If you have developed code in the past, you know that one of the most handy ways to debug your code is to step through your code in real-time as the program is running. As you step through your code, you can check the programming logic and make sure it is executing as expected. You can also "watch" variables as they are declared and populated with values. Watching variables is especially important if they are being filled from backend database calls or APIs.
In this article, I'm going to show you how you can step through your Visual Studio code in real-time as your activity is being executed within the Workflow Studio Designer. As always, I'll keep the process simple and break it down into the following steps:
• Step 1 - Initial setup
• Step 2 - Place break points in the Visual Studio project
• Step 3 - Verify the project build settings
• Step 4 - Attach Visual Studio to the WorkflowExpressRuntime.exe process
• Step 5 - Start the workflow within the Workflow Studio Designer
• Step 6 - Step through your code in Visual Studio when your break points are hit
Step 1 - Initial setup
Workflow Studio needs to be installed on your Visual Studio development machine. This allows Visual Studio to attach to the various Workflow Studio processes for stepping through your code (as discussed in a later step).
Next, when you are ready to test your workflow and step through your code, you essentially need two programs running. First, you need your Visual Studio project opened so you can step through your code. Second, you need the Workflow Studio Designer opened so you can place your activity in a workflow and initiate the test. If you do not know how to add your activity to the Workflow Studio Designer, please refer to my last blog (Part 4) on how to test your new Activity DLL within Workflow Studio.
I'm going to use the same "AdvancedDelay" example that I discussed in the last blog to illustrate the step-through process. My workflow is shown below. The activity I'm trying to step-through is the AdvancedDelay activity. This activity inserts a delay into the workflow for a specified amount of time (about 5000 milliseconds in this example). When this activity completes, a message box will pop up via the MessageBox activity. 
Step 2 - Place break points in the Visual Studio project
Once you have your activity placed in a workflow within the Workflow Studio Designer, you can place break points in your Visual Studio project. In this example, I placed a breakpoint in the line of code that is actually performing the delay here. Within the execution section of my activity project, the Sleep() call is actually performing the delay. I want to step through this code myself to make sure it works while my workflow is running. 
Step 3 - Verify the Project Build settings.
Your Visual Studio project needs to be set up in a certain way in order for you to step through your code in real-time. The following two screen shots show how I have my project set up. You can access these same screens by going to the Properties of the activity project.
I actually did not have to make any changes to the project settings as is shown here - my project was already set up correctly based on the project template. Your project is most likely already set up this same way as well. I really wanted to give you these screens here for reference in case you were playing with these properties during the development stage. A few things you'll need to check at the least:
• Your project should be in "Debug" mode instead of "Release" mode.
• The "Optimize code" setting should be disabled
• In the Advanced dialog, the "Debug Info" setting should be set to "full". 
Step 4 - Attach Visual Studio to the WorkflowExpressRuntime.exe process
Next, navigate to Tools-->Attach to Process within Visual Studio. In the Attach to Process dialog, select "WorkflowExpressRuntime.exe". This is the process used by the Workflow Studio Designer for executing workflows. If you do not see this process listed, it means that you do not have the Workflow Studio Designer open.
If you are curious about what the "WorkflowRuntimeHostService.exe" process is, that is the process used by Workflow Studio for executing regular jobs. If you want to step through your code when executing a job instead of using the Workflow Studio Designer, you can attach to that process instead and then run a job containing this activity. It's pretty cool we have some flexibility here for stepping through our code in either situation! 
Step 5 - Start the workflow within the Workflow Studio Designer
Once Visual Studio is attached to the correct process, we are ready to begin our test. Start the workflow within the Workflow Studio Designer. When our custom activity is executing (AdvancedDelay1), any break points that are hit within our code will automatically bring up Visual Studio at those break points. 
Step 6 - Step through your code in Visual Studio when the break points are hit
Our break points are now getting hit and we can begin stepping through our code. The standard way to step through your code in C# is with the following keys - Step Over (F10), Step Into (F11), Step Out (Shift + F11), and Continue Execution (F5).
In our example below, we set a break point when our Sleep() command actually performs the delay. If you execute this statement, the sleep will actually occur for the specified amount of time as specified within the activity (which is 5 seconds here). 
Final remarks:
You should now be well on your way for creating custom activities within Visual Studio, testing them, and stepping through your code for advanced debugging. I hope this series was helpful and stay tuned for more information on using the SDK. If there are certain topics that you would like us to focus on in the future, please let us know!
Blogs in this series:
• Getting Started
• Setting up your Visual Studio development environment
• Anatomy of a Workflow Studio activity project
• Testing your Workflow Studio activity project
• Stepping through your Visual Studio code (this one)
After attending Citrix Synergy last week, I wanted to come back and complete this 5 part series that I started before the conference began. In the last article (Part 3), I discussed the anatomy of a Workflow Studio project. The information in that article should help you get started in coding your activities. Next on the list is to discuss how to test your activity project within Workflow Studio once you've completed a bulk of the code in Visual Studio.
If you want to follow along with me, you should create the AdvancedDelay activity project as outlined within the Workflow Studio Developers Guide. The AdvancedDelay activity inserts a delay into your workflows for a specified amount of time. As discussed in the Developers Guide, the code that you add is pretty straightforward. You are just adding a property to specify the delay time and a sleep command in the execution section to perform the actual delay.
To make the testing process simple, I'll break it up into the following sections. Each section is discussed in more detail below.
• Before you begin
• Build your solution in Visual Studio
• Copy the activity DLL to the Workflow Studio activities folder
• Launch Workflow Studio and create a new workflow project
• Add the activity to the workflow project and run/test the workflow
Before you begin
Before you compile your project, you should check out a few settings that are placed at the top of your activity file. If you are following the AdvancedDelay example, open the AdvancedDelay.cs file and check out the activity settings at the top.
• DisplayNameAttribute - this is the name of the activity as it will appear in the Workflow Studio Designer.
• ActivityTreePath - this is the location that the activity will be placed in within the Workflow Studio Designer activity pane. In the example below, I'm placing this activity within the General/Custom Activities folder. You can place this activity anywhere in the activity pane.
Build your solution in Visual Studio
You build the solution like any other Visual Studio project. Just navigate to Build-->Build Solution in the file menu. Verify that the build succeeds within the Output window at the bottom of Visual Studio. 
Copy the activity DLL to the Workflow Studio activities folder
After you compile the project, a DLL is produced that contains your activity project code. This DLL is typically found in a sub-directory where your Visual Studio project resides on the system. In my environment, this DLL was found in my user profile since my Visual Studio projects are all written to my user profile ("C:\Documents and Settings\Administrator\My Documents\Visual Studio 2008\ProjectsAdvancedDelay\AdvancedDelay\bin\Debug").
Copy the activity DLL (AdvancedDelay.dll in this example) and paste into "C:\Program Files\Citrix\Workflow Studio". Your DLL will need to be here in order for Workflow Studio to use it.
Note: If your project happens to reference other 3rd party DLLs that you added manually to the project (for example, mfcom.dll for tying into XenApp), you'll need to add these extra DLLs to the above folder as well. This allows the Workflow Studio Designer and Runtime to pick up these references to allow you to run the activity. In our example here, our AdvancedDelay activity project is pretty simple and we didn't add a reference to another 3rd party DLL so we can bypass this action.
Launch Workflow Studio and create a new workflow project
With your activity DLL now in the right location, launch Workflow Studio and create a new workflow project. I typically like to create new workflow projects for testing activities, but you can also edit existing workflow projects if you desire.
Add the activity to the workflow project and run/test the workflow
The Workflow Studio Designer should now be displayed. If this is your first time testing the activity, the activity will not yet be displayed within the activity pane. To add the activity as an available activity within the pane, navigate to Tools-->Choose Activities. Browse to the activity, verify it is selected, and close the Choose Activities dialog. Notice the "Toolbox Location" field on this dialog. This is the location we specified in our code where this activity will be placed within the activity pane. 
Verify the activity is now listed within the activity pane. Drag the activity to the designer surface and configure the properties as needed. Start the activity and verify that it runs as expected.
In the example below, I configured the AdvancedDelay activity to run for 5000 milliseconds (5 seconds). I then placed a message box beneath the delay. When running the activity, it should take about 5 seconds for the message box to pop up. If it does, I know this activity is running as expected. 
One final note:
If you find that you need to make code changes to your activity, just open up Visual Studio, update your code, and recompile your project. You'll then need to place the updated DLL back in the C:\Program Files\Citrix\Workflow Studio folder in order for Workflow Studio to pick it up. If you get an "Access Denied" type message, this typically means that you'll need to close Workflow Studio (Console and Designer) in order to successfully overwrite the existing DLL that is in that location. The Workflow Studio executables will have a lock on that DLL if you just used a previous version of that DLL in a workflow.
Once you can copy the updated DLL to that location, re-open Workflow Studio, and edit your workflow project. When you edit your project, your workflow will automatically be referencing the new DLL. You don't have to re-browse for the activity and add it to the activity pane. Make the appropriate property changes and workflow changes and re-execute your workflow.
In the next blog, I'll explain how you can step through your code in real-time in case you wanted to perform more robust troubleshooting at this stage. Stay tuned!
Blogs in this series:
• Getting Started
• Setting up your Visual Studio development environment
• Anatomy of a Workflow Studio activity project
• Testing your Workflow Studio activity project (this one)
• Stepping through your Visual Studio code
When you create a new Workflow Studio activity project within Visual Studio, the templates provide you with a pretty comprehensive and documented activity class file. In the screen shot below, I minimized a lot of the code, but you can see the primary sections of the activity file within the project. 
The primary sections of this file are listed below:
- Using statements
- General activity properties
- Class constructor
- Standard properties
- Dependency properties
- Activity execution section
- Property validation section
In this blog, I'll discuss at a high level each of these primary sections. I won't detail the meaning of all of the attributes and properties that are present as they are pretty well documented within the Activity Developers Guide and within the comments of the class file itself. This blog is really meant to give you an overview of what is actually in here so you can navigate to the appropriate section as you develop your activity.
1. Using statements:
There is a long list of using statements at the top that define the references for the class. What you should notice here is that the last five all come from Workflow Studio. If your activity references a third party DLL, you'll most likely need to add more using statements to make sure your references are all in place.
using Citrix.WorkflowStudio.Common;
using Citrix.WorkflowStudio.CustomActivities.Designers;
using Citrix.WorkflowStudio.CustomActivities.Editors;
using Citrix.WorkflowStudio.CustomActivities.Serializers;
using Citrix.WorkflowStudio.User;
2. General activity properties:
Right beneath the using statements is a section called "Attribute Definitions and Comments". This section contains a series of general properties for the activity. The comments provided within this section explain these settings pretty well. A few of them you should take note of are below.
[DisplayNameAttribute(@"AdvancedDelay")]
This is the name of the activity displayed within the Workflow Studio Designer.
[Description(@"This activity will delay for a specified amount of time")]
This is the description of the activity displayed within the Workflow Studio Designer. When you select the activity in the Activity pane, the description is shown in the lower-left corner of the Designer.
[ActivityTreePath(@"Windows PowerShell/Utilities")]
This is the folder location for where the activity is placed within the Activity pane of the Workflow Studio Designer. A forward slash is used to specify a subfolder.
3. Class constructor:
The class constructor is next. This code gets executed when the activity is placed on the drag-and-drop surface within the Designer. The most common thing you'll need to do in the constructor is to initialize the values of your properties.
4. Standard properties:
The section for standard properties is listed after the class constructor. A sample one is provided in the template which is commented out. This sample is mainly here to give you the syntax for defining a sample property if you would like to use one within your code.
What you really need to know is that there are two types of properties you can define within the class - standard properties and dependency properties. The primary difference between them is that dependency properties are "bindable" to other activities whereas standard properties cannot be bound. Dependency properties have much more flexibility than standard properties due to being bindable. In the Designer, bindable properties allow their values to come from other activities. Bindable properties can also be used as input to properties of other activities. Due to this flexibility, dependency properties are much more common to use than standard properties and you should probably define all of your properties as dependency properties first, then fall back to being standard if the bindable behavior is not desired.
5. Dependency properties:
The dependency property section is listed after the standard property section. As stated in the section above, dependency properties are much more common to use than standard properties since they can be bound to the properties of other activities. Their flexibility makes them a much better choice in most cases.
The activity template gives you a series of sample dependency properties that are commented out. I won't go into all of the code for this property here (it's explained pretty well within the Activity Developers Guide). I'll just highlight a portion of the settings here...
[DefaultValue("0")]
This is the default value of the property. Default values can also be set within the class constructor. When using the Workflow Studio Designer, if the property value is ever set to something different than this default value, the value is shown as bold within the Designer to indicate it has changed.
[DisplayName(@"DelayTime")]
This is the name of the property as shown within the Workflow Studio Designer. This name should be intuitive and easy for admins to understand.
[Description(@"Amount of time to sleep in ms")]
This is the description of the property as shown within the Workflow Studio Designer. When you select the property in the Designer, this text is shown in the lower-right corner of the Designer.
[Browsable(true)]
This setting defines whether this property is visible within the Workflow Studio Designer. If set to true, it is displayed within the Designer when the activity is selected. If you don't want admins to know about this property or see it within the Designer, you can set browsable to false.
[InputAttribute]
A property can either be an input property or output property. Input properties define some value that is inputted into the activity. Output properties define something that is returned by the activity after the activity is executed. The use of the [InputAttribute] or [OutputAttribute] declaratation defines what icons should be used for this property in the Workflow Studio Designer.
6. Activity execution section:
After all of the properties are defined, the next section is the Execute() function. This function gets called when the activity is executed by Workflow Studio. All of the execution logic should go into this function.
The Execute() function provides a try/catch block. Put all of your execution logic in the try block. Don't touch the ExpandStringProperties() call at the top as this function will dynamically retrieve the property values set within the Workflow Studio Designer at runtime so that you can use them within the try block.
7. Property validation section:
The last section of the file defines how property validation is performed within the Workflow Studio Designer. If you have used the out-of-the-box activities within the Designer, you may have noticed that some activities have required properties that need to be set in order for them to be valid. These properties provide a red X or yellow warning icon to inform admins that they are required or desired to be set. You can set up the same type of functionality for your properties through the code in this section. There are a lot of comments within this section to explain how to set up your properties for validation, so I won't go into this here. I may blog about this in the future as it could be a big discussion on its own.
Blogs in this series:
- Getting Started
- Setting up your Visual Studio development environment
- Anatomy of a Workflow Studio activity project (this one)
- Testing your Workflow Studio activity project
- [Stepping through your Workflow Studio activity project code]
I recommend having a separate Development machine and Test machine for working with the SDK. I have mine set up as follows:
- Development machine - contains Visual Studio 2008, Workflow Studio 1.0, and the Workflow Studio 1.0 SDK (C# templates).
- Test machine - just has Workflow Studio 1.0 on it for testing activities created on the development machine. Having a separate box for testing allows you to be sure that your activity works on a non-development machine.
One thing you may notice is that I have the full Workflow Studio 1.0 product on my development machine as well. The benefit of placing Workflow Studio on the development machine is that it allows you to step through your code in Visual Studio by attaching to the key Workflow Studio processes. I'll go into more detail on that later in this blog series. Technically you can get by without installing Workflow Studio on your dev machine by copying over 5 key DLLs from another Workflow Studio installation. The Activity Developers Guide provides details on how to locate and copy these DLLs if you wanted a more minimal installation.
1 - My initial development machine layout:
When I started building my Dev machine I had a barebones Windows Server 2003 installation:
- Windows Server 2003 SP1
- IIS with ASP/ASP.NET enabled
2 - Install the prereqs for Visual Studio 2008 and Workflow Studio 1.0:
Next, I installed the prereqs for Workflow Studio and Visual Studio listed below.
3 - Install Visual Studio 2008
Third, I installed the Visual Studio product.
- During installation, select at least the C# language since the WFS Activity templates are based on C#. You can choose other languages as well if you want to use this machine for other purposes later on.
- After installation, launch Visual Studio and select the C# development layout on the first time use screen. I've tried both the VB IDE layout and C# IDE layout and the C# layout makes it a lot easier to set up the "stepping through code" settings for later on.
4 - Install Workflow Studio 1.0
Fourth, I installed Workflow Studio 1.0.
- During installation, point to your SQL Database installation (mine was local SQLEXPRESS). When configuring the Runtime Service, I added one service that is tied to my local admin account.
- After installation, launch Workflow Studio and ensure you can access the Workflow Studio Console
5 - Install Workflow Studio 1.0 SDK
Finally, I installed the Workflow Studio SDK. This installation adds 4 templates to Visual Studio (2 project templates and 2 class templates)
- During installation, take all of the defaults.
- After installation, launch Visual Studio and verify that these templates are present. Essentially, try to create a new C# project and the Workflow Studio project templates should be listed there.
After completing the final step, you're all set to start writing custom activities. If this is your first time developing an activity I definitely recommend checking out the Activity Developers Guide that explains how to create a few sample activity projects.
Blogs in this series:
- Getting Started
- Setting up your Visual Studio development environment (this one)
- Anatomy of a Workflow Studio activity project
- Testing your Workflow Studio activity project
- Stepping through your Visual Studio code
I've been using the Workflow Studio SDK for about a month and just wanted to share with everyone some things I've learned along the way. I figured a good approach to get the word out to our partners, customers, and Consulting teams about how to use the Workflow Studio SDK was to try a blogging series. Over the course of the next few weeks I'll blog about some of the fundamentals of using the Workflow Studio SDK. This is part 1 of the series in answering some of the beginning questions.
What is the Workflow Studio SDK?
The Workflow Studio SDK is a series of C# templates for Visual Studio 2008 that allows you to create activities for Workflow Studio. There are two types of activities you can create using the templates:
- Powershell Activity - this is an activity based on a Powershell command. When you choose this activity type within Visual Studio, the Powershell Converter opens where you select the Powershell command you want to transform into an activity. The Powershell Converter then creates the activity code based on the Powershell command(s) that were selected. You can then further modify this code to customize as you see fit.
- Standard Activity - this is an activity used for standard actions not based on Powershell commands. Essentially, you will create a standard activity if you are not creating an activity based on a Powershell command. The code you get looks about 95% the same with a few differences.
What skills do I need to use the Workflow Studio SDK?
From a programming side I would say you need a basic background in using Visual Studio and C#. The templates are only available in C#, so if you are a VB or VB.NET programmer you'll have to walk on the other side of the fence here.
My personal coding experience mainly comes from web development (HTML, JavaScript, ASP, etc.) several years back. I'm not an extensive coder but I do understand the object-oriented programming principles. Using the SDK was my first time to extensively use C# and if you understand coding principles and object-oriented programming, it's really a matter of learning the new syntax. For example, for me I found myself asking things like "I know how to create properties in VB, how do I do this in C#?"
In addition to the recommendations above, I would definitely recommend playing with the Workflow Studio product before you start using the SDK (that's probably a given 
). You'll want to understand how activities tie to each other through binding, as you'll be creating "bindable" properties in your code.
Using the SDK might sound pretty complex at the beginning, but the templates you are given have so many comments that they really guide you through the process as well.
Where can I find the Workflow Studio SDK?
The SDK can be found on the Citrix Developer Network site (http://community.citrix.com/cdn/wf/sdks).
Is there a Developer's Guide for getting started with the SDK?
Yes, a great guide is available on the Citrix Developer Network site (http://community.citrix.com/cdn/wf/sdks). If you are new to using the SDK this guide is a must for getting started. You should come here first before venturing out on your own. This guide will walk you through creating two sample activities:
- "GetDate" Powershell activity - creates an activity based on the "Get-Date" powershell command. This activity returns the current date/time of the system.
- "AdvancedDelay" Standard activity - creates an activity that allows you to specify a time delay for your workflow. For example, in Workflow Studio if you want the runtime to pause a certain length of time before continuing with executing the rest of the workflow, you can add the AdvancedDelay activity to pause a certain amount of time.
Upcoming blogs in this series:
I just posted a video tutorial on using the Workflow Studio SDK to to convert a PowerShell cmdlet to an activity library on the Multimedia section of the Workflow Studio CDN site
This tutorial walks you through creating an activity library from the Get-Date PowerShell cmdlet just like the tutorial in the Developer's guide. The SDK and Developer Guide is available here:
http://community.citrix.com/cdn/wf/sdks
Here is the video:
Getting Started with the Workflow Studio SDK
Get started converting your own favorite PowerShell cmdlets and let us know what you find.
***Update: As of the 2.0 release we now include 143 activities with the product, including libraries for Netscaler, XenServer, and XenApp. We keep adding more, and if you have specific requests, please email me...
Alex posted in our forums that he was extremely disappointed in the 1.0 release of Workflow Studio because of a lack of libraries/templates for use with Citrix products. We are working on releasing libraries for Citrix products, as well as libraries that integrate with Active Directory, Group Policy, Power Management, and Windows. I appreciate the criticism, as it made me realize that we haven't done a good job of describing the target audience of this 1.0 release. I would like to take the opportunity to explain the different audiences that Workflow Studio appeals to, and why we released 1.0 as it is. Hopefully this post will help to explain how the different features of Workflow Studio appeal to these audiences and also clarify how it can be used today and where we are going in the future.
To make sure we are all on the same page, I want to start by defining the audiences that I will refer back to later. The titles I chose are not important, but hopefully the descriptions will help you to place where this fits in your organization. In the IT industry people often wear many hats and don't fit neatly into a classification.
- IT Operations - This role is responsible for ensuring that IT systems are working and available on a wide scale, but would not typically do development or scripting tasks.
- Server Administrator - This role is responsible for specific server workloads and is intimately familiar with the software running on a system. They are comfortable with batch files, scripting, PowerShell, etc. but would not be comfortable doing traditional software development.
- Software Developer - This role is defined by people who write software that is either sold (Software Companies, System Integrators, Consultants, etc.) or used internally by other groups (often including the above two audiences.)
Workflow Studio is built on top of two technologies from Microsoft - Windows PowerShell and Windows Workflow Foundation. Linking these technologies to the audiences from above for PowerShell would be the Server Administrator, and for Workflow Foundation would be the Software Developer. Our intent with Workflow Studio is to merge these two technologies together and offer solutions that appeal to the IT Operations staff (and Server Administrators who are looking for tools, but are too busy to script solutions to all their needs themselves.) As a result of being built on top of PowerShell and Workflow Foundation, we offer features that the other two audiences will also find useful.
As Alex pointed out, the 1.0 release is not very interesting to the IT Operations audience yet because there isn't a large base of activity libraries and workflows available today. The Software Developer audience on the other hand can use 1.0 today with the publicly available APIs for our Citrix products (and if they choose, share or sell their work to the community at large.)
Now I want to take a look at specific features and functionality of Workflow Studio and how they map to these audiences:
IT Operations
The intended process of using Workflow Studio for this audience would be to download workflows (and activity libraries) that solve specific problems that this audience faces. All that needs to be done after downloading the workflows is to schedule or execute them as applications that solve those specific needs.
Workflow Studio has a community tab that links the product back to the Citrix Developer Network (CDN). Citrix, our partners, and the community at large can post activity libraries and workflows that can be downloaded and used without any need to write scripts or code. We built in a tutorial workflow called ExportServices that you can access through the Help menu to see how this process is intended to work. We plan to leverage this mechanism to release activity libraries and workflows to address specific problems faced in deploying the Citrix Delivery Center and the Citrix Cloud Center. We are also looking to our partners and community to build additional libraries and workflows that this audience will find valuable.
Obviously, this audience will not be well served until pre-built workflows are available that solve problems you face in your environment. Let me know in the comments or through email what types of things you would like to see. As we release activity libraries we will also release workflows that relate to them and as more are available we will be able to release more integrated workflows as well.
Server Administrator
The intended use case for this audience is to build and modify workflows using the Workflow Studio Designer for use either internally or to share with the community.
We are working on some activity libraries that will be available in coming weeks that will facilitate building workflows that leverage your existing VBScript and PowerShell scripts. This functionality will enable this audience to leverage their existing scripting knowledge in a more visual, database-driven, automatically versioned, and easily share-able way. Workflows can be extended through C# with the code-beside feature, so if you know a little bit of programming you can automate almost anything that .NET and C# will allow with just the Designer and not need to go into Visual Studio to build native activity libraries. We have built in some pretty powerful extensions to Workflow Foundation in our Designer that will help you be more productive and make it easy to share within your group, organization, or the community. For instance, the snippets functionality allows you to save templates of individual activity configurations or groups of activities and then export and reuse/share them. Workflows themselves can also be exported and reused/shared as well. The Workflow Studio Designer is accessed by either creating a New Workflow or editing an existing workflow. You can also download other workflows and edit them to see how they were built.
This audience needs activity libraries available, and we are working on several that will be released in coming months. Active Directory, Group Policy, Windows, Power Management, and Citrix product support are all coming soon, so stay tuned.
Software Developer
The intended use case for this audience is to build and share/sell activity libraries that the above two audiences will find useful. These can target Workflow Studio directly or target Workflow Foundation more generically as the vendors in my post on Workflow Studio Extensibility have done.
Activity Libraries are the mechanism for extending Workflow Studio. An activity library is a component defined by Microsoft as part of Workflow Foundation. These can be built without any knowledge of Workflow Studio (standard Workflow Foundation activity libraries), but there are some features of Workflow Studio that we think offer additional value. We make it easy to target Workflow Studio directly with a set of templates for Visual Studio. Specifically, we have a converter that will take existing PowerShell snap-ins and convert them to activity libraries automatically. You will soon be able to download these templates and documentation on automating Workflow Studio on our Download SDKs page.
Workflow Foundation and PowerShell have been around now for more than 2 years. These technologies are robust and stable and can easily be leveraged with the 1.0 release of Workflow Studio. If you are a Citrix partner (or want to be one) and have some ideas in this space, feel free to contact me to discuss.
Hopefully this will help clarify where we are with Workflow Studio and where we are going. Feel free to email me with comments or thoughts on how we can do a better job of addressing your needs with Workflow Studio - whichever audience you may fall into.
The Citrix Desktop Delivery Controller PowerShell SDK provides a snap-in, XDCommands, for the Microsoft PowerShell v1.0 framework. The SDK consists of a number of "cmdlets" that allow you to script many of the administrative tasks you may need to perform on a regular basis.
Step by Step setting up your PowerShell / XenDesktop environment
- Install PowerShell 1.0 on the DDC (Desktop Delivery Controller)
- Download and Install Microsoft .NET Framework 3.5
- The PowerShell SDK is located on the XenDesktop 2.1 CD in the ...\Support\DdcSdk folder. Run the installer XenDesktop_2_0_DDC_Powershell_SDK.msi
Installing the SDK registers the XdCommands snap-in assembly with the Microsoft PowerShell framework. The snap-in makes a number of new classes and "cmdlets" available to PowerShell scripts or interactive shell sessions.
To run scripts you may need to use the built-in "Set-ExecutionPolicy" cmdlet to adjust the PowerShell execution policy to a value such as "RemoteSigned"
- Start Powershell and set the Excecution Policy. Set-ExecutionPolicy RemoteSigned
- Change to the folder where the SDK is installed cd \Program Files\Citrix\Desktop Delivery Controller\Powershell
- Load the snap-in into the PowerShell Add-PSSnapin XdCommands
Alternatively, use the installed PowerShell console file, XdCommands.psc1, to start an interactive PowerShell shell session with the XdCommands snap-in pre-loaded. Citrix provides a shortcut on the Start menu to start such a session. This shortcut also runs the "XdAliases.ps1" PowerShell script that sets up aliases for most of the SDK cmdlets. This shortcut will not function properly until the PowerShell execution policy, as described above, is set appropriately.
Help
Online help is available for all Desktop Delivery Controller SDK cmdlets. To obtain a list of cmdlets offered by the snap-in, run the built-in "Get-Command" cmdlet, as follows: Get-Command -psSnapin XdCommands
Online help for individual cmdlets is available using the built-in "Get-Help" cmdlet. For example, to view the online help for the "Get-XdDesktopGroup" cmdlet, run the following command: Get-Help Get-XdDesktopGroup
For an overview of all cmdlets provided by the SDK, view the "about_XdCommands" help topic. To view this information, run the following command: Get-Help about_XdCommands
Samples
Creating a new VM-based desktop group
This command creates a new VM-based desktop group, "testgrp", containing three machines, and published to all domain users. $usr = New-XdUser 'domain users' -group $cred = Get-Credential 'root' $hs = New-XdHostingServer 'XDS01' $cred $machineName= 'machine1','machine2','machine3' #find all the VM machines in the pool $allvms = Get-XdHostedMachine $hs #Find the workers and set the AD identity to the correct machine $dsk = $machineName | foreach { $vm=$_; $allvms | where {$_.HostingName -match $vm } | foreach { $_.Name = $vm; $_ }} $hgs = New-XdGroupHostingSettings $hs $ng = New-XdDesktopGroup -pub 'testgrp' -desk $dsk -user $usr -hosting $hgs
Adding a virtual desktop to an existing VM-based desktop group
This command adds a new virtual desktop, hosted by a VM, to an existing VM-based desktop group. Before adding a VM to the group, you must create a mapping between the VMs host ID and Active Directory ID. To do this, run the Get-XdHostedMachine cmdlet to obtain a list of host IDs for VMs and assign Active Directory IDs to those VMs.
# get all the groups whose name starts with 'test' (should be just one) $grp = Get-XdDesktopGroup test* # get all the workers whose friendly names have 'machine3' in them (should be just one) $dsk= Get-XdHostedMachine $grp.HostingSettings.HostingServer -name *machine3* # Set up the mapping to the AD name for the new Virtual Desktop machine $dsk.Name = 'machine3' $grp.Desktops.Add($dsk) Set-XdDesktopGroup $grp
If host ID to Active Directory ID mappings have been created previously, run the following command:
Get-XdDesktopGroup test* | *%* { \[void\]$\_.Desktops.Add($(Get-XdHostedMachine $\_.HostingSettings.HostingServer \-name \*machine3\*)); $\_ }| Set-XdDesktopGroup
Logging off a user from all current sessions, after sending a warning message
This command displays a warning message to all users whose names start with "christian" before logging them off. Note that in this example there is specified time period (10 seconds) before logoff occurs.
# get sessions for all users whose names start with 'christian'
$sess = Get-XdSession -user christian*
# warn the user
Send-XdSessionMessage $sess 'Forced log off in 10 seconds'
Start-Sleep 10
#Then go ahead with the logoff
Stop-XdSession $sess
Adding a user to an existing desktop group
This command adds users in all groups whose names match "GroupName" to an existing desktop group.
# get all the groups whose name matches 'GroupName' (should be just one)
# Note could also be written as:
# $grp = Get-XdDesktopGroup GroupName
$grp = Get-XdDesktopGroup | ? {$_.Name -match "GroupName" }
$Usr = New-XdUser "UserName"
$grp.Users.Add($Usr)
Set-XdDesktopGroup $grp
Robert O'Keefe has created a demo of how to use the Citrix Password Manager Localization SDK, which can be used to localize the CPM plugin to languages beyond those natively supported.
Yesterday, we released the Application Streaming Profiler SDK version 1.2, and it is now available as a free download.
This SDK allows creating applications or scripts that automate the management of streaming profiles. The API allows creating, updating, reseting and deleting profiles, and can be combined with automatic starts of unattended installers. Without this SDK, these tasks could only be done through the Streaming Profiler user interface and would require the physical presence and monitoring of an administrator.
Here follow a list of improvements in this second release of the SDK:
- New APIs for Inter-Isolation Communication profiles: The New IRADEPackage2 classes include support for defining links between profiles.
- Includes the TLB file that allows the easy creation of COM client applications with C++.
- Includes and explains multiple working samples in both C# and C++.
- The files included in this SDK are better organized for easy navigation.
For more information about Application Streaming see the product documentation or search for "Application Streaming" on the Citrix Blogs, and for detailed questions about the SDK, visit the dedicated Community Forum. Also, keep monitoring the Citrix Blogs because Joe Nord, our Product Architect for Application Streaming, will soon post entries to further explain the Streaming Profiler, the SDK, and this release.
Very important: we want to know about your experience with this SDK:
- Have you been able to use the SDK effectively?
- What else would you like to see in the SDK?
Lastly, XenApp 5.0 was announced earlier this week. If you want to learn more about it, you should not miss Citrix Delivery Center Live. This live virtual event will take place on September 9th. Make sure to register now!
We have just released the XenApp Management SDK (MFCOM) for XenApp 5.0, and it is now available as a free download.
This SDK allows creating programs or scripts that automate the management of XenApp. Examples of use for this SDK range from simple scripts to the implementation of full-fledge custom consoles for fully managing a XenApp deployment.
This release of the SDK adds support for Health Monitoring and Recovery, for reboot schedules, and for session policies. For additional details see the SDK and the XenApp documentation. You can also visit the very active Community Forum for this SDK.
XenApp 5.0 was announced earlier this week. If you want to learn more about it, you should not miss Citrix Delivery Center Live. This live virtual event will take place on September 9th. Make sure to register now!
Microsoft Windows PowerShell command line shell and scripting language helps IT professionals achieve greater control and productivity. Using a new admin-focused scripting language, more than 130 standard command line tools, and consistent syntax and utilities, Windows PowerShell allows IT professionals to control system administration and accelerate automation more easily
With PowerShell, Citrix Administrators can script MFCom Objects to manage and administer the XenApp Farm. The secret of using COM objects starts with the command: New-Object -COM.
The following PowerShell example creates a new MetaFrame object (do not get confused with the COM Object naming), initializes the Farm and prints out the farmname:
$farm = new-Object -com "MetaframeCOM.MetaframeFarm"
$farm.Initialize(1)
$farm.FarmName
It's not going to be a spectacular script. But look at the following little code enhancement:
$farm = new-Object -com "MetaframeCOM.MetaframeFarm"
$farm.Initialize(1)
$farm.FarmName
$farm.sessions | Format-Table UserName,ClientAddress
Just adding one more lines of code and you will get all sessions within the farm displaying the Username and IP Address.
Setting up your PowerShell / MFCom environment
Beginning with PowerShell / MFCom Scripting you should install Microsoft Powershell on a Citrix Presentation / XenApp Server in your lab. I recommend downloading the PowerShell Graphical Helpfile which also provides great information's about VBScript to PowerShell conversion.
For creating and editing your PowerShell scripts I suggest downloading the free PowerGui graphical user interface and script editor. Its easy to use and works well with COM Objects.
PowerShell
http://www.microsoft.com/windowsserver2003/technologies/management/powershell/download.mspx
PowerShell Graphical Help File
http://www.microsoft.com/downloads/details.aspx?FamilyId=3B3F7CE4-43EA-4A21-90CC-966A7FC6C6E8&displaylang=en
PowerGui - Graphical user interface and script editor
http://www.powergui.org
Displaying apps in your farm
To give you some basic ideas where PowerShell leverages your daily administrative tasks, I've created the following script:
$farm = new-Object -com "MetaframeCOM.MetaframeFarm"
$farm.Initialize(1)
$farm.FarmName
$farm.applications| where {$_.BrowserName -like "Winword*" {color:black}} | select DistinguishedName
The script above enumerates each application published in the farm and selects all applications where Winword* is contained in the BrowserName.
PowerShell Examples provided by CDN
PowerShell and other scripting examples can be found on the Citrix Developer Network:
We have recently released an update for the Health Monitoring & Recovery SDK, and it is now available for download.
The popularity of the Health Monitoring & Recovery (HMR) feature, included with XenApp 4.5 Platinum and Enterprise editions, has greatly increased during the last few months among Citrix customers. This feature monitors the health of XenApp by periodically executing multiple tests and by starting a recovery action if any of those tests fails.
Citrix provides multiple HMR tests out-of-the-box for the administrators to configure, but customers and third parties can use this SDK to develop additional tests.
Some of the improvements in this update of the SDK include:
- Improved error handling.
- Support for additional test formats.
- Additional sample tests.
- Support for Windows Server 2008.
We are planning a future video blog regarding HMR in general and about the SDK in particular. So, stay tuned!
In the mean time, you can check the Citrix Presentation Server Administrator's Guide or a prior posting about the feature for more information.
Enjoy!
Aureliano Lopez-Martin
Senior Product Manager, XenApp SDKs
Windows PowerShell is an extensible command line interface shell and associated scripting language from Microsoft. To implement you own specialist functions you can use cmdlets for enhancing PowerShell. Cmdlets are specialized .NET classes, which the PowerShell runtime instantiates and invokes when they are run.
For building your own cmdlets I've found C# and VB.NET cmdlet Templates in the web. http://channel9.msdn.com/ShowPost.aspx?PostID=256835.
(Extract the ZIP File and you should find 2 vsi files. One for C# and one for VB.NET. They are working well with Visual Studio 2008.)
If you now go to Visual Studio and create a new project select Windows Powershell Template as the project template.
Right-click your project and choose, add then New Item. From the list of items choose Windows PowerShell PSCmdlet. This should be the default choice for cmdlets.
Microsoft describes how to extend Windows PowerShell with custom commands in the following MSDN article.
http://msdn.microsoft.com/msdnmag/issues/07/12/PowerShell/default.aspx?loc=en
After building our solution we need to install assembly with the InstallUtil tool. Open a Visual Studio cmd prompt, navigate to the bin\debug folder of your solution and run:
InstallUtil yourassemblyname.dll
Next load Windows PowerShell and type:
Get-PSSnapIn -registered
(which should list your snapin along with any other snapins currently registered.)
Next enter:
Add-PSSnapIn yoursnapinname
(this will load your snapin)
You should now be able to call your new functions in PowerShell.
In the next couple of weeks (if I will have time) I'd like to develop a cmdlet which allows you to do basic operation tasks within a Citrix Presentation Server or XenApp farm. Things like: list all sessions, get farm name, logoff idle session, etc.
Have fun
Christian