Question on choosing state machine for my scenario - 5 different event driven jobs. RRS feed

  • Question

  • Hi,

    I have a scenario that is possibly suited for state machine workflow.

    Please throw some light if my scenario is best suited for state machine.

    I have 5 different jobs that are currently running based on different scenarios - All of my jobs are event driven.

    Of which 2 jobs are controlled through autosys which will invoke 2 different .net console apps.
    These two jobs runs on a daily basis in two different times. These jobs queries SQL database and update some tables and send some information to external systems.

    There is one more job running as windows service which listens to a windows folder for a file which will be uploaded by an external system in different times and the service will process the file.

    There is one more job triggered by the user action an UI.

    And finally one more job which listens to MQ queue and processes the incoming message.

    All of these jobs are unrelated to each other in terms of their operations, but they are logically related as these jobs are either talking to the same Business Tire or same database for processing one business request.

    My question is - would it be suitable to select state machine workflow as the solution to integrate all these jobs into one workflow?

    2 jobs are time driven
    1 job is based on arrival of a file in a FTP location
    1 job is based on user action
    1 job is based on arrival of message in MQ queue


    Friday, March 2, 2012 5:16 AM


  • TechV,

    You mention that,  "All of my jobs are event driven", but state machines were designed to execute based on human response.

    Some background on state machines:

    State machine workflows are designed to be driven by human intervention or events. You can design state machine patterns using FlowChart workflows, but since the release of .Net 4.1, state machine workflows are a better choice. State machine workflows carry the concept of managing state within a workflow, so as business logic progresses, it is always within a "current state" while it waits for a humanistic event.

    Now the cool thing is that state machine and flowchart can be combind within the same workflow, but the business logic modeled should be related in some form. For instance, based on your tasks:  

    2 jobs are time driven=>flowchart, sequential
    1 job is based on arrival of a file in a FTP location=>flowchart, sequential
    1 job is based on user action=>State machine
    1 job is based on arrival of message in MQ queue=>flowchart sequential(not human because waiting on message)

    If these tasks are not related, then I would recommend that they reside within their own workflow of execution, however if they are dependant on one another, then they can be combinded, but based on your post I don't believe that's the case. Just my two cents without knowing the business process:

    Blogging at Humanworkflow.net

    • Marked as answer by LeoTang Sunday, March 11, 2012 7:56 AM
    Monday, March 5, 2012 4:06 PM