kie-rules-processes

Kie API Showcase

A bunch of examples of using the Kie API to create an embedded rule or process engine and either evaluate rules or run various processes.

By package:

rules

• SimpleMatch

  • Knowledge Base: simple
  • Package(s): simple
  • Description: A couple of simple examples of rule matching.

• FactIntegritySingle, FactIntegrityMultiple

  • Knowledge Base: integrity
  • Package(s): integrity
  • Description: Shows how referential integrity must be used when working with multiple unrelated sets of facts.

• AssertAndQueryFacts

  • Knowledge Base: awards
  • Package(s): facts
  • Description: Shows how Drools queries can be used to retrieve facts that may not have existed prior to firing the rules.

• AgendaGroupsWrongOrderLog, AgendaGroupsRightOrderLog

  • Knowledge Base: agendaWrong, agendaRight
  • Package(s): agenda.wrong, agenda.right
  • Description: Shows how using agenda groups can be used to stage rule evaluation. A nice example of an unsolvable infinite firing loop. Additionally, shows how global variables can be used to pass service objects, such as loggers, to your rule engine (and how to use them in rule consequences).

processes

• ProcessWithFacts

  • Knowledge Base: ruleflow
  • Package(s): ruleflow
  • Process(es): ruleflow.RulesRulesRules
  • Description: Inserts facts into working memory and starts a process without parameters. Shows that the facts are not visible to process tasks.

• ProcessWithParams

  • Knowledge Base: ruleflow
  • Package(s): ruleflow
  • Process(es): ruleflow.RulesRulesRules
  • Description: Starts a process with parameters instead of inserting facts. Check the Business Rule Tasks' I/O Parameter settings to see how to present those parameters to the rule engine. One shortcoming here is that rules insert awards into working memory, so they still need to be retrieved using a query.

• ProcessWithParamsOnly

  • Knowledge Base: ruleflowParams
  • Package(s): ruleflow_params
  • Process(es): ruleflow.RulesRulesRules (different package!)
  • Description: This time around, no facts are created by the rules, consequently the query comes up empty-handed. However, relationship between Customer and Award is established prior to starting the process, which allows us to write rules that modify existing facts, and simplifies our integration code - thanks to pass-by-reference, any modifications to Award are visible in the main() method after returning.

• ProcessWithListParams

  • Knowledge Base: ruleflowParams
  • Package(s): ruleflow_params
  • Process(es): ruleflow.RulesWithListParams
  • Description: Just here to show that wrapped parameters (such as a List<Customer>) do not match the rules. Facts must be presented individually for the matching patterns to be able to see them. The process was just modified to change parameter types and adjust I/O mappings for BR tasks. No other logic changes.

• ProcessWithListSubProcess

  • Knowledge Base: ruleflowParams
  • Package(s): ruleflow_params
  • Process(es): ruleflow.RulesWithListSubProc
  • Description: A working, albeit ugly, way of handling list parameters in processes. To present individual data objects to the working memory, two parallel multi-instance subprocesses had to be created, each with its own List as the driver. The sub-processes then iterate over the lists, and a single script task in each of the two is used to insert the facts into the working memory. Since there is the possibility that multiple customers have been passed in for processing, the congratulations task must also iterate over the list of awards and decide whom to congratulate based on each award's state. Uses the kcontext implicit global variable in script tasks, and is hence non-portable.

use_rest

All of the classes in this package use the serviceTasks knowledge base, which only makes the service_tasks Kie package available to the engines.

• UseSimpleJavaBeanService

  • Process: servicetasks.JavaBeanServiceTask
  • Implementation: beans.GenerateCustomer
  • Description: Showcase a plain Java bean being used as a service task. No REST whatsoever.

• UseRestEasyManualClient

  • Process: servicetasks.JavaRestClientServiceTask
  • Implementation: ws_client.CustomerServiceClient
  • Description: Uses a manual implementation of a REST client using RestEasy Request/Response approach. Note how the service task does not change, in principle, it is the implementation that makes the difference.

• UseRestEasyProxyClient

  • Process: servicetasks.JavaRestProxyServiceTask
  • Implementation: ws_client.CustomerServiceProxy
  • Description: Just a switch from manual implementation to a proxy-based REST client, using the interface from the shared-data-model project. Much easier and safer.

• UseRestServiceTask

  • Process: servicetasks.BpmnRestTask
  • Implementation: internal
  • Description: Uses a custom WorkItemHandler to register an internal REST client which is then configured in a custom task in the process model itself. Remember how we had to manually modify the BPMN2 model to add a taskName="Rest" attribute as the CodeReady tooling does not have a definition of a REST custom task, and regularly chokes on it, or else, without the taskName attribute, the engine complains that the custom task has no type and dies.

top-level package

Just contains a single class, UseRemoteKieArtifact, which loads a RHPAM project with GAV coordinates of net.p0f.samples.rhpam-fuse-integration:pam-simple-process:1.0.0-SNAPSHOT using a remote KieContainer, and then just for the sake of the example, also creates a KieScanner which has the ability to reload that container and update it to latest version in order for new sessions to be able to use the updated artifacts.