In one of the recent posts I presented KIE Server Router to allow to scale to more instances of KIE Servers where there is one smart router that can:
- find the right servers to deal with requests
- aggregate data from various servers
- remove burden from clients to know the location of KIE Servers
- and more...
With all that it's time to look into using KIE Server Router with workbench to utilize its UI capabilities to work with processes and tasks. Overall idea is to use the router as any other KIE Server so that means:
- router will connect to workbench controller
- notifies when started
- notifies when shutting down
- server template is required for the router - if none created before it will self-register itself
- all containers deployed behind the router must be in router's server template so all of them can be used in terms of forms, images and data
Though router acts like a KIE Server from workbench point of view it does not allow to perform KIE Server management operations like creating containers or upgrading them etc. These should be still managed in the same way as without router.
Workbench will see the router as regular KIE Server and thus will make the exact same features available for it, like starting processes, working with user tasks etc. So let's imagine following scenario:
- single workbench
- single router
- KIE Server for HR process - running on dedicated server instance (:8180 port)
- KIE Server for Evaluation process - running on dedicated server instance (:8280 port)
KIE servers are running in unmanaged mode with predefined versions of kjars to be deployed, one per KIE Server. These KIE Servers are then connected to router. In turn router is configured to connect to controller once started. In workbench there is a single KIE Server Router server template configured with both kjars (containers) configured and started.
Here you can see how it works
As can be seen in the screen cast, all normal operations are available to the users. Starting processes that are actually executed on different servers (that in real scenario will be on completely different machines) without any hassle. Same goes for retrieving various information like active instances, showing process instance image, work with tasks. All goes via router that decides to what server the request should be forwarded.
Moreover, it aggregates the results for queries e.g. process instance, process definition or tasks so there is no need to go over individual servers to figure out what instances are running and to get the details of them. Even dashboard does work via router, though it still has some issues as it expects to have a single row instead of aggregate of all servers so this is still something to address...
The only limitation at the moment is sorting capabilities of the aggregated results. In general router is capable of doing aggregate sort but the problem here is that the data returned when used through workbench are in raw format and thus router has not information what field is what and thus sorting is in the way that individual servers returned. Though it does support paging in normal fashion.
... if you want to give it a try yourself
there is small trick to start it in particular sequence:
Moreover, it aggregates the results for queries e.g. process instance, process definition or tasks so there is no need to go over individual servers to figure out what instances are running and to get the details of them. Even dashboard does work via router, though it still has some issues as it expects to have a single row instead of aggregate of all servers so this is still something to address...
The only limitation at the moment is sorting capabilities of the aggregated results. In general router is capable of doing aggregate sort but the problem here is that the data returned when used through workbench are in raw format and thus router has not information what field is what and thus sorting is in the way that individual servers returned. Though it does support paging in normal fashion.
... if you want to give it a try yourself
there is small trick to start it in particular sequence:
- workbench first
- ./standalone.sh
- router (without the controller property)
- java -jar target/kie-server-router-proxy-7.0.0-SNAPSHOT.jar
- kie servers (with router property)
- /standalone.sh --server-config=standalone-full.xml -Djboss.socket.binding.port-offset=100 -Dorg.kie.server.id=hr-server -Dorg.kie.server.location=http://localhost:8180/kie-server/services/rest/server -Dorg.kie.server.router=http://localhost:9000
- restart router with controller property
- java -Dorg.kie.server.controller=http://localhost:8080/kie-wb/rest/controller -jar target/kie-server-router-proxy-7.0.0-SNAPSHOT.jar
this is needed when running in memory data base as upon connection of the router to controller, it will push queries to the connected KIE Server to register so workbench queries could work as expected. Since the router is connecting to controller it will the forward these queries to all connected kie servers to register these queries in there. As they are running with in memory db these queries are constantly dropped and thus must be registered again. With real use case these are going to be registered once and won't be really relevant to have the sequence as above.
