Drools Documentation

Signing to jboss.org will give you access to the JBoss wiki, forums and JIRA. Go to https://www.jboss.org/ and click "Register".

The only form you need to sign is the contributor agreement, which is fully automated via the web. As the image below says "This establishes the terms and conditions for your contributions and ensures that source code can be licensed appropriately"

https://cla.jboss.org/

To be able to interact with the core development team you will need to use JIRA, the issue tracker. This ensures that all requests are logged and allocated to a release schedule and all discussions captured in one place. Bug reports, bug fixes, feature requests and feature submissions should all go here. General questions should be undertaken at the mailing lists.

Minor code submissions, like format or documentation fixes do not need an associated JIRA issue created.

https://issues.jboss.org/browse/JBRULES (Drools)

https://issues.jboss.org/browse/JBPM

https://issues.jboss.org/browse/GUVNOR

With the contributor agreement signed and your requests submitted to JIRA you should now be ready to code :) Create a GitHub account and fork any of the Drools, jBPM or Guvnor repositories. The fork will create a copy in your own GitHub space which you can work on at your own pace. If you make a mistake, don’t worry blow it away and fork again. Note each GitHub repository provides you the clone (checkout) URL, GitHub will provide you URLs specific to your fork.

https://github.com/droolsjbpm

When writing tests, try and keep them minimal and self contained. We prefer to keep the DRL fragments within the test, as it makes for quicker reviewing. If their are a large number of rules then using a String is not practical so then by all means place them in separate DRL files instead to be loaded from the classpath. If your tests need to use a model, please try to use those that already exist for other unit tests; such as Person, Cheese or Order. If no classes exist that have the fields you need, try and update fields of existing classes before adding a new class.

There are a vast number of tests to look over to get an idea, MiscTest is a good place to start.

https://github.com/droolsjbpm/drools/blob/master/drools-compiler/src/test/java/org/drools/integrationtests/MiscTest.java

When you commit, make sure you use the correct conventions. The commit must start with the JIRA issue id, such as JBRULES-220. This ensures the commits are cross referenced via JIRA, so we can see all commits for a given issue in the same place. After the id the title of the issue should come next. Then use a newline, indented with a dash, to provide additional information related to this commit. Use an additional new line and dash for each separate point you wish to make. You may add additional JIRA cross references to the same commit, if it’s appropriate. In general try to avoid combining unrelated issues in the same commit.

Don’t forget to rebase your local fork from the original master and then push your commits back to your fork.

With your code rebased from original master and pushed to your personal GitHub area, you can now submit your work as a pull request. If you look at the top of the page in GitHub for your work area their will be a "Pull Request" button. Selecting this will then provide a gui to automate the submission of your pull request.

The pull request then goes into a queue for everyone to see and comment on. Below you can see a typical pull request. The pull requests allow for discussions and it shows all associated commits and the diffs for each commit. The discussions typically involve code reviews which provide helpful suggestions for improvements, and allows for us to leave inline comments on specific parts of the code. Don’t be disheartened if we don’t merge straight away, it can often take several revisions before we accept a pull request. Luckily GitHub makes it very trivial to go back to your code, do some more commits and then update your pull request to your latest and greatest.

It can take time for us to get round to responding to pull requests, so please be patient. Submitted tests that come with a fix will generally be applied quite quickly, where as just tests will often way until we get time to also submit that with a fix. Don’t forget to rebase and resubmit your request from time to time, otherwise over time it will have merge conflicts and core developers will general ignore those.

Drools provides an Eclipse-based IDE (which is optional), but at its core only Java 1.5 (Java SE) is required.

A simple way to get started is to download and install the Eclipse plug-in - this will also require the Eclipse GEF framework to be installed (see below, if you don’t have it installed already). This will provide you with all the dependencies you need to get going: you can simply create a new rule project and everything will be done for you. Refer to the chapter on the Rule Workbench and IDE for detailed instructions on this. Installing the Eclipse plug-in is generally as simple as unzipping a file into your Eclipse plug-in directory.

Use of the Eclipse plug-in is not required. Rule files are just textual input (or spreadsheets as the case may be) and the IDE (also known as the Rule Workbench) is just a convenience. People have integrated the rule engine in many ways, there is no "one size fits all".

Alternatively, you can download the binary distribution, and include the relevant JARs in your projects classpath.

Historically Rete has always been a sequential algorithm and even if Phreak, its evolution introduced in Drools 6, allowed some degree of parallelization, this possibility wasn’t concretely leveraged yet. In Drools 7 is finally possible to make the engine to evaluate more rules in parallel. This is achieved by partitioning the Rete/Phreak in independent partitions and evaluating them in parallel.

This feature is off by default, but it’s possible to create a parallel KieBase by enabling it via the KieBaseConfiguration as it follows:

or alternatively through the system property:

In Drools 6 when using the sum function inside an accumulate pattern the result was always a Double regardless of the field type on which the sum was performed. This caused the following 3 problems:

Conversely Drools 7 preserves the type of the expression on which the sum is executed, so it will be possible to directly match on that type as in:

Prior to 7.x the Workbench used to install pre-defined examples at startup.

Version 7.x brings the ability to import examples from git repositories.
The Authoring Perspective contains a menu item for 'Examples' clicking this launches a Wizard to guide you through the import.

All system pop-ups had their UX improved.

The "comment" field is hidden by default.
image::shared/Workbench/ReleaseNotes/popups-comment-field.png[]

Now, the destination package can be selected when a project file is copied from any package.
image::shared/Workbench/ReleaseNotes/popups-package-field.png[]

Composite field constraints now support use of formulae.

When adding constraints to a Pattern the "Multiple Field Constraint" selection ("All of (and)" and "Any of (or)") supports use of formulae in addition to expressions.

The Guided Decision Table Editor has been extensively rewritten to support editing of multiple tables in the same editor. Tables that share an association are visibly linked making it easier to visualise relationships. Associations are infered from Actions that create or update a Fact consumed by the Conditions of another table.

Highlights include:-

The Guided Decision Table Editor has long been capable of using enumeration definitions. However since a table can contain many cells performance of enumerations could sometimes be less than ideal if the definition required a server round-trip to retrieve the lookups from a helper class.

Results from server round-trips are now cached in the client hence removing the need for successive network calls when cells are modified. The cache is initialised when the editor is opened and populated on demand.

The "Reimport" button invalidates all cached dependencies, in order to handle scenarios where a specific dependency was updated without having its version modified.

The User and Group management perspectives released in version 6.4 have been unified into a single perspective which delivers a shared view for managing both users and groups as well as the permissions granted to any of the application roles.

This very new perspective is placed under the Home section in the top menu bar.

The next screenshot shows how this new perspective looks:

A tabbed pane is shown on the left, allowing the User to select the Roles, Groups or Users tab. After clicking on a Role (or Group)
a detailed screen is displayed allowing the user to configure some security settings.

The command-line tool kie-config-cli.[sh/bat] for managing remote repositories that was present in 6.x has been removed for the following reasons:

The workbench now has a new menu item: "Admin". In there, you can find some admin tools, like "Users", "Groups" and "Roles" management, and also general preferences. When a preference is changed there, it will affect all places that depend on it, but only for the logged user.

Each project also has its own admin page, with admin tools and preferences. When a preference is changed there, it will affect only that project, and only for the logged user.

It is now possible, for each user, to set the GAV conflict check flag, and also allow or block child GAV edition for all their projects, or specifically for each project.

The configuration can be found inside the admin tool "Project", in case the access is made through the "Admin" menu item. It can also be found by entering the admin tool "General", on the Project admin page.

Some runtime environments (like for example Google App Engine) don’t allow to directly create new Threads.
For this reason it is now possible to plug your own ThreadFactory implementation by setting the system property drools.threadFactory with its class name.
For instance if you implemented your Google App Engine compatible ThreadFactory with the class com.user.project.GoogleAppEngineThreadFactory you can make Drools to use it by setting:

It is now possible to use as input argument for a query both the field of a fact as in:

and more in general any kind of valid expression like in:

Property reactivity has been introduced to avoid unwanted and useless (re)evaluations and allow the engine to react only to
modification of properties actually constrained or bound inside of a given pattern. However this feature is automatically available
only for modifications performed inside the consequence of a rule. Conversely a programmatic update is unaware of the object’s
properties that have been changed, so it is unable of using this feature.

