• 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
Related Tags
posted by Ed York

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.

Labels

workflow studio workflow_studio Delete
sdk sdk Delete
visual studio visual_studio Delete
activity libraries activity_libraries Delete
workflow-studio workflow-studio Delete
xenapp xenapp Delete
nonspecific nonspecific Delete
lang-eng lang-eng Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

Anonymous says:

You are not logged in. Any changes you make will be marked as anonymous. You may want to Log In if you already have an account. You can also Sign Up for a new account.