Slides from my talk at WeAreDevelopers Live on the Java Day about long-running processes. Code can be found here: https://github.com/berndruecker/customer-onboarding-camunda-8-springboot

1. @berndruecker
Are you done yet?
Mastering
long-running processes
in modern architectures

2. Let‘s talk about food

3. How does ordering Pizza work?
Pizza
Place
You
Phone Call
Synchronous blocking communication
Feedback loop (ack, confirmation or rejection)
Temporal coupling (e.g. busy, not answering)
Pizza
Place
You
Email
Asynchronous non-blocking communication
No temporal coupling
Pizza
Place
You
A feedback loop might make sense
(ack, confirmation or rejection)
Email
Confirmation Email
@berndruecker

4. Feedback loop != result
Pizza
Place
You
Email
Confirmation Email
Pizza Delivery
Feedback (ACK, confirmation, rejection)
Result
@berndruecker

5. Only the first communication step is synchronous / blocking
Pizza
Place
You
PUT/order
HTTP 200
Pizza Delivery
The task of
Pizza making is
long running
@berndruecker

6. Synchronous blocking behavior for the result?
Bad user experience
Does not scale well
@berndruecker

7. Scalable Coffee Making
https://www.enterpriseintegrationpatterns.com/ramblings/18_starbucks.html
Photo by John Ingle
@berndruecker

8. Long running

9. Long running

10. Long running basically means waiting

11. When do services want to wait? Some business reasons…
Human work Waiting for response
Let some time pass

12. Spoiler alert: There are also
technical reasons why services
need to wait…
Please wait…

13. Why is waiting a pain?
Persistent state How to solve the technical challenges without adding accidential
complexity?
Monitoring &
Operations
Visibility
Versioning
Scheduling &
Timeouts
Domain Logic
Scalability &
Resilience

14. Warning:
Contains Opinion

15. bernd.ruecker@camunda.com
@berndruecker
http://berndruecker.io/
Bernd Ruecker
Co-founder and
Chief Technologist of
Camunda

16. Workflow Engine aka Process Engine aka Orchestration Engine

17. Live hacking
https://github.com/berndruecker/customer-onboarding-camunda-8-springboot

18. Customer Unboarding
https://github.com/berndruecker/customer-onboarding-camunda-8-springboot

19. @berndruecker

20. There are also technical reasons
why services need to wait…

21. When do services need to wait? Some technical reasons…
Asynchronous communication
Wait for
responses
Wait for
availability
Especially failure scenarios
Unavailability of peers

22. Live hacking
https://github.com/berndruecker/customer-onboarding-camunda-8-springboot

23. Photo by Tookapic, available under Creative Commons CC0 1.0 license.

24. „There was an error
while sending your
boarding pass“

25. Check-in
Web-UI
Me
Current situation

26. Check-in
Barcode
Generator
Web-UI
Me
Output
Mgmt
Current situation

27. Check-in
Barcode
Generator
Web-UI
Me
Output
Mgmt
Current situation

28. Some
Service
Some
Service
Some
Service
Some
Service
Some
Service
Some
Service
Some
Service
Failure will happen.
Accept it!
But keep it local!
Be resilient.

29. Check-in
Barcode
Generator
Web-UI
Me
Output
Mgmt
Current situation – the bad part

30. Check-in
Barcode
Generator
Web-UI
Me
Output
Mgmt
Current situation – the bad part

31. Check-in
Barcode
Generator
Web-UI
Me
Output
Mgmt
Current situation – the bad part
Stateful
Retry

33. We are having some technical
difficulties and cannot present you
your boarding pass right away.
But we do actively retry ourselves, so
lean back, relax and we will send it
on time.

34. Check-in
Barcode
Generator
Web-UI
Me
Output
Mgmt
Possible situation – much better!

35. Check-in
Barcode
Generator
Web-UI
Me
Output
Mgmt
Possible situation – much better!
Stateful
Retry

36. Check-in
Barcode
Generator
Web-UI
Me
Output
Mgmt
Stateful
Retry
Possible situation – much better!
The failure
never leaves
this scope!