To overcome this limitation it is now possible to optionally specify in an update statement the names of the properties that
have been changed in the modified object as in the following example:

A new type of MBean has been introduced in order to provide monitoring of the KieContainers, and the JMX MBeans hierarchical structure have been revisited to reflect the relationship with the related MBeans of the KieBases.
The JMX objectnaming has been normalized to reflect the terminology used in the Kie API.
A new type of MBean has been introduced in order to provide monitoring for Stateless KieSession, which was not available in previous releases.

The KieSession MBeans consolidate the statistics data for all sessions instantiated under the same name.

KieSession created via JPAKnowledgeService, will be monitored under a KieSession MBean having constant {ksessionName} valorized to persistent; this MBean is not managed by the KieContainer directly, hence it requires to be manually deregistered from JMX, when monitoring is no longer needed.

The new JMX objectnaming scheme now enforces proper JMX quoting for IDs, e.g.: org.kie:kcontainerId="2cb55f40-f220-432a-aba8-7940c18bf108",kbaseId="KBase1"

The old DroolsManagementAgent (which was registered on JMX under org.drools:type=DroolsManagementAgent) is no longer necessary, hence no longer registered on JMX.

The KieSession MBeans now have proper JMX CompositeData and TabularData support, where applicable. The KieSession MBeans continue to support all process-related aggregated statistics monitoring, but no longer display start/end dates for each process instances: auditing and logging support is available in jBPM for this scope.

The Drools RHQ/JON plug-in have been changed to reflect all the above mentioned changes, in addition to specific bug-fixing aiming to display hierarchical nesting correctly.

It is now possible to use Java 8 syntax (lambdas and method references) in the Right Hand Side (then) part of a rule.

The incremental compilation (dynamic rule-base update) had some relevant flaws when one or more rules with a subnetwork (rules with complex existential patterns) were involved, especially when the same subnetwork was shared among different rules.
This issue required a partial rewriting of the existing incremental compilation algorithm, followed by a complete audit that has also been validated by brand new test suite made by more than 20,000 test cases only in this area.

Engine’s code dealing with multi-threading has been partially rewritten in order to remove a large number of synchronisation points and improve stability and predictability.
In particular this new implementation allows a clearer separation and better interaction between the User thread (performing the insert/update/delete actions on the session), the Engine thread (doing the proper rules evaluation) and the Timer one (performing time-based actions like events expiration).

This improvement has been made possible by the new phreak algorithm introduced with Drools 6.
In fact with in the ReteOO algorithm the network evaluation is performed during the User insert/update/delete action, meaning that each user action locks the entire engine.
Conversely with phreak the insert/update/delete is separated and the network evaluation happens when fireAllRules or fireUntilHalt is called.

More in detail this improvement has been made by 2 parts.
First of all a new thread-safe queue has been added to store all user actions as commands.
This queue is populated by the User thread while its entries are flushed and processed by the Engine thread during the rules evaluations phase.
The second part introduced a state machine coordinating the User, Timer and Engine threads and then providing a clearer and self-documenting way to model their interactions.

OOPath has been introduced with Drools 6.3.0.
In Drools 6.4.0 it has been enhanced to support the following features:

The general look and feel in the entire workbench has been updated to adopt PatternFly.
The update brings a cleaner, lightweight and more consistent user experience throughout every screen.
Allowing users focus on the data and the tasks by removing all uncessary visual elements.
Interactions and behaviors remain mostly unchanged, limiting the scope of this change to visual updates.

In addition to the PatternFly update described above which targeted the general look and feel, many individual components in the workbench have been improved to create a better user experience.
This involved making sure the default size of modal popup windows is appropriate to fit the corresponding content, adjusting the size of text fields as well as aligning labels, and improving the resize behaviour of various components when used on smaller screens.

Locales ru (Russian) and zh_TW (Chineses Traditional) have now been added.

The locales now supported are:

The Workbench used to have a section in the Project Editor for "Import Suggestions" which was really a way for Users to register classes provided by the Java Runtime environment to be available to Rule authoring.
Furthermore Editors had a "Config" tab which was where Users were expected to import classes from other packages to that in which the rule resides.

Neither term was clear and both were inconsistent with each other and other aspects of the Workbench.

We have changed these terms to (hopefully) be clearer in their meaning and to be consistent with the "Data Object" term used in relation to authoring Java classes within the Workbench.

The Data Object screen lists all Data Objects in the same package as the asset and allows other Data Objects from other packages to be imported.

When navigating Projects with the Project Explorer the workbench automatically builds the selected project, displaying build messages in the Message Console.
Whilst this is beneficial it can have a detremental impact on performance of the workbench when authoring large projects.
The automatic build can now be disabled with the org.kie.build.disable-project-explorer System Property.
Set the value to true to disable.
The default value is false.

When cloning git Repositories it is now possible to use SCP style URLS, for example git@github.com:user/repository.git.
If your Operating System’s public keystore is password protected the passphrase can be provided with the org.uberfire.nio.git.ssh.passphrase System Property.

When performing any of the following operations a check is now made against all Maven Repositories, resolved for the Project, for whether the Project’s GroupId, ArtifactId and Version pre-exist.
If a clash is found the operation is prevented; although this can be overridden by Users with the admin role.

Resolved repositories are those discovered in:

Affected operations:

Users with the Admin role can override the list of Repositories checked using the "Repositories" settings in the Project Editor.

The KIE Execution Server Management UI has been completely redesigned to adjust to major improvements introduced recently.
Besides the fact that new UI has been built from scratch and following best practices provided by PatternFly, the new interface expands previous features giving users more control of their servers.

Provides the backend services and an intuitive and friendly user interface that allows the workbench administrators to manage the application’s users and groups.

This interface provides to the workbench administrators the ability to perform realm related operations such as create users, create groups, assign groups or roles to a given user, etc.

It comes by default with built-in implementations for the administration of Wildfly, EAP and Tomcat default realms, and it’s designed to be extensible - any third party realm management system can be easily integrated into the workbench.

When the field of a fact is a collection it is possible to bind and reason over all the items in that collection on by one using the from keyword.
Nevertheless, when it is required to browse a graph of object the extensive use of the from conditional element may result in a verbose and cubersome syntax like in the following example:

In this example it has been assumed to use a domain model consisting of a Student who has a Plan of study: a Plan can have zero or more Exams and an Exam zero or more Grades.
Note that only the root object of the graph (the Student in this case) needs to be in the working memory in order to make this works.

By borrowing ideas from XPath, this syntax can be made more succinct, as XPath has a compact notation for navigating through related elements while handling collections and filtering constraints.
This XPath-inspired notation has been called OOPath since it is explictly intended to browse graph of objects.
Using this notation the former example can be rewritten as it follows:

Formally, the core grammar of an OOPath expression can be defined in EBNF notation in this way.

In practice an OOPath expression has the following features.

A new viewer has been added to the Eclipse Tooling.
This Kie Navigator View is used to manage Kie Server installations and projects.

Please read the chapter Kie Navigator View
for more information about this new feature

Decision tables used to have a Validation-button for validating the table.
This is now removed and the table is validated after each cell value change.
The validation and verification checks include:

These checks are explained in detail in the workbench documentation.

The DRL Editor has undergone a face lift; moving from a plain TextArea to using ACE Editor and a custom DRL syntax highlighter.

To avoid conflicts when editing assets, a new locking mechanism has been introduced that makes sure that only one user at a time can edit an asset.
When a user begins to edit an asset, a lock will automatically be acquired.
This is indicated by a lock symbol appearing on the asset title bar as well as in the project explorer view.
If a user starts editing an already locked asset a pop-up notification will appear to inform the user that the asset can’t currently be edited, as it is being worked on by another user.
As long as the editing user holds the lock, changes by other users will be prevented.
Locks will automatically be released when the editing user saves or closes the asset, or logs out of the workbench.
Every user further has the option to force a lock release in the metadata tab, if required.

Drools and jBPM configurations, Persistence (see Generation of JPA enabled Data Models) and Advanced configurations were moved into "Tool Windows". "Tool Windows" are a new concept introduced in latest Uberfire version that enables the development of context aware screens.
Each "Tool Window" will contain a domain editor that will manage a set of related Data Object parameters.

Data modeller was extended to support the generation of persistable Data Objects.
The persistable Data Objects are based on the JPA specification and all the underlying metadata are automatically generated.

