Lessons Learned: passing parameters to your workflow

I just came off of a large UCMA 3.0 project writing an IVR app that records a voice mail and also allows you to customize your mailbox greeting. I spent lots of time on the project and learned quite a bit about how UCMA differs from the Speech Server apps that we are all used to building. I discovered some bugs (or undocumented features) and worked my way through some stuff that wasn’t well documented. It was tough at times but I learned a lot and now I am going to pass that on to you. I’ve decided to do a series of “Lessons Learned”. I’ll cover things that aren’t obvious, aren’t part of the default features and in one case a bug (or at least I think it is a bug). Unfortunately I can’t just post the complete code but I will post snippets where appropriate and you can fill in the connecting parts.

One of the things my app does is make a branching decision at the top. The same app handles both the voice mail recording function as well as the custom greeting recording. the app doesn’t prompt the caller for which action to take – it just “knows” and the caller has no idea that it is the same application doing both. It does this by looking at the SIP header as the custom greeting calls have a custom parameter in the SIP header. I’ll cover how to access the parameter value in another post. Today I’m going to assume you have it and now need to pass it into your work flow.

Every UCMA application should have an event handler to handle receiving calls. This event fires once the call comes in and is essentially where your code really starts running. The event should look like this:

       private static void AudioVideoCallReceived(object sender, CallReceivedEventArgs<AudioVideoCall> e)

Somewhere in the method (usually at the bottom) you call the method to create your workflow passing in any parameters that you need. In the code below I am passing in a string called resource that tells the workflow the type of call is coming in – voice mail or custom greeting:

            StartWorkflow(e.Call, e.RequestData, e.TransferredBy.ToString(), e.RemoteParticipant.ToString(), resource);

Back stepping slightly here but in order to pass something into your workflow you have to declare a variable in your workflow to receive it and setup a get/set for it. Once your workflow starts you can then access it like any other variable in your code:

        private string resource;

        public string Resource
            get { return resource; }
            set { resource = value; }

Now lets go back to the  StartWorkflow method as it is there that all of the magic occurs. First you need to create a Dictionary object then you need to add your variable to the Dictionary:

             // Create the parameters for the workflow
            Dictionary<string, object> parameters = new Dictionary<string, object>();

            parameters.Add(“Resource”, resource);

This is where it gets a little tricky. If you misspell  the parameter your workflow does not work and any error messages you may get don’t make any sense. Just make sure you spell the parameter names the same as the public parameter you created in your workflow code.

Now all that is left is to create the workflow passing in the  Dictionary object like this:

             WorkflowInstance workflowInstance = _workflowRuntime.CreateWorkflow(typeof(Workflow1), parameters);

The rest of the code for starting your can figure out from the code samples that Microsoft supplies when you install UCMA 3.0.

I’m going to try and post a new “Lessons Learned” post each week as my time permits.

I hope this helps. As always I would love to hear your feedback and questions on this post.


Leave a Reply

Your email address will not be published. Required fields are marked *