JBoss.orgCommunity Documentation

Chapter 19. KIE Execution Server

19.1. Introduction
19.2. Installing the KIE Execution Server
19.2.1. Installation details for different containers
19.3. Registering a server
19.4. Creating a Kie Container
19.5. Managing Containers
19.5.1. Starting a Container
19.5.2. Stopping and Deleting a Container
19.5.3. Updating a Container
19.6. REST API
19.6.1. [GET] /
19.6.2. [POST] /
19.6.3. [GET] /containers
19.6.4. ⁠[GET] /containers/{id}
19.6.5. [PUT] /containers/{id}
19.6.6. [DELETE] /containers/{id}
19.6.7. [POST] /containers/{id}
19.6.8. [GET] /containers/{id}/release-id
19.6.9. [POST] /containers/{id}/release-id
19.6.10. [GET] /containers/{id}/scanner
19.6.11. [POST] /containers/{id}/scanner

The KIE Execution Server is a standalone, out-of-the-box component that can be used to instantiate and execute rules via interfaces available for REST, JMS or a Java client side application. Created as a web deployable WAR file, this engine can be deployed on any web container.

This server has a low footprint, with minimal memory consumption, and therefore, can be deployed easily on a cloud instance. Each instance of this server can open and instantiate multiple Kie Containers which allows you to execute multiple rule services in parallel.

You can provision execution server instances via KIE Workbench. In this chapter, we will go through the steps required to setup an execution server, provision and connect to this server via KIE Workbench, control what rule artifacts go in each instance and go through its lifecycle.

The KIE Execution Server is distributed as a web application archive (WAR) file. The WAR file comes in three different flavors:

To install the KIE Execution Server and verify it is running, complete the following steps:

To register a new KIE Execution Server instance, click on Deploy → Rule Deployments in KIE Workbench. This will open up the screen to show you any existing servers that you have registered. Click on Register to bring up the screen for entering details for a new server.

Enter details of your new server by specifying the endpoint and giving it a unique and identifiable name.

The endpoint should be the same you used to verify that the server was running in the previous section and looks like this: http://SERVER:PORT/CONTEXT/services/rest/server. Also provide a unique identifiable name for this server.

Although the username/password sections are not mandatory, unless you specifically take away the authentication required for your kie-server webapp, then you will need to enter these. These values should match the ones created in the previous section when you were installing this webapp with the role of kie-server.

Click Connect to connect and register this server. If you have successfully entered all the details, your server will be listed in the Rule Deployments Screen.

Common errors at this stage include issues like invalid username/password or the username not having the required kie-server role or the endpoint not being correct. All of these issues will give the same error: Can't connect to endpoint

Once your Execution Server is registered, you can start adding Kie Containers to it.

Kie Containers are self contained environments that have been provisioned to hold instances of your packaged and deployed rule instances.

Containers within the Execution Server can be started, stopped and updated from within KIE Workbench.⁠

You can update deployed KieContainers without restarting the Execution Server. This is useful in cases where the Business Rules change, creating new versions of packages to be provisioned.

You can have multiple versions of the same package provisioned and deployed, each to a different KieContainer.

To update deployments in a KieContainer dynamically, click on the icon next to the Container. This will open up the Container Info screen. An example of this screen is shown here:

The Container Info screen is a useful tool because it not only allows you to see the endpoint for this KieContainer, but it also allows you to either manually or automatically refresh the provision if an update is available. The update can be manual or automatic:

Manual Update: To manually update a KieContainer, enter the new Version number in the Version box and click on the Update button. You can of course, update the Group Id or the Artifact Id , if these have changed as well. Once updated, the Execution server updates the container and shows you the resolved GAV attributes at the bottom of the screen in the Resolved Release Id section.

Automatic Update: If you want a deployed Container to always have the latest version of your deployment without manually editing it, you will need to set the Version property to the value of LATEST and start a Scanner. This will ensure that the deployed provision always contains the latest version. The Scanner can be started just once on demand by clicking the Scan Now button or you can start it in the background with scans happening at a specified interval (in seconds).You can also set this value to LATEST when you are first creating this deployment. The Resolved Release Id in this case will show you the actual, latest version number.

The Execution Server supports the following commands via the REST API.

Please note the following before using these commands: