mri-bp2015

Keith D Swenson

May 2015

@swensonkeith

Robustness in Process

http:// www.slideshare.net / kswenson / mribp2015

1. Coding Effect on Robustness

2. Process and Transactions

3.Transactions and Messages

4. Distributed Scenarios

5. Etiquette

APPLICATION

DISK SPACE ….

The Day the Application Stood Still

Application built and deployed

Works fine with some number of people, say 50

CPU is around 2%

Memory and disk IO is reasonable

Above that number of people

CPU spikes to ~90%

Users complain of frozen screens

Disk IO and memory usage spike

Becomes impossible to do the simplest tasks

What is going on?

The Beast

...

try {

InitialContext cxt = new InitialContext();

String dataSourceJndi = mapComponentSettings.get("AssocDataSource");

DataSource ds = (DataSource) cxt.lookup(dataSourceJndi);

privateAssociations.setDataSource(ds);

}

catch (Exception e) {

log.error("Unable to load JNDI data source from context.");

}

...

Don’t Swallow

Exceptions

...

try {

InitialContext cxt = new InitialContext();

String dataSourceJndi = mapComponentSettings.get("AssocDataSource");

DataSource ds = (DataSource) cxt.lookup(dataSourceJndi);

privateAssociations.setDataSource(ds);

}

catch (Exception e) {

log.error("Unable to load JNDI data source: " + e.toString());

return null;

}

...

Don’t Swallow

Exceptions You Don’t Know

what the

Exception will be!

ADD the

Current

Context

& RETHROW

Don’t Log

IT!

Callers

Don’t test

For NULL

Normal

Situation

Error

Situation

Error

Situation

Error

Situation

cond

ition

condition

conditio

n

Started at Netscape in 1990’s

Input to Java team

Informed by projects from iFlow

and Interstage BPM in 2000’s

While the purpose of error

reporting is to assist in solving

the problem.

There is a problem

The system can’t handle it

The more completely the problem is

described, the faster it is resolved,

the happier users will be.

Throwing an exception should never be used to return a "normal" value

back to the caller.

Describe the current scope! Not what you think caused the exception.

Use a single monomorphic exception class.

• Every method (that throws) should declare throwing java.lang.Exception.

• Every catch block should catch java.lang.Exception

Do not assume that there is only one possible exception to be caught.

Always test for the exact exception class and the exact message key

before handling the exception in any other way than wrap and re-throw.

Don’t worry about making catch blocks efficient. Instead, design them to

be easy to maintain and easy to verify that the exception correctly

handled.

Act as if LOG files are not accessible

https://agiletribe.wordpress.com/

TRANSACTIONS

3GL Code

Data Sources

Resting state Transaction

Occurs

Resting state

A transition is a transaction

Transaction

Data Sources

Transaction Rollback … User View

Transaction

Rollback

Data Sources

Fail

Data Sources

Error State

Resting state

(error mode)

Transaction 1 Fail

Rollback

Transaction

2

Subprocess Scenario

Parent Process Child Process

Subprocess Scenario

Parent Process Child Process

Subprocess Scenario

Parent Process Child Process

Subprocess Scenario

Parent Process Child Process

Subprocess Scenario

Parent Process Child Process

Subprocess Scenario

Parent Process Child Process

Retries are Evil

Retries!

Data Sources

BPMN Transactional Notation

Transaction 1

Transaction 2

A Single

Transaction

Any failure in

either node,

you roll back to

where you started,

and put the process

in error mode.

What does this mean?

A BPMN transaction boundary

Something like

this might make

more sense …

but not really.

Front

1

2 3

Unit 1 Unit 2

Unit 3

4

5

6

Message

Bus

Front

Unit 1 Unit 2

Unit 3

Unit 5

Unit 4

Message

Bus

Fire and Forget

Front

Unit 1 Unit 2

Unit 3

Unit 5

Unit 4

Fail

Message

Bus

HOWEVER…

Distributed Systems

One transactionally

consistent enclave Another transactionally

consistent enclave

You have to deal with the fact that you can not have

transactional consistency everywhere

Business Process != System Architecture

Business Process != System Architecture

Required configuration in 6 different environments to be

consistent.

If one got our of sync, it broke the processes.

Messages were assumed to be reliable, but between reliable

system, they can NOT be reliable.

Your protocol MUST assume that messages are reliable, and

must deal with that.

Gringo Symposium Process

Reserve Room

Invite Speaker

Order Drinks

Gringo Symposium Process

Order Drinks

Order Fulfillment

A

B

Infinite Liquors A reliable message

Transport with

“exactly once”

delivery

“Six cases of

Sierra Nevada

Pale Ale for

delivery.”

2:07 PM 2:07 PM

Gringo Symposium Process

Order Drinks

Order Fulfillment

A

B

Infinite Liquors

Disk

Crash

2:10 PM

Gringo Symposium Process

Order Drinks

Order Fulfillment

A

B

Infinite Liquors

2:30 PM

1:00 PM

Backup

2:30 PM

Reliable System

#1

Reliable System

#2

Always

Consistent

Always

Consistent

Reliable System

#1a

Reliable System

#1c

Always

Consistent?

#1b

Consistency Seeking

Gringo Symposium

Order Drinks

Order Fulfillment

A

B

Infinite Liquors Orders

FOR

Infinite

Liquors

Orders

FROM

Gringo

Compare.

Are these

Consistent?

Take action

To make

Consistent.

Hourly

Poll.

Ship Bridge

to Engine Room

telegraph

use the same

principle

BPM

Roles, and Etiquette

Purchasing Agent Product Development

Business Etiquette Modeling

For each role in an organization, determine:

each of the services that role might perform

what must be provided

what will be produced

what conditions will decide whether the task is accepted or not

what contexts all this is valid in

Use simulation across many roles in the organization to see if

the process is ‘optimal’

tweak the etiquette rules as necessary

Record history and track KPIs like normal

Respond if necessary by tweaking the etiquette rules

Cross Company Emergent Processes

Manufacturing Company Consulting Firm

1. Coding Effect on Robustness

2. Process and Transactions

3.Transactions and Messages

4. Distributed Scenarios

5. Etiquette

Workflow Management Coalition

• Standards • Books • Awards • Information

Four years running. Four books

Real-life use cases.

Experience with ACM.

http://AdaptiveCaseManagement.org/

Workflow Management Coalition

2014: Thriving on Adaptability:

Best practices

for knowledge workers

NEW! When Thinking Matters in the Workplace: How Executives and Leaders of Knowledge Work Teams can Innovate with Case Management. http:// ThinkingMattersBook.com

Q & A

http:// www.slideshare.net / kswenson / mribp2015

Antifragility

http:// www.slideshare.net / kswenson / bpm2014 46:00

We know what fragility is.

But what is the opposite?

Fragile

?

Fragile Robust

Fragile Robust Antifragile

Definition of BPM

Business Process Management (BPM) is a

discipline involving any combination of

modeling, automation, execution,

control, measurement and optimization

of business activity flows,

in support of enterprise goals,

spanning systems, employees, customers and partners

within and beyond the enterprise boundaries.

“The System”

Your

Organization

IT

System

&

People

Offices

Agreements

Skills Expertise

Relationships

Hardware

Software

Data

Desire to

optimize

the entire

system