processi

about processes and engines

the “trouble ticket” process

If you’re interested in workflow and BPM, you have to follow Keith Swenson‘s blog.

Keith Swenson is at the head of Fujitsu Software BPM and workflow effort, he is also a member of the workflow management coalition, there are many things to learn from his work.

During this year switch period he produced three great posts about human processes. I will focus on one of them which is about a practical “trouble ticket” process.

Keith represented the process in a very readable BPMN diagram, he then discussed variants on it and why he was using “multiple conclusions” for the activities in the diagram, ie multiple exit arrows instead of one exit arrow followed by a branching diamond.

That got me wondering how I could ‘implement’ this process without using [apparent] branching constructs in the Ruote process definition language. How could I preserve some of the readability and elegance of the original diagram ?

OpenWFEru is block structured, not your usual state/transition workflow tool, but it can express that. I came up with an implementation. I chose to express it as Ruby code (instead of XML), it should be readable enough.

Yes, it’s an exercise in manually compiling from BPMN to the OpenWFEru process definition language (it could yield lessons for [automated] compilers).

class TroubleTicket01 < OpenWFE::ProcessDefinition
  
  #
  # The root of the process
  #
  sequence do

    #
    # the first activity, customer support
    #
    cs :activity => "enter details"

    #
    # initiating the first step
    #
    step :part => "qa", :desc => "reproduce problem"
  end
  
  #
  # At the core of the process, 
  # the 'step' subprocess
  #
  process_definition :name => "step" do
    sequence do

      # participant performs activity
      participant(
        :ref => "${part}", :activity => "${desc}")

      # then, call next step (via a subprocess)
      subprocess :ref => "${field:next}"

    end
  end

  #
  # The 'outputs' of the activities
  #
  
  # QA 'reproduce problem' outputs
  
  process_definition :name => "out:cannot_reproduce" do
    step :part => "cs", :desc => "correct report"
  end
  process_definition :name => "out:known_solution" do
    finalsteps
  end
  process_definition :name => "out:duplicate" do
    step :part => "qa", :desc => "verify"
  end
  process_definition :name => "out:reproduced" do
    step :part => "dev", :desc => "resolution"
  end
  

  # Customer Support 'correct report' outputs
  
  process_definition :name => "out:submit" do
    step :part => "qa", :desc => "reproduce problem"
  end
  process_definition :name => "out:give_up" do
    finalsteps
  end

  
  # QA 'verify' outputs
  
  process_definition :name => "out:qa_fixed" do
    finalsteps
  end
  process_definition :name => "out:not_fixed" do
    step :part => "dev", :desc => "resolution"
  end
  

  # dev 'resolution' outputs
  
  process_definition :name => "out:dev_fixed" do
    step :part => "qa", :desc => "verify"
  end
  
  set(
    :var => "out:not_a_bug", 
    :variable_value => "out:dev_fixed")
        # "not_a_bug" is an alias to "dev_fixed"
  

  # the final steps
  
  process_definition :name => "finalsteps" do
    concurrence do
      cs :activity => "communicate results"
      qa :activity => "audit"
    end
  end

end

This is quite long, but still shorter than an XPDL file (of course this OpenWFEru process definition doesn’t carry any graphical information as the XPDL one does).

The interesting part is in the 35 initial lines, where the “step” subprocess (you may think of it as a function) is defined and where there is the sequence that bootstraps the whole process (Customer Support enters the details then first step : QA attempts to reproduce problem).

The rest of the process definition, is, well, transitions. Did I end up mimicking a a state/transition system here ? Well, I haven’t given much thought about it, but my intuition says ‘yes’.

There are no apparent “ifs”, they are somehow hidden in the “step” subprocess, coupled with the ‘transitions as subprocesses’ that might qualify as ‘elegant’.

Swenson-san discusses in his post implied loops, OpenWFEru has cursor and loop expressions that might have qualified for the implementation.

  cursor do
    participant :ref => "dev", :activity => "resolution"
    participant :ref => "qa", :activity => "verify"
  end

With this “cursor” the participant QA can decide on handing back the work[item] to the Developement participant, that’s a nice to have. I preferred to stick with the “step” solution. Using a “cursor” leads to a flatter process execution stack, the presented implementation may potentially build big “execution trees” but hopefully, quoting Keith :

It could be passed back and forth between these people any number of times. In reality of course these are people performing the activities, so if it goes too many times they are likely to take steps to find out why it is taking so many step, or possibly to escalate to management.

A process definition should not be exempted from testing, so I have wrapped this implementation in a functional test. A single test looks like :

  dotest(
    [ "", "reproduced", "dev_fixed", "qa_fixed" ],
    [ "cs", "qa", "dev", "qa", "cs", "qa" ])

The first array are the activity conclusions (in order) and the second one is the expected trace through the process. (there is a small glitch with this test suite, the final, concurrent “cs” and “qa” might come out as “qa” then “cs”, so the test might fail for that, I’ll correct that in a future version of the test).

As a further refinement, when calling the “step” process, the possible outcomes/transitions could be passed as a list, that would help in the ‘participant’ implementation/settings :

  step(
    :part => "qa", 
    :desc => "verify", 
    :outcomes => "fixed, not_fixed")

Maybe that “step” subprocess could be extracted and become a first class OpenWFEru expression, reusable by many other process definitions, maybe not.

In a future post, I shall explain how to use Densha to host this business process, for real participants, not test dummies.

Written by John Mettraux

January 4, 2008 at 5:14 am

Posted in bpm, bpmn, openwferu, ruby, workflow

One Response

Subscribe to comments with RSS.

  1. […] already took a look at that in a former post, the trouble ticket. The transformation (from BPMN to OpenWFEru) was manual. The resulting process definition used a […]


Comments are closed.

%d bloggers like this: