jBPM 7 brought a new component named smart router. Some common questions around it are:
Let’s start with the “what” question and then we can talk about the “when”.
What is a Smart Router?
Kie smart router is an extremely lightweight Java component that abstracts the details of the integration between client applications and multiple Kie Servers. It is a jar, available for download in Red Hat Process Automation Add-Ons at Red Hat Developers site. It can be initially executed like:
java -jar rhpam-7.4-smart-router.jar
When a client application does a request to the router, it works like a gateway. It knows which Kie Server is responsible for processing this request, and it can properly forward the requests.
It can also gather information that is spread across different Kie Servers, and give the response back for the client application in a transparent manner. So for example, instead of doing two requests to get all the process instances:
GET http://my-server-one/kie-server/services/rest/server/queries/processes/instances GET http://my-server-two/kie-server/services/rest/server/queries/processes/instances
The client application can do this request to the router:
The response is a list of all the running process instances existing in all Kie Servers that are registered in this router. In this way, the client doesn’t need to know how many kie servers are running, or where they are, in order to interact with the business logic.
Notice that the router omits the context “kie-server/services/rest/server” from the URL.
Finally, the smart router is capable of load balancing requests using round-robin and capable of avoiding requests to offline kie servers.
When should I use a Smart Router?
TLDR: Some of the moments when you might want to use a Smart Router in your architecture:
- When you have several Kie Servers running on top of different databases and need to retrieve the business information that comes from them, as one, as if they were in a single server;
- When you have a dynamic environment and want to centralize/focus all the requests from the client applications to a smart component (router). In this way, client applications configuration and integration logic is made easier.
- When you work with docker containers (K8s!) : Kie Server containers are created/destroyed easily. It can auto-register itself in the Smart Router, therefore, the client application doesn’t need to know about the changes;
- When you have a dynamic deployment environment with multiple project versions deployed among different Kie Servers; The Smart Router knows how to identify the Kie Server that holds a specific container, thus it can correctly address the requests; With this, the client application doesn’t need to know “which Kie Container” is associated with a specific process instance.
Consider the following starting scenario: a client application needs to start a new process via REST. The client application must make a REST call for the Kie Server which is running a Kie Container. Something like:
Instead of: In order to interact with Kie Server, the client application also needs to know where the Kie Server is running – for example, by configuring the server IP:PORT and valid authentication/authorization options.
An environment with a client application and a single Kie Server is mostly the scenario of a local development environment. Let’s add some spice here.
Scale this environment to a cluster environment and think about
- How you can configure the client application to integrate with the multiple Kie Servers?
- How would the client application know, which Kie Server is responsible for processing a determined process instance?
- How many requests would the client application need to do, to list all the existing process instances?
Now, in a modern fast-development and delivery environment, we containerize apps. We deploy them in Kubernetes-based environments (like Openshift) with auto scaling features.
In this case, the smart router is capable of dealing with a simpler cluster like the example above, and also with advanced scenarios like a hybrid-cloud with long-running processes, that constantly goes through changes and upgrades, by using a CI/CD pipeline for automated releases.
Finally, here are some topics that might help you defining when to use the smart router. Do you currently face issues dealing with how your client applications locates multiple kie servers to execute the following actions:
- Start a new process instance using the most recent version of process definition available across the whole environment;
- Complete a task, update a running process instance started on previous versions;
- List all process instances, no matter where they are running;
- Send requests to only to running Kie Server instance of the cluster;
In order to solve the topics above, use a smart router as the gateway between the client apps and the Kie Servers.
Want more information?
I will explain further posts a practical quick guide on how to start from scratch and integrate with the smart router component.
For more details about the smart router, I recommend checking this document with information on the origin and architecture of the smart router.
I hope this post helped clarifying what is a Smart Router and hope it helped you define whether you need to use it or not, in your jBPM or RHPAM architecture 🙂
Red Hat Process Automation Manager (RHPAM) is the open-source enterprise version of the upstream jBPM project. They are the same, therefore, the concepts here presented apply to both.