UCMA Workflow SDK services: CommunicationsWorkflowRuntimeService & TrackingDataWorkflowRuntimeService

In a previous post I mentioned two services which I created as part of an example in setting up a new UCMA Workflow application, but didn’t go into much detail. I’d like to rectify that now.

CommunicationsWorkflowRuntimeService

This service is required if you want to use Workflow (without errors anyway!). If you think about it, you’re using standard Windows Workflow components to build a standard Windows Workflow workflow which, by itself, won’t know anything about Lync or UCMA. That’s where this service comes in – it bridges the gap and passes through information such as calls and conversations from UCMA.

You can see this happening if you examine the code. Incoming Lync calls are actually passed (EnqueueCall‘d) to an instance of this service – NOT the workflow itself.

TrackingDataWorkflowRuntimeService

This isn’t actually required, even though I included it in the example. It’s an optional extra you can use to track communication data. What’s communication data? It’s “what was said”, either by the UCMA application as part of a speech statement or question, or by the user as part of an answer, either speech or DTMF tones.

If you do include it, then you can take advantage of it in your workflow. You can use it in any of the following shapes:

• speechStatement
• speechQuestionAnswer
• instantMessagingStatement
• instantMessagingQuestionAnswer

Each of those shapes has a IsTrackingDataEnabled property which you can set to True. This means that, once the shape been hit, relevant data about what was said will be added to the Tracking Service. You have to opt-in each shape though if you want data from that shape to be stored. The data stored will be the MainPrompt data and any response values. You can also programmatically add entries to the Tracking Service, which might be useful if you’re developing your own shapes and want to log some pertinent event.

Why might this be useful? Well, useful for logging and auditing purposes, and some companies will have compliance issues with IVRs where they need to record what the customer has been told, and what information they provided to an IVR. Also, in IVR solutions which involve collecting data automatically and then transferring to a human, information about the questions the caller has already been asked and the responses can be sent to the agent handling the call to provide more information.

Here’s a simple, not-production-ready, example of accessing the tracking data of a workflow instance. It’s worth pointing out that if you want the information, you have to make sure you get it whilst you still have the workflow instance as once the instance is deleted, so is all that lovely tracking information:

 TrackingDataWorkflowRuntimeService service = executionContext.GetService<TrackingDataWorkflowRuntimeService>();
	  Collection<ActivityTrackingData> list = service.GetTrackingData(WorkflowInstanceId);

		try
		{
			StringBuilder context = new StringBuilder();
			XmlSerializer serializer = new XmlSerializer(typeof(Collection<ActivityTrackingData>));
			StringWriter stringWriter = new StringWriter();

			serializer.Serialize(stringWriter, list);

			string callContext = stringWriter.ToString();
			stringWriter.Close();
						   
			System.IO.File.WriteAllText(@"log\\" + WorkflowCall.CallId + ".txt", callContext);
			
		}

		catch (InvalidOperationException invalidOpException)
		{
			Console.WriteLine(invalidOpException.Message);
		}

Potentially, a good place to collect this is on the CallDisconnected Event of the communicationSequence which contains the shapes you want to track. That way, it’ll fire after the call is disconnected when nothing more can happen, but just before the instance is deleted.