BPM for developers, extended

BPM for developers:
improve agility of
implementations –
“Extended”
A. Samarin
More about slides 32, 33 and 34 of the
http://fr.slideshare.net/samarin/bpm-for-
developers

• After a few discussions linked to “BPM for developers”
presentation http://fr.slideshare.net/samarin/bpm-for-
developers I found that some slides (namely 32, 33 and
34) are too “condensed” thus difficult to understand
• This presentation gives more details about those slides
• The topics discussed are only about the automation
© A. Samarin 2013 BPM for developers "extended", v1 2
WHY this second presentation

• Speed of developing automation is the primary factor of
agility of a process-centric solution
• Automation and process template have different speed of
changes – keep automation outside the process template
• Automation may be long-running and resource-consuming
• Automation may and will fail
• Failures maybe because of technical (no access to a web
service) or business (missing important data) reasons
• Recovery after failure should be easy
• Automation’s problems (failures, resource consuming)
must not undermine the performance of process engine
Concerns about automation

• Why:
– Process template is a composition of many other artefacts
(events, data, documents, KPIs, services, etc.)
– Those artefacts have their own evolution speed
– Some changes are not under your control
• Process templates, XSD, WSDL, services, namespaces,
documents, etc. must be explicitly versioned
• Many versions of the “same” should easily co-exist
• Use the simplest version schema – just sequential
numbering: 1, 2, 3, …
• At the same time, keep the possibility to refer to the
“current” version
Explicit versioning of everything (1)

• A typical use (which is often a compliance requirement):
– Since 1st of April all new process instances will use process
template v2
– Already running process instances must remain at process
template v1
• Another typical use (from the real life):
– Since 1st of April all new process instances will use process
template v2
– Some already running process instances will remain at process
template v1 (if those instances are close to the completion)
– Some already running process instances may be migrated to
process template v2 (if those instances are far from the
completion)
Explicit versioning of everything (2)

• There are two major patterns for mixing human and
automation activities
• Pre Do Post pattern in which each human activity (DO) is
surrounded by automated activities (PRE and POST)
• The rationale:
– to reduce human’s non-productive work, data, documents,
information must be prepared in advance
– the results of human’s
work should be placed in
different repositories
– pre- and post- for the whole
process
Mixing human and automated activities (1)
PRE
POST
DO

• Error Recovery Loop is the other pattern which mandates
a human intervention for the recovery of a failed
automated activity
• The rationale:
– explicit catch of exceptions
– ability to assign “recovery” human activity
to different roles depending the nature of
exception (bypass the service desk)
– maybe implemented as a container without
exposure to the process
• Relates to other techniques:
– dynamic (interpretive) language
– idempotency
Recover
Work

• At the same time, small fragments of automation may be
used to react on different events related to a particular
human activity (as in Bonita); those fragments are event
handlers (and not the automation per se):
– ready (available to be claimed)
– claim (assign yourself to a human activity which is ready)
– unclaim (opposite to claim)
– suspend (stop temporary)
– resume (after suspending)
– delegate (reassign somebody for your human activity)
– send for review (delegate and ask to return the activity to you)
– done (or complete; maybe with some qualifiers or dispositions)
– terminate (or cancel; some kind of exception)
– exception (escalate, timeout, etc.)

• Automated activities are usually built on existing APIs to
access different enterprise systems and repositories
• Automation looks like scripting
• Interpretive language (no need to recompile) are good for
scripting
• Combine dynamic and static programming languages, for
example, Jython and Java, Groovy and Java, etc.
• Use the strong typing to secure interfaces, enjoy
introspection, and avoid exotic features
• Automation scripts must be kept outside process
templates to allow modifications even within a process
instance
Use dynamic (interpretive) language

• Use “robot” (an external to the process engine) program
to execute scripts
• Universal robots and specialised robots may co-exist
• Robots must be clonable (for scalability, load-balancing
and fault-tolerance)
• Integration patterns between the process engine and
robots (scripts are passed by reference):
1. Human activity is assigned to a robot or group of robots; each
robot is systematically checking its inbox (poor-man solution)
2. Process engine queues (via a WS) work for robots; the queue
manager dispatches work requests to robots (ideal solution)
• A crash of a robot will not disturb the process engine (last
an activity will be “late” or “overdue”)
Execution of automation scripts

• Typical sequence
1. Exception is raised in an automation script of an automated
activity
2. The process instance is routed to the recovery human activity
3. A responsible person makes necessary corrections (up to
modifying the automation script) and completes this human
activity
4. The process instance is routed to the automated activity
5. The automation script is executed again
• Idempotency of automated scripts is a must
Error recovery loop

• Idempotence (pron.: /ˌaɪdɨmˌpoʊtəns/ EYE-dəm-POH-
təns) is the property of certain operations, that can be
applied multiple times without changing the result beyond
the initial application
• This an automation script is a collection of idempotent
invocations of some services; a typical execution
sequence for services A, and B:
1. Start of the automation script
2. Invocation of service A – OK
3. Invocation of service B – exception
4. Re-start of the automation script (due to error recovery loop)
5. Invocation of service A – OK (due to idempotency)
6. Invocation of service B – OK
7. End of the automation script
Idempotence

• Automation script are actually executed by “system”
account
• But, in some case, they have to pretend to be as one of
the participants in the process instance; for example, a
submitted document should be owned by the submitter
• Automation script must have reach access to process
instance (BPM API) and be able to impersonate (change
account)
Impersonating

• Ruthless monitoring of all services (including robots, other
systems and repositories)
• Not just checking that a port is bound, but asking to do a
real work; for example, echo-test
• Service should be developed in the way to facilitate such
a monitoring
• System should be developed in a way to facilitate such a
monitoring
• Also, robots proactively (before executing automation
scripts) must check (via monitoring) the availability of
services to be used in a particular automation script
• It is better to wait a little than recover from an error
Monitoring

Thanks

• Mixing human and automated activities
• Each human activity may be surrounded by two
automated activities (pre-processing and post-processing)
© A. Samarin 2013 BPM for developers, v1 16
Look at automation within processes

• Explicit versioning of everything (another topic for
developers)
• Keep automation outside the process template (as they
have different speed of changes)
• Use an interpretive language for automation scripting (no
need to recompile)
• Use recovery loops (preserve
instance, carry out quick corrections in
“this” instance)
• Smart error handling (bypass some
levels of support)
Speed of developing automation is the
primary factor of agility

• Combine static and dynamic programming languages
• Use the strong typing, introspection, no exotic features
• Use external (to process engine) universal program
(robot) to execute automation scripts (scalability)
• Assign automated activities to robots (potential use of
specialised robots)
• Multiple robots (load balancing)
• Process engine queues jobs for robots
• Proactive monitoring of resource availability (better to
wait a little than recover from an error)
• Idempotency
More tricks

BPM for developers, extended

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à BPM for developers, extended

Similaire à BPM for developers, extended (20)

Plus de Alexander SAMARIN

Plus de Alexander SAMARIN (20)

Dernier

Dernier (20)

BPM for developers, extended