• Like
BPM for developers, extended
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

BPM for developers, extended

  • 828 views
Published

 

Published in Technology , Business
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
828
On SlideShare
0
From Embeds
0
Number of Embeds
25

Actions

Shares
Downloads
43
Comments
0
Likes
2

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. BPM for developers:improve agility ofimplementations –“Extended”A. SamarinMore about slides 32, 33 and 34 of thehttp://fr.slideshare.net/samarin/bpm-for-developers
  • 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 and34) 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 2WHY this second presentation
  • 3. • Speed of developing automation is the primary factor ofagility of a process-centric solution• Automation and process template have different speed ofchanges – 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 webservice) 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 BPM for developers "extended", v1 3Concerns about automation
  • 4. • 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 sequentialnumbering: 1, 2, 3, …• At the same time, keep the possibility to refer to the“current” version© A. Samarin 2013 BPM for developers "extended", v1 4Explicit versioning of everything (1)
  • 5. • A typical use (which is often a compliance requirement):– Since 1st of April all new process instances will use processtemplate v2– Already running process instances must remain at processtemplate v1• Another typical use (from the real life):– Since 1st of April all new process instances will use processtemplate v2– Some already running process instances will remain at processtemplate v1 (if those instances are close to the completion)– Some already running process instances may be migrated toprocess template v2 (if those instances are far from thecompletion)© A. Samarin 2013 BPM for developers "extended", v1 5Explicit versioning of everything (2)
  • 6. • There are two major patterns for mixing human andautomation activities• Pre Do Post pattern in which each human activity (DO) issurrounded 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 BPM for developers "extended", v1 6Mixing human and automated activities (1)PREPOSTDO
  • 7. • Error Recovery Loop is the other pattern which mandatesa human intervention for the recovery of a failedautomated activity• The rationale:– explicit catch of exceptions– ability to assign “recovery” human activityto different roles depending the nature ofexception (bypass the service desk)– maybe implemented as a container withoutexposure to the process• Relates to other techniques:– dynamic (interpretive) language– idempotency© A. Samarin 2013 BPM for developers "extended", v1 7Mixing human and automated activities (2)RecoverWork
  • 8. • At the same time, small fragments of automation may beused to react on different events related to a particularhuman activity (as in Bonita); those fragments are eventhandlers (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 BPM for developers "extended", v1 8Mixing human and automated activities (3)
  • 9. • Automated activities are usually built on existing APIs toaccess different enterprise systems and repositories• Automation looks like scripting• Interpretive language (no need to recompile) are good forscripting• Combine dynamic and static programming languages, forexample, Jython and Java, Groovy and Java, etc.• Use the strong typing to secure interfaces, enjoyintrospection, and avoid exotic features• Automation scripts must be kept outside processtemplates to allow modifications even within a processinstance© A. Samarin 2013 BPM for developers "extended", v1 9Use dynamic (interpretive) language
  • 10. • Use “robot” (an external to the process engine) programto execute scripts• Universal robots and specialised robots may co-exist• Robots must be clonable (for scalability, load-balancingand fault-tolerance)• Integration patterns between the process engine androbots (scripts are passed by reference):1. Human activity is assigned to a robot or group of robots; eachrobot is systematically checking its inbox (poor-man solution)2. Process engine queues (via a WS) work for robots; the queuemanager dispatches work requests to robots (ideal solution)• A crash of a robot will not disturb the process engine (lastan activity will be “late” or “overdue”)© A. Samarin 2013 BPM for developers "extended", v1 10Execution of automation scripts
  • 11. • Typical sequence1. Exception is raised in an automation script of an automatedactivity2. The process instance is routed to the recovery human activity3. A responsible person makes necessary corrections (up tomodifying the automation script) and completes this humanactivity4. The process instance is routed to the automated activity5. The automation script is executed again• Idempotency of automated scripts is a must© A. Samarin 2013 BPM for developers "extended", v1 11Error recovery loop
  • 12. • Idempotence (pron.: /ˌaɪdɨmˌpoʊtəns/ EYE-dəm-POH-təns) is the property of certain operations, that can beapplied multiple times without changing the result beyondthe initial application• This an automation script is a collection of idempotentinvocations of some services; a typical executionsequence for services A, and B:1. Start of the automation script2. Invocation of service A – OK3. Invocation of service B – exception4. 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 – OK7. End of the automation script© A. Samarin 2013 BPM for developers "extended", v1 12Idempotence
  • 13. • Automation script are actually executed by “system”account• But, in some case, they have to pretend to be as one ofthe participants in the process instance; for example, asubmitted document should be owned by the submitter• Automation script must have reach access to processinstance (BPM API) and be able to impersonate (changeaccount)© A. Samarin 2013 BPM for developers "extended", v1 13Impersonating
  • 14. • Ruthless monitoring of all services (including robots, othersystems and repositories)• Not just checking that a port is bound, but asking to do areal work; for example, echo-test• Service should be developed in the way to facilitate sucha monitoring• System should be developed in a way to facilitate such amonitoring• Also, robots proactively (before executing automationscripts) must check (via monitoring) the availability ofservices to be used in a particular automation script• It is better to wait a little than recover from an error© A. Samarin 2013 BPM for developers "extended", v1 14Monitoring
  • 15. © A. Samarin 2013 BPM for developers "extended", v1 15Thanks
  • 16. • Mixing human and automated activities• Each human activity may be surrounded by twoautomated activities (pre-processing and post-processing)© A. Samarin 2013 BPM for developers, v1 16Look at automation within processes
  • 17. • Explicit versioning of everything (another topic fordevelopers)• Keep automation outside the process template (as theyhave different speed of changes)• Use an interpretive language for automation scripting (noneed to recompile)• Use recovery loops (preserveinstance, carry out quick corrections in“this” instance)• Smart error handling (bypass somelevels of support)© A. Samarin 2013 BPM for developers "extended", v1 17Speed of developing automation is theprimary factor of agility
  • 18. • 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 ofspecialised robots)• Multiple robots (load balancing)• Process engine queues jobs for robots• Proactive monitoring of resource availability (better towait a little than recover from an error)• Idempotency© A. Samarin 2013 BPM for developers "extended", v1 18More tricks