|
|
@@ -0,0 +1,142 @@
|
|
|
+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.
|
|
|
+
|
