Creating subflows
Recently I was working on setting up an application where I wanted different pieces of the call flow to be placed in separate work flows or at least segmented out so that multiple developers can work on the different pieces. The desire was to do this in a way that I could easily add the different pieces into the main work flow. Think of this as having the main menu in the main work flow then having components and sub menus setting off in a separate work flows that I could drag and drop into the main workflow as needed. In order for this to work I had two requirements:
- Each subflow needs to be able to see and set values in the main work flow
- The main work flow needs to be able to see and set values in the subflows
This post is going to show you how I accomplished this. First though I want to note that there are probably other ways of doing this and you may have hit on a better way of accomplishing this task. Also note that the term "subflow" is not terminology you will find in Microsoft documentation.
The first thing I did was create a new speech workflow application and dragged a few activities into the designer. There is nothing special here and it is something that you have done before.
Next you right click the project and chose Add/New Item fro the popup menu. This opens the new item window and presents a list of templates. Highlight "Voice Response Sequence Activity" and set the name for your subflow then click Add. Visual studio will create a new partial class and add it to your project.
After building your project you should see an new item in the toolbox that has a purple sprocket or cog for an icon that is named the same as the new class you created. This can be added to your workflow by dragging and dropping it into the designer like you drop any other component.
By default the component shows in your workflow as just a container - in other words in the main workflow you want be able to see any of the activities in your subflow -
But if you look closely at the first code example shown below you will see a line that starts with "[Designer (typeof(System.Workflow........]". All you have to do is comment out that line and your subflow will now show it's activities (you must rebuild your app first). You should also notice either a "+" or a "-" next to the name of the sublfow. You can click on this to show or hide the activities in the subflow.
Now that we have the necessary pieces we need to establish a way that they can communicate with each other. This is not as simple as you may think because if you simply create public variables with setter/getter logic you will find that variables are not getting set property. You will encounter problems with scope of the objects and the timing of when they are created as the work flow engine creates/clones your subflows. To make this work you will need to create the public variables and a static InstanceDependencyProperty so that they can accessed when your subflow isn't running. It's really very simple as this code example shows.
Note that in the code above we also declared a private variable called parentWorkflow. Once the subflow starts you need to set it so that it points to the main workflow like I show below.
If you don't so this then you won't be able to reference variables (including the call related stuff) in the main workflow. Once you have done this you have full use of IntelliSense for variables residing in the main work flow. Note - I realize there is a syntax error in the code shown below but I didn't want to upload another image and it doesn't affect what I'm trying to demonstrate.
To access subflow variables from the main workflow you simply reference the public variable you declared in the subflow. The magic behind the InstanceDependencyProperty that you created above makes this all work.
That's all there is to it and as I said earlier there may be other ways of doing this but this is what I settled on and it works for me.
I would love to hear how you approach this process and if you have any improevements then let me know.