A new perspective for authoring data set definitions has been added.
Data set definitions make it possible to retrieve data from external systems like databases, CSV/Excel files or even use a Java class to generate the data.
Once the data is available it can be used, for instance, to create charts and dashboards from the Perspective Editor just feeding the charts from any of the data sets available.

The introduction of PHREAK as default algorithm for the Drools engine made the rules' evaluation lazy.
This new Drools lazy behavior allowed a relevant performance boost but, in some very specific cases, breaks the semantic of a few Drools features.

More precisely in some circumstances it is necessary to propagate the insertion of new fact into th session immediately.
For instance Drools allows a query to be executed in pull only (or passive) mode by prepending a '?' symbol to its invocation as in the following example:

In this case, since the query is passive, it shouldn’t react to the insertion of a String matching the join condition in the query itself.
In other words this sequence of commands

shouldn’t cause the rule R to fire because the String satisfying the query condition has been inserted after the Integer and the passive query shouldn’t react to this insertion.
Conversely the rule should fire if the insertion sequence is inverted because the insertion of the Integer, when the passive query can be satisfied by the presence of an already existing String, will trigger it.

Unfortunately the lazy nature of PHREAK doesn’t allow the engine to make any distinction regarding the insertion sequence of the two facts, so the rule will fire in both cases.
In circumstances like this it is necessary to evaluate the rule eagerly as done by the old RETEOO-based engine.

In other cases it is required that the propagation is eager, meaning that it is not immedate, but anyway has to happen before the engine/agenda starts scheduled evaluations.
For instance this is necessary when a rule has the no-loop or the lock-on-active attribute and in fact when this happens this propagation mode is automatically enforced by the engine.

To cover these use cases, and in all other situations where an immediate or eager rule evaluation is required, it is possible to declaratively specify so by annotating the rule itself with @Propagation(Propagation.Type), where Propagation.Type is an enumeration with 3 possible values:

This means that the following drl:

will make the rule R to fire if and only if the Integer is inserted after the String, thus behaving in accordance with the semantic of the passive query.

This feature makes it possible to download a repository or a folder from the repository as a ZIP file.

The ability to configure role-based permissions for the Project Editor have been added.

Permissions can be configured using the WEB-INF/classes/workbench-policy.properties file.

The following permissions are supported:

All of our new screens use GWT-Bootstrap widgets and alert users to input errors in a consistent way.

One of the most noticable differences was the Guided Decision Table Wizard that alerted errors in a way inconsistent with our use of GWT-Bootstrap.

This Wizard has been updated to use the new look and feel.

During the re-work of the Guided Decision Table’s Wizard to make it’s validation consistent with other areas of the application we took the opportunity to move the Wizard Framework to GWT-Bootstrap too.

The resulting appearance is much more pleasing.
We hope to migrate more legacy editors to GWT-Bootstrap as time and priorities permit.

Consistency is a good thing for everybody.
Users can expect different authoring metaphores to produce the same rule behaviour (and developers know when something is a bug!).

There were a few inconsistencies in the way XLS Decision Tables, Guidied Decision Tables and Guided Rule Templates generated the underlying rules for empty cells.
These have been eliminated making their operation consistent.

The Metadata tab provided in previous versions was redesigned to provide a better asset versioning information browsing and recovery.
Now every workbench editor will provide an "Overview tab" that will enable the user to manage the following information.

The Java editor was unified to the standard workbench editors functioning.
It means that and now every data object is edited on his own editor window.

A new perspective called Management has been added under Servers top level menu.
This perspective provides users the ability to manage multiple execution servers with multiple containers.
Available features includes connect to already deployed execution servers; create new, start, stop, delete or upgrade containers.

A brand new feature called Social Activities has been added under a new top level menu item group called Activity.

This new feature is divided in two different perspectives: Timeline Perspective and People Perspective.

The Timeline Perspective shows on left side the recent assets created or edited by the logged user.
In the main window there is the "Latest Changes" screen, showing all the recent updated assets and an option to filter the recent updates by repository.

The People Perspective is the home page of an user.
Showing his infos (including a gravatar picture from user e-mail), user connections (people that user follow) and user recent activities.
There is also a way to edit an user info.
The search suggestion can be used to navigate to a user profile, follow him and see his updates on your timeline.

A brand new perspective called Contributors has been added under a new top level menu item group called Activity.
The perspective itself is a dashboard which shows several indicators about the contributions made to the managed organizations / repositories within the workbench.
Every time a organization/repository is added/removed from the workbench the dashboard itself is updated accordingly.

This new perspective allows for the monitoring of the underlying activity on the managed repositories.

The location of new assets whilst authoring was driven by the context of the Project Explorer.

This has been replaced with a Package Selector in the New Resource Popup.

The location defaults to the Project Explorer context but different packages can now be more easily chosen.

All Popups have been refactored to use GWT-Bootstrap widgets.

Whilst a simple change it brings greater visual consistency to the application as a whole.

A new editor has been added to support modelling of simple decision trees.

See the applicable section within the User Guide for more information about usage.

A wizard has been created to guide the repository creation process.
Now the user can decide at repository creation time if it should be a managed or unmanaged repository and configure all related parameters.

The new Repository Structure Screen will let users to manage the projects for a given repository, as well as other operations related to managed repositories like: branch creation, assets promotion and project release.

A new KIE Execution Server was created with the goal of supporting the deployment of kjars and the automatic creation of REST endpoints for remote rules execution.
This initial implementation supports provisioning and execution of kjars via REST without any glue code.

A user interface was also integrated into the workbench for remote provisioning.
See the workbench’s New&Noteworthy for details.

Added support for JMX monitoring and management on KieScanner and KieContainer.
To enable, set the property kie.scanner.mbeans to enabled, for example via Java command line: -Dkie.scanner.mbeans=enabled .

KieScannerMBean will register under the name:

It exposes the following properties:

It also exposes the following operations:

Full round trip between Data modeler and Java source code is now supported.
No matter where the Java code was generated (e.g.
Eclipse, Data modeller), data modeler will only update the necessary code blocks to maintain the model updated.

New annotations @TypeSafe, @ClassReactive, @PropertyReactive, @Timestamp, @Duration and @Expires were added in order enrich current Drools annotations manged by the data modeler.

We have standardized the display of tabular data with a new table widget.

The new table supports the following features:

The table is used in the following scenarios:

The Guided Rule Editor, Guided Template Editor and Guided Decision Table Editor have been changed to generate modify(x){…​}

Historically these editors supported the older update(x) syntax and hence rules created within the Workbench would not respond correctly to @PropertyReactive and associated annotations within a model.
This has now been rectified with the use of modify(x){…​} blocks.

KIE is the new umbrella name used to group together our related projects; as the family continues to grow.
KIE is also used for the generic parts of unified API; such as building, deploying and loading.
This replaces the droolsjbpm and knowledge keywords that would have been used before.

One of the biggest complaints during the 5.x series was the lack of defined methodology for deployment.
The mechanism used by Drools and jBPM was very flexible, but it was too flexible.
A big focus for 6.0 was streamlining the build, deploy and loading (utilization) aspects of the system.
Building and deploying activities are now aligned with Maven and Maven repositories.
The utilization for loading rules and processess is now convention and configuration oriented, instead of programmatic, with sane defaults to minimise the configuration.

Projects can be built with Maven and installed to the local M2_REPO or remote Maven repositories.
Maven is then used to declare and build the classpath of dependencies, for KIE to access.

The 'kmodule.xml' provides declarative configuration for KIE projects.
Conventions and defaults are used to reduce the amount of configuration needed.

It is possible to include all the KIE artifacts belonging to a KieBase into a second KieBase.
This means that the second KieBase, in addition to all the rules, function and processes directly defined into it, will also contain the ones created in the included KieBase.
This inclusion can be done declaratively in the kmodule.xml file

or programmatically using the KieModuleModel.

Any Maven produced JAR with a 'kmodule.xml' in it is considered a KieModule.
This can be loaded from the classpath or dynamically at runtime from a Resource location.
If the kie-ci dependency is on the classpath it embeds Maven and all resolving is done automatically using Maven and can access local or remote repositories.
Settings.xml is obeyed for Maven configuration.

The KieContainer provides a runtime to utilize the KieModule, versioning is built in throughout, via Maven.
Kie-ci will create a classpath dynamically from all the Maven declared dependencies for the artifact being loaded.
Maven LATEST, SNAPSHOT, RELEASE and version ranges are supported.

