Questions on workflow types

Hello,

< xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /> 

I have a number of questions about workflow types.  As I understand it, there are two workflow types available out-of-the-box with WWF: sequential and state machine.  With sequential workflows, I believe the flow is generally top down from the initial activity to a final activity.  The path is well defined; activities like ‘While’ allow the workflow to repeat contained activities and the ‘IfElse’ activity allows the workflow author to conditionally execute branches of related activities, which are embedded in the container ‘IfElse’ activity.  In contrast, the state machine workflow is much more adhoc and driven by external (often human) input; the workflow can jump from state to state in many ways.  Some good guidance on how to choose which workflow type to use when is presented here (http://blogs.msdn.com/davegreen/archive/2005/10/20/483309.aspx). First question: do I have this right so far

 

If my understanding above is correct, then it seems to me that with a sequential workflow, you cannot ‘go to’ an activity, unless that activity is explicitly embedded in container composite activity.  For example, the IfElse activity allows one to drop (and execute) activities in each of its branches, but has no facility to call an activity defined earlier in the workflow (outside the composite IfElse activity) or any activity otherwise not embedded in the IfElse activity.  So, using a sequential workflow, it wouldn’t be possible to visually model a workflow in the traditional flowchart format, as shown in Figure 1 of http://msdn.microsoft.com/windowsvista/building/workflow/default.aspx pull=/library/en-us/dnlong/html/WWFIntro.asp   Is this correct

 

As I understand it, a hybrid model can be used with the top level model being a state machine and, within each state, elements of a sequential workflow can be defined.  I don’t believe the reverse can be done; that is, I can’t have my top level workflow be a sequential workflow and embed elements of a state machine workflow.  Is this right

 

If my understanding is still correct, then I believe that the only way I could achieve the traditional flowchart diagram format, would be to create a custom workflow type.  This is mentioned as being possible in http://msdn.microsoft.com/windowsvista/building/workflow/default.aspx pull=/library/en-us/dnlong/html/WWFIntro.asp.  Would this be the best way to achieve this   How would I go about doing this   I’ve not found any documentation or samples anywhere describing how to do this.

 

Thank you! Notre



Answer this question

Questions on workflow types

  • cabhijeet

    Thanks for your reply Arjun.  This sounds promising.  Will Beta2 provide any documentation/samples/resources on how to create a new workflow type   Also, more information on the free-form designer infrastructure would be very welcome.  I'm eager to see Beta 2!

    (Bill, please see my response to your question, two posts up).

  • wave702

    Question 1:  Yes..

    Question 2:  Yes and No:  You can use a While loop to continually run the same set of activities.

    Question 3: You can have a State workflow invoked from a Sequential, but in my mind, it would REALLY depend on what you are trying to accomplish.

    Question 4:  You can create all kinds of custom activities to assist you in your workflow.  

    Bottom line:  What are you trying to do with your workflow.

    Cheers,

    Bill



  • vcp_learner

    Notre,

    thanks for your detailed reply.   I was getting to the Beta 2 side of the house, and what it can offer to you.

    thank you Arjun for filling in while I was away for a few hours..

    Cheers,

    Bill

  • David Strommer

    Notre.. 

    Thanks for getting back with me.

    I'm trying to understand your first goal of a Flowchart Model for a Workflow.  You can create custom activites, but I don't really see or understand your need for a new workflow type.   We are incredibly flexible win our Sequential and State Machine workflows.  I've gone back 10-13 years on some of my older programs, and was able to port 80% of them to workflow models.  The other 20% are teh programs that I've not had time to work yet.  
    Yes, there will be some modification to the way the program works, but in the long run, I've only found one part that I really had to re-architech to fit into a Workflow.

    Sequential WF's are a general top down flow as you said.   You can loop thru activities, but it can get a bit cumbersome if your loops are really messy.

    Judging from you diagrams, you appear to be trying to bail out of a loop when a certain condition exists, and then either continue within the loop or exit out of the loop.  Is this correct

    Looking at your design and what you are trying to do, I'd use a State Machine WF, intead of a Sequential. 

    This will allow you to have extremely flexible WF models and will allow you to move to just about any place in your state model.   You can have as many states as you wish.  In some of our examples, we only show you four(4), but you can have more than that.

    As for my statement of invoking a State WF from a Sequential:  it is possible, but I really cannot see the need for it.  The other way around is better:  Invoking a Sequential from a State. And yes,  When you invoke a workflow, the invoke is calling another workflow.   It can be in the same project, but it is a new workflow.

    I hope this helps,

    Cheers,

    Bill



  • Promit

    Thank you very much for your reply Bill.

    I have a few goals in mind.  First, I would like to visually represent workflow in the traditional flowchart manner.  This is demonstrated in figure 1 of http://msdn.microsoft.com/windowsvista/building/workflow/default.aspx pull=/library/en-us/dnlong/html/WWFIntro.asp.  If you compare figure 1 to figure 3 in that document, you'll see a few significant differences (other than the fact they are modeling completely different workflows Smile ).  In figure 1, the classic diamond is used to represent a decision point and boxes are used to represents process steps in the flowchart.  You'll note that in figure 1 the diamonds branch to boxes, which in turn branch to more diamonds and boxes.  Conceivably, more than one diamond / decision point could be chained together directly, without an intermediate process step box (please excuse the crude drawings):




    One could conceivably combine the two triangles into one and make a more complex expression, but the ability to express this as chained diamonds may sometimes be useful.  More interesting is where a logic branch leads back to an earlier portion of the workflow.  This is illustrated in figure 1 of the document with the "Get acceptance or rejection" arrow leading out of the "Reject applicant" box.  I will draw another diagram to hopefully more clearly illustrate the possibility:



    Here, one of the 'exits' from D2 feeds back into P1.  This is quite different from what we see in a WWF sequential workflow.  In WWF, an "IfElse" activity would embed activities that make up the conditional branch.  I don't know if there would be a way to go back to an earlier point in the process, unless the case was modeled using a looping primitive, like the "While" activity.  This would certainly work, but detracts from the spirit of the flowchart and imposes a quite different mental model on the workflow creator.  Here's a rough sketch of the structure using WWF primitives:



    I've tried to use the same labels on the WWF sequence diagram as on the flowchart diagram shown earlier.  (Note that the above image looks grainy when viewed on the forum, but if you save it to your computer and view with Paint it's a lot more legible).

    In my mind, in the WWF sequence diagram things must follow a general top down flow.  In other words, the WWF sequence diagram is imposing structured programming, something which the flowchart does not impose.  The flowchart model allows the combination of conditionals with looping structures by effectively allowing the 'go to' command.

    I imagine that a lot of developers might balk at the use of a 'go to' statement.  But my audience is not developers; it is business analysts and end users.  I believer these actors would be more comfortable with the flowchart model, and therefore this is something I would like to investigate.  Note that the state model diagram also employs the SetState activity, which is effectively a 'go to' statement.

    So, my first goal is to investigate and possibly implement a flowchart model of workflow.  It is my belief (and this is certainly something I'd like clarification on), that in order to implement a flowchart model, I would need to define a new workflow type, other than the sequential or state models.

    My second goal then is related to the first: how would I go about starting to implement my own workflow model type   I'm initially interested in the design time perspective but I anticipate that I would need to define my own runtime model as well.  Even outside of the flowchart custom workflow model (say for example I can implement this to my satisfaction using custom activities), I would like to have a better understanding of what it means to create a custom workflow type, and to review and resources available on the topic.

    I'm also quite interested in your comment here: "You can have a State workflow invoked from a Sequential, but in my mind, it would REALLY depend on what you are trying to accomplish."  How would I invoke a state workflow initiated from a sequential workflow; unless they're actually two different workflows and the sequential workflow calls into a state machine workflow using the InvokeWorkflow activity

    Thanks and sorry for the long post!
    Notre

  • Rajen Suchede

    Notre,

    Thanks for making such a detailed post!  The Sequential and State Machine workflows are two models that capture unique ways of modeling work - process driven, and human driven, respectively.  As Bill mentioned, most workflow can be modeled using these types.  However, I could certainly understand with wanting workflow to be represented in a manner that makes more sense to analysts and higher-level process modelers.  

    You are correct in that you would need a new workflow type to capture way in which to model flowchart-like processes.  Beta2 will include free-form designer infrastructure (used by the state machine designer) that will enable this from a designer tool perspective.  From a runtime and activities standpoint, you'll need a new set of activities to represent shapes like the decision diamond.  I could easily envision a decision activity that uses a condition to decide which activity to execute next.  Unlike the traditional IfElse branch, the next activity in the flowchart model could be any activity in the flow, as opposed to a direct child.

    I hope this helps.  I think this is a great idea and would be a very cool application of the WF framework!

    Arjun

  • Biber Technology

    Hi Bill,

    I understand and respect the flexibility and power of the sequential and state machine workflow types.  As noted in the 'Presenting Windows Workflow Foundation' book (in the chapter on state machine workflow), it's theoretically possible to model pretty much all business processes using a sequential workflow type.  But, as the book notes, it's not the best way to model a certain category of workflows. 

    Likewise, it is possible to use the sequential workflow model in place of a flowchart model.  In my pseudo-models above, I expressed a certain workflow using a flowchart and followed that by an alternative implementation of the workflow using a state machine.  My point is that while the sequential workflow is sufficient, it is not the ideal approach in all cases.   Workflows do not live in isolation from the people that create them; a traditional software developer is well versed in the use of structured programming and is comfortable thinking in such a manner.  But a business analyst or average business user is not a developer; they may be quick to grasp the use of a flowchart to express the logic of a system but don't have the patience or background to write a structured program.  I want to cater to this group of users as much as possible since, although they are not the best developers, they are (presumably) the domain experts.  The user interface for designing workflows in Visual Studio is explicitly targeted at developers (as noted in the book and in other resources).  This is not my primary intended audience.  Much as MS Office, with its share point designer (which I'm just starting to investigate), realizes that many of its authors are not developers (coders), neither are my app's users.

    So what does the flowchart model offer that the sequential model does not   The flowchart blurs the distinction between the need for formal looping structure/primitives and conditional structure/primitives.  The diamond acts as a decision point; it says, given some expression it will evaluate to a distinct value; based on the evaluated result, a specific 'action' (process step, represented by the box; not to be confused with a WWF action) should be executed by means of calling a given process.  Loops are defined by connecting an output (exit) from a diamond (decision point) to some other item in the flowchart; if it happens to be an earlier item then a loop is created.  There's no need for a formal 'while', 'foreach', etc loop structure; the author of the workflow needs only to be concerned with (different types of) process (box) steps (i.e. different activities), diamonds (to set up decision points), and lines between the diamonds and boxes to establish the flow.

    The use of a flowchart is closely related to a sequential diagram; I would argue that it's more closely related to the sequential diagram than a state machine diagram.  As noted in Dave Green's blog (noted on initial post), the state machine diagram is not 'in control', it's largely reactive to external events.  The flow chart model is 'in control', much like the sequence diagram; it's just that it's a little more free form and flexible.  I acknowledge that in many ways there's a good reason for the structure of the sequence workflow, but it's a tradeoff that's probably worth the cost (to me) if it opens up workflow authoring to a larger audience of users.

    Notre

  • Questions on workflow types