If you’ve been following along with Richard Hayton’s recent posts on the release of Storefront 3.0, you’ve probably noticed that we are enabling Storefront with a lot of APIs to let you configure and use it in the way that best fit your environment.

The blog post series is great, and I recommend checking them out, as this article builds on them. You can read Richard’s posts here, but be sure to check out X1 DIY Approvals and Citrix Recipe Box: StoreFront Approvals, as they build on what we’re talking about here today.

Since this post contains multiple sub-parts, we are going to make this a series of posts, so we can break down–in detail–each of the steps. With that said, let get onto enabling Octoblu to handle your users request for application access, via the Storefront API.

Overview and setup:

This is going to be more of a general overview of the process and a high level How-To technical article so we can show you how to get up and running with the Storefront/Octoblu integration.

The scenario is that we have a set of applications, that we would like to display to all users but, only grant access when the user requests the application. A typical approval workflow that workflow engines handle.

There are a few steps we need to perform to enable Storefront to understand that an application needs to ask for approval. I’ve outlined those below.

  • Enable storefront to put applications in pending state.
  • Setup the published application to enable the approval process
  • Build a subscription database monitoring application to look for “pending” application.
  • Build a Octoblu workflow that handles the process flow for requesting, approving or denying a request for application access.
  • Build/Deploy intermediate page that allows a manager to approve the request.

Step One: Enable Storefront for workflows

There is a customization DLL that we are making available that you need to drop into your Storefront 3.0 directory. Richard’s blog (X1 DIY Approvals) gives the instructions, but I have copied them here, as well.

  1. Find the directory to the store you want to enable workflow for. For example C:\inetpub\wwwroot\Purple
  2. Edit web.config in this directory and add the following to the end of the <components> section
    <component id=”SimpleWorkflowHandler”  type=”Citrix.DeveloperNetwork.StoreFront.SimpleWorkflowHandler, SimpleWorkflowHandler”  service=”Citrix.DeliveryServices.DazzleResources.Workflow.IWorkflowAdaptor,           Citrix.DeliveryServices.DazzleResources.Workflow” />
  3. Download the DLL from here and save it in the bin directory (e.g. C:\inetpub\wwroot\Purple\bin)

Step Two: Setup published application(s) to enable workflows

Now that we have Storefront configured, we need to modify the published application(s) so that Storefront knows that it is an workflow enabled application. This is achieved by adding “KEYWORDS:WFS” into the description of any desired published application that you wish to have the user ask for access. Below is an example of the properties screen of a published application that has the description field filled in with the appropriate keywords.

Step Three: Setup Storefront monitoring application to watch for application requests.

Now that we have our Storefront and the XenApp/XenDesktop application configured, the next step is to create an application that will monitor the storefront database and look for applications that are in a “Pending” state and then trigger the Octoblu workflow and wait for a response. The basic flow is below.

  • Monitor Storefront Subscription database for any subscriptions of the “Pending” state.
  • Register with the Octoblu service to receive messages.
  • For each “Pending” application, call the defined Octoblu workflow.
  • Process received messages from Octoblu and based on the response, either change the pending state of the application to subscribed or remove the subscription.

Since breaking this application down is an entire blog on it’s own, we are building a follow-up blog on the drill down of this application. In the mean time we have made the application open source and available on our GitHub account. You can download it here https://github.com/citrix/Citrix-Storefront-ApprovalMonitoring

*Once you download it you can run it on your StoreFront server to start monitoring for pending applications.

Below is a quick screen capture of the monitoring application and after you download it you will have to modify a few pieces. You can check out the code for the specifics on where to add the following items.

  1. Add the workflow endpoint into the code.
  2. Add your Device UUID/Token into the code. (Check out our Visual Studio Extension to help you enable an application as a device in Octoblu)
  3. Add the email you wish to get the approval emails. We built it this way to enable you to quickly check out the process.

Step Four: Build/deploy intermediate page to handle the workflow requests.

To quickly enable managers to approve or deny requests we should provide a simple web interface that you can deploy on a web server to enable the managers to approve or deny the users request. We have provided a skeleton page that you can download from our GitHub site here https://github.com/citrix/Citrix-Storefront-ManagerApprovalSite

*Once you download this you will need to update the code to add your workflow endpoint. Check out the html for more instructions.

Below is the screenshot of the intermediate approval page. As you can see, there is buttons for approving or denying the application.

Step Five: Setup the Octoblu workflow for requesting application access.

The final step in this post if the create the Octoblu workflow that will handle the request and approval/denial process. We have provided a blueprint that you can download to get started. You can grab the workflow blueprint here


As a general overview – the workflow looks for some data that was posted to the workflow. It then will determine if the request is an “application request” or if it is a approval/denial request. Based on the request type, the workflow will route to different paths. One interested note here is that this workflow communicates back to the monitoring application ( Step 2 ) to inform it what it needs to do.

You can import this workflow into you own instance of Octoblu and start working through the nodes and see how we built the request process.

Below is a quick screen shot of the existing workflow:

As a final note, this post is meant to be more of an overview of the process and few technical notes on how it was implemented. We are working on providing additional posts to drill down on each of the steps to have a clearer understanding of the entire process, but in the meantime download the code and workflows and let us know what you think.

As always, feel free to reach out to me on twitter (@johnmcbride) or leave a comment on the post with any questions or comments.

John McBride/Developer Advocate