KieContainers can be dynamically updated to a specific version, and resolved through Maven if KIE-CI is on the classpath.
For stateful KieSessions the existing sessions are incrementally updated.

The KieScanner is a Maven-oriented replacement of the KnowledgeAgent present in Drools 5.
It continuously monitors your Maven repository to check if a new release of a Kie project has been installed and if so, deploys it in the KieContainer wrapping that project.
The use of the KieScanner requires kie-ci.jar to be on the classpath.

A KieScanner can be registered on a KieContainer as in the following example.

In this example the KieScanner is configured to run with a fixed time interval, but it is also possible to run it on demand by invoking the scanNow() method on it.
If the KieScanner finds, in the Maven repository, an updated version of the Kie project used by that KieContainer it automatically downloads the new version and triggers an incremental build of the new project.
From this moment all the new KieBases and KieSessions created from that KieContainer will use the new project version.

The CompositeClassLoader is no longer used; as it was a constant source of performance problems and bugs.
Traditional hierarchical classloaders are now used.
The root classloader is at the KieContext level, with one child ClassLoader per namespace.
This makes it cleaner to add and remove rules, but there can now be no referencing between namespaces in DRL files; i.e.
functions can only be used by the namespaces that declared them.
The recommendation is to use static Java methods in your project, which is visible to all namespaces; but those cannot (like other classes on the root KieContainer ClassLoader) be dynamically updated.

The 5.x API for building and running with Drools and jBPM is still available through Maven dependency "knowledge-api-legacy5-adapter". Because the nature of deployment has significantly changed in 6.0, it was not possible to provide an adapter bridge for the KnowledgeAgent.
If any other methods are missing or problematic, please open a JIRA, and we’ll fix for 6.1

While a lot of new documentation has been added for working with the new KIE API, the entire documentation has not yet been brought up to date.
For this reason there will be continued references to old terminologies.
Apologies in advance, and thank you for your patience.
We hope those in the community will work with us to get the documentation updated throughout, for 6.1

The main work done for Drools in 6.0 involves the new PREAK algorithm.
This is a lazy algorithm that should enable Drools to handle a larger number of rules and facts.
AngendaGroups can now help improvement performance, as rules are not evaluated until it attempts to fire them.

Sequential mode continues to be supported for PHREAK but now 'modify' is allowed.
While there is no 'inference' with sequential configuration, as rules are lazily evaluated, any rule not yet evaluated will see the more recent data as a result of 'modify'. This is more inline with how people intuitively think sequential works.

The conflict resolution order has been tweaked for PHREAK, and now is ordered by salience and then rule order; based on the rule position in the file.. Prior to Drools 6.0.0, after salience, it was considered arbitrary.
When KieModules and updateToVersion are used for dynamic deployment, the rule order in the file is preserved via the diff processing.

When the rule engine runs in passive mode (i.e.: using fireAllRules) by default it doesn’t fire consequences of timed rules unless fireAllRules isn’t invoked again.
Now it is possible to change this default behavior by configuring the KieSession with a TimedRuleExectionOption as shown in the following example.

It is also possible to have a finer grained control on the timed rules that have to be automatically executed.
To do this it is necessary to set a `FILTERED`TimedRuleExectionOption that allows to define a callback to filter those rules, as done in the next example.

It is now possible to define both the delay and interval of an interval timer as an expression instead of a fixed value.
To do that it is necessary to declare the timer as an expression one (indicated by "expr:") as in the following example:

The expressions, $d and $p in this case, can use any variable defined in the pattern matching part of the rule and can be any String that can be parsed in a time duration or any numeric value that will be internally converted in a long representing a duration expressed in milliseconds.

Both interval and expression timers can have 3 optional parameters named "start", "end" and "repeat-limit". When one or more of these parameters are used the first part of the timer definition must be followed by a semicolon ';' and the parameters have to be separated by a comma ',' as in the following example:

The value for start and end parameters can be a Date, a String representing a Date or a long, or more in general any Number, that will be transformed in a Java Date applying the following conversion:

Conversely the repeat-limit can be only an integer and it defines the maximum number of repetitions allowed by the timer.
If both the end and the repeat-limit parameters are set the timer will stop when the first of the two will be matched.

The using of the start parameter implies the definition of a phase for the timer, where the beginning of the phase is given by the start itself plus the eventual delay.
In other words in this case the timed rule will then be scheduled at times:

for up to repeat-limit times and no later than the end timestamp (whichever first). For instance the rule having the following interval timer

will be scheduled at the 30th second of every minute after the midnight of the 3-JAN-2010.
This also means that if for example you turn the system on at midnight of the 3-FEB-2010 it won’t be scheduled immediately but will preserve the phase defined by the timer and so it will be scheduled for the first time 30 seconds after the midnight.
If for some reason the system is paused (e.g.
the session is serialized and then deserialized after a while) the rule will be scheduled only once to recover from missing activations (regardless of how many activations we missed) and subsequently it will be scheduled again in phase with the timer.

These two groups have been merged and now RuleFlowGroups behave the same as AgendaGroups.
The get methods have been left, for deprecation reasons, but both return the same underlying data.
When jBPM activates a group it now just calls setFocus.
RuleFlowGroups and AgendaGroups when used together was a continued source of errors.
It also aligns the codebase, towards PHREAK and the multi-core explotation that is planned in the future.

CDI is now tightly integrated into the KIE API.
It can be used to inject versioned KieSession and KieBases.

Spring has been revamped and now integrated with KIE.
Spring can replace the 'kmodule.xml' with a more powerful spring version.
The aim is for consistency with kmodule.xml

Aries blueprints is now also supported, and follows the work done for spring.
The aim is for consistency with spring and kmodule.xml

All modules have been refactored to avoid package splitting, which was a problem in 5.x.
Testing has been moved to PAX.

The process of researching an integration knowledge solution for Drools and jBPM has simply used the "droolsjbpm" group name.
This name permeates GitHub accounts and Maven POMs.
As scopes broadened and new projects were spun KIE, an acronym for Knowledge Is Everything, was chosen as the new group name.
The KIE name is also used for the shared aspects of the system; such as the unified build, deploy and utilization.

KIE currently consists of the following subprojects:

OptaPlanner, a local search and optimization tool, has been spun off from Drools Planner and is now a top level project with Drools and jBPM.
This was a natural evolution as Optaplanner, while having strong Drools integration, has long been independant of Drools.

From the Polymita acquisition, along with other things, comes the powerful Dashboard Builder which provides powerful reporting capabilities.
Dashboard Builder is currently a temporary name and after the 6.0 release a new name will be chosen.
Dashboard Builder is completely independant of Drools and jBPM and will be used by many projects at JBoss, and hopefully outside of JBoss :)

UberFire is the new base workbench project, spun off from the ground up rewrite.
UberFire provides Eclipse-like workbench capabilities, with panels and perspectives from plugins.
The project is independant of Drools and jBPM and anyone can use it as a basis of building flexible and powerful workbenches.
UberFire will be used for console and workbench development throughout JBoss.

It was determined that the Guvnor brand leaked too much from its intended role; such as the authoring metaphors, like Decision Tables, being considered Guvnor components instead of Drools components.
This wasn’t helped by the monolithic projects structure used in 5.x for Guvnor.
In 6.0 Guvnor’s focus has been narrowed to encapsulate the set of UberFire plugins that provide the basis for building a web based IDE.
Such as Maven integration for building and deploying, management of Maven repositories and activity notifications via inboxes.
Drools and jBPM build workbench distributions using Uberfire as the base and including a set of plugins, such as Guvnor, along with their own plugins for things like decision tables, guided editors, BPMN2 designer, human tasks.
The Drools workbench is called Drools-WB.
KIE-WB is the uber workbench that combined all the Guvnor, Drools and jBPM plugins.
The jBPM-WB is ghosted out, as it doesn’t actually exist, being made redundant by KIE-WB.

The different aspects, or life cycles, of working with KIE system, whether it’s Drools or jBPM, can typically be broken down into the following:

6.0 introduces a new configuration and convention approach to building knowledge bases, instead of using the programmatic builder approach in 5.x.
The builder is still available to fall back on, as it’s used for the tooling integration.