37. „But the customer wants a synchronous response!“
Check-in
Barcode
Generator
Web-UI
Me
Output
Mgmt
„Eh – no!“

38. has to implement
Retry
has to implement
Idempotency
Client Service Provider

39. Make every service idempotent!
Credit
Card
Payment
Charge Credit Card
cardNumber
amount
Charge Credit Card
cardNumber
amount
transactionId
Not idempotent
Idempotent
charge

42. Payment
Stateful retry by using an orchestration engine
Credit
Card
REST

43. Distributed systems introduce complexity you have to tackle!
Credit
Card
Payment
REST

44. It is impossible to
differentiate certain
failure scenarios.
Independant of
communication style!
Service
Provider
Client

45. Distributed systems introduce complexity you have to tackle!
Credit
Card
Payment
REST

46. Distributed systems introduce complexity you have to tackle!
Credit
Card
Payment
REST
Cancel
charge
Using an orchestration engine allows to do long
running processes reliably, and end-to-end

47. retrievePayment
HTTP 200 OK
HTTP 202 ACCEPTED
Payment
Happy case: Synchronous response
Otherwise: asynchronous
Embrace asynchronicity

48. If you want to
dive into code…
https://github.com/berndruecker/flowing-retail

49. Long running capabilities
are essential to design
good service boundaries
(= a good architecture)
@berndruecker

50. Example
Booking Payment
Retrieve
Payment
@berndruecker

51. Example
Booking Payment
Credit
Card
Retrieve
Payment
@berndruecker

52. Example
Booking Payment
Credit
Card
Retrieve
Payment
Rejected
@berndruecker

53. Example
Booking Payment
If the credit
card was
rejected, the
customer can
provide new
details
Credit
Card
Retrieve
Payment
Rejected
Rejected
@berndruecker

54. Example
Booking Payment
If the credit
card was
rejected, the
customer can
provide new
details
Credit
Card
Retrieve
Payment
Rejected
Rejected
@berndruecker
A few
smart god services
tell
anemic CRUD services
what to do
Sam Newmann

55. Payment
failed
Who is responsible to deal with problems?
Booking Payment
If the credit
card was
rejected, the
customer can
provide new
details
Credit
Card
Retrieve
Payment
Rejected
Payment
received
@berndruecker

56. Payment
failed
(Potentially) long running services
Order
Fulfillment
Payment
Credit
Card
Retrieve
Payment
Rejected
Payment
received
@berndruecker

57. Long running services
Order Payment
Credit
Card
@berndruecker

58. Extending Payment Options
@berndruecker

59. Extending Payment Options
begin commit
{local TX}
Customer Credit Service
begin commit
{local TX}
Credit Card Service
@berndruecker

60. Distributed transactions using compensation *
Compensation
@berndruecker

61. Long running capabilities
are essential to design
good service boundaries
(= a good architecture)
@berndruecker

62. Being able to implement
long running services
makes it easy to distribute
responsibilities correctly
@berndruecker

63. Being able to implement
long running services
makes it easy to embrace
async/non-blocking
@berndruecker

64. Orchestration != monolithic processes
Booking Payment
Credit
Card
@berndruecker

65. Graphical models?
@berndruecker

66. BPMN
Business Process
Model and Notation
ISO Standard
@berndruecker

67. Living documentation for long-running behaviour
@berndruecker

68. Living documentation for long-running behaviour
@berndruecker

69. BizDevOps
@berndruecker

70. Consistency decisions
need to be elevated
to the business level!

71. You need to redesign
your customer journeys
to leverage your
hipster architecture!
Shutterstock

73. @berndruecker
sync

74. @berndruecker

75. @berndruecker
happy
case
failure
case
Redesign your business process accordingly!
Or some interface
to poll for status
Sync in happy case
Async response

76. @berndruecker
A better customer experience: Resilient, responsive and asynchronous

77. Recap
• You need capabilities for long running behavior for
technical and business reasons
• Process orchestration engines are a great fit
• This allows you to design better service boundaries,
implement requirements at the right places, embrace
asynchronoucity and provide a better customer experience
@berndruecker

78. Want to learn more?
http://camunda.com/

79. Thank you!
@berndruecker