Orchestration process microservices

Hi, everyone, we are designing orchestration architecture for our micrioservices. We have read great article by Bernd The Microservices Workflow Automation Cheat Sheet | by Bernd Rücker | berndruecker and watched various talks. However, one question is not still clear.

Let’s for example imagine, that we have a simple insurance company API. Which can have three endpoints:

  1. POST quotes - returns quote of policy

  2. POST agreement - saves draft of policy from the quote

  3. POST /checkout - issues payment of the agreement

As per Bernd’s talks and by the logic of separation of concerns, each microservice should have it’s own process (BPMN model) and should we started on API request

But what process should govern the order of this requests? For example, that first you need to run quote, then agreement, then checkout? Should there be a service that governs that? How it’s BPMN relates to others (of payment, quote and agreement?)?

Would be interested to here opinions,
Regards,
Ruslan

2 Likes

Hi Ruslan.

There is no general answer to that. It really depends how you design the boundaries of your systems. So yes, it could be that you have an own microservice, that handles the policy application and owns a workflow that probably orchestrate the other services. It could also be that the quote microservice owns that workflow as you decide it is responsible for the quoting until the quite is really checked out.

The relationship of the BPMN and microservices is a “simple” service invocation/integration. So the application workflow might either call some quote service (or possibly also send a message, but POST looks you are targeting REST), not really knowing that there is a workflow in the background.

After all it is “simply” about how you organize your components/microservices, which might influence team structure and a lot of other things. To be honest it is quite hard to get this right in the first place - but it is pretty good that you give it a proper thought.

Hopefully this helps a bit further?

Best
Bernd

1 Like

Thanks a lot Bernd, and thanks a lot for the tons of useful information on the web.

We have also checked Zebee, and would likely go with it but we have some lock’ins on Camunda (user tasks, some parts for web services).

Overall, I agree that it depends on the usage and can be done either way.

As for the REST part, we have several frontends (web, mobile, internal) and number of partners using our Public API, so we want to have simple RESTish API for them and to use that ourselves. Underneath, it will trigger processes and will be working on events/messages.

Thanks again!

1 Like

Hi all,

one question that came up in some discussions recently (my company just started to get into process engines, and we experiencing some growing pains) was how do design workflows that handle asynchronous events that may be asynchronous for days, even weeks on the one side, but we would like to be able to start/stop the engine for maintenance etc. also. Where to persist the events, is the question? Will we need a separate database for the events? Or will handling asynchronity inside the workflows be sufficient? I would be happy to receive some hints. -E

This is a big question actually - with lots of possible answers. the first thing to know is that you don’t need any additional systems beyond The Camunda Engine and Camunda’s own database to do this.

The engine will always store the state safely - you can easily turn of the engine without losing data.

That would be absolutely fine.

If you’d like you can check out this example and watch the recording, it may give you some idea about the capabilities.