Building now uses Maven, and aligns with Maven practices.
A KIE project or module is simply a Maven Java project or module; with an additional metadata file META-INF/kmodule.xml.
The kmodule.xml file is the descriptor that selects resources to knowledge bases and configures those knowledge bases and sessions.
There is also alternative XML support via Spring and OSGi BluePrints.

While standard Maven can build and package KIE resources, it will not provide validation at build time.
There is a Maven plugin which is recommended to use to get build time validation.
The plugin also generates many classes, making the runtime loading faster too.

The example project layout and Maven POM descriptor is illustrated in the screenshot

KIE uses defaults to minimise the amount of configuration.
With an empty kmodule.xml being the simplest configuration.
There must always be a kmodule.xml file, even if empty, as it’s used for discovery of the JAR and its contents.

Maven can either 'mvn install' to deploy a KieModule to the local machine, where all other applications on the local machine use it.
Or it can 'mvn deploy' to push the KieModule to a remote Maven repository.
Building the Application will pull in the KieModule and populate the local Maven repository in the process.

JARs can be deployed in one of two ways.
Either added to the classpath, like any other JAR in a Maven dependency listing, or they can be dynamically loaded at runtime.
KIE will scan the classpath to find all the JARs with a kmodule.xml in it.
Each found JAR is represented by the KieModule interface.
The terms classpath KieModule and dynamic KieModule are used to refer to the two loading approaches.
While dynamic modules supports side by side versioning, classpath modules do not.
Further once a module is on the classpath, no other version may be loaded dynamically.

Detailed references for the API are included in the next sections, the impatient can jump straight to the examples section, which is fairly self-explanatory on the different use cases.

The best way to learn the new build system is by example.
The source project "drools-examples-api" contains a number of examples, and can be found at GitHub:

https://github.com/droolsjbpm/drools/tree/6.0.x/drools-examples-api

Each example is described below, the order starts with the simplest (most of the options are defaulted) and working its way up to more complex use cases.

The Deploy use cases shown below all involve mvn install.
Remote deployment of JARs in Maven is well covered in Maven literature.
Utilize refers to the initial act of loading the resources and providing access to the KIE runtimes.
Where as Run refers to the act of interacting with those runtimes.

The KIE engine is a platform for the modelling and execution of business behavior, using a multitude of declarative abstractions and metaphores, like rules, processes, decision tables and etc.

Many times, the authoring of these metaphores is done by third party groups, be it a different group inside the same company, a group from a partner company, or even anonymous third parties on the internet.

Rules and Processes are designed to execute arbitrary code in order to do their job, but in such cases it might be necessary to constrain what they can do.
For instance, it is unlikely a rule should be allowed to create a classloader (what could open the system to an attack) and certainly it should not be allowed to make a call to System.exit().

The Java Platform provides a very comprehensive and well defined security framework that allows users to define policies for what a system can do.
The KIE platform leverages that framework and allow application developers to define a specific policy to be applied to any execution of user provided code, be it in rules, processes, work item handlers and etc.

Over the last few decades artificial
intelligence
(AI) became an unpopular term, with the well-known "AI
Winter".
There were large boasts from scientists and engineers looking for funding, which never lived up to expectations, resulting in many failed projects. Thinking
Machines Corporation and the 5th
Generation Computer (5GP) project probably exemplify best the problems at the time.

Thinking Machines Corporation was one of the leading AI firms in 1990, it had sales of nearly $65 million.
Here is a quote from its brochure:

“Some day we will build a thinking machine. It will be a truly
intelligent machine. One that can see and hear and speak. A machine that
will be proud of us.”

Yet 5 years later it filed for bankruptcy protection under Chapter 11.
The site inc.com has a fascinating article titled "The Rise and
Fall of Thinking Machines".
The article covers the growth of the industry and how a cosy relationship with Thinking Machines and DARPA over-heated the market, to the point of collapse.
It explains how and why commerce moved away from AI and towards more practical number-crunching super computers.

The 5th Generation Computer project was a USD 400 million project in Japan to build a next generation computer.
Valves (or Tubes) was the first generation, transistors the second, integrated circuits the third and finally microprocessors was the fourth.
The fifth was intended to be a machine capable of effective Artificial Intelligence.
This project spurred an "arms" race with the UK and USA, that caused much of the AI bubble.
The 5GP would provide massive multi-cpu parallel processing hardware along with powerful knowledge representation and reasoning software via Prolog
; a type of [term]_ expert system_
.
By 1992 the project was considered a failure and cancelled.
It was the largest and most visible commercial venture for Prolog, and many of the failures are pinned on the problems of trying to run a logic based programming language concurrently on multi CPU hardware with effective results.
Some believe that the failure of the 5GP project tainted Prolog and relegated it to academia, see "Whatever Happened to Prolog" by John C.
Dvorak.

However while research funding dried up and the term AI became less used, many green shoots were planted and continued more quietly under discipline specific names: cognitive systems
, machine learning
, intelligent
systems
,[term]_ knowledge representation and
reasoning_
.
Offshoots of these then made their way into commercial systems, such as expert systems in the Business
Rules Management System
(BRMS) market.

Imperative
, system based languages, languages such as C, C++, Java and C#/.Net have dominated the last 20 years, enabled by the practicality of the languages and ability to run with good performance on commodity hardware.
However many believe there is a renaissance underway in the field of AI, spurred by advances in hardware capabilities and AI research.
In 2005 Heather Havenstein authored "Spring comes to AI
winter" which outlines a case for this resurgence.
Norvig and Russel dedicate several pages to what factors allowed the industry to overcome its problems and the research that came about as a result:

Computer vision
, neural networks
, machine
learning
and knowledge representation and reasoning
(KRR) have made great strides towards becoming practical in commercial environments.
For example, vision-based systems can now fully map out and navigate their environments with strong recognition skills.
As a result we now have self-driving cars about to enter the commercial market. Ontological
research, based around description logic, has provided very rich semantics to represent our world.
Algorithms such as the tableaux algorithm have made it possible to use those rich semantics effectively in large complex ontologies.
Early KRR systems, like Prolog in 5GP, were dogged by the limited semantic capabilities and memory restrictions on the size of those ontologies.

In A Little History talks about AI as a broader subject and touches on Knowledge Representation and Reasoning (KRR) and also Expert Systems, I’ll come back to Expert Systems later.

KRR is about how we represent our knowledge in symbolic form, i.e.
how we describe something.
Reasoning is about how we go about the act of thinking using this knowledge.
System based object-oriented languages, like C++, Java and C#, have data definitions called classes for describing the composition and behaviour of modeled entities.
In Java we call exemplars of these described things beans or instances.
However those classification systems are limited to ensure computational efficiency.
Over the years researchers have developed increasingly sophisticated ways to represent our world.
Many of you may already have heard of OWL (Web Ontology Language). There is always a gap between what can be theoretically represented and what can be used computationally in practically timely manner, which is why OWL has different sub-languages from Lite to Full.
It is not believed that any reasoning system can support OWL Full.
However, algorithmic advances continue to narrow that gap and improve the expressiveness available to reasoning engines.

There are also many approaches to how these systems go about thinking.
You may have heard discussions comparing the merits of forward chaining, which is reactive and data driven, with backward chaining, which is passive and query driven.
Many other types of reasoning techniques exist, each of which enlarges the scope of the problems we can tackle declaratively.
To list just a few: imperfect reasoning (fuzzy logic, certainty factors), defeasible logic, belief systems, temporal reasoning and correlation.
You don’t need to understand all these terms to understand and use Drools.
They are just there to give an idea of the range of scope of research topics, which is actually far more extensive, and continues to grow as researchers push new boundaries.

KRR is often referred to as the core of Artificial Intelligence.
Even when using biological approaches like neural networks, which model the brain and are more about pattern recognition than thinking, they still build on KRR theory.
My first endeavours with Drools were engineering oriented, as I had no formal training or understanding of KRR.
Learning KRR has allowed me to get a much wider theoretical background,
and to better understand both what I’ve done and where I’m going, as it underpins nearly all of the theoretical side to our Drools R&D.
It really is a vast and fascinating subject that will pay dividends for those who take the time to learn.
I know it did and still does for me.
Bracham and Levesque have written a seminal piece of work, called "Knowledge Representation and Reasoning" that is a must read for anyone wanting to build strong foundations.
I would also recommend the Russel and Norvig book "Artificial Intelligence, a modern approach" which also covers KRR.

