Workflow Service to guide client with next possible steps

2
votes

Workflow Service consumes user input using Receive activities. Workflow does some work upon getting data from caller using business logic embedded in Workflow. This sounds great with one exception. How caller may know what is next Workflow step should be?

For example we have document processing Workflow. New Workflow instance is created when document come to the system.

After creation, document can be validated by different managers, sent request for additional info, Reviewed, Closed, Canceled, Merged and etc. Order of possible operations is stored in workflow. Operations are performed outside of Workflow and communicated to workflow through several published Receive activity. Order of these Receive operation is inside Workflow (it is actually what Workflow is).

Logic may be different from department to department. So we do not want to hardcode it outside of our workflow.

Now document processing is in the following state:

  1. Previous Receive activity was performed
  2. Workflow did some work and now persisted
  3. Workflow can be woke-up if User perform some operation and call next Receive activity

The question is how external code may know what that operation is and what Receive end-point is waiting should be called?

Is there any easy way to ask Workflow what are possible next steps to use that information in GUI?

1
.networkflowworkflow-foundation-4workflowservice

1 Answers

1
votes

Here is a blog article by Ron Jacobs that will walk you through extending registration with WF 4 - this should get you the foundation you need to build what you're needing.

http://blogs.msdn.com/b/rjacobs/archive/2012/05/06/extending-asp-net-mvc-account-registration-with-workflow-wf4.aspx

Edited to better address the issue of "knowing the next state".

Okay there isn't going to be a way to query the workflow, and the primary reason for that is because the workflow service runs on the WSH and when it hits a new bookmark(s) it's idled (you never know where it's really running). So, your best bet is to publish that information before idling and I would recommend publishing it to the caller via a Reply because that's the ideal time for the UX to respond.

Edited to provide a link that may be the "magic" you're looking for.

This is a video on Channel 9 by @RonJacobs - this guy is amazing really because he works really hard for the developers - and I think it may be the magic you're looking for. However, it may require you to update the version you're using, but it may not. You will probably also need to get the Microsoft.Activities.Extensions NuGet package if you don't already. I've used his custom tracking mechanisms already for unit testing but not for this. Let me know what you find out!

http://channel9.msdn.com/Shows/Workflow-TV/Workflow-TV-Tracking-StateMachines