Advanced Process Integration Tips - Mastering the Kie Smart Router

Using advanced process integration techniques becomes essential as you evolve your developer skills while integrating more and more of your business workflows. To get you started with becoming a master at complexer deployment environments, let's explore the Kie Smart Router and what it can mean for your process integration architectures.

Let's start with the what part of this 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. 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/instancesGET http://my-server-two/kie-server/services/rest/server/queries/processes/instances

The client application can do this request to the router:

GET http://localhost:9000/queries/processes/instances

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.

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?

Some of the moments when you might want to use a Smart Router in your architecture:

1. 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
2. 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
3. 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
4. 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

More details

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:

POST/server/containers/{containerId}/processes/{processId}/instances

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.

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 process integration architecture.