We’ve now covered a brief history of AI and learnt that the core of AI is formed around KRR.
We’ve shown than KRR is a vast and fascinating subject which forms the bulk of the theory driving Drools R&D.

The rule engine is the computer program that delivers KRR functionality to the developer.
At a high level it has three components:

As previously mentioned the ontology is the representation model we use for our "things". It could use records or Java classes or full-blown OWL based ontologies.
The rules perform the reasoning, i.e., they facilitate "thinking". The distinction between rules and ontologies blurs a little with OWL based ontologies, whose richness is rule based.

The term "rules engine" is quite ambiguous in that it can be any system that uses rules, in any form, that can be applied to data to produce outcomes.
This includes simple systems like form validation and dynamic expression engines.
The book "How to Build a Business Rules Engine" (2004) by Malcolm Chisholm exemplifies this ambiguity.
The book is actually about how to build and alter a database schema to hold validation rules.
The book then shows how to generate Visual Basic code from those validation rules to validate data entry.
While perfectly valid, this is very different to what we are talking about.

Drools started life as a specific type of rule engine called a Production Rule System (PRS) and was based around the Rete algorithm (usually pronounced as two syllables, e.g., REH-te or RAY-tay). The Rete algorithm, developed by Charles Forgy in 1974, forms the brain of a Production Rule System and is able to scale to a large number of rules and facts.
A Production Rule is a two-part structure: the engine matches facts and data against Production Rules - also called Productions or just Rules - to infer conclusions which result in actions.

The process of matching the new or existing facts against Production Rules is called pattern
matching

, which is performed by the inference engine

.
Actions execute in response to changes in data, like a database trigger; we say this is a data driven

approach to reasoning.
The actions themselves can change data, which in turn could match against other rules causing them to fire; this is referred to as

forward chaining

Drools 5.x implements and extends the Rete

algorithm.
This extended Rete algorithm is named ReteOO

, signifying that Drools has an enhanced and optimized implementation of the Rete algorithm for object oriented systems.
Other Rete based engines also have marketing terms for their proprietary enhancements to Rete, like RetePlus and Rete III.
The most common enhancements are covered in "Production Matching for Large Learning Systems" (1995) by Robert B.
Doorenbos' thesis, which presents Rete/UL.
Drools 6.x introduces a new lazy algorithm named PHREAK

; which is covered in more detail in the PHREAK algorithm section.

The Rules are stored in the

Production Memory and the facts that the Inference Engine matches against are kept in the

Working Memory.
Facts are asserted into the Working Memory where they may then be modified or retracted.
A system with a large number of rules and facts may result in many rules being true for the same fact assertion; these rules are said to be in conflict.
The Agenda manages the execution order of these conflicting rules using a Conflict Resolution strategy.

You may have read discussions comparing the merits of forward chaining (reactive and data driven) or backward chaining (passive query). Here is a quick explanation of these two main types of reasoning.

Forward chaining is "data-driven" and thus reactionary, with facts being asserted into working memory, which results in one or more rules being concurrently true and scheduled for execution by the Agenda.
In short, we start with a fact, it propagates through the rules, and we end in a conclusion.

Backward chaining is "goal-driven", meaning that we start with a conclusion which the engine tries to satisfy.
If it can’t, then it searches for conclusions that it can satisfy.
These are known as subgoals, that will help satisfy some unknown part of the current goal.
It continues this process until either the initial conclusion is proven or there are no more subgoals.
Prolog is an example of a Backward Chaining engine.
Drools can also do backward chaining, which we refer to as derivation queries.

Historically you would have to make a choice between systems like OPS5 (forward) or Prolog (backward). Nowadays many modern systems provide both types of reasoning capabilities.
There are also many other types of reasoning techniques, each of which enlarges the scope of the problems we can tackle declaratively.
To list just a few: imperfect reasoning (fuzzy logic, certainty factors), defeasible logic, belief systems, temporal reasoning and correlation.
Modern systems are merging these capabilities, and others not listed, to create hybrid reasoning
systems
(HRS).

While Drools started out as a PRS, 5.x introduced Prolog style backward chaining reasoning as well as some functional programming styles.
For this reason we now prefer the term Hybrid Reasoning System when describing Drools.

Drools currently provides crisp reasoning, but imperfect reasoning is almost ready.
Initially this will be imperfect reasoning with fuzzy logic; later we’ll add support for other types of uncertainty.
Work is also under way to bring OWL based ontological reasoning, which will integrate with our traits
system.
We also continue to improve our functional programming capabilities.

You will often hear the terms expert systems
used to refer to production rule systems
or Prolog
-like systems.
While this is normally acceptable, it’s technically incorrect as these are frameworks to build expert systems with, rather than expert systems themselves.
It becomes an expert system once there is an ontological model to represent the domain and there are facilities for knowledge acquisition and explanation.

Mycin
is the most famous expert system, built during the 70s.
It is still heavily covered in academic literature, such as the recommended book "Expert Systems" by Peter Jackson.

*
General AI, KRR and Expert System
Books*

For those wanting to get a strong theoretical background in KRR and expert systems, I’d strongly recommend the following books.
"Artificial Intelligence: A Modern Approach" is a must have, for anyone’s bookshelf.

*
Papers*

Here are some recommended papers that cover interesting areas in rule engine research:

*
Drools Books*

There are currently three Drools books, all from Packt Publishing.

So where do we get started? There are so many use cases and so much functionality in a rule engine such as Drools that it becomes beguiling.
Have no fear my intrepid adventurer, the complexity is layered and you can ease yourself in with simple use cases.

Stateless session, not utilising inference, forms the simplest use case.
A stateless session can be called like a function passing it some data and then receiving some results back.
Some common use cases for stateless sessions are, but not limited to:

So let’s start with a very simple example using a driving license application.

Now that we have our data model we can write our first rule.
We assume that the application uses rules to reject invalid applications.
As this is a simple validation use case we will add a single rule to disqualify any applicant younger than 18.

To make the engine aware of data, so it can be processed against the rules, we have to insert the data, much like with a database.
When the Applicant instance is inserted into the engine it is evaluated against the constraints of the rules, in this case just two constraints for one rule.
We say two because the type Applicant is the first object type constraint, and age < 18 is the second field constraint.
An object type constraint plus its zero or more field constraints is referred to as a pattern.
When an inserted instance satisfies both the object type constraint and all the field constraints, it is said to be matched.
The $a is a binding variable which permits us to reference the matched object in the consequence.
There its properties can be updated.
The dollar character ('$') is optional, but it helps to differentiate variable names from field names.
The process of matching patterns against the inserted data is, not surprisingly, often referred to as pattern matching.

To use this rule it is necessary to put it a Drools file, just a plain text file with .drl extension , short for "Drools Rule Language". Let’s call this file licenseApplication.drl, and store it in a Kie Project.
A Kie Project has the structure of a normal Maven project with an additional file (kmodule.xml) defining the KieBases and KieSessions that can be created.
This file has to be placed in the resources/META-INF folder of the Maven project while all the other Drools artifacts, such as the licenseApplication.drl containing the former rule, must be stored in the resources folder or in any other subfolder under it.

Since meaningful defaults have been provided for all configuration aspects, the simplest kmodule.xml file can contain just an empty kmodule tag like the following:

At this point it is possible to create a KieContainer that reads the files to be built, from the classpath.

The above code snippet compiles all the DRL files found on the classpath and put the result of this compilation, a KieModule, in the KieContainer.
If there are no errors, we are now ready to create our session from the KieContainer and execute against some data:

The preceding code executes the data against the rules.
Since the applicant is under the age of 18, the application is marked as invalid.

So far we’ve only used a single instance, but what if we want to use more than one? We can execute against any object implementing Iterable, such as a collection.
Let’s add another class called Application, which has the date of the application, and we’ll also move the boolean valid field to the Application class.

We will also add another rule to validate that the application was made within a period of time.

Unfortunately a Java array does not implement the Iterable interface, so we have to use the JDK converter method Arrays.asList(…​).
The code shown below executes against an iterable list, where all collection elements are inserted before any matched rules are fired.

The two execute methods execute(Object object) and execute(Iterable objects) are actually convenience methods for the interface BatchExecutor's method execute(Command command).

The KieCommands commands factory, obtainable from the KieServices like all other factories of the KIE API, is used to create commands, so that the following is equivalent to execute(Iterable it):

