I am new to Camunda and trying to build an application that will re-route the request to different
service providers based on type of services they are providing.
If you see the image attached - The image outlines a system where leading applications send HTTP requests for processing. The Orchestration Engine
after receieving these requests manages these requests, applying rules and initiating workflows. Some processes are synchronous, while others queue for
asynchronous handling. Data flows through connectors to various services.
Now I am trying to figure out the best way to route requests coming from API gateway - should I configure connectors URL
as a backend or I can create a trigger with URL that will kick off the processes.
Hi @KD_dms, welcome to the forums! Camunda isn’t most efficient at acting as a router, though DMN can be an efficient way to build rule sets. I think there may be better ways to leverage Camunda in this scenario, but I don’t have enough details to recommend much. If you have a process already modeled that you can share, happy to provide feedback!
However, that wasn’t your question! There are two main ways to start a process programmatically:
- You can use an inbound Connector. For your use case, the webhook Connector might be a good choice.
- You can call the gRPC gateway
CreateProcessInstance command. (This is the same call made behind the scenes when you start a process from inside Web or Desktop Modeler.)
Hope that helps!
Thanks for responding, Just wanted to check and confirm how scalable is webhook connector in case of thousands of requests coming in. An example - if Webhook URL is used to trigger tasks that perform document operations(upload file, fetch file etc) .
Hi @KD_dms - I don’t think the inbound webhook would be the best solution. The webhook is hosted by your Camunda stack, so you would be scaling part of your Camunda distribution along with it. For high traffic, I would recommend calling the gRPC gateway from your backend to start the processes when needed. Then you are only scaling Zeebe to match your processing needs instead of also scaling your Connectors runtime and possibly Operate with it.