How can we orchestrate and integrate different SaaS products to support end-to-end business processes? What affordances do SaaS providers need to design into their APIs to help deliver the Composable Enterprise.

1. Automating Business Processes
with APIs
Saul Caganoff
CTO, Sixtree
@scaganoff @APIdaysAU

2. The Web is Now Programmable
• We need to talk about consuming APIs
• Each API will have thousands or millions of consumers
• Enterprise digital initiatives – lean, SaaS, PaaS, IaaS
• How to enable the Composable Enterprise?

4. SaaS - Different Levels of Specialization
• Infrastructure – storage, compute, management, integration
• Commodity – people, places, things, payment, security…
• Functional – sales, marketing, service management, financial,
human resources…
• Industry – healthcare, education, supply-chain…
• Your unique business value depends on how you integrate
and operate all these services
– The end-to-end business process

5. iPaaS & Cloud BPM
Consumer
Enterprise
Cloud BPM
Data Sync

6. This is what you want…
• The business process ensemble
• Coordination between process and API?
• API is constrained by its underlying state model
• Business Process has its own goal to achieve

7. This is what you get…
• Each SaaS is built as an island
…or with point integrations
• Not designed for integration
• An awful lot of polling going on
“We’ve got a long way to go” - @njyx

8. E.g. Bookstore
Finance
Sales
Fulfilment
Product
Customer

9. End-to-end Process
?

10. State: the “S” in REST
• Created
• Composed
• Addressed
• Quoted
• Paid
• Confirmed
• Declined
• Cancelled

11. Created Populated Addressed Quoted
PaidDeclined ConfirmedCancelled
Add
Item
Add
Item
Remove
Item
Accepted
Add
Credit Card
Details
Add
Address
Calculate
Cost
Declined
Add
Credit Card
Details
Cancel Cancel Cancel Cancel
Cancel

12. HATEOAS
• State Model
• Business Process = a path through the state model
• API Affordances
– Expose hyperlinks that represent available state transitions

13. HATEOAS
Empty
Cart
Full
Cart
Quoted
Paid
POST /cart
PUT /cart/:id
{ book: … }
PUT /cart/:id
{ book: … }
DELETE /cart/:id/books/:id
PUT /cart/:id
{ address: … }
POST /payments
{ cart: …, card: {…}}
Commands
{create: { cart: … } … }
{add: { cart: …, book: {…}} ..}
{add: { cart: …, book: {…}} ..}
{del: { cart: …, book: {…}} ..}
{quoted: { cart: … } … }
{paid: { cart: … } … }
Events (EATNOAS)

14. HATEOAS and Events
• State Model
• Business Process = a path through the state model
• Duality between state transitions and events
• An external observer can infer the state of a resource from its
event-stream
– This is the essence of event-sourcing & CQRS
• Affordances
– Expose hyperlinks that represent available state transitions
– Publish events that notify actual state transitions

15. Event Transports: Syndication
• API exposes list of events – e.g. an RSS/atom feed
• Consumers do all the hard work:
– Subscription
– State Management (where am I up to?)
– Retries
• Positives
– Very easy…well-known pattern
• Negatives
– Polling
– High latency

16. Event Transports: WebHooks
• Service POSTs events to subscribers
• Publishers do all the hard work:
– Subscriber management
– Consumers must provide an endpoint
• Positives
– Not polling, relatively lower latency
• Negatives
– Subscription management & guaranteed delivery must be done yourself
– Reliability requires coordination between publisher & subscriber

17. Check out RESTHooks
• Sponsored by Zapier
• WebHooks with
• RESTful Subscription Management
resthooks.org

18. Notification Services

19. End-to-end Process
Update
Inventory
Process
Payment
Initiate
Fulfilment
Update
Financials
Complete
Order

20. Affordances for Business Automation
• Have an explicit State Model
– With published hypermedia controls
• Track changes
– Allow query of changes since last “poll”
• Even better - notify changes
– Event streams
– WebHooks or REST Hooks
– Notification Services
• Consider the importance of event reliability