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

http://fr.slideshare.net/samarin/bpm-for-developers


BPM for developers "extended", v1 2

• 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

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

© A. Samarin 2013

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

© A. Samarin 2013

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)

© A. Samarin 2013

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’swork should be placed indifferent repositories

– pre- and post- for the wholeprocess

© A. Samarin 2013

Mixing human and automated activities (1)

PREPOST

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 activityto different roles depending the nature of exception (bypass the service desk)

– maybe implemented as a container withoutexposure to the process

• Relates to other techniques:

– dynamic (interpretive) language

– idempotency© A. Samarin 2013


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.)

© A. Samarin 2013



• 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

© A. Samarin 2013

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”)

© A. Samarin 2013

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

© A. Samarin 2013

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© A. Samarin 2013

Idempotence

http://en.wikipedia.org/wiki/Help:IPA_for_English

http://en.wikipedia.org/wiki/Help:IPA_for_English#Key

http://en.wikipedia.org/wiki/Help:IPA_for_English#Key

http://en.wikipedia.org/wiki/Help:IPA_for_English

http://en.wikipedia.org/wiki/Wikipedia:Pronunciation_respelling_key







• 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)

© A. Samarin 2013

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

© A. Samarin 2013

Monitoring

BPM for developers, v1 16

• Mixing human and automated activities

• Each human activity may be surrounded by two automated activities (pre-processing and post-processing)

© A. Samarin 2013

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)

© A. Samarin 2013

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

© A. Samarin 2013

More tricks

bpm for developers, extended

Technology