Batch Executor and Command Factory are particularly useful when working with multiple Commands and with output identifiers for obtaining results.

CommandFactory supports many other Commands that can be used in the BatchExecutor like StartProcess, Query, and SetGlobal.

Stateful Sessions are long lived and allow iterative changes over time.
Some common use cases for Stateful Sessions are, but not limited to:

In contrast to a Stateless Session, the dispose() method must be called afterwards to ensure there are no memory leaks, as the KieBase contains references to Stateful Knowledge Sessions when they are created.
Since Stateful Knowledge Session is the most commonly used session type it is just named KieSession in the KIE API. KieSession also supports the BatchExecutor interface, like StatelessKieSession, the only difference being that the FireAllRules command is not automatically called at the end for a Stateful Session.

We illustrate the monitoring use case with an example for raising a fire alarm.
Using just four classes, we represent rooms in a house, each of which has one sprinkler.
If a fire starts in a room, we represent that with a single Fire instance.

In the previous section on Stateless Sessions the concepts of inserting and matching against data were introduced.
That example assumed that only a single instance of each object type was ever inserted and thus only used literal constraints.
However, a house has many rooms, so rules must express relationships between objects, such as a sprinkler being in a certain room.
This is best done by using a binding variable as a constraint in a pattern.
This "join" process results in what is called cross products, which are covered in the next section.

When a fire occurs an instance of the Fire class is created, for that room, and inserted into the session.
The rule uses a binding on the room field of the Fire object to constrain matching to the sprinkler for that room, which is currently off.
When this rule fires and the consequence is executed the sprinkler is turned on.

Whereas the Stateless Session uses standard Java syntax to modify a field, in the above rule we use the modify statement, which acts as a sort of "with" statement.
It may contain a series of comma separated Java expressions, i.e., calls to setters of the object selected by the modify statement’s control expression.
This modifies the data, and makes the engine aware of those changes so it can reason over them once more.
This process is called inference, and it’s essential for the working of a Stateful Session.
Stateless Sessions typically do not use inference, so the engine does not need to be aware of changes to data.
Inference can also be turned off explicitly by using the sequential mode.

So far we have rules that tell us when matching data exists, but what about when it does not exist? How do we determine that a fire has been extinguished, i.e., that there isn’t a Fire object any more? Previously the constraints have been sentences according to Propositional Logic, where the engine is constraining against individual instances.
Drools also has support for First Order Logic that allows you to look at sets of data.
A pattern under the keyword not matches when something does not exist.
The rule given below turns the sprinkler off as soon as the fire in that room has disappeared.

While there is one sprinkler per room, there is just a single alarm for the building.
An Alarm object is created when a fire occurs, but only one Alarm is needed for the entire building, no matter how many fires occur.
Previously not was introduced to match the absence of a fact; now we use its complement exists which matches for one or more instances of some category.

Likewise, when there are no fires we want to remove the alarm, so the not keyword can be used again.

Finally there is a general health status message that is printed when the application first starts and after the alarm is removed and all sprinklers have been turned off.

As we did in the Stateless Session example, the above rules should be placed in a single DRL file and saved into the resouces folder of your Maven project or any of its subfolder.
As before, we can then obtain a KieSession from the KieContainer.
The only difference is that this time we create a Stateful Session, whereas before we created a Stateless Session.

With the session created it is now possible to iteratively work with it over time.
Four Room objects are created and inserted, as well as one Sprinkler object for each room.
At this point the engine has done all of its matching, but no rules have fired yet.
Calling ksession.fireAllRules() allows the matched rules to fire, but without a fire that will just produce the health message.

We now create two fires and insert them; this time a reference is kept for the returned FactHandle.
A Fact Handle is an internal engine reference to the inserted instance and allows instances to be retracted or modified at a later point in time.
With the fires now in the engine, once fireAllRules() is called, the alarm is raised and the respective sprinklers are turned on.

After a while the fires will be put out and the Fire instances are retracted.
This results in the sprinklers being turned off, the alarm being cancelled, and eventually the health message is printed again.

Everyone still with me? That wasn’t so hard and already I’m hoping you can start to see the value and power of a declarative rule system.

People often confuse methods and rules, and new rule users often ask, "How do I call a rule?" After the last section, you are now feeling like a rule expert and the answer to that is obvious, but let’s summarize the differences nonetheless.

Earlier the term "cross product" was mentioned, which is the result of a join.
Imagine for a moment that the data from the fire alarm example were used in combination with the following rule where there are no field constraints:

In SQL terms this would be like doing select * from Room,
Sprinkler and every row in the Room table would be joined with every row in the Sprinkler table resulting in the following output:

These cross products can obviously become huge, and they may very well contain spurious data.
The size of cross products is often the source of performance problems for new rule authors.
From this it can be seen that it’s always desirable to constrain the cross products, which is done with the variable constraint.

This results in just four rows of data, with the correct Sprinkler for each Room.
In SQL (actually HQL) the corresponding query would be select * from Room, Sprinkler where Room ==
Sprinkler.room.

The Agenda is a Rete feature.
It maintains set of rules that are able to execute, its job is to schedule that execution in a deterministic order.

During actions on the RuleRuntime, rules may become fully matched and eligible for execution; a single Rule Runtime Action can result in multiple eligible rules.
When a rule is fully matched a Rule Match is created, referencing the rule and the matched facts, and placed onto the Agenda.
The Agenda controls the execution order of these Matches using a Conflict Resolution strategy.

The engine cycles repeatedly through two phases:

The process repeats until the agenda is clear, in which case control returns to the calling application.
When Rule Runtime Actions are taking place, no rules are being fired.

Inference has a bad name these days, as something not relevant to business use cases and just too complicated to be useful.
It is true that contrived and complicated examples occur with inference, but that should not detract from the fact that simple and useful ones exist too.
But more than this, correct use of inference can crate more agile and less error prone business rules, which are easier to maintain.

So what is inference? Something is inferred when we gain knowledge of something from using previous knowledge.
For example, given a Person fact with an age field and a rule that provides age policy control, we can infer whether a Person is an adult or a child and act on this.

Due to the preceding rule, every Person who is 18 or over will have an instance of IsAdult inserted for them.
This fact is special in that it is known as a relation.
We can use this inferred relation in any rule:

So now we know what inference is, and have a basic example, how does this facilitate good rule design and maintenance?

Let’s take a government department that are responsible for issuing ID cards when children become adults, henceforth referred to as ID department.
They might have a decision table that includes logic like this, which says when an adult living in London is 18 or over, issue the card:

However the ID department does not set the policy on who an adult is.
That’s done at a central government level.
If the central government were to change that age to 21, this would initiate a change management process.
Someone would have to liaise with the ID department and make sure their systems are updated, in time for the law going live.

This change management process and communication between departments is not ideal for an agile environment, and change becomes costly and error prone.
Also the card department is managing more information than it needs to be aware of with its "monolithic" approach to rules management which is "leaking" information better placed elsewhere.
By this I mean that it doesn’t care what explicit age ▸ = 18 information determines whether someone is an adult, only that they are an adult.

In contrast to this, let’s pursue an approach where we split (de-couple) the authoring responsibilities, so that both the central government and the ID department maintain their own rules.

It’s the central government’s job to determine who is an adult.
If they change the law they just update their central repository with the new rules, which others use:

The IsAdult fact, as discussed previously, is inferred from the policy rules.
It encapsulates the seemingly arbitrary piece of logic age ▸ = 18 and provides semantic abstractions for its meaning.
Now if anyone uses the above rules, they no longer need to be aware of explicit information that determines whether someone is an adult or not.
They can just use the inferred fact:

While the example is very minimal and trivial it illustrates some important points.
We started with a monolithic and leaky approach to our knowledge engineering.
We created a single decision table that had all possible information in it and that leaks information from central government that the ID department did not care about and did not want to manage.

We first de-coupled the knowledge process so each department was responsible for only what it needed to know.
We then encapsulated this leaky knowledge using an inferred fact IsAdult.
The use of the term IsAdult also gave a semantic abstraction to the previously arbitrary logic age ▸ = 18.

So a general rule of thumb when doing your knowledge engineering is:

After regular inserts you have to retract facts explicitly.
With logical assertions, the fact that was asserted will be automatically retracted when the conditions that asserted it in the first place are no longer true.
Actually, it’s even cleverer then that, because it will be retracted only if there isn’t any single condition that supports the logical assertion.

