此内容没有您所选择的语言版本。
Packaging and deploying a Red Hat Decision Manager project
Abstract
Preface
As a business rules developer, you must build and deploy a developed Red Hat Decision Manager project to a Decision Server in order to begin using the services you have created in Red Hat Decision Manager. You can develop and deploy a project from Business Central, from an independent Maven project, from a Java application, or using a combination of various platforms. For example, you can develop a project in Business Central and deploy it using the Decision Server REST API, or develop a project in Maven configured with Business Central and deploy it using Business Central.
Prerequisites
- The project to be deployed has been developed and tested. For projects in Business Central, consider using test scenarios to test the assets in your project. For example, see Testing a decision service using test scenarios.
Chapter 1. Red Hat Decision Manager project packaging
Red Hat Decision Manager projects contain the business assets that you develop in Red Hat Decision Manager. Each project in Red Hat Decision Manager is packaged as a Knowledge JAR (KJAR) file with configuration files such as a Maven project object model file (pom.xml
), which contains build, environment, and other information about the project, and a KIE module descriptor file (kmodule.xml
), which contains the KIE base and KIE session configurations for the assets in the project. You deploy the packaged KJAR file to a Decision Server that runs the decision services and other deployable assets (collectively referred to as services) from that KJAR file. These services are consumed at run time through an instantiated KIE container, or deployment unit. Project KJAR files are stored in a Maven repository and identified by three values: GroupId
, ArtifactId
, and Version
(GAV). The Version
value must be unique for every new version that might need to be deployed. To identify an artifact (including a KJAR file), you need all three GAV values.
Projects in Business Central are packaged automatically when you build and deploy the projects. For projects outside of Business Central, such as independent Maven projects or projects within a Java application, you must configure the KIE module descriptor settings in an appended kmodule.xml
file or directly in your Java application in order to build and deploy the projects.
Chapter 2. Project deployment in Business Central
You can use Business Central to develop your business assets and services and to manage Decision Servers configured for project deployment. When your project is developed, you can build the project in Business Central and deploy it automatically to the Decision Server. To enable automatic deployment, Business Central includes a built-in Maven repository. From Business Central, you can start, stop, or remove the deployment units (KIE containers) that contain the services and their project versions that you have built and deployed.
You can also connect several Decision Servers to the same Business Central instance and group them into different server configurations (in Menu → Deploy → Execution Servers). Servers belonging to the same server configuration run the same services, but you can deploy different projects or different versions of projects on different configurations.
For example, you could have test servers in the Test
configuration and production servers in a Production
configuration. As you develop business assets and services in a project, you deploy the project on the Test
server configuration and then, when a version of the project is sufficiently tested, you can deploy it on the Production
server configuration. In this case, to keep developing the project, change the version in the project settings. Then the new version and the old version are seen as different artifacts in the built-in Maven repository. You can deploy the new version on the Test
server configuration and keep running the old version on the Production
server configuration. This deployment process is simple but has significant limitations. Notably, there is not enough access control: a developer can deploy a project directly into a production environment.
You cannot move a Decision Server into a different server configuration using Business Central. You must change the configuration file of the server to change the server configuration name for it.
2.1. Configuring a Decision Server to connect to Business Central
If a Decision Server is not already configured in your Red Hat Decision Manager environment, or if you require additional Decision Servers in your Red Hat Decision Manager environment, you must configure a Decision Server to connect to Business Central.
If you are deploying Decision Server on Red Hat OpenShift Container Platform, see Deploying a Red Hat Decision Manager authoring or managed server environment on Red Hat OpenShift Container Platform for instructions about configuring it to connect to Business Central.
Prerequisites
- Decision Server is installed. For installation options, see Planning a Red Hat Decision Manager installation.
Procedure
-
In your Red Hat Decision Manager installation directory, navigate to the
standalone-full.xml
file. For example, if you use a Red Hat JBoss EAP installation for Red Hat Decision Manager, go to$EAP_HOME/standalone/configuration/standalone-full.xml
. Open
standalone-full.xml
and under the<system-properties>
tag, set the following properties:- org.kie.server.controller.user: The user name of a user who can log in to the Business Central.
- org.kie.server.controller.pwd: The password of the user who can log in to the Business Central.
-
org.kie.server.controller: The URL for connecting to the API of Business Central. Normally, the URL is
http://<centralhost>:<centralport>/decision-central/rest/controller
, where<centralhost>
and<centralport>
are the host name and port for Business Central. If Business Central is deployed on OpenShift, removedecision-central/
from the URL. -
org.kie.server.location: The URL for connecting to the API of Decision Server. Normally, the URL is
http://<serverhost>:<serverport>/kie-server/services/rest/server
, where<serverhost>
and<serverport>
are the host name and port for Decision Server. - org.kie.server.id: The name of a server configuration. If this server configuration does not exist in Business Central, it is created automatically when Decision Server connects to Business Central.
Example:
<property name="org.kie.server.controller.user" value="central_user"/> <property name="org.kie.server.controller.pwd" value="central_password"/> <property name="org.kie.server.controller" value="http://central.example.com:8080/decision-central/rest/controller"/> <property name="org.kie.server.location" value="http://kieserver.example.com:8080/kie-server/services/rest/server"/> <property name="org.kie.server.id" value="production-servers"/>
- Start or restart the Decision Server.
2.2. Configuring the environment mode in Decision Server and Business Central
You can set Decision Server to run in production
mode or in development
mode. Development mode provides a flexible deployment policy that enables you to update existing deployment units (KIE containers) while maintaining active process instances for small changes. It also enables you to reset the deployment unit state before updating active process instances for larger changes. Production mode is optimal for production environments, where each deployment creates a new deployment unit.
In a development environment, you can click Deploy in Business Central to deploy the built KJAR file to a Decision Server without stopping any running instances (if applicable), or click Redeploy to deploy the built KJAR file and stop any running instances. The next time you deploy or redeploy the built KJAR, the previous deployment unit (KIE container) is automatically updated in the same target Decision Server.
In a production environment, the Redeploy option in Business Central is disabled and you can click only Deploy to deploy the built KJAR file to a new deployment unit (KIE container) on a Decision Server.
Procedure
-
To configure the Decision Server environment mode, set the
org.kie.server.mode
system property toorg.kie.server.mode=development
ororg.kie.server.mode=production
. To configure the deployment behavior for a project in Business Central, go to project Settings → General Settings → Version and toggle the Development Mode option.
NoteBy default, Decision Server and all new projects in Business Central are in development mode.
You cannot deploy a project with Development Mode turned on or with a manually added
SNAPSHOT
version suffix to a Decision Server that is in production mode.
2.3. Configuring an external Maven repository for Business Central and Decision Server
You can configure Business Central and Decision Server to use an external Maven repository, such as Nexus or Artifactory, instead of the built-in repository. This enables Business Central and Decision Server to access and download artifacts that are maintained in the external Maven repository.
For information about configuring an external Maven repository for an authoring environment on Red Hat OpenShift Container Platform, see the following documents:
Prerequisites
- Business Central and Decision Server are installed. For installation options, see Planning a Red Hat Decision Manager installation.
Procedure
-
Create a Maven
settings.xml
file with connection and access details for your external repository. For details about thesettings.xml
file, see the Maven Settings Reference. -
Save the file in a known location, for example,
/opt/custom-config/settings.xml
. -
In your Red Hat Decision Manager installation directory, navigate to the
standalone-full.xml
file. For example, if you use a Red Hat JBoss EAP installation for Red Hat Decision Manager, go to$EAP_HOME/standalone/configuration/standalone-full.xml
. Open
standalone-full.xml
and under the<system-properties>
tag, set thekie.maven.settings.custom
property to the full path name of thesettings.xml
file.For example:
<property name="kie.maven.settings.custom" value="/opt/custom-config/settings.xml"/>
- Start or restart Business Central and Decision Server.
Next steps
For each Business Central project that you want to export or push as a KJAR artifact to the external Maven repository, you must add the repository information in the project pom.xml
file. For instructions, see Section 2.4, “Exporting a Business Central project to an external Maven repository”.
2.4. Exporting a Business Central project to an external Maven repository
If you configured an external Maven repository for Business Central and Decision Server, you must add the repository information in the pom.xml
file for each Business Central project that you want to export or push as a KJAR artifact to that external repository. You can then progress the project KJAR files through the repository as necessary to implement your integration process, and deploy the KJAR files using Business Central or the Decision Server REST API.
Prerequisites
You configured Business Central and Decision Server to use an external Maven repository. If you deployed Business Central on-premise, for more information about configuring an external Maven repository, see Section 2.3, “Configuring an external Maven repository for Business Central and Decision Server”. If you deployed your authoring environment on Red Hat OpenShift Container Platform, for more information, see the following documents:
Procedure
- In Business Central, go to Menu → Design → Projects, click the project name, and select any asset in the project.
- In the Project Explorer menu on the left side of the screen, click the Customize View gear icon and select Repository View → pom.xml.
Add the following settings at the end of the project
pom.xml
file (before the</project>
closing tag). The values must correspond to the settings that you defined in yoursettings.xml
file.<distributionManagement> <repository> <id>${maven-repo-id}</id> <url>${maven-repo-url}</url> <layout>default</layout> </repository> </distributionManagement>
-
Click Save to save the
pom.xml
file changes.
Repeat this procedure for each Business Central project that you want to export or push as a KJAR artifact to the external Maven repository.
2.5. Building and deploying a project in Business Central
After your project is developed, you can build the project in Business Central and deploy it to the configured Decision Server. Projects in Business Central are packaged automatically as KJARs with all necessary components when you build and deploy the projects.
Procedure
- In Business Central, go to Menu → Design → Projects and click the project name.
In the upper-right corner, click Deploy to build the project and deploy it to a Decision Server. To compile the project without deploying it to Decision Server, click Build.
NoteYou can also select the Build & Install option to build the project and publish the KJAR file to the configured Maven repository without deploying to a Decision Server. In a development environment, you can click Deploy to deploy the built KJAR file to a Decision Server without stopping any running instances (if applicable), or click Redeploy to deploy the built KJAR file and stop any running instances. The next time you deploy or redeploy the built KJAR, the previous deployment unit (KIE container) is automatically updated in the same target Decision Server. In a production environment, the Redeploy option is disabled and you can click Deploy only to deploy the built KJAR file to a new deployment unit (KIE container) on a Decision Server.
To configure the Decision Server environment mode, set the
org.kie.server.mode
system property toorg.kie.server.mode=development
ororg.kie.server.mode=production
. To configure the deployment behavior for a corresponding project in Business Central, go to project Settings → General Settings → Version and toggle the Development Mode option. By default, Decision Server and all new projects in Business Central are in development mode. You cannot deploy a project with Development Mode turned on or with a manually addedSNAPSHOT
version suffix to a Decision Server that is in production mode.If only one Decision Server is connected to Business Central, or if all connected Decision Servers are in the same server configuration, the services in the project are started automatically in a deployment unit (KIE container).
If multiple server configurations are available, a deployment dialog is displayed in Business Central, prompting you to specify server and deployment details.
If the deployment dialog appears, verify or set the following values:
- Deployment Unit Id / Deployment Unit Alias: Verify the name and alias of the deployment unit (KIE container) running the service within the Decision Server. You normally do not need to change these settings.
- Server Configuration: Select the server configuration for deploying this project. You can later deploy it to other configured servers without rebuilding the project.
- Start Deployment Unit?: Verify that this box is selected to start the deployment unit (KIE container). If you clear this box, the service is deployed onto the server but not started.
2.6. Deployment units in Business Central
The services in a project are consumed at run time through an instantiated KIE container, or deployment unit, on a configured Decision Server. When you build and deploy a project in Business Central, the deployment unit is created automatically in the configured server. You can start, stop, or remove deployment units in Business Central as needed. You can also create additional deployment units from previously built projects and start them on existing or new Decision Servers configured in Business Central.
2.6.1. Creating a deployment unit in Business Central
One or more deployment units should already exist as part of your Red Hat Decision Manager configuration, but if not, you can create a deployment unit from a project that was previously built in Business Central.
Prerequisites
- The project for which you are creating the new deployment unit has been built in Business Central.
Procedure
- In Business Central, go to Menu → Deploy → Execution servers.
- Under Server Configurations, select an existing configuration or click New Server Configuration to create a configuration.
- Under Deployment Units, click Add Deployment Unit.
- In the table within the window, select a GAV and click Select next to the GAV to populate the deployment unit data fields.
- Select the Start Deployment Unit? box to start the service immediately, or clear the box to start it later.
Click Finish.
The new deployment unit for the service is created and placed on the Decision Servers that are configured for this server configuration. If you have selected Start Deployment Unit?, the service is started.
2.6.2. Starting, stopping, and removing deployment units in Business Central
When a deployment unit is started, the services in the deployment unit are available for use. If only one Decision Server is connected to Business Central, or if all connected Decision Servers are in the same server configuration, services are started in a deployment unit automatically when a project is deployed. If multiple server configurations are available, you are prompted upon deployment to specify server and deployment details and to start the deployment unit. However, at any time you can manually start, stop, or remove deployment units in Business Central to manage your deployed services as needed.
Procedure
- In Business Central, go to Menu → Deploy → Execution servers.
- Under Server Configurations, select a configuration.
- Under Deployment Units, select a deployment unit.
- Click Start, Stop, or Remove in the upper-right corner. To remove a running deployment unit, stop it and then remove it.
2.7. Editing the GAV values for a project in Business Central
The GroupId
, ArtifactId
, and Version
(GAV) values identify a project in a Maven repository. When Business Central and Decision Server are on the same file system and use the same Maven repository, the project is automatically updated in the repository each time you build a new version of your project. However, if Business Central and Decision Server are on separate file systems and use separate local Maven repositories, you must update a project GAV value, usually the version, for any new versions of the project to ensure that the project is seen as a different artifact alongside the old version.
For development purposes only, you can toggle the Development Mode option in project Settings → General Settings → Version to add the SNAPSHOT
suffix in the project version. This suffix instructs Maven to get a new snapshot update according to the Maven policy. Do not use Development Mode or manually add the SNAPSHOT
version suffix for a production environment.
You can set the GAV values in the project Settings screen.
Procedure
- In Business Central, go to Menu → Design → Projects and click the project name.
- Click the project Settings tab.
In General Settings, modify the Group ID, Artifact ID, or Version fields as necessary. If you have deployed the project and are developing a new version, usually you need to increase the version number.
NoteFor development purposes only, you can toggle the Development Mode option in project Settings → General Settings → Version to add the
SNAPSHOT
suffix in the project version. This suffix instructs Maven to get a new snapshot update according to the Maven policy. Do not use Development Mode or manually add theSNAPSHOT
version suffix for a production environment.- Click Save to finish.
2.8. Duplicate GAV detection in Business Central
In Business Central, all Maven repositories are checked for any duplicated GroupId
, ArtifactId
, and Version
(GAV) values in a project. If a GAV duplicate exists, the performed operation is canceled.
Duplicate GAV detection is disabled for projects in Development Mode. To enable duplicate GAV detection in Business Central, go to project Settings → General Settings → Version and toggle the Development Mode option to OFF (if applicable).
Duplicate GAV detection is executed every time you perform the following operations:
- Save a project definition for the project.
-
Save the
pom.xml
file. - Install, build, or deploy a project.
The following Maven repositories are checked for duplicate GAVs:
-
Repositories specified in the
<repositories>
and<distributionManagement>
elements of thepom.xml
file. -
Repositories specified in the Maven
settings.xml
configuration file.
2.8.1. Managing duplicate GAV detection settings in Business Central
Business Central users with the admin
role can modify the list of repositories that are checked for duplicate GroupId
, ArtifactId
, and Version
(GAV) values for a project.
Duplicate GAV detection is disabled for projects in Development Mode. To enable duplicate GAV detection in Business Central, go to project Settings → General Settings → Version and toggle the Development Mode option to OFF (if applicable).
Procedure
- In Business Central, go to Menu → Design → Projects and click the project name.
- Click the project Settings tab and then click Validation to open the list of repositories.
Select or clear any of the listed repository options to enable or disable duplicate GAV detection.
In the future, duplicate GAVs will be reported for only the repositories you have enabled for validation.
NoteTo disable this feature, set the
org.guvnor.project.gav.check.disabled
system property totrue
for Business Central at system startup:$ ~/EAP_HOME/bin/standalone.sh -c standalone-full.xml -Dorg.guvnor.project.gav.check.disabled=true
Chapter 3. Project deployment without Business Central
As an alternative to developing and deploying projects in the Business Central interface, you can use independent Maven projects or your own Java applications to develop Red Hat Decision Manager projects and deploy them in KIE containers (deployment units) to a configured Decision Server. You can then use the Decision Server REST API to start, stop, or remove the KIE containers that contain the services and their project versions that you have built and deployed. This flexibility enables you to continue to use your existing application work flow to develop business assets using Red Hat Decision Manager features.
Projects in Business Central are packaged automatically when you build and deploy the projects. For projects outside of Business Central, such as independent Maven projects or projects within a Java application, you must configure the KIE module descriptor settings in an appended kmodule.xml
file or directly in your Java application in order to build and deploy the projects.
3.1. Configuring a KIE module descriptor file
A KIE module is a Maven project or module with an additional metadata file META-INF/kmodule.xml
. All Red Hat Decision Manager projects require a kmodule.xml
file in order to be properly packaged and deployed. This kmodule.xml
file is a KIE module descriptor that defines the KIE base and KIE session configurations for the assets in a project. A KIE base is a repository that contains all rules and other business assets in Red Hat Decision Manager but does not contain any runtime data. A KIE session stores and executes runtime data and is created from a KIE base or directly from a KIE container if you have defined the KIE session in the kmodule.xml
file.
If you create projects outside of Business Central, such as independent Maven projects or projects within a Java application, you must configure the KIE module descriptor settings in an appended kmodule.xml
file or directly in your Java application in order to build and deploy the projects.
Procedure
In the
~/resources/META-INF
directory of your project, create akmodule.xml
metadata file with at least the following content:<?xml version="1.0" encoding="UTF-8"?> <kmodule xmlns="http://www.drools.org/xsd/kmodule"> </kmodule>
This empty
kmodule.xml
file is sufficient to produce a single default KIE base that includes all files found under your projectresources
path. The default KIE base also includes a single default KIE session that is triggered when you create a KIE container in your application at build time.The following example is a more advanced
kmodule.xml
file:<?xml version="1.0" encoding="UTF-8"?> <kmodule xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.drools.org/xsd/kmodule"> <configuration> <property key="drools.evaluator.supersetOf" value="org.mycompany.SupersetOfEvaluatorDefinition"/> </configuration> <kbase name="KBase1" default="true" eventProcessingMode="cloud" equalsBehavior="equality" declarativeAgenda="enabled" packages="org.domain.pkg1"> <ksession name="KSession1_1" type="stateful" default="true" /> <ksession name="KSession1_2" type="stateful" default="true" beliefSystem="jtms" /> </kbase> <kbase name="KBase2" default="false" eventProcessingMode="stream" equalsBehavior="equality" declarativeAgenda="enabled" packages="org.domain.pkg2, org.domain.pkg3" includes="KBase1"> <ksession name="KSession2_1" type="stateless" default="true" clockType="realtime"> <fileLogger file="debugInfo" threaded="true" interval="10" /> <workItemHandlers> <workItemHandler name="name" type="new org.domain.WorkItemHandler()" /> </workItemHandlers> <listeners> <ruleRuntimeEventListener type="org.domain.RuleRuntimeListener" /> <agendaEventListener type="org.domain.FirstAgendaListener" /> <agendaEventListener type="org.domain.SecondAgendaListener" /> <processEventListener type="org.domain.ProcessListener" /> </listeners> </ksession> </kbase> </kmodule>
This example defines two KIE bases. Specific
packages
of rule assets are included with both KIE bases. When you specify packages in this way, you must organize your rule files in a folder structure that reflects the specified packages. Two KIE sessions are instantiated from theKBase1
KIE base, and one KIE session fromKBase2
. The KIE session fromKBase2
is astateless
KIE session, which means that data from a previous invocation of the KIE session (the previous session state) is discarded between session invocations. That KIE session also specifies a file (or a console) logger, aWorkItemHandler
, and listeners of the three supported types shown:ruleRuntimeEventListener
,agendaEventListener
andprocessEventListener
. The<configuration>
element defines optional properties that you can use to further customize yourkmodule.xml
file.As an alternative to manually appending a
kmodule.xml
file to your project, you can use aKieModuleModel
instance within your Java application to programatically create akmodule.xml
file that defines the KIE base and a KIE session, and then add all resources in your project to the KIE virtual file systemKieFileSystem
.Creating
kmodule.xml
programmatically and adding it toKieFileSystem
import org.kie.api.KieServices; import org.kie.api.builder.model.KieModuleModel; import org.kie.api.builder.model.KieBaseModel; import org.kie.api.builder.model.KieSessionModel; import org.kie.api.builder.KieFileSystem; KieServices kieServices = KieServices.Factory.get(); KieModuleModel kieModuleModel = kieServices.newKieModuleModel(); KieBaseModel kieBaseModel1 = kieModuleModel.newKieBaseModel("KBase1") .setDefault(true) .setEqualsBehavior(EqualityBehaviorOption.EQUALITY) .setEventProcessingMode(EventProcessingOption.STREAM); KieSessionModel ksessionModel1 = kieBaseModel1.newKieSessionModel("KSession1_1") .setDefault(true) .setType(KieSessionModel.KieSessionType.STATEFUL) .setClockType(ClockTypeOption.get("realtime")); KieFileSystem kfs = kieServices.newKieFileSystem(); kfs.writeKModuleXML(kieModuleModel.toXML());
After you configure the
kmodule.xml
file either manually or programmatically in your project, retrieve the KIE bases and KIE sessions from the KIE container to verify the configurations:KieServices kieServices = KieServices.Factory.get(); KieContainer kContainer = kieServices.getKieClasspathContainer(); KieBase kBase1 = kContainer.getKieBase("KBase1"); KieSession kieSession1 = kContainer.newKieSession("KSession1_1"), kieSession2 = kContainer.newKieSession("KSession1_2"); KieBase kBase2 = kContainer.getKieBase("KBase2"); StatelessKieSession kieSession3 = kContainer.newStatelessKieSession("KSession2_1");
If
KieBase
orKieSession
have been configured asdefault="true"
in thekmodule.xml
file, as in the previouskmodule.xml
example, you can retrieve them from the KIE container without passing any names:KieContainer kContainer = ... KieBase kBase1 = kContainer.getKieBase(); KieSession kieSession1 = kContainer.newKieSession(), kieSession2 = kContainer.newKieSession(); KieBase kBase2 = kContainer.getKieBase(); StatelessKieSession kieSession3 = kContainer.newStatelessKieSession();
To increase or decrease the maximum number of KIE modules or artifact versions that are cached in the decision engine, you can modify the values of the following system properties in your Red Hat Decision Manager distribution:
-
kie.repository.project.cache.size
: Maximum number of KIE modules that are cached in the decision engine. Default value:100
-
kie.repository.project.versions.cache.size
: Maximum number of versions of the same artifact that are cached in the decision engine. Default value:10
For the full list of KIE repository configurations, download the Red Hat Decision Manager [VERSION] Source Distribution ZIP file from the Red Hat Customer Portal and navigate to
~/rhdm-7.4.0-sources/src/drools-$VERSION/drools-compiler/src/main/java/org/drools/compiler/kie/builder/impl/KieRepositoryImpl.java
.-
For more information about the kmodule.xml
file, download the Red Hat Decision Manager [VERSION] Source Distribution ZIP file from the Red Hat Customer Portal (if not downloaded already) and see the kmodule.xsd
XML schema located at $FILE_HOME/rhdm-$VERSION-sources/kie-api-parent-$VERSION/kie-api/src/main/resources/org/kie/api/
.
KieBase
or KiePackage
serialization is not supported in Red Hat Decision Manager 7.4. For more information, see Is serialization of kbase/package supported in BRMS 6/BPM Suite 6/RHDM 7?.
3.1.1. KIE module configuration properties
The optional <configuration>
element in the KIE module descriptor file (kmodule.xml
) of your project defines property key
and value
pairs that you can use to further customize your kmodule.xml
file.
Example configuration property in a kmodule.xml
file
<kmodule> ... <configuration> <property key="drools.dialect.default" value="java"/> ... </configuration> ... </kmodule>
The following are the <configuration>
property keys and values supported in the KIE module descriptor file (kmodule.xml
) for your project:
- drools.dialect.default
Sets the default Drools dialect.
Supported values:
java
,mvel
<property key="drools.dialect.default" value="java"/>
- drools.accumulate.function.$FUNCTION
Links a class that implements an accumulate function to a specified function name, which allows you to add custom accumulate functions into the decision engine.
<property key="drools.accumulate.function.hyperMax" value="org.drools.custom.HyperMaxAccumulate"/>
- drools.evaluator.$EVALUATION
Links a class that implements an evaluator definition to a specified evaluator name so that you can add custom evaluators into the decision engine. An evaluator is similar to a custom operator.
<property key="drools.evaluator.soundslike" value="org.drools.core.base.evaluators.SoundslikeEvaluatorsDefinition"/>
- drools.dump.dir
Sets a path to the Red Hat Decision Manager
dump/log
directory.<property key="drools.dump.dir" value="$DIR_PATH/dump/log"/>
- drools.defaultPackageName
Sets a default package for the business assets in your project.
<property key="drools.defaultPackageName" value="org.domain.pkg1"/>
- drools.parser.processStringEscapes
Sets the String escape function. If this property is set to
false
, the\n
character will not be interpreted as the newline character.Supported values:
true
(default),false
<property key="drools.parser.processStringEscapes" value="true"/>
- drools.kbuilder.severity.$DUPLICATE
Sets a severity for instances of duplicate rules, processes, or functions reported when a KIE base is built. For example, if you set
duplicateRule
toERROR
, then an error is generated for any duplicated rules detected when the KIE base is built.Supported key suffixes:
duplicateRule
,duplicateProcess
,duplicateFunction
Supported values:
INFO
,WARNING
,ERROR
<property key="drools.kbuilder.severity.duplicateRule" value="ERROR"/>
- drools.propertySpecific
Sets the property reactivity of the decision engine.
Supported values:
DISABLED
,ALLOWED
,ALWAYS
<property key="drools.propertySpecific" value="ALLOWED"/>
- drools.lang.level
Sets the DRL language level.
Supported values:
DRL5
,DRL6
,DRL6_STRICT
(default)<property key="drools.lang.level" value="DRL_STRICT"/>
3.1.2. KIE base attributes supported in KIE modules
A KIE base is a repository that you define in the KIE module descriptor file (kmodule.xml
) for your project and contains all rules and other business assets in Red Hat Decision Manager. When you define KIE bases in the kmodule.xml
file, you can specify certain attributes and values to further customize your KIE base configuration.
Example KIE base configuration in a kmodule.xml
file
<kmodule> ... <kbase name="KBase2" default="false" eventProcessingMode="stream" equalsBehavior="equality" declarativeAgenda="enabled" packages="org.domain.pkg2, org.domain.pkg3" includes="KBase1"> ... </kbase> ... </kmodule>
The following are the kbase
attributes and values supported in the KIE module descriptor file (kmodule.xml
) for your project:
Attribute | Supported values | Description |
---|---|---|
| Any name |
Defines the name that retrieves |
| Comma-separated list of other KIE base objects in the KIE module |
Defines other KIE base objects and artifacts to be included in this KIE base. A KIE base can be contained in multiple KIE modules if you declare it as a dependency in the |
| Comma-separated list of packages to include in the KIE base
Default: |
Defines packages of artifacts (such as rules and processes) to be included in this KIE base. By default, all artifacts in the |
|
Default: | Determines whether a KIE base is the default KIE base for a module so that it can be created from the KIE container without passing any name. Each module can have only one default KIE base. |
|
Default: |
Defines the behavior of Red Hat Decision Manager when a new fact is inserted into the working memory. If set to |
|
Default: |
Determines how events are processed in the KIE base. If this property is set to |
|
Default: | Determines whether the declarative agenda is enabled or not. |
3.1.3. KIE session attributes supported in KIE modules
A KIE session stores and executes runtime data and is created from a KIE base or directly from a KIE container if you have defined the KIE session in the KIE module descriptor file (kmodule.xml
) for your project. When you define KIE bases and KIE sessions in the kmodule.xml
file, you can specify certain attributes and values to further customize your KIE session configuration.
Example KIE session configuration in a kmodule.xml
file
<kmodule> ... <kbase> ... <ksession name="KSession2_1" type="stateless" default="true" clockType="realtime"> ... </kbase> ... </kmodule>
The following are the ksession
attributes and values supported in the KIE module descriptor file (kmodule.xml
) for your project:
Attribute | Supported values | Description |
---|---|---|
| Any name |
Defines the name that retrieves |
|
Default: |
Determines whether data is retained ( |
|
Default: | Determines whether a KIE session is the default session for a module so that it can be created from the KIE container without passing any name. Each module can have only one default KIE session. |
|
Default: | Determines whether event time stamps are assigned by the system clock or by a pseudo clock controlled by the application. This clock is especially useful for unit testing on temporal rules. |
|
Default: | Defines the type of belief system used by the KIE session. A belief system deduces the truth from knowledge (facts). For example, if a new fact is inserted based on another fact which is later removed from the decision engine, the system can determine that the newly inserted fact should be removed as well. |
3.2. Packaging and deploying a Red Hat Decision Manager project in Maven
If you want to deploy a Maven project outside of Business Central to a configured Decision Server, you can edit the project pom.xml
file to package your project as a KJAR file and add a kmodule.xml
file with the KIE base and KIE session configurations for the assets in your project.
Prerequisites
- You have a Mavenized project that contains Red Hat Decision Manager business assets.
-
Decision Server is installed and
kie-server
user access is configured. For installation options, see Planning a Red Hat Decision Manager installation.
Procedure
In the
pom.xml
file of your Maven project, set the packaging type tokjar
and add thekie-maven-plugin
build component:<packaging>kjar</packaging> ... <build> <plugins> <plugin> <groupId>org.kie</groupId> <artifactId>kie-maven-plugin</artifactId> <version>${rhdm.version}</version> <extensions>true</extensions> </plugin> </plugins> </build>
The
kjar
packaging type activates thekie-maven-plugin
component to validate and pre-compile artifact resources. The<version>
is the Maven artifact version for Red Hat Decision Manager currently used in your project (for example, 7.23.0.Final-redhat-00002). These settings are required to properly package the Maven project for deployment.NoteInstead of specifying a Red Hat Decision Manager
<version>
for individual dependencies, consider adding the Red Hat Business Automation bill of materials (BOM) dependency to your projectpom.xml
file. The Red Hat Business Automation BOM applies to both Red Hat Decision Manager and Red Hat Process Automation Manager. When you add the BOM files, the correct versions of transitive dependencies from the provided Maven repositories are included in the project.Example BOM dependency:
<dependency> <groupId>com.redhat.ba</groupId> <artifactId>ba-platform-bom</artifactId> <version>7.4.0.GA-redhat-00002</version> <scope>import</scope> <type>pom</type> </dependency>
For more information about the Red Hat Business Automation BOM, see What is the mapping between Red Hat Decision Manager and the Maven library version?.
Add the following dependencies to the
pom.xml
file to generate an executable rule model from your rule assets:-
drools-canonical-model
: Enables an executable canonical representation of a rule set model that is independent from Red Hat Decision Manager -
drools-model-compiler
: Compiles the executable model into Red Hat Decision Manager internal data structures so that it can be executed by the decision engine
<dependency> <groupId>org.drools</groupId> <artifactId>drools-canonical-model</artifactId> <version>${rhdm.version}</version> </dependency> <dependency> <groupId>org.drools</groupId> <artifactId>drools-model-compiler</artifactId> <version>${rhdm.version}</version> </dependency>
Executable rule models are embeddable models that provide a Java-based representation of a rule set for execution at build time. The executable model is a more efficient alternative to the standard asset packaging in Red Hat Decision Manager and enables KIE containers and KIE bases to be created more quickly, especially when you have large lists of DRL (Drools Rule Language) files and other Red Hat Decision Manager assets.
For more information about executable rule models, see Designing a decision service using DRL rules.
To enable Decision Model and Notation (DMN) executable models for DMN assets in your project (if applicable), also add the
kie-dmn-core
dependency in thepom.xml
file:<dependency> <groupId>org.kie</groupId> <artifactId>kie-dmn-core</artifactId> <scope>provided</scope> <version>${rhdm.version}</version> </dependency>
-
In the
~/resources
directory of your Maven project, create aMETA-INF/kmodule.xml
metadata file with at least the following content:<?xml version="1.0" encoding="UTF-8"?> <kmodule xmlns="http://www.drools.org/xsd/kmodule"> </kmodule>
This
kmodule.xml
file is a KIE module descriptor that is required for all Red Hat Decision Manager projects. You can use the KIE module to define one or more KIE bases and one or more KIE sessions from each KIE base.For more information about
kmodule.xml
configuration, see Section 3.1, “Configuring a KIE module descriptor file”.In the relevant resource in your Maven project, configure a
.java
class to create a KIE container and a KIE session to load the KIE base:import org.kie.api.KieServices; import org.kie.api.runtime.KieContainer; import org.kie.api.runtime.KieSession; public void testApp() { // Load the KIE base: KieServices ks = KieServices.Factory.get(); KieContainer kContainer = ks.getKieClasspathContainer(); KieSession kSession = kContainer.newKieSession(); }
In this example, the KIE container reads the files to be built from the class path for a
testApp
project. TheKieServices
API enables you to access all KIE building and runtime configurations.You can also create the KIE container by passing the project
ReleaseId
to theKieServices
API. TheReleaseId
is generated from theGroupId
,ArtifactId
, andVersion
(GAV) values in the projectpom.xml
file.import org.kie.api.KieServices; import org.kie.api.runtime.KieContainer; import org.kie.api.runtime.KieSession; public void testApp() { // Identify the project in the local repository: ReleaseId rid = new ReleaseId(); rid.setGroupId("com.sample"); rid.setArtifactId("my-app"); rid.setVersion("1.0.0"); // Load the KIE base: KieServices ks = KieServices.Factory.get(); KieContainer kContainer = ks.newKieContainer(rid); KieSession kSession = kContainer.newKieSession(); }
In a command terminal, navigate to your Maven project directory and run the following command to build the project from an executable model:
mvn clean install -DgenerateModel=<VALUE>
The
-DgenerateModel=<VALUE>
property enables the project to be built as a model-based KJAR instead of a DRL-based KJAR, so that rule assets are built in an executable rule model.Replace
<VALUE>
with one of three values:-
YES
: Generates the executable model corresponding to the DRL files in the original project and excludes the DRL files from the generated KJAR. -
WITHDRL
: Generates the executable model corresponding to the DRL files in the original project and also adds the DRL files to the generated KJAR for documentation purposes (the KIE base is built from the executable model regardless). -
NO
: Does not generate the executable model.
Example build command:
mvn clean install -DgenerateModel=YES
For DMN executable models, run the following command:
mvn clean install -DgenerateDMNModel=YES
If the build fails, address any problems described in the command line error messages and try again to validate the files until the build is successful.
-
After you successfully build and test the project locally, deploy the project to the remote Maven repository:
mvn deploy
3.3. Packaging and deploying a Red Hat Decision Manager project in a Java application
If you want to deploy a project from within your own Java application to a configured Decision Server, you can use a KieModuleModel
instance to programatically create a kmodule.xml
file that defines the KIE base and a KIE session, and then add all resources in your project to the KIE virtual file system KieFileSystem
.
Prerequisites
- You have a Java application that contains Red Hat Decision Manager business assets.
-
Decision Server is installed and
kie-server
user access is configured. For installation options, see Planning a Red Hat Decision Manager installation.
Procedure
In your client application, add the following dependencies to the relevant classpath of your Java project to generate an executable rule model from your rule assets:
-
drools-canonical-model
: Enables an executable canonical representation of a rule set model that is independent from Red Hat Decision Manager -
drools-model-compiler
: Compiles the executable model into Red Hat Decision Manager internal data structures so that it can be executed by the decision engine
<dependency> <groupId>org.drools</groupId> <artifactId>drools-canonical-model</artifactId> <version>${rhdm.version}</version> </dependency> <dependency> <groupId>org.drools</groupId> <artifactId>drools-model-compiler</artifactId> <version>${rhdm.version}</version> </dependency>
Executable rule models are embeddable models that provide a Java-based representation of a rule set for execution at build time. The executable model is a more efficient alternative to the standard asset packaging in Red Hat Decision Manager and enables KIE containers and KIE bases to be created more quickly, especially when you have large lists of DRL (Drools Rule Language) files and other Red Hat Decision Manager assets.
For more information about executable rule models, see Designing a decision service using DRL rules.
To enable Decision Model and Notation (DMN) executable models for DMN assets in your project (if applicable), also add the
kie-dmn-core
dependency in thepom.xml
file:<dependency> <groupId>org.kie</groupId> <artifactId>kie-dmn-core</artifactId> <scope>provided</scope> <version>${rhdm.version}</version> </dependency>
The
<version>
is the Maven artifact version for Red Hat Decision Manager currently used in your project (for example, 7.23.0.Final-redhat-00002).NoteInstead of specifying a Red Hat Decision Manager
<version>
for individual dependencies, consider adding the Red Hat Business Automation bill of materials (BOM) dependency to your projectpom.xml
file. The Red Hat Business Automation BOM applies to both Red Hat Decision Manager and Red Hat Process Automation Manager. When you add the BOM files, the correct versions of transitive dependencies from the provided Maven repositories are included in the project.Example BOM dependency:
<dependency> <groupId>com.redhat.ba</groupId> <artifactId>ba-platform-bom</artifactId> <version>7.4.0.GA-redhat-00002</version> <scope>import</scope> <type>pom</type> </dependency>
For more information about the Red Hat Business Automation BOM, see What is the mapping between Red Hat Decision Manager and the Maven library version?.
-
Use the
KieServices
API to create aKieModuleModel
instance with the desired KIE base and KIE session. TheKieServices
API enables you to access all KIE building and runtime configurations. TheKieModuleModel
instance generates thekmodule.xml
file for your project.For more information about
kmodule.xml
configuration, see Section 3.1, “Configuring a KIE module descriptor file”.Convert your
KieModuleModel
instance into XML and add the XML toKieFileSystem
.Creating
kmodule.xml
programmatically and adding it toKieFileSystem
import org.kie.api.KieServices; import org.kie.api.builder.model.KieModuleModel; import org.kie.api.builder.model.KieBaseModel; import org.kie.api.builder.model.KieSessionModel; import org.kie.api.builder.KieFileSystem; KieServices kieServices = KieServices.Factory.get(); KieModuleModel kieModuleModel = kieServices.newKieModuleModel(); KieBaseModel kieBaseModel1 = kieModuleModel.newKieBaseModel("KBase1") .setDefault(true) .setEqualsBehavior(EqualityBehaviorOption.EQUALITY) .setEventProcessingMode(EventProcessingOption.STREAM); KieSessionModel ksessionModel1 = kieBaseModel1.newKieSessionModel("KSession1") .setDefault(true) .setType(KieSessionModel.KieSessionType.STATEFUL) .setClockType(ClockTypeOption.get("realtime")); KieFileSystem kfs = kieServices.newKieFileSystem(); kfs.writeKModuleXML(kieModuleModel.toXML());
Add any remaining Red Hat Decision Manager assets that you use in your project to your
KieFileSystem
instance. The artifacts must be in a Maven project file structure.import org.kie.api.builder.KieFileSystem; KieFileSystem kfs = ... kfs.write("src/main/resources/KBase1/ruleSet1.drl", stringContainingAValidDRL) .write("src/main/resources/dtable.xls", kieServices.getResources().newInputStreamResource(dtableFileStream));
In this example, the project assets are added both as a
String
variable and as aResource
instance. You can create theResource
instance using theKieResources
factory, also provided by theKieServices
instance. TheKieResources
class provides factory methods to convertInputStream
,URL
, andFile
objects, or aString
representing a path of your file system to aResource
instance that theKieFileSystem
can manage.You can also explicitly assign a
ResourceType
property to aResource
object when you add project artifacts toKieFileSystem
:import org.kie.api.builder.KieFileSystem; KieFileSystem kfs = ... kfs.write("src/main/resources/myDrl.txt", kieServices.getResources().newInputStreamResource(drlStream) .setResourceType(ResourceType.DRL));
Use
KieBuilder
withbuildAll( ExecutableModelProject.class )
specified to build the content ofKieFileSystem
from an executable model, and create a KIE container to deploy it:import org.kie.api.KieServices; import org.kie.api.KieServices.Factory; import org.kie.api.builder.KieFileSystem; import org.kie.api.builder.KieBuilder; import org.kie.api.runtime.KieContainer; KieServices kieServices = KieServices.Factory.get(); KieFileSystem kfs = ... KieBuilder kieBuilder = ks.newKieBuilder( kfs ); // Build from an executable model kieBuilder.buildAll( ExecutableModelProject.class ) assertEquals(0, kieBuilder.getResults().getMessages(Message.Level.ERROR).size()); KieContainer kieContainer = kieServices .newKieContainer(kieServices.getRepository().getDefaultReleaseId());
After
KieFileSystem
is built from the executable model, the resultingKieSession
uses constraints based on lambda expressions instead of less-efficientmvel
expressions. To build the project in the standard method without an executable model, do not specify any argument inbuildAll()
.A build
ERROR
indicates that the project compilation failed, noKieModule
was produced, and nothing was added to theKieRepository
singleton. AWARNING
or anINFO
result indicates that the compilation of the project was successful, with information about the build process.
3.4. Starting a service in Decision Server
If you have deployed Red Hat Decision Manager assets from a Maven or Java project outside of Business Central, you use a Decision Server REST API call to start the KIE container (deployment unit) and the services in it. You can use the Decision Server REST API to start services regardless of your deployment type, including deployment from Business Central, but projects deployed from Business Central either are started automatically or can be started within the Business Central interface.
Prerequisites
-
Decision Server is installed and
kie-server
user access is configured. For installation options, see Planning a Red Hat Decision Manager installation.
Procedure
In your command terminal, run the following API request to load a service into a KIE container in the Decision Server and to start it:
$ curl --user "<username>:<password>" -H "Content-Type: application/json" -X PUT -d '{"container-id" : "<containerID>","release-id" : {"group-id" : "<groupID>","artifact-id" : "<artifactID>","version" : "<version>"}}' http://<serverhost>:<serverport>/kie-server/services/rest/server/containers/<containerID>
Replace the following values:
-
<username>, <password>: The user name and password of a user with the
kie-server
role. - <containerID>: The identifier for the KIE container (deployment unit). You can use any random identifier but it must be the same in both places in the command (the URL and the data).
- <groupID>, <artifactID>, <version>: The project GAV values.
-
<serverhost>: The host name for the Decision Server, or
localhost
if you are running the command on the same host as the Decision Server. - <serverport>: The port number for the Decision Server.
Example:
curl --user "rhdmAdmin:password@1" -H "Content-Type: application/json" -X PUT -d '{"container-id" : "kie1","release-id" : {"group-id" : "org.kie.server.testing","artifact-id" : "container-crud-tests1","version" : "2.1.0.GA"}}' http://localhost:39043/kie-server/services/rest/server/containers/kie1
3.5. Stopping and removing a service in Decision Server
If you have started Red Hat Decision Manager services from a Maven or Java project outside of Business Central, you use a Decision Server REST API call to stop and remove the KIE container (deployment unit) containing the services. You can use the Decision Server REST API to stop services regardless of your deployment type, including deployment from Business Central, but services from Business Central can also be stopped within the Business Central interface.
Prerequisites
-
Decision Server is installed and
kie-server
user access is configured. For installation options, see Planning a Red Hat Decision Manager installation.
Procedure
In your command terminal, run the following API request to stop and remove a KIE container with services on Decision Server:
$ curl --user "<username>:<password>" -X DELETE http://<serverhost>:<serverport>/kie-server/services/rest/server/containers/<containerID>
Replace the following values:
-
<username>, <password>: The user name and password of a user with the
kie-server
role. - <containerID>: The identifier for the KIE container (deployment unit). You can use any random identifier but it must be the same in both places in the command (the URL and the data).
-
<serverhost>: The host name for the Decision Server, or
localhost
if you are running the command on the same host as the Decision Server. - <serverport>: The port number for the Decision Server.
Example:
curl --user "rhdmAdmin:password@1" -X DELETE http://localhost:39043/kie-server/services/rest/server/containers/kie1
Chapter 4. Additional resources
- "Executing rules" in Designing a decision service using DRL rules
- Deploying a Red Hat Decision Manager immutable server environment on Red Hat OpenShift Container Platform
- Deploying a Red Hat Decision Manager authoring or managed server environment on Red Hat OpenShift Container Platform
- Deploying a Red Hat Decision Manager environment on Red Hat OpenShift Container Platform using Operators
- Deploying a Red Hat Decision Manager trial environment on Red Hat OpenShift Container Platform
Appendix A. Versioning information
Documentation last updated on Monday, August 12, 2019.