dhis2-devs team mailing list archive

[Bob Jolliffe <bobjolliffe@xxxxxxxxx>]

Saptarshi,

2009/6/9 Saptarshi Purkayastha <sunbiz@xxxxxxxxx>:
>>
>> I'm not sure what happened to the BPEL eclipse project
>> (http://www.eclipse.org/bpel/) which would give us all this in a
>> standard way.  I know the Alfresco DMS uses BPEL as a workflow engine.
>>  I'll take a look and see.  Might be too heavy a hammer to crack this
>> nut.  On the other hand it might be quite light and elegant.
>
> BPEL would surely be a heavy hammer. I think there is not a lot of Business
> "Process" involved in all of this. Its mostly just collecting data on these
> forms and not a long logic of things to be done with the data.
>

Yes I know we've had this discussion before and in my heart of hearts
I know you are right.  BPEL is too much.  Nevertheless I think it
makes sense to think in terms of a process (I dislike the word
business in this context) and that we might look for a bit of
inspiration to the modelling languages.  For one thing it is not just
the data which is being processed.  I see that, whereas BPEL was
initially focussed on automated processes only, there is a growing
awareness (and emerging standard) for a BPEL4People which also takes
into account people-acted or people-executed processes.  Other minor
process languages like YAWL already take this into account.  I just
want to be sure we don't end up with a naive implementation which
misses some fundamental process modelling patterns
(http://yawlfoundation.org/resources/patterns.html).

Perhaps what I'm really saying is that (now that we have achieved some
sort of consensus around the data part of the model) its time to start
looking at the actions and methods of our objects - and in particular
the ActivityPlan which is by far the most interesting of our new
objects.  I'd like to think of the ActivityPlan not just as a set of
visits but as a sort of a workflow process, with a beginning and an
end and a bundle of states and activities along the way.  And after
its run to its conclusion it will have spawned a whole lot of
encounters and collected some data values (or been cancelled or
aborted or transferred or ..).  It will provide input to the
generation of the next Activity plan after which it can be disposed of
or more probably archived.  This thinking was rekindled when I saw the
'supervisor' and 'hew' (the supervisor approval is really like a state
variable in the activity state machine).  Agreed we might not need a
fully fledged language and engine to describe it.  But we should
certainly allow for some flexible and unforeseen variations of what we
currently understand of the concrete Indian ActivityPlan.  Give it
some thought anyway.

Regards
Bob