Normal insertions are said to be stated, i.e., just like the intuitive meaning of "stating a fact" implies.
Using a HashMap and a counter, we track how many times a particular equality is stated; this means we count how many different instances are equal.

When we logically insert an object during a RHS execution we are said to justify it, and it is considered to be justified by the firing rule.
For each logical insertion there can only be one equal object, and each subsequent equal logical insertion increases the justification counter for this logical assertion.
A justification is removed by the LHS of the creating rule becoming untrue, and the counter is decreased accordingly.
As soon as we have no more justifications the logical object is automatically retracted.

If we try to logically insert an object when there is an equal stated object, this will fail and return null.
If we state an object that has an existing equal object that is justified we override the Fact; how this override works depends on the configuration setting WM_BEHAVIOR_PRESERVE.
When the property is set to discard we use the existing handle and replace the existing instance with the new Object, which is the default behavior; otherwise we override it to stated but we create an new FactHandle.

This can be confusing on a first read, so hopefully the flow charts below help.
When it says that it returns a new FactHandle, this also indicates the Object was propagated through the network.

Consider decision tables as a course of action if rules exist that can be expressed as rule templates and data: each row of a decision table provides data that is combined with a template to generate a rule.

Many businesses already use spreadsheets for managing data, calculations, etc.
If you are happy to continue this way, you can also manage your business rules this way.
This also assumes you are happy to manage packages of rules in .xls
or .csv
files.
Decision tables are not recommended for rules that do not follow a set of templates, or where there are a small number of rules (or if there is a dislike towards software like Excel or OpenOffice.org). They are ideal in the sense that there can be control over what parameters of rules can be edited, without exposing the rules directly.

Decision tables also provide a degree of insulation from the underlying object model.

Here are some examples of real world decision tables (slightly edited to protect the innocent).

In the above examples, the technical aspects of the decision table have been collapsed away (using a standard spreadsheet feature).

The rules start from row 17, with each row resulting in a rule.
The conditions are in columns C, D, E, etc., the actions being off-screen.
The values in the cells are quite simple, and their meaning is indicated by the headers in Row 16.
Column B is just a description.
It is customary to use color to make it obvious what the different areas of the table mean.

As each row is a rule, the same principles apply.
As the rule engine processes the facts, any rules that match may fire.
(Some people are confused by this.
It is possible to clear the agenda when a rule fires and simulate a very simple decision table where only the first match effects an action.) Also note that you can have multiple tables on one spreadsheet.
This way, rules can be grouped where they share common templates, yet at the end of the day they are all combined into one rule package.
Decision tables are essentially a tool to generate DRL rules automatically.

The key point to keep in mind is that in a decision table each row is a rule, and each column in that row is either a condition or action for that rule.

The spreadsheet looks for the RuleTable
keyword to indicate the start of a rule table (both the starting row and column). Other keywords are also used to define other package level attributes (covered later). It is important to keep the keywords in one column.
By convention the second column ("B") is used for this, but it can be any column (convention is to leave a margin on the left for notes). In the following diagram, C is actually the column where it starts.
Everything to the left of this is ignored.

If we expand the hidden sections, it starts to make more sense how it works; note the keywords in column C.

Now the hidden magic which makes it work can be seen.
The RuleSet keyword indicates the name to be used in the rule package that will encompass all the rules.
This name is optional, using a default, but it must have the RuleSet keyword in the cell immediately to the right.

The other keywords visible in Column C are Import and Sequential which will be covered later.
The RuleTable keyword is important as it indicates that a chunk of rules will follow, based on some rule templates.
After the RuleTable keyword there is a name, used to prefix the names of the generated rules.
The sheet name and row numbers are appended to guarantee unique rule names.

The column of RuleTable indicates the column in which the rules start; columns to the left are ignored.

Referring to row 14 (the row immediately after RuleTable), the keywords CONDITION and ACTION indicate that the data in the columns below are for either the LHS or the RHS parts of a rule.
There are other attributes on the rule which can also be optionally set this way.

Row 15 contains declarations of ObjectTypes
.
The content in this row is optional, but if this option is not in use, the row must be left blank; however this option is usually found to be quite useful.
When using this row, the values in the cells below (row 16) become constraints on that object type.
In the above case, it generates Person(age=="42") and Cheese(type=="stilton"), where 42 and "stilton" come from row 18.
In the above example, the "==" is implicit; if just a field name is given the translator assumes that it is to generate an exact match.

Row 16 contains the rule templates themselves.
They can use the "$param" placeholder to indicate where data from the cells below should be interpolated.
(For multiple insertions, use "$1", "$2", etc., indicating parameters from a comma-separated list in a cell below.) Row 17 is ignored; it may contain textual descriptions of the column’s purpose.

Rows 18 and 19 show data, which will be combined (interpolated) with the templates in row 15, to generate rules.
If a cell contains no data, then its template is ignored.
(This would mean that some condition or action does not apply for that rule row.) Rule rows are read until there is a blank row.
Multiple RuleTables can exist in a sheet.
Row 20 contains another keyword, and a value.
The row positions of keywords like this do not matter (most people put them at the top) but their column should be the same one where the RuleTable or RuleSet keywords should appear.
In our case column C has been chosen to be significant, but any other column could be used instead.

In the above example, rules would be rendered like the following (as it uses the "ObjectType" row):

The API to use spreadsheet based decision tables is in the drools-decisiontables module.
There is really only one class to look at: SpreadsheetCompiler.
This class will take spreadsheets in various formats, and generate rules in DRL (which you can then use in the normal way). The SpreadsheetCompiler can just be used to generate partial rule files if it is wished, and assemble it into a complete rule package after the fact (this allows the separation of technical and non-technical aspects of the rules if needed).

To get started, a sample spreadsheet can be used as a base.
Alternatively, if the plug-in is being used (Rule Workbench IDE), the wizard can generate a spreadsheet from a template (to edit it an xls compatible spreadsheet editor will need to be used).

Related to decision tables (but not necessarily requiring a spreadsheet) are "Rule Templates" (in the drools-templates module). These use any tabular data source as a source of rule data - populating a template to generate many rules.
This can allow both for more flexible spreadsheets, but also rules in existing databases for instance (at the cost of developing the template up front to generate the rules).

With Rule Templates the data is separated from the rule and there are no restrictions on which part of the rule is data-driven.
So whilst you can do everything you could do in decision tables you can also do the following:

As an example, a more classic decision table is shown, but without any hidden rows for the rule meta data (so the spreadsheet only contains the raw data to generate the rules).

See the ExampleCheese.xls in the examples download for the above spreadsheet.

If this was a regular decision table there would be hidden rows before row 1 and between rows 1 and 2 containing rule metadata.
With rule templates the data is completely separate from the rules.
This has two handy consequences - you can apply multiple rule templates to the same data and your data is not tied to your rules at all.
So what does the template look like?

Annotations to the preceding program listing:

The rule templates rely on MVEL to do substitution using the syntax @{token_name}. There is currently one built-in expression, @{row.rowNumber} which gives a unique number for each row of data and enables you to generate unique rule names.
For each row of data a rule will be generated with the values in the data substituted for the tokens in the template.

A rule template has to be included in a file with extension .drt and associated to the corresponding decision table when defining the kbase in the kmodule.xml file as in the following example

With the example data above the following rule file would be generated:

At this point the KieSession named "TemplatesKS" and containing the rules generated from the template can be simply created from the KieContainer and used as any other KieSession.

The EntryPoint provides the methods around inserting, updating and deleting facts.
The term "entry point" is related to the fact that we have multiple partitions in a Working Memory and you can choose which one you are inserting into.
The use of multiple entry points is more common in event processing use cases, but they can be used by pure rule applications as well.

The KieRuntime interface provides the main interaction with the engine.
It is available in rule consequences and process actions.
In this manual the focus is on the methods and interfaces related to rules, and the methods pertaining to processes will be ignored for now.
But you’ll notice that the KieRuntime inherits methods from both the WorkingMemory and the ProcessRuntime, thereby providing a unified API to work with processes and rules.
When working with rules, three interfaces form the KieRuntime: EntryPoint, WorkingMemory and the KieRuntime itself.

The RuleRuntime provides access to the Agenda, permits query executions, and lets you access named Entry Points.

The StatefulRuleSession is inherited by the KieSession and provides the rule related methods that are relevant from outside of the engine.