locked
Bidding process for many specialties replicated in Workflow RRS feed

  • General discussion

  • Preface: Hey – it works…

     

    A common scenario for many businesses (especially construction) is for a company (the general contractor in this case) to send out bids in specialty areas – concrete, electric, heating, steel, roofing for instance -- and receive replies.  The general contractor does not want to start the construction necessarily until a number of bids is received in each specialty and until there is at least one bid per specialty. 

     

    Let’s say I use a Parallel activity that holds the workflows for the specialties – again, concrete, electric, heating, steel…  And let’s say that the parallel workflows send out messages to a number of preselected contractors in each specialty. A number of other requirements must be met. At some point in time – a specific date --, the bidding process stops.  Additionally, the project may be cancelled at any point. Also, other bidders should be able to be added at any time in each specialty, and some  bidders should be able to be removed by the general contractor. 

     

    I therefore envision that the Parallel holds specialties (via Whiles and Picks) within their own Parallels. The Whiles would continue to gather bids until the While condition is broken by a “Cancel Bid” Pick Branch, a “Cancel Project” Pick Branch, or the While Date condition is broken. These “Receive Bid” Pick Branches would require that the Receives have CanCreateInstance equal true in order that many bids can be requested (and receive responses). A Job Guid would have to hold all of this together.

     

    The problem I see with this scenario is that a “Receive Bid” Pick Branch may end up waiting for a response (from a bidder). Therefore, the workflow is never completed.  In order to counter this, each While requires within it, a Pick with Pick Branches with Receives that can break the wait… That is to say, for every “Bid” Receive Pick Branch, there must be a concomitant “Kill It” Receive Pick Branch. 

     

    If all specialties receive at least one bid and the cutoff date is reached, the workflow would send out a “Kill it” to all specialties in order to have the “Kill it” branches overtake the “Receive Bid” branches within each While. Thus the workflow can complete.

     

    …Starting to get really complicated…   While this all works, I feel that I must be missing something.  This is seemingly, an oft-used business process.

     

    When laying this out (and as a newbie to workflow), I was a bit surprised that there is so little “trigger” type activities – essentially the “Receive.”  Granted, I was able to send out messages from one part of the workflow to another by essentially sending a “Receive” type message, I would think there would be a simpler way – even a direct call.

     

    Any ideas of what workflow pattern/activity I am looking for in order to simplify this?

     

    (Parenthetically, I am using Silverlight as a test bed since I can become both the owner of the workflow (as a service of course) and the responder to the workflow with ease in a single interface... Nice combination...) 

     


    bruce chase
    Tuesday, January 11, 2011 8:23 PM

All replies

  • Hi Bruce,
    It's a late reply so I guess either you're well into the scenario by now or have given up. The overall parallelism via Parallel activity or ParallelForEach, or something like that sounds good.

    The first bit that sounds weird is having CreateFirstInstance on multiple receive bidding branches. Only one receive activity in the workflow will create any particular workflow instance. You're allowing for any bid to start the workflow, but to me it sounds like the overall business process is not really started by receiving a bid, the workflow is started by requesting bids from the bidders (by some mechanism), and you would really want to be correlating bids to the initial workflow that requested bids.

    You're right that out of the box workflow gives you very few ways to receive events. Receive activity is basically it. The reason is that in order for the workflow to be persistable and rehydratable, the ultimate work of listening for events needs to be done by a host, who is responsible for waking up activities. And the only host shipped with .net 4 which does this kind of stuff is the WorkflowServiceHost, and the only thing that knows about is WCF style communication and the Receive activity.

    So basically you end up with two options for events which is force yourself into communicating via those WCF messaging activities, or roll your own 'ReceiveEvent' activity (or many receive event activity types), which you can make work by customizing the hosting story to work based on your favorite way. (I hear you can still use WorkflowServiceHost for custom eventing schemes, and that it provides some helpful functionality with the instance management but I don't really know about this.)

    On the bright side, WCF is fairly versatile - configurabile, and extensible, and able to communicate to some services already out there.

    On the opposing less bright side, it's a fair investment of time to learn about workflow enough in order to see how to write your own host and ReceiveEvent activities.

    I would guess that it's likely that as WF is adapted in various hosting scenarios (by ISVs or by MS) we'll see more 'messaging' type activities like Receive which let you do things appropriate to the hosting scenario. Like I can imagine someone using WF to drive an email marketing campaign, and having a Receive which is based GET web requests coming into their host, or a host which reacting to email replies but which it does via checking mail on the mail server in polling fashion (your host doesn't actually have to be event driven it just helps).

    Well that's my perspective!

    Anyhow, would be interested to hear how the parallel idea worked out.

    Regards,
    Tim

    Wednesday, March 30, 2011 7:25 AM