diff --git a/README.md b/README.md index 433596f..a334e8c 100644 --- a/README.md +++ b/README.md @@ -1,2 +1,6 @@ # publishing-tutorial-sample-repo -A sample repo to be used in conjunction with the tutorial "Getting started publishing with Pantheon 2" +A sample repo to be used in conjunction with the tutorial "Getting started publishing with Pantheon 2" + +This repo is a copy of the [Example modular documentation repository (Kogito)](https://github.com/redhat-documentation/modular-docs/tree/mod-doc-repo-example). + +For more information, including an explanation of the directories and the directory structure of this repo, see the README file for that repo. diff --git a/_artifacts/author-group.adoc b/_artifacts/author-group.adoc new file mode 100644 index 0000000..0e0ab8e --- /dev/null +++ b/_artifacts/author-group.adoc @@ -0,0 +1,8 @@ +//:sectnums!: +ifndef::DOCU_NAME[] +[appendix] +[id='author-group'] += Contact information + +{CONTACT} +endif::DOCU_NAME[] diff --git a/_artifacts/document-attributes-kogito-comm.adoc b/_artifacts/document-attributes-kogito-comm.adoc new file mode 100644 index 0000000..fe2f0ee --- /dev/null +++ b/_artifacts/document-attributes-kogito-comm.adoc @@ -0,0 +1,12 @@ +// Do NOT delete repeated or superfluous variables unless the same can be deleted from all other attributes docs (for DM, PAM, jBPM, etc.). All attributes here are in use in product docs at this time, and as we single source, we need those same variables to render appropriately for Drools. But do please correct and add info where necessary. (Stetson, 2 Aug 2018) + +:PRODUCT: Kogito +:PRODUCT_SHORT: Kogito +:PRODUCT_INIT: kogito +:PRODUCT_INIT_CAP: KOGITO +:PRODUCT_INIT_BA: kogito +:PRODUCT_INIT_CAP_BA: KOGITO +:URL_COMPONENT_PRODUCT: kogito + +:OPENSHIFT: OpenShift +:URL_COMPONENT_OPENSHIFT: openshift diff --git a/_artifacts/document-attributes-kogito-ent.adoc b/_artifacts/document-attributes-kogito-ent.adoc new file mode 100644 index 0000000..3fcad04 --- /dev/null +++ b/_artifacts/document-attributes-kogito-ent.adoc @@ -0,0 +1,14 @@ +// Do NOT delete repeated or superfluous variables unless the same can be deleted from all other attributes docs (for DM, PAM, jBPM, etc.). All attributes here are in use in product docs at this time, and as we single source, we need those same variables to render appropriately for Drools. But do please correct and add info where necessary. (Stetson, 2 Aug 2018) + +:PRODUCT: Kogito +:PRODUCT_SHORT: Kogito +:PRODUCT_INIT: kogito +:PRODUCT_INIT_CAP: KOGITO +:PRODUCT_INIT_BA: kogito +:PRODUCT_INIT_CAP_BA: KOGITO +:URL_COMPONENT_PRODUCT: kogito + +:OPENSHIFT: Red Hat OpenShift Container Platform +:URL_COMPONENT_OPENSHIFT: red_hat_openshift_container_platform + +:CONTACT: {PRODUCT} documentation team: brms-docs@redhat.com diff --git a/_artifacts/document-attributes.adoc b/_artifacts/document-attributes.adoc new file mode 100644 index 0000000..5ad3492 --- /dev/null +++ b/_artifacts/document-attributes.adoc @@ -0,0 +1,102 @@ + +:REBUILT: Tuesday, April 21, 2020 + +:COMMUNITY_VERSION: 0.9 +:ENTERPRISE_VERSION: {COMMUNITY_VERSION} +:ENTERPRISE_VERSION_LONG: {COMMUNITY_VERSION}.1 +:COMMUNITY_VERSION_LONG: {COMMUNITY_VERSION}.1 +:COMMUNITY_VERSION_FINAL: {COMMUNITY_VERSION_LONG}.Final +:COMMUNITY_VERSION_BRANCH: 0.9.x + +:PRODUCT_FILE: {PRODUCT_INIT}-{ENTERPRISE_VERSION_LONG} +:PRODUCT_FILE_BA: {PRODUCT_INIT_BA}-{ENTERPRISE_VERSION_LONG} + +// For copyright +:YEAR: 2020 + +// Maven info, from https://mvnrepository.com (public repo) or https://repository.jboss.org/nexus/index.html#welcome (Nexus repo) +ifdef::KOGITO-ENT[] +:MAVEN_ARTIFACT_VERSION: {COMMUNITY_VERSION_FINAL}-redhat-00002 +:BOM_VERSION: {ENTERPRISE_VERSION_LONG}.redhat-00002 +endif::[] +ifdef::KOGITO-COMM[] +:MAVEN_ARTIFACT_VERSION: {COMMUNITY_VERSION_FINAL} +:BOM_VERSION: {COMMUNITY_VERSION_FINAL} +endif::[] + +//// +IMPORTANT: The `{BOM_VERSION}` variable requires additional conditioning in single-sourced content, as shown in this example: + +.Example BOM declaration in single-sourced content +[source,xml,subs="attributes+"] +---- +ifdef::KOGITO-ENT[] + com.redhat.ba + ba-platform-bom +endif::[] +ifdef::KOGITO-COMM[] + org.kie + kie-platform-bom +endif::[] + {BOM_VERSION} +---- +//// + +ifdef::KOGITO-ENT[] +include::document-attributes-kogito-ent.adoc[] +endif::KOGITO-ENT[] + +ifdef::KOGITO-COMM[] +include::document-attributes-kogito-comm.adoc[] +endif::KOGITO-COMM[] + +//// +//For source includes +:kogito-dir: kogito-docs/src/main/asciidoc +//// + +// Product and component names +:PRODUCT_PAM: Red Hat Process Automation Manager +:PRODUCT_DM: Red Hat Decision Manager +:PRODUCT_BO: Red Hat Business Optimizer +:PRODUCT_BA: Red Hat Business Automation +:PRODUCT_DROOLS: Drools +:PRODUCT_JBPM: jBPM +:PRODUCT_OP: OptaPlanner + +:DECISION_ENGINE: decision engine +:DECISION_ENGINE_CAP: Decision engine +:PROCESS_ENGINE: process engine +:PROCESS_ENGINE_CAP: process engine +:PLANNING_ENGINE: planning engine +:PLANNING_ENGINE_CAP: Planning engine +:URL_COMPONENT_DECISION_ENGINE: decision-engine +:URL_COMPONENT_PROCESS_ENGINE: process-engine +:URL_COMPONENT_PLANNING_ENGINE: planner-engine + +// Assembly names (some of these will likely be moved product-specific attrs docs in the future, i.e., document-attributes-dm.adoc and ..-ba.adoc) + +:RELEASE_NOTES: Release notes for {PRODUCT} {ENTERPRISE_VERSION} +:CREATING_RUNNING: Creating and running your first {PRODUCT} services +:DEPLOYING_ON_OPENSHIFT: Deploying {PRODUCT} services on {OPENSHIFT} +:DECISION_SERVICES: Developing decision services with {PRODUCT} +:PROCESS_SERVICES: Developing process services with {PRODUCT} +:CONFIGURING_KOGITO: Configuring {PRODUCT} supporting services and runtime capabilities + +// URL components, for post Dev Preview +:URL_COMPONENT_FORMAT: html-single +:URL_BASE_ENTERPRISE: https://access.redhat.com/documentation/en-us/{URL_COMPONENT_PRODUCT}/{ENTERPRISE_VERSION}/{URL_COMPONENT_FORMAT} +:URL_BASE_BPMSUITE: https://access.redhat.com/documentation/en-us/red-hat-jboss-bpm-suite/{ENTERPRISE_VERSION}/{URL_COMPONENT_FORMAT} +:URL_BASE_GITHUB_DM: https://github.com/jboss-container-images/rhdm-7-openshift-image/tree/rhdm70-dev +:URL_BASE_GITHUB_PAM: https://github.com/jboss-container-images/rhpam-7-openshift-image/tree/rhpam70-dev + +// URLs for assemblies (some of these will likely be moved product-specific attrs docs in the future, i.e., document-attributes-dm.adoc and ..-ba.adoc) + +:URL_RELEASE_NOTES: {URL_BASE_ENTERPRISE}/release_notes_for_{PRODUCT_INIT}_{ENTERPRISE_VERSION} +:URL_CREATING_RUNNING: {URL_BASE_ENTERPRISE}/creating_and_running_your_first_{PRODUCT_INIT}_services +:URL_DEPLOYING_ON_OPENSHIFT: {URL_BASE_ENTERPRISE}/deploying_{PRODUCT_INIT}_services_on_{URL_COMPONENT_OPENSHIFT} +:URL_DECISION_SERVICES: {URL_BASE_ENTERPRISE}/developing_decision_services_with_{PRODUCT_INIT} +:URL_PROCESS_SERVICES: {URL_BASE_ENTERPRISE}/developing_process_services_with_{PRODUCT_INIT} +:URL_CONFIGURING_KOGITO: {URL_BASE_ENTERPRISE}/configuring_{PRODUCT_INIT}_supporting_services_and_runtime_capabilities + +:ndash: – diff --git a/_artifacts/legal-notice.adoc b/_artifacts/legal-notice.adoc new file mode 100644 index 0000000..f3df1a9 --- /dev/null +++ b/_artifacts/legal-notice.adoc @@ -0,0 +1,29 @@ +== Legal Notice + +Copyright (C) {YEAR} Red Hat, Inc. + +This document is licensed by Red Hat under the http://creativecommons.org/licenses/by-sa/3.0/[Creative Commons Attribution-ShareAlike 3.0 Unported License]. +If you distribute this document, or a modified version of it, you must provide attribution to Red Hat, Inc. +and provide a link to the original. +If the document is modified, all Red Hat trademarks must be removed. + +Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. + +Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity Logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries. + +Linux(R) is the registered trademark of Linus Torvalds in the United States and other countries. + +Java(R) is a registered trademark of Oracle and/or its affiliates. + +XFS(R) is a trademark of Silicon Graphics International Corp. +or its subsidiaries in the United States and/or other countries. + +MySQL(R) is a registered trademark of MySQL AB in the United States, the European Union and other countries. + +Node.js(R) is an official trademark of Joyent. +Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project. + +The OpenStack(R) Word Mark and OpenStack Logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. +We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community. + +All other trademarks are the property of their respective owners. diff --git a/_artifacts/versioning-information-bigbuild.adoc b/_artifacts/versioning-information-bigbuild.adoc new file mode 100644 index 0000000..235a63c --- /dev/null +++ b/_artifacts/versioning-information-bigbuild.adoc @@ -0,0 +1,7 @@ +//:sectnums!: + +[appendix] +[id='versioning-information-bigbuild'] += Versioning information + +Documentation set last updated on {REBUILT}. diff --git a/_artifacts/versioning-information.adoc b/_artifacts/versioning-information.adoc new file mode 100644 index 0000000..a815a77 --- /dev/null +++ b/_artifacts/versioning-information.adoc @@ -0,0 +1,8 @@ +//:sectnums!: +ifndef::DOCU_NAME[] +[appendix] +[id='versioning-information'] += Versioning information + +Documentation last updated on {REBUILT}. +endif::DOCU_NAME[] diff --git a/_artifacts/xpaas_maven_mirror_url.adoc b/_artifacts/xpaas_maven_mirror_url.adoc new file mode 100644 index 0000000..3a5c2bc --- /dev/null +++ b/_artifacts/xpaas_maven_mirror_url.adoc @@ -0,0 +1,54 @@ +// This page describes MAVEN_MIRROR_URL variable usage +// It requires 'bcname' attribute to be set to the name of the product + +A repository in Maven holds build artifacts and dependencies of various types +(all the project jars, library jar, plugins or any other project specific +artifacts). It also specifies locations from where to download artifacts from, +while performing the S2I build. Besides using central repositories, it is a +common practice for organizations to deploy a local custom repository (mirror). + +Benefits of using a mirror are: + +* Availability of a synchronized mirror, which is geographically closer and + faster. +* Ability to have greater control over the repository content. +* Possibility to share artifacts across different teams (developers, CI), + without the need to rely on public servers and repositories. +* Improved build times. + +Often, a repository manager can serve as local cache to a mirror. Assuming that +the repository manager is already deployed and reachable externally at +*_pass:[http://10.0.0.1:8080/repository/internal/]_*, the S2I build can then use this +manager by supplying the `MAVEN_MIRROR_URL` environment variable to the +build configuration of the application as follows: + +. Identify the name of the build configuration to apply `MAVEN_MIRROR_URL` + variable against: ++ +[subs="attributes"] +---- +oc get bc -o name +buildconfig/{bcname} +---- +. Update build configuration of `{bcname}` with a `MAVEN_MIRROR_URL` environment variable ++ +[subs="attributes"] +---- +oc env bc/{bcname} MAVEN_MIRROR_URL="http://10.0.0.1:8080/repository/internal/" +buildconfig "{bcname}" updated +---- +. Verify the setting ++ +[subs="attributes"] +---- +oc env bc/{bcname} --list +# buildconfigs {bcname} +MAVEN_MIRROR_URL=http://10.0.0.1:8080/repository/internal/ +---- +. Schedule new build of the application + +NOTE: During application build, you will notice that Maven dependencies are +pulled from the repository manager, instead of the default public repositories. +Also, after the build is finished, you will see that the mirror is filled with +all the dependencies that were retrieved and used during the build. + diff --git a/_images/kogito/bpmn/BusinessRuleTask.png b/_images/kogito/bpmn/BusinessRuleTask.png new file mode 100644 index 0000000..91fb4f0 Binary files /dev/null and b/_images/kogito/bpmn/BusinessRuleTask.png differ diff --git a/_images/kogito/bpmn/ConvergingGateway.png b/_images/kogito/bpmn/ConvergingGateway.png new file mode 100644 index 0000000..93fbc65 Binary files /dev/null and b/_images/kogito/bpmn/ConvergingGateway.png differ diff --git a/_images/kogito/bpmn/DivergingGateway.png b/_images/kogito/bpmn/DivergingGateway.png new file mode 100644 index 0000000..04882a5 Binary files /dev/null and b/_images/kogito/bpmn/DivergingGateway.png differ diff --git a/_images/kogito/bpmn/EmbeddedSubProcess.png b/_images/kogito/bpmn/EmbeddedSubProcess.png new file mode 100644 index 0000000..272cb51 Binary files /dev/null and b/_images/kogito/bpmn/EmbeddedSubProcess.png differ diff --git a/_images/kogito/bpmn/EndEvent.png b/_images/kogito/bpmn/EndEvent.png new file mode 100644 index 0000000..00d9d37 Binary files /dev/null and b/_images/kogito/bpmn/EndEvent.png differ diff --git a/_images/kogito/bpmn/ErrorEndEvent.png b/_images/kogito/bpmn/ErrorEndEvent.png new file mode 100644 index 0000000..93a640f Binary files /dev/null and b/_images/kogito/bpmn/ErrorEndEvent.png differ diff --git a/_images/kogito/bpmn/bk_x.png b/_images/kogito/bpmn/bk_x.png new file mode 100644 index 0000000..086c253 Binary files /dev/null and b/_images/kogito/bpmn/bk_x.png differ diff --git a/_images/kogito/bpmn/bk_x.xcf b/_images/kogito/bpmn/bk_x.xcf new file mode 100644 index 0000000..87911b4 Binary files /dev/null and b/_images/kogito/bpmn/bk_x.xcf differ diff --git a/_images/kogito/bpmn/bpm-throwing-escalation.png b/_images/kogito/bpmn/bpm-throwing-escalation.png new file mode 100644 index 0000000..2dba1d0 Binary files /dev/null and b/_images/kogito/bpmn/bpm-throwing-escalation.png differ diff --git a/_images/kogito/bpmn/bpmn-business-rule-task.png b/_images/kogito/bpmn/bpmn-business-rule-task.png new file mode 100644 index 0000000..c8e808e Binary files /dev/null and b/_images/kogito/bpmn/bpmn-business-rule-task.png differ diff --git a/_images/kogito/bpmn/bpmn-businessrule-task.png b/_images/kogito/bpmn/bpmn-businessrule-task.png new file mode 100644 index 0000000..8150f6e Binary files /dev/null and b/_images/kogito/bpmn/bpmn-businessrule-task.png differ diff --git a/_images/kogito/bpmn/bpmn-compensation-start.png b/_images/kogito/bpmn/bpmn-compensation-start.png new file mode 100644 index 0000000..e184d5b Binary files /dev/null and b/_images/kogito/bpmn/bpmn-compensation-start.png differ diff --git a/_images/kogito/bpmn/bpmn-conditional-non-interrupt.png b/_images/kogito/bpmn/bpmn-conditional-non-interrupt.png new file mode 100644 index 0000000..5eb9564 Binary files /dev/null and b/_images/kogito/bpmn/bpmn-conditional-non-interrupt.png differ diff --git a/_images/kogito/bpmn/bpmn-conditional-noninterrupt.png b/_images/kogito/bpmn/bpmn-conditional-noninterrupt.png new file mode 100644 index 0000000..d1b66db Binary files /dev/null and b/_images/kogito/bpmn/bpmn-conditional-noninterrupt.png differ diff --git a/_images/kogito/bpmn/bpmn-conditional-start.png b/_images/kogito/bpmn/bpmn-conditional-start.png new file mode 100644 index 0000000..440f535 Binary files /dev/null and b/_images/kogito/bpmn/bpmn-conditional-start.png differ diff --git a/_images/kogito/bpmn/bpmn-decision-task.png b/_images/kogito/bpmn/bpmn-decision-task.png new file mode 100644 index 0000000..1daa4c5 Binary files /dev/null and b/_images/kogito/bpmn/bpmn-decision-task.png differ diff --git a/_images/kogito/bpmn/bpmn-drag-nodes.png b/_images/kogito/bpmn/bpmn-drag-nodes.png new file mode 100644 index 0000000..7f18c31 Binary files /dev/null and b/_images/kogito/bpmn/bpmn-drag-nodes.png differ diff --git a/_images/kogito/bpmn/bpmn-email-task.png b/_images/kogito/bpmn/bpmn-email-task.png new file mode 100644 index 0000000..f3d540a Binary files /dev/null and b/_images/kogito/bpmn/bpmn-email-task.png differ diff --git a/_images/kogito/bpmn/bpmn-end-compensation.png b/_images/kogito/bpmn/bpmn-end-compensation.png new file mode 100644 index 0000000..8286db4 Binary files /dev/null and b/_images/kogito/bpmn/bpmn-end-compensation.png differ diff --git a/_images/kogito/bpmn/bpmn-end-error.png b/_images/kogito/bpmn/bpmn-end-error.png new file mode 100644 index 0000000..d0e7cf0 Binary files /dev/null and b/_images/kogito/bpmn/bpmn-end-error.png differ diff --git a/_images/kogito/bpmn/bpmn-end-escalation.png b/_images/kogito/bpmn/bpmn-end-escalation.png new file mode 100644 index 0000000..18dd1e9 Binary files /dev/null and b/_images/kogito/bpmn/bpmn-end-escalation.png differ diff --git a/_images/kogito/bpmn/bpmn-end-message.png b/_images/kogito/bpmn/bpmn-end-message.png new file mode 100644 index 0000000..f971fe3 Binary files /dev/null and b/_images/kogito/bpmn/bpmn-end-message.png differ diff --git a/_images/kogito/bpmn/bpmn-end-node.png b/_images/kogito/bpmn/bpmn-end-node.png new file mode 100644 index 0000000..ceff2a4 Binary files /dev/null and b/_images/kogito/bpmn/bpmn-end-node.png differ diff --git a/_images/kogito/bpmn/bpmn-end-signal.png b/_images/kogito/bpmn/bpmn-end-signal.png new file mode 100644 index 0000000..fb2d701 Binary files /dev/null and b/_images/kogito/bpmn/bpmn-end-signal.png differ diff --git a/_images/kogito/bpmn/bpmn-end-terminate.png b/_images/kogito/bpmn/bpmn-end-terminate.png new file mode 100644 index 0000000..025eb85 Binary files /dev/null and b/_images/kogito/bpmn/bpmn-end-terminate.png differ diff --git a/_images/kogito/bpmn/bpmn-error-start.png b/_images/kogito/bpmn/bpmn-error-start.png new file mode 100644 index 0000000..43188b9 Binary files /dev/null and b/_images/kogito/bpmn/bpmn-error-start.png differ diff --git a/_images/kogito/bpmn/bpmn-escalation-non-interrupt.png b/_images/kogito/bpmn/bpmn-escalation-non-interrupt.png new file mode 100644 index 0000000..6227feb Binary files /dev/null and b/_images/kogito/bpmn/bpmn-escalation-non-interrupt.png differ diff --git a/_images/kogito/bpmn/bpmn-escalation-start.png b/_images/kogito/bpmn/bpmn-escalation-start.png new file mode 100644 index 0000000..f1967b8 Binary files /dev/null and b/_images/kogito/bpmn/bpmn-escalation-start.png differ diff --git a/_images/kogito/bpmn/bpmn-gateway-event.png b/_images/kogito/bpmn/bpmn-gateway-event.png new file mode 100644 index 0000000..e0c9fd6 Binary files /dev/null and b/_images/kogito/bpmn/bpmn-gateway-event.png differ diff --git a/_images/kogito/bpmn/bpmn-gateway-exclusive.png b/_images/kogito/bpmn/bpmn-gateway-exclusive.png new file mode 100644 index 0000000..75bc7db Binary files /dev/null and b/_images/kogito/bpmn/bpmn-gateway-exclusive.png differ diff --git a/_images/kogito/bpmn/bpmn-gateway-inclusive.png b/_images/kogito/bpmn/bpmn-gateway-inclusive.png new file mode 100644 index 0000000..d853b70 Binary files /dev/null and b/_images/kogito/bpmn/bpmn-gateway-inclusive.png differ diff --git a/_images/kogito/bpmn/bpmn-gateway-parallel.png b/_images/kogito/bpmn/bpmn-gateway-parallel.png new file mode 100644 index 0000000..c7717eb Binary files /dev/null and b/_images/kogito/bpmn/bpmn-gateway-parallel.png differ diff --git a/_images/kogito/bpmn/bpmn-gateway.png b/_images/kogito/bpmn/bpmn-gateway.png new file mode 100644 index 0000000..53143df Binary files /dev/null and b/_images/kogito/bpmn/bpmn-gateway.png differ diff --git a/_images/kogito/bpmn/bpmn-global-variables.png b/_images/kogito/bpmn/bpmn-global-variables.png new file mode 100644 index 0000000..1b1934f Binary files /dev/null and b/_images/kogito/bpmn/bpmn-global-variables.png differ diff --git a/_images/kogito/bpmn/bpmn-intermediate-catch.png b/_images/kogito/bpmn/bpmn-intermediate-catch.png new file mode 100644 index 0000000..27ea1df Binary files /dev/null and b/_images/kogito/bpmn/bpmn-intermediate-catch.png differ diff --git a/_images/kogito/bpmn/bpmn-intermediate-compensation-throwing.png b/_images/kogito/bpmn/bpmn-intermediate-compensation-throwing.png new file mode 100644 index 0000000..62c1c59 Binary files /dev/null and b/_images/kogito/bpmn/bpmn-intermediate-compensation-throwing.png differ diff --git a/_images/kogito/bpmn/bpmn-intermediate-compensation.png b/_images/kogito/bpmn/bpmn-intermediate-compensation.png new file mode 100644 index 0000000..4a186bf Binary files /dev/null and b/_images/kogito/bpmn/bpmn-intermediate-compensation.png differ diff --git a/_images/kogito/bpmn/bpmn-intermediate-compensation.xcf b/_images/kogito/bpmn/bpmn-intermediate-compensation.xcf new file mode 100644 index 0000000..537af2c Binary files /dev/null and b/_images/kogito/bpmn/bpmn-intermediate-compensation.xcf differ diff --git a/_images/kogito/bpmn/bpmn-intermediate-conditional.png b/_images/kogito/bpmn/bpmn-intermediate-conditional.png new file mode 100644 index 0000000..5583cf9 Binary files /dev/null and b/_images/kogito/bpmn/bpmn-intermediate-conditional.png differ diff --git a/_images/kogito/bpmn/bpmn-intermediate-error.png b/_images/kogito/bpmn/bpmn-intermediate-error.png new file mode 100644 index 0000000..a2b67d7 Binary files /dev/null and b/_images/kogito/bpmn/bpmn-intermediate-error.png differ diff --git a/_images/kogito/bpmn/bpmn-intermediate-escalation-non-interrupting.png b/_images/kogito/bpmn/bpmn-intermediate-escalation-non-interrupting.png new file mode 100644 index 0000000..95fd54d Binary files /dev/null and b/_images/kogito/bpmn/bpmn-intermediate-escalation-non-interrupting.png differ diff --git a/_images/kogito/bpmn/bpmn-intermediate-escalation-throwing.png b/_images/kogito/bpmn/bpmn-intermediate-escalation-throwing.png new file mode 100644 index 0000000..507eeb2 Binary files /dev/null and b/_images/kogito/bpmn/bpmn-intermediate-escalation-throwing.png differ diff --git a/_images/kogito/bpmn/bpmn-intermediate-escalation.png b/_images/kogito/bpmn/bpmn-intermediate-escalation.png new file mode 100644 index 0000000..b2fbc33 Binary files /dev/null and b/_images/kogito/bpmn/bpmn-intermediate-escalation.png differ diff --git a/_images/kogito/bpmn/bpmn-intermediate-message.png b/_images/kogito/bpmn/bpmn-intermediate-message.png new file mode 100644 index 0000000..f49c224 Binary files /dev/null and b/_images/kogito/bpmn/bpmn-intermediate-message.png differ diff --git a/_images/kogito/bpmn/bpmn-intermediate-signal.png b/_images/kogito/bpmn/bpmn-intermediate-signal.png new file mode 100644 index 0000000..ca94097 Binary files /dev/null and b/_images/kogito/bpmn/bpmn-intermediate-signal.png differ diff --git a/_images/kogito/bpmn/bpmn-intermediate-timer.png b/_images/kogito/bpmn/bpmn-intermediate-timer.png new file mode 100644 index 0000000..2c23ecd Binary files /dev/null and b/_images/kogito/bpmn/bpmn-intermediate-timer.png differ diff --git a/_images/kogito/bpmn/bpmn-lane.png b/_images/kogito/bpmn/bpmn-lane.png new file mode 100644 index 0000000..3c36f56 Binary files /dev/null and b/_images/kogito/bpmn/bpmn-lane.png differ diff --git a/_images/kogito/bpmn/bpmn-lanes.png b/_images/kogito/bpmn/bpmn-lanes.png new file mode 100644 index 0000000..869105f Binary files /dev/null and b/_images/kogito/bpmn/bpmn-lanes.png differ diff --git a/_images/kogito/bpmn/bpmn-local-variables.png b/_images/kogito/bpmn/bpmn-local-variables.png new file mode 100644 index 0000000..9752bf3 Binary files /dev/null and b/_images/kogito/bpmn/bpmn-local-variables.png differ diff --git a/_images/kogito/bpmn/bpmn-log-task.png b/_images/kogito/bpmn/bpmn-log-task.png new file mode 100644 index 0000000..5cfd546 Binary files /dev/null and b/_images/kogito/bpmn/bpmn-log-task.png differ diff --git a/_images/kogito/bpmn/bpmn-message-node.png b/_images/kogito/bpmn/bpmn-message-node.png new file mode 100644 index 0000000..6d981ec Binary files /dev/null and b/_images/kogito/bpmn/bpmn-message-node.png differ diff --git a/_images/kogito/bpmn/bpmn-message-non-interrupt.png b/_images/kogito/bpmn/bpmn-message-non-interrupt.png new file mode 100644 index 0000000..f33c269 Binary files /dev/null and b/_images/kogito/bpmn/bpmn-message-non-interrupt.png differ diff --git a/_images/kogito/bpmn/bpmn-message-noninterrupt.png b/_images/kogito/bpmn/bpmn-message-noninterrupt.png new file mode 100644 index 0000000..d17093c Binary files /dev/null and b/_images/kogito/bpmn/bpmn-message-noninterrupt.png differ diff --git a/_images/kogito/bpmn/bpmn-message-throwing.png b/_images/kogito/bpmn/bpmn-message-throwing.png new file mode 100644 index 0000000..9b2fb24 Binary files /dev/null and b/_images/kogito/bpmn/bpmn-message-throwing.png differ diff --git a/_images/kogito/bpmn/bpmn-messaging-end-event.png b/_images/kogito/bpmn/bpmn-messaging-end-event.png new file mode 100644 index 0000000..218a070 Binary files /dev/null and b/_images/kogito/bpmn/bpmn-messaging-end-event.png differ diff --git a/_images/kogito/bpmn/bpmn-messaging-example.png b/_images/kogito/bpmn/bpmn-messaging-example.png new file mode 100644 index 0000000..0f666fa Binary files /dev/null and b/_images/kogito/bpmn/bpmn-messaging-example.png differ diff --git a/_images/kogito/bpmn/bpmn-messaging-start-event.png b/_images/kogito/bpmn/bpmn-messaging-start-event.png new file mode 100644 index 0000000..c469874 Binary files /dev/null and b/_images/kogito/bpmn/bpmn-messaging-start-event.png differ diff --git a/_images/kogito/bpmn/bpmn-model-example-evaluation.png b/_images/kogito/bpmn/bpmn-model-example-evaluation.png new file mode 100644 index 0000000..b89b82a Binary files /dev/null and b/_images/kogito/bpmn/bpmn-model-example-evaluation.png differ diff --git a/_images/kogito/bpmn/bpmn-model-example-mortgage-application.png b/_images/kogito/bpmn/bpmn-model-example-mortgage-application.png new file mode 100644 index 0000000..99f4d7f Binary files /dev/null and b/_images/kogito/bpmn/bpmn-model-example-mortgage-application.png differ diff --git a/_images/kogito/bpmn/bpmn-model-example-order-items.png b/_images/kogito/bpmn/bpmn-model-example-order-items.png new file mode 100644 index 0000000..51c11c1 Binary files /dev/null and b/_images/kogito/bpmn/bpmn-model-example-order-items.png differ diff --git a/_images/kogito/bpmn/bpmn-model-example-orders.png b/_images/kogito/bpmn/bpmn-model-example-orders.png new file mode 100644 index 0000000..70de51e Binary files /dev/null and b/_images/kogito/bpmn/bpmn-model-example-orders.png differ diff --git a/_images/kogito/bpmn/bpmn-none-task.png b/_images/kogito/bpmn/bpmn-none-task.png new file mode 100644 index 0000000..1fe6089 Binary files /dev/null and b/_images/kogito/bpmn/bpmn-none-task.png differ diff --git a/_images/kogito/bpmn/bpmn-process-variables.png b/_images/kogito/bpmn/bpmn-process-variables.png new file mode 100644 index 0000000..d5d26f1 Binary files /dev/null and b/_images/kogito/bpmn/bpmn-process-variables.png differ diff --git a/_images/kogito/bpmn/bpmn-rest-task.png b/_images/kogito/bpmn/bpmn-rest-task.png new file mode 100644 index 0000000..6ffc564 Binary files /dev/null and b/_images/kogito/bpmn/bpmn-rest-task.png differ diff --git a/_images/kogito/bpmn/bpmn-script-task.png b/_images/kogito/bpmn/bpmn-script-task.png new file mode 100644 index 0000000..0a88a31 Binary files /dev/null and b/_images/kogito/bpmn/bpmn-script-task.png differ diff --git a/_images/kogito/bpmn/bpmn-service-task.png b/_images/kogito/bpmn/bpmn-service-task.png new file mode 100644 index 0000000..92874df Binary files /dev/null and b/_images/kogito/bpmn/bpmn-service-task.png differ diff --git a/_images/kogito/bpmn/bpmn-service-tasks-button.png b/_images/kogito/bpmn/bpmn-service-tasks-button.png new file mode 100644 index 0000000..dd965cf Binary files /dev/null and b/_images/kogito/bpmn/bpmn-service-tasks-button.png differ diff --git a/_images/kogito/bpmn/bpmn-service-tasks-designer.png b/_images/kogito/bpmn/bpmn-service-tasks-designer.png new file mode 100644 index 0000000..22154e1 Binary files /dev/null and b/_images/kogito/bpmn/bpmn-service-tasks-designer.png differ diff --git a/_images/kogito/bpmn/bpmn-signal-non-interrupt.png b/_images/kogito/bpmn/bpmn-signal-non-interrupt.png new file mode 100644 index 0000000..509b182 Binary files /dev/null and b/_images/kogito/bpmn/bpmn-signal-non-interrupt.png differ diff --git a/_images/kogito/bpmn/bpmn-signal-noninterrupt.png b/_images/kogito/bpmn/bpmn-signal-noninterrupt.png new file mode 100644 index 0000000..7288711 Binary files /dev/null and b/_images/kogito/bpmn/bpmn-signal-noninterrupt.png differ diff --git a/_images/kogito/bpmn/bpmn-signal-start.png b/_images/kogito/bpmn/bpmn-signal-start.png new file mode 100644 index 0000000..9abf6e5 Binary files /dev/null and b/_images/kogito/bpmn/bpmn-signal-start.png differ diff --git a/_images/kogito/bpmn/bpmn-signal-throwing.png b/_images/kogito/bpmn/bpmn-signal-throwing.png new file mode 100644 index 0000000..0e4da17 Binary files /dev/null and b/_images/kogito/bpmn/bpmn-signal-throwing.png differ diff --git a/_images/kogito/bpmn/bpmn-start-node.png b/_images/kogito/bpmn/bpmn-start-node.png new file mode 100644 index 0000000..949a628 Binary files /dev/null and b/_images/kogito/bpmn/bpmn-start-node.png differ diff --git a/_images/kogito/bpmn/bpmn-subprocesses.png b/_images/kogito/bpmn/bpmn-subprocesses.png new file mode 100644 index 0000000..a49a560 Binary files /dev/null and b/_images/kogito/bpmn/bpmn-subprocesses.png differ diff --git a/_images/kogito/bpmn/bpmn-swimlane.png b/_images/kogito/bpmn/bpmn-swimlane.png new file mode 100644 index 0000000..aff9947 Binary files /dev/null and b/_images/kogito/bpmn/bpmn-swimlane.png differ diff --git a/_images/kogito/bpmn/bpmn-swimlane2.png b/_images/kogito/bpmn/bpmn-swimlane2.png new file mode 100644 index 0000000..869105f Binary files /dev/null and b/_images/kogito/bpmn/bpmn-swimlane2.png differ diff --git a/_images/kogito/bpmn/bpmn-tasks-designer.png b/_images/kogito/bpmn/bpmn-tasks-designer.png new file mode 100644 index 0000000..fab3260 Binary files /dev/null and b/_images/kogito/bpmn/bpmn-tasks-designer.png differ diff --git a/_images/kogito/bpmn/bpmn-throwing-compensation.png b/_images/kogito/bpmn/bpmn-throwing-compensation.png new file mode 100644 index 0000000..af0ff9f Binary files /dev/null and b/_images/kogito/bpmn/bpmn-throwing-compensation.png differ diff --git a/_images/kogito/bpmn/bpmn-timer-non-interrupt.png b/_images/kogito/bpmn/bpmn-timer-non-interrupt.png new file mode 100644 index 0000000..ef482d5 Binary files /dev/null and b/_images/kogito/bpmn/bpmn-timer-non-interrupt.png differ diff --git a/_images/kogito/bpmn/bpmn-timer-noninterrupt.png b/_images/kogito/bpmn/bpmn-timer-noninterrupt.png new file mode 100644 index 0000000..ceef6c5 Binary files /dev/null and b/_images/kogito/bpmn/bpmn-timer-noninterrupt.png differ diff --git a/_images/kogito/bpmn/bpmn-timer-start.png b/_images/kogito/bpmn/bpmn-timer-start.png new file mode 100644 index 0000000..a4c1343 Binary files /dev/null and b/_images/kogito/bpmn/bpmn-timer-start.png differ diff --git a/_images/kogito/bpmn/bpmn-user-task.png b/_images/kogito/bpmn/bpmn-user-task.png new file mode 100644 index 0000000..617c63e Binary files /dev/null and b/_images/kogito/bpmn/bpmn-user-task.png differ diff --git a/_images/kogito/bpmn/bpmn-ws-task.png b/_images/kogito/bpmn/bpmn-ws-task.png new file mode 100644 index 0000000..b5968de Binary files /dev/null and b/_images/kogito/bpmn/bpmn-ws-task.png differ diff --git a/_images/kogito/bpmn/events.png b/_images/kogito/bpmn/events.png new file mode 100644 index 0000000..d30d3f0 Binary files /dev/null and b/_images/kogito/bpmn/events.png differ diff --git a/_images/kogito/bpmn/events1.png b/_images/kogito/bpmn/events1.png new file mode 100644 index 0000000..1aa350c Binary files /dev/null and b/_images/kogito/bpmn/events1.png differ diff --git a/_images/kogito/bpmn/gateway.png b/_images/kogito/bpmn/gateway.png new file mode 100644 index 0000000..4838563 Binary files /dev/null and b/_images/kogito/bpmn/gateway.png differ diff --git a/_images/kogito/bpmn/gear-icon.png b/_images/kogito/bpmn/gear-icon.png new file mode 100644 index 0000000..e647ac6 Binary files /dev/null and b/_images/kogito/bpmn/gear-icon.png differ diff --git a/_images/kogito/bpmn/grn_check.png b/_images/kogito/bpmn/grn_check.png new file mode 100644 index 0000000..e5b6533 Binary files /dev/null and b/_images/kogito/bpmn/grn_check.png differ diff --git a/_images/kogito/bpmn/grn_check.xcf b/_images/kogito/bpmn/grn_check.xcf new file mode 100644 index 0000000..dbe9a5a Binary files /dev/null and b/_images/kogito/bpmn/grn_check.xcf differ diff --git a/_images/kogito/bpmn/grn_cir.png b/_images/kogito/bpmn/grn_cir.png new file mode 100644 index 0000000..846a01d Binary files /dev/null and b/_images/kogito/bpmn/grn_cir.png differ diff --git a/_images/kogito/bpmn/grn_star.png b/_images/kogito/bpmn/grn_star.png new file mode 100644 index 0000000..8c38cda Binary files /dev/null and b/_images/kogito/bpmn/grn_star.png differ diff --git a/_images/kogito/bpmn/grn_star.xcf b/_images/kogito/bpmn/grn_star.xcf new file mode 100644 index 0000000..fd89484 Binary files /dev/null and b/_images/kogito/bpmn/grn_star.xcf differ diff --git a/_images/kogito/bpmn/grn_star_lg.png b/_images/kogito/bpmn/grn_star_lg.png new file mode 100644 index 0000000..8d211e2 Binary files /dev/null and b/_images/kogito/bpmn/grn_star_lg.png differ diff --git a/_images/kogito/bpmn/grn_star_sm.png b/_images/kogito/bpmn/grn_star_sm.png new file mode 100644 index 0000000..aa2d1db Binary files /dev/null and b/_images/kogito/bpmn/grn_star_sm.png differ diff --git a/_images/kogito/bpmn/kogito-management-console-domain-explorer-visas-attributes.png b/_images/kogito/bpmn/kogito-management-console-domain-explorer-visas-attributes.png new file mode 100644 index 0000000..4ba5bfa Binary files /dev/null and b/_images/kogito/bpmn/kogito-management-console-domain-explorer-visas-attributes.png differ diff --git a/_images/kogito/bpmn/kogito-management-console-domain-explorer-visas-sorted-data.png b/_images/kogito/bpmn/kogito-management-console-domain-explorer-visas-sorted-data.png new file mode 100644 index 0000000..ff9b0cf Binary files /dev/null and b/_images/kogito/bpmn/kogito-management-console-domain-explorer-visas-sorted-data.png differ diff --git a/_images/kogito/bpmn/kogito-management-console-domain-explorer-visas.png b/_images/kogito/bpmn/kogito-management-console-domain-explorer-visas.png new file mode 100644 index 0000000..449dd6c Binary files /dev/null and b/_images/kogito/bpmn/kogito-management-console-domain-explorer-visas.png differ diff --git a/_images/kogito/bpmn/kogito-management-console-domain-explorer.png b/_images/kogito/bpmn/kogito-management-console-domain-explorer.png new file mode 100644 index 0000000..e1bfeb6 Binary files /dev/null and b/_images/kogito/bpmn/kogito-management-console-domain-explorer.png differ diff --git a/_images/kogito/bpmn/kogito-management-console-node-error-skip.png b/_images/kogito/bpmn/kogito-management-console-node-error-skip.png new file mode 100644 index 0000000..52f2793 Binary files /dev/null and b/_images/kogito/bpmn/kogito-management-console-node-error-skip.png differ diff --git a/_images/kogito/bpmn/kogito-management-console-node-error.png b/_images/kogito/bpmn/kogito-management-console-node-error.png new file mode 100644 index 0000000..1320b5c Binary files /dev/null and b/_images/kogito/bpmn/kogito-management-console-node-error.png differ diff --git a/_images/kogito/bpmn/kogito-management-console-process-details.png b/_images/kogito/bpmn/kogito-management-console-process-details.png new file mode 100644 index 0000000..9229ec5 Binary files /dev/null and b/_images/kogito/bpmn/kogito-management-console-process-details.png differ diff --git a/_images/kogito/bpmn/kogito-management-console-process-endpoint.png b/_images/kogito/bpmn/kogito-management-console-process-endpoint.png new file mode 100644 index 0000000..563aa5c Binary files /dev/null and b/_images/kogito/bpmn/kogito-management-console-process-endpoint.png differ diff --git a/_images/kogito/bpmn/kogito-management-console-process-error.png b/_images/kogito/bpmn/kogito-management-console-process-error.png new file mode 100644 index 0000000..5a71b06 Binary files /dev/null and b/_images/kogito/bpmn/kogito-management-console-process-error.png differ diff --git a/_images/kogito/bpmn/kogito-management-console-subprocesses.png b/_images/kogito/bpmn/kogito-management-console-subprocesses.png new file mode 100644 index 0000000..dab5ddf Binary files /dev/null and b/_images/kogito/bpmn/kogito-management-console-subprocesses.png differ diff --git a/_images/kogito/bpmn/kogito-management-console.png b/_images/kogito/bpmn/kogito-management-console.png new file mode 100644 index 0000000..652023f Binary files /dev/null and b/_images/kogito/bpmn/kogito-management-console.png differ diff --git a/_images/kogito/bpmn/process-designer-activities.png b/_images/kogito/bpmn/process-designer-activities.png new file mode 100644 index 0000000..84a7966 Binary files /dev/null and b/_images/kogito/bpmn/process-designer-activities.png differ diff --git a/_images/kogito/bpmn/subprocess.png b/_images/kogito/bpmn/subprocess.png new file mode 100644 index 0000000..de79876 Binary files /dev/null and b/_images/kogito/bpmn/subprocess.png differ diff --git a/_images/kogito/bpmn/swimlane.png b/_images/kogito/bpmn/swimlane.png new file mode 100644 index 0000000..6b406cd Binary files /dev/null and b/_images/kogito/bpmn/swimlane.png differ diff --git a/_images/kogito/configuration/data-index-architecture.jpg b/_images/kogito/configuration/data-index-architecture.jpg new file mode 100644 index 0000000..213f84d Binary files /dev/null and b/_images/kogito/configuration/data-index-architecture.jpg differ diff --git a/_images/kogito/configuration/jobs-service-architecture.png b/_images/kogito/configuration/jobs-service-architecture.png new file mode 100644 index 0000000..a6e6132 Binary files /dev/null and b/_images/kogito/configuration/jobs-service-architecture.png differ diff --git a/_images/kogito/configuration/jobs-service-state-control.png b/_images/kogito/configuration/jobs-service-state-control.png new file mode 100644 index 0000000..7f64e7e Binary files /dev/null and b/_images/kogito/configuration/jobs-service-state-control.png differ diff --git a/_images/kogito/configuration/prometheus-expression-browser-targets.png b/_images/kogito/configuration/prometheus-expression-browser-targets.png new file mode 100644 index 0000000..ae544eb Binary files /dev/null and b/_images/kogito/configuration/prometheus-expression-browser-targets.png differ diff --git a/_images/kogito/configuration/prometheus-grafana-data.png b/_images/kogito/configuration/prometheus-grafana-data.png new file mode 100644 index 0000000..7c15ca2 Binary files /dev/null and b/_images/kogito/configuration/prometheus-grafana-data.png differ diff --git a/_images/kogito/creating-running/bpmn-model-example-order-items.png b/_images/kogito/creating-running/bpmn-model-example-order-items.png new file mode 100644 index 0000000..51c11c1 Binary files /dev/null and b/_images/kogito/creating-running/bpmn-model-example-order-items.png differ diff --git a/_images/kogito/creating-running/bpmn-model-example-orders.png b/_images/kogito/creating-running/bpmn-model-example-orders.png new file mode 100644 index 0000000..70de51e Binary files /dev/null and b/_images/kogito/creating-running/bpmn-model-example-orders.png differ diff --git a/_images/kogito/creating-running/kogito-assets-to-cloud.png b/_images/kogito/creating-running/kogito-assets-to-cloud.png new file mode 100644 index 0000000..d0eb4f5 Binary files /dev/null and b/_images/kogito/creating-running/kogito-assets-to-cloud.png differ diff --git a/_images/kogito/creating-running/kogito-bpmn-example-person.png b/_images/kogito/creating-running/kogito-bpmn-example-person.png new file mode 100644 index 0000000..6bb8487 Binary files /dev/null and b/_images/kogito/creating-running/kogito-bpmn-example-person.png differ diff --git a/_images/kogito/creating-running/kogito-dmn-example-person-data-types.png b/_images/kogito/creating-running/kogito-dmn-example-person-data-types.png new file mode 100644 index 0000000..c63ad82 Binary files /dev/null and b/_images/kogito/creating-running/kogito-dmn-example-person-data-types.png differ diff --git a/_images/kogito/creating-running/kogito-dmn-example-person-logic.png b/_images/kogito/creating-running/kogito-dmn-example-person-logic.png new file mode 100644 index 0000000..8a6b60c Binary files /dev/null and b/_images/kogito/creating-running/kogito-dmn-example-person-logic.png differ diff --git a/_images/kogito/creating-running/kogito-dmn-example-person.png b/_images/kogito/creating-running/kogito-dmn-example-person.png new file mode 100644 index 0000000..c811676 Binary files /dev/null and b/_images/kogito/creating-running/kogito-dmn-example-person.png differ diff --git a/_images/kogito/creating-running/kogito-domain-api-endpoints-example.png b/_images/kogito/creating-running/kogito-domain-api-endpoints-example.png new file mode 100644 index 0000000..e32f13c Binary files /dev/null and b/_images/kogito/creating-running/kogito-domain-api-endpoints-example.png differ diff --git a/_images/kogito/creating-running/kogito-modeler-hub.png b/_images/kogito/creating-running/kogito-modeler-hub.png new file mode 100644 index 0000000..c1da8bb Binary files /dev/null and b/_images/kogito/creating-running/kogito-modeler-hub.png differ diff --git a/_images/kogito/creating-running/kogito-related-technolgies.png b/_images/kogito/creating-running/kogito-related-technolgies.png new file mode 100644 index 0000000..f30f2b5 Binary files /dev/null and b/_images/kogito/creating-running/kogito-related-technolgies.png differ diff --git a/_images/kogito/creating-running/kogito-run-quarkus-devmode-demo.gif b/_images/kogito/creating-running/kogito-run-quarkus-devmode-demo.gif new file mode 100644 index 0000000..f669cf7 Binary files /dev/null and b/_images/kogito/creating-running/kogito-run-quarkus-devmode-demo.gif differ diff --git a/_images/kogito/creating-running/kogito-swagger-example-jbpm.png b/_images/kogito/creating-running/kogito-swagger-example-jbpm.png new file mode 100644 index 0000000..84b88e6 Binary files /dev/null and b/_images/kogito/creating-running/kogito-swagger-example-jbpm.png differ diff --git a/_images/kogito/creating-running/kogito-swagger-example.png b/_images/kogito/creating-running/kogito-swagger-example.png new file mode 100644 index 0000000..b64fbad Binary files /dev/null and b/_images/kogito/creating-running/kogito-swagger-example.png differ diff --git a/_images/kogito/decision-engine/Alpha_Nodes.png b/_images/kogito/decision-engine/Alpha_Nodes.png new file mode 100644 index 0000000..1838df6 Binary files /dev/null and b/_images/kogito/decision-engine/Alpha_Nodes.png differ diff --git a/_images/kogito/decision-engine/Alpha_Nodes.svg b/_images/kogito/decision-engine/Alpha_Nodes.svg new file mode 100644 index 0000000..e566d4d --- /dev/null +++ b/_images/kogito/decision-engine/Alpha_Nodes.svg @@ -0,0 +1,90 @@ + + + + + + + + + + + + + + + + Page-1 + + + + + On-page reference.79 + + + + + + + + On-page reference.80 + + + + + + + + Dynamic connector.81 + + + + + + + Sheet.82 + Cheese + + + + Cheese + + Dynamic connector.83 + + + + + + + Sheet.84 + name == “cheddar” + + + + name == “cheddar” + + On-page reference.91 + + + + + + + + Sheet.93 + strength == “strong” + + + + strength == “strong” + + \ No newline at end of file diff --git a/_images/kogito/decision-engine/Backward_Chaining.png b/_images/kogito/decision-engine/Backward_Chaining.png new file mode 100644 index 0000000..e036a25 Binary files /dev/null and b/_images/kogito/decision-engine/Backward_Chaining.png differ diff --git a/_images/kogito/decision-engine/Backward_Chaining.svg b/_images/kogito/decision-engine/Backward_Chaining.svg new file mode 100644 index 0000000..e302c78 --- /dev/null +++ b/_images/kogito/decision-engine/Backward_Chaining.svg @@ -0,0 +1,458 @@ + + + + + + + + + + + + + + + + + + Page-1 + + + + + Process.8 + Examine working memory and goals to see if goals are “known” ... + + + + + + + + + + + + Examine working memory and goals to see if goals are “known” true in KIE base + + Process (circle).9 + Working Memory + + + + + + + + + + + + WorkingMemory + + Process (circle).10 + Rule Base + + + + + + + + + + + + RuleBase + + Process (circle).11 + Goal + + + + + + + + + + + + Goal + + Decision.12 + Do goals match? + + + + + + + + + + + + Do goals match? + + Process.13 + Return True + + + + + + + + + + + + Return True + + Process.14 + Return False + + + + + + + + + + + + Return False + + Process.15 + Determine next possible rules to fire by checking conclusions... + + + + + + + + + + + + Determine next possible rules to fire by checking conclusions and goals + + Decision.16 + Select Rule to Fire + + + + + + + + + + + + Select Rule to Fire + + Process (circle).17 + Conflict Resolution Strategy + + + + + + + + + + + + ConflictResolutionStrategy + + Process.18 + Fire Rule + + + + + + + + + + + + Fire Rule + + Process.19 + For each rule condition, recursively backchain with condition... + + + + + + + + + + + + For each rule condition, recursively backchain with condition as goal. + + Decision.20 + All recursion returns true? + + + + + + + + + + + + All recursion returns true? + + Process.21 + true + + + + + + + + + + + + true + + Dynamic connector.31 + + + + + + + Dynamic connector.32 + + + + + + + Dynamic connector.33 + + + + + + + Dynamic connector.34 + + + + + + + Dynamic connector.35 + + + + + + + Dynamic connector.36 + yes + + + + + + + + yes + + Dynamic connector.37 + + + + + + + Dynamic connector.38 + + + + + + + Dynamic connector.39 + + + + + + + Dynamic connector.40 + No Rule Found + + + + + + + + No Rule Found + + Process.41 + Exit + + + + + + + + + + + + Exit + + Dynamic connector.42 + Goals found to be true, exist, returning true + + + + + + + + Goals found to be true, exist, returning true + + Dynamic connector.43 + + + + + + + Dynamic connector.44 + Rule Found + + + + + + + + Rule Found + + Dynamic connector.45 + + + + + + + Dynamic connector.46 + + + + + + + Dynamic connector.47 + + + + + + + Dynamic connector.48 + + + + + + + Sheet.49 + Yes + + + + Yes + + Sheet.51 + One or more goals failed, Check next matching rule + + + + One or more goals failed, Check next matching rule + + Sheet.52 + Recursively back-chain + + + + Recursively back-chain + + Sheet.53 + Each condition of fired rule is a goal + + + + Each condition of fired rule is a goal + + Sheet.54 + No (return false to recursive procedure) + + + + No (return false to recursive procedure) + + Dynamic connector.56 + + + + + + + diff --git a/_images/kogito/decision-engine/Forward_Chaining.png b/_images/kogito/decision-engine/Forward_Chaining.png new file mode 100644 index 0000000..9500d2a Binary files /dev/null and b/_images/kogito/decision-engine/Forward_Chaining.png differ diff --git a/_images/kogito/decision-engine/Forward_Chaining.svg b/_images/kogito/decision-engine/Forward_Chaining.svg new file mode 100644 index 0000000..56c92d1 --- /dev/null +++ b/_images/kogito/decision-engine/Forward_Chaining.svg @@ -0,0 +1,215 @@ + + + + + + + + + + + + + + + + Page-1 + + + + + Decision + Select Rule to Fire + + + + + + + + + + + + Select Rule to Fire + + Process + Determine possible rules to fire + + + + + + + + + + + + Determine possible rules to fire + + Process.3 + exit + + + + + + + + + + + + exit + + Process.4 + Fire Rule + + + + + + + + + + + + Fire Rule + + Process (circle) + Rule Base + + + + + + + + + + + + RuleBase + + Process (circle).6 + Working Memory + + + + + + + + + + + + WorkingMemory + + Process (circle).7 + Conflict Resolution Strategy + + + + + + + + + + + + ConflictResolutionStrategy + + Dynamic connector + Rule Found + + + + + + + + RuleFound + + Dynamic connector.23 + + + + + + + Dynamic connector.24 + + + + + + + Dynamic connector.25 + + + + + + + Dynamic connector.26 + + + + + + + Dynamic connector.27 + Conflict Set + + + + + + + + Conflict Set + + Dynamic connector.28 + No Rule Found + + + + + + + + No RuleFound + + Dynamic connector.29 + Exit If specified by rule + + + + + + + + Exit If specified by rule + + Dynamic connector.30 + + + + + + + \ No newline at end of file diff --git a/_images/kogito/decision-engine/Join_Node.png b/_images/kogito/decision-engine/Join_Node.png new file mode 100644 index 0000000..901df8d Binary files /dev/null and b/_images/kogito/decision-engine/Join_Node.png differ diff --git a/_images/kogito/decision-engine/Join_Node.svg b/_images/kogito/decision-engine/Join_Node.svg new file mode 100644 index 0000000..a3f03d8 --- /dev/null +++ b/_images/kogito/decision-engine/Join_Node.svg @@ -0,0 +1,140 @@ + + + + + + + + + + + + + + + + + + + Page-1 + + + + + On-page reference.47 + + + + + + + + On-page reference.48 + + + + + + + + Dynamic connector.49 + + + + + + + Sheet.50 + Cheese + + + + Cheese + + Sheet.55 + name == “cheddar” + + + + name == “cheddar” + + On-page reference.43 + + + + + + + + Manual operation + + + + + + + + + + + + + + On-page reference.45 + + + + + + + + Dynamic connector + + + + + + + Sheet.53 + Person + + + + Person + + Sheet.57 + Person.favouriteCheese == Cheese.name + + + + Person.favouriteCheese == Cheese.name + + Dynamic connector.58 + + + + + + + Dynamic connector.59 + + + + + + + \ No newline at end of file diff --git a/_images/kogito/decision-engine/LayeredMemory.png b/_images/kogito/decision-engine/LayeredMemory.png new file mode 100644 index 0000000..a87b302 Binary files /dev/null and b/_images/kogito/decision-engine/LayeredMemory.png differ diff --git a/_images/kogito/decision-engine/LayeredMemory_enterprise.png b/_images/kogito/decision-engine/LayeredMemory_enterprise.png new file mode 100644 index 0000000..40c5da1 Binary files /dev/null and b/_images/kogito/decision-engine/LayeredMemory_enterprise.png differ diff --git a/_images/kogito/decision-engine/Logical_Assertion.png b/_images/kogito/decision-engine/Logical_Assertion.png new file mode 100644 index 0000000..a608121 Binary files /dev/null and b/_images/kogito/decision-engine/Logical_Assertion.png differ diff --git a/_images/kogito/decision-engine/Logical_Assertion.svg b/_images/kogito/decision-engine/Logical_Assertion.svg new file mode 100644 index 0000000..696483e --- /dev/null +++ b/_images/kogito/decision-engine/Logical_Assertion.svg @@ -0,0 +1,269 @@ + + + + + + + + + + + + + + + + Page-1 + + + + + Decision + Does the Object already exist? + + + + + + + + + + + + Does the Object already exist? + + Decision.2 + Is the Object STATED or JUSTIFED? + + + + + + + + + + + + Is the Object STATED or JUSTIFED? + + Dynamic connector + yes + + + + + + + + yes + + Process + Can’t Justify a STATED fact, return existing FactHandle. + + + + + + + + + + + + Can’t Justify a STATED fact, return existing FactHandle. + + Dynamic connector.6 + STATED + + + + + + + + STATED + + Dynamic connector.7 + JUSTIFIED + + + + + + + + JUSTIFIED + + Process.8 + Add additional justification and return existing FactHandle + + + + + + + + + + + + Add additional justification and return existing FactHandle + + Decision.4 + Is there an existing Equal Object? + + + + + + + + + + + + Is there an existing Equal Object? + + Dynamic connector.9 + no + + + + + + + + no + + Dynamic connector.10 + yes + + + + + + + + yes + + Dynamic connector.11 + no + + + + + + + + no + + Decision.13 + Is the Object STATED or JUSTIFE? + + + + + + + + + + + + Is the Object STATED or JUSTIFE? + + Process.14 + Can’t Justify a STATED fact, return null. + + + + + + + + + + + + Can’t Justify a STATED fact, return null. + + Dynamic connector.15 + STATED + + + + + + + + STATED + + Dynamic connector.16 + JUSTIFIED + + + + + + + + JUSTIFIED + + Process.12 + Add first justification and return new FactHandle + + + + + + + + + + + + Add first justification and return new FactHandle + + Process.17 + Add first justification and return new FactHandle + + + + + + + + + + + + Add first justification and return new FactHandle + + On-page reference.83 + + + + + + + + Dynamic connector.19 + + + + + + + \ No newline at end of file diff --git a/_images/kogito/decision-engine/Logical_Assertion_enterprise.png b/_images/kogito/decision-engine/Logical_Assertion_enterprise.png new file mode 100644 index 0000000..2d55b16 Binary files /dev/null and b/_images/kogito/decision-engine/Logical_Assertion_enterprise.png differ diff --git a/_images/kogito/decision-engine/Node_Sharing.png b/_images/kogito/decision-engine/Node_Sharing.png new file mode 100644 index 0000000..3b128c9 Binary files /dev/null and b/_images/kogito/decision-engine/Node_Sharing.png differ diff --git a/_images/kogito/decision-engine/Node_Sharing.svg b/_images/kogito/decision-engine/Node_Sharing.svg new file mode 100644 index 0000000..b2ab6ab --- /dev/null +++ b/_images/kogito/decision-engine/Node_Sharing.svg @@ -0,0 +1,223 @@ + + + + + + + + + + + + + + + + + + + Page-1 + + + + + On-page reference.47 + + + + + + + + On-page reference.48 + + + + + + + + Dynamic connector.49 + + + + + + + Terminator.51 + + + + + + + + + + + + + Dynamic connector.52 + + + + + + + Sheet.6 + name == “cheddar” + + + + name == “cheddar” + + On-page reference.43 + + + + + + + + Manual operation + + + + + + + + + + + + + + On-page reference.45 + + + + + + + + Dynamic connector + + + + + + + Sheet.11 + Person + + + + Person + + Sheet.12 + Person.favouriteCheese == Cheese.name + + + + Person.favouriteCheese == Cheese.name + + Sheet.15 + System.out.println( person.getName() + " likes cheddar" ) + + + + System.out.println( person.getName() + " likes cheddar" ) + + Manual operation.17 + + + + + + + + + + + + + + Sheet.18 + Person.favouriteCheese != Cheese.name + + + + Person.favouriteCheese != Cheese.name + + Dynamic connector.19 + + + + + + + Dynamic connector.13 + + + + + + + Dynamic connector.20 + + + + + + + Dynamic connector.14 + + + + + + + Terminator.21 + + + + + + + + + + + + + Dynamic connector.22 + + + + + + + Sheet.23 + System.out.println( person.getName() + " does not like chedda... + + + + System.out.println( person.getName() + " does not like cheddar" ) + + \ No newline at end of file diff --git a/_images/kogito/decision-engine/Object_Type_Nodes.png b/_images/kogito/decision-engine/Object_Type_Nodes.png new file mode 100644 index 0000000..12478c5 Binary files /dev/null and b/_images/kogito/decision-engine/Object_Type_Nodes.png differ diff --git a/_images/kogito/decision-engine/Object_Type_Nodes.svg b/_images/kogito/decision-engine/Object_Type_Nodes.svg new file mode 100644 index 0000000..b28d5ee --- /dev/null +++ b/_images/kogito/decision-engine/Object_Type_Nodes.svg @@ -0,0 +1,108 @@ + + + + + + + + + + + + + + + + + + + Page-1 + + + + + On-page reference.65 + + + + + + + + On-page reference.66 + + + + + + + + Dynamic connector.67 + + + + + + + Sheet.68 + Cheese + + + + Cheese + + On-page reference.69 + + + + + + + + Sheet.70 + Person + + + + Person + + Dynamic connector.71 + + + + + + + Dynamic connector.72 + + + + + + + Dynamic connector.73 + + + + + + + Sheet.74 + ReteNode + + + + ReteNode + + \ No newline at end of file diff --git a/_images/kogito/decision-engine/ReasoningGraph.png b/_images/kogito/decision-engine/ReasoningGraph.png new file mode 100644 index 0000000..53f501d Binary files /dev/null and b/_images/kogito/decision-engine/ReasoningGraph.png differ diff --git a/_images/kogito/decision-engine/Rete_Nodes.png b/_images/kogito/decision-engine/Rete_Nodes.png new file mode 100644 index 0000000..b6818e1 Binary files /dev/null and b/_images/kogito/decision-engine/Rete_Nodes.png differ diff --git a/_images/kogito/decision-engine/Rete_Nodes.svg b/_images/kogito/decision-engine/Rete_Nodes.svg new file mode 100644 index 0000000..e38863d --- /dev/null +++ b/_images/kogito/decision-engine/Rete_Nodes.svg @@ -0,0 +1,162 @@ + + + + + + + + Page-1 + + + + + On-page reference.35 + + + + + + + + On-page reference.36 + + + + + + + + On-page reference.37 + + + + + + + + Terminator.40 + + + + + + + + + + + + + Sheet.39 + ObjectTypeNode + + + + ObjectTypeNode + + Sheet.40 + AlphaNode + + + + AlphaNode + + Manual operation.38 + + + + + + + + + + + + + + Sheet.62 + JoinNode + + + + JoinNode + + Sheet.63 + LeftInputAdapterNode + + + + LeftInputAdapterNode + + Sheet.64 + TerminalNode + + + + TerminalNode + + On-page reference.41 + + + + + + + + Sheet.42 + ReteNode + + + + ReteNode + + On-page reference.75 + + + + + + + + Sheet.76 + EvalNode + + + + EvalNode + + Manual operation.77 + + + + + + + + + + + + + + Sheet.78 + NotNode + + + + NotNode + + \ No newline at end of file diff --git a/_images/kogito/decision-engine/RuleEvaluation.png b/_images/kogito/decision-engine/RuleEvaluation.png new file mode 100644 index 0000000..beeed47 Binary files /dev/null and b/_images/kogito/decision-engine/RuleEvaluation.png differ diff --git a/_images/kogito/decision-engine/RuleEvaluation_Enterprise.png b/_images/kogito/decision-engine/RuleEvaluation_Enterprise.png new file mode 100644 index 0000000..ce2fc05 Binary files /dev/null and b/_images/kogito/decision-engine/RuleEvaluation_Enterprise.png differ diff --git a/_images/kogito/decision-engine/Stated_Assertion.png b/_images/kogito/decision-engine/Stated_Assertion.png new file mode 100644 index 0000000..340655e Binary files /dev/null and b/_images/kogito/decision-engine/Stated_Assertion.png differ diff --git a/_images/kogito/decision-engine/Stated_Assertion.svg b/_images/kogito/decision-engine/Stated_Assertion.svg new file mode 100644 index 0000000..32391a1 --- /dev/null +++ b/_images/kogito/decision-engine/Stated_Assertion.svg @@ -0,0 +1,321 @@ + + + + + + + + + + + + + + + + Page-1 + + + + + Decision.20 + Does the Object already exist? + + + + + + + + + + + + Does the Object already exist? + + Decision.21 + Is the Object STATED or JUSTIFED? + + + + + + + + + + + + Is the Object STATED or JUSTIFED? + + Dynamic connector.22 + yes + + + + + + + + yes + + Process.23 + Return existing FactHandle. + + + + + + + + + + + + Return existing FactHandle. + + Dynamic connector.24 + STATED + + + + + + + + STATED + + Dynamic connector.25 + JUSTIFIED + + + + + + + + JUSTIFIED + + Process.26 + Override JUSTIFIED and set to STATED, remove justifications a... + + + + + + + + + + + + Override JUSTIFIED and set to STATED, remove justifications and return existing FactHandle + + Decision.27 + Is there an existing Equal Object? + + + + + + + + + + + + Is there an existing Equal Object? + + Dynamic connector.28 + no + + + + + + + + no + + Dynamic connector.29 + yes + + + + + + + + yes + + Dynamic connector.30 + no + + + + + + + + no + + Decision.31 + Is the Object STATED or JUSTIFED? + + + + + + + + + + + + Is the Object STATED or JUSTIFED? + + Process.32 + Return new FactHandle + + + + + + + + + + + + Return new FactHandle + + Dynamic connector.33 + STATED + + + + + + + + STATED + + Dynamic connector.34 + JUSTIFIED + + + + + + + + JUSTIFIED + + Process.36 + Return new FactHandle + + + + + + + + + + + + Return new FactHandle + + On-page reference.37 + + + + + + + + Dynamic connector.38 + + + + + + + Decision.39 + Discard Logical Assertion? + + + + + + + + + + + + Discard Logical Assertion? + + Process.40 + Override JUSTIFIED, and set to STATED, set existing handle to... + + + + + + + + + + + + Override JUSTIFIED, and set to STATED, set existing handle to the new Object. + + Process.41 + Override JUSTIFIED and set to STATED, remove justifications a... + + + + + + + + + + + + Override JUSTIFIED and set to STATED, remove justifications and return existing FactHandle + + Dynamic connector.42 + yes + + + + + + + + yes + + Dynamic connector.43 + no + + + + + + + + no + + \ No newline at end of file diff --git a/_images/kogito/decision-engine/Stated_Assertion_enterprise.png b/_images/kogito/decision-engine/Stated_Assertion_enterprise.png new file mode 100644 index 0000000..c546875 Binary files /dev/null and b/_images/kogito/decision-engine/Stated_Assertion_enterprise.png differ diff --git a/_images/kogito/decision-engine/TransitiveReasoning.png b/_images/kogito/decision-engine/TransitiveReasoning.png new file mode 100644 index 0000000..1ce891c Binary files /dev/null and b/_images/kogito/decision-engine/TransitiveReasoning.png differ diff --git a/_images/kogito/decision-engine/TransitiveReasoning_Enterprise.png b/_images/kogito/decision-engine/TransitiveReasoning_Enterprise.png new file mode 100644 index 0000000..0b8189f Binary files /dev/null and b/_images/kogito/decision-engine/TransitiveReasoning_Enterprise.png differ diff --git a/_images/kogito/decision-engine/Two_Phase.png b/_images/kogito/decision-engine/Two_Phase.png new file mode 100644 index 0000000..22c8d4a Binary files /dev/null and b/_images/kogito/decision-engine/Two_Phase.png differ diff --git a/_images/kogito/decision-engine/Two_Phase.svg b/_images/kogito/decision-engine/Two_Phase.svg new file mode 100644 index 0000000..40a6d6c --- /dev/null +++ b/_images/kogito/decision-engine/Two_Phase.svg @@ -0,0 +1,222 @@ + + + + + + + + + + + + + + + + + + Page-1 + + + + + Process.17 + Working Memory Action + + + + + + + + + + + + Working Memory Action + + Process.18 + retract + + + + + + + + + + + + retract + + Process.19 + update + + + + + + + + + + + + update + + Process.21 + insert + + + + + + + + + + + + insert + + Process.22 + Agenda Evaluation + + + + + + + + + + + + Agenda Evaluation + + Decision.23 + Select Rule to Fire + + + + + + + + + + + + Select Rule to Fire + + Process.25 + exit + + + + + + + + + + + + exit + + Dynamic connector.27 + No Rule Found + + + + + + + + No RuleFound + + Process.24 + Fire Rule + + + + + + + + + + + + Fire Rule + + Dynamic connector.26 + + + + + + + Dynamic connector.28 + + + + + + + Process.29 + Determine possible rules to fire + + + + + + + + + + + + Determine possible rules to fire + + Dynamic connector.30 + + + + + + + Dynamic connector.31 + + + + + + + Sheet.20 + Rule Found + + + + RuleFound + + diff --git a/_images/kogito/decision-engine/Two_Phase.vsd b/_images/kogito/decision-engine/Two_Phase.vsd new file mode 100644 index 0000000..512e152 Binary files /dev/null and b/_images/kogito/decision-engine/Two_Phase.vsd differ diff --git a/_images/kogito/decision-engine/Two_Phase_enterprise.png b/_images/kogito/decision-engine/Two_Phase_enterprise.png new file mode 100644 index 0000000..447da1e Binary files /dev/null and b/_images/kogito/decision-engine/Two_Phase_enterprise.png differ diff --git a/_images/kogito/decision-engine/book_recommendations.png b/_images/kogito/decision-engine/book_recommendations.png new file mode 100644 index 0000000..345bcb9 Binary files /dev/null and b/_images/kogito/decision-engine/book_recommendations.png differ diff --git a/_images/kogito/decision-engine/drools_book_recommendations.png b/_images/kogito/decision-engine/drools_book_recommendations.png new file mode 100644 index 0000000..b7ff4f7 Binary files /dev/null and b/_images/kogito/decision-engine/drools_book_recommendations.png differ diff --git a/_images/kogito/decision-engine/expertsytem_history.png b/_images/kogito/decision-engine/expertsytem_history.png new file mode 100644 index 0000000..8bf9e31 Binary files /dev/null and b/_images/kogito/decision-engine/expertsytem_history.png differ diff --git a/_images/kogito/decision-engine/rule-engine-inkscape.png b/_images/kogito/decision-engine/rule-engine-inkscape.png new file mode 100644 index 0000000..c06138f Binary files /dev/null and b/_images/kogito/decision-engine/rule-engine-inkscape.png differ diff --git a/_images/kogito/decision-engine/rule-engine-inkscape.svg b/_images/kogito/decision-engine/rule-engine-inkscape.svg new file mode 100644 index 0000000..61007d6 --- /dev/null +++ b/_images/kogito/decision-engine/rule-engine-inkscape.svg @@ -0,0 +1,440 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + Inference Engine + (ReteOO / Leaps) + + + + + + + + + + + + + + Agenda + + + + PatternMatcher + + + + + + diff --git a/_images/kogito/decision-engine/rule-engine-inkscape_enterprise.png b/_images/kogito/decision-engine/rule-engine-inkscape_enterprise.png new file mode 100644 index 0000000..1cb205a Binary files /dev/null and b/_images/kogito/decision-engine/rule-engine-inkscape_enterprise.png differ diff --git a/_images/kogito/decision-engine/segment1.png b/_images/kogito/decision-engine/segment1.png new file mode 100644 index 0000000..52cab83 Binary files /dev/null and b/_images/kogito/decision-engine/segment1.png differ diff --git a/_images/kogito/decision-engine/segment1_enterprise.png b/_images/kogito/decision-engine/segment1_enterprise.png new file mode 100644 index 0000000..1bebd8e Binary files /dev/null and b/_images/kogito/decision-engine/segment1_enterprise.png differ diff --git a/_images/kogito/decision-engine/segment2.png b/_images/kogito/decision-engine/segment2.png new file mode 100644 index 0000000..e20ee75 Binary files /dev/null and b/_images/kogito/decision-engine/segment2.png differ diff --git a/_images/kogito/decision-engine/segment2_enterprise.png b/_images/kogito/decision-engine/segment2_enterprise.png new file mode 100644 index 0000000..2a797d5 Binary files /dev/null and b/_images/kogito/decision-engine/segment2_enterprise.png differ diff --git a/_images/kogito/decision-engine/segment3.png b/_images/kogito/decision-engine/segment3.png new file mode 100644 index 0000000..8a03d03 Binary files /dev/null and b/_images/kogito/decision-engine/segment3.png differ diff --git a/_images/kogito/decision-engine/segment3_enterprise.png b/_images/kogito/decision-engine/segment3_enterprise.png new file mode 100644 index 0000000..7696bd1 Binary files /dev/null and b/_images/kogito/decision-engine/segment3_enterprise.png differ diff --git a/_images/kogito/decision-engine/segment4.png b/_images/kogito/decision-engine/segment4.png new file mode 100644 index 0000000..9176d66 Binary files /dev/null and b/_images/kogito/decision-engine/segment4.png differ diff --git a/_images/kogito/decision-engine/segment4_enterprise.png b/_images/kogito/decision-engine/segment4_enterprise.png new file mode 100644 index 0000000..7d93ea4 Binary files /dev/null and b/_images/kogito/decision-engine/segment4_enterprise.png differ diff --git a/_images/kogito/decision-engine/segment5.png b/_images/kogito/decision-engine/segment5.png new file mode 100644 index 0000000..c5b3593 Binary files /dev/null and b/_images/kogito/decision-engine/segment5.png differ diff --git a/_images/kogito/decision-engine/segment5_enterprise.png b/_images/kogito/decision-engine/segment5_enterprise.png new file mode 100644 index 0000000..3886760 Binary files /dev/null and b/_images/kogito/decision-engine/segment5_enterprise.png differ diff --git a/_images/kogito/decision-tables/decision-table-example-02.png b/_images/kogito/decision-tables/decision-table-example-02.png new file mode 100644 index 0000000..22774fb Binary files /dev/null and b/_images/kogito/decision-tables/decision-table-example-02.png differ diff --git a/_images/kogito/decision-tables/decision-table-example-03.png b/_images/kogito/decision-tables/decision-table-example-03.png new file mode 100644 index 0000000..47e54f2 Binary files /dev/null and b/_images/kogito/decision-tables/decision-table-example-03.png differ diff --git a/_images/kogito/dmn/decision_node_edit.png b/_images/kogito/dmn/decision_node_edit.png new file mode 100644 index 0000000..20998a7 Binary files /dev/null and b/_images/kogito/dmn/decision_node_edit.png differ diff --git a/_images/kogito/dmn/dmn-add-project-gs.png b/_images/kogito/dmn/dmn-add-project-gs.png new file mode 100644 index 0000000..6bc3bc1 Binary files /dev/null and b/_images/kogito/dmn/dmn-add-project-gs.png differ diff --git a/_images/kogito/dmn/dmn-age-classification-decision-table.png b/_images/kogito/dmn/dmn-age-classification-decision-table.png new file mode 100644 index 0000000..781ec9b Binary files /dev/null and b/_images/kogito/dmn/dmn-age-classification-decision-table.png differ diff --git a/_images/kogito/dmn/dmn-age-classification-drd.png b/_images/kogito/dmn/dmn-age-classification-drd.png new file mode 100644 index 0000000..4fe4da3 Binary files /dev/null and b/_images/kogito/dmn/dmn-age-classification-drd.png differ diff --git a/_images/kogito/dmn/dmn-annotation-node.png b/_images/kogito/dmn/dmn-annotation-node.png new file mode 100644 index 0000000..52e4ac7 Binary files /dev/null and b/_images/kogito/dmn/dmn-annotation-node.png differ diff --git a/_images/kogito/dmn/dmn-association-connector.png b/_images/kogito/dmn/dmn-association-connector.png new file mode 100644 index 0000000..2c72c43 Binary files /dev/null and b/_images/kogito/dmn/dmn-association-connector.png differ diff --git a/_images/kogito/dmn/dmn-authority-connector.png b/_images/kogito/dmn/dmn-authority-connector.png new file mode 100644 index 0000000..bc2ce2a Binary files /dev/null and b/_images/kogito/dmn/dmn-authority-connector.png differ diff --git a/_images/kogito/dmn/dmn-bkm-define.png b/_images/kogito/dmn/dmn-bkm-define.png new file mode 100644 index 0000000..6d2180f Binary files /dev/null and b/_images/kogito/dmn/dmn-bkm-define.png differ diff --git a/_images/kogito/dmn/dmn-bkm-edit.png b/_images/kogito/dmn/dmn-bkm-edit.png new file mode 100644 index 0000000..a45dfb5 Binary files /dev/null and b/_images/kogito/dmn/dmn-bkm-edit.png differ diff --git a/_images/kogito/dmn/dmn-bkm-node.png b/_images/kogito/dmn/dmn-bkm-node.png new file mode 100644 index 0000000..2d10243 Binary files /dev/null and b/_images/kogito/dmn/dmn-bkm-node.png differ diff --git a/_images/kogito/dmn/dmn-bkm-to-annotation.png b/_images/kogito/dmn/dmn-bkm-to-annotation.png new file mode 100644 index 0000000..804b605 Binary files /dev/null and b/_images/kogito/dmn/dmn-bkm-to-annotation.png differ diff --git a/_images/kogito/dmn/dmn-bkm-to-bkm.png b/_images/kogito/dmn/dmn-bkm-to-bkm.png new file mode 100644 index 0000000..702de27 Binary files /dev/null and b/_images/kogito/dmn/dmn-bkm-to-bkm.png differ diff --git a/_images/kogito/dmn/dmn-bkm-to-decision.png b/_images/kogito/dmn/dmn-bkm-to-decision.png new file mode 100644 index 0000000..84116ed Binary files /dev/null and b/_images/kogito/dmn/dmn-bkm-to-decision.png differ diff --git a/_images/kogito/dmn/dmn-boxed-expression-example.png b/_images/kogito/dmn/dmn-boxed-expression-example.png new file mode 100644 index 0000000..70c29b3 Binary files /dev/null and b/_images/kogito/dmn/dmn-boxed-expression-example.png differ diff --git a/_images/kogito/dmn/dmn-boxed-expression-example2.png b/_images/kogito/dmn/dmn-boxed-expression-example2.png new file mode 100644 index 0000000..00562e0 Binary files /dev/null and b/_images/kogito/dmn/dmn-boxed-expression-example2.png differ diff --git a/_images/kogito/dmn/dmn-context-expression-example.png b/_images/kogito/dmn/dmn-context-expression-example.png new file mode 100644 index 0000000..dbd8e56 Binary files /dev/null and b/_images/kogito/dmn/dmn-context-expression-example.png differ diff --git a/_images/kogito/dmn/dmn-context-expression-example2.png b/_images/kogito/dmn/dmn-context-expression-example2.png new file mode 100644 index 0000000..f03d6f9 Binary files /dev/null and b/_images/kogito/dmn/dmn-context-expression-example2.png differ diff --git a/_images/kogito/dmn/dmn-custom-data-type-add.png b/_images/kogito/dmn/dmn-custom-data-type-add.png new file mode 100644 index 0000000..bbe1a82 Binary files /dev/null and b/_images/kogito/dmn/dmn-custom-data-type-add.png differ diff --git a/_images/kogito/dmn/dmn-custom-data-type-constraints-drag.png b/_images/kogito/dmn/dmn-custom-data-type-constraints-drag.png new file mode 100644 index 0000000..18d9dbe Binary files /dev/null and b/_images/kogito/dmn/dmn-custom-data-type-constraints-drag.png differ diff --git a/_images/kogito/dmn/dmn-custom-data-type-constraints.png b/_images/kogito/dmn/dmn-custom-data-type-constraints.png new file mode 100644 index 0000000..34e7b96 Binary files /dev/null and b/_images/kogito/dmn/dmn-custom-data-type-constraints.png differ diff --git a/_images/kogito/dmn/dmn-custom-datatypes-tab.png b/_images/kogito/dmn/dmn-custom-datatypes-tab.png new file mode 100644 index 0000000..d6a3b4c Binary files /dev/null and b/_images/kogito/dmn/dmn-custom-datatypes-tab.png differ diff --git a/_images/kogito/dmn/dmn-datatype-constraints-tickmark.png b/_images/kogito/dmn/dmn-datatype-constraints-tickmark.png new file mode 100644 index 0000000..e527031 Binary files /dev/null and b/_images/kogito/dmn/dmn-datatype-constraints-tickmark.png differ diff --git a/_images/kogito/dmn/dmn-decision-boxed-expression-options.png b/_images/kogito/dmn/dmn-decision-boxed-expression-options.png new file mode 100644 index 0000000..c4c8db4 Binary files /dev/null and b/_images/kogito/dmn/dmn-decision-boxed-expression-options.png differ diff --git a/_images/kogito/dmn/dmn-decision-edit.png b/_images/kogito/dmn/dmn-decision-edit.png new file mode 100644 index 0000000..c68c107 Binary files /dev/null and b/_images/kogito/dmn/dmn-decision-edit.png differ diff --git a/_images/kogito/dmn/dmn-decision-node.png b/_images/kogito/dmn/dmn-decision-node.png new file mode 100644 index 0000000..b4af674 Binary files /dev/null and b/_images/kogito/dmn/dmn-decision-node.png differ diff --git a/_images/kogito/dmn/dmn-decision-service-node.png b/_images/kogito/dmn/dmn-decision-service-node.png new file mode 100644 index 0000000..a650d22 Binary files /dev/null and b/_images/kogito/dmn/dmn-decision-service-node.png differ diff --git a/_images/kogito/dmn/dmn-decision-service-node1.png b/_images/kogito/dmn/dmn-decision-service-node1.png new file mode 100644 index 0000000..4746d2e Binary files /dev/null and b/_images/kogito/dmn/dmn-decision-service-node1.png differ diff --git a/_images/kogito/dmn/dmn-decision-service-to-bkm.png b/_images/kogito/dmn/dmn-decision-service-to-bkm.png new file mode 100644 index 0000000..b571a82 Binary files /dev/null and b/_images/kogito/dmn/dmn-decision-service-to-bkm.png differ diff --git a/_images/kogito/dmn/dmn-decision-service-to-decision.png b/_images/kogito/dmn/dmn-decision-service-to-decision.png new file mode 100644 index 0000000..c095ba8 Binary files /dev/null and b/_images/kogito/dmn/dmn-decision-service-to-decision.png differ diff --git a/_images/kogito/dmn/dmn-decision-table-example.png b/_images/kogito/dmn/dmn-decision-table-example.png new file mode 100644 index 0000000..f887d55 Binary files /dev/null and b/_images/kogito/dmn/dmn-decision-table-example.png differ diff --git a/_images/kogito/dmn/dmn-decision-table-example1a.png b/_images/kogito/dmn/dmn-decision-table-example1a.png new file mode 100644 index 0000000..6ea93c6 Binary files /dev/null and b/_images/kogito/dmn/dmn-decision-table-example1a.png differ diff --git a/_images/kogito/dmn/dmn-decision-table-example2.png b/_images/kogito/dmn/dmn-decision-table-example2.png new file mode 100644 index 0000000..1c42a27 Binary files /dev/null and b/_images/kogito/dmn/dmn-decision-table-example2.png differ diff --git a/_images/kogito/dmn/dmn-decision-table-example3.png b/_images/kogito/dmn/dmn-decision-table-example3.png new file mode 100644 index 0000000..11cf8ac Binary files /dev/null and b/_images/kogito/dmn/dmn-decision-table-example3.png differ diff --git a/_images/kogito/dmn/dmn-decision-to-annotation.png b/_images/kogito/dmn/dmn-decision-to-annotation.png new file mode 100644 index 0000000..67252ad Binary files /dev/null and b/_images/kogito/dmn/dmn-decision-to-annotation.png differ diff --git a/_images/kogito/dmn/dmn-decision-to-decision.png b/_images/kogito/dmn/dmn-decision-to-decision.png new file mode 100644 index 0000000..e71aeeb Binary files /dev/null and b/_images/kogito/dmn/dmn-decision-to-decision.png differ diff --git a/_images/kogito/dmn/dmn-designer-nav-view.png b/_images/kogito/dmn/dmn-designer-nav-view.png new file mode 100644 index 0000000..6911fd6 Binary files /dev/null and b/_images/kogito/dmn/dmn-designer-nav-view.png differ diff --git a/_images/kogito/dmn/dmn-designer-nav-view2.png b/_images/kogito/dmn/dmn-designer-nav-view2.png new file mode 100644 index 0000000..972b758 Binary files /dev/null and b/_images/kogito/dmn/dmn-designer-nav-view2.png differ diff --git a/_images/kogito/dmn/dmn-designer-preview.png b/_images/kogito/dmn/dmn-designer-preview.png new file mode 100644 index 0000000..0c7de95 Binary files /dev/null and b/_images/kogito/dmn/dmn-designer-preview.png differ diff --git a/_images/kogito/dmn/dmn-designer-project-view.png b/_images/kogito/dmn/dmn-designer-project-view.png new file mode 100644 index 0000000..755a94f Binary files /dev/null and b/_images/kogito/dmn/dmn-designer-project-view.png differ diff --git a/_images/kogito/dmn/dmn-designer-properties.png b/_images/kogito/dmn/dmn-designer-properties.png new file mode 100644 index 0000000..1f6750f Binary files /dev/null and b/_images/kogito/dmn/dmn-designer-properties.png differ diff --git a/_images/kogito/dmn/dmn-designer-search.png b/_images/kogito/dmn/dmn-designer-search.png new file mode 100644 index 0000000..429faf4 Binary files /dev/null and b/_images/kogito/dmn/dmn-designer-search.png differ diff --git a/_images/kogito/dmn/dmn-diagram-properties-tab.png b/_images/kogito/dmn/dmn-diagram-properties-tab.png new file mode 100644 index 0000000..5910eaa Binary files /dev/null and b/_images/kogito/dmn/dmn-diagram-properties-tab.png differ diff --git a/_images/kogito/dmn/dmn-documentation.png b/_images/kogito/dmn/dmn-documentation.png new file mode 100644 index 0000000..5b4a39a Binary files /dev/null and b/_images/kogito/dmn/dmn-documentation.png differ diff --git a/_images/kogito/dmn/dmn-drag-decision-node.png b/_images/kogito/dmn/dmn-drag-decision-node.png new file mode 100644 index 0000000..695c7c4 Binary files /dev/null and b/_images/kogito/dmn/dmn-drag-decision-node.png differ diff --git a/_images/kogito/dmn/dmn-drg.png b/_images/kogito/dmn/dmn-drg.png new file mode 100644 index 0000000..bb2f92b Binary files /dev/null and b/_images/kogito/dmn/dmn-drg.png differ diff --git a/_images/kogito/dmn/dmn-example-drd.png b/_images/kogito/dmn/dmn-example-drd.png new file mode 100644 index 0000000..4ef2b6c Binary files /dev/null and b/_images/kogito/dmn/dmn-example-drd.png differ diff --git a/_images/kogito/dmn/dmn-example-drd2.png b/_images/kogito/dmn/dmn-example-drd2.png new file mode 100644 index 0000000..e95e246 Binary files /dev/null and b/_images/kogito/dmn/dmn-example-drd2.png differ diff --git a/_images/kogito/dmn/dmn-example-drd3.png b/_images/kogito/dmn/dmn-example-drd3.png new file mode 100644 index 0000000..22bf965 Binary files /dev/null and b/_images/kogito/dmn/dmn-example-drd3.png differ diff --git a/_images/kogito/dmn/dmn-execution-business-process.png b/_images/kogito/dmn/dmn-execution-business-process.png new file mode 100644 index 0000000..230c0b3 Binary files /dev/null and b/_images/kogito/dmn/dmn-execution-business-process.png differ diff --git a/_images/kogito/dmn/dmn-execution-data-type.png b/_images/kogito/dmn/dmn-execution-data-type.png new file mode 100644 index 0000000..e422327 Binary files /dev/null and b/_images/kogito/dmn/dmn-execution-data-type.png differ diff --git a/_images/kogito/dmn/dmn-execution-expression.png b/_images/kogito/dmn/dmn-execution-expression.png new file mode 100644 index 0000000..4776d4c Binary files /dev/null and b/_images/kogito/dmn/dmn-execution-expression.png differ diff --git a/_images/kogito/dmn/dmn-execution-graph.png b/_images/kogito/dmn/dmn-execution-graph.png new file mode 100644 index 0000000..3d4ce9a Binary files /dev/null and b/_images/kogito/dmn/dmn-execution-graph.png differ diff --git a/_images/kogito/dmn/dmn-execution-io-mapping.png b/_images/kogito/dmn/dmn-execution-io-mapping.png new file mode 100644 index 0000000..87ffa69 Binary files /dev/null and b/_images/kogito/dmn/dmn-execution-io-mapping.png differ diff --git a/_images/kogito/dmn/dmn-execution-negative-condition.png b/_images/kogito/dmn/dmn-execution-negative-condition.png new file mode 100644 index 0000000..3a091f0 Binary files /dev/null and b/_images/kogito/dmn/dmn-execution-negative-condition.png differ diff --git a/_images/kogito/dmn/dmn-execution-positive-condition.png b/_images/kogito/dmn/dmn-execution-positive-condition.png new file mode 100644 index 0000000..c086bf4 Binary files /dev/null and b/_images/kogito/dmn/dmn-execution-positive-condition.png differ diff --git a/_images/kogito/dmn/dmn-execution-process-instance-form.png b/_images/kogito/dmn/dmn-execution-process-instance-form.png new file mode 100644 index 0000000..972f5a0 Binary files /dev/null and b/_images/kogito/dmn/dmn-execution-process-instance-form.png differ diff --git a/_images/kogito/dmn/dmn-function-example.png b/_images/kogito/dmn/dmn-function-example.png new file mode 100644 index 0000000..010f947 Binary files /dev/null and b/_images/kogito/dmn/dmn-function-example.png differ diff --git a/_images/kogito/dmn/dmn-function-expression-example.png b/_images/kogito/dmn/dmn-function-expression-example.png new file mode 100644 index 0000000..ee8cb16 Binary files /dev/null and b/_images/kogito/dmn/dmn-function-expression-example.png differ diff --git a/_images/kogito/dmn/dmn-function-expression-example2.png b/_images/kogito/dmn/dmn-function-expression-example2.png new file mode 100644 index 0000000..4552f8e Binary files /dev/null and b/_images/kogito/dmn/dmn-function-expression-example2.png differ diff --git a/_images/kogito/dmn/dmn-function-expression-example3.png b/_images/kogito/dmn/dmn-function-expression-example3.png new file mode 100644 index 0000000..1434805 Binary files /dev/null and b/_images/kogito/dmn/dmn-function-expression-example3.png differ diff --git a/_images/kogito/dmn/dmn-function-expression-example4.png b/_images/kogito/dmn/dmn-function-expression-example4.png new file mode 100644 index 0000000..538d94f Binary files /dev/null and b/_images/kogito/dmn/dmn-function-expression-example4.png differ diff --git a/_images/kogito/dmn/dmn-function-expression-example5.png b/_images/kogito/dmn/dmn-function-expression-example5.png new file mode 100644 index 0000000..27ae6c2 Binary files /dev/null and b/_images/kogito/dmn/dmn-function-expression-example5.png differ diff --git a/_images/kogito/dmn/dmn-gs-context-table.png b/_images/kogito/dmn/dmn-gs-context-table.png new file mode 100644 index 0000000..164abb4 Binary files /dev/null and b/_images/kogito/dmn/dmn-gs-context-table.png differ diff --git a/_images/kogito/dmn/dmn-gs-fine-decision-table.png b/_images/kogito/dmn/dmn-gs-fine-decision-table.png new file mode 100644 index 0000000..1b26e94 Binary files /dev/null and b/_images/kogito/dmn/dmn-gs-fine-decision-table.png differ diff --git a/_images/kogito/dmn/dmn-gs-test-scenarios-execution-results.png b/_images/kogito/dmn/dmn-gs-test-scenarios-execution-results.png new file mode 100644 index 0000000..b5f3afc Binary files /dev/null and b/_images/kogito/dmn/dmn-gs-test-scenarios-execution-results.png differ diff --git a/_images/kogito/dmn/dmn-gs-traffic-violation-test-scenarios.png b/_images/kogito/dmn/dmn-gs-traffic-violation-test-scenarios.png new file mode 100644 index 0000000..d09a196 Binary files /dev/null and b/_images/kogito/dmn/dmn-gs-traffic-violation-test-scenarios.png differ diff --git a/_images/kogito/dmn/dmn-hit-policies.png b/_images/kogito/dmn/dmn-hit-policies.png new file mode 100644 index 0000000..b224564 Binary files /dev/null and b/_images/kogito/dmn/dmn-hit-policies.png differ diff --git a/_images/kogito/dmn/dmn-include-model-data-types.png b/_images/kogito/dmn/dmn-include-model-data-types.png new file mode 100644 index 0000000..421b884 Binary files /dev/null and b/_images/kogito/dmn/dmn-include-model-data-types.png differ diff --git a/_images/kogito/dmn/dmn-include-model-drd.png b/_images/kogito/dmn/dmn-include-model-drd.png new file mode 100644 index 0000000..1a3ee6f Binary files /dev/null and b/_images/kogito/dmn/dmn-include-model-drd.png differ diff --git a/_images/kogito/dmn/dmn-include-model-expression-pmml.png b/_images/kogito/dmn/dmn-include-model-expression-pmml.png new file mode 100644 index 0000000..cb8e11a Binary files /dev/null and b/_images/kogito/dmn/dmn-include-model-expression-pmml.png differ diff --git a/_images/kogito/dmn/dmn-include-model-list-pmml.png b/_images/kogito/dmn/dmn-include-model-list-pmml.png new file mode 100644 index 0000000..c02c69a Binary files /dev/null and b/_images/kogito/dmn/dmn-include-model-list-pmml.png differ diff --git a/_images/kogito/dmn/dmn-include-model-list.png b/_images/kogito/dmn/dmn-include-model-list.png new file mode 100644 index 0000000..0c192f9 Binary files /dev/null and b/_images/kogito/dmn/dmn-include-model-list.png differ diff --git a/_images/kogito/dmn/dmn-include-model-pmml.png b/_images/kogito/dmn/dmn-include-model-pmml.png new file mode 100644 index 0000000..8d0741b Binary files /dev/null and b/_images/kogito/dmn/dmn-include-model-pmml.png differ diff --git a/_images/kogito/dmn/dmn-include-model.png b/_images/kogito/dmn/dmn-include-model.png new file mode 100644 index 0000000..5098a6b Binary files /dev/null and b/_images/kogito/dmn/dmn-include-model.png differ diff --git a/_images/kogito/dmn/dmn-info-connector.png b/_images/kogito/dmn/dmn-info-connector.png new file mode 100644 index 0000000..f0914d2 Binary files /dev/null and b/_images/kogito/dmn/dmn-info-connector.png differ diff --git a/_images/kogito/dmn/dmn-input-connection-example.png b/_images/kogito/dmn/dmn-input-connection-example.png new file mode 100644 index 0000000..570d857 Binary files /dev/null and b/_images/kogito/dmn/dmn-input-connection-example.png differ diff --git a/_images/kogito/dmn/dmn-input-connection-example2.png b/_images/kogito/dmn/dmn-input-connection-example2.png new file mode 100644 index 0000000..57c4d18 Binary files /dev/null and b/_images/kogito/dmn/dmn-input-connection-example2.png differ diff --git a/_images/kogito/dmn/dmn-input-data-node.png b/_images/kogito/dmn/dmn-input-data-node.png new file mode 100644 index 0000000..fc7965a Binary files /dev/null and b/_images/kogito/dmn/dmn-input-data-node.png differ diff --git a/_images/kogito/dmn/dmn-input-to-annotation.png b/_images/kogito/dmn/dmn-input-to-annotation.png new file mode 100644 index 0000000..402f585 Binary files /dev/null and b/_images/kogito/dmn/dmn-input-to-annotation.png differ diff --git a/_images/kogito/dmn/dmn-input-to-decision.png b/_images/kogito/dmn/dmn-input-to-decision.png new file mode 100644 index 0000000..9dbe5b5 Binary files /dev/null and b/_images/kogito/dmn/dmn-input-to-decision.png differ diff --git a/_images/kogito/dmn/dmn-input-to-knowledge-source.png b/_images/kogito/dmn/dmn-input-to-knowledge-source.png new file mode 100644 index 0000000..4069fce Binary files /dev/null and b/_images/kogito/dmn/dmn-input-to-knowledge-source.png differ diff --git a/_images/kogito/dmn/dmn-invocation-example.png b/_images/kogito/dmn/dmn-invocation-example.png new file mode 100644 index 0000000..22017a4 Binary files /dev/null and b/_images/kogito/dmn/dmn-invocation-example.png differ diff --git a/_images/kogito/dmn/dmn-invocation-example2.png b/_images/kogito/dmn/dmn-invocation-example2.png new file mode 100644 index 0000000..49a0378 Binary files /dev/null and b/_images/kogito/dmn/dmn-invocation-example2.png differ diff --git a/_images/kogito/dmn/dmn-knowledge-connector.png b/_images/kogito/dmn/dmn-knowledge-connector.png new file mode 100644 index 0000000..08c1378 Binary files /dev/null and b/_images/kogito/dmn/dmn-knowledge-connector.png differ diff --git a/_images/kogito/dmn/dmn-knowledge-source-node.png b/_images/kogito/dmn/dmn-knowledge-source-node.png new file mode 100644 index 0000000..ae4d81a Binary files /dev/null and b/_images/kogito/dmn/dmn-knowledge-source-node.png differ diff --git a/_images/kogito/dmn/dmn-knowledge-source-to-annotation.png b/_images/kogito/dmn/dmn-knowledge-source-to-annotation.png new file mode 100644 index 0000000..05a586c Binary files /dev/null and b/_images/kogito/dmn/dmn-knowledge-source-to-annotation.png differ diff --git a/_images/kogito/dmn/dmn-knowledge-source-to-bkm.png b/_images/kogito/dmn/dmn-knowledge-source-to-bkm.png new file mode 100644 index 0000000..7a61942 Binary files /dev/null and b/_images/kogito/dmn/dmn-knowledge-source-to-bkm.png differ diff --git a/_images/kogito/dmn/dmn-knowledge-source-to-decision.png b/_images/kogito/dmn/dmn-knowledge-source-to-decision.png new file mode 100644 index 0000000..8a4e41b Binary files /dev/null and b/_images/kogito/dmn/dmn-knowledge-source-to-decision.png differ diff --git a/_images/kogito/dmn/dmn-knowledge-source-to-knowledge-source.png b/_images/kogito/dmn/dmn-knowledge-source-to-knowledge-source.png new file mode 100644 index 0000000..e807579 Binary files /dev/null and b/_images/kogito/dmn/dmn-knowledge-source-to-knowledge-source.png differ diff --git a/_images/kogito/dmn/dmn-list-expression-example.png b/_images/kogito/dmn/dmn-list-expression-example.png new file mode 100644 index 0000000..6269d79 Binary files /dev/null and b/_images/kogito/dmn/dmn-list-expression-example.png differ diff --git a/_images/kogito/dmn/dmn-list-expression-example2.png b/_images/kogito/dmn/dmn-list-expression-example2.png new file mode 100644 index 0000000..ec885ec Binary files /dev/null and b/_images/kogito/dmn/dmn-list-expression-example2.png differ diff --git a/_images/kogito/dmn/dmn-list-expression-example2a.png b/_images/kogito/dmn/dmn-list-expression-example2a.png new file mode 100644 index 0000000..d398882 Binary files /dev/null and b/_images/kogito/dmn/dmn-list-expression-example2a.png differ diff --git a/_images/kogito/dmn/dmn-literal-expression-example.png b/_images/kogito/dmn/dmn-literal-expression-example.png new file mode 100644 index 0000000..6b1a060 Binary files /dev/null and b/_images/kogito/dmn/dmn-literal-expression-example.png differ diff --git a/_images/kogito/dmn/dmn-literal-expression-example2.png b/_images/kogito/dmn/dmn-literal-expression-example2.png new file mode 100644 index 0000000..1255c97 Binary files /dev/null and b/_images/kogito/dmn/dmn-literal-expression-example2.png differ diff --git a/_images/kogito/dmn/dmn-literal-expression-example3.png b/_images/kogito/dmn/dmn-literal-expression-example3.png new file mode 100644 index 0000000..b30a7e2 Binary files /dev/null and b/_images/kogito/dmn/dmn-literal-expression-example3.png differ diff --git a/_images/kogito/dmn/dmn-literal-expression-example3b.png b/_images/kogito/dmn/dmn-literal-expression-example3b.png new file mode 100644 index 0000000..d47b4de Binary files /dev/null and b/_images/kogito/dmn/dmn-literal-expression-example3b.png differ diff --git a/_images/kogito/dmn/dmn-literal-expression-example4.png b/_images/kogito/dmn/dmn-literal-expression-example4.png new file mode 100644 index 0000000..1cb0ae7 Binary files /dev/null and b/_images/kogito/dmn/dmn-literal-expression-example4.png differ diff --git a/_images/kogito/dmn/dmn-manage-data-types-blank.png b/_images/kogito/dmn/dmn-manage-data-types-blank.png new file mode 100644 index 0000000..c64a7d4 Binary files /dev/null and b/_images/kogito/dmn/dmn-manage-data-types-blank.png differ diff --git a/_images/kogito/dmn/dmn-manage-data-types-structured.png b/_images/kogito/dmn/dmn-manage-data-types-structured.png new file mode 100644 index 0000000..590b9bf Binary files /dev/null and b/_images/kogito/dmn/dmn-manage-data-types-structured.png differ diff --git a/_images/kogito/dmn/dmn-manage-data-types-structured2-drag.png b/_images/kogito/dmn/dmn-manage-data-types-structured2-drag.png new file mode 100644 index 0000000..b82f211 Binary files /dev/null and b/_images/kogito/dmn/dmn-manage-data-types-structured2-drag.png differ diff --git a/_images/kogito/dmn/dmn-manage-data-types-structured2.png b/_images/kogito/dmn/dmn-manage-data-types-structured2.png new file mode 100644 index 0000000..909ce20 Binary files /dev/null and b/_images/kogito/dmn/dmn-manage-data-types-structured2.png differ diff --git a/_images/kogito/dmn/dmn-manage-data-types-structured3.png b/_images/kogito/dmn/dmn-manage-data-types-structured3.png new file mode 100644 index 0000000..0796b75 Binary files /dev/null and b/_images/kogito/dmn/dmn-manage-data-types-structured3.png differ diff --git a/_images/kogito/dmn/dmn-manage-data-types-structured3a.png b/_images/kogito/dmn/dmn-manage-data-types-structured3a.png new file mode 100644 index 0000000..6e3435b Binary files /dev/null and b/_images/kogito/dmn/dmn-manage-data-types-structured3a.png differ diff --git a/_images/kogito/dmn/dmn-manage-data-types-structured3b.png b/_images/kogito/dmn/dmn-manage-data-types-structured3b.png new file mode 100644 index 0000000..5f66dc9 Binary files /dev/null and b/_images/kogito/dmn/dmn-manage-data-types-structured3b.png differ diff --git a/_images/kogito/dmn/dmn-manage-data-types.png b/_images/kogito/dmn/dmn-manage-data-types.png new file mode 100644 index 0000000..65872be Binary files /dev/null and b/_images/kogito/dmn/dmn-manage-data-types.png differ diff --git a/_images/kogito/dmn/dmn-manage-data-types1a.png b/_images/kogito/dmn/dmn-manage-data-types1a.png new file mode 100644 index 0000000..155e72a Binary files /dev/null and b/_images/kogito/dmn/dmn-manage-data-types1a.png differ diff --git a/_images/kogito/dmn/dmn-manage-data-types2.png b/_images/kogito/dmn/dmn-manage-data-types2.png new file mode 100644 index 0000000..42fc1ff Binary files /dev/null and b/_images/kogito/dmn/dmn-manage-data-types2.png differ diff --git a/_images/kogito/dmn/dmn-new-project-gs.png b/_images/kogito/dmn/dmn-new-project-gs.png new file mode 100644 index 0000000..21e6d4a Binary files /dev/null and b/_images/kogito/dmn/dmn-new-project-gs.png differ diff --git a/_images/kogito/dmn/dmn-passenger-rebooking-drd.png b/_images/kogito/dmn/dmn-passenger-rebooking-drd.png new file mode 100644 index 0000000..779c21a Binary files /dev/null and b/_images/kogito/dmn/dmn-passenger-rebooking-drd.png differ diff --git a/_images/kogito/dmn/dmn-play-icon.png b/_images/kogito/dmn/dmn-play-icon.png new file mode 100644 index 0000000..e177d29 Binary files /dev/null and b/_images/kogito/dmn/dmn-play-icon.png differ diff --git a/_images/kogito/dmn/dmn-reassign-passenger.png b/_images/kogito/dmn/dmn-reassign-passenger.png new file mode 100644 index 0000000..7c71d70 Binary files /dev/null and b/_images/kogito/dmn/dmn-reassign-passenger.png differ diff --git a/_images/kogito/dmn/dmn-relation-expression-example.png b/_images/kogito/dmn/dmn-relation-expression-example.png new file mode 100644 index 0000000..393ec4e Binary files /dev/null and b/_images/kogito/dmn/dmn-relation-expression-example.png differ diff --git a/_images/kogito/dmn/dmn-tDriver-custom-datatype.png b/_images/kogito/dmn/dmn-tDriver-custom-datatype.png new file mode 100644 index 0000000..cd65d76 Binary files /dev/null and b/_images/kogito/dmn/dmn-tDriver-custom-datatype.png differ diff --git a/_images/kogito/dmn/dmn-tFine-custom-datatype.png b/_images/kogito/dmn/dmn-tFine-custom-datatype.png new file mode 100644 index 0000000..fe0732d Binary files /dev/null and b/_images/kogito/dmn/dmn-tFine-custom-datatype.png differ diff --git a/_images/kogito/dmn/dmn-tViolation-custom-datatype.png b/_images/kogito/dmn/dmn-tViolation-custom-datatype.png new file mode 100644 index 0000000..2a84332 Binary files /dev/null and b/_images/kogito/dmn/dmn-tViolation-custom-datatype.png differ diff --git a/_images/kogito/dmn/dmn-traffic-violations-drd.png b/_images/kogito/dmn/dmn-traffic-violations-drd.png new file mode 100644 index 0000000..e115593 Binary files /dev/null and b/_images/kogito/dmn/dmn-traffic-violations-drd.png differ diff --git a/_images/kogito/dmn/info-requirement.png b/_images/kogito/dmn/info-requirement.png new file mode 100644 index 0000000..9b684a2 Binary files /dev/null and b/_images/kogito/dmn/info-requirement.png differ diff --git a/_images/kogito/dmn/library_objects.png b/_images/kogito/dmn/library_objects.png new file mode 100644 index 0000000..e02cbf7 Binary files /dev/null and b/_images/kogito/dmn/library_objects.png differ diff --git a/_images/kogito/dmn/select_logic_type.png b/_images/kogito/dmn/select_logic_type.png new file mode 100644 index 0000000..d7ec741 Binary files /dev/null and b/_images/kogito/dmn/select_logic_type.png differ diff --git a/_images/kogito/dmn/try-samples.png b/_images/kogito/dmn/try-samples.png new file mode 100644 index 0000000..05c6532 Binary files /dev/null and b/_images/kogito/dmn/try-samples.png differ diff --git a/_images/kogito/drl/AccumulateAction.png b/_images/kogito/drl/AccumulateAction.png new file mode 100644 index 0000000..25e6811 Binary files /dev/null and b/_images/kogito/drl/AccumulateAction.png differ diff --git a/_images/kogito/drl/AccumulateAction.svg b/_images/kogito/drl/AccumulateAction.svg new file mode 100644 index 0000000..68cceaa --- /dev/null +++ b/_images/kogito/drl/AccumulateAction.svg @@ -0,0 +1,52 @@ + +AccumulateAction + + +action + + + + +( + + + + +Statement + + + + + + + + + + + + +) + + + +, + + + + + + + + + + + + +AccumulateAction + + + diff --git a/_images/kogito/drl/AccumulateClause.png b/_images/kogito/drl/AccumulateClause.png new file mode 100644 index 0000000..e227793 Binary files /dev/null and b/_images/kogito/drl/AccumulateClause.png differ diff --git a/_images/kogito/drl/AccumulateClause.svg b/_images/kogito/drl/AccumulateClause.svg new file mode 100644 index 0000000..7da5568 --- /dev/null +++ b/_images/kogito/drl/AccumulateClause.svg @@ -0,0 +1,64 @@ + +AccumulateClause + + +accumulate + + + + +( + + + + +ConditionalAnd + + + + +, + + + + + + + + + + + + + + +AccumulateSteps + + + +AccumulateFunction + + + + + + + + + + + + + + +) + + +AccumulateClause + + + diff --git a/_images/kogito/drl/AccumulateFunction.png b/_images/kogito/drl/AccumulateFunction.png new file mode 100644 index 0000000..e5068e1 Binary files /dev/null and b/_images/kogito/drl/AccumulateFunction.png differ diff --git a/_images/kogito/drl/AccumulateFunction.svg b/_images/kogito/drl/AccumulateFunction.svg new file mode 100644 index 0000000..91efff7 --- /dev/null +++ b/_images/kogito/drl/AccumulateFunction.svg @@ -0,0 +1,51 @@ + +AccumulateFunction + + +Identifier + + + + +( + + + + +ConditionalExpr + + +, + + + + + + + + + + + + + + + + + + + + + + +) + + +AccumulateFunction + + + diff --git a/_images/kogito/drl/AccumulateInit.png b/_images/kogito/drl/AccumulateInit.png new file mode 100644 index 0000000..3535310 Binary files /dev/null and b/_images/kogito/drl/AccumulateInit.png differ diff --git a/_images/kogito/drl/AccumulateInit.svg b/_images/kogito/drl/AccumulateInit.svg new file mode 100644 index 0000000..5a82e42 --- /dev/null +++ b/_images/kogito/drl/AccumulateInit.svg @@ -0,0 +1,52 @@ + +AccumulateInit + + +init + + + + +( + + + + +Statement + + + + + + + + + + + + +) + + + +, + + + + + + + + + + + + +AccumulateInit + + + diff --git a/_images/kogito/drl/AccumulateResult.png b/_images/kogito/drl/AccumulateResult.png new file mode 100644 index 0000000..dd4411b Binary files /dev/null and b/_images/kogito/drl/AccumulateResult.png differ diff --git a/_images/kogito/drl/AccumulateResult.svg b/_images/kogito/drl/AccumulateResult.svg new file mode 100644 index 0000000..44a08e9 --- /dev/null +++ b/_images/kogito/drl/AccumulateResult.svg @@ -0,0 +1,30 @@ + +AccumulateResult + + +result + + + + +( + + + + +ConditionalExpr + + + + +) + + +AccumulateResult + + + diff --git a/_images/kogito/drl/AccumulateReverse.png b/_images/kogito/drl/AccumulateReverse.png new file mode 100644 index 0000000..7487d43 Binary files /dev/null and b/_images/kogito/drl/AccumulateReverse.png differ diff --git a/_images/kogito/drl/AccumulateReverse.svg b/_images/kogito/drl/AccumulateReverse.svg new file mode 100644 index 0000000..22e6858 --- /dev/null +++ b/_images/kogito/drl/AccumulateReverse.svg @@ -0,0 +1,52 @@ + +AccumulateReverse + + +reverse + + + + +( + + + + +Statement + + + + + + + + + + + + +) + + + +, + + + + + + + + + + + + +AccumulateReverse + + + diff --git a/_images/kogito/drl/AccumulateSteps.png b/_images/kogito/drl/AccumulateSteps.png new file mode 100644 index 0000000..278bd59 Binary files /dev/null and b/_images/kogito/drl/AccumulateSteps.png differ diff --git a/_images/kogito/drl/AccumulateSteps.svg b/_images/kogito/drl/AccumulateSteps.svg new file mode 100644 index 0000000..bfe9b7b --- /dev/null +++ b/_images/kogito/drl/AccumulateSteps.svg @@ -0,0 +1,44 @@ + +AccumulateSteps + + +AccumulateInit + + + + + +AccumulateAction + + + + + +AccumulateReverse + + + + + + + + + + + + + + + +AccumulateResult + + + +AccumulateSteps + + + diff --git a/_images/kogito/drl/Accumulations.png b/_images/kogito/drl/Accumulations.png new file mode 100644 index 0000000..b4a1b3d Binary files /dev/null and b/_images/kogito/drl/Accumulations.png differ diff --git a/_images/kogito/drl/Accumulations.svg b/_images/kogito/drl/Accumulations.svg new file mode 100644 index 0000000..44d0d5a --- /dev/null +++ b/_images/kogito/drl/Accumulations.svg @@ -0,0 +1,39 @@ + +Accumulations + + +Identifier + + + + +: + + + + +AccumulateFunction + + +, + + + + + + + + + + + + + +Accumulations + + + diff --git a/_images/kogito/drl/AdditiveExpr.png b/_images/kogito/drl/AdditiveExpr.png new file mode 100644 index 0000000..deb5d6e Binary files /dev/null and b/_images/kogito/drl/AdditiveExpr.png differ diff --git a/_images/kogito/drl/AdditiveExpr.svg b/_images/kogito/drl/AdditiveExpr.svg new file mode 100644 index 0000000..217445d --- /dev/null +++ b/_images/kogito/drl/AdditiveExpr.svg @@ -0,0 +1,71 @@ + +AdditiveExpr + + +UnaryExpr + + +* + +/ + +% + + + + + + + + + + + + + + + + + + + + + + + + + ++ + +- + + + + + + + + + + + + + + + + + + + + + + + +AdditiveExpr + + + diff --git a/_images/kogito/drl/Annotation.png b/_images/kogito/drl/Annotation.png new file mode 100644 index 0000000..5ff82d0 Binary files /dev/null and b/_images/kogito/drl/Annotation.png differ diff --git a/_images/kogito/drl/Annotation.svg b/_images/kogito/drl/Annotation.svg new file mode 100644 index 0000000..83d5f80 --- /dev/null +++ b/_images/kogito/drl/Annotation.svg @@ -0,0 +1,81 @@ + +Annotation + +@ + + + + +Identifier + + + + +( + + + + +Tokens + + + +Identifier + + + + += + + + + +Value + + +, + + + + + + + + + + + + + + + + + + + + + + + + +) + + + + + + + + + + + + +Annotation + + + diff --git a/_images/kogito/drl/Arguments.png b/_images/kogito/drl/Arguments.png new file mode 100644 index 0000000..2414cb1 Binary files /dev/null and b/_images/kogito/drl/Arguments.png differ diff --git a/_images/kogito/drl/Arguments.svg b/_images/kogito/drl/Arguments.svg new file mode 100644 index 0000000..ca7e435 --- /dev/null +++ b/_images/kogito/drl/Arguments.svg @@ -0,0 +1,34 @@ + +Arguments + +( + + + + +ExpressionList + + + + + + + + + + + + + + +) + + +Arguments + + + diff --git a/_images/kogito/drl/ArrayCreatorRest.png b/_images/kogito/drl/ArrayCreatorRest.png new file mode 100644 index 0000000..6879672 Binary files /dev/null and b/_images/kogito/drl/ArrayCreatorRest.png differ diff --git a/_images/kogito/drl/ArrayCreatorRest.svg b/_images/kogito/drl/ArrayCreatorRest.svg new file mode 100644 index 0000000..2430bdc --- /dev/null +++ b/_images/kogito/drl/ArrayCreatorRest.svg @@ -0,0 +1,82 @@ + +ArrayCreatorRest + +[ + + + +] + + + + + + + + + + + + + + +ArrayInitializer + + +[ + + + + +Expression + + + + +] + + + + + + + + + + + + + +[ + + + +] + + + + + + + + + + + + + + + + + + + + +ArrayCreatorRest + + + diff --git a/_images/kogito/drl/ArrayInitializer.png b/_images/kogito/drl/ArrayInitializer.png new file mode 100644 index 0000000..95baa10 Binary files /dev/null and b/_images/kogito/drl/ArrayInitializer.png differ diff --git a/_images/kogito/drl/ArrayInitializer.svg b/_images/kogito/drl/ArrayInitializer.svg new file mode 100644 index 0000000..acdc5bd --- /dev/null +++ b/_images/kogito/drl/ArrayInitializer.svg @@ -0,0 +1,69 @@ + +ArrayInitializer + +{ + + + + +VariableInitializer + + +, + + + + + + + + + + + + + + + + + + + + + + +, + + + + + + + + + + + + + + + + + + + + + + + +} + + +ArrayInitializer + + + diff --git a/_images/kogito/drl/AssignmentOperator.png b/_images/kogito/drl/AssignmentOperator.png new file mode 100644 index 0000000..ec4e106 Binary files /dev/null and b/_images/kogito/drl/AssignmentOperator.png differ diff --git a/_images/kogito/drl/AssignmentOperator.svg b/_images/kogito/drl/AssignmentOperator.svg new file mode 100644 index 0000000..9596638 --- /dev/null +++ b/_images/kogito/drl/AssignmentOperator.svg @@ -0,0 +1,76 @@ + +AssignmentOperator + += + ++= + +-= + +*= + +/= + +&= + +|= + +^= + +%= + +<<= + +>>>= + +>>= + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +AssignmentOperator + + + diff --git a/_images/kogito/drl/BindingPattern.png b/_images/kogito/drl/BindingPattern.png new file mode 100644 index 0000000..94819e6 Binary files /dev/null and b/_images/kogito/drl/BindingPattern.png differ diff --git a/_images/kogito/drl/BindingPattern.svg b/_images/kogito/drl/BindingPattern.svg new file mode 100644 index 0000000..692d1e3 --- /dev/null +++ b/_images/kogito/drl/BindingPattern.svg @@ -0,0 +1,73 @@ + +BindingPattern + + +Identifier + + + + +: + + + + + + + + + + + + + + +SourcePattern + + +( + + + + +SourcePattern + + + +or + + + + + + + + + + + + + + + +) + + + + + + + + + + + + +BindingPattern + + + diff --git a/_images/kogito/drl/Block.png b/_images/kogito/drl/Block.png new file mode 100644 index 0000000..01d03e2 Binary files /dev/null and b/_images/kogito/drl/Block.png differ diff --git a/_images/kogito/drl/Block.svg b/_images/kogito/drl/Block.svg new file mode 100644 index 0000000..927be20 --- /dev/null +++ b/_images/kogito/drl/Block.svg @@ -0,0 +1,32 @@ + +Block + +{ + + + + +Statement + + + + + + + + + + + + +} + + +Block + + + diff --git a/_images/kogito/drl/BooleanLiteral.png b/_images/kogito/drl/BooleanLiteral.png new file mode 100644 index 0000000..20aa923 Binary files /dev/null and b/_images/kogito/drl/BooleanLiteral.png differ diff --git a/_images/kogito/drl/BooleanLiteral.svg b/_images/kogito/drl/BooleanLiteral.svg new file mode 100644 index 0000000..edaa743 --- /dev/null +++ b/_images/kogito/drl/BooleanLiteral.svg @@ -0,0 +1,30 @@ + +BooleanLiteral + + +true + + + +false + + + + + + + + + + + + + +BooleanLiteral + + + diff --git a/_images/kogito/drl/CompilationUnit.png b/_images/kogito/drl/CompilationUnit.png new file mode 100644 index 0000000..79d9865 Binary files /dev/null and b/_images/kogito/drl/CompilationUnit.png differ diff --git a/_images/kogito/drl/CompilationUnit.svg b/_images/kogito/drl/CompilationUnit.svg new file mode 100644 index 0000000..79d9622 --- /dev/null +++ b/_images/kogito/drl/CompilationUnit.svg @@ -0,0 +1,74 @@ + +CompilationUnit + + +package + + + + + +QualifiedName + + + + +; + + + + + + + + + + + + + + + + + + + + + + + + +Definition + + + + +; + + + + + + + + + + + + + + + + + + + + +CompilationUnit + + + diff --git a/_images/kogito/drl/ConditionalAnd.png b/_images/kogito/drl/ConditionalAnd.png new file mode 100644 index 0000000..cf26c2c Binary files /dev/null and b/_images/kogito/drl/ConditionalAnd.png differ diff --git a/_images/kogito/drl/ConditionalAnd.svg b/_images/kogito/drl/ConditionalAnd.svg new file mode 100644 index 0000000..6c18b02 --- /dev/null +++ b/_images/kogito/drl/ConditionalAnd.svg @@ -0,0 +1,31 @@ + +ConditionalAnd + + +ConditionalElement + + + +and + + + + + + + + + + + + + + +ConditionalAnd + + + diff --git a/_images/kogito/drl/ConditionalElement.png b/_images/kogito/drl/ConditionalElement.png new file mode 100644 index 0000000..543e12e Binary files /dev/null and b/_images/kogito/drl/ConditionalElement.png differ diff --git a/_images/kogito/drl/ConditionalElement.svg b/_images/kogito/drl/ConditionalElement.svg new file mode 100644 index 0000000..5d96016 --- /dev/null +++ b/_images/kogito/drl/ConditionalElement.svg @@ -0,0 +1,194 @@ + +ConditionalElement + + +exists + + + +not + + + + + + + + + + + + + + + +BindingPattern + + +( + + + + +ConditionalOr + + + + +) + + + + + + + + + + + + +eval + + + + +( + + + + +ConditionalExpr + + + + +) + + +forall + + + + +( + + + + +BindingPattern + + + + + + + + + + + + + + +) + + +accumulate + + + + +( + + + + +ConditionalAnd + + + + +, + + + + + + + + + + + + + + +Accumulations + + + + +) + +( + + + + +ConditionalOr + + + + +) + + +BindingPattern + + + + + + + + + + + + + + + + + + + + + + + + + + +; + + + + + + + + + + + + +ConditionalElement + + + diff --git a/_images/kogito/drl/ConditionalElementAccumulate.png b/_images/kogito/drl/ConditionalElementAccumulate.png new file mode 100644 index 0000000..c785ea8 Binary files /dev/null and b/_images/kogito/drl/ConditionalElementAccumulate.png differ diff --git a/_images/kogito/drl/ConditionalElementAccumulate.svg b/_images/kogito/drl/ConditionalElementAccumulate.svg new file mode 100644 index 0000000..fb7c551 --- /dev/null +++ b/_images/kogito/drl/ConditionalElementAccumulate.svg @@ -0,0 +1,50 @@ + +ConditionalElementAccumulate + + +accumulate + + + + +( + + + + +ConditionalAnd + + + + +, + + + + + + + + + + + + + + +Accumulations + + + + +) + + +ConditionalElementAccumulate + + + diff --git a/_images/kogito/drl/ConditionalElementEval.png b/_images/kogito/drl/ConditionalElementEval.png new file mode 100644 index 0000000..e86812b Binary files /dev/null and b/_images/kogito/drl/ConditionalElementEval.png differ diff --git a/_images/kogito/drl/ConditionalElementEval.svg b/_images/kogito/drl/ConditionalElementEval.svg new file mode 100644 index 0000000..c249e45 --- /dev/null +++ b/_images/kogito/drl/ConditionalElementEval.svg @@ -0,0 +1,30 @@ + +ConditionalElementEval + + +eval + + + + +( + + + + +ConditionalExpr + + + + +) + + +ConditionalElementEval + + + diff --git a/_images/kogito/drl/ConditionalElementExists.png b/_images/kogito/drl/ConditionalElementExists.png new file mode 100644 index 0000000..d67e5ea Binary files /dev/null and b/_images/kogito/drl/ConditionalElementExists.png differ diff --git a/_images/kogito/drl/ConditionalElementExists.svg b/_images/kogito/drl/ConditionalElementExists.svg new file mode 100644 index 0000000..0c493df --- /dev/null +++ b/_images/kogito/drl/ConditionalElementExists.svg @@ -0,0 +1,44 @@ + +ConditionalElementExists + + +exists + + + + + +BindingPattern + + +( + + + + +ConditionalOr + + + + +) + + + + + + + + + + + + +ConditionalElementExists + + + diff --git a/_images/kogito/drl/ConditionalElementForall.png b/_images/kogito/drl/ConditionalElementForall.png new file mode 100644 index 0000000..d4caa90 Binary files /dev/null and b/_images/kogito/drl/ConditionalElementForall.png differ diff --git a/_images/kogito/drl/ConditionalElementForall.svg b/_images/kogito/drl/ConditionalElementForall.svg new file mode 100644 index 0000000..372929a --- /dev/null +++ b/_images/kogito/drl/ConditionalElementForall.svg @@ -0,0 +1,40 @@ + +ConditionalElementForall + + +forall + + + + +( + + + + +BindingPattern + + + + + + + + + + + + + + +) + + +ConditionalElementForall + + + diff --git a/_images/kogito/drl/ConditionalElementNot.png b/_images/kogito/drl/ConditionalElementNot.png new file mode 100644 index 0000000..f7860d9 Binary files /dev/null and b/_images/kogito/drl/ConditionalElementNot.png differ diff --git a/_images/kogito/drl/ConditionalElementNot.svg b/_images/kogito/drl/ConditionalElementNot.svg new file mode 100644 index 0000000..6fcd522 --- /dev/null +++ b/_images/kogito/drl/ConditionalElementNot.svg @@ -0,0 +1,44 @@ + +ConditionalElementNot + + +not + + + + + +BindingPattern + + +( + + + + +ConditionalOr + + + + +) + + + + + + + + + + + + +ConditionalElementNot + + + diff --git a/_images/kogito/drl/ConditionalExpr.png b/_images/kogito/drl/ConditionalExpr.png new file mode 100644 index 0000000..0a6df0c Binary files /dev/null and b/_images/kogito/drl/ConditionalExpr.png differ diff --git a/_images/kogito/drl/ConditionalExpr.svg b/_images/kogito/drl/ConditionalExpr.svg new file mode 100644 index 0000000..7807819 --- /dev/null +++ b/_images/kogito/drl/ConditionalExpr.svg @@ -0,0 +1,46 @@ + +ConditionalExpr + + +ConditionalOrExpr + + + + +? + + + + +Expression + + + + +: + + + + +Expression + + + + + + + + + + + + + +ConditionalExpr + + + diff --git a/_images/kogito/drl/ConditionalOr.png b/_images/kogito/drl/ConditionalOr.png new file mode 100644 index 0000000..6d3019c Binary files /dev/null and b/_images/kogito/drl/ConditionalOr.png differ diff --git a/_images/kogito/drl/ConditionalOr.svg b/_images/kogito/drl/ConditionalOr.svg new file mode 100644 index 0000000..073285c --- /dev/null +++ b/_images/kogito/drl/ConditionalOr.svg @@ -0,0 +1,31 @@ + +ConditionalOr + + +ConditionalAnd + + + +or + + + + + + + + + + + + + + +ConditionalOr + + + diff --git a/_images/kogito/drl/ConditionalOrExpr.png b/_images/kogito/drl/ConditionalOrExpr.png new file mode 100644 index 0000000..336ae8b Binary files /dev/null and b/_images/kogito/drl/ConditionalOrExpr.png differ diff --git a/_images/kogito/drl/ConditionalOrExpr.svg b/_images/kogito/drl/ConditionalOrExpr.svg new file mode 100644 index 0000000..7f30c43 --- /dev/null +++ b/_images/kogito/drl/ConditionalOrExpr.svg @@ -0,0 +1,106 @@ + +ConditionalOrExpr + + +InstanceOfExpr + + +== + +!= + + + + + + + + + + + + + + + + + + + + + + +& + + + + + + + + + + + + +^ + + + + + + + + + + + + +| + + + + + + + + + + + + +&& + + + + + + + + + + + + +|| + + + + + + + + + + + + + +ConditionalOrExpr + + + diff --git a/_images/kogito/drl/Constraints.png b/_images/kogito/drl/Constraints.png new file mode 100644 index 0000000..85cc2ac Binary files /dev/null and b/_images/kogito/drl/Constraints.png differ diff --git a/_images/kogito/drl/Constraints.svg b/_images/kogito/drl/Constraints.svg new file mode 100644 index 0000000..dd12da5 --- /dev/null +++ b/_images/kogito/drl/Constraints.svg @@ -0,0 +1,72 @@ + +Constraints + + +ConditionalOrExpr + + +, + + + + + + + + + + + + + + +; + + + + + + + + + + + + + + +ConditionalOrExpr + + +, + + + + + + + + + + + + + + + + + + + + + + + +Constraints + + + diff --git a/_images/kogito/drl/CreatedName.png b/_images/kogito/drl/CreatedName.png new file mode 100644 index 0000000..3a2ef3e Binary files /dev/null and b/_images/kogito/drl/CreatedName.png differ diff --git a/_images/kogito/drl/CreatedName.svg b/_images/kogito/drl/CreatedName.svg new file mode 100644 index 0000000..e09e07f --- /dev/null +++ b/_images/kogito/drl/CreatedName.svg @@ -0,0 +1,59 @@ + +CreatedName + + +Identifier + + + + + +TypeArguments + + + + + + + + + + + + +. + + + + + + + + + + + + + +PrimitiveType + + + + + + + + + + + + + +CreatedName + + + diff --git a/_images/kogito/drl/Creator.png b/_images/kogito/drl/Creator.png new file mode 100644 index 0000000..520197c Binary files /dev/null and b/_images/kogito/drl/Creator.png differ diff --git a/_images/kogito/drl/Creator.svg b/_images/kogito/drl/Creator.svg new file mode 100644 index 0000000..e6a5e21 --- /dev/null +++ b/_images/kogito/drl/Creator.svg @@ -0,0 +1,52 @@ + +Creator + + +NonWildcardTypeArguments + + + + + + + + + + + + + + + +CreatedName + + + + + +ArrayCreatorRest + + + +Arguments + + + + + + + + + + + + + +Creator + + + diff --git a/_images/kogito/drl/Definition.png b/_images/kogito/drl/Definition.png new file mode 100644 index 0000000..b529d1c Binary files /dev/null and b/_images/kogito/drl/Definition.png differ diff --git a/_images/kogito/drl/Definition.svg b/_images/kogito/drl/Definition.svg new file mode 100644 index 0000000..6e5fd37 --- /dev/null +++ b/_images/kogito/drl/Definition.svg @@ -0,0 +1,65 @@ + +Definition + + +RuleAttribute + + + +ImportDefinition + + + +GlobalDefinition + + + +FunctionDefinition + + + +TypeDefinition + + + +RuleDefinition + + + +QueryDefinition + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Definition + + + diff --git a/_images/kogito/drl/Digit.png b/_images/kogito/drl/Digit.png new file mode 100644 index 0000000..3747d31 Binary files /dev/null and b/_images/kogito/drl/Digit.png differ diff --git a/_images/kogito/drl/Digit.svg b/_images/kogito/drl/Digit.svg new file mode 100644 index 0000000..a34dd54 --- /dev/null +++ b/_images/kogito/drl/Digit.svg @@ -0,0 +1,14 @@ + +Digit + +'0'..'9' + + +Digit + + + diff --git a/_images/kogito/drl/ExplicitGenericInvocation.png b/_images/kogito/drl/ExplicitGenericInvocation.png new file mode 100644 index 0000000..57436fc Binary files /dev/null and b/_images/kogito/drl/ExplicitGenericInvocation.png differ diff --git a/_images/kogito/drl/ExplicitGenericInvocation.svg b/_images/kogito/drl/ExplicitGenericInvocation.svg new file mode 100644 index 0000000..1ab0226 --- /dev/null +++ b/_images/kogito/drl/ExplicitGenericInvocation.svg @@ -0,0 +1,22 @@ + +ExplicitGenericInvocation + + +NonWildcardTypeArguments + + + + + +Arguments + + + +ExplicitGenericInvocation + + + diff --git a/_images/kogito/drl/ExplicitGenericInvocationSuffix.png b/_images/kogito/drl/ExplicitGenericInvocationSuffix.png new file mode 100644 index 0000000..ed1a101 Binary files /dev/null and b/_images/kogito/drl/ExplicitGenericInvocationSuffix.png differ diff --git a/_images/kogito/drl/ExplicitGenericInvocationSuffix.svg b/_images/kogito/drl/ExplicitGenericInvocationSuffix.svg new file mode 100644 index 0000000..16189df --- /dev/null +++ b/_images/kogito/drl/ExplicitGenericInvocationSuffix.svg @@ -0,0 +1,42 @@ + +ExplicitGenericInvocationSuffix + + +super + + + + + +SuperSuffix + + + +Identifier + + + + + +Arguments + + + + + + + + + + + + + +ExplicitGenericInvocationSuffix + + + diff --git a/_images/kogito/drl/Exponent.png b/_images/kogito/drl/Exponent.png new file mode 100644 index 0000000..6dadfb0 Binary files /dev/null and b/_images/kogito/drl/Exponent.png differ diff --git a/_images/kogito/drl/Exponent.svg b/_images/kogito/drl/Exponent.svg new file mode 100644 index 0000000..281aeb0 --- /dev/null +++ b/_images/kogito/drl/Exponent.svg @@ -0,0 +1,72 @@ + +Exponent + + +e + + + +E + + + + + + + + + + + + + + ++ + +- + + + + + + + + + + + + + + + + + + + + + + + + +Digit + + + + + + + + + + + + + +Exponent + + + diff --git a/_images/kogito/drl/Expression.png b/_images/kogito/drl/Expression.png new file mode 100644 index 0000000..5d48758 Binary files /dev/null and b/_images/kogito/drl/Expression.png differ diff --git a/_images/kogito/drl/Expression.svg b/_images/kogito/drl/Expression.svg new file mode 100644 index 0000000..83deb95 --- /dev/null +++ b/_images/kogito/drl/Expression.svg @@ -0,0 +1,38 @@ + +Expression + + +ConditionalExpr + + + + + +AssignmentOperator + + + + + +Expression + + + + + + + + + + + + + +Expression + + + diff --git a/_images/kogito/drl/ExpressionList.png b/_images/kogito/drl/ExpressionList.png new file mode 100644 index 0000000..cb3657d Binary files /dev/null and b/_images/kogito/drl/ExpressionList.png differ diff --git a/_images/kogito/drl/ExpressionList.svg b/_images/kogito/drl/ExpressionList.svg new file mode 100644 index 0000000..2405da4 --- /dev/null +++ b/_images/kogito/drl/ExpressionList.svg @@ -0,0 +1,29 @@ + +ExpressionList + + +Expression + + +, + + + + + + + + + + + + + +ExpressionList + + + diff --git a/_images/kogito/drl/Field.png b/_images/kogito/drl/Field.png new file mode 100644 index 0000000..1146dc1 Binary files /dev/null and b/_images/kogito/drl/Field.png differ diff --git a/_images/kogito/drl/Field.svg b/_images/kogito/drl/Field.svg new file mode 100644 index 0000000..2ea5389 --- /dev/null +++ b/_images/kogito/drl/Field.svg @@ -0,0 +1,74 @@ + +Field + + +Identifier + + + + +: + + + + +QualifiedName + + + + += + + + + +ConditionalExpr + + + + + + + + + + + + + + + +Annotation + + + + + + + + + + + + +; + + + + + + + + + + + + +Field + + + diff --git a/_images/kogito/drl/Fraction.png b/_images/kogito/drl/Fraction.png new file mode 100644 index 0000000..3235db0 Binary files /dev/null and b/_images/kogito/drl/Fraction.png differ diff --git a/_images/kogito/drl/Fraction.svg b/_images/kogito/drl/Fraction.svg new file mode 100644 index 0000000..bf5176d --- /dev/null +++ b/_images/kogito/drl/Fraction.svg @@ -0,0 +1,72 @@ + +Fraction + + +Digit + + + + + + + + + + + + + + +. + + + + +Digit + + + + + + + + + + +. + + + + +Digit + + + + + + + + + + + + + + + + + + + + + + + +Fraction + + + diff --git a/_images/kogito/drl/FromAccumulateClause.png b/_images/kogito/drl/FromAccumulateClause.png new file mode 100644 index 0000000..035a236 Binary files /dev/null and b/_images/kogito/drl/FromAccumulateClause.png differ diff --git a/_images/kogito/drl/FromAccumulateClause.svg b/_images/kogito/drl/FromAccumulateClause.svg new file mode 100644 index 0000000..0f14943 --- /dev/null +++ b/_images/kogito/drl/FromAccumulateClause.svg @@ -0,0 +1,22 @@ + +FromAccumulateClause + + +from + + + + + +AccumulateClause + + + +FromAccumulateClause + + + diff --git a/_images/kogito/drl/FromClause.png b/_images/kogito/drl/FromClause.png new file mode 100644 index 0000000..7218e1d Binary files /dev/null and b/_images/kogito/drl/FromClause.png differ diff --git a/_images/kogito/drl/FromClause.svg b/_images/kogito/drl/FromClause.svg new file mode 100644 index 0000000..2f98f0a --- /dev/null +++ b/_images/kogito/drl/FromClause.svg @@ -0,0 +1,22 @@ + +FromClause + + +from + + + + + +ConditionalOrExpr + + + +FromClause + + + diff --git a/_images/kogito/drl/FromCollectClause.png b/_images/kogito/drl/FromCollectClause.png new file mode 100644 index 0000000..16738e2 Binary files /dev/null and b/_images/kogito/drl/FromCollectClause.png differ diff --git a/_images/kogito/drl/FromCollectClause.svg b/_images/kogito/drl/FromCollectClause.svg new file mode 100644 index 0000000..9e8a2a2 --- /dev/null +++ b/_images/kogito/drl/FromCollectClause.svg @@ -0,0 +1,36 @@ + +FromCollectClause + + +from + + + + + +collect + + + + +( + + + + +SourcePattern + + + + +) + + +FromCollectClause + + + diff --git a/_images/kogito/drl/FunctionDefinition.png b/_images/kogito/drl/FunctionDefinition.png new file mode 100644 index 0000000..a08dfcb Binary files /dev/null and b/_images/kogito/drl/FunctionDefinition.png differ diff --git a/_images/kogito/drl/FunctionDefinition.svg b/_images/kogito/drl/FunctionDefinition.svg new file mode 100644 index 0000000..bfb877f --- /dev/null +++ b/_images/kogito/drl/FunctionDefinition.svg @@ -0,0 +1,50 @@ + +FunctionDefinition + + +function + + + + + +Type + + + + + + + + + + + + + + + +Identifier + + + + + +Parameters + + + + + +Block + + + +FunctionDefinition + + + diff --git a/_images/kogito/drl/GlobalDefinition.png b/_images/kogito/drl/GlobalDefinition.png new file mode 100644 index 0000000..2a2fcec Binary files /dev/null and b/_images/kogito/drl/GlobalDefinition.png differ diff --git a/_images/kogito/drl/GlobalDefinition.svg b/_images/kogito/drl/GlobalDefinition.svg new file mode 100644 index 0000000..601e8e8 --- /dev/null +++ b/_images/kogito/drl/GlobalDefinition.svg @@ -0,0 +1,28 @@ + +GlobalDefinition + + +global + + + + + +Type + + + + + +Identifier + + + +GlobalDefinition + + + diff --git a/_images/kogito/drl/IdentifierSuffix.png b/_images/kogito/drl/IdentifierSuffix.png new file mode 100644 index 0000000..3b6c577 Binary files /dev/null and b/_images/kogito/drl/IdentifierSuffix.png differ diff --git a/_images/kogito/drl/IdentifierSuffix.svg b/_images/kogito/drl/IdentifierSuffix.svg new file mode 100644 index 0000000..33dce6a --- /dev/null +++ b/_images/kogito/drl/IdentifierSuffix.svg @@ -0,0 +1,77 @@ + +IdentifierSuffix + +[ + + + +] + + + + + + + + + + + + + +. + + + + +class + + +[ + + + + +Expression + + + + +] + + + + + + + + + + + + +Arguments + + + + + + + + + + + + + + + + +IdentifierSuffix + + + diff --git a/_images/kogito/drl/ImportDefinition.png b/_images/kogito/drl/ImportDefinition.png new file mode 100644 index 0000000..06e9058 Binary files /dev/null and b/_images/kogito/drl/ImportDefinition.png differ diff --git a/_images/kogito/drl/ImportDefinition.svg b/_images/kogito/drl/ImportDefinition.svg new file mode 100644 index 0000000..d0acf13 --- /dev/null +++ b/_images/kogito/drl/ImportDefinition.svg @@ -0,0 +1,70 @@ + +ImportDefinition + + +import + + + + + +function + + + +static + + + + + + + + + + + + + + + + + + + + + + + + + +QualifiedName + + + + +. + + + +* + + + + + + + + + + + + +ImportDefinition + + + diff --git a/_images/kogito/drl/InExpr.png b/_images/kogito/drl/InExpr.png new file mode 100644 index 0000000..290282b Binary files /dev/null and b/_images/kogito/drl/InExpr.png differ diff --git a/_images/kogito/drl/InExpr.svg b/_images/kogito/drl/InExpr.svg new file mode 100644 index 0000000..9bf64ca --- /dev/null +++ b/_images/kogito/drl/InExpr.svg @@ -0,0 +1,65 @@ + +InExpr + + +RelationalExpr + + + + + +not + + + + + + + + + + + + + + + +in + + + + +( + + + + +Expression + + +, + + + + + + + + + + + + + + +) + + +InExpr + + + diff --git a/_images/kogito/drl/InlineListExpr.png b/_images/kogito/drl/InlineListExpr.png new file mode 100644 index 0000000..10703bd Binary files /dev/null and b/_images/kogito/drl/InlineListExpr.png differ diff --git a/_images/kogito/drl/InlineListExpr.svg b/_images/kogito/drl/InlineListExpr.svg new file mode 100644 index 0000000..4154171 --- /dev/null +++ b/_images/kogito/drl/InlineListExpr.svg @@ -0,0 +1,34 @@ + +InlineListExpr + +[ + + + + +ExpressionList + + + + + + + + + + + + + + +] + + +InlineListExpr + + + diff --git a/_images/kogito/drl/InlineMapExpr.png b/_images/kogito/drl/InlineMapExpr.png new file mode 100644 index 0000000..2cfc255 Binary files /dev/null and b/_images/kogito/drl/InlineMapExpr.png differ diff --git a/_images/kogito/drl/InlineMapExpr.svg b/_images/kogito/drl/InlineMapExpr.svg new file mode 100644 index 0000000..04610e6 --- /dev/null +++ b/_images/kogito/drl/InlineMapExpr.svg @@ -0,0 +1,47 @@ + +InlineMapExpr + +[ + + + + +Expression + + + + +: + + + + +Expression + + +, + + + + + + + + + + + + + + +] + + +InlineMapExpr + + + diff --git a/_images/kogito/drl/InnerCreator.png b/_images/kogito/drl/InnerCreator.png new file mode 100644 index 0000000..e5847c5 Binary files /dev/null and b/_images/kogito/drl/InnerCreator.png differ diff --git a/_images/kogito/drl/InnerCreator.svg b/_images/kogito/drl/InnerCreator.svg new file mode 100644 index 0000000..f026ccc --- /dev/null +++ b/_images/kogito/drl/InnerCreator.svg @@ -0,0 +1,22 @@ + +InnerCreator + + +Identifier + + + + + +Arguments + + + +InnerCreator + + + diff --git a/_images/kogito/drl/InstanceOfExpr.png b/_images/kogito/drl/InstanceOfExpr.png new file mode 100644 index 0000000..9733dd3 Binary files /dev/null and b/_images/kogito/drl/InstanceOfExpr.png differ diff --git a/_images/kogito/drl/InstanceOfExpr.svg b/_images/kogito/drl/InstanceOfExpr.svg new file mode 100644 index 0000000..56cd059 --- /dev/null +++ b/_images/kogito/drl/InstanceOfExpr.svg @@ -0,0 +1,38 @@ + +InstanceOfExpr + + +InExpr + + + + + +instanceof + + + + + +Type + + + + + + + + + + + + + +InstanceOfExpr + + + diff --git a/_images/kogito/drl/IntLiteral.png b/_images/kogito/drl/IntLiteral.png new file mode 100644 index 0000000..354ff13 Binary files /dev/null and b/_images/kogito/drl/IntLiteral.png differ diff --git a/_images/kogito/drl/IntLiteral.svg b/_images/kogito/drl/IntLiteral.svg new file mode 100644 index 0000000..b40f5d8 --- /dev/null +++ b/_images/kogito/drl/IntLiteral.svg @@ -0,0 +1,99 @@ + +IntLiteral + ++ + +- + + + + + + + + + + + + + + + + + + + + + + + + +Digit + + + + + + + + + + + + + +0x + + + + + +Digit + + +'a'..'f' + +'A'..'F' + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +IntLiteral + + + diff --git a/_images/kogito/drl/Literal.png b/_images/kogito/drl/Literal.png new file mode 100644 index 0000000..9d981a2 Binary files /dev/null and b/_images/kogito/drl/Literal.png differ diff --git a/_images/kogito/drl/Literal.svg b/_images/kogito/drl/Literal.svg new file mode 100644 index 0000000..5d97f53 --- /dev/null +++ b/_images/kogito/drl/Literal.svg @@ -0,0 +1,44 @@ + +Literal + + +IntLiteral + + + +RealLiteral + + + +BooleanLiteral + + + +StringLiteral + + + + + + + + + + + + + + + + + + + +Literal + + + diff --git a/_images/kogito/drl/ModifyStatement.png b/_images/kogito/drl/ModifyStatement.png new file mode 100644 index 0000000..35dcbf9 Binary files /dev/null and b/_images/kogito/drl/ModifyStatement.png differ diff --git a/_images/kogito/drl/ModifyStatement.svg b/_images/kogito/drl/ModifyStatement.svg new file mode 100644 index 0000000..a0c6a31 --- /dev/null +++ b/_images/kogito/drl/ModifyStatement.svg @@ -0,0 +1,65 @@ + +ModifyStatement + + +modify + + + + +( + + + + +ConditionalExpr + + + + +) + + + +{ + + + + +ConditionalExpr + + +, + + + + + + + + + + + + + + + + + + + + + + +} + + +ModifyStatement + + + diff --git a/_images/kogito/drl/NonWildcardTypeArguments.png b/_images/kogito/drl/NonWildcardTypeArguments.png new file mode 100644 index 0000000..4438e12 Binary files /dev/null and b/_images/kogito/drl/NonWildcardTypeArguments.png differ diff --git a/_images/kogito/drl/NonWildcardTypeArguments.svg b/_images/kogito/drl/NonWildcardTypeArguments.svg new file mode 100644 index 0000000..5a30a71 --- /dev/null +++ b/_images/kogito/drl/NonWildcardTypeArguments.svg @@ -0,0 +1,37 @@ + +NonWildcardTypeArguments + +< + + + + +Type + + +, + + + + + + + + + + + + + + +> + + +NonWildcardTypeArguments + + + diff --git a/_images/kogito/drl/OrRestriction.png b/_images/kogito/drl/OrRestriction.png new file mode 100644 index 0000000..6eaec20 Binary files /dev/null and b/_images/kogito/drl/OrRestriction.png differ diff --git a/_images/kogito/drl/OrRestriction.svg b/_images/kogito/drl/OrRestriction.svg new file mode 100644 index 0000000..0662137 --- /dev/null +++ b/_images/kogito/drl/OrRestriction.svg @@ -0,0 +1,42 @@ + +OrRestriction + + +SingleRestriction + + +&& + + + + + + + + + + + + +|| + + + + + + + + + + + + + +OrRestriction + + + diff --git a/_images/kogito/drl/OverClause.png b/_images/kogito/drl/OverClause.png new file mode 100644 index 0000000..e4a24a9 Binary files /dev/null and b/_images/kogito/drl/OverClause.png differ diff --git a/_images/kogito/drl/OverClause.svg b/_images/kogito/drl/OverClause.svg new file mode 100644 index 0000000..b723545 --- /dev/null +++ b/_images/kogito/drl/OverClause.svg @@ -0,0 +1,69 @@ + +OverClause + + +over + + + + + +Identifier + + + + +: + + + + +Identifier + + + + +( + + + + +ConditionalExpr + + +, + + + + + + + + + + + + + + + + + + + + + + + + +) + + +OverClause + + + diff --git a/_images/kogito/drl/Parameters.png b/_images/kogito/drl/Parameters.png new file mode 100644 index 0000000..fd3475c Binary files /dev/null and b/_images/kogito/drl/Parameters.png differ diff --git a/_images/kogito/drl/Parameters.svg b/_images/kogito/drl/Parameters.svg new file mode 100644 index 0000000..bac5792 --- /dev/null +++ b/_images/kogito/drl/Parameters.svg @@ -0,0 +1,69 @@ + +Parameters + +( + + + + +Type + + + + + +Identifier + + + + +[ + + + +] + + + + + + + + + +, + + + + + + + + + + + + + + + + + + + + + + + + +) + + +Parameters + + + diff --git a/_images/kogito/drl/Pattern.png b/_images/kogito/drl/Pattern.png new file mode 100644 index 0000000..7437a5a Binary files /dev/null and b/_images/kogito/drl/Pattern.png differ diff --git a/_images/kogito/drl/Pattern.vsd b/_images/kogito/drl/Pattern.vsd new file mode 100644 index 0000000..84ff4c1 Binary files /dev/null and b/_images/kogito/drl/Pattern.vsd differ diff --git a/_images/kogito/drl/Placeholders.png b/_images/kogito/drl/Placeholders.png new file mode 100644 index 0000000..8f47d1e Binary files /dev/null and b/_images/kogito/drl/Placeholders.png differ diff --git a/_images/kogito/drl/Placeholders.svg b/_images/kogito/drl/Placeholders.svg new file mode 100644 index 0000000..799cbd9 --- /dev/null +++ b/_images/kogito/drl/Placeholders.svg @@ -0,0 +1,47 @@ + +Placeholders + +( + + + + +Identifier + + +, + + + + + + + + + + + + + + + + + + + + + + + + +) + + +Placeholders + + + diff --git a/_images/kogito/drl/Primary.png b/_images/kogito/drl/Primary.png new file mode 100644 index 0000000..ce9bdaf Binary files /dev/null and b/_images/kogito/drl/Primary.png differ diff --git a/_images/kogito/drl/Primary.svg b/_images/kogito/drl/Primary.svg new file mode 100644 index 0000000..58b0462 --- /dev/null +++ b/_images/kogito/drl/Primary.svg @@ -0,0 +1,204 @@ + +Primary + +( + + + + +Expression + + + + +) + + +NonWildcardTypeArguments + + + + + +ExplicitGenericInvocationSuffix + + + +this + + + + + +Arguments + + + + + + + + + + + + + +Literal + + + +super + + + + + +SuperSuffix + + + +new + + + + + +Creator + + + +PrimitiveType + + + + +[ + + + +] + + + + + + + + + + + +. + + + + +class + + + +void + + + + +. + + + + +class + + + +this + + + +InlineMapExpr + + + +InlineListExpr + + + +Identifier + + +. + + + + + + + + + + + + + + + +IdentifierSuffix + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Primary + + + diff --git a/_images/kogito/drl/PrimitiveType.png b/_images/kogito/drl/PrimitiveType.png new file mode 100644 index 0000000..8e14836 Binary files /dev/null and b/_images/kogito/drl/PrimitiveType.png differ diff --git a/_images/kogito/drl/PrimitiveType.svg b/_images/kogito/drl/PrimitiveType.svg new file mode 100644 index 0000000..2eba75f --- /dev/null +++ b/_images/kogito/drl/PrimitiveType.svg @@ -0,0 +1,72 @@ + +PrimitiveType + + +boolean + + + +char + + + +byte + + + +short + + + +int + + + +long + + + +float + + + +double + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +PrimitiveType + + + diff --git a/_images/kogito/drl/QualifiedName.png b/_images/kogito/drl/QualifiedName.png new file mode 100644 index 0000000..a651fe8 Binary files /dev/null and b/_images/kogito/drl/QualifiedName.png differ diff --git a/_images/kogito/drl/QualifiedName.svg b/_images/kogito/drl/QualifiedName.svg new file mode 100644 index 0000000..13f1147 --- /dev/null +++ b/_images/kogito/drl/QualifiedName.svg @@ -0,0 +1,29 @@ + +QualifiedName + + +Identifier + + +. + + + + + + + + + + + + + +QualifiedName + + + diff --git a/_images/kogito/drl/QueryDefinition.png b/_images/kogito/drl/QueryDefinition.png new file mode 100644 index 0000000..b3a0ce4 Binary files /dev/null and b/_images/kogito/drl/QueryDefinition.png differ diff --git a/_images/kogito/drl/QueryDefinition.svg b/_images/kogito/drl/QueryDefinition.svg new file mode 100644 index 0000000..4de0108 --- /dev/null +++ b/_images/kogito/drl/QueryDefinition.svg @@ -0,0 +1,48 @@ + +QueryDefinition + + +query + + + + + +StringId + + + + + +QueryOptions + + + + + +ConditionalOr + + + + + + + + + + + + + +end + + + +QueryDefinition + + + diff --git a/_images/kogito/drl/QueryOptions.png b/_images/kogito/drl/QueryOptions.png new file mode 100644 index 0000000..9fe87dc Binary files /dev/null and b/_images/kogito/drl/QueryOptions.png differ diff --git a/_images/kogito/drl/QueryOptions.svg b/_images/kogito/drl/QueryOptions.svg new file mode 100644 index 0000000..ca0edfb --- /dev/null +++ b/_images/kogito/drl/QueryOptions.svg @@ -0,0 +1,54 @@ + +QueryOptions + + +Parameters + + + +Placeholders + + + + + + + + + + + + + + + + + + + + + + + + + +Annotation + + + + + + + + + + + +QueryOptions + + + diff --git a/_images/kogito/drl/RealLiteral.png b/_images/kogito/drl/RealLiteral.png new file mode 100644 index 0000000..d1fca60 Binary files /dev/null and b/_images/kogito/drl/RealLiteral.png differ diff --git a/_images/kogito/drl/RealLiteral.svg b/_images/kogito/drl/RealLiteral.svg new file mode 100644 index 0000000..55e14ef --- /dev/null +++ b/_images/kogito/drl/RealLiteral.svg @@ -0,0 +1,134 @@ + +RealLiteral + ++ + +- + + + + + + + + + + + + + + + + + + + + + + + + +Fraction + + + + + +Exponent + + + + + + + + + + + + + +Digit + + + + + + + + + + + + + + + +Exponent + + + + + + + + + + + + + + + +RealTypeSuffix + + + + + + + + + + + + + +Digit + + + + + + + + + + + + + + + +RealTypeSuffix + + + + + + + + + + + + + +RealLiteral + + + diff --git a/_images/kogito/drl/RealTypeSuffix.png b/_images/kogito/drl/RealTypeSuffix.png new file mode 100644 index 0000000..9305d08 Binary files /dev/null and b/_images/kogito/drl/RealTypeSuffix.png differ diff --git a/_images/kogito/drl/RealTypeSuffix.svg b/_images/kogito/drl/RealTypeSuffix.svg new file mode 100644 index 0000000..d2e1646 --- /dev/null +++ b/_images/kogito/drl/RealTypeSuffix.svg @@ -0,0 +1,44 @@ + +RealTypeSuffix + + +f + + + +F + + + +d + + + +D + + + + + + + + + + + + + + + + + + + +RealTypeSuffix + + + diff --git a/_images/kogito/drl/RelationalExpr.png b/_images/kogito/drl/RelationalExpr.png new file mode 100644 index 0000000..1775ed9 Binary files /dev/null and b/_images/kogito/drl/RelationalExpr.png differ diff --git a/_images/kogito/drl/RelationalExpr.svg b/_images/kogito/drl/RelationalExpr.svg new file mode 100644 index 0000000..f4f379f --- /dev/null +++ b/_images/kogito/drl/RelationalExpr.svg @@ -0,0 +1,30 @@ + +RelationalExpr + + +ShiftExpr + + + + + +OrRestriction + + + + + + + + + + + +RelationalExpr + + + diff --git a/_images/kogito/drl/RelationalOperator.png b/_images/kogito/drl/RelationalOperator.png new file mode 100644 index 0000000..8f22b6a Binary files /dev/null and b/_images/kogito/drl/RelationalOperator.png differ diff --git a/_images/kogito/drl/RelationalOperator.svg b/_images/kogito/drl/RelationalOperator.svg new file mode 100644 index 0000000..3260874 --- /dev/null +++ b/_images/kogito/drl/RelationalOperator.svg @@ -0,0 +1,103 @@ + +RelationalOperator + +== + +!= + +<= + +>= + +< + +> + + +not + + + + + + + + + + + + + + + +Identifier + + + + +[ + + + + +ExpressionList + + + + + + + + + + + + + + +] + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +RelationalOperator + + + diff --git a/_images/kogito/drl/RhsStatement.png b/_images/kogito/drl/RhsStatement.png new file mode 100644 index 0000000..bab85bc Binary files /dev/null and b/_images/kogito/drl/RhsStatement.png differ diff --git a/_images/kogito/drl/RhsStatement.svg b/_images/kogito/drl/RhsStatement.svg new file mode 100644 index 0000000..61d3469 --- /dev/null +++ b/_images/kogito/drl/RhsStatement.svg @@ -0,0 +1,30 @@ + +RhsStatement + + +ModifyStatement + + + +Statement + + + + + + + + + + + + + +RhsStatement + + + diff --git a/_images/kogito/drl/RuleAttribute.png b/_images/kogito/drl/RuleAttribute.png new file mode 100644 index 0000000..c386af4 Binary files /dev/null and b/_images/kogito/drl/RuleAttribute.png differ diff --git a/_images/kogito/drl/RuleAttribute.svg b/_images/kogito/drl/RuleAttribute.svg new file mode 100644 index 0000000..e2ae931 --- /dev/null +++ b/_images/kogito/drl/RuleAttribute.svg @@ -0,0 +1,172 @@ + +RuleAttribute + + +salience + + + + + +ConditionalExpr + + + +enabled + + + + + +ConditionalExpr + + +auto-focus + +no-loop + +lock-on-active + + + + + + + + + + + + + + + + + +BooleanLiteral + + + + + + + + + + + + +agenda-group + +activation-group + +date-effective + +date-expires + + +dialect + + +ruleflow-group + + + + + + + + + + + + + + + + + + + + + + + + + + +StringLiteral + + + +timer + + + + +( + + + + +Tokens + + + + +) + + +calendars + + + + + +StringLiteral + + +, + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +RuleAttribute + + + diff --git a/_images/kogito/drl/RuleAttributes.png b/_images/kogito/drl/RuleAttributes.png new file mode 100644 index 0000000..caa0656 Binary files /dev/null and b/_images/kogito/drl/RuleAttributes.png differ diff --git a/_images/kogito/drl/RuleAttributes.svg b/_images/kogito/drl/RuleAttributes.svg new file mode 100644 index 0000000..8b84224 --- /dev/null +++ b/_images/kogito/drl/RuleAttributes.svg @@ -0,0 +1,79 @@ + +RuleAttributes + + +attributes + + + + +: + + + + + + + + + + + + + + + + + + + + + + + + +RuleAttribute + + +, + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +RuleAttributes + + + diff --git a/_images/kogito/drl/RuleDefinition.png b/_images/kogito/drl/RuleDefinition.png new file mode 100644 index 0000000..1808ad0 Binary files /dev/null and b/_images/kogito/drl/RuleDefinition.png differ diff --git a/_images/kogito/drl/RuleDefinition.svg b/_images/kogito/drl/RuleDefinition.svg new file mode 100644 index 0000000..923f0f3 --- /dev/null +++ b/_images/kogito/drl/RuleDefinition.svg @@ -0,0 +1,50 @@ + +RuleDefinition + + +rule + + + + + +StringId + + + + + +RuleOptions + + + + + +WhenPart + + + + + + + + + + + + + + + +ThenPart + + + +RuleDefinition + + + diff --git a/_images/kogito/drl/RuleOptions.png b/_images/kogito/drl/RuleOptions.png new file mode 100644 index 0000000..49660ae Binary files /dev/null and b/_images/kogito/drl/RuleOptions.png differ diff --git a/_images/kogito/drl/RuleOptions.svg b/_images/kogito/drl/RuleOptions.svg new file mode 100644 index 0000000..56a2632 --- /dev/null +++ b/_images/kogito/drl/RuleOptions.svg @@ -0,0 +1,62 @@ + +RuleOptions + + +extends + + + + + +StringId + + + + + + + + + + + + + + + +Annotation + + + + + + + + + + + + + +RuleAttributes + + + + + + + + + + + + + +RuleOptions + + + diff --git a/_images/kogito/drl/Selector.png b/_images/kogito/drl/Selector.png new file mode 100644 index 0000000..462079f Binary files /dev/null and b/_images/kogito/drl/Selector.png differ diff --git a/_images/kogito/drl/Selector.svg b/_images/kogito/drl/Selector.svg new file mode 100644 index 0000000..0973930 --- /dev/null +++ b/_images/kogito/drl/Selector.svg @@ -0,0 +1,108 @@ + +Selector + +. + + + + +super + + + + + +SuperSuffix + + +. + + + + +new + + + + + +NonWildcardTypeArguments + + + + + + + + + + + + + + + +InnerCreator + + +. + + + + +Identifier + + + + + +Arguments + + + + + + + + + + + + +[ + + + + +Expression + + + + +] + + + + + + + + + + + + + + + + + + +Selector + + + diff --git a/_images/kogito/drl/ShiftExpr.png b/_images/kogito/drl/ShiftExpr.png new file mode 100644 index 0000000..c16e42f Binary files /dev/null and b/_images/kogito/drl/ShiftExpr.png differ diff --git a/_images/kogito/drl/ShiftExpr.svg b/_images/kogito/drl/ShiftExpr.svg new file mode 100644 index 0000000..b3f2afa --- /dev/null +++ b/_images/kogito/drl/ShiftExpr.svg @@ -0,0 +1,46 @@ + +ShiftExpr + + +AdditiveExpr + + +<< + +>> + +>>> + + + + + + + + + + + + + + + + + + + + + + + + + + +ShiftExpr + + + diff --git a/_images/kogito/drl/SingleRestriction.png b/_images/kogito/drl/SingleRestriction.png new file mode 100644 index 0000000..30f5703 Binary files /dev/null and b/_images/kogito/drl/SingleRestriction.png differ diff --git a/_images/kogito/drl/SingleRestriction.svg b/_images/kogito/drl/SingleRestriction.svg new file mode 100644 index 0000000..00e1ee8 --- /dev/null +++ b/_images/kogito/drl/SingleRestriction.svg @@ -0,0 +1,44 @@ + +SingleRestriction + + +RelationalOperator + + + + + +ShiftExpr + + +( + + + + +OrRestriction + + + + +) + + + + + + + + + + + + +SingleRestriction + + + diff --git a/_images/kogito/drl/SourcePattern.png b/_images/kogito/drl/SourcePattern.png new file mode 100644 index 0000000..924bc8e Binary files /dev/null and b/_images/kogito/drl/SourcePattern.png differ diff --git a/_images/kogito/drl/SourcePattern.svg b/_images/kogito/drl/SourcePattern.svg new file mode 100644 index 0000000..c6640d1 --- /dev/null +++ b/_images/kogito/drl/SourcePattern.svg @@ -0,0 +1,100 @@ + +SourcePattern + + +Pattern + + + + + +OverClause + + + + + + + + + + + + + + + +from + + + + + +ConditionalOrExpr + + + +collect + + + + +( + + + + +BindingPattern + + + + +) + +entry-point + + + + +StringId + + + +AccumulateClause + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +SourcePattern + + + diff --git a/_images/kogito/drl/StringId.png b/_images/kogito/drl/StringId.png new file mode 100644 index 0000000..8b2097e Binary files /dev/null and b/_images/kogito/drl/StringId.png differ diff --git a/_images/kogito/drl/StringId.svg b/_images/kogito/drl/StringId.svg new file mode 100644 index 0000000..fdaaa2b --- /dev/null +++ b/_images/kogito/drl/StringId.svg @@ -0,0 +1,30 @@ + +StringId + + +Identifier + + + +StringLiteral + + + + + + + + + + + + + +StringId + + + diff --git a/_images/kogito/drl/SuperSuffix.png b/_images/kogito/drl/SuperSuffix.png new file mode 100644 index 0000000..7cdfdb6 Binary files /dev/null and b/_images/kogito/drl/SuperSuffix.png differ diff --git a/_images/kogito/drl/SuperSuffix.svg b/_images/kogito/drl/SuperSuffix.svg new file mode 100644 index 0000000..c6bca41 --- /dev/null +++ b/_images/kogito/drl/SuperSuffix.svg @@ -0,0 +1,50 @@ + +SuperSuffix + + +Arguments + + +. + + + + +Identifier + + + + + +Arguments + + + + + + + + + + + + + + + + + + + + + + + +SuperSuffix + + + diff --git a/_images/kogito/drl/ThenPart.png b/_images/kogito/drl/ThenPart.png new file mode 100644 index 0000000..86c008a Binary files /dev/null and b/_images/kogito/drl/ThenPart.png differ diff --git a/_images/kogito/drl/ThenPart.svg b/_images/kogito/drl/ThenPart.svg new file mode 100644 index 0000000..37dcbfb --- /dev/null +++ b/_images/kogito/drl/ThenPart.svg @@ -0,0 +1,36 @@ + +ThenPart + + +then + + + + + +RhsStatement + + + + + + + + + + + + + +end + + + +ThenPart + + + diff --git a/_images/kogito/drl/Type.png b/_images/kogito/drl/Type.png new file mode 100644 index 0000000..f68ab06 Binary files /dev/null and b/_images/kogito/drl/Type.png differ diff --git a/_images/kogito/drl/Type.svg b/_images/kogito/drl/Type.svg new file mode 100644 index 0000000..f5eb84e --- /dev/null +++ b/_images/kogito/drl/Type.svg @@ -0,0 +1,91 @@ + +Type + + +PrimitiveType + + + + +[ + + + +] + + + + + + + + + + +Identifier + + + + + +TypeArguments + + + + + + + + + + + + +. + + + + + + + + + + + + + + +[ + + + +] + + + + + + + + + + + + + + + + + + + + +Type + + + diff --git a/_images/kogito/drl/TypeArgument.png b/_images/kogito/drl/TypeArgument.png new file mode 100644 index 0000000..13e81e7 Binary files /dev/null and b/_images/kogito/drl/TypeArgument.png differ diff --git a/_images/kogito/drl/TypeArgument.svg b/_images/kogito/drl/TypeArgument.svg new file mode 100644 index 0000000..04136d7 --- /dev/null +++ b/_images/kogito/drl/TypeArgument.svg @@ -0,0 +1,64 @@ + +TypeArgument + + +Type + + +? + + + + +extends + + + +super + + + + + + + + + + + + + + + +Type + + + + + + + + + + + + + + + + + + + + + + + +TypeArgument + + + diff --git a/_images/kogito/drl/TypeArguments.png b/_images/kogito/drl/TypeArguments.png new file mode 100644 index 0000000..8cf0906 Binary files /dev/null and b/_images/kogito/drl/TypeArguments.png differ diff --git a/_images/kogito/drl/TypeArguments.svg b/_images/kogito/drl/TypeArguments.svg new file mode 100644 index 0000000..7cab349 --- /dev/null +++ b/_images/kogito/drl/TypeArguments.svg @@ -0,0 +1,37 @@ + +TypeArguments + +< + + + + +TypeArgument + + +, + + + + + + + + + + + + + + +> + + +TypeArguments + + + diff --git a/_images/kogito/drl/TypeDefinition.png b/_images/kogito/drl/TypeDefinition.png new file mode 100644 index 0000000..4b7f867 Binary files /dev/null and b/_images/kogito/drl/TypeDefinition.png differ diff --git a/_images/kogito/drl/TypeDefinition.svg b/_images/kogito/drl/TypeDefinition.svg new file mode 100644 index 0000000..e3687f3 --- /dev/null +++ b/_images/kogito/drl/TypeDefinition.svg @@ -0,0 +1,48 @@ + +TypeDefinition + + +declare + + + + + +QualifiedName + + + + + +TypeOptions + + + + + +Field + + + + + + + + + + + + + +end + + + +TypeDefinition + + + diff --git a/_images/kogito/drl/TypeOptions.png b/_images/kogito/drl/TypeOptions.png new file mode 100644 index 0000000..1829990 Binary files /dev/null and b/_images/kogito/drl/TypeOptions.png differ diff --git a/_images/kogito/drl/TypeOptions.svg b/_images/kogito/drl/TypeOptions.svg new file mode 100644 index 0000000..5b7c221 --- /dev/null +++ b/_images/kogito/drl/TypeOptions.svg @@ -0,0 +1,46 @@ + +TypeOptions + + +extends + + + + + +QualifiedName + + + + + + + + + + + + + + + +Annotation + + + + + + + + + + + +TypeOptions + + + diff --git a/_images/kogito/drl/UnaryExpr.png b/_images/kogito/drl/UnaryExpr.png new file mode 100644 index 0000000..d8328e7 Binary files /dev/null and b/_images/kogito/drl/UnaryExpr.png differ diff --git a/_images/kogito/drl/UnaryExpr.svg b/_images/kogito/drl/UnaryExpr.svg new file mode 100644 index 0000000..8303de3 --- /dev/null +++ b/_images/kogito/drl/UnaryExpr.svg @@ -0,0 +1,69 @@ + +UnaryExpr + ++ + +- + + + + + + + + + + + + + + +UnaryExpr + + +++ + +-- + + + + + + + + + + + + + + +Primary + + + +UnaryExprNotPlusMinus + + + + + + + + + + + + + + + + +UnaryExpr + + + diff --git a/_images/kogito/drl/UnaryExprNotPlusMinus.png b/_images/kogito/drl/UnaryExprNotPlusMinus.png new file mode 100644 index 0000000..e594739 Binary files /dev/null and b/_images/kogito/drl/UnaryExprNotPlusMinus.png differ diff --git a/_images/kogito/drl/UnaryExprNotPlusMinus.svg b/_images/kogito/drl/UnaryExprNotPlusMinus.svg new file mode 100644 index 0000000..0b8bdb2 --- /dev/null +++ b/_images/kogito/drl/UnaryExprNotPlusMinus.svg @@ -0,0 +1,133 @@ + +UnaryExprNotPlusMinus + +~ + +! + +( + + + + +PrimitiveType + + + +Type + + + + + + + + + + + + + + +) + + + + + + + + + + + + + + + + + +UnaryExpr + + + +Identifier + + + + +: + +:= + + + + + + + + + + + + + + + + + + + + + + + + +Primary + + + + +++ + +-- + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +UnaryExprNotPlusMinus + + + diff --git a/_images/kogito/drl/Value.png b/_images/kogito/drl/Value.png new file mode 100644 index 0000000..a0350cb Binary files /dev/null and b/_images/kogito/drl/Value.png differ diff --git a/_images/kogito/drl/Value.svg b/_images/kogito/drl/Value.svg new file mode 100644 index 0000000..28dffa8 --- /dev/null +++ b/_images/kogito/drl/Value.svg @@ -0,0 +1,61 @@ + +Value + +{ + + + + +Value + + +, + + + + + + + + + + + + + + + + + + + + + + + + +} + + +ConditionalExpr + + + + + + + + + + + + + +Value + + + diff --git a/_images/kogito/drl/VariableInitializer.png b/_images/kogito/drl/VariableInitializer.png new file mode 100644 index 0000000..11a63ae Binary files /dev/null and b/_images/kogito/drl/VariableInitializer.png differ diff --git a/_images/kogito/drl/VariableInitializer.svg b/_images/kogito/drl/VariableInitializer.svg new file mode 100644 index 0000000..d6606f2 --- /dev/null +++ b/_images/kogito/drl/VariableInitializer.svg @@ -0,0 +1,30 @@ + +VariableInitializer + + +ArrayInitializer + + + +Expression + + + + + + + + + + + + + +VariableInitializer + + + diff --git a/_images/kogito/drl/WhenPart.png b/_images/kogito/drl/WhenPart.png new file mode 100644 index 0000000..251dc1e Binary files /dev/null and b/_images/kogito/drl/WhenPart.png differ diff --git a/_images/kogito/drl/WhenPart.svg b/_images/kogito/drl/WhenPart.svg new file mode 100644 index 0000000..14cf2bf --- /dev/null +++ b/_images/kogito/drl/WhenPart.svg @@ -0,0 +1,44 @@ + +WhenPart + + +when + + + + +: + + + + + + + + + + + + + + +ConditionalOr + + + + + + + + + + + +WhenPart + + + diff --git a/_images/kogito/drl/abbreviatedCombinedRelationCondition.png b/_images/kogito/drl/abbreviatedCombinedRelationCondition.png new file mode 100644 index 0000000..bbf7cfe Binary files /dev/null and b/_images/kogito/drl/abbreviatedCombinedRelationCondition.png differ diff --git a/_images/kogito/drl/abbreviatedCombinedRelationCondition.svg b/_images/kogito/drl/abbreviatedCombinedRelationCondition.svg new file mode 100644 index 0000000..3fd5705 --- /dev/null +++ b/_images/kogito/drl/abbreviatedCombinedRelationCondition.svg @@ -0,0 +1,141 @@ + + + + + + + + + + + + + + + + + + Page-1 + + + + + On-page reference.60 + + + + + + + + Process.61 + restriction + + + + + + + + + + + + restriction + + Dynamic connector.64 + + + + Dynamic connector.65 + + + + On-page reference.68 + + + + + + + + Process.69 + ‘&&’ | ‘||’ + + + + + + + + + + + + ‘&&’ | ‘||’ + + Dynamic connector.144 + + + + Dynamic connector.145 + + + + Dynamic connector.146 + + + + Process.29 + restrictionGroup + + + + + + + + + + + + restrictionGroup + + Dynamic connector.30 + + + + Dynamic connector.31 + + + + Dynamic connector.32 + + + + Dynamic connector.33 + + + + diff --git a/_images/kogito/drl/abbreviatedCombinedRelationConditionGroup.png b/_images/kogito/drl/abbreviatedCombinedRelationConditionGroup.png new file mode 100644 index 0000000..7b5adf2 Binary files /dev/null and b/_images/kogito/drl/abbreviatedCombinedRelationConditionGroup.png differ diff --git a/_images/kogito/drl/abbreviatedCombinedRelationConditionGroup.svg b/_images/kogito/drl/abbreviatedCombinedRelationConditionGroup.svg new file mode 100644 index 0000000..182fad2 --- /dev/null +++ b/_images/kogito/drl/abbreviatedCombinedRelationConditionGroup.svg @@ -0,0 +1,116 @@ + + + + + + + + + + + + + + + + + + Page-1 + + + + + Process.34 + multiRestriction + + + + + + + + + + + + multiRestriction + + Dynamic connector.35 + + + + Process.36 + ‘(‘ + + + + + + + + + + + + ‘(‘ + + Process.37 + ‘)‘ + + + + + + + + + + + + ‘)‘ + + On-page reference.39 + + + + + + + + Dynamic connector.55 + + + + Dynamic connector.147 + + + + On-page reference.149 + + + + + + + + Dynamic connector.150 + + + + diff --git a/_images/kogito/drl/accumulate.png b/_images/kogito/drl/accumulate.png new file mode 100644 index 0000000..90acae9 Binary files /dev/null and b/_images/kogito/drl/accumulate.png differ diff --git a/_images/kogito/drl/accumulate.svg b/_images/kogito/drl/accumulate.svg new file mode 100644 index 0000000..92fe3ba --- /dev/null +++ b/_images/kogito/drl/accumulate.svg @@ -0,0 +1,367 @@ + + + + + + + + + + + + + + + + + + Page-1 + + + + + Process.49 + pattern + + + + + + + + + + + + pattern + + Dynamic connector.52 + + + + On-page reference.53 + + + + + + + + Dynamic connector.55 + + + + Process.60 + ‘from’ + + + + + + + + + + + + ‘from’ + + Process.61 + ‘accumulate’ + + + + + + + + + + + + ‘accumulate’ + + Dynamic connector.65 + + + + Dynamic connector.66 + + + + Process.45 + ‘(‘ + + + + + + + + + + + + ‘(‘ + + Dynamic connector.74 + + + + Dynamic connector.75 + + + + Process.76 + pattern + + + + + + + + + + + + pattern + + Process.77 + collect + + + + + + + + + + + + collect + + Process.78 + accumulate + + + + + + + + + + + + accumulate + + Process.79 + from + + + + + + + + + + + + from + + Dynamic connector.80 + + + + Dynamic connector.81 + + + + Dynamic connector.82 + + + + Dynamic connector.83 + + + + Dynamic connector.84 + + + + Dynamic connector.85 + + + + Process.86 + init + + + + + + + + + + + + init + + Process.87 + action + + + + + + + + + + + + action + + Process.88 + reverse + + + + + + + + + + + + reverse + + Process.89 + result + + + + + + + + + + + + result + + Dynamic connector.90 + + + + Dynamic connector.91 + + + + Dynamic connector.92 + + + + Dynamic connector.93 + + + + Process.94 + accumulateFunction + + + + + + + + + + + + accumulateFunction + + Dynamic connector.95 + + + + Process.97 + ‘)’ + + + + + + + + + + + + ‘)’ + + On-page reference.98 + + + + + + + + Dynamic connector.99 + + + + Dynamic connector.100 + + + + Dynamic connector.101 + + + + diff --git a/_images/kogito/drl/collect.png b/_images/kogito/drl/collect.png new file mode 100644 index 0000000..72cd418 Binary files /dev/null and b/_images/kogito/drl/collect.png differ diff --git a/_images/kogito/drl/collect.svg b/_images/kogito/drl/collect.svg new file mode 100644 index 0000000..e20306d --- /dev/null +++ b/_images/kogito/drl/collect.svg @@ -0,0 +1,249 @@ + + + + + + + + + + + + + + + + + + Page-1 + + + + + Process.17 + pattern + + + + + + + + + + + + pattern + + Process.18 + ‘(‘ + + + + + + + + + + + + ‘(‘ + + Process.19 + ‘)’ + + + + + + + + + + + + ‘)’ + + Dynamic connector.20 + + + + On-page reference.21 + + + + + + + + On-page reference.22 + + + + + + + + Dynamic connector.23 + + + + Dynamic connector.24 + + + + Process.29 + ‘from’ + + + + + + + + + + + + ‘from’ + + Process.30 + ‘collect’ + + + + + + + + + + + + ‘collect’ + + Dynamic connector.28 + + + + Dynamic connector.31 + + + + Dynamic connector.32 + + + + Dynamic connector.33 + + + + Process.1 + pattern + + + + + + + + + + + + pattern + + Process.10 + collect + + + + + + + + + + + + collect + + Process.35 + accumulate + + + + + + + + + + + + accumulate + + Process.14 + from + + + + + + + + + + + + from + + Dynamic connector.25 + + + + Dynamic connector.26 + + + + Dynamic connector.27 + + + + Dynamic connector.36 + + + + Dynamic connector.38 + + + + Dynamic connector.39 + + + + diff --git a/_images/kogito/drl/compoundValueRestriction.png b/_images/kogito/drl/compoundValueRestriction.png new file mode 100644 index 0000000..dcc9966 Binary files /dev/null and b/_images/kogito/drl/compoundValueRestriction.png differ diff --git a/_images/kogito/drl/compoundValueRestriction.svg b/_images/kogito/drl/compoundValueRestriction.svg new file mode 100644 index 0000000..1729fea --- /dev/null +++ b/_images/kogito/drl/compoundValueRestriction.svg @@ -0,0 +1,360 @@ + + + + + + + + + + + + + + + + + + Page-1 + + + + + On-page reference.66 + + + + + + + + Dynamic connector.83 + + + + Process.95 + ‘in’ | ‘not in’ + + + + + + + + + + + + ‘in’ | ‘not in’ + + On-page reference.96 + + + + + + + + Dynamic connector.85 + + + + Process.67 + ‘)‘ + + + + + + + + + + + + ‘)‘ + + Process.87 + ‘(‘ + + + + + + + + + + + + ‘(‘ + + Process.98 + ‘,‘ + + + + + + + + + + + + ‘,‘ + + Process.40 + variable + + + + + + + + + + + + variable + + Process.41 + literal + + + + + + + + + + + + literal + + Process.4 + returnValue + + + + + + + + + + + + returnValue + + Process.5 + variable + + + + + + + + + + + + variable + + Process.11 + literal + + + + + + + + + + + + literal + + Process.12 + returnValue + + + + + + + + + + + + returnValue + + Dynamic connector.33 + + + + Dynamic connector.53 + + + + Dynamic connector.54 + + + + Dynamic connector.114 + + + + Dynamic connector.99 + + + + Dynamic connector.116 + + + + Dynamic connector.101 + + + + Dynamic connector.102 + + + + Dynamic connector.103 + + + + Dynamic connector.104 + + + + Dynamic connector.105 + + + + Dynamic connector.106 + + + + Dynamic connector.107 + + + + Dynamic connector.125 + + + + Dynamic connector.127 + + + + Dynamic connector.128 + + + + Dynamic connector.126 + + + + Dynamic connector.137 + + + + Process.155 + qualifiedIdentifier + + + + + + + + + + + + qualifiedIdentifier + + Dynamic connector.156 + + + + Dynamic connector.157 + + + + Dynamic connector.158 + + + + Process.159 + qualifiedIdentifier + + + + + + + + + + + + qualifiedIdentifier + + Dynamic connector.160 + + + + Dynamic connector.161 + + + + diff --git a/_images/kogito/drl/error_message.png b/_images/kogito/drl/error_message.png new file mode 100644 index 0000000..86a38f6 Binary files /dev/null and b/_images/kogito/drl/error_message.png differ diff --git a/_images/kogito/drl/eval.png b/_images/kogito/drl/eval.png new file mode 100644 index 0000000..e6e4362 Binary files /dev/null and b/_images/kogito/drl/eval.png differ diff --git a/_images/kogito/drl/eval.svg b/_images/kogito/drl/eval.svg new file mode 100644 index 0000000..ddc83da --- /dev/null +++ b/_images/kogito/drl/eval.svg @@ -0,0 +1,127 @@ + + + + + + + + + + + + + + + + Page-1 + + + + + Dynamic connector.130 + + + + Process.132 + ‘eval’ + + + + + + + + + + + + ‘eval’ + + Process.133 + ‘(‘ + + + + + + + + + + + + ‘(‘ + + Process.134 + ‘)’ + + + + + + + + + + + + ‘)’ + + Dynamic connector.135 + + + + On-page reference.136 + + + + + + + + On-page reference.138 + + + + + + + + Dynamic connector.137 + + + + Dynamic connector.131 + + + + Process.193 + expression + + + + + + + + + + + + expression + + Dynamic connector.194 + + + + \ No newline at end of file diff --git a/_images/kogito/drl/exists.png b/_images/kogito/drl/exists.png new file mode 100644 index 0000000..d2fef65 Binary files /dev/null and b/_images/kogito/drl/exists.png differ diff --git a/_images/kogito/drl/exists.svg b/_images/kogito/drl/exists.svg new file mode 100644 index 0000000..22100da --- /dev/null +++ b/_images/kogito/drl/exists.svg @@ -0,0 +1,146 @@ + + + + + + + + + + + + + + + + + + Page-1 + + + + + Process.23 + ‘exists’ + + + + + + + + + + + + ‘exists’ + + Process.24 + ‘(‘ + + + + + + + + + + + + ‘(‘ + + Process.25 + ‘)’ + + + + + + + + + + + + ‘)’ + + Dynamic connector.26 + + + + On-page reference.27 + + + + + + + + On-page reference.28 + + + + + + + + Dynamic connector.29 + + + + Dynamic connector.30 + + + + Process.31 + conditionalElement + + + + + + + + + + + + conditionalElement + + Dynamic connector.32 + + + + Dynamic connector.33 + + + + Dynamic connector.156 + + + + Dynamic connector.157 + + + + diff --git a/_images/kogito/drl/forall.png b/_images/kogito/drl/forall.png new file mode 100644 index 0000000..b95a669 Binary files /dev/null and b/_images/kogito/drl/forall.png differ diff --git a/_images/kogito/drl/forall.svg b/_images/kogito/drl/forall.svg new file mode 100644 index 0000000..8448153 --- /dev/null +++ b/_images/kogito/drl/forall.svg @@ -0,0 +1,141 @@ + + + + + + + + + + + + + + + + + + Page-1 + + + + + Process.132 + ‘foralll’ + + + + + + + + + + + + ‘foralll’ + + Process.133 + ‘(‘ + + + + + + + + + + + + ‘(‘ + + Process.134 + ‘)’ + + + + + + + + + + + + ‘)’ + + Dynamic connector.135 + + + + On-page reference.136 + + + + + + + + On-page reference.138 + + + + + + + + Dynamic connector.137 + + + + Dynamic connector.131 + + + + Dynamic connector.194 + + + + Process.13 + pattern + + + + + + + + + + + + pattern + + Dynamic connector.15 + + + + Dynamic connector.16 + + + + diff --git a/_images/kogito/drl/from.png b/_images/kogito/drl/from.png new file mode 100644 index 0000000..75d651d Binary files /dev/null and b/_images/kogito/drl/from.png differ diff --git a/_images/kogito/drl/from.svg b/_images/kogito/drl/from.svg new file mode 100644 index 0000000..a8cbe67 --- /dev/null +++ b/_images/kogito/drl/from.svg @@ -0,0 +1,112 @@ + + + + + + + + + + + + + + + + + + Page-1 + + + + + Process.34 + ‘from’ + + + + + + + + + + + + ‘from’ + + Process.37 + expression + + + + + + + + + + + + expression + + Dynamic connector.40 + + + + On-page reference.41 + + + + + + + + On-page reference.42 + + + + + + + + Dynamic connector.44 + + + + Process.43 + pattern + + + + + + + + + + + + pattern + + Dynamic connector.46 + + + + Dynamic connector.50 + + + + diff --git a/_images/kogito/drl/function.png b/_images/kogito/drl/function.png new file mode 100644 index 0000000..76890a6 Binary files /dev/null and b/_images/kogito/drl/function.png differ diff --git a/_images/kogito/drl/function.svg b/_images/kogito/drl/function.svg new file mode 100644 index 0000000..ee23078 --- /dev/null +++ b/_images/kogito/drl/function.svg @@ -0,0 +1,245 @@ + + + + + + + + + + + + + + + + Page-1 + + + + + Process.1 + ‘{‘ + + + + + + + + + + + + ‘{‘ + + Process.34 + ‘function’ + + + + + + + + + + + + ‘function’ + + Process.36 + name + + + + + + + + + + + + name + + Dynamic connector.37 + + + + Process.37 + ‘}’ + + + + + + + + + + + + ‘}’ + + Dynamic connector.52 + + + + Dynamic connector.55 + + + + Dynamic connector.123 + + + + Process.124 + documentation + + + + + + + + + + + + documentation + + Dynamic connector.127 + + + + On-page reference.130 + + + + + + + + On-page reference.132 + + + + + + + + Process.5 + code + + + + + + + + + + + + code + + Dynamic connector.8 + + + + Dynamic connector.167 + + + + Process.9 + ‘(‘ + + + + + + + + + + + + ‘(‘ + + Process.12 + ‘)’ + + + + + + + + + + + + ‘)’ + + Dynamic connector.35 + + + + Process.53 + params + + + + + + + + + + + + params + + Dynamic connector.7 + + + + Dynamic connector.41 + + + + Process.54 + return-type + + + + + + + + + + + + return-type + + Dynamic connector.82 + + + + Dynamic connector.25 + + + + \ No newline at end of file diff --git a/_images/kogito/drl/function.vsd b/_images/kogito/drl/function.vsd new file mode 100644 index 0000000..86b26cf Binary files /dev/null and b/_images/kogito/drl/function.vsd differ diff --git a/_images/kogito/drl/global.png b/_images/kogito/drl/global.png new file mode 100644 index 0000000..916db91 Binary files /dev/null and b/_images/kogito/drl/global.png differ diff --git a/_images/kogito/drl/global.svg b/_images/kogito/drl/global.svg new file mode 100644 index 0000000..c5af5eb --- /dev/null +++ b/_images/kogito/drl/global.svg @@ -0,0 +1,131 @@ + + + + + + + + + + + + + + + + Page-1 + + + + + Process.69 + ‘global’ + + + + + + + + + + + + ‘global’ + + On-page reference.70 + + + + + + + + Process.72 + ‘;’ + + + + + + + + + + + + ‘;’ + + On-page reference.73 + + + + + + + + Dynamic connector.74 + + + + Dynamic connector.75 + + + + Dynamic connector.76 + + + + Dynamic connector.77 + + + + Dynamic connector.78 + + + + Process.71 + class + + + + + + + + + + + + class + + Process.101 + name + + + + + + + + + + + + name + + Dynamic connector.23 + + + + \ No newline at end of file diff --git a/_images/kogito/drl/import.png b/_images/kogito/drl/import.png new file mode 100644 index 0000000..7ddff55 Binary files /dev/null and b/_images/kogito/drl/import.png differ diff --git a/_images/kogito/drl/import.svg b/_images/kogito/drl/import.svg new file mode 100644 index 0000000..c7bdd09 --- /dev/null +++ b/_images/kogito/drl/import.svg @@ -0,0 +1,112 @@ + + + + + + + + + + + + + + + + Page-1 + + + + + Process.16 + ‘import’ + + + + + + + + + + + + ‘import’ + + On-page reference.90 + + + + + + + + Process.92 + class + + + + + + + + + + + + class + + Process.93 + ‘;’ + + + + + + + + + + + + ‘;’ + + On-page reference.94 + + + + + + + + Dynamic connector.95 + + + + Dynamic connector.96 + + + + Dynamic connector.97 + + + + Dynamic connector.98 + + + + Dynamic connector.99 + + + + \ No newline at end of file diff --git a/_images/kogito/drl/infixAnd.png b/_images/kogito/drl/infixAnd.png new file mode 100644 index 0000000..3e8b314 Binary files /dev/null and b/_images/kogito/drl/infixAnd.png differ diff --git a/_images/kogito/drl/infixAnd.svg b/_images/kogito/drl/infixAnd.svg new file mode 100644 index 0000000..5c90b59 --- /dev/null +++ b/_images/kogito/drl/infixAnd.svg @@ -0,0 +1,153 @@ + + + + + + + + + + + + + + + + + + Page-1 + + + + + Process.89 + CE + + + + + + + + + + + + CE + + Dynamic connector.97 + + + + On-page reference.98 + + + + + + + + On-page reference.99 + + + + + + + + Dynamic connector.100 + + + + Dynamic connector.91 + + + + Dynamic connector.37 + + + + Process.79 + ‘and’ + + + + + + + + + + + + ‘and’ + + Dynamic connector.80 + + + + Dynamic connector.81 + + + + Process.48 + ‘(’ + + + + + + + + + + + + ‘(’ + + Process.82 + ‘)’ + + + + + + + + + + + + ‘)’ + + Dynamic connector.85 + + + + Dynamic connector.86 + + + + diff --git a/_images/kogito/drl/infixOr.png b/_images/kogito/drl/infixOr.png new file mode 100644 index 0000000..7edb576 Binary files /dev/null and b/_images/kogito/drl/infixOr.png differ diff --git a/_images/kogito/drl/infixOr.svg b/_images/kogito/drl/infixOr.svg new file mode 100644 index 0000000..984547a --- /dev/null +++ b/_images/kogito/drl/infixOr.svg @@ -0,0 +1,178 @@ + + + + + + + + + + + + + + + + + + Page-1 + + + + + Process.39 + CE + + + + + + + + + + + + CE + + Dynamic connector.40 + + + + On-page reference.42 + + + + + + + + Dynamic connector.43 + + + + Dynamic connector.44 + + + + Dynamic connector.45 + + + + Process.46 + ‘or’ + + + + + + + + + + + + ‘or’ + + Dynamic connector.47 + + + + Dynamic connector.67 + + + + Process.87 + ‘(’ + + + + + + + + + + + + ‘(’ + + Process.88 + ‘)’ + + + + + + + + + + + + ‘)’ + + Dynamic connector.104 + + + + Dynamic connector.105 + + + + On-page reference.151 + + + + + + + + Process.153 + patternBinding + + + + + + + + + + + + patternBinding + + Dynamic connector.154 + + + + Dynamic connector.155 + + + + diff --git a/_images/kogito/drl/inlineEvalConstraint.png b/_images/kogito/drl/inlineEvalConstraint.png new file mode 100644 index 0000000..35966d7 Binary files /dev/null and b/_images/kogito/drl/inlineEvalConstraint.png differ diff --git a/_images/kogito/drl/inlineEvalConstraint.svg b/_images/kogito/drl/inlineEvalConstraint.svg new file mode 100644 index 0000000..4ba5764 --- /dev/null +++ b/_images/kogito/drl/inlineEvalConstraint.svg @@ -0,0 +1,115 @@ + + + + + + + + + + + + + + + + + + Page-1 + + + + + Process.175 + ‘eval(‘ + + + + + + + + + + + + ‘eval(‘ + + Process.176 + ‘)’ + + + + + + + + + + + + ‘)’ + + Dynamic connector.177 + + + + On-page reference.178 + + + + + + + + Dynamic connector.179 + + + + Process.180 + expression + + + + + + + + + + + + expression + + Dynamic connector.181 + + + + Dynamic connector.182 + + + + On-page reference.183 + + + + + + + + diff --git a/_images/kogito/drl/lhs.png b/_images/kogito/drl/lhs.png new file mode 100644 index 0000000..fd28d9d Binary files /dev/null and b/_images/kogito/drl/lhs.png differ diff --git a/_images/kogito/drl/lhs.svg b/_images/kogito/drl/lhs.svg new file mode 100644 index 0000000..f3b8cb8 --- /dev/null +++ b/_images/kogito/drl/lhs.svg @@ -0,0 +1,78 @@ + + + + + + + + + + + + + + + + + + Page-1 + + + + + Process.84 + conditionalElement + + + + + + + + + + + + conditionalElement + + Dynamic connector.92 + + + + On-page reference.130 + + + + + + + + Dynamic connector.131 + + + + On-page reference.132 + + + + + + + + Dynamic connector.133 + + + + diff --git a/_images/kogito/drl/meta_data.png b/_images/kogito/drl/meta_data.png new file mode 100644 index 0000000..a1fb8cd Binary files /dev/null and b/_images/kogito/drl/meta_data.png differ diff --git a/_images/kogito/drl/multi_line_comment.png b/_images/kogito/drl/multi_line_comment.png new file mode 100644 index 0000000..a132e56 Binary files /dev/null and b/_images/kogito/drl/multi_line_comment.png differ diff --git a/_images/kogito/drl/multi_line_comment.svg b/_images/kogito/drl/multi_line_comment.svg new file mode 100644 index 0000000..1ae910b --- /dev/null +++ b/_images/kogito/drl/multi_line_comment.svg @@ -0,0 +1,107 @@ + + + + + + + + + + + + + + + + Page-1 + + + + + Process.25 + ‘/*’ + + + + + + + + + + + + ‘/*’ + + On-page reference.26 + + + + + + + + Dynamic connector.27 + + + + Dynamic connector.28 + + + + Dynamic connector.29 + + + + Process.30 + text + + + + + + + + + + + + text + + Process.31 + ‘*/’ + + + + + + + + + + + + ‘*/’ + + On-page reference.32 + + + + + + + + Dynamic connector.33 + + + + \ No newline at end of file diff --git a/_images/kogito/drl/not.png b/_images/kogito/drl/not.png new file mode 100644 index 0000000..12f2b0d Binary files /dev/null and b/_images/kogito/drl/not.png differ diff --git a/_images/kogito/drl/not.svg b/_images/kogito/drl/not.svg new file mode 100644 index 0000000..d1bda25 --- /dev/null +++ b/_images/kogito/drl/not.svg @@ -0,0 +1,146 @@ + + + + + + + + + + + + + + + + + + Page-1 + + + + + Process.141 + ‘not’ + + + + + + + + + + + + ‘not’ + + Process.142 + ‘(‘ + + + + + + + + + + + + ‘(‘ + + Process.143 + ‘)’ + + + + + + + + + + + + ‘)’ + + Dynamic connector.144 + + + + On-page reference.145 + + + + + + + + On-page reference.146 + + + + + + + + Dynamic connector.147 + + + + Dynamic connector.148 + + + + Process.149 + conditionalElement + + + + + + + + + + + + conditionalElement + + Dynamic connector.150 + + + + Dynamic connector.151 + + + + Dynamic connector.41 + + + + Dynamic connector.152 + + + + diff --git a/_images/kogito/drl/operator.png b/_images/kogito/drl/operator.png new file mode 100644 index 0000000..6692320 Binary files /dev/null and b/_images/kogito/drl/operator.png differ diff --git a/_images/kogito/drl/operator.svg b/_images/kogito/drl/operator.svg new file mode 100644 index 0000000..68119fe --- /dev/null +++ b/_images/kogito/drl/operator.svg @@ -0,0 +1,81 @@ + + + + + + + + + + + + + + + + + + Page-1 + + + + + On-page reference.210 + + + + + + + + Process.211 + '<' | '<=' | '>' | '>=' | '==' | '!=' | ‘contains’ | ‘not con... + + + + + + + + + + + + '<' | '<=' | '>' | '>=' | '==' | '!=' | ‘contains’ | ‘not contains’ | ‘memberof’ | ‘not memberof’ | ‘matches’ | ‘not matches’ + + On-page reference.212 + + + + + + + + Dynamic connector.213 + + + + Dynamic connector.214 + + + + diff --git a/_images/kogito/drl/package.png b/_images/kogito/drl/package.png new file mode 100644 index 0000000..a24e537 Binary files /dev/null and b/_images/kogito/drl/package.png differ diff --git a/_images/kogito/drl/package.svg b/_images/kogito/drl/package.svg new file mode 100644 index 0000000..137b07f --- /dev/null +++ b/_images/kogito/drl/package.svg @@ -0,0 +1,277 @@ + + + + + + + + + + + + + + + + Page-1 + + + + + Process.1 + import + + + + + + + + + + + + import + + Process.97 + rule + + + + + + + + + + + + rule + + Dynamic connector.102 + + + + Process.103 + function + + + + + + + + + + + + function + + Process.104 + global + + + + + + + + + + + + global + + Dynamic connector.105 + + + + Dynamic connector.39 + + + + Dynamic connector.113 + + + + Process.175 + expander + + + + + + + + + + + + expander + + Process.17 + EOF + + + + + + + + + + + + EOF + + Dynamic connector.78 + + + + Dynamic connector.11 + + + + Process.23 + ‘package’ + + + + + + + + + + + + ‘package’ + + Dynamic connector.18 + + + + Dynamic connector.223 + + + + Process.224 + query + + + + + + + + + + + + query + + Dynamic connector.225 + + + + Dynamic connector.30 + + + + Dynamic connector.83 + + + + Dynamic connector.84 + + + + Dynamic connector.106 + + + + Dynamic connector.115 + + + + Dynamic connector.63 + + + + Dynamic connector.79 + + + + Dynamic connector.80 + + + + Process.82 + namespace + + + + + + + + + + + + namespace + + Process.87 + ‘;’ + + + + + + + + + + + + ‘;’ + + Dynamic connector.88 + + + + Dynamic connector.89 + + + + Dynamic connector.91 + + + + On-page reference.14 + + + + + + + + On-page reference.81 + + + + + + + + \ No newline at end of file diff --git a/_images/kogito/drl/package.vsd b/_images/kogito/drl/package.vsd new file mode 100644 index 0000000..130cb13 Binary files /dev/null and b/_images/kogito/drl/package.vsd differ diff --git a/_images/kogito/drl/prefixAnd.png b/_images/kogito/drl/prefixAnd.png new file mode 100644 index 0000000..6174306 Binary files /dev/null and b/_images/kogito/drl/prefixAnd.png differ diff --git a/_images/kogito/drl/prefixAnd.svg b/_images/kogito/drl/prefixAnd.svg new file mode 100644 index 0000000..9fa562b --- /dev/null +++ b/_images/kogito/drl/prefixAnd.svg @@ -0,0 +1,141 @@ + + + + + + + + + + + + + + + + + + Page-1 + + + + + Process.108 + ‘(’ + + + + + + + + + + + + ‘(’ + + Process.110 + ‘and’ + + + + + + + + + + + + ‘and’ + + Process.111 + CE + + + + + + + + + + + + CE + + On-page reference.112 + + + + + + + + Dynamic connector.113 + + + + Dynamic connector.114 + + + + Dynamic connector.115 + + + + Dynamic connector.116 + + + + Process.117 + ‘)’ + + + + + + + + + + + + ‘)’ + + On-page reference.118 + + + + + + + + Dynamic connector.119 + + + + Dynamic connector.120 + + + + diff --git a/_images/kogito/drl/prefixOr.png b/_images/kogito/drl/prefixOr.png new file mode 100644 index 0000000..61c7e42 Binary files /dev/null and b/_images/kogito/drl/prefixOr.png differ diff --git a/_images/kogito/drl/prefixOr.svg b/_images/kogito/drl/prefixOr.svg new file mode 100644 index 0000000..3596cfa --- /dev/null +++ b/_images/kogito/drl/prefixOr.svg @@ -0,0 +1,166 @@ + + + + + + + + + + + + + + + + + + Page-1 + + + + + Process.121 + ‘(’ + + + + + + + + + + + + ‘(’ + + Process.122 + ‘or’ + + + + + + + + + + + + ‘or’ + + Process.123 + CE + + + + + + + + + + + + CE + + On-page reference.124 + + + + + + + + Dynamic connector.140 + + + + Dynamic connector.141 + + + + Dynamic connector.142 + + + + Dynamic connector.143 + + + + Process.144 + ‘)’ + + + + + + + + + + + + ‘)’ + + On-page reference.145 + + + + + + + + Dynamic connector.146 + + + + Dynamic connector.147 + + + + Process.148 + patternBinding + + + + + + + + + + + + patternBinding + + Dynamic connector.149 + + + + Dynamic connector.150 + + + + diff --git a/_images/kogito/drl/query.png b/_images/kogito/drl/query.png new file mode 100644 index 0000000..babe92c Binary files /dev/null and b/_images/kogito/drl/query.png differ diff --git a/_images/kogito/drl/query.svg b/_images/kogito/drl/query.svg new file mode 100644 index 0000000..8d50832 --- /dev/null +++ b/_images/kogito/drl/query.svg @@ -0,0 +1,264 @@ + + + + + + + + + + + + + + + + + + Page-1 + + + + + Dynamic connector.4 + + + + Process.1 + ‘query’ + + + + + + + + + + + + ‘query’ + + Process.58 + ‘end’ + + + + + + + + + + + + ‘end’ + + Process.69 + LHS + + + + + + + + + + + + LHS + + Dynamic connector.73 + + + + On-page reference.135 + + + + + + + + Dynamic connector.136 + + + + On-page reference.138 + + + + + + + + Dynamic connector.140 + + + + Process.6 + name + + + + + + + + + + + + name + + Dynamic connector.37 + + + + Process.38 + type + + + + + + + + + + + + type + + Process.39 + identifier + + + + + + + + + + + + identifier + + Dynamic connector.40 + + + + Dynamic connector.41 + + + + Dynamic connector.42 + + + + Process.43 + ‘,’ + + + + + + + + + + + + ‘,’ + + Process.44 + ‘(’ + + + + + + + + + + + + ‘(’ + + Dynamic connector.45 + + + + Dynamic connector.46 + + + + Process.47 + ‘)’ + + + + + + + + + + + + ‘)’ + + Dynamic connector.48 + + + + Dynamic connector.49 + + + + Dynamic connector.50 + + + + Dynamic connector.51 + + + + diff --git a/_images/kogito/drl/query.vsd b/_images/kogito/drl/query.vsd new file mode 100644 index 0000000..c3830e5 Binary files /dev/null and b/_images/kogito/drl/query.vsd differ diff --git a/_images/kogito/drl/rule.png b/_images/kogito/drl/rule.png new file mode 100644 index 0000000..97c47e7 Binary files /dev/null and b/_images/kogito/drl/rule.png differ diff --git a/_images/kogito/drl/rule.svg b/_images/kogito/drl/rule.svg new file mode 100644 index 0000000..44a4e7a --- /dev/null +++ b/_images/kogito/drl/rule.svg @@ -0,0 +1,211 @@ + + + + + + + + + + + + + + + + Page-1 + + + + + Dynamic connector.4 + + + + Process.1 + ‘rule’ + + + + + + + + + + + + ‘rule’ + + Process.4 + attributes + + + + + + + + + + + + attributes + + Dynamic connector.3 + + + + Process.58 + ‘end’ + + + + + + + + + + + + ‘end’ + + Dynamic connector.60 + + + + Process.61 + ‘when’ + + + + + + + + + + + + ‘when’ + + Dynamic connector.62 + + + + Dynamic connector.64 + + + + Process.62 + ‘then’ + + + + + + + + + + + + ‘then’ + + Process.69 + LHS + + + + + + + + + + + + LHS + + Dynamic connector.73 + + + + On-page reference.135 + + + + + + + + Dynamic connector.136 + + + + On-page reference.138 + + + + + + + + Dynamic connector.140 + + + + Process.6 + name + + + + + + + + + + + + name + + Dynamic connector.37 + + + + Process.28 + RHS + + + + + + + + + + + + RHS + + Dynamic connector.38 + + + + Dynamic connector.39 + + + + \ No newline at end of file diff --git a/_images/kogito/drl/rule.vsd b/_images/kogito/drl/rule.vsd new file mode 100644 index 0000000..d3386ed Binary files /dev/null and b/_images/kogito/drl/rule.vsd differ diff --git a/_images/kogito/drl/rule_attributes.png b/_images/kogito/drl/rule_attributes.png new file mode 100644 index 0000000..10c4b50 Binary files /dev/null and b/_images/kogito/drl/rule_attributes.png differ diff --git a/_images/kogito/drl/rule_attributes.svg b/_images/kogito/drl/rule_attributes.svg new file mode 100644 index 0000000..6c57afc --- /dev/null +++ b/_images/kogito/drl/rule_attributes.svg @@ -0,0 +1,423 @@ + + + + + + + + + + + + + + + + + + Page-1 + + + + + Process.89 + ‘no-loop’ + + + + + + + + + + + + ‘no-loop’ + + Process.90 + ‘salience’ + + + + + + + + + + + + ‘salience’ + + Dynamic connector.91 + + + + Dynamic connector.92 + + + + Process.93 + ‘agenda-group’ + + + + + + + + + + + + ‘agenda-group’ + + Process.94 + ‘duration’ + + + + + + + + + + + + ‘duration’ + + Dynamic connector.95 + + + + Dynamic connector.96 + + + + Dynamic connector.98 + + + + + Dynamic connector.99 + + + + Dynamic connector.100 + + + + Dynamic connector.101 + + + + Process.156 + value + + + + + + + + + + + + value + + On-page reference.157 + + + + + + + + Process.160 + ; + + + + + + + + + + + + ; + + Dynamic connector.161 + + + + Dynamic connector.162 + + + + Dynamic connector.163 + + + + On-page reference.164 + + + + + + + + Process.201 + duration-value (ms) + + + + + + + + + + + + duration-value (ms) + + Dynamic connector.202 + + + + Process.60 + ‘auto-focus’ + + + + + + + + + + + + ‘auto-focus’ + + Dynamic connector.61 + + + + Dynamic connector.62 + + + + Process.63 + ‘lock-on-active’ + + + + + + + + + + + + ‘lock-on-active’ + + Dynamic connector.64 + + + + Dynamic connector.65 + + + + Process.66 + ‘ruleflow-group’ + + + + + + + + + + + + ‘ruleflow-group’ + + Dynamic connector.67 + + + + Dynamic connector.68 + + + + Process.69 + ‘activation-group’ + + + + + + + + + + + + ‘activation-group’ + + Dynamic connector.70 + + + + Dynamic connector.71 + + + + Process.72 + ‘dialect’ + + + + + + + + + + + + ‘dialect’ + + Dynamic connector.73 + + + + Dynamic connector.74 + + + + Process.75 + ‘date-effective’ + + + + + + + + + + + + ‘date-effective’ + + Dynamic connector.76 + + + + Dynamic connector.77 + + + + Process.78 + ‘date-expires’ + + + + + + + + + + + + ‘date-expires’ + + Dynamic connector.79 + + + + Dynamic connector.80 + + + + Process.81 + ‘enabled’ + + + + + + + + + + + + ‘enabled’ + + Dynamic connector.82 + + + + Dynamic connector.83 + + + + diff --git a/_images/kogito/drl/type_declaration.png b/_images/kogito/drl/type_declaration.png new file mode 100644 index 0000000..24c0ec9 Binary files /dev/null and b/_images/kogito/drl/type_declaration.png differ diff --git a/_images/kogito/openshift/kogito-data-index-graphiql-process-instances.png b/_images/kogito/openshift/kogito-data-index-graphiql-process-instances.png new file mode 100644 index 0000000..1f817ab Binary files /dev/null and b/_images/kogito/openshift/kogito-data-index-graphiql-process-instances.png differ diff --git a/_images/kogito/openshift/kogito-data-index-graphiql-travels.png b/_images/kogito/openshift/kogito-data-index-graphiql-travels.png new file mode 100644 index 0000000..00c5549 Binary files /dev/null and b/_images/kogito/openshift/kogito-data-index-graphiql-travels.png differ diff --git a/_images/kogito/openshift/kogito-data-index-graphiql-usertask-instances.png b/_images/kogito/openshift/kogito-data-index-graphiql-usertask-instances.png new file mode 100644 index 0000000..b1ec7c1 Binary files /dev/null and b/_images/kogito/openshift/kogito-data-index-graphiql-usertask-instances.png differ diff --git a/_images/kogito/openshift/kogito-data-index-graphiql-visaapplications.png b/_images/kogito/openshift/kogito-data-index-graphiql-visaapplications.png new file mode 100644 index 0000000..56297f4 Binary files /dev/null and b/_images/kogito/openshift/kogito-data-index-graphiql-visaapplications.png differ diff --git a/_images/kogito/openshift/kogito-data-index-graphiql.png b/_images/kogito/openshift/kogito-data-index-graphiql.png new file mode 100644 index 0000000..9336b88 Binary files /dev/null and b/_images/kogito/openshift/kogito-data-index-graphiql.png differ diff --git a/_images/kogito/openshift/kogito-management-console-instance.png b/_images/kogito/openshift/kogito-management-console-instance.png new file mode 100644 index 0000000..b5a629f Binary files /dev/null and b/_images/kogito/openshift/kogito-management-console-instance.png differ diff --git a/_images/kogito/openshift/kogito-ocp-app-build-details.png b/_images/kogito/openshift/kogito-ocp-app-build-details.png new file mode 100644 index 0000000..76d7548 Binary files /dev/null and b/_images/kogito/openshift/kogito-ocp-app-build-details.png differ diff --git a/_images/kogito/openshift/kogito-ocp-app-deployment-details-agency.png b/_images/kogito/openshift/kogito-ocp-app-deployment-details-agency.png new file mode 100644 index 0000000..0137cbb Binary files /dev/null and b/_images/kogito/openshift/kogito-ocp-app-deployment-details-agency.png differ diff --git a/_images/kogito/openshift/kogito-ocp-app-deployment-details-visas.png b/_images/kogito/openshift/kogito-ocp-app-deployment-details-visas.png new file mode 100644 index 0000000..723cedc Binary files /dev/null and b/_images/kogito/openshift/kogito-ocp-app-deployment-details-visas.png differ diff --git a/_images/kogito/openshift/kogito-ocp-app-deployment-details.png b/_images/kogito/openshift/kogito-ocp-app-deployment-details.png new file mode 100644 index 0000000..c9c25cb Binary files /dev/null and b/_images/kogito/openshift/kogito-ocp-app-deployment-details.png differ diff --git a/_images/kogito/openshift/kogito-ocp-app-details.png b/_images/kogito/openshift/kogito-ocp-app-details.png new file mode 100644 index 0000000..91eb775 Binary files /dev/null and b/_images/kogito/openshift/kogito-ocp-app-details.png differ diff --git a/_images/kogito/openshift/kogito-ocp-app-route-details.png b/_images/kogito/openshift/kogito-ocp-app-route-details.png new file mode 100644 index 0000000..5c4a017 Binary files /dev/null and b/_images/kogito/openshift/kogito-ocp-app-route-details.png differ diff --git a/_images/kogito/openshift/kogito-ocp-app-routes-agency-TEST (another copy).png b/_images/kogito/openshift/kogito-ocp-app-routes-agency-TEST (another copy).png new file mode 100644 index 0000000..7b9958e Binary files /dev/null and b/_images/kogito/openshift/kogito-ocp-app-routes-agency-TEST (another copy).png differ diff --git a/_images/kogito/openshift/kogito-ocp-app-routes-agency-TEST (copy).png b/_images/kogito/openshift/kogito-ocp-app-routes-agency-TEST (copy).png new file mode 100644 index 0000000..42343a9 Binary files /dev/null and b/_images/kogito/openshift/kogito-ocp-app-routes-agency-TEST (copy).png differ diff --git a/_images/kogito/openshift/kogito-ocp-app-routes-agency.png b/_images/kogito/openshift/kogito-ocp-app-routes-agency.png new file mode 100644 index 0000000..a66e915 Binary files /dev/null and b/_images/kogito/openshift/kogito-ocp-app-routes-agency.png differ diff --git a/_images/kogito/openshift/kogito-ocp-create-app-listed-agency.png b/_images/kogito/openshift/kogito-ocp-create-app-listed-agency.png new file mode 100644 index 0000000..cfdea5b Binary files /dev/null and b/_images/kogito/openshift/kogito-ocp-create-app-listed-agency.png differ diff --git a/_images/kogito/openshift/kogito-ocp-create-app-listed.png b/_images/kogito/openshift/kogito-ocp-create-app-listed.png new file mode 100644 index 0000000..cf389ad Binary files /dev/null and b/_images/kogito/openshift/kogito-ocp-create-app-listed.png differ diff --git a/_images/kogito/openshift/kogito-ocp-create-app.png b/_images/kogito/openshift/kogito-ocp-create-app.png new file mode 100644 index 0000000..7dd5888 Binary files /dev/null and b/_images/kogito/openshift/kogito-ocp-create-app.png differ diff --git a/_images/kogito/openshift/kogito-ocp-data-index-deployment.png b/_images/kogito/openshift/kogito-ocp-data-index-deployment.png new file mode 100644 index 0000000..5b51432 Binary files /dev/null and b/_images/kogito/openshift/kogito-ocp-data-index-deployment.png differ diff --git a/_images/kogito/openshift/kogito-ocp-data-index-graphql.png b/_images/kogito/openshift/kogito-ocp-data-index-graphql.png new file mode 100644 index 0000000..bba326c Binary files /dev/null and b/_images/kogito/openshift/kogito-ocp-data-index-graphql.png differ diff --git a/_images/kogito/openshift/kogito-ocp-data-index-graphql2.png b/_images/kogito/openshift/kogito-ocp-data-index-graphql2.png new file mode 100644 index 0000000..673fbd1 Binary files /dev/null and b/_images/kogito/openshift/kogito-ocp-data-index-graphql2.png differ diff --git a/_images/kogito/openshift/kogito-ocp-data-index-route.png b/_images/kogito/openshift/kogito-ocp-data-index-route.png new file mode 100644 index 0000000..1298109 Binary files /dev/null and b/_images/kogito/openshift/kogito-ocp-data-index-route.png differ diff --git a/_images/kogito/openshift/kogito-ocp-data-index.png b/_images/kogito/openshift/kogito-ocp-data-index.png new file mode 100644 index 0000000..a41da36 Binary files /dev/null and b/_images/kogito/openshift/kogito-ocp-data-index.png differ diff --git a/_images/kogito/openshift/kogito-ocp-infinispan-infra.png b/_images/kogito/openshift/kogito-ocp-infinispan-infra.png new file mode 100644 index 0000000..e12ab37 Binary files /dev/null and b/_images/kogito/openshift/kogito-ocp-infinispan-infra.png differ diff --git a/_images/kogito/openshift/kogito-ocp-infra-kafka.png b/_images/kogito/openshift/kogito-ocp-infra-kafka.png new file mode 100644 index 0000000..9c4c81d Binary files /dev/null and b/_images/kogito/openshift/kogito-ocp-infra-kafka.png differ diff --git a/_images/kogito/openshift/kogito-ocp-infra.png b/_images/kogito/openshift/kogito-ocp-infra.png new file mode 100644 index 0000000..2f1dc5c Binary files /dev/null and b/_images/kogito/openshift/kogito-ocp-infra.png differ diff --git a/_images/kogito/openshift/kogito-ocp-installed-operators.png b/_images/kogito/openshift/kogito-ocp-installed-operators.png new file mode 100644 index 0000000..b4a47d3 Binary files /dev/null and b/_images/kogito/openshift/kogito-ocp-installed-operators.png differ diff --git a/_images/kogito/openshift/kogito-ocp-kafka-infra.png b/_images/kogito/openshift/kogito-ocp-kafka-infra.png new file mode 100644 index 0000000..2000d6b Binary files /dev/null and b/_images/kogito/openshift/kogito-ocp-kafka-infra.png differ diff --git a/_images/kogito/openshift/kogito-ocp-stateful-sets-infinispan.png b/_images/kogito/openshift/kogito-ocp-stateful-sets-infinispan.png new file mode 100644 index 0000000..d70b142 Binary files /dev/null and b/_images/kogito/openshift/kogito-ocp-stateful-sets-infinispan.png differ diff --git a/_images/kogito/openshift/kogito-ocp-stateful-sets-kafka.png b/_images/kogito/openshift/kogito-ocp-stateful-sets-kafka.png new file mode 100644 index 0000000..0f52fba Binary files /dev/null and b/_images/kogito/openshift/kogito-ocp-stateful-sets-kafka.png differ diff --git a/_images/kogito/openshift/kogito-ocp-travel-agency-app.png b/_images/kogito/openshift/kogito-ocp-travel-agency-app.png new file mode 100644 index 0000000..5cdd73e Binary files /dev/null and b/_images/kogito/openshift/kogito-ocp-travel-agency-app.png differ diff --git a/_images/kogito/openshift/kogito-ocp-travel-agency-process.png b/_images/kogito/openshift/kogito-ocp-travel-agency-process.png new file mode 100644 index 0000000..54ec40b Binary files /dev/null and b/_images/kogito/openshift/kogito-ocp-travel-agency-process.png differ diff --git a/_images/kogito/openshift/kogito-ocp-visas-app.png b/_images/kogito/openshift/kogito-ocp-visas-app.png new file mode 100644 index 0000000..89d71f6 Binary files /dev/null and b/_images/kogito/openshift/kogito-ocp-visas-app.png differ diff --git a/_images/kogito/openshift/kogito-ocp-visas-process.png b/_images/kogito/openshift/kogito-ocp-visas-process.png new file mode 100644 index 0000000..ac7eec4 Binary files /dev/null and b/_images/kogito/openshift/kogito-ocp-visas-process.png differ diff --git a/_images/kogito/openshift/kogito-travel-agency-new-trip-created.png b/_images/kogito/openshift/kogito-travel-agency-new-trip-created.png new file mode 100644 index 0000000..9c74e5f Binary files /dev/null and b/_images/kogito/openshift/kogito-travel-agency-new-trip-created.png differ diff --git a/_images/kogito/openshift/kogito-travel-agency-plan-new-trip.png b/_images/kogito/openshift/kogito-travel-agency-plan-new-trip.png new file mode 100644 index 0000000..90ccbdf Binary files /dev/null and b/_images/kogito/openshift/kogito-travel-agency-plan-new-trip.png differ diff --git a/_images/kogito/openshift/kogito-travel-agency-task-confirm-travel.png b/_images/kogito/openshift/kogito-travel-agency-task-confirm-travel.png new file mode 100644 index 0000000..d9afad7 Binary files /dev/null and b/_images/kogito/openshift/kogito-travel-agency-task-confirm-travel.png differ diff --git a/_images/kogito/openshift/kogito-travel-agency-task-visaapplication-form.png b/_images/kogito/openshift/kogito-travel-agency-task-visaapplication-form.png new file mode 100644 index 0000000..f34b6cf Binary files /dev/null and b/_images/kogito/openshift/kogito-travel-agency-task-visaapplication-form.png differ diff --git a/_images/kogito/openshift/kogito-travel-agency-task-visaapplication.png b/_images/kogito/openshift/kogito-travel-agency-task-visaapplication.png new file mode 100644 index 0000000..397be3c Binary files /dev/null and b/_images/kogito/openshift/kogito-travel-agency-task-visaapplication.png differ diff --git a/_images/kogito/openshift/kogito-travel-agency-travel-complete.png b/_images/kogito/openshift/kogito-travel-agency-travel-complete.png new file mode 100644 index 0000000..1c9eae4 Binary files /dev/null and b/_images/kogito/openshift/kogito-travel-agency-travel-complete.png differ diff --git a/_images/kogito/openshift/kogito-travel-agency-visa-approved.png b/_images/kogito/openshift/kogito-travel-agency-visa-approved.png new file mode 100644 index 0000000..1d3d002 Binary files /dev/null and b/_images/kogito/openshift/kogito-travel-agency-visa-approved.png differ diff --git a/_images/kogito/openshift/kogito-visas-application.png b/_images/kogito/openshift/kogito-visas-application.png new file mode 100644 index 0000000..f9e9472 Binary files /dev/null and b/_images/kogito/openshift/kogito-visas-application.png differ diff --git a/_images/kogito/openshift/kogito-visas-task-approval.png b/_images/kogito/openshift/kogito-visas-task-approval.png new file mode 100644 index 0000000..09ffcfe Binary files /dev/null and b/_images/kogito/openshift/kogito-visas-task-approval.png differ diff --git a/_images/logos/droolsExpertLogo.png b/_images/logos/droolsExpertLogo.png new file mode 100644 index 0000000..a057955 Binary files /dev/null and b/_images/logos/droolsExpertLogo.png differ diff --git a/_images/logos/jBPMLogo.png b/_images/logos/jBPMLogo.png new file mode 100644 index 0000000..985547e Binary files /dev/null and b/_images/logos/jBPMLogo.png differ diff --git a/_images/logos/kogitoLogo.png b/_images/logos/kogitoLogo.png new file mode 100644 index 0000000..2f5fead Binary files /dev/null and b/_images/logos/kogitoLogo.png differ diff --git a/_images/logos/optaPlannerLogo.png b/_images/logos/optaPlannerLogo.png new file mode 100644 index 0000000..c810701 Binary files /dev/null and b/_images/logos/optaPlannerLogo.png differ diff --git a/_images/readme/github-content-overview.png b/_images/readme/github-content-overview.png new file mode 100644 index 0000000..ba1a633 Binary files /dev/null and b/_images/readme/github-content-overview.png differ diff --git a/assemblies/.gitignore b/assemblies/.gitignore new file mode 100644 index 0000000..378eac2 --- /dev/null +++ b/assemblies/.gitignore @@ -0,0 +1 @@ +build diff --git a/assemblies/assembly-kogito-configuring.adoc b/assemblies/assembly-kogito-configuring.adoc new file mode 100644 index 0000000..31fd567 --- /dev/null +++ b/assemblies/assembly-kogito-configuring.adoc @@ -0,0 +1,35 @@ +ifdef::context[:parent-context: {context}] + +[id='assembly-kogito-configuring'] += Configuring {PRODUCT} supporting services and runtime capabilities +:context: kogito-configuring + +// Purpose statement for the assembly +As a developer of business processes and decisions, you can configure {PRODUCT} supporting services and runtime properties for advanced use cases with your {PRODUCT} services. + +// Modules - concepts, procedures, refs, etc. +include::modules/configuration/con-kogito-supporting-services-and-configuration.adoc[leveloffset=+1] +include::modules/configuration/ref-kogito-runtime-properties.adoc[leveloffset=+1] +include::modules/configuration/con-kogito-runtime-events.adoc[leveloffset=+1] +include::modules/configuration/proc-messaging-enabling.adoc[leveloffset=+2] +include::modules/configuration/proc-event-listeners-registering.adoc[leveloffset=+2] +include::modules/configuration/proc-prometheus-metrics-monitoring.adoc[leveloffset=+2] +include::modules/configuration/con-persistence.adoc[leveloffset=+1] +include::modules/configuration/proc-persistence-enabling.adoc[leveloffset=+2] +include::modules/configuration/con-data-index-service.adoc[leveloffset=+1] +include::modules/configuration/proc-data-index-service-using.adoc[leveloffset=+2] +include::modules/configuration/ref-data-index-service-queries.adoc[leveloffset=+2] +include::modules/configuration/con-jobs-service.adoc[leveloffset=+1] +include::modules/configuration/proc-jobs-service-using.adoc[leveloffset=+2] +include::modules/configuration/proc-jobs-service-persistence.adoc[leveloffset=+2] +include::modules/configuration/proc-jobs-service-messaging.adoc[leveloffset=+2] +include::modules/process-services/con-bpmn-process-management-addon.adoc[leveloffset=+1] + +== Additional resources +* {URL_CREATING_RUNNING}[_{CREATING_RUNNING}_] +* {URL_DEPLOYING_ON_OPENSHIFT}[_{DEPLOYING_ON_OPENSHIFT}_] +* {URL_DECISION_SERVICES}[_{DECISION_SERVICES}_] +* {URL_PROCESS_SERVICES}[_{PROCESS_SERVICES}_] + +ifdef::parent-context[:context: {parent-context}] +ifndef::parent-context[:!context:] diff --git a/assemblies/assembly-kogito-creating-running.adoc b/assemblies/assembly-kogito-creating-running.adoc new file mode 100644 index 0000000..7c854ca --- /dev/null +++ b/assemblies/assembly-kogito-creating-running.adoc @@ -0,0 +1,32 @@ +ifdef::context[:parent-context: {context}] + +[id='assembly-kogito-creating-running'] += Creating and running your first {PRODUCT} services +:context: kogito-creating-running + +// Purpose statement for the assembly +As a developer of business processes and decisions, you can use {PRODUCT} business automation to build cloud-native applications with a domain-specific set of services. + +// Modules - concepts, procedures, refs, etc. +include::modules/creating-running/con-kogito-automation.adoc[leveloffset=+1] +include::modules/creating-running/con-kogito-quarkus-springboot.adoc[leveloffset=+2] +include::modules/creating-running/ref-kogito-app-examples.adoc[leveloffset=+1] +include::modules/creating-running/proc-kogito-app-examples-running.adoc[leveloffset=+2] +include::modules/creating-running/con-kogito-modelers.adoc[leveloffset=+1] +include::modules/creating-running/proc-kogito-modelers.adoc[leveloffset=+2] +include::modules/creating-running/proc-kogito-vscode-extension.adoc[leveloffset=+2] +include::modules/creating-running/proc-kogito-creating-project.adoc[leveloffset=+1] +include::modules/creating-running/proc-kogito-designing-app.adoc[leveloffset=+1] +include::modules/creating-running/proc-kogito-designing-app-rule-units.adoc[leveloffset=+2] +include::modules/creating-running/proc-kogito-running-app.adoc[leveloffset=+1] +include::modules/creating-running/proc-kogito-interacting-app.adoc[leveloffset=+1] +include::modules/creating-running/ref-kogito-glossary.adoc[leveloffset=+1] + +== Additional resources +* {URL_DEPLOYING_ON_OPENSHIFT}[_{DEPLOYING_ON_OPENSHIFT}_] +* {URL_DECISION_SERVICES}[_{DECISION_SERVICES}_] +* {URL_PROCESS_SERVICES}[_{PROCESS_SERVICES}_] +* {URL_CONFIGURING_KOGITO}[_{CONFIGURING_KOGITO}_] + +ifdef::parent-context[:context: {parent-context}] +ifndef::parent-context[:!context:] diff --git a/assemblies/assembly-kogito-decision-engine.adoc b/assemblies/assembly-kogito-decision-engine.adoc new file mode 100644 index 0000000..c4bbf18 --- /dev/null +++ b/assemblies/assembly-kogito-decision-engine.adoc @@ -0,0 +1,18 @@ +ifdef::context[:parent-context: {context}] + +[id='assembly-kogito-decision-engine'] += {DECISION_ENGINE_CAP} in {PRODUCT} +:context: kogito-decision-engine + +As a developer of business decisions, your understanding of the {DECISION_ENGINE} in {PRODUCT} can help you design more effective business assets and a more scalable decision management architecture. The {DECISION_ENGINE} is the {PRODUCT} component that stores, processes, and evaluates data to execute business rules and to reach the decisions that you define. This document describes basic concepts and functions of the {DECISION_ENGINE} to consider as you create your business rule system and decision services in {PRODUCT}. + +include::modules/decision-engine/con-decision-engine.adoc[leveloffset=+1] +include::modules/decision-engine/con-execution-control.adoc[leveloffset=+1] +include::modules/decision-engine/con-phreak-algorithm.adoc[leveloffset=+1] +include::modules/decision-engine/con-phreak-rule-evaluation.adoc[leveloffset=+2] +include::modules/decision-engine/con-forward-and-backward-chaining.adoc[leveloffset=+3] +include::modules/decision-engine/con-property-change-listeners.adoc[leveloffset=+2] +include::modules/decision-engine/con-engine-event-listeners.adoc[leveloffset=+1] + +ifdef::parent-context[:context: {parent-context}] +ifndef::parent-context[:!context:] diff --git a/assemblies/assembly-kogito-managing-processes.adoc b/assemblies/assembly-kogito-managing-processes.adoc new file mode 100644 index 0000000..73283f0 --- /dev/null +++ b/assemblies/assembly-kogito-managing-processes.adoc @@ -0,0 +1,20 @@ +ifdef::context[:parent-context: {context}] + +[id='assembly-kogito-managing-processes'] += Managing and monitoring business processes in Business Central +:context: kogito-managing-and-monitoring-processes + +// Purpose statement for the assembly +As a process administrator, you can use Business Central in {PRODUCT} to manage and monitor process instances and tasks running on a number of projects. From Business Central you can start a new process instance, verify the state of all process instances, and abort processes. You can view the list of jobs and tasks associated with your processes, as well as understand and communicate any process errors. + +// Modules - concepts, procedures, refs, etc. +include::modules/process-services/con-process-definitions-and-instances.adoc[leveloffset=+1] +include::modules/process-services/proc-starting-process-instance-from-definition.adoc[leveloffset=+2] +include::modules/process-services/proc-starting-process-instance-from-instances.adoc[leveloffset=+2] + +include::modules/process-services/con-process-instance-details.adoc[leveloffset=+1] +include::modules/process-services/proc-process-instance-filtering.adoc[leveloffset=+2] +include::modules/process-services/proc-creating-new-process-instance-list.adoc[leveloffset=+2] + +ifdef::parent-context[:context: {parent-context}] +ifndef::parent-context[:!context:] diff --git a/assemblies/assembly-kogito-using-bpmn.adoc b/assemblies/assembly-kogito-using-bpmn.adoc new file mode 100644 index 0000000..6cc4abe --- /dev/null +++ b/assemblies/assembly-kogito-using-bpmn.adoc @@ -0,0 +1,46 @@ +ifdef::context[:parent-context: {context}] + +[id='assembly-kogito-using-bpmn'] += Using BPMN models in {PRODUCT} services +:context: kogito-bpmn-models + +// Purpose statement for the assembly +As a developer of business processes, you can use {PRODUCT} business automation to develop process services using Business Process Model and Notation (BPMN) 2.0 process models. BPMN process models are graphical representations of the steps required to achieve a business goal. You can design your BPMN processes with the {PRODUCT} BPMN modeler in VSCode or import existing BPMN processes into your {PRODUCT} projects for deployment and execution. + +For more information about BPMN, see the Object Management Group (OMG) https://www.omg.org/spec/BPMN/2.0/About-BPMN[Business Process Model and Notation 2.0 specification]. + +// Modules - concepts, procedures, refs, etc. +include::modules/creating-running/ref-kogito-app-examples.adoc[leveloffset=+1] +include::modules/process-services/con-bpmn.adoc[leveloffset=+1] +include::modules/process-services/ref-bpmn-model-example.adoc[leveloffset=+2] +include::modules/process-services/ref-bpmn-support.adoc[leveloffset=+2] +include::modules/process-services/ref-bpmn-start-events.adoc[leveloffset=+2] +include::modules/process-services/ref-bpmn-intermediate-events.adoc[leveloffset=+2] +include::modules/process-services/ref-bpmn-end-events.adoc[leveloffset=+2] +include::modules/process-services/ref-bpmn-tasks.adoc[leveloffset=+2] +include::modules/process-services/ref-bpmn-subprocesses.adoc[leveloffset=+2] +include::modules/process-services/ref-bpmn-gateways.adoc[leveloffset=+2] +include::modules/process-services/ref-bpmn-connectors.adoc[leveloffset=+2] +include::modules/process-services/proc-bpmn-model-creating.adoc[leveloffset=+1] +include::modules/process-services/con-bpmn-variables.adoc[leveloffset=+1] +include::modules/process-services/proc-bpmn-variables-global.adoc[leveloffset=+2] +include::modules/process-services/proc-bpmn-variables-process.adoc[leveloffset=+2] +include::modules/process-services/proc-bpmn-variables-local.adoc[leveloffset=+2] +include::modules/configuration/con-persistence.adoc[leveloffset=+1] +include::modules/configuration/proc-persistence-enabling.adoc[leveloffset=+2] +include::modules/configuration/proc-messaging-enabling.adoc[leveloffset=+1] +include::modules/configuration/con-task-life-cycle.adoc[leveloffset=+1] +include::modules/configuration/proc-task-lifecycle-custom.adoc[leveloffset=+2] +include::modules/process-services/con-bpmn-process-management-addon.adoc[leveloffset=+1] +include::modules/process-services/con-management-console.adoc[leveloffset=+1] +include::modules/process-services/proc-management-console-using.adoc[leveloffset=+2] +include::modules/creating-running/con-kogito-service-execution.adoc[leveloffset=+1] + +== Additional resources +* {URL_CREATING_RUNNING}[_{CREATING_RUNNING}_] +* {URL_DEPLOYING_ON_OPENSHIFT}[_{DEPLOYING_ON_OPENSHIFT}_] +* {URL_DECISION_SERVICES}[_{DECISION_SERVICES}_] +* {URL_CONFIGURING_KOGITO}[_{CONFIGURING_KOGITO}_] + +ifdef::parent-context[:context: {parent-context}] +ifndef::parent-context[:!context:] diff --git a/assemblies/assembly-kogito-using-dmn.adoc b/assemblies/assembly-kogito-using-dmn.adoc new file mode 100644 index 0000000..261206d --- /dev/null +++ b/assemblies/assembly-kogito-using-dmn.adoc @@ -0,0 +1,37 @@ +ifdef::context[:parent-context: {context}] + +[id='assembly-kogito-using-dmn'] += Using DMN models in {PRODUCT} services +:context: kogito-dmn-models + +As a developer of business decisions, you can use Decision Model and Notation (DMN) to model a decision service graphically in a decision requirements diagram (DRD). This diagram consists of one or more decision requirements graphs (DRGs) that trace business decisions from start to finish, with each decision node using logic defined in DMN boxed expressions such as decision tables. + +{PRODUCT} provides design and runtime support for DMN 1.2 models at conformance level 3, and runtime-only support for DMN 1.1 and 1.3 models at conformance level 3. You can design your DMN models with the {PRODUCT} DMN modeler in VSCode or import existing DMN models into your {PRODUCT} projects for deployment and execution. Any DMN 1.1 models that you import into your {PRODUCT} project, open in the DMN modeler, and save are converted to DMN 1.2 models. DMN 1.3 models are not supported in the {PRODUCT} DMN modeler. + +For more information about DMN, see the Object Management Group (OMG) https://www.omg.org/spec/DMN[Decision Model and Notation specification]. + +include::modules/decision-services/con-dmn.adoc[leveloffset=+1] +include::modules/decision-services/con-dmn-conformance-levels.adoc[leveloffset=+2] +include::modules/decision-services/ref-dmn-drd-components.adoc[leveloffset=+2] +include::modules/decision-services/con-dmn-feel.adoc[leveloffset=+2] +include::modules/decision-services/con-dmn-names.adoc[leveloffset=+3] +include::modules/decision-services/ref-dmn-data-types.adoc[leveloffset=+3] +include::modules/decision-services/con-dmn-boxed-expressions.adoc[leveloffset=+2] +include::modules/decision-services/con-dmn-decision-tables.adoc[leveloffset=+3] +include::modules/decision-services/con-dmn-decision-tables-hit-policies.adoc[leveloffset=+4] +include::modules/decision-services/con-dmn-literal-expressions.adoc[leveloffset=+3] +include::modules/decision-services/con-dmn-context-expressions.adoc[leveloffset=+3] +include::modules/decision-services/con-dmn-relation-expressions.adoc[leveloffset=+3] +include::modules/decision-services/con-dmn-function-expressions.adoc[leveloffset=+3] +include::modules/decision-services/con-dmn-invocation-expressions.adoc[leveloffset=+3] +include::modules/decision-services/con-dmn-list-expressions.adoc[leveloffset=+3] +include::modules/decision-services/ref-dmn-model-example.adoc[leveloffset=+2] +include::modules/decision-services/proc-dmn-model-creating.adoc[leveloffset=+1] +include::modules/decision-services/proc-dmn-logic-defining.adoc[leveloffset=+2] +include::modules/decision-services/proc-dmn-data-types-defining.adoc[leveloffset=+2] +include::modules/decision-services/con-dmn-documentation.adoc[leveloffset=+2] +include::modules/decision-services/ref-dmn-designer-nav.adoc[leveloffset=+2] +include::modules/creating-running/con-kogito-service-execution.adoc[leveloffset=+1] + +ifdef::parent-context[:context: {parent-context}] +ifndef::parent-context[:!context:] diff --git a/assemblies/assembly-kogito-using-drl.adoc b/assemblies/assembly-kogito-using-drl.adoc new file mode 100644 index 0000000..f4bb52c --- /dev/null +++ b/assemblies/assembly-kogito-using-drl.adoc @@ -0,0 +1,37 @@ +ifdef::context[:parent-context: {context}] + +[id='assembly-kogito-using-drl'] += Using DRL rules in {PRODUCT} services +:context: drl-rules + +As a developer of business decisions, you can define business rules using Drools Rule Language (DRL) directly in free-form `.drl` text files. A DRL file can contain one or more rules that define at a minimum the rule conditions (`when`) and actions (`then`). + +include::modules/decision-services/con-drl.adoc[leveloffset=+1] +include::modules/decision-services/con-drl-packages.adoc[leveloffset=+2] +include::modules/decision-services/con-drl-rule-units.adoc[leveloffset=+2] +include::modules/decision-services/con-drl-imports.adoc[leveloffset=+2] +include::modules/decision-services/con-drl-declarations.adoc[leveloffset=+2] +include::modules/decision-services/con-drl-declarations-without-metadata.adoc[leveloffset=+3] +include::modules/decision-services/con-drl-declarations-enumerative.adoc[leveloffset=+3] +include::modules/decision-services/con-drl-declarations-extended.adoc[leveloffset=+3] +include::modules/decision-services/con-drl-declarations-with-metadata.adoc[leveloffset=+3] +include::modules/decision-services/ref-drl-declarations-metadata-tags.adoc[leveloffset=+3] +include::modules/decision-services/con-drl-queries.adoc[leveloffset=+2] +include::modules/decision-engine/con-property-change-listeners.adoc[leveloffset=+3] +include::modules/decision-services/ref-rules-attributes.adoc[leveloffset=+2] +include::modules/decision-services/con-drl-rules-conditions.adoc[leveloffset=+2] +include::modules/decision-services/ref-drl-operators.adoc[leveloffset=+3] +include::modules/decision-services/ref-drl-operator-precedence.adoc[leveloffset=+3] +include::modules/decision-services/ref-drl-rules-conditions-elements.adoc[leveloffset=+3] +ifdef::KOGITO-COMM[] +include::modules/decision-services/ref-drl-rules-conditions-elements-diagrams.adoc[leveloffset=+3] +endif::[] +include::modules/decision-services/con-drl-rules-actions.adoc[leveloffset=+2] +include::modules/decision-services/con-drl-rules-comments.adoc[leveloffset=+2] +include::modules/decision-services/ref-drl-rules-errors.adoc[leveloffset=+2] +include::modules/decision-services/con-drl-legacy.adoc[leveloffset=+2] +include::modules/decision-services/proc-drl-rules-create.adoc[leveloffset=+1] +include::modules/creating-running/con-kogito-service-execution.adoc[leveloffset=+1] + +ifdef::parent-context[:context: {parent-context}] +ifndef::parent-context[:!context:] diff --git a/assemblies/assembly-kogito-using-spreadsheet-decision-tables.adoc b/assemblies/assembly-kogito-using-spreadsheet-decision-tables.adoc new file mode 100644 index 0000000..8bead8f --- /dev/null +++ b/assemblies/assembly-kogito-using-spreadsheet-decision-tables.adoc @@ -0,0 +1,17 @@ +ifdef::context[:parent-context: {context}] + +[id='assembly-kogito-using-spreadsheet-decision-tables'] += Using spreadsheet decision tables in {PRODUCT} services +:context: decision-tables + +As a developer of business decisions, you can define business rules in a tabular format in spreadsheet decision tables and then include the spreadsheet file in your {PRODUCT} project. These rules are compiled into Drools Rule Language (DRL) for the decision service in your project. + +include::modules/decision-services/con-decision-tables.adoc[leveloffset=+1] +include::modules/decision-services/con-decision-tables-use-case.adoc[leveloffset=+1] +include::modules/decision-services/proc-decision-tables-creating.adoc[leveloffset=+1] +include::modules/decision-services/ref-decision-tables-rule-set-entries.adoc[leveloffset=+2] +include::modules/decision-services/ref-decision-tables-rule-table-entries.adoc[leveloffset=+2] +include::modules/decision-services/ref-decision-tables-attributes.adoc[leveloffset=+2] + +ifdef::parent-context[:context: {parent-context}] +ifndef::parent-context[:!context:] diff --git a/assemblies/modules/configuration/con-data-index-service.adoc b/assemblies/modules/configuration/con-data-index-service.adoc new file mode 100644 index 0000000..81501e6 --- /dev/null +++ b/assemblies/modules/configuration/con-data-index-service.adoc @@ -0,0 +1,53 @@ +[id='con-data-index-service_{context}'] += {PRODUCT} Data Index Service + +{PRODUCT} provides a Data Index Service that stores all {PRODUCT} events related to processes, tasks, and domain data. The Data Index Service uses Apache Kafka messaging to consume https://cloudevents.io/[CloudEvents] messages from {PRODUCT} services, and then indexes the returned data for future GraphQL queries and stores the data in the Infinispan persistence store. The Data Index Service is at the core of all {PRODUCT} search, insight, and management capabilities. + +.Data Index Service architecture in an example {PRODUCT} service +image::kogito/configuration/data-index-architecture.jpg[Diagram of an example Kogito service using Data Index Service] + +The {PRODUCT} Data Index Service has the following key attributes: + +* Distinct focus on domain data +* Flexible data structure +* Distributable and cloud-ready format +* Infinispan-based persistence support +* Message-based communication with {PRODUCT} runtime (Apache Kafka, cloud events ) +* Powerful querying API using GraphQL + +NOTE: The {PRODUCT} Data Index Service is not intended for permanent storage or audit log purposes. The Data Index Service is designed to make business domain data accessible for processes that are currently in progress. + +== Data Index Service workflow in {PRODUCT} + +The {PRODUCT} Data Index Service is a Quarkus application, based on https://vertx.io/[Vert.x] with https://smallrye.io/smallrye-reactive-messaging/[Reactive Messaging], that exposes a https://graphql.org[GraphQL] endpoint that client applications use to access business domain-specific data and other information about running process instances. + +The Data Index Service uses Apache Kafka messaging to consume https://cloudevents.io/[CloudEvents] messages from {PRODUCT} services, and then indexes the returned data for future GraphQL queries. These events contain information about units of work executed for a process. + +Indexed data from the Data Index Service is parsed and pushed into the following Infinispan caches: + +* *Domain cache*: Generic cache for each process definition where the process instance variables are pushed as the root content. This cache also includes some process instance metadata, which enables data correlation between domain and process instances. Data is transferred in JSON format to an Infinispan server. +* *Process instance cache*: Cache for each process instance. This cache contains all process instance information, including all metadata and other detailed information such as executed nodes. +* *User task instance cache*: Cache for each user task instance. This cache contains all task instance information, including all metadata and other detailed information such as data input and output. + +The indexing functionality in the Data Index Service is based on https://lucene.apache.org/[Apache Lucene], and storage for the Data Index Service is provided by https://infinispan.org/[Infinispan]. Communication between the Data Index Service and Infinispan is handled through a protobuf (https://developers.google.com/protocol-buffers/[protocol buffers]) schema and generated marshallers. + +After the data is indexed and stored in a cache, the Data Index Service inspects the process model to update the GraphQL schema and enable a type-checked query system that consumer clients can use to access the data. + +.Infinispan indexing +[NOTE] +==== + +Infinispan also supports data indexing through an embedded Apache Lucene engine. To determine which attributes must be indexed, Inifinispan requires `@Indexed` and `@Field` Hibernate Search parameters that annotate the relevant protobuf file attributes: + +.Example indexed model in Infinispan server configuration +[source] +---- +/* @Indexed */ +message ProcessInstanceMeta { + /* @Field(store = Store.YES) */ + optional string id = 1; +} +---- + +For more information about Infinispan indexing, see https://infinispan.org/docs/stable/titles/developing/developing.html#enable_indexing[Indexing of protobuf encoded entries] in the Infinispan documentation. +==== diff --git a/assemblies/modules/configuration/con-jobs-service.adoc b/assemblies/modules/configuration/con-jobs-service.adoc new file mode 100644 index 0000000..7e0cbb0 --- /dev/null +++ b/assemblies/modules/configuration/con-jobs-service.adoc @@ -0,0 +1,234 @@ +[id='con-jobs-service_{context}'] += {PRODUCT} Jobs Service + +{PRODUCT} provides a Jobs Service for scheduling Business Process Model and Notation (BPMN) process events that are configured to be executed at a specified time. These time-based events in a process model are known as _jobs_. + +By default, {PRODUCT} services use an in-memory timer service to handle jobs defined in your BPMN process models. This default timer service does not cover long time intervals and is only suitable for short delays defined in the process. For advanced use cases where time intervals can be days or weeks or when additional event handling options are required, you can configure your {PRODUCT} project to use the {PRODUCT} Jobs Service as an external timer service. + +The Jobs Service does not execute a job, but triggers a callback that might be an HTTP request on an endpoint specified for the job request or any other configured callback. The Jobs Service receives requests for job scheduling and then sends a request at the time specified on the job request. + +.Jobs Service architecture +image::kogito/configuration/jobs-service-architecture.png[Diagram of the Jobs Service architecture] + +NOTE: The {PRODUCT} Jobs Service currently supports only HTTP `POST` requests that are sent to an endpoint specified on the job-scheduling request. The HTTP callback information must be specified in the job-scheduling request. + +The main goal of the Jobs Service is to work with only active jobs. The Jobs Service tracks only the jobs that are scheduled and that need to be executed. When a job reaches a final state, the job is removed from the Jobs Service. All job information and transition states are sent to the {PRODUCT} Data Index Service where they can be indexed and made available for GraphQL queries. + +The Jobs Service implementation is based on non-blocking APIs and https://smallrye.io/smallrye-reactive-messaging/[Reactive Messaging] on top of Quarkus, which provides effective throughput and resource utilization. The scheduling engine is implemented on top of https://vertx.io/[Vert.x] and the external requests are built using a non-blocking HTTP client based on Vert.x. + +== Supported job states in the {PRODUCT} Jobs Service + +The {PRODUCT} Jobs Service uses an internal state control mechanism to manage the job scheduling life cycle using the following supported job states: + +* *Scheduled* +* *Executed* +* *Canceled* +* *Retry* +* *Error* + +The Jobs Service workflow through these states is illustrated in the following diagram: + +.Jobs Service state control workflow +image::kogito/configuration/jobs-service-state-control.png[Diagram of Jobs Service states] + +== Supported job types in the {PRODUCT} Jobs Service + +The {PRODUCT} Jobs Service supports the following job types: + +* *Time scheduled*: A job that is scheduled at a specified time and executed only once when that point in time is reached. The time must be specified on the job scheduling request and must be in the future. +* *Periodic scheduled*: A job that is scheduled at a specified time and executed after a specified interval, and then executed repeatedly over a specified period of time until a limit of executions is reached. The execution limit and interval must be specified in the job-scheduling request. + +== Supported configuration properties in the {PRODUCT} Jobs Service + +The {PRODUCT} Jobs Service supports the following configuration properties. You can set these properties either using the `-D` prefix during Jobs Service start-up or in the `src/main/resources/application.properties` file of the Jobs Service project. + +.Supported configuration properties in Jobs Service +[cols="30%,40%,15%,15%"] +|=== +|Name |Description |Value |Default + +|`kogito.jobs-service.persistence` +|Identifies the persistence mechanism used by the Jobs Service. +|`in-memory`, `infinispan` +|`in-memory` + +|`kogito.jobs-service.backoffRetryMillis` +|Defines the retry back-off time in milliseconds between job execution attempts, in case the execution fails +|Long type +|`1000` + +|`kogito.jobs-service.maxIntervalLimitToRetryMillis` +|Defines the maximum interval in milliseconds when retrying to execute jobs, in case the execution fails +|Long type +|`60000` + +|`mp.messaging.outgoing.kogito-job-service-job-status-events.bootstrap.servers` +|Identifies the Kafka bootstrap server address with the port used to publish events +|String +|`localhost:9092` + +|`mp.messaging.outgoing.kogito-job-service-job-status-events.topic` +|Defines the name of the Kafka topic where the events are published +|String +|`kogito-jobs-events` +|=== + +//// +// @comment: These endpoints are used internally by Jobs Service and may confuse users who think they need to use them in some way. Excluding for now. (Stetson, 1 Apr 2020) +### Usage + +The basic actions on Job Service are made through REST as follow: + +#### Schedule a Job + +POST + +{url-job-service}{jobs-path} + +``` +{ + "id": "1", + "priority": "1", + "expirationTime": "2019-11-29T18:16:00Z", + "callbackEndpoint": "http://localhost:8080/callback" +} +``` + +Example: +[subs="attributes"] + curl -X POST \ + {url-job-service}{jobs-path}/ \ + -H 'Content-Type: application/json' \ + -d '{ + "id": "1", + "priority": "1", + "expirationTime": "2019-11-29T18:16:00Z", + "callbackEndpoint": "http://localhost:8080/callback" +}' + +{sp} + + +#### Reschedule a Job + +POST + +{url-job-service}{jobs-path} + +``` +{ + "id": "1", + "priority": "1", + "expirationTime": "2019-11-29T18:19:00Z", + "callbackEndpoint": "http://localhost:8080/callback" +} +``` + +Example: +[subs="attributes"] + curl -X POST \ + {url-job-service}{jobs-path}/ \ + -H 'Content-Type: application/json' \ + -d '{ + "id": "1", + "priority": "1", + "expirationTime": "2019-11-29T18:19:00Z", + "callbackEndpoint": "http://localhost:8080/callback" +}' + +{sp} + + +#### Cancel a scheduled Job + +DELETE + +{url-job-service}{jobs-path}/1 + +Example: +[subs="attributes"] + curl -X DELETE {url-job-service}{jobs-path}/1 + +{sp} + + +#### Retrieve a scheduled Job + +GET + +{url-job-service}{jobs-path}/1 + +Example: +[subs="attributes"] + curl -X GET {url-job-service}{jobs-path}/1 + +{sp} + + +--- +//// + + +//// +//@comment: Excluded for now because underlying details that might confuse the user when trying to understand how to actually use it. (Stetson, 1 Apr 2020) +# Kogito Job Service add-ons + +Addons are specific classes that provides integration with Kogito Job Service to the runtime services. +This allows to use Job Service as a timer service for process instances. +Whenever there is a need to schedule timer as part of process instance it will be scheduled in the Job Service and the job service will callback the service upon timer expiration. + +The general implementation of the add-on is as follows: + +* an implementation of `org.kie.kogito.jobs.JobsService` interface that is used by the service to schedule jobs +* REST endpoint registered on `/management/jobs` path + +## Configuration properties + +Regardless of the runtime being used following are two configuration properties that are expected (and by that are mandatory) + +[cols="40%,400%,20%"] +|=== +|Name |Description |Example + +|`kogito.service.url` +|A URL that identifies where the service is deployed to. Used by runtime events to set the source of the event. +|http://localhost:8080 + +|`kogito.jobs-service.url` +|An URL that posts to a running Kogito Job Service, it is expected to be in form `scheme://host:port` +|http://localhost:8085 +|=== + +## JobService implementation + +A dedicated `org.kie.kogito.jobs.JobsService` implementation is provided based on the runtime being used (either Quarkus or SpringBoot) as it relies on the technology used in these runtime to optimise dependencies and integration. + +### Quarkus + +For Quarkus based runtimes, there is `org.kie.kogito.jobs.management.quarkus.VertxJobsService` implementation that utilises Vert.x `WebClient` to interact with Job Service over HTTP. + +It configures web client by default based on properties found in application.properties. +Though in case this is not enough it supports to provide custom instance of `io.vertx.ext.web.client.WebClient` type that will be used instead to communicate with Job Service. + +### Spring Boot + +For Spring Boot based runtimes, there is `org.kie.kogito.jobs.management.springboot.SpringRestJobsService` implementation that utilises Spring `RestTemplate` to interact with Job Service over HTTP. + +It configures rest template by default based on properties found in application.properties. +Though in case this is not enough it supports to provide custom instance of `org.springframework.web.client.RestTemplate` type that will be used instead to communicate with Job Service. + +## REST endpoint for callbacks + +The REST endpoint that is provided with the add-on is responsible for receiving the callbacks from Job Service at exact time when the timer was scheduled and by that move the process instance execution forward. + +The callback URL is given to the Job Service upon scheduling and as such does provide all the information that are required to move the instance + +* process id +* process instance id +* timer instance id + +NOTE: Timer instance id is build out of two parts - actual job id (in UUID format) and a timer id (a timer definition id generated by the process engine). +An example of a timer instance id is `62cad2e4-d343-46ac-a89c-3e313a30c1ad_1` where `62cad2e4-d343-46ac-a89c-3e313a30c1ad` is the UUID of the job and `1` is the timer definition id. +Both values are separated with `_` + +### API documentation + +The current API documentation is based on Swagger, and the service has an embedded UI available at +{url-job-service}/swagger-ui/[{url-job-service}/swagger-ui] +//// diff --git a/assemblies/modules/configuration/con-kogito-runtime-events.adoc b/assemblies/modules/configuration/con-kogito-runtime-events.adoc new file mode 100644 index 0000000..569b71f --- /dev/null +++ b/assemblies/modules/configuration/con-kogito-runtime-events.adoc @@ -0,0 +1,203 @@ +[id='con-kogito-runtime-events_{context}'] += {PRODUCT} runtime events + +A runtime event is record of a significant change of state in the application domain at a point in time. {PRODUCT} emits runtime events as a result of successfully executed requests, or _units of work_, in a process instance or task instance in a process. {PRODUCT} can use these events to notify third parties about changes to the BPMN process instance and its data. + +== Process instance events + +For every executed process instance, an event is generated that contains information for that instance, such as the following information: + +* Process instance metadata, such as the process definition ID, process instance ID, process instance state, and other identifying information +* Node instances that have been triggered during the execution +* Variables used and the current state of variables after the execution + +These events provide a complete view of the process instances being executed and can be consumed by an event listener, such as a `ProcessEventListener` configuration. + +If multiple processes are executed within a single request (unit of work), each process instance is given a dedicated event. + +The following event is an example process instance event generated after the request was executed successfully: + +.Example process instance event +[source,json] +---- +{ + "specversion": "0.3", + "id": "f52af50c-4fe2-4581-9184-7ad48137fb3f", + "source": null, + "type": "ProcessInstanceEvent", + "time": "2019-08-05T17:47:49.019494+02:00[Europe/Warsaw]", + "data": { + "id": "c1aced49-399b-4938-9071-b2ffa3fb7045", + "parentInstanceId": null, + "rootInstanceId": null, + "processId": "deals", + "processName": "SubmitDeal", + "startDate": 1565020069015, + "endDate": null, + "state": 1, + "nodeInstances": [ + { + "id": "a8fe24c4-27a5-4869-85df-16e9f170f2c4", + "nodeId": "2", + "nodeDefinitionId": "CallActivity_1", + "nodeName": "Call a deal", + "nodeType": "SubProcessNode", + "triggerTime": 1565020069015, + "leaveTime": null + }, + { + "id": "7a3bf1b1-b167-4928-969d-20bddf16c87a", + "nodeId": "1", + "nodeDefinitionId": "StartEvent_1", + "nodeName": "StartProcess", + "nodeType": "StartNode", + "triggerTime": 1565020069015, + "leaveTime": 1565020069015 + } + ], + "variables": { + "name": "my fancy deal", + "traveller": { + "firstName": "John", + "lastName": "Doe", + "email": "jon.doe@example.com", + "nationality": "American", + "address": { + "street": "main street", + "city": "Boston", + "zipCode": "10005", + "country": "US" + } + } + } + }, + "kogitoProcessinstanceId": "c1aced49-399b-4938-9071-b2ffa3fb7045", + "kogitoParentProcessinstanceId": null, + "kogitoRootProcessinstanceId": null, + "kogitoProcessId": "deals", + "kogitoProcessinstanceState": "1" +} +---- + +The event is in https://cloudevents.io/[CloudEvents] format so that it can be consumed efficiently by other entities. + +The event data also includes the following extensions to enable event routing based on the event metadata without requiring the body of the event: + +* `kogitoProcessinstanceId` +* `kogitoParentProcessinstanceId` +* `kogitoRootProcessinstanceId` +* `kogitoProcessId` +* `kogitoProcessinstanceState` + +== User task instance events + +If an executed request (unit of work) in a process instance interacts with a user task, an event is generated for that user task and contains information for the task instance, such as the following information: + +* Task metadata, such as the task description, priority, start and complete dates, and other identifying information +* Task input and output data +* Task assignments, such as the task owner, potential users and groups, business administrator and business administrator groups, or excluded users +* Task reference name that should be used to interact with the task using the {PRODUCT} service endpoints + +The following event is an example user task instance event generated after the relevant request was executed successfully: + +.Example user task instance event +[source,json] +---- +{ + "data": { + "adminGroups": [], + "adminUsers": [], + "excludedUsers": [], + "id": "4d899471-19dd-485d-b7f4-b313185d430d", + "inputs": { + "Locale": "en-UK", + "trip": { + "begin": "2019-09-22T22:00:00Z[UTC]", + "city": "Boston", + "country": "US", + "end": "2019-09-26T22:00:00Z[UTC]", + "visaRequired": true + }, + "TaskName": "VisaApplication", + "NodeName": "Apply for visa", + "Priority": "1", + "Skippable": "true", + "traveller": { + "address": { + "city": "Krakow", + "country": "Poland", + "street": "Polna", + "zipCode": "12345" + }, + "email": "jan.kowalski@email.com", + "firstName": "Jan", + "lastName": "Kowalski", + "nationality": "Polish" + } + }, + "outputs": {}, + "potentialGroups": [], + "potentialUsers": [], + "processId": "travels", + "processInstanceId": "63c297cb-f5ac-4e20-8254-02f37bd72b80", + "referenceName": "VisaApplication", + "startDate": "2019-09-16T15:22:26.658Z[UTC]", + "state": "Ready", + "taskName": "Apply for visa", + "taskPriority": "1" + }, + "id": "9c340cfa-c9b6-46f2-a048-e1114b077a7f", + "kogitoProcessId": "travels", + "kogitoProcessinstanceId": "63c297cb-f5ac-4e20-8254-02f37bd72b80", + "kogitoUserTaskinstanceId": "4d899471-19dd-485d-b7f4-b313185d430d", + "kogitoUserTaskinstanceState": "Ready", + "source": "http://localhost:8080/travels", + "specversion": "0.3", + "time": "2019-09-16T17:22:26.662592+02:00[Europe/Berlin]", + "type": "UserTaskInstanceEvent" +} +---- + +The event data also includes the following extensions to enable event routing based on the event metadata without requiring the body of the event: + +* `kogitoUserTaskinstanceId` +* `kogitoUserTaskinstanceState` +* `kogitoProcessinstanceId` +* `kogitoProcessId` + +== Event publishing + +{PRODUCT} generates events only when at least one publisher is configured. A {PRODUCT} service environment can have many event publishers that publish these events into different channels. + +By default, {PRODUCT} includes the following message-based event publishers, depending on your application framework: + +* *For Quarkus*: https://smallrye.io/smallrye-reactive-messaging/[Reactive Messaging] for sending events using Apache Kafka, Apache Camel, Advanced Message Queuing Protocol (AMQP), or MQ Telemetry Transport (MQTT) +* *For Spring Boot*: https://spring.io/projects/spring-kafka[Spring for Apache Kafka] for sending events using Kafka + +To enable or disable event publishing, you can adjust the following properties in the `src/main/resources/application.properties` file in your {PRODUCT} project: + +* `kogito.events.processinstances.enabled`: Enables or disables publishing for process instance events (default: `enabled`) +* `kogito.events.usertasks.enabled`: Enables or disables publishing for user task instance events (default: `enabled`) + +To develop additional event publishers, you can implement the `org.kie.kogito.event.EventPublisher` implementation and include the required annotations for JavaBeans discovery. + +//// +//@comment: Excluded for now because not yet supported in Kogito. Will be in its own topic. (Stetson, 1 Apr 2020) +## Registering work item handlers + +To be able to use custom service tasks a work item handler must be registered. Once the work item handler is implemented to can be either packaged in the application itself or as dependency of the application. + +`WorkItemHandlerConfig` class should be created to provide custom work item handlers. It must implement `org.kie.kogito.process.WorkItemHandlerConfig` although recommended is to always extend the default implementation (`org.kie.kogito.process.impl.DefaultWorkItemHandlerConfig`) to benefit from the out of the box provided handlers as well. + +[source, java] +---- +@ApplicationScoped +public class CustomWorkItemHandlerConfig extends DefaultWorkItemHandlerConfig {{ + register("MyServiceTask", new MyServiceWorkItemHandler()); +}} +---- + +NOTE: These classes are meant to be injectable so ensure you properly annotate the class (`@ApplicationScoped`/`@Component`) so they can be found and registered. + +You can also take advantage of life cycle method like `@PostConstruct` and `@PreDestroy` to manage your handlers. +//// diff --git a/assemblies/modules/configuration/con-kogito-supporting-services-and-configuration.adoc b/assemblies/modules/configuration/con-kogito-supporting-services-and-configuration.adoc new file mode 100644 index 0000000..ccc4392 --- /dev/null +++ b/assemblies/modules/configuration/con-kogito-supporting-services-and-configuration.adoc @@ -0,0 +1,22 @@ +[id='con-kogito-supporting-services-and-configuration_{context}'] += {PRODUCT} supporting services and runtime configuration + +{PRODUCT} supporting services consist of middleware infrastructure services and other dedicated services that help you build additional functionality in the {PRODUCT} domain-specific services that you create. + +{PRODUCT} supports the following key middleware infrastructure services: + +* Infinispan persistence +* Apache Kafka reactive messaging + +{PRODUCT} also provides the following dedicated services: + +* {PRODUCT} Data Index Service indexing and querying +* {PRODUCT} Jobs Service job scheduling + +The {PRODUCT} runtime supports various configuration options for these supporting services and for other capabilities, such as the following examples: + +* Custom event listeners +* Prometheus metrics monitoring +* Process instance management + +These supporting services, runtime configurations, and {PRODUCT} add-on components enable you to optimize your {PRODUCT} domain-specific services for your business automation requirements. diff --git a/assemblies/modules/configuration/con-persistence.adoc b/assemblies/modules/configuration/con-persistence.adoc new file mode 100644 index 0000000..0388cea --- /dev/null +++ b/assemblies/modules/configuration/con-persistence.adoc @@ -0,0 +1,98 @@ +[id='con-persistence_{context}'] += Persistence in {PRODUCT} services + +{PRODUCT} supports runtime persistence for preserving process data in your services across application restarts. {PRODUCT} persistence is based on https://infinispan.org/[Infinispan] and enables you to configure key-value storage definitions to persist data, such as active process nodes and process instance variables. + +Runtime persistence is intended primarily for storing data that is required to resume workflow execution for a particular process instance. Persistence applies to both public and private processes that are not yet complete. Once a process completes, persistence is no longer applied. This persistence behavior means that only the information that is required to resume execution is persisted. + +Node instances that are currently active or in wait states are persisted. When a process instance finishes execution but has not reached the end state (completed or aborted), the node instance data is persisted. + +== Persistence workflow in {PRODUCT} + +In {PRODUCT}, a process instance is persisted when the process reaches a wait state, where the process does not execute anymore but has not reached the end state (completed or aborted). + +For example, when a process reaches a user task or a catching signal event, the process instances pauses and the {PRODUCT} {PROCESS_ENGINE} takes a complete snapshot of the process, including the following data: + +* Process instance metadata, such as process instance ID, process definition ID, state, description, and start date +* Process instance variables +* Active node instances, including local variables + +Process instance metadata is persisted with a predefined protobuf (https://developers.google.com/protocol-buffers/[protocol buffers]) schema that is aware of the metadata and supports node instances that are in wait states. + +Process instance and node instance variables are persisted based on the generated protobuf schema and generated marshallers. Custom data types are also persisted during execution. + +For straight-through process instances that do not trigger any activity, persistence is not invoked and no data is stored. + +Each process definition has its own cache for storing runtime information. The cache is based on the process definition ID and is named in the Infinispan server. If no process cache exists, cache is automatically created in Infinispan. This setup facilitates maintenance of process instance data and reduces concurrency on the cache instances. + +== Persisted process instance variables and data types + +Persisted process variables, local variables, and other process data are stored with the process instance. The stored data is marshalled into bytes format so it can be transferred and persisted into the key-value storage definition. The marshalling and unmarshalling is implemented based on protobuf (https://developers.google.com/protocol-buffers/[protocol buffers]) and requires a schema and marshallers for handling a specified type of data. + +{PRODUCT} generates both the protobuf schema (as PROTO files) and marshallers for persisting variables. The {PRODUCT} marshallers are based on the https://github.com/infinispan/protostream[ProtoStream] subproject of Infinispan. + +When you build your {PRODUCT} project, {PRODUCT} scans all process definitions and extracts information about the data within the business assets. Based on the unique data types (regardless of how many processes reference a specified type), a PROTO file called `kogito-application.proto` is generated that builds a complete schema for the application. This file is stored in the `target/classes/persistence/` folder of your project after successful build. + +.Example PROTO file generated by {PRODUCT} to persist process data +[source] +---- +syntax = "proto2"; +package org.kie.kogito.examples; +import "kogito-types.proto"; + +message Order { + option java_package = "org.kie.kogito.examples.demo"; + optional string orderNumber = 1; + optional bool shipped = 2; + optional double total = 3; +} +message Person { + option java_package = "org.kie.kogito.examples.demo"; + optional bool adult = 1; + optional int32 age = 2; + optional string name = 3; +} +---- + +NOTE: Each `kogito-application.proto` file imports a `kogito-types.proto` file that automatically defines the base types managed by {PRODUCT}. + +Based on the `kogito-application.proto` file, marshallers are also generated and configured in the application so that whenever a particular data type is used in a process instance, the data is successfully marshalled and unmarshalled. + +== Supported data types for persisted variables + +For optimal persistence with process data and variables, use Java objects as data types that represent your process variables. If you use other formats for data types, your data might not be persisted or your {PRODUCT} project might fail to compile. + +{PRODUCT} currently supports the following data types for process variables: + +.Supported data types +[cols="30%,70%", options="header"] +|=== +|Data type |Description + +|`java.lang.String` +|Basic text type + +|`java.lang.Integer` +|Basic number type + +|`java.lang.Long` +|Extended size number type + +|`java.lang.Float` +|Basic floating point number type + +|`java.lang.Double` +|Extended size floating point number type + +|`java.util.Date` +|Basic date type + +|Java object +|Custom data type built with multiple simple types + +|Java object with a Java object +|Custom data type built with multiple simple types and includes another Java object + +|Java object with a list of Java objects +|Custom data type built with multiple simple types and a list of Java objects, and can also contain another Java object +|=== diff --git a/assemblies/modules/configuration/con-task-life-cycle.adoc b/assemblies/modules/configuration/con-task-life-cycle.adoc new file mode 100644 index 0000000..79055f8 --- /dev/null +++ b/assemblies/modules/configuration/con-task-life-cycle.adoc @@ -0,0 +1,156 @@ +[id='con-task-life-cycle_{context}'] += Task life cycle in {PRODUCT} processes + +In {PRODUCT} business processes, tasks are implemented as work items and their execution is defined by work item handlers. User tasks in particular are a core construct in {PRODUCT} processes. When a user task is reached in a process, the task progresses through phases of a defined life cycle until it reaches an end state. + +{PRODUCT} supports the following default phases in a work item (task) life cycle: + +* *Active*: Indicates initial state when the work item is activated +* *Abort*: Indicates abnormal completion of the work item +* *Complete*: Indicates normal completion of the work item +* *Claim*: Assigns the work item to a specific actor, restricting access to anyone else +* *Release*: Unassigns the work item from a specific actor, releasing it to any other potential user or group to work on it (by claiming or completing) +* *Skip*: Skips the work item + +With {PRODUCT}, you can also add custom life cycles and life cycle phases to meet your business needs. + +A life cycle moves a work item across various phases that are not defined by the `WorkItem` interface and defines the behavior of a work item at runtime. You typically add a life cycle on top of the `WorkItemHandler` interface so that the life cycle is pluggable with more flexible runtime characteristics. + +The `WorkItemHandler` interface provides the option to move between task phases, as shown in the following method example: + +.WorkItemHandler support for moving between task phases +[source, java] +---- +public void transitionToPhase(WorkItem workItem, WorkItemManager manager, Transition transition) +---- + +NOTE: This method is a default method that does nothing when not implemented. This functionality maintains backward compatibility with existing work item handler implementations. + +You typically implement the `transitionToPhase` method as shown in the following example: + +.Example implementation of transitionToPhase method +[source, java] +---- +@Override +public void transitionToPhase(WorkItem workItem, WorkItemManager manager, Transition transition) { + + lifeCycle.transitionTo(workItem, manager, (Transition>) transition); +} +---- + +The `lifeCycle` element is an implementation of `org.kie.{PRODUCT_INIT}.process.workitem.LifeCycle` that defines the execution semantics. + +== User task authorization + +The `org.jbpm.process.instance.impl.humantask.BaseHumanTaskLifeCycle` implementation in {PRODUCT} ensures that a user task is worked on by authorized users, based on the user or group assignments that you provide. + +You can use the following parameters to provide assignments for authorized users or groups in the relevant BPMN process model. All of the listed parameters support expressions. + +.Parameters for authorized users or groups +[cols="35%,35%,30%"] +|=== +|Parameter name |Description |Example value + +|`ActorId` +|Comma-separated list of authorized users +|`John,Mary,#{actor}` + +|`GroupId` +|Comma-separated list of authorized groups of users +|`mangers,#{mygroup}` + +|`BusinessAdministratorId` +|Comma-separated list of authorized administrators +|`administrator,#{adminuser}` + +|`BusinessAdministratorGroupId` +|Comma-separated list of groups of administrators +|`admins,#{admingroup}` + +|`ExcludedOwnerId` +|Comma-separated list of unauthorized users who cannot work on this task +|`paul,#{lastactor}` +|=== + +NOTE: Authorization is only enforced when the method that calls the work item life cycle methods uses a security context. This security behavior is dependent on the API that you use. + +== API interaction with task life cycle phases + +The following example API interacts with user tasks (work items) using life cycle phases: + +.Example API to interact with task life cycle phases +[source, java] +---- +// Start process instance +ProcessInstance processInstance = approvalsProcess.createInstance(m); +processInstance.start(); + +// Set up security policy with identity information +StaticIdentityProvider identity = new StaticIdentityProvider("admin", Collections.singletonList("managers")); +SecurityPolicy policy = SecurityPolicy.of(identity); + +// Get list of work items, taking security restrictions into account +List workItems = processInstance.workItems(policy); + +// Work on a task +final String wiId = workItems.get(0).getId(); +processInstance.transitionWorkItem(wiId, + new HumanTaskTransition(Claim.ID, null, policy)); + +processInstance.transitionWorkItem(wiId, + new HumanTaskTransition(Complete.ID, Collections.singletonMap("approved", false), policy)); +---- + +When you interact with user tasks through a REST API, you can also provide the following query parameters for user and group information: + +.Query parameters for user or group information in REST APIs +[cols="20%,60%,20%"] +|=== +|Parameter name |Description |Multi-value support + +|`user` +|User name to be used for the user task authorization check +|No + +|`group` +|Zero or more group names to be used for the user task authorization check +|Yes +|=== + +For example, the following REST endpoints interact with user tasks in an `orderItems.bpmn2` process for verifying customer orders: + +.Example GET request to retrieve open tasks using the process UUID +[source] +---- +curl -X GET http://localhost:8080/orderItems/66c11e3e-c211-4cee-9a07-848b5e861bc5/tasks +---- + +.Example response +[source] +---- +{"62f1c985-d31c-4ead-9906-2fe8d05937f0":"Verify order"} +---- + +.Example GET request to retrieve task details by process and task UUID +[source,subs="+quotes"] +---- +curl -X GET http://localhost:8080/orderItems/66c11e3e-c211-4cee-9a07-848b5e861bc5/Verify_order/62f1c985-d31c-4ead-9906-2fe8d05937f0 +---- + +.Example response +[source] +---- +{"id":"62f1c985-d31c-4ead-9906-2fe8d05937f0","input1":{"orderNumber":"12345","shipped":false,"total":0.537941914075738},"name":"Verify order"} +---- + +.Example POST request to complete the task and define the authorized group and user +[source] +---- +curl -X POST http://localhost:8080/orderItems/66c11e3e-c211-4cee-9a07-848b5e861bc5/Verify_order/62f1c985-d31c-4ead-9906-2fe8d05937f0?group=managers&user=john -H "accept: application/json" -H "content-type: application/json" +---- + +.Example response +[source] +---- +{"id":"66c11e3e-c211-4cee-9a07-848b5e861bc5","order":{"orderNumber":"12345","shipped":false,"total":0.537941914075738}} +---- diff --git a/assemblies/modules/configuration/proc-data-index-service-security.adoc b/assemblies/modules/configuration/proc-data-index-service-security.adoc new file mode 100644 index 0000000..5ea5daa --- /dev/null +++ b/assemblies/modules/configuration/proc-data-index-service-security.adoc @@ -0,0 +1,58 @@ +[id='proc-data-index-service-security_{context}'] += Enabling {PRODUCT} Data Index Service security with OpenID Connect + +For Quarkus-based {PRODUCT} services, you can use the https://quarkus.io/guides/security-openid-connect[Quarkus OpenID Connect adapter] with the {PRODUCT} Data Index Service to enable security using bearer token authorization. These tokens are issued by OpenID Connect and OAuth 2.0 compliant authorization servers such as https://www.keycloak.org/about.html[Keycloak]. + +IMPORTANT: This procedure applies only when you are using a locally cloned copy of the https://github.com/kiegroup/kogito-runtimes/data-index[{PRODUCT} Data Index Service] repository in GitHub. + +.Prerequisites +* You have cloned the https://github.com/kiegroup/kogito-runtimes/data-index[{PRODUCT} Data Index Service] repository from GitHub. + +.Procedure +. In a command terminal, navigate to the local clone of the {PRODUCT} Data Index Service repository and enter the following command to run the application with the required security properties: ++ +-- +.Run the Data Index Service with security properties +[source] +---- +mvn clean compile quarkus:dev \ + -Dquarkus.profile=keycloak \ + -Dkogito.protobuf.folder=/home/git/kogito-runtimes/data-index/data-index-service/src/test/resources \ + -Dkogito.protobuf.watch=true +---- + +The Data Index Service contains a Quarkus profile to encapsulate the security configuration, so if the +service requires enabled security, you can specify the `quarkus.profile=keycloak` property at build time to enable the needed security. If the `keycloak` Quarkus profile is not added, the OpenID Connect extension is disabled. +-- +. Navigate to the `src/man/resources/application.properties` file of the Data Index Service project and add the following properties: ++ +-- +.Required security properties in `applications.properties` file +[source] +---- +%keycloak.quarkus.oidc.enabled=true +%keycloak.quarkus.oidc.auth-server-url=http://localhost:8280/auth/realms/kogito +%keycloak.quarkus.oidc.client-id=kogito-data-index-service +%keycloak.quarkus.oidc.credentials.secret=secret +%keycloak.quarkus.http.auth.policy.role-policy1.roles-allowed=confidential +%keycloak.quarkus.http.auth.permission.roles1.paths=/graphql +%keycloak.quarkus.http.auth.permission.roles1.policy=role-policy1 +---- + +Replace any property definitions with those of your specific environment, especially the following properties: + +* `quarkus.oidc.auth-server-url`: The base URL of the OpenID Connect (OIDC) server, such as `https://localhost:8280/auth`. All other OIDC server page and service URLs are derived from this URL. If you work with Keycloak OIDC server, ensure that the base URL is in the following format: `https://__HOST__:__PORT__/auth/realms/__KEYCLOAK_REALM__`. +* `quarkus.oidc.client-id`: The client ID of the application. Each application has a client ID that is used to identify the application. +* `quarkus.oidc.credentials.secret`: The client secret for the applicaiton. +-- +. In the same `application.properties`, also configure the resources to be exposed and the required permissions for accessing the resources. ++ +-- +This example configuration enables only users with role `confidential` to access a single `/graphql` endpoint. + +For more information about configuring endpoints and permissiones, see https://quarkus.io/guides/security#authorization-of-web-endpoints-using-configuration[Authorization of Web Endpoints using configuration] in the Quarkus documentation. + +NOTE: When you configure OpenID Connect security as a service in your application (`quarkus.oidc.application-type=service`), the GraphiQL interface is unavailable. To support the GraphiQL interface, you must configure the application as a web application (`quarkus.oidc.application-type=web-app`). + +-- +. Stop and restart the the Data Index Service application to apply the changes. diff --git a/assemblies/modules/configuration/proc-data-index-service-using.adoc b/assemblies/modules/configuration/proc-data-index-service-using.adoc new file mode 100644 index 0000000..c42e2bc --- /dev/null +++ b/assemblies/modules/configuration/proc-data-index-service-using.adoc @@ -0,0 +1,97 @@ +[id='proc-data-index-service-using_{context}'] += Using the {PRODUCT} Data Index Service to query application data + +{PRODUCT} provides a Data Index Service that stores all {PRODUCT} events related to processes, tasks, and domain data. The Data Index Service uses Kafka messaging to consume https://cloudevents.io/[CloudEvents] messages from {PRODUCT} services, and then indexes the returned data for future GraphQL queries and stores the data in the Infinispan persistence store. The Data Index Service is at the core of all {PRODUCT} search, insight, and management capabilities. + +You can use the {PRODUCT} Data Index Service to index, store, and query process data in your {PRODUCT} services. + +.Prerequisites +* https://infinispan.org/[Infinispan server] 10.0 or later is installed and running. For information about Infinispan installation and configuration, see the https://infinispan.org/documentation/[Infinispan documentation]. +* https://kafka.apache.org/[Apache Kafka] is installed, including required topics, and the Kafka messaging server is running. For information about Kafka installation and configuration, see the https://kafka.apache.org/documentation/[Apache Kafka documentation]. ++ +-- +For a list of configuration options for setting up the Kafka consumer, see https://kafka.apache.org/documentation/#consumerconfigs[Consumer Configs] in the Kafka documentation. + +For more information about using Kafka messaging on Quarkus, see https://quarkus.io/guides/kafka[Using Apache Kafka with reactive messaging] in the Quarkus documentation. +-- + +.Procedure +. Configure your {PRODUCT} project to enable Infinispan persistence and Apache Kafka messaging. ++ +-- +For instructions on enabling persistence, see xref:proc-persistence-enabling_kogito-configuring[]. + +For instructions on enabling messaging, see xref:proc-messaging-enabling_kogito-configuring[]. +-- +. Go to the https://repository.jboss.org/org/kie/kogito/data-index-service/[`data-index-service`] artifacts page, select the latest release of the Data Index Service, and download the `data-index-service-__VERSION__-runner.jar` file to a local directory. +. In a command terminal, navigate to the directory location of the downloaded `data-index-service-__VERSION__-runner.jar` file and enter the following command to run the Data Index Service with the required Infinispan credentials: ++ +-- +.Running the Data Index Service +[source,subs="+quotes"] +---- +$ java \ + -Dquarkus.infinispan-client.auth-username=__INFINISPAN_USER_NAME__ \ + -Dquarkus.infinispan-client.auth-password=__INFINISPAN_PASSWORD__ \ + -jar data-index-service-__VERSION__-runner.jar +---- + +For more information about Infinispan authentication on Quarkus, see https://quarkus.io/guides/infinispan-client[Infinispan client] in the Quarkus documentation. + +To change the logging level of the Data Index Service, such as for debugging, you can specify the following start-up properties as needed when you run the Data Index Service: + +.Modifying Data Index Service logging level for debugging +[source,subs="+quotes"] +---- +$ java \ + -Dquarkus.log.console.level=DEBUG -Dquarkus.log.category.\"org.kie.kogito\".min-level=DEBUG \ + -Dquarkus.log.category.\"org.kie.kogito\".level=DEBUG \ + -jar data-index-service-__VERSION__-runner.jar +---- +-- +. In a separate command terminal window, navigate to your {PRODUCT} project and run the project using your preferred run mode, such as development mode: ++ +-- +.On Quarkus +[source] +---- +mvn clean compile quarkus:dev +---- + +.On Sprint Boot +[source] +---- +mvn clean compile spring-boot:run +---- + +With the Data Index Service and your {PRODUCT} project both configured and running, the Data Index Service starts consuming messages from the defined Kafka topics, such as `kogito-processinstances-events`. +-- +. In a web browser, navigate to the `http://__HOST__:__PORT__` location configured for your running {PRODUCT} service, such as `\http://localhost:8080/`, to explore the exposed data model. ++ +-- +To query the available data using the https://github.com/graphql/graphiql[GraphiQL] interface, navigate to `http://__HOST__:__PORT__/graphql`, such as `\http://localhost:8080/graphql` in this example, and begin executing supported queries to interact with your application data. + +.Example query for process instance data +[source] +---- +{ ProcessInstances { + id, + processId, + processName, + state, + nodes { + name, + type, + enter, + exit + } +} } +---- + +.Example response +image::kogito/openshift/kogito-data-index-graphiql-process-instances.png[Image of GraphQL query and response for process instances] + +For available query types, click *Docs* in the upper-right corner of the GraphiQL interface. + +For more information about supported queries with the Data Index Service, see xref:ref-data-index-service-queries_kogito-configuring[]. +-- diff --git a/assemblies/modules/configuration/proc-event-listeners-registering.adoc b/assemblies/modules/configuration/proc-event-listeners-registering.adoc new file mode 100644 index 0000000..4f685d1 --- /dev/null +++ b/assemblies/modules/configuration/proc-event-listeners-registering.adoc @@ -0,0 +1,45 @@ +[id='proc-event-listeners-registering_{context}'] += Registering event listeners + +You can register custom event listeners to detect and publish events that are not published by {PRODUCT} by default. Your custom event listener configuration must implement the relevant implementation for either processes or rules. + +.Procedure +. Create an event listener configuration class for either process or rule events, such as a `ProcessEventListenerConfig` class or a `RuleEventListenerConfig` class. +. In your event listener configuration class, extend the default implementation of the configuration class as part of your listener definition: ++ +-- +* Implementation for process events: `org.kie.kogito.process.impl.DefaultProcessEventListenerConfig` +* Implementation for rule events: `org.drools.core.config.DefaultRuleEventListenerConfig` + +.Example process event listener with extended default implementation +[source, java] +---- +@ApplicationScoped +public class ProcessEventListenerConfig extends DefaultProcessEventListenerConfig { + + public ProcessEventListenerConfig() { + super(new CustomProcessEventListener()); + } +} +---- + +.Example rule event listener with extended default implementation +[source, java] +---- +@ApplicationScoped +public class RuleEventListenerConfig extends DefaultRuleEventListenerConfig { + + public RuleEventListenerConfig() { + super(new CustomRuleEventListener()); + } +} +---- + +NOTE: These configuration classes must be injectable, so ensure that you properly annotate the classes, such as with the annotations `@ApplicationScoped` or `@Component`, so that they can be found and registered. + +Alternatively, you can implement the relevant event listener interface instead of extending the default implementation, but this approach excludes other listeners provided by {PRODUCT}. + +* Interface for process events: `org.kie.kogito.process.ProcessEventListenerConfig` +* Interface for rule events: `org.kie.kogito.rules.RuleEventListenerConfig` +-- +. After the event listener is configured, package the listener configuration class in the `src/main/java` folder of the relevant application or add it as dependency in the `pom.xml` file of the application to make the listener available. diff --git a/assemblies/modules/configuration/proc-jobs-service-messaging.adoc b/assemblies/modules/configuration/proc-jobs-service-messaging.adoc new file mode 100644 index 0000000..e7ad95d --- /dev/null +++ b/assemblies/modules/configuration/proc-jobs-service-messaging.adoc @@ -0,0 +1,29 @@ +[id='proc-jobs-service-messaging_{context}'] += Enabling Kafka messaging in the {PRODUCT} Jobs Service + +The {PRODUCT} Jobs Service supports Apache Kafka messaging to publish events for each job state transition to a defined Kafka topic. Any application can subscribe to this Kafka topic to receive information about jobs and job state transitions. For example, the {PRODUCT} Data Index Service is subscribed to the Jobs Service Kafka topic so that if you configure and run the Jobs Service, the Data Index Service can begin indexing jobs with their current state. + +You can enable Kafka messaging in the {PRODUCT} Jobs Service during application start-up and in the Jobs Service `application.properties` file. + +.Procedure +. In the `src/main/resources/application.properties` file in the Jobs Service project, add the following properties to identify the Kafka bootstrap server with the port used to publish events and the Kafka topic where the events are published: ++ +.Defining Kafka server and topic in Jobs Service `application.properties` +[source,subs="+quotes"] +---- +mp.messaging.outgoing.kogito-job-service-job-status-events.bootstrap.servers=__SERVER_ADDRESS__ +mp.messaging.outgoing.kogito-job-service-job-status-events.topic=__TOPIC_NAME__ +---- +. Run the Jobs Service with the property `-Dquarkus.profile=events-support`: ++ +-- +.Enabling Kafka messaging during Jobs Service start-up +[source,subs="+quotes"] +---- +$ java \ + -Dquarkus.profile=events-support \ + -jar jobs-service-__VERSION__-runner.jar +---- + +Alternatively, you can add the environment variable `QUARKUS_PROFILE=events-support`. +-- diff --git a/assemblies/modules/configuration/proc-jobs-service-persistence.adoc b/assemblies/modules/configuration/proc-jobs-service-persistence.adoc new file mode 100644 index 0000000..42b46b7 --- /dev/null +++ b/assemblies/modules/configuration/proc-jobs-service-persistence.adoc @@ -0,0 +1,24 @@ +[id='proc-jobs-service-persistence_{context}'] += Enabling Infinispan persistence in the {PRODUCT} Jobs Service + +The {PRODUCT} Jobs Service supports the following persistence mechanisms for job data: + +* *In-memory persistence*: (Default) Job data is persisted with the Jobs Service in-memory storage during the Jobs Service runtime. If the Jobs Service is restarted, all job information is lost. If no other persistence configuration is set, the Jobs Service uses this persistence mechanism. +* *Infinispan persistence*: Job data is persisted using Infinispan storage so that the data is preserved across application restarts. If the Jobs Service is restarted, the service continues to process any previously scheduled jobs. + +You can enable Infinispan persistence in the {PRODUCT} Jobs Service during application start-up and in the Jobs Service `application.properties` file. + +.Procedure +Run the Jobs Service with the property `-Dkogito.job-service.persistence=infinispan`: + +.Enabling Infinispan persistence during Jobs Service start-up +[source,subs="+quotes"] +---- +$ java \ + -Dkogito.job-service.persistence=infinispan \ + -jar jobs-service-__VERSION__-runner.jar +---- + +Alternatively, you can add the same property to the `src/main/resources/application.properties` file in the Jobs Service project. + +For more information about Infinispan configuration with Quarkus applications, see https://quarkus.io/guides/infinispan-client[Infinispan client] in the Quarkus documentation. diff --git a/assemblies/modules/configuration/proc-jobs-service-using.adoc b/assemblies/modules/configuration/proc-jobs-service-using.adoc new file mode 100644 index 0000000..bd62b25 --- /dev/null +++ b/assemblies/modules/configuration/proc-jobs-service-using.adoc @@ -0,0 +1,93 @@ +[id='proc-jobs-service-using_{context}'] += Using the {PRODUCT} Jobs Service as a timer service + +By default, {PRODUCT} services use an in-memory timer service to handle time-based events (jobs) defined in your Business Process Model and Notation (BPMN) process models. This default timer service does not cover long time intervals and is only suitable for short delays defined in the process. + +For advanced use cases where time intervals can be days or weeks or when additional event handling options are required, you can configure your {PRODUCT} project to use the {PRODUCT} Jobs Service as an external timer service. Whenever you need to schedule a timer as part of process instance, the timer is scheduled in the Jobs Service and the Jobs Service calls back to the {PRODUCT} service upon timer expiration. + +The {PRODUCT} Jobs Service also supports Infinispan persistence that you can enable when you run the Jobs Service so that job data is preserved across application restarts. + +.Procedure +. Go to the https://repository.jboss.org/org/kie/kogito/jobs-service/[`jobs-service`] artifacts page, select the latest release of the Jobs Service, and download the `jobs-service-__VERSION__-runner.jar` file to a local directory. +. In a command terminal, navigate to the directory location of the downloaded `jobs-service-__VERSION__-runner.jar` file and enter the following command to run the Jobs Service with Infinispan persistence enabled: ++ +-- +.Running the Jobs Service with Infinispan persistence enabled +[source,subs="+quotes"] +---- +$ java \ + -Dkogito.job-service.persistence=infinispan \ + -jar jobs-service-__VERSION__-runner.jar +---- + +Infinispan persistence enables the job data to be preserved across application restarts. If you do not use Infinispan persistence, the Jobs Service uses the default in-memory storage and all job information is lost between application restarts. + +To change the logging level of the Jobs Service, such as for debugging, you can specify the following start-up properties: + +.Modifying Jobs Service logging level for debugging +[source,subs="+quotes"] +---- +$ java \ + -Dquarkus.log.console.level=DEBUG -Dquarkus.log.category.\"org.kie.kogito\".min-level=DEBUG \ + -Dquarkus.log.category.\"org.kie.kogito\".level=DEBUG \ + -jar jobs-service-__VERSION__-runner.jar +---- +-- +. In your {PRODUCT} project, add the following dependency to the `pom.xml` file to enable the Jobs Service add-on: ++ +-- +.On Quarkus +[source, xml] +---- + + org.kie.kogito + jobs-management-quarkus-addon + +---- + +.On Spring Boot +[source, xml] +---- + + org.kie.kogito + jobs-management-springboot-addon + +---- +-- +. In your {PRODUCT} project, add the following properties to the `src/main/resources/application.properties` to define the locations of the Jobs Service and the callback to be used when the timer expires: ++ +.Configure {PRODUCT} service properties for Jobs Service +[source] +---- +kogito.jobs-service.url=http://localhost:8085 +kogito.service.url=http://localhost:8080 +---- +. In a command terminal, navigate to your {PRODUCT} project and run the project using your preferred run mode, such as development mode: ++ +-- +.On Quarkus +[source] +---- +mvn clean compile quarkus:dev +---- + +.On Sprint Boot +[source] +---- +mvn clean compile spring-boot:run +---- + +With the Jobs Service and your {PRODUCT} project both configured and running, the Jobs Service can receive any job-scheduling requests to function as the external timer service. + +By default, the implementation of the Jobs Service uses the following basic components: + +* An implementation of the `org.kie.kogito.jobs.JobsService` interface that is used by the service to schedule jobs +* A REST endpoint registered at the path `/management/jobs` + +If the default REST clients used by the Jobs Service add-on do not meet your needs, you can configure custom REST clients using the relevant service implementors. The REST client depends on the application type: + +* On Quarkus, the Jobs Service uses a Vert.x web client: `io.vertx.ext.web.client.WebClient` +* On Spring Boot, the Jobs Service uses a rest template: `org.springframework.web.client.RestTemplate` + +In both cases, you produce an instance of the client to enable detailed setup of the client. +-- diff --git a/assemblies/modules/configuration/proc-messaging-enabling.adoc b/assemblies/modules/configuration/proc-messaging-enabling.adoc new file mode 100644 index 0000000..8f0e2e1 --- /dev/null +++ b/assemblies/modules/configuration/proc-messaging-enabling.adoc @@ -0,0 +1,152 @@ +[id='proc-messaging-enabling_{context}'] += Enabling Kafka messaging for {PRODUCT} services + +{PRODUCT} supports the https://github.com/eclipse/microprofile-reactive-messaging[MicroProfile Reactive Messaging] specification for messaging in your services. You can enable messaging to configure message events as either input or output of business process execution. + +For example, the following process uses messaging start and end events to communicate with travelers: + +.Example process with messaging start and end events +image::kogito/bpmn/bpmn-messaging-example.png[Image of message-based process] + +In this example, the message start and end events require the following information: + +* Message name that maps to the channel that delivers messages +* Message payload that maps to a process instance variable + +.Example message configuration for start event +image::kogito/bpmn/bpmn-messaging-start-event.png[Image of message start event data] + +.Example message configuration for end event +image::kogito/bpmn/bpmn-messaging-end-event.png[Image of message end event data] + +For this procedure, the messaging is based on https://kafka.apache.org/[Apache Kafka] as the event publisher, so you must have Kafka installed in order to enable messaging. Your marshalling configuration depends on the messaging solution that you use. + +.Prerequisites +* https://kafka.apache.org/[Apache Kafka] is installed and includes any required topics. For information about Kafka installation and configuration, see the https://kafka.apache.org/documentation/[Apache Kafka documentation]. + +.Procedure + +. Add the following dependencies to the `pom.xml` file of your {PRODUCT} project: ++ +-- +.On Quarkus +[source, xml] +---- + + io.quarkus + quarkus-smallrye-reactive-messaging-kafka + +---- + +.On Spring Boot +[source,xml] +---- + + org.springframework.kafka + spring-kafka + + + com.fasterxml.jackson.core + jackson-databind + +---- +-- +. Configure the incoming and outgoing messaging channels and properties: ++ +-- +* *On Quarkus*: Add the following properties to the `src/main/resources/application.properties` file in your {PRODUCT} project to configure the incoming and outgoing messages and channels: ++ +.Configure incoming and outgoing messages and channels +[source] +---- +mp.messaging.incoming.travellers.connector=smallrye-kafka +mp.messaging.incoming.travellers.topic=travellers +mp.messaging.incoming.travellers.value.deserializer=org.apache.kafka.common.serialization.StringDeserializer +mp.messaging.outgoing.processedtravellers.connector=smallrye-kafka +mp.messaging.outgoing.processedtravellers.topic=processedtravellers +mp.messaging.outgoing.processedtravellers.value.serializer=org.apache.kafka.common.serialization.StringSerializer +---- ++ +Replace `travellers` with the name of the message start event. +Replace `processedtravellers` with the name of the message end event. ++ +[NOTE] +==== +To prevent execution errors due to long wait times with messaging, you can also use the following property to disable waiting for message completion: + +.Disable message wait time +[source] +---- +mp.messaging.outgoing.[channel-name].waitForWriteCompletion=false +---- +==== + + +* *On Spring Boot*: Add the following property to the `src/main/resources/application.properties` file in your {PRODUCT} project to configure the messaging channel, and create the JavaBeans for the incoming and outgoing messages: ++ +.Configure messaging channel +[source] +---- +kafka.bootstrapAddress=localhost:9092 +---- ++ +.Create JavaBeans for incoming messages +[source, java] +---- +@EnableKafka +@Configuration +public class KafkaConsumerConfig { + + @Value(value = "${kafka.bootstrapAddress}") + private String bootstrapAddress; + + public ConsumerFactory consumerFactory() { + Map props = new HashMap<>(); + props.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, bootstrapAddress); + props.put(ConsumerConfig.GROUP_ID_CONFIG, "travellers-group"); + return new DefaultKafkaConsumerFactory<>(props, new StringDeserializer(), new StringDeserializer()); + } + + @Bean + public ConcurrentKafkaListenerContainerFactory kafkaListenerContainerFactory() { + ConcurrentKafkaListenerContainerFactory factory = new ConcurrentKafkaListenerContainerFactory<>(); + factory.setConsumerFactory(consumerFactory()); + return factory; + } + +} +---- ++ +.Create JavaBeans for outgoing messages +[source, java] +---- +@Configuration +public class KafkaProducerConfig { + + @Value(value = "${kafka.bootstrapAddress}") + private String bootstrapAddress; + + + @Bean + public ProducerFactory producerFactory() { + Map configProps = new HashMap<>(); + configProps.put(JsonSerializer.ADD_TYPE_INFO_HEADERS, false); + configProps.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, bootstrapAddress); + configProps.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class); + configProps.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class); + return new DefaultKafkaProducerFactory<>(configProps); + } + + @Bean + public KafkaTemplate kafkaTemplate() { + return new KafkaTemplate<>(producerFactory()); + } + +} +---- +-- + +For example {PRODUCT} services with Kafka messaging, see the following example applications in GitHub: + +* https://github.com/kiegroup/kogito-examples/tree/stable/process-kafka-quickstart-quarkus[`process-kafka-quickstart-quarkus`]: Example on Quarkus +* https://github.com/kiegroup/kogito-examples/tree/stable/process-kafka-quickstart-springboot[`process-kafka-quickstart-springboot`]: Example on Spring Boot diff --git a/assemblies/modules/configuration/proc-persistence-enabling.adoc b/assemblies/modules/configuration/proc-persistence-enabling.adoc new file mode 100644 index 0000000..ec3a0cf --- /dev/null +++ b/assemblies/modules/configuration/proc-persistence-enabling.adoc @@ -0,0 +1,63 @@ +[id='proc-persistence-enabling_{context}'] += Enabling Infinispan persistence for {PRODUCT} services + +You can enable persistence for your {PRODUCT} services to persist data, such as active process nodes and process instance variables, so that the data is preserved across application restarts. {PRODUCT} persistence is based on https://infinispan.org/[Infinispan], so you must have a an Infinispan server installed and running in order to enable persistence. + +.Prerequisites +* https://infinispan.org/[Infinispan server] 10.0 or later is installed and running. For information about Infinispan installation and configuration, see the https://infinispan.org/documentation/[Infinispan documentation]. + +.Procedure +. Add the following dependencies to the `pom.xml` file of your {PRODUCT} project: ++ +-- +.On Quarkus +[source,xml,subs="attributes+,+quotes"] +---- + + io.quarkus + quarkus-infinispan-client + + + org.kie.kogito + infinispan-persistence-addon + __{PRODUCT_INIT_CAP}_VERSION__ + +---- + +.On Spring Boot +[source,xml,subs="attributes+,+quotes"] +---- + + org.kie.kogito + infinispan-persistence-addon + __{PRODUCT_INIT_CAP}_VERSION__ + + + org.infinispan + infinispan-spring-boot-starter-remote + __INFINISPAN_SPRING_BOOT_VERSION__ + +---- +-- +. Add following property to the `src/main/resources/application.properties` file in your {PRODUCT} project to configure the connection to the Infinispan server. ++ +-- +Replace the server host and port information according to your Infinispan server installation. + +.On Quarkus +[source] +---- +quarkus.infinispan-client.server-list=localhost:11222 +---- + +.On Spring Boot +[source, plain] +---- +infinispan.remote.server-list=127.0.0.1:11222 +---- +-- + +For example {PRODUCT} services with Infinispan persistence, see the following example applications in GitHub: + +* https://github.com/kiegroup/kogito-examples/tree/stable/process-infinispan-persistence-quarkus[`process-infinispan-persistence-quarkus`]: Example on Quarkus +* https://github.com/kiegroup/kogito-examples/tree/stable/process-infinispan-persistence-springboot[`process-infinispan-persistence-springboot`]: Example on Spring Boot diff --git a/assemblies/modules/configuration/proc-prometheus-metrics-monitoring.adoc b/assemblies/modules/configuration/proc-prometheus-metrics-monitoring.adoc new file mode 100644 index 0000000..81dc70b --- /dev/null +++ b/assemblies/modules/configuration/proc-prometheus-metrics-monitoring.adoc @@ -0,0 +1,141 @@ +[id='proc-prometheus-metrics-monitoring_{context}'] += Enabling Prometheus metrics monitoring in {PRODUCT} + +Prometheus is an open-source systems monitoring toolkit that you can use with {PRODUCT} to collect and store metrics related to the execution of Business Process Model and Notation (BPMN) process models, business rules, and Decision Model and Notation (DMN) decision models. You can access the stored metrics through a REST API call to a configured application endpoint, through the Prometheus expression browser, or using a data-graphing tool such as Grafana. + +.Prerequisites +* Prometheus is installed. For information about downloading and using Prometheus, see the https://prometheus.io/docs/introduction/overview/[Prometheus documentation page]. + +.Procedure +. In your {PRODUCT} project, add following dependency to the `pom.xml` file to enable the Prometheus add-on: ++ +.Add dependency for Prometheus add-on +[source,xml,subs="+quotes"] +---- + + org.kie.kogito + monitoring-prometheus-addon + __KOGITO_VERSION__ + +---- +. In the `src/main/java` folder of your project, create an event listener configuration class for the following Prometheus event listeners for monitoring processes or rules, such as a `ProcessEventListenerConfig` class or a `RuleEventListenerConfig` class: ++ +-- +* Prometheus event listener for processes: `org.kie.addons.monitoring.process.PrometheusProcessEventListener` +* Prometheus event listener for rules: `org.kie.addons.monitoring.rule.PrometheusMetricsDroolsListener` + +.Example process event listener for Prometheus +[source, java] +---- +@ApplicationScoped +public class ProcessEventListenerConfig extends DefaultProcessEventListenerConfig { + + public ProcessEventListenerConfig() { + super(new PrometheusProcessEventListener("acme-travels")); + } +} +---- + +.Example rule event listener for Prometheus +[source, java] +---- +@ApplicationScoped +public class RuleEventListenerConfig extends DefaultRuleEventListenerConfig { + + public RuleEventListenerConfig() { + super(new PrometheusMetricsDroolsListener("acme-travels")); + } +} +---- + +The argument `acme-travels` in these listener examples identifies the relevant data when the data is returned from the {PRODUCT} runtime and grouped in Prometheus metrics. +-- +. In the `prometheus.yaml` file of your Prometheus distribution, add the following settings in the `scrape_configs` section to configure Prometheus to scrape metrics from your {PRODUCT} service: ++ +-- +.Example scrape configurations in `prometheus.yaml` file +[source,yaml,subs="+quotes"] +---- +scrape_configs: + job_name: 'travels' +metrics_path: /metrics +static_configs: + - targets: ["localhost:8080"] +---- + +Replace the values according to your {PRODUCT} service settings. +-- +. In a command terminal, navigate to your {PRODUCT} project and run the project using your preferred run mode, such as development mode: ++ +-- +.On Quarkus +[source] +---- +mvn clean compile quarkus:dev +---- + +.On Sprint Boot +[source] +---- +mvn clean compile spring-boot:run +---- + +After you start your {PRODUCT} service, Prometheus begins collecting metrics and {PRODUCT} publishes the metrics to the configured REST API endpoint. +-- +. To verify the metrics configuration, use a REST client or curl utility to send a `GET` request to the configured `/metrics` endpoint, such as `\http://localhost:8080/metrics` in this example: ++ +-- +.Example curl command to return Prometheus metrics +[source] +---- +curl -X GET http://localhost:8080/metrics +---- + +.Example response +[source] +---- +# HELP kie_process_instance_completed_total Completed Process Instances +# TYPE kie_process_instance_completed_total counter +# HELP kie_process_instance_started_total Started Process Instances +# TYPE kie_process_instance_started_total counter +kie_process_instance_started_total{app_id="acme-travels",process_id="travels",} 1.0 +# HELP kie_work_item_duration_seconds Work Items Duration +# TYPE kie_work_item_duration_seconds summary +# HELP drl_match_fired_nanosecond Drools Firing Time +# TYPE drl_match_fired_nanosecond histogram +drl_match_fired_nanosecond_bucket{identifier="acme-travels",rule_name="Brazilian citizens require visa to Australia",le="1000000.0",} 1.0 +drl_match_fired_nanosecond_bucket{identifier="acme-travels",rule_name="Brazilian citizens require visa to Australia",le="2000000.0",} 1.0 +drl_match_fired_nanosecond_bucket{identifier="acme-travels",rule_name="Brazilian citizens require visa to Australia",le="3000000.0",} 1.0 +drl_match_fired_nanosecond_bucket{identifier="acme-travels",rule_name="Brazilian citizens require visa to Australia",le="4000000.0",} 1.0 +drl_match_fired_nanosecond_bucket{identifier="acme-travels",rule_name="Brazilian citizens require visa to Australia",le="5000000.0",} 1.0 +drl_match_fired_nanosecond_bucket{identifier="acme-travels",rule_name="Brazilian citizens require visa to Australia",le="6000000.0",} 1.0 +drl_match_fired_nanosecond_bucket{identifier="acme-travels",rule_name="Brazilian citizens require visa to Australia",le="7000000.0",} 1.0 +drl_match_fired_nanosecond_bucket{identifier="acme-travels",rule_name="Brazilian citizens require visa to Australia",le="8000000.0",} 1.0 +drl_match_fired_nanosecond_bucket{identifier="acme-travels",rule_name="Brazilian citizens require visa to Australia",le="9000000.0",} 1.0 +drl_match_fired_nanosecond_bucket{identifier="acme-travels",rule_name="Brazilian citizens require visa to Australia",le="+Inf",} 1.0 +drl_match_fired_nanosecond_count{identifier="acme-travels",rule_name="Brazilian citizens require visa to Australia",} 1.0 +drl_match_fired_nanosecond_sum{identifier="acme-travels",rule_name="Brazilian citizens require visa to Australia",} 789941.0 +# HELP kie_process_instance_sla_violated_total Process Instances SLA Violated +# TYPE kie_process_instance_sla_violated_total counter +# HELP kie_process_instance_duration_seconds Process Instances Duration +# TYPE kie_process_instance_duration_seconds summary +# HELP kie_process_instance_running_total Running Process Instances +# TYPE kie_process_instance_running_total gauge +kie_process_instance_running_total{app_id="acme-travels",process_id="travels",} 1.0 +---- + +If the metrics are not available at the defined endpoint, review and verify the {PRODUCT} and Prometheus configurations described in this section. + +You can also interact with your collected metrics and application targets in the Prometheus expression browser at `http://__HOST:PORT__/graph` and `http://__HOST:PORT__/targets`, or integrate your Prometheus data source with a data-graphing tool such as Grafana: + +.Prometheus expression browser with {PRODUCT} service targets +image::kogito/configuration/prometheus-expression-browser-targets.png[Image of targets in Prometheus expression browser] + +.Grafana dashboard with {PRODUCT} service metrics +image::kogito/configuration/prometheus-grafana-data.png[Image of application metrics in Grafana] +-- + +.Additional resources +* https://prometheus.io/docs/prometheus/latest/getting_started/[Getting Started with Prometheus] +* https://prometheus.io/docs/visualization/grafana/[Grafana Support for Prometheus] +* https://grafana.com/docs/grafana/latest/features/datasources/prometheus/[Using Prometheus in Grafana] diff --git a/assemblies/modules/configuration/proc-task-lifecycle-custom.adoc b/assemblies/modules/configuration/proc-task-lifecycle-custom.adoc new file mode 100644 index 0000000..cfb36e9 --- /dev/null +++ b/assemblies/modules/configuration/proc-task-lifecycle-custom.adoc @@ -0,0 +1,80 @@ +[id='proc-task-lifecycle-custom_{context}'] += Creating a custom task life cycle and phase + +You can extend the user task life cycle and life cycle phases in {PRODUCT} to implement a custom life cycle and phases as needed. + +.Procedure +. To add custom life cycle phases, implement the `org.kie.kogito.process.workitem.LifeCyclePhase` resource in the Java class for your custom life cycle phases. ++ +-- +This resource implements the following key methods: + +* `id`: Assigns a unique ID that is used when transitioning through phases +* `canTransition`: Provides a checkpoint between phases, if this phase can be transitioned from a specified phase +* `status`: Defines a human-readable status for this phase +* `isTerminating`: Determines if this phase is a completion stage, and if so, completes the work item and moves on to the next activity in the process +* `apply`: Enables additional updates to the work item when transitioning through phases + +You can implement as many phases as needed or extend existing phases. +-- +. To add a custom life cycle, implement the `org.kie.kogito.process.workitem.LifeCycle>` resource in the Java class for your custom life cycle. ++ +-- +NOTE: To support user tasks, the parameterized type `LifeCycle` must be `Map`. + +This resource implements the following key methods: + +* `phaseById`: Retrieves the life cycle phase by ID to verify if the phase is supported by the life cycle implementation +* `phases`: Returns all supported phases by a specified life cycle implementation +* `transitionTo`: Provides the main logic to handle phase transition +* `data`: Returns the current state of data for the work item + +The following is an example Java class that extends the `Complete` life cycle phase from a custom life cycle implementation: + +.Example Java class to extend the `Complete` life cycle phase +[source,java] +---- +package org.acme.travels.usertasks; + +import java.util.Arrays; +import java.util.List; + +import org.jbpm.process.instance.impl.workitem.Complete; +import org.kie.kogito.process.workitem.LifeCyclePhase; + +public class CompleteStartedOnly extends Complete { + + private List allowedTransitions = Arrays.asList(Start.ID); + + @Override + public boolean canTransition(LifeCyclePhase phase) { + return allowedTransitions.contains(phase.id()); + } + +} +---- +-- + +. After you implement your custom life cycle or life cycle phases, create a Java configuration class to enable the {PROCESS_ENGINE} to use the new life cycle or phase instead of the default life cycle. ++ +-- +In this configuration, you use the `WorkItemHandlerConfig` class as you do for any other work item handler, as shown in the following example: + +.Example configuration class for a custom life cycle phase +[source,java] +---- +@ApplicationScoped +public class CustomWorkItemHandlerConfig extends DefaultWorkItemHandlerConfig { + { + register("Human Task", new HumanTaskWorkItemHandler(new CustomHumanTaskLifeCycle())); + } +} +---- + +The work item handler is the same as the default, but instead of the default life cycle, you pass as a constructor argument the custom implementation of the `LifeCycle` interface. +-- + +For example {PRODUCT} services with custom task life cycle configurations, see the following example applications in GitHub: + +* https://github.com/kiegroup/kogito-examples/tree/stable/kogito-usertasks-custom-lifecycle-quarkus[`kogito-usertasks-custom-lifecycle-quarkus`]: Example on Quarkus +* https://github.com/kiegroup/kogito-examples/tree/stable/kogito-usertasks-custom-lifecycle-springboot[`kogito-usertasks-custom-lifecycle-springboot`]: Example on Spring Boot diff --git a/assemblies/modules/configuration/ref-data-index-service-queries.adoc b/assemblies/modules/configuration/ref-data-index-service-queries.adoc new file mode 100644 index 0000000..c2758e0 --- /dev/null +++ b/assemblies/modules/configuration/ref-data-index-service-queries.adoc @@ -0,0 +1,413 @@ +[id='ref-data-index-service-queries_{context}'] += Supported GraphQL queries with the Data Index Service + +After you configure and run your {PRODUCT} service and the {PRODUCT} Data Index Service, you can query the available data using the https://github.com/graphql/graphiql[GraphiQL] interface displayed at `http://__HOST__:__PORT__/graphql`, such as `\http://localhost:8080/graphql`. + +The {PRODUCT} Data Index Service supports GraphQL queries for process definitions (domain cache) and for process instances and task instances (instance caches). + +== GraphQL queries for process definitions (domain cache) + +Use the following GraphQL queries to retrieve data about process definitions. These example queries assume that a `Travels` Business Process Model and Notation (BPMN) process model is running or has been executed. + +Retrieve data from process definitions:: ++ +-- +You can retrieve data about a specified process definition from your {PRODUCT} service. + +.Example query +[source] +---- +{ + Travels { + visaApplication { + duration + } + flight { + flightNumber + gate + } + hotel { + name + address { + city + country + } + } + traveller { + firstName + lastName + nationality + email + } + } +} +---- +-- + +Correlate data using the `metadata` parameter:: ++ +-- +You can use the `metadata` parameter to correlate data from process definitions (domain cache) with data from process instances and task instances (instance caches). This parameter is added to all root models that are deployed in the Data Index Service and enables you to retrieve and filter query data. + +.Example query +[source] +---- +{ + Travels { + flight { + flightNumber + arrival + departure + } + metadata { + lastUpdate + userTasks { + name + } + processInstances { + processId + } + } + } +} +---- +-- + +Filter query results using the `where` and `metadata` parameters:: ++ +-- +You can use the `where` parameter with multiple combinations to filter query results based on process definition attributes. The attributes available for search depend on the BPMN process model that is deployed, such as a `Travels` process model in this example. + +.Example query +[source] +---- +{ + Travels(where: {traveller: {firstName: {like: "Cri*"}}}) { + flight { + flightNumber + arrival + departure + } + traveller { + email + } + } +} +---- + +NOTE: The `like` operator is case sensitive. + +You can also use the `metadata` parameter to filter correlated query results from related process instances or tasks. + +.Example query +[source] +---- +{ + Travels(where: {metadata: {processInstances: {id: {equal: "1aee8ab6-d943-4dfb-b6be-8ea8727fcdc5"}}}}) { + flight { + flightNumber + arrival + departure + } + } +} +---- + +.Example query +[source] +---- +{ + Travels(where: {metadata: {userTasks: {id: {equal: "de52e538-581f-42db-be65-09e8739471a6"}}}}) { + flight { + flightNumber + arrival + departure + } + } +} +---- +-- + +Sort query results using the `orderBy` parameter:: ++ +-- +You can use the `orderBy` parameter to sort query results based on process definition attributes. You can also specify the direction of sorting in ascending `ASC` order or descending `DESC` order. Multiple attributes are applied to the database query in the order they are specified in the query filter. + +.Example query +[source] +---- +{ + Travels(orderBy: {trip: {begin: ASC}}) { + flight { + flightNumber + arrival + departure + } + } +} +---- +-- + +Limit and offset query results using the `pagination` parameter:: ++ +-- +You can use the `pagination` parameter to specify a `limit` and `offset` for query results. + +.Example query +[source] +---- +{ + Travels(where: {traveller: {firstName: {like: "Cri*"}}}, pagination: {offset: 0, limit: 10}) { + flight { + flightNumber + arrival + departure + } + traveller { + email + } + } +} +---- +-- + +== GraphQL queries for process instances and user task instances (instance caches) + +Use the following GraphQL queries to retrieve data about process instances and user task instances. + +Retrieve data from process instances:: ++ +-- +You can retrieve data about a specified process instance from your process definition. + +.Example query +[source] +---- +{ + ProcessInstances { + id + processId + state + parentProcessInstanceId + rootProcessId + rootProcessInstanceId + variables + nodes { + id + name + type + } + } +} +---- +-- + +Retrieve data from user task instances:: ++ +-- +You can retrieve data from a specified user task instance from the process instance. + +.Example query +[source] +---- +{ + UserTaskInstances { + id + name + actualOwner + description + priority + processId + processInstanceId + } +} +---- +-- + +Filter query results using the `where` parameter:: ++ +-- +You can use the `where` parameter with multiple combinations to filter query results based on process or task attributes. + +.Example query +[source] +---- +{ + ProcessInstances(where: {state: {equal: ACTIVE}}) { + id + processId + processName + start + state + variables + } +} +---- + +.Example query +[source] +---- +{ + ProcessInstances(where: {id: {equal: "d43a56b6-fb11-4066-b689-d70386b9a375"}}) { + id + processId + processName + start + state + variables + } +} +---- + +.Example query +[source] +---- +{ + UserTaskInstances(where: {state: {equal: "Ready"}}) { + id + name + actualOwner + description + priority + processId + processInstanceId + } +} +---- + +By default, every filtered attribute is executed as an `AND` operation in queries. You can modify this behavior by combining filters with an `AND` or `OR` operator. + +.Example query +[source] +---- +{ + ProcessInstances(where: {or: {state: {equal: ACTIVE}, rootProcessId: {isNull: false}}}) { + id + processId + processName + start + end + state + } +} +---- + +.Example query +[source] +---- +{ + ProcessInstances(where: {and: {processId: {equal: "travels"}, or: {state: {equal: ACTIVE}, rootProcessId: {isNull: false}}}}) { + id + processId + processName + start + end + state + } +} +---- + +Depending on the attribute type, the following operators are also available: + +* String array argument: +** `contains` : String +** `containsAll`: Array of strings +** `containsAny`: Array of strings +** `isNull`: Boolean (`true` or `false`) + +* String argument: +** `in`: Array of strings +** `like`: String +** `isNull`: Boolean (`true` or `false`) +** `equal`: String + +* ID argument: +** `in`: Array of strings +** `equal`: String +** `isNull`: Boolean (`true` or `false`) + +* Boolean argument: +** `isNull`: Boolean (`true` or `false`) +** `equal`: Boolean (`true` or `false`) + +* Numeric argument: +** `in`: Array of integers +** `isNull`: Boolean +** `equal`: Integer +** `greaterThan`: Integer +** `greaterThanEqual`: Integer +** `lessThan`: Integer +** `lessThanEqual`: Integer +** `between`: Numeric range +** `from`: Integer +** `to`: Integer + +* Date argument: +** `isNull`: Boolean (`true` or `false`) +** `equal`: Date time +** `greaterThan`: Date time +** `greaterThanEqual`: Date time +** `lessThan`: Date time +** `lessThanEqual`: Date time +** `between`: Date range +** `from`: Date time +** `to`: Date time +-- + +Sort query results using the `orderBy` parameter:: ++ +-- +You can use the `orderBy` parameter to sort query results based on process or task attributes. You can also specify the direction of sorting in ascending `ASC` order or descending `DESC` order. Multiple attributes are applied to the database query in the order they are specified in the query filter. + +.Example query +[source] +---- +{ + ProcessInstances(where: {state: {equal: ACTIVE}}, orderBy: {start: ASC}) { + id + processId + processName + start + end + state + } +} +---- + +.Example query +[source] +---- +{ + UserTaskInstances(where: {state: {equal: "Ready"}}, orderBy: {name: ASC, actualOwner: DESC}) { + id + name + actualOwner + description + priority + processId + processInstanceId + } +} +---- +-- + +Limit and offset query results using the `pagination` parameter:: ++ +-- +You can use the `pagination` parameter to specify a `limit` and `offset` for query results. + +.Example query +[source] +---- +{ + ProcessInstances(where: {state: {equal: ACTIVE}}, orderBy: {start: ASC}, pagination: {limit: 10, offset: 0}) { + id + processId + processName + start + end + state + } +} +---- +-- diff --git a/assemblies/modules/configuration/ref-kogito-runtime-properties.adoc b/assemblies/modules/configuration/ref-kogito-runtime-properties.adoc new file mode 100644 index 0000000..de1c7a6 --- /dev/null +++ b/assemblies/modules/configuration/ref-kogito-runtime-properties.adoc @@ -0,0 +1,142 @@ +[id='ref-kogito-runtime-properties_{context}'] += {PRODUCT} runtime properties quick reference + +The following table serves as a quick reference for commonly used runtime configuration properties supported by {PRODUCT}. You can define these properties in the `src/main/resources/application.properties` file of the relevant {PRODUCT} project or by using the `-D` prefix during application start-up. + +NOTE: Some of these properties might require accompanying dependencies in the relevant {PRODUCT} project to enable the specified capability. For more information about dependency requirements, review the sections of the {PRODUCT} configuration documentation that relate to that property. + +.Common runtime properties in {PRODUCT} +[cols="15%,45%,40%"] +|=== +|Relevance |Property |Description + +.3+|Events +|`kogito.events.processinstances.enabled` +a|Determines whether runtime events are published for process instances, either `enabled` or `disabled` + +Default value: `enabled` + +Example: `kogito.events.processinstances.enabled` + +a|`kogito.events.usertasks.enabled` +|Determines whether runtime events are published for user task instances, either `enabled` or `disabled` + +Default value: `enabled` + +Example: `kogito.events.usertasks.enabled` + +a|`kogito.messaging.as-cloudevents` +|Determines whether messages (sent or received through message events) are published in CloudEvents format, either `true` of `false` + +Example: `kogito.messaging.as-cloudevents=true` + +.3+|Infinispan persistence +a|`quarkus.infinispan-client.server-list` + +For Spring Boot: `infinispan.remote.server-list` +a|Defines the location where an Infinispan server is running, typically used to connect your application to Infinispan for persistence + +Example: `quarkus.infinispan-client.server-list=localhost:11222` + +For Spring Boot: `infinispan.remote.server-list=127.0.0.1:11222` + +a|`quarkus.infinispan-client.auth-username` + +`quarkus.infinispan-client.auth-password` +|Identifies the Infinispan user name and password to authenticate Infinispan persistence capabilities in the relevant application, if required, such as in the {PRODUCT} Data Index Service + +Examples: + +`quarkus.infinispan-client.auth-username=admin` + +`quarkus.infinispan-client.auth-password=admin123` + +|`kogito.persistence.infinispan.template` +|Defines an optional template name of the Infinispan cache configuration to be used to persist process instance data + +Example: `kogito.persistence.infinispan.template=MyTemplate` + +|Kafka messaging +a|Incoming: + +`mp.messaging.incoming.__MESSAGE_EVENT_NAME__.connector` + +`mp.messaging.incoming.__MESSAGE_EVENT_NAME__.topic` + +`mp.messaging.incoming.__MESSAGE_EVENT_NAME__.value.deserializer` + +Outgoing: + +`mp.messaging.outgoing.__MESSAGE_EVENT_NAME__.connector` + +`mp.messaging.outgoing.__MESSAGE_EVENT_NAME__.topic` + +`mp.messaging.outgoing.__MESSAGE_EVENT_NAME__.value.serializer` + +For Spring Boot: `kafka.bootstrapAddress` (messages defined separately in JavaBeans) +a|Defines the connector, topic, and deserializer for the incoming and outgoing messages and channels for reactive messaging with Apache Kafka + +Examples for incoming: + +`mp.messaging.incoming.travellers.connector=smallrye-kafka` + +`mp.messaging.incoming.travellers.topic=travellers` + +`mp.messaging.incoming.travellers.value.deserializer=org.apache.kafka.common.serialization.StringDeserializer` + +Examples for outgoing: + +`mp.messaging.outgoing.processedtravellers.connector=smallrye-kafka` + +`mp.messaging.outgoing.processedtravellers.topic=processedtravellers` + +`mp.messaging.outgoing.processedtravellers.value.serializer=org.apache.kafka.common.serialization.StringSerializer` + +For Spring Boot: `kafka.bootstrapAddress=localhost:9092` + +.7+|{PRODUCT} Jobs Service +|`kogito.service.url` +a|Defines the location where the {PRODUCT} service is deployed, typically used by the Jobs Service to find the source of the jobs + +Example: `kogito.service.url=http://localhost:8080` + +a|`kogito.jobs-service.url` +|Defines the callback URL that posts to a running {PRODUCT} Jobs Service + +Example: `kogito.jobs-service.url=http://localhost:8085` + +|`kogito.jobs-service.persistence` +a|(Specified in Jobs Service) Identifies the persistence mechanism used by the Jobs Service, either `in-memory` or `infinispan` + +Default value: `in-memory` + +Example: `kogito.jobs-service.persistence=in-memory` + +|`kogito.jobs-service.backoffRetryMillis` +a|(Specified in Jobs Service) Defines the retry back-off time in milliseconds between job execution attempts, in case the execution fails + +Default value: `1000` + +Example: `kogito.jobs-service.backoffRetryMillis=1000` + +|`kogito.jobs-service.maxIntervalLimitToRetryMillis` +a|(Specified in Jobs Service) Defines the maximum interval in milliseconds when retrying to execute jobs, in case the execution fails + +Default value: `60000` + +Example: `kogito.jobs-service.maxIntervalLimitToRetryMillis=60000` + +|`mp.messaging.outgoing.kogito-job-service-job-status-events.bootstrap.servers` +a|(Specified in Jobs Service) Identifies the Kafka bootstrap server address with the port used to publish events + +Default value: `localhost:9092` + +Example: `mp.messaging.outgoing.kogito-job-service-job-status-events.bootstrap.servers=localhost:9092` + +|`mp.messaging.outgoing.kogito-job-service-job-status-events.topic` +a|(Specified in Jobs Service) Defines the name of the Kafka topic where the events are published + +Default value: `kogito-jobs-events` + +Example: `mp.messaging.outgoing.kogito-job-service-job-status-events.topic=kogito-jobs-events` +|=== diff --git a/assemblies/modules/creating-running/con-kogito-automation.adoc b/assemblies/modules/creating-running/con-kogito-automation.adoc new file mode 100644 index 0000000..0f6a44f --- /dev/null +++ b/assemblies/modules/creating-running/con-kogito-automation.adoc @@ -0,0 +1,57 @@ +[id='con-kogito-automation_{context}'] += {PRODUCT} business automation + +{PRODUCT} is a cloud-native business automation technology for building cloud-ready business applications. The name _Kogito_ derives from the Latin "Cogito", as in "Cogito, ergo sum" ("I think, therefore I am"), and is pronounced `[ˈkoː.d͡ʒi.to]` (_KO-jee-to_). The letter _K_ has reference to Kubernetes, the base for {OPENSHIFT} as the target cloud platform for {PRODUCT}, and to the Knowledge Is Everything (KIE) open source business automation project from which {PRODUCT} originates. + +{PRODUCT} is designed specifically to excel in a hybrid cloud environment and to be adaptable to your domain and tooling needs. The core objective of {PRODUCT} is to help you mold a set of business processes and decisions into your own domain-specific cloud-native set of services. + +.Business processes and decisions to cloud services +image::kogito/creating-running/kogito-assets-to-cloud.png[Image of business assets moving to cloud services] + +When you are using {PRODUCT}, you are building a cloud-native application as a set of independent domain-specific services, collaborating to achieve some business value. The processes and decisions that you use to describe the target behavior are executed as part of the services that you create. The resulting services are highly distributed and scalable with no centralized orchestration service, and the runtime that your service uses is optimized for what your service needs. + +// @comment: Excluding for simplicity for now (Stetson, 18 Feb 2020) +//If you need long-lived processes, you can persist the runtime state externally in a data grid such as Infinispan. Each {PRODUCT} service also produces events that can be consumed by other services. For example, if you use Apache Kafka, events can be aggregated and indexed in a data index service, offering advanced query capabilities through GraphQL. + +{PRODUCT} includes components that are based on well-known business automation KIE projects, specifically https://drools.org[Drools], https://jbpm.org[jBPM], and https://optaplanner.org[OptaPlanner], to offer dependable, open source solutions for business rules, business processes, and constraint solving. + +== Cloud-first priority + +{PRODUCT} is designed to run and scale on a cloud infrastructure. You can use {PRODUCT} with the latest cloud-based technologies, such as Quarkus, Knative, and Apache Kafka, to get fast boot times and instant scaling on container application platforms, such as {OPENSHIFT}. + +.Technologies used with {PRODUCT} +image::kogito/creating-running/kogito-related-technolgies.png[Image of cloud-based technologies] + +For example, {PRODUCT} is compatible with the following technologies: + +* *{OPENSHIFT}*, based on Kubernetes, is the target platform for building and managing containerized applications. +* *Quarkus* is the new native Java stack for Kubernetes that you can use when you build applications with {PRODUCT} services. +* *Spring Boot* is also supported with {PRODUCT} if you need to use the Spring Framework with {PRODUCT}. +ifdef::KOGITO-COMM[] +* *GraalVM* with Quarkus enables you to use native compilation with {PRODUCT}, resulting in fast start-up times and minimal footprint. For example, a native {PRODUCT} service starts in about 0.003ms, about 100 times faster than a non-native start-up. Fast start-up is almost a necessity in a cloud ecosystem, especially if you need small serverless applications. +endif::[] +* *Knative* enables you to build serverless applications with {PRODUCT} that you can scale up or down (to zero) as needed. +* *Prometheus* and *Grafana* are compatible with {PRODUCT} services for monitoring and analytics with optional extensions. +* *Kafka*, *Infinispan*, and *Keycloak* are also some of the middleware technologies that {PRODUCT} supports for messaging, persistence, and security. + +== Domain-specific flexibility + +{PRODUCT} adapts to your business domain instead of forcing you to modify your domain to work with {PRODUCT}. You can expose your {PRODUCT} services with domain-specific APIs, based on the processes and decisions that you have defined. Domain-specific APIs for {PRODUCT} services do not require third-party or internal APIs. + +For example, a process for onboarding employees could generate remote REST API endpoints that you can use to onboard new employees or get information on their status, all using domain-specific JSON data. + +.Example custom API endpoints in Swagger +image::kogito/creating-running/kogito-domain-api-endpoints-example.png[Image of REST API endpoints in Swagger UI] + +You can also expose domain-specific data through events or in a data index so that the data can be consumed and queried by other services. + +== Developer-centered experience + +Another focus of {PRODUCT} is optimal developer experience. You can use much or all of your existing tooling and workflow to develop, build, and deploy {PRODUCT} services, whether locally for testing or into the cloud. Quarkus offers development mode features to help with local testing, such as live reload of your processes and decisions in your running applications for advanced debugging. + +{PRODUCT} tooling is embeddable so that you can continue using the worklfow you already use for cloud-native services. For example, the {PRODUCT} https://github.com/kiegroup/kogito-tooling/releases[VSCode extension] enables you to edit your Business Process Model and Notation (BPMN) 2.0 business processes and Decision Model and Notation (DMN) decision models directly in your VSCode IDE, next to your other application code. + +.Building a {PRODUCT} process service in VSCode +image::kogito/creating-running/kogito-run-quarkus-devmode-demo.gif[Demo of {PRODUCT} BPMN2 extension in VSCode] + +To deploy your services into the cloud, you can use the {PRODUCT} Operator, which guides you through every step. The {PRODUCT} Operator uses the https://github.com/operator-framework[Operator Framework] to automate and manage many of the deployment steps for you. For example, when you give the operator a link to the Git repository that contains your application, the operator can automatically configure the components required to build your project from source and deploy the resulting services. {PRODUCT} also offers a command-line interface (CLI) to simplify some of these deployment tasks. diff --git a/assemblies/modules/creating-running/con-kogito-modelers.adoc b/assemblies/modules/creating-running/con-kogito-modelers.adoc new file mode 100644 index 0000000..7596813 --- /dev/null +++ b/assemblies/modules/creating-running/con-kogito-modelers.adoc @@ -0,0 +1,17 @@ +[id='con-kogito-modelers_{context}'] += {PRODUCT} BPMN and DMN modelers + +{PRODUCT} provides the following extensions or applications that you can use to design Business Process Model and Notation (BPMN) process models and Decision Model and Notation (DMN) decision models for your {PRODUCT} services using graphical modelers. + +For convenience, all {PRODUCT} BPMN and DMN modelers are available in the https://kiegroup.github.io/kogito-online/#/download[Business Modeler Hub] desktop application. + +* *{PRODUCT} VSCode extension*: (Recommended) Enables you to view and design BPMN and DMN models in Visual Studio Code. The VSCode extension in the {PRODUCT} Business Modeler Hub requires VSCode 1.43.0 or later. ++ +To enable the {PRODUCT} VSCode extension without the {PRODUCT} Business Modeler Hub, you can download the `vscode_extension_kogito_kie_editors___VERSION__.vsix` file from the https://github.com/kiegroup/kogito-tooling/releases[`kogito-tooling`] releases page in GitHub and go to *Extensions* -> *More actions* -> *Install from VSIX* in VSCode to install the extension. +* *{PRODUCT} GitHub Chrome extension*: Enables you to view and design BPMN and DMN models in GitHub repositories in Google Chrome. ++ +To enable the {PRODUCT} GitHub Chrome extension without the {PRODUCT} Business Modeler Hub, you can download and extract the `chrome_extension_kogito_kie_editors___VERSION__.zip` file from the https://github.com/kiegroup/kogito-tooling/releases[`kogito-tooling`] releases page in GitHub, and then in the upper-right corner in Chrome, go to *Customize and control* -> *Settings* -> *Extensions* -> *Load unpacked* and open the extracted `dist` folder. +* *Business Modeler desktop application*: Enables you to view and design BPMN and DMN models locally. ++ +To run the {PRODUCT} Business Modeler desktop application without the {PRODUCT} Business Modeler Hub, you can download and extract the `business_modeler_preview___RELEASE__.zip` file from the https://github.com/kiegroup/kogito-tooling/releases[`kogito-tooling`] releases page in GitHub, and then follow the instructions in the application `README` file to run the application on your specific operating system. +* *Business Modeler online viewer*: Enables you to view and design BPMN and DMN models online at `https://kiegroup.github.io/kogito-online/`. The online modeler supports the `.new` format, so you can also enter `bpmn.new` or `dmn.new` in a web browser to start designing a new BPMN or DMN model in the online modeler. diff --git a/assemblies/modules/creating-running/con-kogito-quarkus-springboot.adoc b/assemblies/modules/creating-running/con-kogito-quarkus-springboot.adoc new file mode 100644 index 0000000..3815d41 --- /dev/null +++ b/assemblies/modules/creating-running/con-kogito-quarkus-springboot.adoc @@ -0,0 +1,12 @@ +[id='con-kogito-quarkus-springboot_{context}'] += {PRODUCT} on Quarkus and Spring Boot + +The primary Java frameworks that {PRODUCT} supports are Quarkus (recommended) and Spring Boot. + +https://quarkus.io/[Quarkus] is a Kubernetes-native Java framework with a container-first approach to building Java applications, especially for Java virtual machines (JVMs) such as GraalVM and HotSpot. Quarkus optimizes Java specifically for Kubernetes by reducing the size of both the Java application and container image footprint, eliminating some of the Java programming workload from previous generations, and reducing the amount of memory required to run those images. + +For {PRODUCT} services, Quarkus is the preferred framework for optimal Kubernetes compatibility and enhanced developer features, such as live reload in development mode for advanced debugging. + +https://spring.io/projects/spring-boot[Spring Boot] is a Java-based framework for building standalone production-ready Spring applications. Spring Boot enables you to develop Spring applications with minimal configurations and without an entire Spring configuration setup. + +For {PRODUCT} services, Spring Boot is supported for developers who need to use {PRODUCT} in an existing Spring Framework environment. diff --git a/assemblies/modules/creating-running/con-kogito-service-execution.adoc b/assemblies/modules/creating-running/con-kogito-service-execution.adoc new file mode 100644 index 0000000..779adbe --- /dev/null +++ b/assemblies/modules/creating-running/con-kogito-service-execution.adoc @@ -0,0 +1,53 @@ +[id='con-kogito-service-execution_{context}'] += {PRODUCT} service execution + +After you design your {PRODUCT} service, you can build and run your application and then send REST API requests to the application to execute your services. The exact REST API requests that you can use depend on how you set up the application. + +For example, consider a {PRODUCT} service that is set up to generate a `/persons` REST API endpoint and determines whether a specified customer is an adult or is underage. In this example, you can send the following `POST` request using a REST client or curl utility to add an adult and execute the service: + +.Example POST request body to add an adult (JSON) +[source,json] +---- +{ + "person": { + "name": "John Quark", + "age": 20 + } +} +---- + +.Example curl command to add an adult +[source] +---- +curl -X POST http://localhost:8080/persons -H 'content-type: application/json' -H 'accept: application/json' -d '{"person": {"name":"John Quark", "age": 20}}' +---- + +.Example response (JSON) +[source,json] +---- +{ + "id": "3af806dd-8819-4734-a934-728f4c819682", + "person": { + "name": "John Quark", + "age": 20, + "adult": false + }, + "isAdult": true +} +---- + +For information about creating, running, and testing an example application with {PRODUCT} services, see +ifdef::KOGITO-ENT[] +{URL_CREATING_RUNNING}[_{CREATING_RUNNING}_]. +endif::[] +ifdef::KOGITO-COMM[] +xref:chap-kogito-creating-running[]. +endif::[] + +For information about deploying your {PRODUCT} service to {OPENSHIFT}, see +ifdef::KOGITO-ENT[] +{URL_DEPLOYING_ON_OPENSHIFT}[_{DEPLOYING_ON_OPENSHIFT}_]. +endif::[] +ifdef::KOGITO-COMM[] +xref:chap-kogito-deploying-on-openshift[]. +endif::[] diff --git a/assemblies/modules/creating-running/proc-kogito-app-examples-running.adoc b/assemblies/modules/creating-running/proc-kogito-app-examples-running.adoc new file mode 100644 index 0000000..d25fb2b --- /dev/null +++ b/assemblies/modules/creating-running/proc-kogito-app-examples-running.adoc @@ -0,0 +1,182 @@ +[id='proc-kogito-app-examples-running_{context}'] += Running the {PRODUCT} example applications + +To get started quickly with {PRODUCT}, you can run any of the example applications in the https://github.com/kiegroup/kogito-examples[`kogito-examples`] repository in GitHub and experiment with the {PRODUCT} services. + +For this procedure, use the https://github.com/kiegroup/kogito-examples/tree/stable/process-quarkus-example[`process-quarkus-example`] or https://github.com/kiegroup/kogito-examples/tree/stable/process-springboot-example[`process-springboot-example`] application. You can follow similar steps with the other {PRODUCT} examples on Quarkus or Spring Boot. + +In the `process-quarkus-example` and `process-springboot-example` applications, the `orders.bpmn2` process describes the steps that need to be followed when ordering items. The process includes a script task for writing debug information and a call activity for invoking a subprocess, using a custom `Order` data object. + +.Example `orders.bpmn2` process +image::kogito/creating-running/bpmn-model-example-orders.png[Image of `orders.bpmn` example process] + +The `Add items` subprocess invokes the following `orderItems.bpmn2` process, which uses a `CalculationService.calculateTotal` custom Java service and a user task to verify the order. + +.Example `orderItems.bpmn2` process invoked as a subprocess +image::kogito/creating-running/bpmn-model-example-order-items.png[Image of `orderItems.bpmn` example process] + +The `persons.bpmn2` process invokes a Drools Rule Languge (DRL) rule unit in a business rule task to determine customer age, followed by a user task for special handling requirements for children, if applicable. + +.Example `persons.bpmn2` process invoked as a subprocess +image::kogito/creating-running/kogito-bpmn-example-person.png[Image of `persons` process diagram] + +Based on these processes and on application configurations, this example service exposes REST operations to create new orders, to list and delete active orders, and to determine the age of a specified person. + +.Procedure +. Download the latest https://github.com/kiegroup/kogito-examples/releases[`kogito-examples`] release to a local directory and extract the file. +. In a command terminal, navigate to the extracted `kogito-examples-__RELEASE__/process-__PLATFORM__-example` folder, and enter one of the following commands to build and run the example. ++ +-- +Quarkus and Spring Boot support the following run modes: + +* *Development mode*: For local testing. On Quarkus, development mode also offers live reload of your processes and decisions in your running applications for advanced debugging. +* *JVM mode*: For compatibility with a Java virtual machine (JVM). +ifdef::KOGITO-COMM[] +* *Native mode*: (Quarkus only, requires GraalVM) For direct binary execution as native code. +endif::[] + +The command that you use depends on your preferred run mode and application environment: + +* For development mode: ++ +.On Quarkus +[source] +---- +mvn clean compile quarkus:dev +---- ++ +.On Sprint Boot +[source] +---- +mvn clean compile spring-boot:run +---- ++ +* For JVM mode: ++ +.On Quarkus and Spring Boot +[source] +---- +mvn clean package +java -jar target/sample-kogito-1.0-SNAPSHOT-runner.jar +---- ++ +ifdef::KOGITO-COMM[] +* For native mode (requires GraalVM): ++ +.On Quarkus only +[source] +---- +mvn clean package -Dnative +./target/sample-kogito-1.0-SNAPSHOT-runner +---- ++ +endif::[] +-- +. After the {PRODUCT} service is running, use a REST client, curl utility, or the Swagger UI configured for the application at http://localhost:8080/swagger-ui/ to send API requests with the following components: ++ +-- +* *URL*: `\http://localhost:8080/` +* *HTTP headers*: +** `accept`: `application/json` +** `content-type`: `application/json` +* *HTTP methods*: `GET`, `POST`, or `DELETE` + +.Example POST request body to create an order (JSON) +[source,json] +---- +{ + "approver": "john", + "order": { + "orderNumber": "12345", + "shipped": false + } +} +---- + +.Example curl command to create an order +[source] +---- +curl -X POST http://localhost:8080/orders -H 'content-type: application/json' -H 'accept: application/json' -d '{"approver" : "john", "order" : {"orderNumber" : "12345", "shipped" : false}}' +---- + +.Example response (JSON) +[source,json] +---- +{ + "approver": "john", + "id": "6b53c227-6d5e-40b7-8c8c-a541a2a47d58", + "order": { + "orderNumber": "12345", + "shipped": false, + "total": 0.3845152065899532 + } +} +---- + +.Swagger UI to interact with all application endpoints (\http://localhost:8080/swagger-ui/) +image::kogito/creating-running/kogito-swagger-example-jbpm.png[Image of Swagger UI for example application] + +NOTE: For the predefined {PRODUCT} example applications, the Swagger UI for interacting with service endpoints is available only on Quarkus examples that you run in +ifdef::KOGITO-ENT[] +development mode. +endif::[] +ifdef::KOGITO-COMM[] +development mode or in native mode. +endif::[] + +This example procedure uses the following curl commands for convenience: + +* Create an order: ++ +.Example request +[source] +---- +curl -X POST http://localhost:8080/orders -H 'content-type: application/json' -H 'accept: application/json' -d '{"approver" : "john", "order" : {"orderNumber" : "12345", "shipped" : false}}' +---- ++ +.Example response +[source] +---- +{"approver":"john","id":"6b53c227-6d5e-40b7-8c8c-a541a2a47d58","order":{"orderNumber":"12345","shipped":false,"total":0.3845152065899532}} +---- ++ +The new order has an `"id"` field with a generated UUID that you can use to retrieve details about this specific order, if needed. + +* View active orders: ++ +.Example request +[source] +---- +curl -X GET http://localhost:8080/orders -H 'content-type: application/json' -H 'accept: application/json' +---- ++ +.Example response +[source] +---- +[{"approver":"john","id":"6b53c227-6d5e-40b7-8c8c-a541a2a47d58","order":{"orderNumber":"12345","shipped":false,"total":0.3845152065899532}}] +---- + +* View order details using the returned UUID: ++ +.Example request +[source] +---- +curl -X GET http://localhost:8080/orders/6b53c227-6d5e-40b7-8c8c-a541a2a47d58 -H 'content-type: application/json' -H 'accept: application/json' +---- ++ +.Example response +[source] +---- +{"approver":"john","id":"6b53c227-6d5e-40b7-8c8c-a541a2a47d58","order":{"orderNumber":"12345","shipped":false,"total":0.3845152065899532}} +---- ++ +You use the `"id"` value for the order that was returned when you created the order or when you retrieved active orders. + +* Cancel the order using the returned UUID: ++ +.Example request +[source] +---- +curl -X DELETE http://localhost:8080/orders/6b53c227-6d5e-40b7-8c8c-a541a2a47d58 -H 'content-type: application/json' -H 'accept: application/json' +---- +-- diff --git a/assemblies/modules/creating-running/proc-kogito-creating-project.adoc b/assemblies/modules/creating-running/proc-kogito-creating-project.adoc new file mode 100644 index 0000000..3c1af4a --- /dev/null +++ b/assemblies/modules/creating-running/proc-kogito-creating-project.adoc @@ -0,0 +1,38 @@ +[id='proc-kogito-creating-project_{context}'] += Creating a Maven project for a {PRODUCT} service + +Before you can begin developing {PRODUCT} services, you need to create a Maven project where you can build your {PRODUCT} assets and any other related resources for your application. + +.Procedure +. In a command terminal, navigate to a local folder where you want to store the new {PRODUCT} project. +. Run the following command to generate a project within a defined folder: ++ +-- +.On Quarkus +[source] +---- +mvn archetype:generate \ + -DarchetypeGroupId=org.kie.kogito \ + -DarchetypeArtifactId=kogito-quarkus-archetype \ + -DgroupId=org.acme -DartifactId=sample-kogito \ + -Dversion=1.0-SNAPSHOT +---- +//// +@comment: The following standard command for Quarkus isn't working currently but may be restored for Dev Preview + +mvn io.quarkus:quarkus-maven-plugin:create -DprojectGroupId=com.company -DprojectArtifactId=sample-kogito -Dextensions="kogito" +//// + +.On Spring Boot +[source] +---- +mvn archetype:generate \ + -DarchetypeGroupId=org.kie.kogito \ + -DarchetypeArtifactId=kogito-springboot-archetype \ + -DgroupId=org.acme -DartifactId=sample-kogito \ + -Dversion=1.0-SNAPSHOT +---- + +This command generates a `sample-kogito` Maven project and imports the {PRODUCT} extension for all required dependencies and configurations to prepare your application for business automation. +-- +. Open or import the project in your VSCode IDE to view the contents. diff --git a/assemblies/modules/creating-running/proc-kogito-designing-app-rule-units.adoc b/assemblies/modules/creating-running/proc-kogito-designing-app-rule-units.adoc new file mode 100644 index 0000000..0cc59ae --- /dev/null +++ b/assemblies/modules/creating-running/proc-kogito-designing-app-rule-units.adoc @@ -0,0 +1,71 @@ +[id='proc-kogito-designing-app-rule-units_{context}'] += Using DRL rule units as an alternative decision service + +As an alternative to using Decision Model and Notation (DMN) to define this example decision service, you can also use a Drools Rule Language (DRL) file implemented as a rule unit. + +A DRL rule unit is a module for rules and a unit of execution. A rule unit collects a set of rules with the declaration of the type of facts that the rules act on. A rule unit also serves as a unique namespace for each group of rules. A single rule base can contain multiple rule units. You typically store all the rules for a unit in the same file as the unit declaration so that the unit is self-contained. For more information about rule units, see +ifdef::KOGITO-ENT[] +{URL_DECISION_SERVICES}#con-drl-rule-units_drl-rules[_{DECISION_SERVICES}_]. +endif::[] +ifdef::KOGITO-COMM[] +xref:con-drl-rule-units_drl-rules[]. +endif::[] + +.Procedure +. In the `src/main/resources` folder of your example {PRODUCT} project, instead of using a DMN file, add the following `PersonRules.drl` file: ++ +-- +.Example person DRL file +[source] +---- +package org.acme +unit PersonRules; + +import org.acme.Person; + +rule isAdult + when + $person: /person[ age > 18 ] + then + modify($person) { + setAdult(true) + }; +end +---- + +This example rule determines that any person who is older than 18 is classified as an adult. The rule file also declares that the rule belongs to the rule unit `PersonRules`. This is the rule unit that you define as part of the business rule task in the example BPMN process. When you build the project, the rule unit is generated and associated with the DRL file. + +The rule also defines the condition using OOPath notation. OOPath is an object-oriented syntax extension to XPath for navigating through related elements while handling collections and filtering constraints. + +You can also rewrite the same rule condition in a more explicit form using the traditional rule pattern syntax, as shown in the following example: + +.Example person DRL file using traditional notation +[source] +---- +package org.acme +unit PersonRules; + +import org.acme.Person; + +rule isAdult + when + $person: Person(age > 18) from person + then + modify($person) { + setAdult(true) + }; +end +---- +-- +. In the `src/main/resources` folder, use the {PRODUCT} BPMN modeler in VSCode to open the `PersonProcess.bpmn2` process diagram that you created. +. Select the `Evaluate person` business rule task and modify the following properties: + +* *Implementation/Execution*: Set the following values: +** *Rule Language*: `DRL` (instead of `DMN`) +** *Rule Flow Group*: `unit:org.acme.PersonRules` ++ +This rule unit syntax in the *Rule Flow Group* field specifies that you are using the `org.acme.PersonRules` rule unit instead of a traditional rule flow group. This is the rule unit that you referenced in the example DRL file. When you build the project, the business process implicitly declares the rule unit as part of the business rule task to execute the DRL file. +* *Data Assignments*: Open the assignment settings and change the data input *Name* to `person` (instead of `Person`). This accommodates the input variable syntax required by the DRL file. +. Select the connector that connects the exclusive gateway to the end event and for the *Implementation/Execution* property, verify that the *Condition Expression* is set to `Java` and change the condition to `return person.isAdult();`. +. Select the connector that connects the exclusive gateway to the user task and for the *Implementation/Execution* property, verify that the *Condition Expression* is set to `Java` and change the condition `return ! person.isAdult();`. +. Save the process file to update the model. diff --git a/assemblies/modules/creating-running/proc-kogito-designing-app.adoc b/assemblies/modules/creating-running/proc-kogito-designing-app.adoc new file mode 100644 index 0000000..ebb2a92 --- /dev/null +++ b/assemblies/modules/creating-running/proc-kogito-designing-app.adoc @@ -0,0 +1,516 @@ +[id='proc-kogito-designing-app_{context}'] += Designing the application logic for a {PRODUCT} service using DMN and BPMN + +After you create your {PRODUCT} project, you can create or import Business Process Model and Notation (BPMN) 2.0 business processes, Decision Model and Notation (DMN) decision models, Drools Rule Language (DRL) business rules, XLS or XLSX decision tables, and other assets in the `src/main/resources` folder of your project. You can also include Java classes in the `src/main/java` folder of your project that act as Java services or that provide implementations that you call from your business processes or decisions. + +The example for this procedure is a basic {PRODUCT} service that provides a REST endpoint `/persons`. This endpoint is automatically generated based on an example `PersonProcess.bpmn2` business process that employs an example `PersonDecisions.dmn` DMN model to make decisions based on the data being processed. + +The business process contains the business logic of the {PRODUCT} service. The process provides the complete set of steps to achieve the business goal. The process is also the entry point to the service that can be consumed by other services. + +The business decision contains the decision logic of the {PRODUCT} service. In this example, the decision logic is invoked as part of the business process. You can define business rules and decisions in several ways, such as with DMN models, DRL rules, or XLS or XLSX decision tables. The example for this procedure uses a DMN model. + +.Procedure +. In the Maven project that you generated for your {PRODUCT} service, navigate to the `src/main/java/org/acme` folder and add the following `Person.java` file: ++ +-- +.Example person Java object +[source,java] +---- +package org.acme; + +import java.io.Serializable; + +public class Person { + + private String name; + private int age; + private boolean adult; + + public String getName() { + return name; + } + + public void setName(String name) { + this.name = name; + } + + public int getAge() { + return age; + } + + public void setAge(int age) { + this.age = age; + } + + public boolean isAdult() { + return adult; + } + + public void setAdult(boolean adult) { + this.adult = adult; + } + + @Override + public String toString() { + return "Person [name=" + name + ", age=" + age + ", adult=" + adult + "]"; + } + +} +---- +This example Java object sets and retrieves a person's name, age, and adult status. +-- +. Navigate to the `src/main/resources` folder and add the following `PersonDecisions.dmn` DMN decision model: ++ +-- +.Example person DMN decision requirements diagram (DRD) +image::kogito/creating-running/kogito-dmn-example-person.png[Image of person DMN decision diagram] + +.Example DMN boxed expression for Is Adult decision +image::kogito/creating-running/kogito-dmn-example-person-logic.png[Image of person DMN decision table] + +.Example DMN data types +image::kogito/creating-running/kogito-dmn-example-person-data-types.png[Image of person DMN data types] + +This example DMN model consists of a basic DMN input node and a decision node defined by a DMN decision table with a custom structured data type. + +In VSCode (recommended), you can add the {PRODUCT} https://github.com/kiegroup/kogito-tooling/releases[VSCode extension] to design the decision requirements diagram (DRD), boxed expression, and data types with the {PRODUCT} DMN modeler. + +To create this example DMN model quickly, you can copy the following `PersonDecisions.dmn` file content: + +.Example DMN file +[source,xml] +---- + + + + + number + + + string + + + boolean + + + + + + + + + + + + + + + + Person.Age + + + + + + > 18 + + + true + + + + + <= 18 + + + false + + + + + + + + + + 50 + 100 + 100 + 100 + + + + + + + + + + + + + + + + + + + + + + + + + + + + +---- + +To create this example DMN model in VSCode using the {PRODUCT} DMN modeler, follow these steps: + +.. In the upper-right corner of the DMN modeler, click the *Properties* icon and confirm that the DMN model *Name* is set to `PersonDecisions`. +.. In the left palette, select *DMN Input Data*, drag the node to the canvas, and double-click the node to name it `Person`. +.. In the left palette, select *DMN Decision*, drag the node to the canvas, double-click the node to name it `isAdult`, and link to it from the input node. +.. Select the decision node to display the node options and click the *Edit* icon to open the DMN boxed expression editor to define the decision logic for the node. +.. Click the undefined expression field and select *Decision Table*. +.. Click the upper-left corner of the decision table to set the hit policy to *Unique*. +.. Set the input and output columns so that the input source `Person.Age` with type `number` determines the age limit and the output target `isAdult` with type `boolean` determines adult status: ++ +.Example DMN decision table for `isAdult` decision +image::kogito/creating-running/kogito-dmn-example-person-logic.png[Image of person DMN decision table] +.. In the upper tab options, select the *Data Types* tab and add the following `tPerson` structured data type and nested data types: ++ +.Example DMN data types +image::kogito/creating-running/kogito-dmn-example-person-data-types.png[Image of person DMN data types] +.. After you define the data types, select the *Editor* tab to return to the DMN modeler canvas. +.. Select the *Person* input node, click the *Properties* icon, and under *Information item*, set the *Data type* to `tPerson`. +.. Select the *isAdult* decision node, click the *Properties* icon, and under *Information item*, confirm that the *Data type* is still set to `boolean`. You previously set this data type when you created the decision table. +.. Save the DMN decision file. +-- +. In the `src/main/resources` folder, add the following `PersonProcess.bpmn2` BPMN process model: ++ +-- +.Example person BPMN process +image::kogito/creating-running/kogito-bpmn-example-person.png[Image of person process diagram] + +This example process consists of the following basic BPMN components: + +* Start event +* Business rule task +* Exclusive gateway +* User task +* End events + +In VSCode (recommended), you can add the {PRODUCT} https://github.com/kiegroup/kogito-tooling/releases[VSCode extension] to model the business process with the {PRODUCT} BPMN modeler. + +To create this example process quickly, you can copy the following `PersonProcess.bpmn2` file content: + +.Example BPMN file +[source,xml] +---- + + + + + + + + + + + + + + + + + + + + + + + + + + + + return isAdult == false; + + + + return isAdult == true; + + + + + StartProcess + + + SequenceFlow_1 + + + + + Evaluate person + + + SequenceFlow_1 + SequenceFlow_2 + + + + + + + + BusinessRuleTask_1_namespaceInputX + BusinessRuleTask_1_decisionInputX + BusinessRuleTask_1_modelInputX + BusinessRuleTask_1_PersonInputX + + + BusinessRuleTask_1_isAdultOutputX + + + + BusinessRuleTask_1_namespaceInputX + + https://kiegroup.org/dmn/_52CEF9FD-9943-4A89-96D5-6F66810CA4C1 + BusinessRuleTask_1_namespaceInputX + + + + BusinessRuleTask_1_decisionInputX + + isAdult + BusinessRuleTask_1_decisionInputX + + + + BusinessRuleTask_1_modelInputX + + PersonDecisions + BusinessRuleTask_1_modelInputX + + + + person + BusinessRuleTask_1_PersonInputX + + + BusinessRuleTask_1_isAdultOutputX + isAdult + + + + + + Exclusive Gateway 1 + + + SequenceFlow_2 + SequenceFlow_5 + SequenceFlow_3 + + + + + Special handling for children + + + SequenceFlow_3 + SequenceFlow_4 + + + + + + + UserTask_1_TaskNameInputX + UserTask_1_personInputX + UserTask_1_SkippableInputX + UserTask_1_PriorityInputX + + + + UserTask_1_TaskNameInputX + + ChildrenHandling + UserTask_1_TaskNameInputX + + + + person + UserTask_1_personInputX + + + UserTask_1_SkippableInputX + + true + UserTask_1_SkippableInputX + + + + UserTask_1_PriorityInputX + + 1 + UserTask_1_PriorityInputX + + + + + + + End Event 1 + + + SequenceFlow_4 + + + + + End Event 2 + + + SequenceFlow_5 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + _J4ElsVJgEDiScotxwBQ14Q + _J4ElsVJgEDiScotxwBQ14Q + + +---- + +To create this example BPMN process in VSCode using the {PRODUCT} BPMN modeler, follow these steps: + +.. In the upper-right corner of the BPMN modeler, click the *Properties* icon and define the following properties: +* *Process*: Set the following values: +** *Name*: `Person Process` +** *ID*: `persons` +** *Package*: `org.acme` +* *Process Data*: Add the following process variables: +** `person` with the type `org.acme.Person` (Use the *Custom* data type option to define the custom type.) +** `isAdult` with the type `Boolean` +.. In the left palette, select *Activities* -> *Business Rule*, drag the task to the canvas, and link to it from the start event. +.. Select the business rule task and define the following properties: + +* *General*: Set the rule task *Name* to `Evaluate person`. +* *Implementation/Execution*: Set the following values: +** *Rule Language*: `DMN` +** *Namespace*: The `namespace` property value from the `PersonDecisions.dmn` file that you created previously, such as `\https://kiegroup.org/dmn/_52CEF9FD-9943-4A89-96D5-6F66810CA4C1` +** *Decision Name*: `isAdult` +** *DMN Model Name*: `PersonDecisions` +* *Data Assignments*: Add the following assignments: +** *Data Input*: Add a data input with the name `Person`, with the type `org.acme.Person`, and with the source `person`. +** *Data Output*: Add a data output with the name `isAdult`, with the type `Boolean`, and with the source `isAdult`. +.. In the left palette, select *Gateways* -> *Exclusive*, drag the gateway to the canvas, and link to it from the rule task. +.. In the left palette, select *Activities* -> *User*, drag the user task to the canvas, and link to it from the exclusive gateway. +.. Select the user task and define the following properties: + +* *General*: Set the user task *Name* to `Special handling for children`. +* *Implementation/Execution*: Set the *Task Name* to `ChildrenHandling`, and add a data input with the name `person`, the type `org.acme.Person`, and the source `person`. +.. In the left palette, select *End Events* -> *End*, drag two end events to the canvas, and link to one end event from the user task and to the other end event from the exclusive gateway. +.. Select the connector that connects the exclusive gateway to the end event and for the *Implementation/Execution* property, set the *Condition Expression* to `Java` and enter the condition `return isAdult == true;`. +.. Select the connector that connects the exclusive gateway to the user task and for the *Implementation/Execution* property, set the *Condition Expression* to `Java` and enter the condition to `return isAdult == false;` +.. Save the BPMN process file. +-- diff --git a/assemblies/modules/creating-running/proc-kogito-interacting-app.adoc b/assemblies/modules/creating-running/proc-kogito-interacting-app.adoc new file mode 100644 index 0000000..2104042 --- /dev/null +++ b/assemblies/modules/creating-running/proc-kogito-interacting-app.adoc @@ -0,0 +1,140 @@ +[id='proc-kogito-interacting-app_{context}'] += Interacting with a running {PRODUCT} service + +After your {PRODUCT} service is running, you can send REST API requests to interact with your application and execute your services according to how you set up the application. + +This example tests the `/persons` REST API endpoint that is automatically generated based on the `PersonProcess.bpmn2` business process, according to the decisions in the `PersonDecisions.dmn` file (or the rules in the `PersonRules.drl` file if you used a DRL rule unit). + +For this example, use a REST client, curl utility, or the Swagger UI configured for the application at http://localhost:8080/swagger-ui/ to send API requests with the following components: + +* *URL*: `\http://localhost:8080/persons` +* *HTTP headers*: +** `accept`: `application/json` +** `content-type`: `application/json` +* *HTTP methods*: `GET`, `POST`, or `DELETE` + +.Example POST request body to add an adult (JSON) +[source,json] +---- +{ + "person": { + "name": "John Quark", + "age": 20 + } +} +---- + +.Example curl command to add an adult +[source] +---- +curl -X POST http://localhost:8080/persons -H 'content-type: application/json' -H 'accept: application/json' -d '{"person": {"name":"John Quark", "age": 20}}' +---- + +.Example response (JSON) +[source,json] +---- +{ + "id": "3af806dd-8819-4734-a934-728f4c819682", + "person": { + "name": "John Quark", + "age": 20, + "adult": false + }, + "isAdult": true +} +---- + +.Swagger UI to interact with all application endpoints (\http://localhost:8080/swagger-ui/) +image::kogito/creating-running/kogito-swagger-example.png[Image of Swagger UI for example application] + +This example procedure uses curl commands for convenience. + +.Procedure +In a command terminal window that is separate from your running application, navigate to the project that contains your {PRODUCT} service and use any of the following curl commands with JSON requests to interact with your running service: + +NOTE: On Spring Boot, you might need to modify how your application exposes API endpoints in order for these example requests to function. For more information, see the `README` file included in the example Spring Boot project that you created for this tutorial. + +* Add an adult person: ++ +-- +.Example request +[source] +---- +curl -X POST http://localhost:8080/persons -H 'content-type: application/json' -H 'accept: application/json' -d '{"person": {"name":"John Quark", "age": 20}}' +---- + +.Example response +[source] +---- +{"id":"3af806dd-8819-4734-a934-728f4c819682","person":{"name":"John Quark","age":20,"adult":false},"isAdult":true} +---- +-- +* Add an underage person: ++ +-- +.Example request +[source] +---- +curl -X POST http://localhost:8080/persons -H 'content-type: application/json' -H 'accept: application/json' -d '{"person": {"name":"Jenny Quark", "age": 15}}' +---- + +.Example response +[source] +---- +{"id":"8eef502b-012b-4628-acb7-73418a089c08","person":{"name":"Jenny Quark","age":15,"adult":false},"isAdult":false} +---- +-- +* View active process instances: ++ +-- +.Example request +[source] +---- +curl -X GET http://localhost:8080/persons -H 'content-type: application/json' -H 'accept: application/json' +---- + +.Example response +[source] +---- +[{"id":"8eef502b-012b-4628-acb7-73418a089c08","person":{"name":"Jenny Quark","age":15,"adult":false},"isAdult":false}] +---- +-- +* View process instance details using the returned process UUID: ++ +-- +.Example request +[source] +---- +curl -X GET http://localhost:8080/persons/8eef502b-012b-4628-acb7-73418a089c08/tasks -H 'content-type: application/json' -H 'accept: application/json' +---- + +.Example response (JSON) +[source] +---- +{"cdec4241-d676-47de-8c55-4ee4f9598bac":"ChildrenHandling"} +---- +-- +* View task instance details using the returned process and task UUIDs: ++ +-- +.Example request +[source] +---- +curl -X GET http://localhost:8080/persons/8eef502b-012b-4628-acb7-73418a089c08/ChildrenHandling/cdec4241-d676-47de-8c55-4ee4f9598bac -H 'content-type: application/json' -H 'accept: application/json' +---- + +.Example response +[source] +---- +{"person":{"name":"Jenny Quark","age":15,"adult":false},"name":"ChildrenHandling","id":"cdec4241-d676-47de-8c55-4ee4f9598bac"} +---- +-- +* Complete the evaluation using the returned UUIDs: ++ +-- +.Example request +[source] +---- +curl -X POST http://localhost:8080/persons/8eef502b-012b-4628-acb7-73418a089c08/ChildrenHandling/cdec4241-d676-47de-8c55-4ee4f9598bac -H 'content-type: application/json' -H 'accept: application/json' -d '{}' +---- +-- diff --git a/assemblies/modules/creating-running/proc-kogito-modelers.adoc b/assemblies/modules/creating-running/proc-kogito-modelers.adoc new file mode 100644 index 0000000..47cfb44 --- /dev/null +++ b/assemblies/modules/creating-running/proc-kogito-modelers.adoc @@ -0,0 +1,41 @@ +[id='proc-kogito-modelers_{context}'] += Installing and using the {PRODUCT} Business Modeler Hub + +{PRODUCT} provides a https://kiegroup.github.io/kogito-online/#/download[Business Modeler Hub] desktop application with all {PRODUCT} extensions or applications for modeling Business Process Model and Notation (BPMN) process models and Decision Model and Notation (DMN) decision models in {PRODUCT} services. {PRODUCT} currently provides extensions for VSCode (recommended) and GitHub modelers, a desktop application for offline modeling, and an online modeler. + +As you develop {PRODUCT} services, you can use the {PRODUCT} Business Modeler Hub to install, launch, or uninstall the available modeling extensions or applications as needed. + +.Procedure +. In a web browser, go to the https://kiegroup.github.io/kogito-online/#/download[Business Modeler Hub] download page, select the relevant *Operating System* option, and click *Download*. +. Extract the downloaded `business_modeler_hub_preview___RELEASE__` binary file to a local directory. ++ +-- +* On Linux: In a command terminal, navigate to the directory where you downloaded the `business_modeler_hub_preview___RELEASE__` binary file and enter the following command to extract the contents: ++ +.Extract the {PRODUCT} Business Modeler Hub distribution +[source,subs="attributes+,+quotes"] +---- +tar -xzpf business_modeler_hub_preview___RELEASE__.tar.gz +---- + +* On Windows or Mac: In your file browser, navigate to the directory where you downloaded the `business_modeler_hub_preview___RELEASE__` binary file and extract the ZIP file. +-- +. In a command terminal, navigate to the extracted `business_modeler_hub_preview___RELEASE__` folder and enter the following command to run the application: ++ +-- +.Run the {PRODUCT} Business Modeler Hub application +[source,subs="attributes+,+quotes"] +---- +$ cd __PATH_TO_MODELER_HUB__ +$ ./Business\ Modeler\ Hub\ Preview-__RELEASE__/Business\ Modeler\ Hub\ Preview +---- + +The *Business Modeler Hub* opens in a new window: + +.{PRODUCT} Business Modeler Hub window +image::kogito/creating-running/kogito-modeler-hub.png[Image of Business Modeler Hub] + +NOTE: If the *Business Modeler Hub* window does not appear, review the `README` documentation in the Business Modeler Hub application folder for any details specific to your operating system. + +Use the {PRODUCT} Business Modeler Hub to install, launch, or uninstall the available extensions or applications as needed. +-- diff --git a/assemblies/modules/creating-running/proc-kogito-running-app.adoc b/assemblies/modules/creating-running/proc-kogito-running-app.adoc new file mode 100644 index 0000000..6f5b1ee --- /dev/null +++ b/assemblies/modules/creating-running/proc-kogito-running-app.adoc @@ -0,0 +1,51 @@ +[id='proc-kogito-running-app_{context}'] += Running a {PRODUCT} service + +After you design the business decisions and processes for your {PRODUCT} service, you can run your Quarkus or Spring Boot application in one of the following modes: + +* *Development mode*: For local testing. On Quarkus, development mode also offers live reload of your processes and decisions in your running applications for advanced debugging. +* *JVM mode*: For compatibility with a Java virtual machine (JVM). +ifdef::KOGITO-COMM[] +* *Native mode*: (Quarkus only, requires GraalVM) For direct binary execution as native code. +endif::[] + +.Procedure +In a command terminal, navigate to the project that contains your {PRODUCT} service and enter one of the following commands, depending on your preferred run mode and application environment: + +* For development mode: ++ +-- +.On Quarkus +[source] +---- +mvn clean compile quarkus:dev +---- + +.On Sprint Boot +[source] +---- +mvn clean compile spring-boot:run +---- +-- +* For JVM mode: ++ +-- +.On Quarkus and Spring Boot +[source] +---- +mvn clean package +java -jar target/sample-kogito-1.0-SNAPSHOT-runner.jar +---- +-- +ifdef::KOGITO-COMM[] +* For native mode (requires GraalVM): ++ +-- +.On Quarkus only +[source] +---- +mvn clean package -Dnative +./target/sample-kogito-1.0-SNAPSHOT-runner +---- +-- +endif::[] diff --git a/assemblies/modules/creating-running/proc-kogito-vscode-extension.adoc b/assemblies/modules/creating-running/proc-kogito-vscode-extension.adoc new file mode 100644 index 0000000..40be39d --- /dev/null +++ b/assemblies/modules/creating-running/proc-kogito-vscode-extension.adoc @@ -0,0 +1,38 @@ +[id='proc-kogito-vscode-extension_{context}'] += Enabling the {PRODUCT} VSCode extension without the {PRODUCT} Business Modeler Hub + +Visual Studio Code (VSCode) is the preferred integrated development environment (IDE) for developing {PRODUCT} services. {PRODUCT} provides a https://github.com/kiegroup/kogito-tooling/releases[VSCode extension] that enables you to design Business Process Model and Notation (BPMN) 2.0 business processes and Decision Model and Notation (DMN) decision models directly in VSCode. + +For convenience, you can install and launch the VSCode from the https://kiegroup.github.io/kogito-online/#/download[Business Modeler Hub] desktop application, along with all other available {PRODUCT} modelers. + +However, if you need to enable the VSCode extension without the {PRODUCT} Business Modeler Hub, follow this procedure to download and install the VSCode extension manually. + +.Prerequisites +* https://code.visualstudio.com/[VSCode] 1.43.0 or later is installed. + +.Procedure +. In the https://github.com/kiegroup/kogito-tooling/releases[`kogito-tooling`] releases page in GitHub, download the latest version of the `vscode_extension_{PRODUCT_INIT}_kie_editors___VERSION__.vsix` file. +. In your VSCode IDE, go to *Extensions* -> *More actions* -> *Install from VSIX* and select the downloaded extension file. +. When the {PRODUCT} extension appears in the extension list in VSCode, select it and click *Enable*, if needed. +. Close your instance of VSCode and re-launch VSCode from a command terminal with the following command and parameters: ++ +-- +.On Linux or Windows +[source] +---- +$ code --enable-proposed-api kiegroup.vscode-extension-pack-kogito-kie-editors +---- +.On Mac +[source] +---- +$ code --args --enable-proposed-api kiegroup.vscode-extension-pack-kogito-kie-editors +---- + +Use this method to open VSCode each time you develop {PRODUCT} services. This set of parameters enables the Microsoft https://code.visualstudio.com/api/advanced-topics/using-proposed-api[Proposed API] for an optimal user experience with VSCode extensions. +-- + +After you enable this VSCode extension, any `.bpmn2` and `.dmn` files that you open in VSCode are automatically displayed as graphical models. + +If the {PRODUCT} BPMN or DMN modelers open only the XML source of a BPMN or DMN file and displays an error message, review the reported errors and the model file to ensure that all BPMN or DMN elements are correctly defined. + +NOTE: For new BPMN or DMN models, you can also enter `bpmn.new` or `dmn.new` in a web browser to design your BPMN or DMN model in the {PRODUCT} online modeler. When you finish creating your model, you can click *Download* in the online modeler page to import your BPMN or DMN file into your {PRODUCT} project in VSCode. diff --git a/assemblies/modules/creating-running/ref-kogito-app-examples.adoc b/assemblies/modules/creating-running/ref-kogito-app-examples.adoc new file mode 100644 index 0000000..4915251 --- /dev/null +++ b/assemblies/modules/creating-running/ref-kogito-app-examples.adoc @@ -0,0 +1,18 @@ +[id='ref-kogito-app-examples_{context}'] += Example applications with {PRODUCT} services + +{PRODUCT} includes example applications in the https://github.com/kiegroup/kogito-examples[`kogito-examples`] repository in GitHub. These example applications contain various types of {PRODUCT} services on Quarkus or Spring Boot to help you develop your own applications. The services use one or more Business Process Model and Notation (BPMN) process models, Decision Model and Notation (DMN) decision models, Drools Rule Language (DRL) rule units, XLS spreadsheet decision tables, or Java classes to define the service logic. + +For information about each example application and instructions for using them, see the `README` file in the relevant application folder. + +NOTE: In the https://github.com/kiegroup/kogito-examples[`{PRODUCT_INIT}-examples`] repository in GitHub, the example applications in the default `stable` branch use the latest version of {PRODUCT}. + +The following list describes some of the examples provided with {PRODUCT}: + +* `dmn-quarkus-example` and `dmn-springboot-example`: A decision service (on Quarkus or Spring Boot) that uses DMN to determine driver penalty and suspension based on traffic violations +* `rules-quarkus-helloworld`: A Hello World decision service on Quarkus with a single DRL rule unit +* `ruleunit-quarkus-example` and `ruleunit-springboot-example`: A decision service (on Quarkus or Spring Boot) that uses DRL with rule units to validate a loan application and that exposes REST operations to view application status +* `process-quarkus-helloworld`: A Hello World process service on Quarkus with a single BPMN model +* `process-quarkus-example` and `process-springboot-example`: A process service (on Quarkus or Spring Boot) for ordering items and that exposes REST operations to create new orders or to list and delete active orders +* `onboarding-example`: A combination of a process service and two decision services that use DMN and DRL for onboarding new employees +* `kogito-travel-agency`: A combination of process services and decision services that use DRL and XLS for travel booking, intended for deployment on {OPENSHIFT} diff --git a/assemblies/modules/creating-running/ref-kogito-glossary.adoc b/assemblies/modules/creating-running/ref-kogito-glossary.adoc new file mode 100644 index 0000000..76de0e4 --- /dev/null +++ b/assemblies/modules/creating-running/ref-kogito-glossary.adoc @@ -0,0 +1,294 @@ +[id='ref-kogito-glossary_{context}'] += {PRODUCT} glossary of terms + +This glossary defines terms, concepts, or components that are referenced frequently in {PRODUCT} documentation or that have a unique meaning or function in {PRODUCT}. + +BPMN model:: +A definition of a business process workflow based on the https://www.omg.org/spec/BPMN/2.0/About-BPMN[Business Process Model and Notation (BPMN) specification]. BPMN is a standard established by the Object Management Group (OMG) for describing and modeling business processes. BPMN defines an XML schema that enables BPMN models to be shared between BPMN-compliant platforms and across organizations so that business analysts and business process developers can collaborate in designing and implementing BPMN process services. The BPMN standard is similar to and can be used together with the Decision Model and Notation (DMN) standard for designing and modeling business decisions. ++ +.Additional resources +ifdef::KOGITO-ENT[] +* {URL_PROCESS_SERVICES}[_{PROCESS_SERVICES}_] +endif::[] +ifdef::KOGITO-COMM[] +* xref:chap-kogito-bpmn-models[] +endif::[] + +business domain API:: +An API that your business develops and implements within business applications that contain {PRODUCT} services. + +business models:: +The collection of BPMN process models, DMN decision models, DRL rules, XLS decision tables, and any other assets that define the business logic for a {PRODUCT} service. + +CloudEvents format:: +A specification for describing event data in a common way. {PRODUCT} runtime events for messages, processes, tasks, and other application activities are published in https://cloudevents.io/[CloudEvents] format so that they can be consumed efficiently by other entities, such as the {PRODUCT} Data Index Service. ++ +.Additional resources +ifdef::KOGITO-ENT[] +* {URL_CONFIGURING_KOGITO}#con-kogito-runtime-events_kogito-configuring[_{PRODUCT} runtime events_] +* {URL_CONFIGURING_KOGITO}#con-data-index-service_kogito-configuring[_{PRODUCT} Data Index Service_] +endif::[] +ifdef::KOGITO-COMM[] +* xref:con-kogito-runtime-events_kogito-configuring[] +* xref:con-data-index-service_kogito-configuring[] +endif::[] + +decision table:: +A set of business rules defined in a tabular format. Each row in a decision table is a rule, and each column is a condition, an action, or another rule attribute. ++ +.Additional resources +ifdef::KOGITO-ENT[] +* {URL_DECISION_SERVICES}#con-decision-tables_decision-tables[_Designing a decision service using spreadsheet decision tables_] +endif::[] +ifdef::KOGITO-COMM[] +* xref:con-decision-tables_decision-tables[] +endif::[] + +development mode:: +A project build option that provides a fast feedback loop from code changes to a running system using hot reload. Development mode also enables debugging tools such as Swagger in {PRODUCT} runtime services. ++ +.Additional resources +ifdef::KOGITO-ENT[] +* {URL_CREATING_RUNNING}#proc-kogito-running-app_kogito-creating-running[_Running a {PRODUCT} service_] +endif::[] +ifdef::KOGITO-COMM[] +* xref:proc-kogito-running-app_kogito-creating-running[] +endif::[] +* https://quarkus.io/guides/maven-tooling[_Quarkus - Building applications with Maven_] + +DRL rule:: +A definition of a business rule in Drools Rule Language (DRL) format. DRL is a notation established by the https://www.drools.org/[Drools] open source business automation project for defining and describing business rules. ++ +.Additional resources +ifdef::KOGITO-ENT[] +* {URL_DECISION_SERVICES}#con-drl_drl-rules[_Designing a decision service using DRL rules_] +endif::[] +ifdef::KOGITO-COMM[] +* xref:con-drl_drl-rules[] +endif::[] + +DRL rule unit:: +A module for rules and a unit of execution. A rule unit collects a set of rules with the declaration of the type of facts that the rules act on. A rule unit also serves as a unique namespace for each group of rules. A single rule base can contain multiple rule units. You typically store all the rules for a unit in the same file as the unit declaration so that the unit is self-contained. ++ +.Additional resources +ifdef::KOGITO-ENT[] +* {URL_DECISION_SERVICES}#con-drl-rule-units_drl-rules[_Rule units in DRL_] +endif::[] +ifdef::KOGITO-COMM[] +* xref:con-drl-rule-units_drl-rules[] +endif::[] + +DMN model:: +A definition of a business decision flow based on the https://www.omg.org/spec/DMN[Decision Model and Notation (DMN) specification]. DMN is a standard established by the Object Management Group (OMG) for describing and modeling operational decisions. DMN defines an XML schema that enables DMN models to be shared between DMN-compliant platforms and across organizations so that business analysts and business rules developers can collaborate in designing and implementing DMN decision services. The DMN standard is similar to and can be used together with the Business Process Model and Notation (BPMN) standard for designing and modeling business processes. ++ +.Additional resources +ifdef::KOGITO-ENT[] +* {URL_DECISION_SERVICES}#con-dmn_kogito-dmn-models[_Designing a decision service using DMN models_] +endif::[] +ifdef::KOGITO-COMM[] +* xref:con-dmn_kogito-dmn-models[] +endif::[] + +event listener:: +A procedure or function in a program that reacts to a specified event, such as a completed node in a process or an executed decision. ++ +.Additional resources +ifdef::KOGITO-ENT[] +* {URL_CONFIGURING_KOGITO}#proc-event-listeners-registering_kogito-configuring[_Registering event listeners_] +endif::[] +ifdef::KOGITO-COMM[] +* xref:proc-event-listeners-registering_kogito-configuring[] +endif::[] + +intelligent application:: +An optimized, integrated solution that uses {PRODUCT} services to implement business-domain knowledge. + +{PRODUCT} CLI:: +A command-line interface (CLI) that enables you to interact with the {PRODUCT} Operator for deployment tasks. The {PRODUCT} CLI also enables you to deploy {PRODUCT} services from source instead of relying on custom resources and YAML files. ++ +.Additional resources +ifdef::KOGITO-ENT[] +* {URL_DEPLOYING_ON_OPENSHIFT}#proc-kogito-deploying-on-ocp-kogito-cli_kogito-deploying-on-openshift[_Deploying {PRODUCT} on {OPENSHIFT} using the {PRODUCT} CLI_] +endif::[] +ifdef::KOGITO-COMM[] +* xref:proc-kogito-deploying-on-ocp-kogito-cli_kogito-deploying-on-openshift[] +endif::[] + +//// +//@comment: Excluding for now due to current build issues with the extension and we aren't using it at this point. (Stetson, 2 Apr 2020) +{PRODUCT} Quarkus extension:: +An extension required to generate and build a Maven project for {PRODUCT} runtime services on the Quarkus Java framework. You can add the {PRODUCT} extension during project creation using the Quarkus Maven plugin or using the https://code.quarkus.io/[Code with Quarkus] extension manager. +//// + +{PRODUCT} Data Index Service:: +A dedicated service in {PRODUCT} that stores all {PRODUCT} events related to processes, tasks, and domain data. The Data Index Service uses Apache Kafka messaging to consume CloudEvents messages from {PRODUCT} services, and then indexes the returned data for future GraphQL queries and stores the data in the Infinispan persistence store. The Data Index Service is at the core of all {PRODUCT} search, insight, and management capabilities. ++ +.Additional resources +ifdef::KOGITO-ENT[] +* {URL_CONFIGURING_KOGITO}#con-data-index-service_kogito-configuring[_{PRODUCT} Data Index Service_] +endif::[] +ifdef::KOGITO-COMM[] +* xref:con-data-index-service_kogito-configuring[] +endif::[] + +{PRODUCT} domain-specific service:: +A business automation service for your business domain that you create using {PRODUCT}. You define the logic of this service using BPMN process models, DMN decision models, or other business models, and any other supported runtime configurations. In {PRODUCT} documentation, the general term for _{PRODUCT} services_ that you create refers to this type of service. + +{PRODUCT} Jobs Service:: +A dedicated service in {PRODUCT} for scheduling BPMN process events that are configured to be executed at a specified time. These time-based events in a process model are known as _jobs_. The Jobs Service does not execute a job, but triggers a callback that might be an HTTP request on a given endpoint specified for the job request or any other configured callback. The Jobs Service receives requests for job scheduling and then sends a request at the time specified on the job request. ++ +.Additional resources +ifdef::KOGITO-ENT[] +* {URL_CONFIGURING_KOGITO}#con-jobs-service_kogito-configuring[_{PRODUCT} Jobs Service_] +endif::[] +ifdef::KOGITO-COMM[] +* xref:con-jobs-service_kogito-configuring[] +endif::[] + +{PRODUCT} Management Console:: +A user interface for viewing the state of all available {PRODUCT} services and managing process instances. ++ +.Additional resources +ifdef::KOGITO-ENT[] +* {URL_PROCESS_SERVICES}#con-management-console_kogito-bpmn-models[_{PRODUCT} Management Console_] +endif::[] +ifdef::KOGITO-COMM[] +* xref:con-management-console_kogito-bpmn-models[] +endif::[] + +{PRODUCT} Operator:: +An operator that deploys {PRODUCT} services and manages the required {PRODUCT} infrastructure services. The {PRODUCT} Operator uses the https://github.com/operator-framework[Operator Framework] and automates many of the deployment steps for you. ++ +.Additional resources +ifdef::KOGITO-ENT[] +* {URL_DEPLOYING_ON_OPENSHIFT}#con-kogito-on-ocp_kogito-deploying-on-openshift[_{PRODUCT} on {OPENSHIFT}_] +endif::[] +ifdef::KOGITO-COMM[] +* xref:con-kogito-on-ocp_kogito-deploying-on-openshift[] +endif::[] + +{PRODUCT} runtime event:: +A record of a significant change of state in the application domain at a point in time. {PRODUCT} emits runtime events as a result of successfully executed requests, or _units of work_, in a process instance or task instance in a process. {PRODUCT} can use these events to notify third parties about changes to the BPMN process instance and its data. ++ +.Additional resources +ifdef::KOGITO-ENT[] +* {URL_CONFIGURING_KOGITO}#con-kogito-runtime-events_kogito-configuring[_{PRODUCT} runtime events_] +endif::[] +ifdef::KOGITO-COMM[] +* xref:con-kogito-runtime-events_kogito-configuring[] +endif::[] + +{PRODUCT} runtime persistence:: +An optional capability for preserving {PRODUCT} process data in your services across application restarts. {PRODUCT} persistence is based on https://infinispan.org/[Infinispan] and enables you to configure key-value storage definitions to persist data, such as active process nodes and process instance variables. ++ +.Additional resources +ifdef::KOGITO-ENT[] +* {URL_CONFIGURING_KOGITO}#con-persistence_kogito-configuring[_Persistence in {PRODUCT}_] +endif::[] +ifdef::KOGITO-COMM[] +* xref:con-persistence_kogito-configuring[] +endif::[] + +{PRODUCT} supporting services:: +The collection of middleware infrastructure services and other dedicated services that help you build additional functionality in the {PRODUCT} domain-specific services that you create. Key middleware infrastructure services in {PRODUCT} include Infinispan persistence and Apache Kafka reactive messaging. Dedicated services provided by {PRODUCT} include the {PRODUCT} Data Index Service and the {PRODUCT} Jobs Service. ++ +.Additional resources +ifdef::KOGITO-ENT[] +* {URL_CONFIGURING_KOGITO}#con-data-index-service_kogito-configuring[_{PRODUCT} Data Index Service_] +* {URL_CONFIGURING_KOGITO}#con-jobs-service_kogito-configuring[_{PRODUCT} Jobs Service_] +* {URL_CONFIGURING_KOGITO}#proc-persistence-enabling_kogito-configuring[_Enabling persistence for {PRODUCT} services_] +* {URL_CONFIGURING_KOGITO}#proc-messaging-enabling_kogito-configuring[_Enabling messaging for {PRODUCT} services_] +endif::[] +ifdef::KOGITO-COMM[] +* xref:con-data-index-service_kogito-configuring[] +* xref:con-jobs-service_kogito-configuring[] +* xref:proc-persistence-enabling_kogito-configuring[] +* xref:proc-messaging-enabling_kogito-configuring[] +endif::[] + +message event:: +A specified point in a business process where a defined message is used as the input (received) or output (sent) as a result of the process execution. For example, a message event might be an email sent to a specified user after a task is complete. ++ +.Additional resources +ifdef::KOGITO-ENT[] +* {URL_CONFIGURING_KOGITO}#con-kogito-runtime-events_kogito-configuring[_{PRODUCT} runtime events_] +* {URL_CONFIGURING_KOGITO}#proc-messaging-enabling_kogito-configuring[_Enabling messaging for {PRODUCT} services_] +endif::[] +ifdef::KOGITO-COMM[] +* xref:con-kogito-runtime-events_kogito-configuring[] +* xref:proc-messaging-enabling_kogito-configuring[] +endif::[] + +MicroProfile Reactive Messaging:: +A specification for sending and receiving messages within and between microservices using message brokers. {PRODUCT} supports https://github.com/eclipse/microprofile-reactive-messaging[MicroProfile Reactive Messaging] for messaging in {PRODUCT} services, such as message events used as either input or output of business process execution. ++ +.Additional resources +ifdef::KOGITO-ENT[] +* {URL_CONFIGURING_KOGITO}#proc-messaging-enabling_kogito-configuring[_Enabling messaging for {PRODUCT} services_] +endif::[] +ifdef::KOGITO-COMM[] +* xref:proc-messaging-enabling_kogito-configuring[] +endif::[] + +middleware infrastructure services:: +The collection of supplemental services in {PRODUCT} that provide capabilities such as persistence, messaging, and security. Key middleware infrastructure services in {PRODUCT} include Infinispan persistence and Apache Kafka reactive messaging. ++ +.Additional resources +ifdef::KOGITO-ENT[] +* {URL_CONFIGURING_KOGITO}#proc-persistence-enabling_kogito-configuring[_Enabling persistence for {PRODUCT} services_] +* {URL_CONFIGURING_KOGITO}#proc-messaging-enabling_kogito-configuring[_Enabling messaging for {PRODUCT} services_] +endif::[] +ifdef::KOGITO-COMM[] +* xref:proc-persistence-enabling_kogito-configuring[] +* xref:proc-messaging-enabling_kogito-configuring[] +endif::[] + +process definition:: +A model that defines the components, workflow, and functionality for a business process, such as a BPMN model. + +process instance:: +An occurrence of a pending, running, or completed business process, based on the process definition. + +PROTO file (`.proto`):: +A data library used for marshalling Java objects in protobuf (https://developers.google.com/protocol-buffers/[protocol buffers]) format. {PRODUCT} runtime persistence and communication with Infinispan are handled through a protobuf schema and generated marshallers. ++ +.Additional resources +ifdef::KOGITO-ENT[] +* {URL_CONFIGURING_KOGITO}#con-persistence_kogito-configuring[_Persistence in {PRODUCT}_] +endif::[] +ifdef::KOGITO-COMM[] +* xref:con-persistence_kogito-configuring[] +endif::[] + +task life cycle:: +A mechanism that moves a user task or custom task (work item) across various phases, such as *Active* -> *Claim* -> *Complete*. {PRODUCT} provides standard life cycle phases for user tasks and also supports custom life cycles or life cycle phases. ++ +.Additional resources +ifdef::KOGITO-ENT[] +* {URL_PROCESS_SERVICES}#con-task-life-cycle_kogito-bpmn-models[_Task life cycle in {PRODUCT} processes_] +endif::[] +ifdef::KOGITO-COMM[] +* xref:con-task-life-cycle_kogito-bpmn-models[] +endif::[] + +unit of work:: +A component in {PRODUCT} that serves as the basis for {PRODUCT} runtime execution. Units of work capture all steps in a process and are used internally to move a process instance from one state to the next state. After all possible steps in a process are successfully executed, the final state is sent to the {PRODUCT} runtime as a runtime event. {PRODUCT} can then use these events to notify third parties about changes to the BPMN process instance and its data. ++ +.Additional resources +ifdef::KOGITO-ENT[] +* {URL_CONFIGURING_KOGITO}#con-kogito-runtime-events_kogito-configuring[_{PRODUCT} runtime events_] +endif::[] +ifdef::KOGITO-COMM[] +* xref:con-kogito-runtime-events_kogito-configuring[] +endif::[] + + + +//// +//@comment: Excluding for now due to current lack of support in Kogito. Will add once settled. (Stetson 2 Apr 2020) +Work item:: +A custom task, typically a custom service task, that you can reuse across multiple business processes. + +Work item handler:: +A Java object that contains the implementation logic for a custom task (work item). +//// diff --git a/assemblies/modules/decision-engine/con-agenda-filters.adoc b/assemblies/modules/decision-engine/con-agenda-filters.adoc new file mode 100644 index 0000000..c49f949 --- /dev/null +++ b/assemblies/modules/decision-engine/con-agenda-filters.adoc @@ -0,0 +1,19 @@ +[id='con-agenda-filters_{context}'] += Agenda evaluation filters + +*<@Edoardo, see this section.>* + +ifdef::KOGITO-COMM[] +.AgendaFilters +image::UserGuide/AgendaFilter.png[align="center"] +endif::[] + +The {DECISION_ENGINE} supports an `AgendaFilter` object in the filter interface that you can use to allow or deny the evaluation of specified rules during agenda evaluation. You can specify an agenda filter as part of a `fireAllRules()` call. + +The following example code permits only rules ending with the string `"Test"` to be evaluated and executed. All other rules are filtered out of the {DECISION_ENGINE} agenda. + +.Example agenda filter definition +[source,java] +---- +ksession.fireAllRules( new RuleNameEndsWithAgendaFilter( "Test" ) ); +---- diff --git a/assemblies/modules/decision-engine/con-cep-event-streams.adoc b/assemblies/modules/decision-engine/con-cep-event-streams.adoc new file mode 100644 index 0000000..019d404 --- /dev/null +++ b/assemblies/modules/decision-engine/con-cep-event-streams.adoc @@ -0,0 +1,13 @@ +[id='con-cep-event-streams_{context}'] += Event streams and entry points + +The {DECISION_ENGINE} can process high volumes of events in the form of event streams. In DRL rule declarations, a stream is also known as an _entry point_. When you declare an entry point in a DRL rule or Java application, the {DECISION_ENGINE}, at compile time, identifies and creates the proper internal structures to use data from only that entry point to evaluate that rule. + +Facts from one entry point, or stream, can join facts from any other entry point in addition to facts already in the working memory of the {DECISION_ENGINE}. Facts always remain associated with the entry point through which they entered the {DECISION_ENGINE}. Facts of the same type can enter the {DECISION_ENGINE} through several entry points, but facts that enter the {DECISION_ENGINE} through entry point A can never match a pattern from entry point B. + +Event streams have the following characteristics: + +* Events in the stream are ordered by time stamp. The time stamps may have different semantics for different streams, but they are always ordered internally. +* Event streams usually have a high volume of events. +* Atomic events in streams are usually not useful individually, only collectively in a stream. +* Event streams can be homogeneous and contain a single type of event, or heterogeneous and contain events of different types. diff --git a/assemblies/modules/decision-engine/con-cep-events.adoc b/assemblies/modules/decision-engine/con-cep-events.adoc new file mode 100644 index 0000000..71357de --- /dev/null +++ b/assemblies/modules/decision-engine/con-cep-events.adoc @@ -0,0 +1,17 @@ +[id='con-cep-events_{context}'] += Events in complex event processing + +In {PRODUCT}, an event is a record of a significant change of state in the application domain at a point in time. Depending on how the domain is modeled, the change of state may be represented by a single event, multiple atomic events, or hierarchies of correlated events. From a complex event processing (CEP) perspective, an event is a type of fact or object that occurs at a specific point in time, and a business rule is a definition of how to react to the data from that fact or object. For example, in a stock broker application, a change in security prices, a change in ownership from seller to buyer, or a change in an account holder's balance are all considered to be events because a change has occurred in the state of the application domain at a given time. + +Events have the following key characteristics: + +* *Are immutable:* An event is a record of change that has occurred at some time in the past and cannot be changed. ++ +[NOTE] +==== +The {DECISION_ENGINE} does not enforce immutability on the Java objects that represent events. This behavior makes event data enrichment possible. Your application should be able to populate unpopulated event attributes, and these attributes are used by the {DECISION_ENGINE} to enrich the event with inferred data. However, you should not change event attributes that have already been populated. +==== + +* *Have strong temporal constraints:* Rules involving events usually require the correlation of multiple events that occur at different points in time relative to each other. +* *Have managed life cycles:* Because events are immutable and have temporal constraints, they are usually only relevant for a specified period of time. This means that the {DECISION_ENGINE} can automatically manage the life cycle of events. +* *Can use sliding windows:* You can define sliding windows of time or length with events. A sliding time window is a specified period of time during which events can be processed. A sliding length window is a specified number of events that can be processed. diff --git a/assemblies/modules/decision-engine/con-cep-memory-management.adoc b/assemblies/modules/decision-engine/con-cep-memory-management.adoc new file mode 100644 index 0000000..7864b51 --- /dev/null +++ b/assemblies/modules/decision-engine/con-cep-memory-management.adoc @@ -0,0 +1,40 @@ +[id='con-cep-memory-management_{context}'] += Memory management for events + +In stream mode, the {DECISION_ENGINE} uses automatic memory management to maintain events that are stored in KIE sessions. The {DECISION_ENGINE} can retract from a KIE session any events that no longer match any rule due to their temporal constraints and release any resources held by the retracted events. + +The {DECISION_ENGINE} uses either explicit or inferred expiration to retract outdated events: + +* *Explicit expiration:* The {DECISION_ENGINE} removes events that are explicitly set to expire in rules that declare the `@expires` tag: ++ +-- +.DRL rule snippet with explicit expiration +[source] +---- +declare StockPoint + @expires( 30m ) +end +---- + +This example rule sets any `StockPoint` events to expire after 30 minutes and to be removed from the KIE session if no other rules use the events. +-- + +* *Inferred expiration:* The {DECISION_ENGINE} can calculate the expiration offset for a given event implicitly by analyzing the temporal constraints in the rules: ++ +-- +.DRL rule with temporal constraints +[source] +---- +rule "Correlate orders" +when + $bo : BuyOrder($id : id) + $ae : AckOrder(id == $id, this after[0,10s] $bo) +then + // Perform an action. +end +---- + +For this example rule, the {DECISION_ENGINE} automatically calculates that whenever a `BuyOrder` event occurs, the {DECISION_ENGINE} needs to store the event for up to 10 seconds and wait for the matching `AckOrder` event. After 10 seconds, the {DECISION_ENGINE} infers the expiration and removes the event from the KIE session. An `AckOrder` event can only match an existing `BuyOrder` event, so the {DECISION_ENGINE} infers the expiration if no match occurs and removes the event immediately. + +The {DECISION_ENGINE} analyzes the entire KIE base to find the offset for every event type and to ensure that no other rules use the events that are pending removal. Whenever an implicit expiration clashes with an explicit expiration value, the {DECISION_ENGINE} uses the greater time frame of the two to store the event longer. +-- diff --git a/assemblies/modules/decision-engine/con-cep-modes.adoc b/assemblies/modules/decision-engine/con-cep-modes.adoc new file mode 100644 index 0000000..886e176 --- /dev/null +++ b/assemblies/modules/decision-engine/con-cep-modes.adoc @@ -0,0 +1,96 @@ +[id='con-cep-modes_{context}'] += Event processing modes in the {DECISION_ENGINE} + +The {DECISION_ENGINE} runs in either cloud mode or stream mode. In cloud mode, the {DECISION_ENGINE} processes facts as facts with no temporal constraints, independent of time, and in no particular order. In stream mode, the {DECISION_ENGINE} processes facts as events with strong temporal constraints, in real time or near real time. Stream mode uses synchronization to make event processing possible in {PRODUCT}. + +Cloud mode:: +Cloud mode is the default operating mode of the {DECISION_ENGINE}. In cloud mode, the {DECISION_ENGINE} treats events as an unordered cloud. Events still have time stamps, but the {DECISION_ENGINE} running in cloud mode cannot draw relevance from the time stamp because cloud mode ignores the present time. This mode uses the rule constraints to find the matching tuples to activate and execute rules. ++ +-- +Cloud mode does not impose any kind of additional requirements on facts. However, because the {DECISION_ENGINE} in this mode has no concept of time, it cannot use temporal features such as sliding windows or automatic life-cycle management. In cloud mode, events must be explicitly retracted when they are no longer needed. + +The following requirements are not imposed in cloud mode: + +* No clock synchronization because the {DECISION_ENGINE} has no notion of time +* No ordering of events because the {DECISION_ENGINE} processes events as an unordered cloud, against which the {DECISION_ENGINE} match rules + +You can specify cloud mode either by setting the system property in the relevant configuration files or by using the Java client API: + +.Set cloud mode using system property +[source] +---- +drools.eventProcessingMode=cloud +---- + +.Set cloud mode using Java client API +[source,java] +---- +import org.kie.api.conf.EventProcessingOption; +import org.kie.api.KieBaseConfiguration; +import org.kie.api.KieServices.Factory; + +KieBaseConfiguration config = KieServices.Factory.get().newKieBaseConfiguration(); + +config.setOption(EventProcessingOption.CLOUD); +---- + +You can also specify cloud mode using the `eventProcessingMode=""` KIE base attribute in the KIE module descriptor file (`kmodule.xml`) for a specific {PRODUCT} project: + +.Set cloud mode using project `kmodule.xml` file +[source,xml] +---- + + ... + + ... + + ... + +---- +-- + +Stream mode:: +Stream mode enables the {DECISION_ENGINE} to process events chronologically and in real time as they are inserted into the {DECISION_ENGINE}. In stream mode, the {DECISION_ENGINE} synchronizes streams of events (so that events in different streams can be processed in chronological order), implements sliding windows of time or length, and enables automatic life-cycle management. ++ +-- +The following requirements apply to stream mode: + +* Events in each stream must be ordered chronologically. +* A session clock must be present to synchronize event streams. + +NOTE: Your application does not need to enforce ordering events between streams, but using event streams that have not been synchronized may cause unexpected results. + +You can specify stream mode either by setting the system property in the relevant configuration files or by using the Java client API: + +.Set stream mode using system property +[source] +---- +drools.eventProcessingMode=stream +---- + +.Set stream mode using Java client API +[source,java] +---- +import org.kie.api.conf.EventProcessingOption; +import org.kie.api.KieBaseConfiguration; +import org.kie.api.KieServices.Factory; + +KieBaseConfiguration config = KieServices.Factory.get().newKieBaseConfiguration(); + +config.setOption(EventProcessingOption.STREAM); +---- + +You can also specify stream mode using the `eventProcessingMode=""` KIE base attribute in the KIE module descriptor file (`kmodule.xml`) for a specific {PRODUCT} project: + +.Set stream mode using project `kmodule.xml` file +[source,xml] +---- + + ... + + ... + + ... + +---- +-- diff --git a/assemblies/modules/decision-engine/con-cep-negative-patterns.adoc b/assemblies/modules/decision-engine/con-cep-negative-patterns.adoc new file mode 100644 index 0000000..604473c --- /dev/null +++ b/assemblies/modules/decision-engine/con-cep-negative-patterns.adoc @@ -0,0 +1,46 @@ +[id='con-cep-negative-patterns_{context}'] += Negative patterns in {DECISION_ENGINE} stream mode + +A negative pattern is a pattern for conditions that are not met. For example, the following DRL rule activates a fire alarm if a fire is detected and the sprinkler is not activated: + +.Fire alarm rule with a negative pattern +[source] +---- +rule "Sound the alarm" +when + $f : FireDetected() + not(SprinklerActivated()) +then + // Sound the alarm. +end +---- + +In cloud mode, the {DECISION_ENGINE} assumes all facts (regular facts and events) are known in advance and evaluates negative patterns immediately. In stream mode, the {DECISION_ENGINE} can support temporal constraints on facts to wait for a set time before activating a rule. + +The same example rule in stream mode activates the fire alarm as usual, but applies a 10-second delay. + +.Fire alarm rule with a negative pattern and time delay (stream mode only) +[source] +---- +rule "Sound the alarm" +when + $f : FireDetected() + not(SprinklerActivated(this after[0s,10s] $f)) +then + // Sound the alarm. +end +---- + +The following modified fire alarm rule expects one `Heartbeat` event to occur every 10 seconds. If the expected event does not occur, the rule is executed. This rule uses the same type of object in both the first pattern and in the negative pattern. The negative pattern has the temporal constraint to wait 0 to 10 seconds before executing and excludes the `Heartbeat` event bound to `$h` so that the rule can be executed. The bound event `$h` must be explicitly excluded in order for the rule to be executed because the temporal constraint `[0s, ...]` does not inherently exclude that event from being matched again. + +.Fire alarm rule excluding a bound event in a negative pattern (stream mode only) +[source] +---- +rule "Sound the alarm" +when + $h: Heartbeat() from entry-point "MonitoringStream" + not(Heartbeat(this != $h, this after[0s,10s] $h) from entry-point "MonitoringStream") +then + // Sound the alarm. +end +---- diff --git a/assemblies/modules/decision-engine/con-cep-sliding-windows.adoc b/assemblies/modules/decision-engine/con-cep-sliding-windows.adoc new file mode 100644 index 0000000..70e88ae --- /dev/null +++ b/assemblies/modules/decision-engine/con-cep-sliding-windows.adoc @@ -0,0 +1,18 @@ +[id='con-cep-sliding-windows_{context}'] += Sliding windows of time or length + +In stream mode, the {DECISION_ENGINE} can process events from a specified sliding window of time or length. A sliding time window is a specified period of time during which events can be processed. A sliding length window is a specified number of events that can be processed. When you declare a sliding window in a DRL rule or Java application, the {DECISION_ENGINE}, at compile time, identifies and creates the proper internal structures to use data from only that sliding window to evaluate that rule. + +For example, the following DRL rule snippets instruct the {DECISION_ENGINE} to process only the stock points from the last 2 minutes (sliding time window) or to process only the last 10 stock points (sliding length window): + +.Process stock points from the last 2 minutes (sliding time window) +[source] +---- +StockPoint() over window:time(2m) +---- + +.Process the last 10 stock points (sliding length window) +[source] +---- +StockPoint() over window:length(10) +---- diff --git a/assemblies/modules/decision-engine/con-cep.adoc b/assemblies/modules/decision-engine/con-cep.adoc new file mode 100644 index 0000000..d8ed0c8 --- /dev/null +++ b/assemblies/modules/decision-engine/con-cep.adoc @@ -0,0 +1,39 @@ +[id='con-cep_{context}'] += Complex event processing (CEP) + +In {PRODUCT}, an event is a record of a significant change of state in the application domain at a point in time. Depending on how the domain is modeled, the change of state may be represented by a single event, multiple atomic events, or hierarchies of correlated events. From a complex event processing (CEP) perspective, an event is a type of fact or object that occurs at a specific point in time, and a business rule is a definition of how to react to the data from that fact or object. For example, in a stock broker application, a change in security prices, a change in ownership from seller to buyer, or a change in an account holder's balance are all considered to be events because a change has occurred in the state of the application domain at a given time. + +The {DECISION_ENGINE} in {PRODUCT} uses complex event processing (CEP) to detect and process multiple events within a collection of events, to uncover relationships that exist between events, and to infer new data from the events and their relationships. + +CEP use cases share several requirements and goals with business rule use cases. + +From a business perspective, business rule definitions are often defined based on the occurrence of scenarios triggered by events. In the following examples, events form the basis of business rules: + +* In an algorithmic trading application, a rule performs an action if the security price increases by X percent above the day opening price. The price increases are denoted by events on a stock trading application. +* In a monitoring application, a rule performs an action if the temperature in the server room increases X degrees in Y minutes. The sensor readings are denoted by events. + +From a technical perspective, business rule evaluation and CEP have the following key similarities: + +* Both business rule evaluation and CEP require seamless integration with the enterprise infrastructure and applications. This is particularly important with life-cycle management, auditing, and security. +* Both business rule evaluation and CEP have functional requirements such as pattern matching, and non-functional requirements such as response time limits and query-rule explanations. + +CEP scenarios have the following key characteristics: + +* Scenarios usually process large numbers of events, but only a small percentage of the events are relevant. +* Events are usually immutable and represent a record of change in state. +* Rules and queries run against events and must react to detected event patterns. +* Related events usually have a strong temporal relationship. +* Individual events are not prioritized. The CEP system prioritizes patterns of related events and the relationships between them. +* Events usually need to be composed and aggregated. + +Given these common CEP scenario characteristics, the CEP system in {PRODUCT} supports the following features and functions to optimize event processing: + +* Event processing with proper semantics +* Event detection, correlation, aggregation, and composition +* Event stream processing +* Temporal constraints to model the temporal relationships between events +* Sliding windows of significant events +* Session-scoped unified clock +* Required volumes of events for CEP use cases +* Reactive rules +* Adapters for event input into the {DECISION_ENGINE} (pipeline) diff --git a/assemblies/modules/decision-engine/con-decision-engine.adoc b/assemblies/modules/decision-engine/con-decision-engine.adoc new file mode 100644 index 0000000..ff24b3c --- /dev/null +++ b/assemblies/modules/decision-engine/con-decision-engine.adoc @@ -0,0 +1,21 @@ +[id='con-decision-engine_{context}'] += {DECISION_ENGINE_CAP} in {PRODUCT} + +The {DECISION_ENGINE} is the rules engine in {PRODUCT}. The {DECISION_ENGINE} stores, processes, and evaluates data to execute the business rules or decision models that you define. The basic function of the {DECISION_ENGINE} is to match incoming data, or _facts_, to the conditions of rules and determine whether and how to execute the rules. + +The {DECISION_ENGINE} operates using the following basic components: + +* *Rules:* Business rules or DMN decisions that you define. All rules must contain at a minimum the conditions that trigger the rule and the actions that the rule dictates. +* *Facts:* Data that enters or changes in the {DECISION_ENGINE} that the {DECISION_ENGINE} matches to rule conditions to execute applicable rules. +* *Production memory:* Location where rules are stored in the {DECISION_ENGINE}. +* *Working memory:* Location where facts are stored in the {DECISION_ENGINE}. +* *Agenda:* Location where activated rules are registered and sorted (if applicable) in preparation for execution. + +When a business user or an automated system adds or updates rule-related information in {PRODUCT}, that information is inserted into the working memory of the {DECISION_ENGINE} in the form of one or more facts. The {DECISION_ENGINE} matches those facts to the conditions of the rules that are stored in the production memory to determine eligible rule executions. (This process of matching facts to rules is often referred to as _pattern matching_.) When rule conditions are met, the {DECISION_ENGINE} activates and registers rules in the agenda, where the {DECISION_ENGINE} then sorts prioritized or conflicting rules in preparation for execution. + +The following diagram illustrates these basic components of the {DECISION_ENGINE}: + +.Overview of basic {DECISION_ENGINE} components +image::kogito/decision-engine/rule-engine-inkscape_enterprise.png[align="center"] + +These core concepts can help you to better understand other more advanced components, processes, and subprocesses of the {DECISION_ENGINE}, and as a result, to design more effective business assets in {PRODUCT}. diff --git a/assemblies/modules/decision-engine/con-engine-event-listeners.adoc b/assemblies/modules/decision-engine/con-engine-event-listeners.adoc new file mode 100644 index 0000000..324c536 --- /dev/null +++ b/assemblies/modules/decision-engine/con-engine-event-listeners.adoc @@ -0,0 +1,75 @@ +[id='con-engine-event-listeners_{context}'] += {DECISION_ENGINE_CAP} event listeners and debug logging + +[WARNING] +==== +The APIs for {DECISION_ENGINE} event listeners in {PRODUCT} are subject to change. +==== + +In {PRODUCT}, you can add or remove listeners for {DECISION_ENGINE} events, such as fact insertions and rule executions. With {DECISION_ENGINE} event listeners, you can be notified of {DECISION_ENGINE} activity and separate your logging and auditing work from the core of your application. + +The {DECISION_ENGINE} supports the following default event listeners for the agenda and working memory: + +* `AgendaEventListener` +* `WorkingMemoryEventListener` + +ifdef::KOGITO-COMM[] +.WorkingMemoryEventManager +image::UserGuide/WorkingMemoryEventManager.png[align="center"] +endif::[] + +For each event listener, the {DECISION_ENGINE} also supports the following specific events that you can specify to be monitored: + +* `MatchCreatedEvent` +* `MatchCancelledEvent` +* `BeforeMatchFiredEvent` +* `AfterMatchFiredEvent` +* `AgendaGroupPushedEvent` +* `AgendaGroupPoppedEvent` +* `ObjectInsertEvent` +* `ObjectDeletedEvent` +* `ObjectUpdatedEvent` +* `ProcessCompletedEvent` +* `ProcessNodeLeftEvent` +* `ProcessNodeTriggeredEvent` +* `ProcessStartEvent` + +For example, the following code uses a `DefaultAgendaEventListener` listener and specifies the `AfterMatchFiredEvent` event to be monitored. The code prints pattern matches after the rules are executed (fired): + +.Example code to monitor and print `AfterMatchFiredEvent` events in the agenda +[source,java] +---- +public class MyListener extends DefaultAgendaEventListener { + public void afterMatchFired(AfterMatchFiredEvent event) { + super.afterMatchFired( event ); + System.out.println( event ); + } +} + +@ApplicationScoped +public class RuleEventListenerConfig extends DefaultRuleEventListenerConfig { + public RuleEventListenerConfig() { + super(new MyListener()); + } +} +---- + +The {DECISION_ENGINE} also supports the following agenda and working memory event listeners for debug logging: + +* `DebugAgendaEventListener` +* `DebugRuleRuntimeEventListener` + +These event listeners implement the same supported event-listener methods and include a debug print statement by default. You can add a specific supported event to be monitored and documented, or monitor all agenda or working memory activity. + +For example, the following code uses the `DebugRuleRuntimeEventListener` event listener to monitor and print all working memory events: + +.Example code to monitor and print all working memory events +[source,java] +---- +@ApplicationScoped +public class RuleEventListenerConfig extends DefaultRuleEventListenerConfig { + public RuleEventListenerConfig() { + super(new DebugRuleRuntimeEventListener()); + } +} +---- diff --git a/assemblies/modules/decision-engine/con-engine-queries.adoc b/assemblies/modules/decision-engine/con-engine-queries.adoc new file mode 100644 index 0000000..1013efa --- /dev/null +++ b/assemblies/modules/decision-engine/con-engine-queries.adoc @@ -0,0 +1,87 @@ +[id='con-engine-queries_{context}'] += {DECISION_ENGINE_CAP} queries and live queries + +*<@Edoardo, so verdict on this?>* + +You can use queries with the {DECISION_ENGINE} to retrieve fact sets based on fact patterns as they are used in rules. The patterns might also use optional parameters. + +To use queries with the {DECISION_ENGINE}, you add the query definitions in DRL files and then obtain the matching results in your application code. While a query iterates over a result collection, you can use any identifier that is bound to the query to access the corresponding fact or fact field by calling the `get()` method with the binding variable name as the argument. If the binding refers to a fact object, you can retrieve the fact handle by calling `getFactHandle()` with the variable name as the parameter. + +ifdef::KOGITO-COMM[] +.QueryResults +image::UserGuide/QueryResults.png[align="center"] + +.QueryResultsRow +image::UserGuide/QueryResultsRow.png[align="center"] +endif::[] + +.Example query definition in a DRL file +[source] +---- +query "people under the age of 21" + $person : Person( age < 21 ) +end +---- + +.Example application code to obtain and iterate over query results +[source,java] +---- +QueryResults results = ksession.getQueryResults( "people under the age of 21" ); +System.out.println( "we have " + results.size() + " people under the age of 21" ); + +System.out.println( "These people are under the age of 21:" ); + +for ( QueryResultsRow row : results ) { + Person person = ( Person ) row.get( "person" ); + System.out.println( person.getName() + "\n" ); +} +---- + +Invoking queries and processing the results by iterating over the returned set can be difficult when you are monitoring changes over time. To alleviate this difficulty with ongoing queries, {PRODUCT} provides _live queries_, which use an attached listener for change events instead of returning an iterable result set. Live queries remain open by creating a view and publishing change events for the contents of this view. + +To activate a live query, start your query with parameters and monitor changes in the resulting view. You can use the `dispose()` method to terminate the query and discontinue this reactive scenario. + + +.Example query definition in a DRL file +[source] +---- +query colors(String $color1, String $color2) + TShirt(mainColor = $color1, secondColor = $color2, $price: manufactureCost) +end +---- + +.Example application code with an event listener and a live query +[source,java] +---- +final List updated = new ArrayList(); +final List removed = new ArrayList(); +final List added = new ArrayList(); + +ViewChangedEventListener listener = new ViewChangedEventListener() { + public void rowUpdated(Row row) { + updated.add( row.get( "$price" ) ); + } + + public void rowRemoved(Row row) { + removed.add( row.get( "$price" ) ); + } + + public void rowAdded(Row row) { + added.add( row.get( "$price" ) ); + } +}; + +// Open the live query: +LiveQuery query = ksession.openLiveQuery( "colors", + new Object[] { "red", "blue" }, + listener ); +... +... + +// Terminate the live query: +query.dispose() +---- + +ifdef::KOGITO-COMM[] +For more live query examples, see http://blog.athico.com/2010/07/glazed-lists-examples-for-drools-live.html[Glazed Lists examples for Drools Live Queries]. +endif::[] diff --git a/assemblies/modules/decision-engine/con-execution-control.adoc b/assemblies/modules/decision-engine/con-execution-control.adoc new file mode 100644 index 0000000..03926c9 --- /dev/null +++ b/assemblies/modules/decision-engine/con-execution-control.adoc @@ -0,0 +1,144 @@ +[id='con-execution-control_{context}'] += Execution control in the {DECISION_ENGINE} + +When new rule data enters the working memory of the {DECISION_ENGINE}, rules may become fully matched and eligible for execution. A single working memory action can result in multiple eligible rule executions. When a rule is fully matched, the {DECISION_ENGINE} creates an activation instance, referencing the rule and the matched facts, and adds the activation onto the {DECISION_ENGINE} agenda. The agenda controls the execution order of these rule activations using a conflict resolution strategy. + +When rules are executed, the {DECISION_ENGINE} cycles repeatedly through two phases: + +* *Agenda evaluation.* In this phase, the {DECISION_ENGINE} selects all rules that can be executed. If no executable rules exist, the execution cycle ends. If an executable rule is found, the {DECISION_ENGINE} registers the activation in the agenda and then moves on to the working memory actions phase to perform rule consequence actions. +* *Working memory actions.* In this phase, the {DECISION_ENGINE} performs the rule consequence actions (the `then` portion of each rule) for all activated rules previously registered in the agenda. After all the consequence actions are complete or the rules are executed again, the {DECISION_ENGINE} returns to the agenda evaluation phase to reassess rules. + +.Two-phase execution process in the {DECISION_ENGINE} +ifdef::KOGITO-COMM[] +image::kogito/decision-engine/Two_Phase.png[align="center"] +endif::[] +ifdef::KOGITO-ENT[] +image::kogito/decision-engine/Two_Phase_enterprise.png[align="center"] +endif::[] + +When multiple rules exist on the agenda, the execution of one rule may cause another rule to be removed from the agenda. To avoid this, you can define how and when rules are executed in the {DECISION_ENGINE}. Some common methods for defining rule execution order are by using rule salience, agenda groups, activation groups, or rule units for DRL rule sets. + +== Salience for rules + +Each rule has an integer `salience` attribute that determines the order of execution. Rules with a higher salience value are given higher priority when ordered in the activation queue. The default salience value for rules is zero, but the salience can be negative or positive. + +For example, the following sample DRL rules are listed in the {DECISION_ENGINE} stack in the order shown: + +[source] +---- +rule "RuleA" +salience 95 + when + $fact : /myFact[ field1 == true ] + then + System.out.println("Rule2 : " + $fact); + update($fact); +end + +rule "RuleB" +salience 100 + when + $fact : /myFact[ field1 == false ] + then + System.out.println("Rule1 : " + $fact); + $fact.setField1(true); + update($fact); +end +---- + +The `RuleB` rule is listed second, but it has a higher salience value than the `RuleA` rule and is therefore executed first. + +//// +//Excluded per recommendation by Edoardo, since replaced by rule units. (Stetson, 9 Mar 2020) +== Agenda groups for rules + +An agenda group is a set of rules bound together by the same `agenda-group` rule attribute. Agenda groups partition rules on the {DECISION_ENGINE} agenda. At any one time, only one group has a _focus_ that gives that group of rules priority for execution before rules in other agenda groups. You determine the focus with a `setFocus()` call for the agenda group. You can also define rules with an `auto-focus` attribute so that the next time the rule is activated, the focus is automatically given to the entire agenda group to which the rule is assigned. + +Each time the `setFocus()` call is made in a Java application, the {DECISION_ENGINE} adds the specified agenda group to the top of the rule stack. The default agenda group `"MAIN"` contains all rules that do not belong to a specified agenda group and is executed first in the stack unless another group has the focus. + +For example, the following sample DRL rules belong to specified agenda groups and are listed in the {DECISION_ENGINE} stack in the order shown: + +.Sample DRL rules for banking application +[source] +---- +rule "Increase balance for credits" + agenda-group "calculation" +when + ap : AccountPeriod() + acc : Account( $accountNo : accountNo ) + CashFlow( type == CREDIT, + accountNo == $accountNo, + date >= ap.start && <= ap.end, + $amount : amount ) +then + acc.balance += $amount; +end +---- + +[source] +---- +rule "Print balance for AccountPeriod" + agenda-group "report" +when + ap : AccountPeriod() + acc : Account() +then + System.out.println( acc.accountNo + + " : " + acc.balance ); +end +---- + +For this example, the rules in the `"report"` agenda group must always be executed first and the rules in the `"calculation"` agenda group must always be executed second. Any remaining rules in other agenda groups can then be executed. Therefore, the `"report"` and `"calculation"` groups must receive the focus to be executed in that order, before other rules can be executed: + +.Set the focus for the order of agenda group execution +[source,java] +---- +Agenda agenda = ksession.getAgenda(); +agenda.getAgendaGroup( "report" ).setFocus(); +agenda.getAgendaGroup( "calculation" ).setFocus(); +ksession.fireAllRules(); +---- + +You can also use the `clear()` method to cancel all the activations generated by the rules belonging to a given agenda group before each has had a chance to be executed: + +.Cancel all other rule activations +[source,java] +---- +ksession.getAgenda().getAgendaGroup( "Group A" ).clear(); +---- +//// + +== Activation groups for rules + +An activation group is a set of rules bound together by the same `activation-group` rule attribute. In this group, only one rule can be executed. After conditions are met for a rule in that group to be executed, all other pending rule executions from that activation group are removed from the agenda. + +For example, the following sample DRL rules belong to the specified activation group and are listed in the {DECISION_ENGINE} stack in the order shown: + +.Sample DRL rules for banking +[source] +---- +rule "Print balance for AccountPeriod1" +activation-group "report" + when + ap : AccountPeriod1() + acc : Account() + then + System.out.println( acc.accountNo + + " : " + acc.balance ); +end +---- + +[source] +---- +rule "Print balance for AccountPeriod2" +activation-group "report" + when + ap : AccountPeriod2() + acc : Account() + then + System.out.println( acc.accountNo + + " : " + acc.balance ); +end +---- + +For this example, if the first rule in the `"report"` activation group is executed, the second rule in the group and all other executable rules on the agenda are removed from the agenda. diff --git a/assemblies/modules/decision-engine/con-fact-equality-modes.adoc b/assemblies/modules/decision-engine/con-fact-equality-modes.adoc new file mode 100644 index 0000000..96d6f89 --- /dev/null +++ b/assemblies/modules/decision-engine/con-fact-equality-modes.adoc @@ -0,0 +1,66 @@ +[id='con-fact-equality-modes_{context}'] += Fact equality modes in the {DECISION_ENGINE} + +*<@Edoardo, see this section.>* + +The {DECISION_ENGINE} supports the following fact equality modes that determine how the {DECISION_ENGINE} stores and compares inserted facts: + +* `identity`: (Default) The {DECISION_ENGINE} uses an `IdentityHashMap` to store all inserted facts. For every new fact insertion, the {DECISION_ENGINE} returns a new `FactHandle` object. If a fact is inserted again, the {DECISION_ENGINE} returns the original `FactHandle` object, ignoring repeated insertions for the same fact. In this mode, two facts are the same for the {DECISION_ENGINE} only if they are the very same object with the same identity. +* `equality`: The {DECISION_ENGINE} uses a `HashMap` to store all inserted facts. The {DECISION_ENGINE} returns a new `FactHandle` object only if the inserted fact is not equal to an existing fact, according to the `equals()` method of the inserted fact. In this mode, two facts are the same for the {DECISION_ENGINE} if they are composed the same way, regardless of identity. Use this mode when you want objects to be assessed based on feature equality instead of explicit identity. + +As an illustration of fact equality modes, consider the following example facts: + +.Example facts +[source] +---- +Person p1 = new Person("John", 45); +Person p2 = new Person("John", 45); +---- + +In `identity` mode, facts `p1` and `p2` are different instances of a `Person` class and are treated as separate objects because they have separate identities. In `equality` mode, facts `p1` and `p2` are treated as the same object because they are composed the same way. This difference in behavior affects how you can interact with fact handles. + +For example, assume that you insert facts `p1` and `p2` into the {DECISION_ENGINE} and later you want to retrieve the fact handle for `p1`. In `identity` mode, you must specify `p1` to return the fact handle for that exact object, whereas in `equality` mode, you can specify `p1`, `p2`, or `new Person("John", 45)` to return the fact handle. + +.Example code to insert a fact and return the fact handle in `identity` mode +[source] +---- +ksession.insert(p1); + +ksession.getFactHandle(p1); +---- + +.Example code to insert a fact and return the fact handle in `equality` mode +[source] +---- +ksession.insert(p1); + +ksession.getFactHandle(p1); + +// Alternate option: +ksession.getFactHandle(new Person("John", 45)); +---- + +To set the fact equality mode, use one of the following options: + +* Set the system property `drools.equalityBehavior` to `identity` (default) or `equality`. +* Set the equality mode while creating the KIE base programmatically: ++ +[source,java] +---- +KieServices ks = KieServices.get(); +KieBaseConfiguration kieBaseConf = ks.newKieBaseConfiguration(); +kieBaseConf.setOption(EqualityBehaviorOption.EQUALITY); +KieBase kieBase = kieContainer.newKieBase(kieBaseConf); +---- +* Set the equality mode in the KIE module descriptor file (`kmodule.xml`) for a specific {PRODUCT} project: ++ +[source,xml] +---- + + ... + + ... + + ... + +---- diff --git a/assemblies/modules/decision-engine/con-fact-propagation-modes.adoc b/assemblies/modules/decision-engine/con-fact-propagation-modes.adoc new file mode 100644 index 0000000..2dc67a1 --- /dev/null +++ b/assemblies/modules/decision-engine/con-fact-propagation-modes.adoc @@ -0,0 +1,63 @@ +[id='con-fact-propagation-modes_{context}'] += Fact propagation modes in the {DECISION_ENGINE} + +*<@Edoardo, also this section. This is coupled with rule execution modes and also came up a lot in 7.x and is/was a hot topic.>* + +The {DECISION_ENGINE} supports the following fact propagation modes that determine how the {DECISION_ENGINE} progresses inserted facts through the engine network in preparation for rule execution: + +* *Lazy*: (Default) Facts are propagated in batch collections at rule execution, not in real time as the facts are individually inserted by a user or application. As a result, the order in which the facts are ultimately propagated through the {DECISION_ENGINE} may be different from the order in which the facts were individually inserted. +* *Immediate*: Facts are propagated immediately in the order that they are inserted by a user or application. +* *Eager*: Facts are propagated lazily (in batch collections), but before rule execution. The {DECISION_ENGINE} uses this propagation behavior for rules that have the `no-loop` or `lock-on-active` attribute. + +By default, the Phreak rule algorithm in the {DECISION_ENGINE} uses lazy fact propagation for improved rule evaluation overall. However, in few cases, this lazy propagation behavior can alter the expected result of certain rule executions that may require immediate or eager propagation. + +For example, the following rule uses a specified query with a `?` prefix to invoke the query in pull-only or passive fashion: + +.Example rule with a passive query +[source] +---- +query Q (Integer i) + String( this == i.toString() ) +end + +rule "Rule" + when + $i : Integer() + ?Q( $i; ) + then + System.out.println( $i ); +end +---- + +For this example, the rule should be executed only when a `String` that satisfies the query is inserted before the `Integer`, such as in the following example commands: + +.Example commands that should trigger the rule execution +[source,java] +---- +KieSession ksession = ... +ksession.insert("1"); +ksession.insert(1); +ksession.fireAllRules(); +---- + +However, due to the default lazy propagation behavior in Phreak, the {DECISION_ENGINE} does not detect the insertion sequence of the two facts in this case, so this rule is executed regardless of `String` and `Integer` insertion order. For this example, immediate propagation is required for the expected rule evaluation. + +To alter the {DECISION_ENGINE} propagation mode to achieve the expected rule evaluation in this case, you can add the `@Propagation(__TYPE__)` tag to your rule and set `__TYPE__` to `LAZY`, `IMMEDIATE`, or `EAGER`. + +In the same example rule, the immediate propagation annotation enables the rule to be evaluated only when a `String` that satisfies the query is inserted before the `Integer`, as expected: + +.Example rule with a passive query and specified propagation mode +[source] +---- +query Q (Integer i) + String( this == i.toString() ) +end + +rule "Rule" @Propagation(IMMEDIATE) + when + $i : Integer() + ?Q( $i; ) + then + System.out.println( $i ); +end +---- diff --git a/assemblies/modules/decision-engine/con-forward-and-backward-chaining.adoc b/assemblies/modules/decision-engine/con-forward-and-backward-chaining.adoc new file mode 100644 index 0000000..5882a3e --- /dev/null +++ b/assemblies/modules/decision-engine/con-forward-and-backward-chaining.adoc @@ -0,0 +1,16 @@ +[id='con-forward-and-backward-chaining_{context}'] += Rule evaluation with forward and backward chaining + +The {DECISION_ENGINE} in {PRODUCT} is a hybrid reasoning system that uses both forward chaining and backward chaining to evaluate rules. A forward-chaining rule system is a data-driven system that starts with a fact in the working memory of the {DECISION_ENGINE} and reacts to changes to that fact. When objects are inserted into working memory, any rule conditions that become true as a result of the change are scheduled for execution by the agenda. + +In contrast, a backward-chaining rule system is a goal-driven system that starts with a conclusion that the {DECISION_ENGINE} attempts to satisfy, often using recursion. If the system cannot reach the conclusion or goal, it searches for subgoals, which are conclusions that complete part of the current goal. The system continues this process until either the initial conclusion is satisfied or all subgoals are satisfied. + +The following diagram illustrates how the {DECISION_ENGINE} evaluates rules using forward chaining overall with a backward-chaining segment in the logic flow: + +.Rule evaluation logic using forward and backward chaining +ifdef::KOGITO-COMM[] +image::kogito/decision-engine/RuleEvaluation.png[align="center"] +endif::[] +ifdef::KOGITO-ENT[] +image::kogito/decision-engine/RuleEvaluation_Enterprise.png[align="center"] +endif::[] diff --git a/assemblies/modules/decision-engine/con-inference-and-truth-maintenance.adoc b/assemblies/modules/decision-engine/con-inference-and-truth-maintenance.adoc new file mode 100644 index 0000000..1b8bd1a --- /dev/null +++ b/assemblies/modules/decision-engine/con-inference-and-truth-maintenance.adoc @@ -0,0 +1,282 @@ +[id='con-inference-and-truth-maintenance_{context}'] += Inference and truth maintenance in the {DECISION_ENGINE} + +The basic function of the {DECISION_ENGINE} is to match data to business rules and determine whether and how to execute rules. To ensure that relevant data is applied to the appropriate rules, the {DECISION_ENGINE} makes _inferences_ based on existing knowledge and performs the actions based on the inferred information. + +For example, the following DRL rule determines the age requirements for adults, such as in a bus pass policy: + +.Rule to define age requirement +[source] +---- +rule "Infer Adult" +when + $p : Person(age >= 18) +then + insert(new IsAdult($p)) +end +---- + +Based on this rule, the {DECISION_ENGINE} infers whether a person is an adult or a child and performs the specified action (the `then` consequence). Every person who is 18 years old or older has an instance of `IsAdult` inserted for them in the working memory. This inferred relation of age and bus pass can then be invoked in any rule, such as in the following rule segment: + +[source] +---- +$p : Person() +IsAdult(person == $p) +---- + +In many cases, new data in a rule system is the result of other rule executions, and this new data can affect the execution of other rules. If the {DECISION_ENGINE} asserts data as a result of executing a rule, the {DECISION_ENGINE} uses truth maintenance to justify the assertion and enforce truthfulness when applying inferred information to other rules. Truth maintenance also helps to identify inconsistencies and to handle contradictions. For example, if two rules are executed and result in a contradictory action, the {DECISION_ENGINE} chooses the action based on assumptions from previously calculated conclusions. + +The {DECISION_ENGINE} inserts facts using either stated or logical insertions: + +* *Stated insertions:* Defined with `insert()`. After stated insertions, facts are generally retracted explicitly. (The term _insertion_, when used generically, refers to _stated insertion_.) +* *Logical insertions:* Defined with `insertLogical()`. After logical insertions, the facts that were inserted are automatically retracted when the conditions in the rules that inserted the facts are no longer true. The facts are retracted when no condition supports the logical insertion. A fact that is logically inserted is considered to be _justified_ by the {DECISION_ENGINE}. + +For example, the following sample DRL rules use stated fact insertion to determine the age requirements for issuing a child bus pass or an adult bus pass: + +.Rules to issue bus pass, stated insertion +[source] +---- +rule "Issue Child Bus Pass" +when + $p : Person(age < 18) +then + insert(new ChildBusPass($p)); +end + +rule "Issue Adult Bus Pass" +when + $p : Person(age >= 18) +then + insert(new AdultBusPass($p)); +end +---- + +These rules are not easily maintained in the {DECISION_ENGINE} as bus riders increase in age and move from child to adult bus pass. As an alternative, these rules can be separated into rules for bus rider age and rules for bus pass type using logical fact insertion. The logical insertion of the fact makes the fact dependent on the truth of the `when` clause. + +The following DRL rules use logical insertion to determine the age requirements for children and adults: + +.Children and adult age requirements, logical insertion +[source] +---- +rule "Infer Child" +when + $p : Person(age < 18) +then + insertLogical(new IsChild($p)) +end + +rule "Infer Adult" +when + $p : Person(age >= 18) +then + insertLogical(new IsAdult($p)) +end +---- + +IMPORTANT: For logical insertions, your fact objects must override the `equals` and `hashCode` methods from the `java.lang.Object` object according to the Java standard. Two objects are equal if their `equals` methods return `true` for each other and if their `hashCode` methods return the same values. For more information, see the Java API documentation for your Java version. + +When the condition in the rule is false, the fact is automatically retracted. This behavior is helpful in this example because the two rules are mutually exclusive. In this example, if the person is younger than 18 years old, the rule logically inserts an `IsChild` fact. After the person is 18 years old or older, the `IsChild` fact is automatically retracted and the `IsAdult` fact is inserted. + +The following DRL rules then determine whether to issue a child bus pass or an adult bus pass and logically insert the `ChildBusPass` and `AdultBusPass` facts. This rule configuration is possible because the truth maintenance system in the {DECISION_ENGINE} supports chaining of logical insertions for a cascading set of retracts. + +.Rules to issue bus pass, logical insertion +[source] +---- +rule "Issue Child Bus Pass" +when + $p : Person() + IsChild(person == $p) +then + insertLogical(new ChildBusPass($p)); +end + +rule "Issue Adult Bus Pass" +when + $p : Person() + IsAdult(person =$p) +then + insertLogical(new AdultBusPass($p)); +end +---- + +When a person turns 18 years old, the `IsChild` fact and the person's `ChildBusPass` fact is retracted. To these set of conditions, you can relate another rule that states that a person must return the child pass after turning 18 years old. When the {DECISION_ENGINE} automatically retracts the `ChildBusPass` object, the following rule is executed to send a request to the person: + +.Rule to notify bus pass holder of new pass +[source] +---- +rule "Return ChildBusPass Request" +when + $p : Person() + not(ChildBusPass(person == $p)) +then + requestChildBusPass($p); +end +---- + +The following flowcharts illustrate the life cycle of stated and logical insertions: + +.Stated insertion +ifdef::KOGITO-COMM[] +image::kogito/decision-engine/Stated_Assertion.png[] +endif::[] +ifdef::KOGITO-ENT[] +image::kogito/decision-engine/Stated_Assertion_enterprise.png[] +endif::[] + +.Logical insertion +ifdef::KOGITO-COMM[] +image::kogito/decision-engine/Logical_Assertion.png[] +endif::[] +ifdef::KOGITO-ENT[] +image::kogito/decision-engine/Logical_Assertion_enterprise.png[] +endif::[] + +When the {DECISION_ENGINE} logically inserts an object during a rule execution, the {DECISION_ENGINE} _justifies_ the object by executing the rule. For each logical insertion, only one equal object can exist, and each subsequent equal logical insertion increases the justification counter for that logical insertion. A justification is removed when the conditions of the rule become untrue. When no more justifications exist, the logical object is automatically retracted. + +ifdef::KOGITO-COMM[] +== Government ID example + +So now we know what inference is, and have a basic example, how does this facilitate good rule design and maintenance? + +Consider a government ID department that is responsible for issuing ID cards when children become adults. +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: + + + +[cols="4*^"] +|=== + +|{set:cellbgcolor:#bfbfbf} +3+|[white]#RuleTable ID Card{set:cellbgcolor:#000000}# + +|{set:cellbgcolor:#bfbfbf} +|CONDITION{set:cellbgcolor:#ffcc99} +|CONDITION +|ACTION + +|{set:cellbgcolor:#bfbfbf} +2+|p : Person{set:cellbgcolor:#ffcc99} +| + +|{set:cellbgcolor:#bfbfbf} +|location{set:cellbgcolor:#ffcc99} +|age >= $1 +|issueIdCard($1) + +|{set:cellbgcolor:#ccffcc} +|Select Person{set:cellbgcolor:#ccffff} +|Select Adults +|Issue ID Card{set:cellbgcolor:#ffff99} + +|Issue ID Card to Adults{set:cellbgcolor:#ffffff} +|London +|18 +|p + +|=== + + +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 we 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: + + +[cols="3*^"] +|=== + +|{set:cellbgcolor:#bfbfbf} +2+|[white]#RuleTable Age Policy{set:cellbgcolor:#000000}# + +|{set:cellbgcolor:#bfbfbf} +|CONDITION{set:cellbgcolor:#ffcc94} +|ACTION + +|{set:cellbgcolor:#bfbfbf} +|p : Person{set:cellbgcolor:#ffcc94} + +| +|{set:cellbgcolor:#bfbfbf} +|age >= $1{set:cellbgcolor:#ffcc94} +|insert($1) + +|{set:cellbgcolor:#b9ffca} +|Adult Age Policy{set:cellbgcolor:#ccffff} +|Add Adult Relation{set:cellbgcolor:#f7ff92} +|Infer Adult{set:cellbgcolor:#ffffff} + +|18 +|new IsAdult( p ) + +|=== + + + +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: + + +[cols="4*^"] +|=== + +|{set:cellbgcolor:#c0c0c0} +3+|[white]#RuleTable ID Card{set:cellbgcolor:#000000}# + +|{set:cellbgcolor:#c0c0c0} +|CONDITION{set:cellbgcolor:#ffcc99} +|CONDITION +|ACTION + +|{set:cellbgcolor:#c0c0c0} +|p : Person{set:cellbgcolor:#ffcc99} +|isAdult +| + +|{set:cellbgcolor:#c0c0c0} +|location{set:cellbgcolor:#ffcc99} +|person == $1 +|issueIdCard($1) + +|{set:cellbgcolor:#ccffcc} +|Select Person{set:cellbgcolor:#ccffff} +|Select Adults +|Issue ID Card{set:cellbgcolor:#ffff99} + +|Issue ID Card to Adults{set:cellbgcolor:#ffffff} +|London +|p +|p +| + +|=== + + +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: + +* *Bad* +** Monolithic +** Leaky +* *Good* +** De-couple knowledge responsibilities +** Encapsulate knowledge +** Provide semantic abstractions for those encapsulations +endif::[] diff --git a/assemblies/modules/decision-engine/con-kie-sessions-pools.adoc b/assemblies/modules/decision-engine/con-kie-sessions-pools.adoc new file mode 100644 index 0000000..cc33cdc --- /dev/null +++ b/assemblies/modules/decision-engine/con-kie-sessions-pools.adoc @@ -0,0 +1,24 @@ +[id='con-kie-sessions-pools_{context}'] += KIE session pools + +In use cases with large amounts of KIE runtime data and high system activity, KIE sessions might be created and disposed very frequently. A high turnover of KIE sessions is not always time consuming, but when the turnover is repeated millions of times, the process can become a bottleneck and require substantial clean-up effort. + +For these high-volume cases, you can use KIE session pools instead of many individual KIE sessions. To use a KIE session pool, you obtain a KIE session pool from a KIE container, define the initial number of KIE sessions in the pool, and create the KIE sessions from that pool as usual: + +.Example KIE session pool +[source,java] +---- +// Obtain a KIE session pool from the KIE container +KieContainerSessionsPool pool = kContainer.newKieSessionsPool(10); + +// Create KIE sessions from the KIE session pool +KieSession kSession = pool.newKieSession(); +---- + +In this example, the KIE session pool starts with 10 KIE sessions in it, but you can specify the number of KIE sessions that you need. This integer value is the number of KIE sessions that are only initially created in the pool. If required by the running application, the number of KIE sessions in the pool can dynamically grow beyond that value. + +After you define a KIE session pool, the next time you use the KIE session as usual and call `dispose()` on it, the KIE session is reset and pushed back into the pool instead of being destroyed. + +KIE session pools typically apply to stateful KIE sessions, but KIE session pools can also affect stateless KIE sessions that you reuse with multiple `execute()` calls. When you create a stateless KIE session directly from a KIE container, the KIE session continues to internally create a new KIE session for each `execute()` invocation. Conversely, when you create a stateless KIE session from a KIE session pool, the KIE session internally uses only the specific KIE sessions provided by the pool. + +When you finish using a KIE session pool, you can call the `shutdown()` method on it to avoid memory leaks. Alternatively, you can call `dispose()` on the KIE container to shut down all the pools created from the KIE container. diff --git a/assemblies/modules/decision-engine/con-kie-sessions-stateful.adoc b/assemblies/modules/decision-engine/con-kie-sessions-stateful.adoc new file mode 100644 index 0000000..c62af69 --- /dev/null +++ b/assemblies/modules/decision-engine/con-kie-sessions-stateful.adoc @@ -0,0 +1,160 @@ +[id='con-kie-sessions-stateful_{context}'] += Stateful KIE sessions + +A stateful KIE session is a session that uses inference to make iterative changes to facts over time. In a stateful KIE session, data from a previous invocation of the KIE session (the previous session state) is retained between session invocations, whereas in a stateless KIE session, that data is discarded. + +WARNING: Ensure that you call the `dispose()` method after running a stateful KIE session so that no memory leaks occur between session invocations. + +Stateful KIE sessions are commonly used for the following use cases: + +* *Monitoring*, such as monitoring a stock market and automating the buying process +* *Diagnostics*, such as running fault-finding processes or medical diagnostic processes +* *Logistics*, such as parcel tracking and delivery provisioning +* *Ensuring compliance*, such as verifying the legality of market trades + +For example, consider the following fire alarm data model and sample DRL rules: + +.Data model for sprinklers and fire alarm +[source,java] +---- +public class Room { + private String name; + // Getter and setter methods +} + +public class Sprinkler { + private Room room; + private boolean on; + // Getter and setter methods +} + +public class Fire { + private Room room; + // Getter and setter methods +} + +public class Alarm { } +---- + +.Sample DRL rule set for activating sprinklers and alarm +[source] +---- +rule "When there is a fire turn on the sprinkler" +when + Fire($room : room) + $sprinkler : Sprinkler(room == $room, on == false) +then + modify($sprinkler) { setOn(true) }; + System.out.println("Turn on the sprinkler for room "+$room.getName()); +end + +rule "Raise the alarm when we have one or more fires" +when + exists Fire() +then + insert( new Alarm() ); + System.out.println( "Raise the alarm" ); +end + +rule "Cancel the alarm when all the fires have gone" +when + not Fire() + $alarm : Alarm() +then + delete( $alarm ); + System.out.println( "Cancel the alarm" ); +end + + +rule "Status output when things are ok" +when + not Alarm() + not Sprinkler( on == true ) +then + System.out.println( "Everything is ok" ); +end +---- + +For the `When there is a fire turn on the sprinkler` rule, when a fire occurs, the instances of the `Fire` class are created for that room and inserted into the KIE session. The rule adds a constraint for the specific `room` matched in the `Fire` instance so that only the sprinkler for that room is checked. When this rule is executed, the sprinkler activates. The other sample rules determine when the alarm is activated or deactivated accordingly. + +Whereas a stateless KIE session relies on standard Java syntax to modify a field, a stateful KIE session relies on the `modify` statement in rules to notify the {DECISION_ENGINE} of changes. The {DECISION_ENGINE} then reasons over the changes and assesses impact on subsequent rule executions. This process is part of the {DECISION_ENGINE} ability to use _inference_ and _truth maintenance_ and is essential in stateful KIE sessions. + +In this example, the sample rules and all other files in the `~/resources` folder of the {PRODUCT} project are built with the following code: + +.Create the KIE container +[source,java] +---- +KieServices kieServices = KieServices.Factory.get(); +KieContainer kContainer = kieServices.getKieClasspathContainer(); +---- + +This code compiles all the rule files found on the class path and adds the result of this compilation, a `KieModule` object, in the `KieContainer`. + +Finally, the `KieSession` object is instantiated from the `KieContainer` and is executed against specified data: + +.Instantiate the stateful KIE session and enter data +[source,java] +---- +KieSession ksession = kContainer.newKieSession(); + +String[] names = new String[]{"kitchen", "bedroom", "office", "livingroom"}; +Map name2room = new HashMap(); +for( String name: names ){ + Room room = new Room( name ); + name2room.put( name, room ); + ksession.insert( room ); + Sprinkler sprinkler = new Sprinkler( room ); + ksession.insert( sprinkler ); +} + +ksession.fireAllRules(); +---- + +.Console output +[source] +---- +> Everything is ok +---- + +With the data added, the {DECISION_ENGINE} completes all pattern matching but no rules have been executed, so the configured verification message appears. As new data triggers rule conditions, the {DECISION_ENGINE} executes rules to activate the alarm and later to cancel the alarm that has been activated: + +.Enter new data to trigger rules +[source,java] +---- +Fire kitchenFire = new Fire( name2room.get( "kitchen" ) ); +Fire officeFire = new Fire( name2room.get( "office" ) ); + +FactHandle kitchenFireHandle = ksession.insert( kitchenFire ); +FactHandle officeFireHandle = ksession.insert( officeFire ); + +ksession.fireAllRules(); +---- + +.Console output +[source] +---- +> Raise the alarm +> Turn on the sprinkler for room kitchen +> Turn on the sprinkler for room office +---- + +[source,java] +---- +ksession.delete( kitchenFireHandle ); +ksession.delete( officeFireHandle ); + +ksession.fireAllRules(); +---- + +.Console output +[source] +---- +> Cancel the alarm +> Turn off the sprinkler for room office +> Turn off the sprinkler for room kitchen +> Everything is ok +---- + +In this case, a reference is kept for the returned `FactHandle` object. A fact handle is an internal engine reference to the inserted instance and enables instances to be retracted or modified later. + +As this example illustrates, the data and results from previous stateful KIE sessions (the activated alarm) affect the invocation of subsequent sessions (alarm cancellation). diff --git a/assemblies/modules/decision-engine/con-kie-sessions-stateless-globals.adoc b/assemblies/modules/decision-engine/con-kie-sessions-stateless-globals.adoc new file mode 100644 index 0000000..17dbaf1 --- /dev/null +++ b/assemblies/modules/decision-engine/con-kie-sessions-stateless-globals.adoc @@ -0,0 +1,48 @@ +[id='con-kie-sessions-stateless-globals_{context}'] += Global variables in stateless KIE sessions + +The `StatelessKieSession` object supports global variables (globals) that you can configure to be resolved as session-scoped globals, delegate globals, or execution-scoped globals. + +* *Session-scoped globals:* For session-scoped globals, you can use the method `getGlobals()` to return a `Globals` instance that provides access to the KIE session globals. These globals are used for all execution calls. Use caution with mutable globals because execution calls can be executing simultaneously in different threads. ++ +.Session-scoped global +[source,java] +---- +import org.kie.api.runtime.StatelessKieSession; + +StatelessKieSession ksession = kbase.newStatelessKieSession(); + +// Set a global `myGlobal` that can be used in the rules. +ksession.setGlobal("myGlobal", "I am a global"); + +// Execute while resolving the `myGlobal` identifier. +ksession.execute(collection); +---- + +* *Delegate globals:* For delegate globals, you can assign a value to a global (with `setGlobal(String, Object)`) so that the value is stored in an internal collection that maps identifiers to values. Identifiers in this internal collection have priority over any supplied delegate. If an identifier cannot be found in this internal collection, the delegate global (if any) is used. + +* *Execution-scoped globals:* For execution-scoped globals, you can use the `Command` object to set a global that is passed to the `CommandExecutor` interface for execution-specific global resolution. + +The `CommandExecutor` interface also enables you to export data using out identifiers for globals, inserted facts, and query results: + +.Out identifiers for globals, inserted facts, and query results +[source,java] +---- +import org.kie.api.runtime.ExecutionResults; + +// Set up a list of commands. +List cmds = new ArrayList(); +cmds.add(CommandFactory.newSetGlobal("list1", new ArrayList(), true)); +cmds.add(CommandFactory.newInsert(new Person("jon", 102), "person")); +cmds.add(CommandFactory.newQuery("Get People" "getPeople")); + +// Execute the list. +ExecutionResults results = ksession.execute(CommandFactory.newBatchExecution(cmds)); + +// Retrieve the `ArrayList`. +results.getValue("list1"); +// Retrieve the inserted `Person` fact. +results.getValue("person"); +// Retrieve the query as a `QueryResults` instance. +results.getValue("Get People"); +---- diff --git a/assemblies/modules/decision-engine/con-kie-sessions-stateless.adoc b/assemblies/modules/decision-engine/con-kie-sessions-stateless.adoc new file mode 100644 index 0000000..a51b71c --- /dev/null +++ b/assemblies/modules/decision-engine/con-kie-sessions-stateless.adoc @@ -0,0 +1,140 @@ +[id='con-kie-sessions-stateless_{context}'] += Stateless KIE sessions + +A stateless KIE session is a session that does not use inference to make iterative changes to facts over time. In a stateless KIE session, data from a previous invocation of the KIE session (the previous session state) is discarded between session invocations, whereas in a stateful KIE session, that data is retained. A stateless KIE session behaves similarly to a function in that the results that it produces are determined by the contents of the KIE base and by the data that is passed into the KIE session for execution at a specific point in time. The KIE session has no memory of any data that was passed into the KIE session previously. + +Stateless KIE sessions are commonly used for the following use cases: + +* *Validation*, such as validating that a person is eligible for a mortgage +* *Calculation*, such as computing a mortgage premium +* *Routing and filtering*, such as sorting incoming emails into folders or sending incoming emails to a destination + +For example, consider the following driver's license data model and sample DRL rule: + +.Data model for driver's license application +[source,java] +---- +public class Applicant { + private String name; + private int age; + private boolean valid; + // Getter and setter methods +} +---- + +.Sample DRL rule for driver's license application +[source] +---- +package com.company.license + +rule "Is of valid age" +when + $a : Applicant(age < 18) +then + $a.setValid(false); +end +---- + +The `Is of valid age` rule disqualifies any applicant younger than 18 years old. When the `Applicant` object is inserted into the {DECISION_ENGINE}, the {DECISION_ENGINE} evaluates the constraints for each rule and searches for a match. The `"objectType"` constraint is always implied, after which any number of explicit field constraints are evaluated. The variable `$a` is a binding variable that references the matched object in the rule consequence. + +[NOTE] +==== +The dollar sign (`$`) is optional and helps to differentiate between variable names and field names. +==== + +In this example, the sample rule and all other files in the `~/resources` folder of the {PRODUCT} project are built with the following code: + +.Create the KIE container +[source,java] +---- +KieServices kieServices = KieServices.Factory.get(); + +KieContainer kContainer = kieServices.getKieClasspathContainer(); +---- + +This code compiles all the rule files found on the class path and adds the result of this compilation, a `KieModule` object, in the `KieContainer`. + +Finally, the `StatelessKieSession` object is instantiated from the `KieContainer` and is executed against specified data: + +.Instantiate the stateless KIE session and enter data +[source,java] +---- +StatelessKieSession kSession = kContainer.newStatelessKieSession(); + +Applicant applicant = new Applicant("Mr John Smith", 16); + +assertTrue(applicant.isValid()); + +ksession.execute(applicant); + +assertFalse(applicant.isValid()); +---- + +In a stateless KIE session configuration, the `execute()` call acts as a combination method that instantiates the `KieSession` object, adds all the user data and executes user commands, calls `fireAllRules()`, and then calls `dispose()`. Therefore, with a stateless KIE session, you do not need to call `fireAllRules()` or call `dispose()` after session invocation as you do with a stateful KIE session. + +In this case, the specified applicant is under the age of 18, so the application is declined. + +For a more complex use case, see the following example. This example uses a stateless KIE session and executes rules against an iterable list of objects, such as a collection. + +.Expanded data model for driver's license application +[source,java] +---- +public class Applicant { + private String name; + private int age; + // Getter and setter methods +} + +public class Application { + private Date dateApplied; + private boolean valid; + // Getter and setter methods +} +---- + +.Expanded DRL rule set for driver's license application +[source] +---- +package com.company.license + +rule "Is of valid age" +when + Applicant(age < 18) + $a : Application() +then + $a.setValid(false); +end + +rule "Application was made this year" +when + $a : Application(dateApplied > "01-jan-2009") +then + $a.setValid(false); +end +---- + +.Expanded Java source with iterable execution in a stateless KIE session +[source,java] +---- +StatelessKieSession ksession = kbase.newStatelessKnowledgeSession(); +Applicant applicant = new Applicant("Mr John Smith", 16); +Application application = new Application(); + +assertTrue(application.isValid()); +ksession.execute(Arrays.asList(new Object[] { application, applicant })); // <1> +assertFalse(application.isValid()); + +ksession.execute + (CommandFactory.newInsertIterable(new Object[] { application, applicant })); // <2> + +List cmds = new ArrayList(); // <3> +cmds.add(CommandFactory.newInsert(new Person("Mr John Smith"), "mrSmith")); +cmds.add(CommandFactory.newInsert(new Person("Mr John Doe"), "mrDoe")); + +BatchExecutionResults results = ksession.execute(CommandFactory.newBatchExecution(cmds)); +assertEquals(new Person("Mr John Smith"), results.getValue("mrSmith")); +---- + +<1> Method for executing rules against an iterable collection of objects produced by the `Arrays.asList()` method. Every collection element is inserted before any matched rules are executed. The `execute(Object object)` and `execute(Iterable objects)` methods are wrappers around the `execute(Command command)` method that comes from the `BatchExecutor` interface. +<2> Execution of the iterable collection of objects using the `CommandFactory` interface. +<3> `BatchExecutor` and `CommandFactory` configurations for working with many different commands or result output identifiers. The `CommandFactory` interface supports other commands that you can use in the `BatchExecutor`, such as `StartProcess`, `Query`, and `SetGlobal`. diff --git a/assemblies/modules/decision-engine/con-kie-sessions.adoc b/assemblies/modules/decision-engine/con-kie-sessions.adoc new file mode 100644 index 0000000..fa1cf6c --- /dev/null +++ b/assemblies/modules/decision-engine/con-kie-sessions.adoc @@ -0,0 +1,41 @@ +[id='con-kie-sessions_{context}'] += KIE sessions + +In {PRODUCT}, a KIE session stores and executes runtime data. The KIE session is created from a KIE base or directly from a KIE container if you have defined the KIE session in the KIE module descriptor file (`kmodule.xml`) for your project. + +.Example KIE session configuration in a `kmodule.xml` file +[source,xml] +---- + + ... + + ... + + ... + + ... + +---- + +A KIE base is a repository that you define in the KIE module descriptor file (`kmodule.xml`) for your project and contains all +ifdef::DM[] +rules and other business assets +endif::DM[] +ifdef::PAM[] +rules, processes, and other business assets +endif::PAM[] +in {PRODUCT}, but does not contain any runtime data. + +.Example KIE base configuration in a `kmodule.xml` file +[source,xml] +---- + + ... + + ... + + ... + +---- + +A KIE session can be stateless or stateful. In a stateless KIE session, data from a previous invocation of the KIE session (the previous session state) is discarded between session invocations. In a stateful KIE session, that data is retained. The type of KIE session you use depends on your project requirements and how you want data from different asset invocations to be persisted. diff --git a/assemblies/modules/decision-engine/con-phreak-algorithm.adoc b/assemblies/modules/decision-engine/con-phreak-algorithm.adoc new file mode 100644 index 0000000..7416f82 --- /dev/null +++ b/assemblies/modules/decision-engine/con-phreak-algorithm.adoc @@ -0,0 +1,15 @@ +[id='con-phreak-algorithm_{context}'] += Phreak rule algorithm in the {DECISION_ENGINE} + +The {DECISION_ENGINE} in {PRODUCT} uses the Phreak algorithm for rule evaluation. Phreak evolved from the Rete algorithm, including the enhanced Rete algorithm ReteOO that was introduced in previous versions of Drools for object-oriented systems. Overall, Phreak is more scalable than Rete and ReteOO, and is faster in large systems. + +While Rete is considered eager (immediate rule evaluation) and data oriented, Phreak is considered lazy (delayed rule evaluation) and goal oriented. The Rete algorithm performs many actions during the insert, update, and delete actions in order to find partial matches for all rules. This eagerness of the Rete algorithm during rule matching requires a lot of time before eventually executing rules, especially in large systems. With Phreak, this partial matching of rules is delayed deliberately to handle large amounts of data more efficiently. + +The Phreak algorithm adds the following set of enhancements to previous Rete algorithms: + +* Three layers of contextual memory: Node, segment, and rule memory types +* Rule-based, segment-based, and node-based linking +* Lazy (delayed) rule evaluation +* Stack-based evaluations with pause and resume +* Isolated rule evaluation +* Set-oriented propagations diff --git a/assemblies/modules/decision-engine/con-phreak-rule-evaluation.adoc b/assemblies/modules/decision-engine/con-phreak-rule-evaluation.adoc new file mode 100644 index 0000000..e137096 --- /dev/null +++ b/assemblies/modules/decision-engine/con-phreak-rule-evaluation.adoc @@ -0,0 +1,97 @@ +[id='con-phreak-rule-evaluation_{context}'] += Rule evaluation in Phreak + +When the {DECISION_ENGINE} starts, all rules are considered to be _unlinked_ from pattern-matching data that can trigger the rules. At this stage, the Phreak algorithm in the {DECISION_ENGINE} does not evaluate the rules. The rule actions are queued, and Phreak uses a heuristic, based on the rule most likely to result in execution, to calculate and select the next rule for evaluation. When all the required input values are populated for a rule, the rule is considered to be _linked_ to the relevant pattern-matching data. Phreak then creates a goal that represents this rule and places the goal into a priority queue that is ordered by rule salience. Only the rule for which the goal was created is evaluated, and other potential rule evaluations are delayed. While individual rules are evaluated, node sharing is still achieved through the process of segmentation. + +Unlike the tuple-oriented Rete, the Phreak propagation is collection oriented. For the rule that is being evaluated, the {DECISION_ENGINE} accesses the first node and processes all queued insert, update, and delete actions. The results are added to a set, and the set is propagated to the child node. In the child node, all queued insert, update, and delete actions are processed, adding the results to the same set. The set is then propagated to the next child node and the same process repeats until it reaches the terminal node. This cycle creates a batch process effect that can provide performance advantages for certain rule constructs. + +The linking and unlinking of rules happens through a layered bit-mask system, based on network segmentation. When the rule network is built, segments are created for rule network nodes that are shared by the same set of rules. A rule is composed of a path of segments. In case a rule does not share any node with any other rule, it becomes a single segment. + +A bit-mask offset is assigned to each node in the segment. Another bit mask is assigned to each segment in the path of the rule according to these requirements: + +* If at least one input for a node exists, the node bit is set to the `on` state. +* If each node in a segment has the bit set to the `on` state, the segment bit is also set to the `on` state. +* If any node bit is set to the `off` state, the segment is also set to the `off` state. +* If each segment in the path of the rule is set to the `on` state, the rule is considered linked, and a goal is created to schedule the rule for evaluation. + +The same bit-mask technique is used to track modified nodes, segments, and rules. This tracking ability enables an already linked rule to be unscheduled from evaluation if it has been modified since the evaluation goal for it was created. As a result, no rules can ever evaluate partial matches. + +This process of rule evaluation is possible in Phreak because, as opposed to a single unit of memory in Rete, Phreak has three layers of contextual memory with node, segment, and rule memory types. This layering enables much more contextual understanding during the evaluation of a rule. + +.Phreak three-layered memory system +ifdef::KOGITO-COMM[] +image::kogito/decision-engine/LayeredMemory.png[align="center"] +endif::[] +ifdef::KOGITO-ENT[] +image::kogito/decision-engine/LayeredMemory_enterprise.png[align="center"] +endif::[] + +The following examples illustrate how rules are organized and evaluated in this three-layered memory system in Phreak. + +*Example 1:* A single rule (R1) with three patterns: A, B and C. The rule forms a single segment, with bits 1, 2, and 4 for the nodes. The single segment has a bit offset of 1. + +.Example 1: Single rule +ifdef::KOGITO-COMM[] +image::kogito/decision-engine/segment1.png[align="center"] +endif::[] +ifdef::KOGITO-ENT[] +image::kogito/decision-engine/segment1_enterprise.png[align="center"] +endif::[] + +*Example 2:* Rule R2 is added and shares pattern A. + +.Example 2: Two rules with pattern sharing +ifdef::KOGITO-COMM[] +image::kogito/decision-engine/segment2.png[align="center"] +endif::[] +ifdef::KOGITO-ENT[] +image::kogito/decision-engine/segment2_enterprise.png[align="center"] +endif::[] + +Pattern A is placed in its own segment, resulting in two segments for each rule. Those two segments form a path for their respective rules. The first segment is shared by both paths. When pattern A is linked, the segment becomes linked. The segment then iterates over each path that the segment is shared by, setting the bit 1 to `on`. If patterns B and C are later turned on, the second segment for path R1 is linked, and this causes bit 2 to be turned on for R1. With bit 1 and bit 2 turned on for R1, the rule is now linked and a goal is created to schedule the rule for later evaluation and execution. + +When a rule is evaluated, the segments enable the results of the matching to be shared. Each segment has a staging memory to queue all inserts, updates, and deletes for that segment. When R1 is evaluated, the rule processes pattern A, and this results in a set of tuples. The algorithm detects a segmentation split, creates peered tuples for each insert, update, and delete in the set, and adds them to the R2 staging memory. Those tuples are then merged with any existing staged tuples and are executed when R2 is eventually evaluated. + +*Example 3:* Rules R3 and R4 are added and share patterns A and B. + +.Example 3: Three rules with pattern sharing +ifdef::KOGITO-COMM[] +image::kogito/decision-engine/segment3.png[align="center"] +endif::[] +ifdef::KOGITO-ENT[] +image::kogito/decision-engine/segment3_enterprise.png[align="center"] +endif::[] + +Rules R3 and R4 have three segments and R1 has two segments. Patterns A and B are shared by R1, R3, and R4, while pattern D is shared by R3 and R4. + +*Example 4:* A single rule (R1) with a subnetwork and no pattern sharing. + +.Example 4: Single rule with a subnetwork and no pattern sharing +ifdef::KOGITO-COMM[] +image::kogito/decision-engine/segment4.png[align="center"] +endif::[] +ifdef::KOGITO-ENT[] +image::kogito/decision-engine/segment4_enterprise.png[align="center"] +endif::[] + +Subnetworks are formed when a `Not`, `Exists`, or `Accumulate` node contains more than one element. In this example, the element `B not( C )` forms the subnetwork. The element `not( C )` is a single element that does not require a subnetwork and is therefore merged inside of the `Not` node. The subnetwork uses a dedicated segment. Rule R1 still has a path of two segments and the subnetwork forms another inner path. When the subnetwork is linked, it is also linked in the outer segment. + +*Example 5:* Rule R1 with a subnetwork that is shared by rule R2. + +.Example 5: Two rules, one with a subnetwork and pattern sharing +ifdef::KOGITO-COMM[] +image::kogito/decision-engine/segment5.png[align="center"] +endif::[] +ifdef::KOGITO-ENT[] +image::kogito/decision-engine/segment5_enterprise.png[align="center"] +endif::[] + +The subnetwork nodes in a rule can be shared by another rule that does not have a subnetwork. This sharing causes the subnetwork segment to be split into two segments. + +Constrained `Not` nodes and `Accumulate` nodes can never unlink a segment, and are always considered to have their bits turned on. + +The Phreak evaluation algorithm is stack based instead of method-recursion based. Rule evaluation can be paused and resumed at any time when a `StackEntry` is used to represent the node currently being evaluated. + +When a rule evaluation reaches a subnetwork, a `StackEntry` object is created for the outer path segment and the subnetwork segment. The subnetwork segment is evaluated first, and when the set reaches the end of the subnetwork path, the segment is merged into a staging list for the outer node that the segment feeds into. The previous `StackEntry` object is then resumed and can now process the results of the subnetwork. This process has the added benefit, especially for `Accumulate` nodes, that all work is completed in a batch, before propagating to the child node. + +The same stack system is used for efficient backward chaining. When a rule evaluation reaches a query node, the evaluation is paused and the query is added to the stack. The query is then evaluated to produce a result set, which is saved in a memory location for the resumed `StackEntry` object to pick up and propagate to the child node. If the query itself called other queries, the process repeats, while the current query is paused and a new evaluation is set up for the current query node. diff --git a/assemblies/modules/decision-engine/con-phreak-sequential-mode.adoc b/assemblies/modules/decision-engine/con-phreak-sequential-mode.adoc new file mode 100644 index 0000000..4aaf639 --- /dev/null +++ b/assemblies/modules/decision-engine/con-phreak-sequential-mode.adoc @@ -0,0 +1,66 @@ +[id='con-phreak-sequential-mode_{context}'] += Sequential mode in Phreak + +*<@Edoardo, see this section. This was another hot topic in 7.x.>* + +Sequential mode is an advanced rule base configuration in the {DECISION_ENGINE}, supported by Phreak, that enables the {DECISION_ENGINE} to evaluate rules one time in the order that they are listed in the {DECISION_ENGINE} agenda without regard to changes in the working memory. In sequential mode, the {DECISION_ENGINE} ignores any `insert`, `modify`, or `update` statements in rules and executes rules in a single sequence. As a result, rule execution may be faster in sequential mode, but important updates may not be applied to your rules. + +Sequential mode applies to only stateless KIE sessions because stateful KIE sessions inherently use data from previously invoked KIE sessions. If you use a stateless KIE session and you want the execution of rules to influence subsequent rules in the agenda, then do not enable sequential mode. Sequential mode is disabled by default in the {DECISION_ENGINE}. + +To enable sequential mode, use one of the following options: + +* Set the system property `drools.sequential` to `true`. +* Enable sequential mode while creating the KIE base programmatically: ++ +[source,java] +---- +KieServices ks = KieServices.Factory.get(); +KieBaseConfiguration kieBaseConf = ks.newKieBaseConfiguration(); +kieBaseConf.setOption(SequentialOption.YES); +KieBase kieBase = kieContainer.newKieBase(kieBaseConf); +---- +* Enable sequential mode in the KIE module descriptor file (`kmodule.xml`) for a specific {PRODUCT} project: ++ +[source,xml] +---- + + ... + + ... + + ... + +---- + +To configure sequential mode to use a dynamic agenda, use one of the following options: + +* Set the system property `drools.sequential.agenda` to `dynamic`. +* Set the sequential agenda option while creating the KIE base programmatically: ++ +[source,java] +---- +KieServices ks = KieServices.Factory.get(); +KieBaseConfiguration kieBaseConf = ks.newKieBaseConfiguration(); +kieBaseConf.setOption(SequentialAgendaOption.DYNAMIC); +KieBase kieBase = kieContainer.newKieBase(kieBaseConf); +---- + +When you enable sequential mode, the {DECISION_ENGINE} evaluates rules in the following way: + +. Rules are ordered by salience and position in the rule set. +. An element for each possible rule match is created. The element position indicates the execution order. +. Node memory is disabled, with the exception of the right-input object memory. +. The left-input adapter node propagation is disconnected and the object with the node is referenced in a `Command` object. The `Command` object is added to a list in the working memory for later execution. +. All objects are asserted, and then the list of `Command` objects is checked and executed. +. All matches that result from executing the list are added to elements based on the sequence number of the rule. +. The elements that contain matches are executed in a sequence. If you set a maximum number of rule executions, the {DECISION_ENGINE} activates no more than that number of rules in the agenda for execution. + +In sequential mode, the `LeftInputAdapterNode` node creates a `Command` object and adds it to a list in the working memory of the {DECISION_ENGINE}. This `Command` object contains references to the `LeftInputAdapterNode` node and the propagated object. These references stop any left-input propagations at insertion time so that the right-input propagation never needs to attempt to join the left inputs. The references also avoid the need for the left-input memory. + +All nodes have their memory turned off, including the left-input tuple memory, but excluding the right-input object memory. After all the assertions are finished and the right-input memory of all the objects is populated, the {DECISION_ENGINE} iterates over the list of `LeftInputAdatperNode` `Command` objects. The objects propagate down the network, attempting to join the right-input objects, but they are not retained in the left input. + +The agenda with a priority queue to schedule the tuples is replaced by an element for each rule. The sequence number of the `RuleTerminalNode` node indicates the element where to place the match. After all `Command` objects have finished, the elements are checked and existing matches are executed. To improve performance, the first and the last populated cell in the elements are retained. + +When the network is constructed, each `RuleTerminalNode` node receives a sequence number based on its salience number and the order in which it was added to the network. + +The right-input node memories are typically hash maps for fast object deletion. Because object deletions are not supported, Phreak uses an object list when the values of the object are not indexed. For a large number of objects, indexed hash maps provide a performance increase. If an object has only a few instances, Phreak uses an object list instead of an index. diff --git a/assemblies/modules/decision-engine/con-property-change-listeners.adoc b/assemblies/modules/decision-engine/con-property-change-listeners.adoc new file mode 100644 index 0000000..e91b13e --- /dev/null +++ b/assemblies/modules/decision-engine/con-property-change-listeners.adoc @@ -0,0 +1,121 @@ +[id='con-property-change-listeners_{context}'] += Property-change settings and listeners for fact types + +By default, the {DECISION_ENGINE} does not re-evaluate all fact patterns for fact types each time a rule is triggered, but instead reacts only to modified properties that are constrained or bound inside a given pattern. For example, if a rule calls `modify()` on a fact as part of the rule actions, this modification does not automatically trigger the re-evaluation of all patterns referring to the modified type. Only the patterns constrained on the changed properties of that fact are re-evaluated. This property reactivity behavior prevents unwanted recursions and results in more efficient rule evaluation. This behavior also avoids the need of using the `no-loop` rule attribute to prevent infinite recursion. + +You can modify or disable this property reactivity behavior with the following options, and then use a property-change setting in your Java class or DRL files to fine-tune property reactivity as needed: + +* `ALWAYS`: (Default) All types are property reactive, but you can disable property reactivity for a specific type by using the `@classReactive` property-change setting. +* `ALLOWED`: No types are property reactive, but you can enable property reactivity for a specific type by using the `@propertyReactive` property-change setting. +* `DISABLED`: No types are property reactive. All property-change listeners are ignored. + +To set the property reactivity behavior, update the `drools.propertySpecific` system property in the `application.properties` file of your {PRODUCT} project: + +.Example property reactivity setting in system properties +[source] +---- +drools.propertySpecific=ALLOWED +---- + +The {DECISION_ENGINE} supports the following property-change settings and listeners for fact classes or declared DRL fact types: + +@classReactive:: +If property reactivity is set to `ALWAYS` in the {DECISION_ENGINE} (all types are property reactive), this tag disables the default property reactivity behavior for a specific Java class or a declared DRL fact type. You can use this tag if you want the {DECISION_ENGINE} to re-evaluate all fact patterns for the specified fact type each time the rule is triggered, instead of reacting only to modified properties that are constrained or bound inside a given pattern. ++ +-- +.Example: Disable default property reactivity in a DRL type declaration +[source] +---- +declare Person + @classReactive + firstName : String + lastName : String +end +---- + +.Example: Disable default property reactivity in a Java class +[source,java] +---- +@classReactive +public static class Person { + private String firstName; + private String lastName; +} +---- +-- + +@propertyReactive:: +If property reactivity is set to `ALLOWED` in the {DECISION_ENGINE} (no types are property reactive unless specified), this tag enables property reactivity for a specific Java class or a declared DRL fact type. You can use this tag if you want the {DECISION_ENGINE} to react only to modified properties that are constrained or bound inside a given pattern for the specified fact type, instead of re-evaluating all fact patterns for the fact each time the rule is triggered. ++ +-- +.Example: Enable property reactivity in a DRL type declaration (when reactivity is disabled globally) +[source] +---- +declare Person + @propertyReactive + firstName : String + lastName : String +end +---- + +.Example: Enable property reactivity in a Java class (when reactivity is disabled globally) +[source,java] +---- +@propertyReactive +public static class Person { + private String firstName; + private String lastName; +} +---- +-- + +//@comment Currently TBD in Kogito, so excluding for now. (Stetson 7 Apr 2020) +//// +@watch:: +This tag enables property reactivity for additional properties that you specify in-line in fact patterns in DRL rules. This tag is supported only if property reactivity is set to `ALWAYS` in the {DECISION_ENGINE}, or if property reactivity is set to `ALLOWED` and the relevant fact type uses the `@propertyReactive` tag. You can use this tag in DRL rules to add or exclude specific properties in fact property reactivity logic. ++ +-- +Default parameter: None + +Supported parameters: Property name, `\*` (all), `!` (not), `!*` (no properties) + +[source] +---- + @watch ( ) +---- + +.Example: Enable or disable property reactivity in fact patterns +[source] +---- +// Listens for changes in both `firstName` (inferred) and `lastName`: +Person(firstName == $expectedFirstName) @watch( lastName ) + +// Listens for changes in all properties of the `Person` fact: +Person(firstName == $expectedFirstName) @watch( * ) + +// Listens for changes in `lastName` and explicitly excludes changes in `firstName`: +Person(firstName == $expectedFirstName) @watch( lastName, !firstName ) + +// Listens for changes in all properties of the `Person` fact except `age`: +Person(firstName == $expectedFirstName) @watch( *, !age ) + +// Excludes changes in all properties of the `Person` fact (equivalent to using `@classReactivity` tag): +Person(firstName == $expectedFirstName) @watch( !* ) +---- + +The {DECISION_ENGINE} generates a compilation error if you use the `@watch` tag for properties in a fact type that uses the `@classReactive` tag (disables property reactivity) or when property reactivity is set to `ALLOWED` in the {DECISION_ENGINE} and the relevant fact type does not use the `@propertyReactive` tag. Compilation errors also arise if you duplicate properties in listener annotations, such as `@watch( firstName, ! firstName )`. +-- +//// + +@propertyChangeSupport:: +For facts that implement support for property changes as defined in the https://download.oracle.com/otndocs/jcp/7224-javabeans-1.01-fr-spec-oth-JSpec/[JavaBeans Specification], this tag enables the {DECISION_ENGINE} to monitor changes in the fact properties. ++ +-- +.Example: Declare property change support in JavaBeans object +[source] +---- +declare Person + @propertyChangeSupport +end +---- +-- diff --git a/assemblies/modules/decision-engine/con-rule-base-configuration.adoc b/assemblies/modules/decision-engine/con-rule-base-configuration.adoc new file mode 100644 index 0000000..db86843 --- /dev/null +++ b/assemblies/modules/decision-engine/con-rule-base-configuration.adoc @@ -0,0 +1,113 @@ +[id='con-rule-base-configuration_{context}'] += Rule base configuration + +*<@Edoardo, see this section.>* + +{PRODUCT} contains a `RuleBaseConfiguration.java` object that you can use to configure exception handler settings, multithreaded execution, and sequential mode in the {DECISION_ENGINE}. + +For the rule base configuration options, +//// +ifdef::KOGITO-ENT[] +download the *{PRODUCT} {ENTERPRISE_VERSION_LONG} Source Distribution* ZIP file from the https://access.redhat.com/jbossnetwork/restricted/listSoftware.html[Red Hat Customer Portal] and navigate to `~/{PRODUCT_FILE}-sources/src/drools-$VERSION/drools-core/src/main/java/org/drools/core/RuleBaseConfiguration.java`. +endif::[] +ifdef::KOGITO-COMM[] +//// +see the {PRODUCT} https://github.com/kiegroup/drools/blob/{COMMUNITY_VERSION_BRANCH}/drools-core/src/main/java/org/drools/core/RuleBaseConfiguration.java[RuleBaseConfiguration.java] page in GitHub. +//endif::[] + +The following rule base configuration options are available for the {DECISION_ENGINE}: + +drools.consequenceExceptionHandler:: +When configured, this system property defines the class that manages the exceptions thrown by rule consequences. You can use this property to specify a custom exception handler for rule evaluation in the {DECISION_ENGINE}. ++ +-- +Default value: `org.drools.core.runtime.rule.impl.DefaultConsequenceExceptionHandler` + +You can specify the custom exception handler using one of the following options: + +* Specify the exception handler in a system property: ++ +[source] +---- +drools.consequenceExceptionHandler=org.drools.core.runtime.rule.impl.MyCustomConsequenceExceptionHandler +---- + +* Specify the exception handler while creating the KIE base programmatically: ++ +[source,java] +---- +KieServices ks = KieServices.Factory.get(); +KieBaseConfiguration kieBaseConf = ks.newKieBaseConfiguration(); kieBaseConf.setOption(ConsequenceExceptionHandlerOption.get(MyCustomConsequenceExceptionHandler.class)); +KieBase kieBase = kieContainer.newKieBase(kieBaseConf); +---- +-- + +drools.multithreadEvaluation:: +When enabled, this system property enables the {DECISION_ENGINE} to evaluate rules in parallel by dividing the Phreak rule network into independent partitions. You can use this property to increase the speed of rule evaluation for specific rule bases. ++ +-- +Default value: `false` + +You can enable multithreaded evaluation using one of the following options: + +* Enable the multithreaded evaluation system property: ++ +[source] +---- +drools.multithreadEvaluation=true +---- + +* Enable multithreaded evaluation while creating the KIE base programmatically: ++ +[source,java] +---- +KieServices ks = KieServices.Factory.get(); +KieBaseConfiguration kieBaseConf = ks.newKieBaseConfiguration(); +kieBaseConf.setOption(MultithreadEvaluationOption.YES); +KieBase kieBase = kieContainer.newKieBase(kieBaseConf); +---- + +[WARNING] +==== +Rules that use queries, salience, or agenda groups are currently not supported by the parallel {DECISION_ENGINE}. If these rule elements are present in the KIE base, the compiler emits a warning and automatically switches back to single-threaded evaluation. However, in some cases, the {DECISION_ENGINE} might not detect the unsupported rule elements and rules might be evaluated incorrectly. For example, the {DECISION_ENGINE} might not detect when rules rely on implicit salience given by rule ordering inside the DRL file, resulting in incorrect evaluation due to the unsupported salience attribute. +==== +-- + +drools.sequential:: +When enabled, this system property enables sequential mode in the {DECISION_ENGINE}. In sequential mode, the {DECISION_ENGINE} evaluates rules one time in the order that they are listed in the {DECISION_ENGINE} agenda without regard to changes in the working memory. This means that the {DECISION_ENGINE} ignores any `insert`, `modify`, or `update` statements in rules and executes rules in a single sequence. As a result, rule execution may be faster in sequential mode, but important updates may not be applied to your rules. You can use this property if you use stateless KIE sessions and you do not want the execution of rules to influence subsequent rules in the agenda. Sequential mode applies to stateless KIE sessions only. ++ +-- +Default value: `false` + +You can enable sequential mode using one of the following options: + +* Enable the sequential mode system property: ++ +[source] +---- +drools.sequential=true +---- + +* Enable sequential mode while creating the KIE base programmatically: ++ +[source,java] +---- +KieServices ks = KieServices.Factory.get(); +KieBaseConfiguration kieBaseConf = ks.newKieBaseConfiguration(); +kieBaseConf.setOption(SequentialOption.YES); +KieBase kieBase = kieContainer.newKieBase(kieBaseConf); +---- + +* Enable sequential mode in the KIE module descriptor file (`kmodule.xml`) for a specific {PRODUCT} project: ++ +[source,xml] +---- + + ... + + ... + + ... + +---- +-- diff --git a/assemblies/modules/decision-engine/con-rule-execution-modes.adoc b/assemblies/modules/decision-engine/con-rule-execution-modes.adoc new file mode 100644 index 0000000..c05c036 --- /dev/null +++ b/assemblies/modules/decision-engine/con-rule-execution-modes.adoc @@ -0,0 +1,108 @@ +[id='con-rule-execution-modes_{context}'] += Rule execution modes and thread safety in the {DECISION_ENGINE} + +*<@Edoardo, see this section. Not sure how we want to communicate this now. This came up a lot in 7.x so is/was a hot topic.>* + +The {DECISION_ENGINE} supports the following rule execution modes that determine how and when the {DECISION_ENGINE} executes rules: + +* *Passive mode*: (Default) The {DECISION_ENGINE} evaluates rules when a user or an application explicitly calls `fireAllRules()`. Passive mode in the {DECISION_ENGINE} is best for applications that require direct control over rule evaluation and execution, or for complex event processing (CEP) applications that use the pseudo clock implementation in the {DECISION_ENGINE}. ++ +.Example CEP application code with the {DECISION_ENGINE} in passive mode +[source,java] +---- +KieSessionConfiguration config = KieServices.Factory.get().newKieSessionConfiguration(); +config.setOption( ClockTypeOption.get("pseudo") ); +KieSession session = kbase.newKieSession( conf, null ); +SessionPseudoClock clock = session.getSessionClock(); + +session.insert( tick1 ); +session.fireAllRules(); + +clock.advanceTime(1, TimeUnit.SECONDS); +session.insert( tick2 ); +session.fireAllRules(); + +clock.advanceTime(1, TimeUnit.SECONDS); +session.insert( tick3 ); +session.fireAllRules(); + +session.dispose(); +---- + +* *Active mode*: If a user or application calls `fireUntilHalt()`, the {DECISION_ENGINE} starts in active mode and evaluates rules continually until the user or application explicitly calls `halt()`. Active mode in the {DECISION_ENGINE} is best for applications that delegate control of rule evaluation and execution to the {DECISION_ENGINE}, or for complex event processing (CEP) applications that use the real-time clock implementation in the {DECISION_ENGINE}. Active mode is also optimal for CEP applications that use active queries. ++ +-- +.Example CEP application code with the {DECISION_ENGINE} in active mode +[source,java] +---- +KieSessionConfiguration config = KieServices.Factory.get().newKieSessionConfiguration(); +config.setOption( ClockTypeOption.get("realtime") ); +KieSession session = kbase.newKieSession( conf, null ); + +new Thread( new Runnable() { + @Override + public void run() { + session.fireUntilHalt(); + } +} ).start(); + +session.insert( tick1 ); + +... Thread.sleep( 1000L ); ... + +session.insert( tick2 ); + +... Thread.sleep( 1000L ); ... + +session.insert( tick3 ); + +session.halt(); +session.dispose(); +---- + +This example calls `fireUntilHalt()` from a dedicated execution thread to prevent the current thread from being blocked indefinitely while the {DECISION_ENGINE} continues evaluating rules. The dedicated thread also enables you to call `halt()` at a later stage in the application code. +-- + +Although you should avoid using both `fireAllRules()` and `fireUntilHalt()` calls, especially from different threads, the {DECISION_ENGINE} can handle such situations safely using thread-safety logic and an internal state machine. If a `fireAllRules()` call is in progress and you call `fireUntilHalt()`, the {DECISION_ENGINE} continues to run in passive mode until the `fireAllRules()` operation is complete and then starts in active mode in response to the `fireUntilHalt()` call. However, if the {DECISION_ENGINE} is running in active mode following a `fireUntilHalt()` call and you call `fireAllRules()`, the `fireAllRules()` call is ignored and the {DECISION_ENGINE} continues to run in active mode until you call `halt()`. +ifdef::DROOLS,JBPM,OP[] +For more details about thread-safety and the internal state machine, see <<_improved_multi_threading_behaviour>>. +endif::[] + +For added thread safety in active mode, the {DECISION_ENGINE} supports a `submit()` method that you can use to group and perform operations on a KIE session in a thread-safe, atomic action: + +.Example application code with `submit()` method to perform atomic operations in active mode +[source,java] +---- +KieSession session = ...; + +new Thread( new Runnable() { + @Override + public void run() { + session.fireUntilHalt(); + } +} ).start(); + +final FactHandle fh = session.insert( fact_a ); + +... Thread.sleep( 1000L ); ... + +session.submit( new KieSession.AtomicAction() { + @Override + public void execute( KieSession kieSession ) { + fact_a.setField("value"); + kieSession.update( fh, fact_a ); + kieSession.insert( fact_1 ); + kieSession.insert( fact_2 ); + kieSession.insert( fact_3 ); + } +} ); + +... Thread.sleep( 1000L ); ... + +session.insert( fact_z ); + +session.halt(); +session.dispose(); +---- + +Thread safety and atomic operations are also helpful from a client-side perspective. For example, you might need to insert more than one fact at a given time, but require the {DECISION_ENGINE} to consider the insertions as an atomic operation and to wait until all the insertions are complete before evaluating the rules again. diff --git a/assemblies/modules/decision-engine/proc-cep-event-streams.adoc b/assemblies/modules/decision-engine/proc-cep-event-streams.adoc new file mode 100644 index 0000000..2022f6e --- /dev/null +++ b/assemblies/modules/decision-engine/proc-cep-event-streams.adoc @@ -0,0 +1,59 @@ +[id='proc-cep-event-streams_{context}'] += Declaring entry points for rule data + +You can declare an entry point (event stream) for events so that the {DECISION_ENGINE} uses data from only that entry point to evaluate the rules. You can declare an entry point either implicitly by referencing it in DRL rules or explicitly in your Java application. + +.Procedure +Use one of the following methods to declare the entry point: + +* In the DRL rule file, specify `from entry-point ""` for the inserted fact: ++ +-- +.Authorize withdrawal rule with "ATM Stream" entry point +[source] +---- +rule "Authorize withdrawal" +when + WithdrawRequest($ai : accountId, $am : amount) from entry-point "ATM Stream" + CheckingAccount(accountId == $ai, balance > $am) +then + // Authorize withdrawal. +end +---- + +.Apply fee rule with "Branch Stream" entry point +[source] +---- +rule "Apply fee on withdraws on branches" +when + WithdrawRequest($ai : accountId, processed == true) from entry-point "Branch Stream" + CheckingAccount(accountId == $ai) +then + // Apply a $2 fee on the account. +end +---- + +Both example DRL rules from a banking application insert the event `WithdrawalRequest` with the fact `CheckingAccount`, but from different entry points. At run time, the {DECISION_ENGINE} evaluates the `Authorize withdrawal` rule using data from only the `"ATM Stream"` entry point, and evaluates the `Apply fee` rule using data from only the `"Branch Stream"` entry point. Any events inserted into the `"ATM Stream"` can never match patterns for the `"Apply fee"` rule, and any events inserted into the `"Branch Stream"` can never match patterns for the `"Authorize withdrawal rule"`. +-- + +* In the Java application code, use the `getEntryPoint()` method to specify and obtain an `EntryPoint` object and insert facts into that entry point accordingly: ++ +-- +.Java application code with EntryPoint object and inserted facts +[source,java] +---- +import org.kie.api.runtime.KieSession; +import org.kie.api.runtime.rule.EntryPoint; + +// Create your KIE base and KIE session as usual. +KieSession session = ... + +// Create a reference to the entry point. +EntryPoint atmStream = session.getEntryPoint("ATM Stream"); + +// Start inserting your facts into the entry point. +atmStream.insert(aWithdrawRequest); +---- + +Any DRL rules that specify `from entry-point "ATM Stream"` are then evaluated based on the data in this entry point only. +-- diff --git a/assemblies/modules/decision-engine/proc-cep-events.adoc b/assemblies/modules/decision-engine/proc-cep-events.adoc new file mode 100644 index 0000000..73f9abe --- /dev/null +++ b/assemblies/modules/decision-engine/proc-cep-events.adoc @@ -0,0 +1,36 @@ +[id='proc-cep-events_{context}'] += Declaring facts as events + +You can declare facts as events in your Java class or DRL rule file so that the {DECISION_ENGINE} handles the facts as events during complex event processing. You can declare the facts as interval-based events or point-in-time events. Interval-based events have a duration time and persist in the working memory of the {DECISION_ENGINE} until their duration time has lapsed. Point-in-time events have no duration and are essentially interval-based events with a duration of zero. + +.Procedure +For the relevant fact type in your Java class or DRL rule file, enter the `@role( event )` metadata tag and parameter. The `@role` metadata tag accepts the following two values: + +* `fact`: (Default) Declares the type as a regular fact +* `event`: Declares the type as an event + +For example, the following snippet declares that the `StockPoint` fact type in a stock broker application must be handled as an event: + +.Declare fact type as an event +[source] +---- +import some.package.StockPoint + +declare StockPoint + @role( event ) +end +---- + +If `StockPoint` is a fact type declared in the DRL rule file instead of in a pre-existing class, you can declare the event in-line in your application code: + +.Declare fact type in-line and assign it to event role +[source] +---- +declare StockPoint + @role( event ) + + datetime : java.util.Date + symbol : String + price : double +end +---- diff --git a/assemblies/modules/decision-engine/proc-cep-sliding-windows.adoc b/assemblies/modules/decision-engine/proc-cep-sliding-windows.adoc new file mode 100644 index 0000000..1c7c088 --- /dev/null +++ b/assemblies/modules/decision-engine/proc-cep-sliding-windows.adoc @@ -0,0 +1,41 @@ +[id='proc-cep-sliding-windows_{context}'] += Declaring sliding windows for rule data + +You can declare a sliding window of time (flow of time) or length (number of occurrences) for events so that the {DECISION_ENGINE} uses data from only that window to evaluate the rules. + +.Procedure +In the DRL rule file, specify `over window:()` for the inserted fact. + +For example, the following two DRL rules activate a fire alarm based on an average temperature. However, the first rule uses a sliding time window to calculate the average over the last 10 minutes while the second rule uses a sliding length window to calculate the average over the last one hundred temperature readings. + +.Average temperature over sliding time window +[source] +---- +rule "Sound the alarm if temperature rises above threshold" +when + TemperatureThreshold($max : max) + Number(doubleValue > $max) from accumulate( + SensorReading($temp : temperature) over window:time(10m), + average($temp)) +then + // Sound the alarm. +end +---- + +.Average temperature over sliding length window +[source] +---- +rule "Sound the alarm if temperature rises above threshold" +when + TemperatureThreshold($max : max) + Number(doubleValue > $max) from accumulate( + SensorReading($temp : temperature) over window:length(100), + average($temp)) +then + // Sound the alarm. +end +---- + +The {DECISION_ENGINE} discards any `SensorReading` events that are more than 10 minutes old or that are not part of the last one hundred readings, and continues recalculating the average as the minutes or readings "slide" forward in real time. + +The {DECISION_ENGINE} does not automatically remove outdated events from the KIE session because other rules without sliding window declarations might depend on those events. The {DECISION_ENGINE} stores events in the KIE session until the events expire either by explicit rule declarations or by implicit reasoning within the {DECISION_ENGINE} based on inferred data in the KIE base. diff --git a/assemblies/modules/decision-engine/proc-logging-decision-engine.adoc b/assemblies/modules/decision-engine/proc-logging-decision-engine.adoc new file mode 100644 index 0000000..0f05540 --- /dev/null +++ b/assemblies/modules/decision-engine/proc-logging-decision-engine.adoc @@ -0,0 +1,46 @@ +[id='proc-logging-decision-engine_{context}'] += Configuring a logging utility in the {DECISION_ENGINE} + +*<@Edoardo, see this section.>* + +The {DECISION_ENGINE} uses the Java logging API SLF4J for system logging. You can use one of the following logging utilities with the {DECISION_ENGINE} to investigate {DECISION_ENGINE} activity, such as for troubleshooting or data gathering: + +* Logback +* Apache Commons Logging +* Apache Log4j +* `java.util.logging` package + +.Procedure +For the logging utility that you want to use, add the relevant dependency to your Maven project or save the relevant XML configuration file in the `org.drools` package of your {PRODUCT} distribution: + +.Example Maven dependency for Logback +[source,xml] +---- + + ch.qos.logback + logback-classic + ${logback.version} + +---- + +.Example logback.xml configuration file in org.drools package +[source,xml] +---- + + + ... + +---- + +.Example log4j.xml configuration file in org.drools package +[source,xml] +---- + + + + + ... + +---- + +NOTE: If you are developing for an ultra light environment, use the `slf4j-nop` or `slf4j-simple` logger. diff --git a/assemblies/modules/decision-engine/ref-cep-clock.adoc b/assemblies/modules/decision-engine/ref-cep-clock.adoc new file mode 100644 index 0000000..65b11e3 --- /dev/null +++ b/assemblies/modules/decision-engine/ref-cep-clock.adoc @@ -0,0 +1,78 @@ +[id='ref-cep-clock_{context}'] += Session clock implementations in the {DECISION_ENGINE} + +During complex event processing, events in the {DECISION_ENGINE} may have temporal constraints and therefore require a session clock that provides the current time. For example, if a rule needs to determine the average price of a given stock over the last 60 minutes, the {DECISION_ENGINE} must be able to compare the stock price event time stamp with the current time in the session clock. + +The {DECISION_ENGINE} supports a real-time clock and a pseudo clock. You can use one or both clock types depending on the scenario: + +* *Rules testing:* Testing requires a controlled environment, and when the tests include rules with temporal constraints, you must be able to control the input rules and facts and the flow of time. +* *Regular execution:* The {DECISION_ENGINE} reacts to events in real time and therefore requires a real-time clock. +* *Special environments:* Specific environments may have specific time control requirements. For example, clustered environments may require clock synchronization or Java Enterprise Edition (JEE) environments may require a clock provided by the application server. +* *Rules replay or simulation:* In order to replay or simulate scenarios, the application must be able to control the flow of time. + +Consider your environment requirements as you decide whether to use a real-time clock or pseudo clock in the {DECISION_ENGINE}. + +Real-time clock:: +The real-time clock is the default clock implementation in the {DECISION_ENGINE} and uses the system clock to determine the current time for time stamps. To configure the {DECISION_ENGINE} to use the real-time clock, set the KIE session configuration parameter to `realtime`: ++ +-- +.Configure real-time clock in KIE session +[source,java] +---- +import org.kie.api.KieServices.Factory; +import org.kie.api.runtime.conf.ClockTypeOption; +import org.kie.api.runtime.KieSessionConfiguration; + +KieSessionConfiguration config = KieServices.Factory.get().newKieSessionConfiguration(); + +config.setOption(ClockTypeOption.get("realtime")); +---- +-- + +Pseudo clock:: +The pseudo clock implementation in the {DECISION_ENGINE} is helpful for testing temporal rules and it can be controlled by the application. To configure the {DECISION_ENGINE} to use the pseudo clock, set the KIE session configuration parameter to `pseudo`: ++ +-- +.Configure pseudo clock in KIE session +[source,java] +---- +import org.kie.api.runtime.conf.ClockTypeOption; +import org.kie.api.runtime.KieSessionConfiguration; +import org.kie.api.KieServices.Factory; + +KieSessionConfiguration config = KieServices.Factory.get().newKieSessionConfiguration(); + +config.setOption(ClockTypeOption.get("pseudo")); +---- + +You can also use additional configurations and fact handlers to control the pseudo clock: + +.Control pseudo clock behavior in KIE session +[source,java] +---- +import java.util.concurrent.TimeUnit; + +import org.kie.api.runtime.KieSessionConfiguration; +import org.kie.api.KieServices.Factory; +import org.kie.api.runtime.KieSession; +import org.drools.core.time.SessionPseudoClock; +import org.kie.api.runtime.rule.FactHandle; +import org.kie.api.runtime.conf.ClockTypeOption; + +KieSessionConfiguration conf = KieServices.Factory.get().newKieSessionConfiguration(); + +conf.setOption( ClockTypeOption.get("pseudo")); +KieSession session = kbase.newKieSession(conf, null); + +SessionPseudoClock clock = session.getSessionClock(); + +// While inserting facts, advance the clock as necessary. +FactHandle handle1 = session.insert(tick1); +clock.advanceTime(10, TimeUnit.SECONDS); + +FactHandle handle2 = session.insert(tick2); +clock.advanceTime(30, TimeUnit.SECONDS); + +FactHandle handle3 = session.insert(tick3); +---- +-- diff --git a/assemblies/modules/decision-engine/ref-cep-temporal-operators.adoc b/assemblies/modules/decision-engine/ref-cep-temporal-operators.adoc new file mode 100644 index 0000000..3c9ffcb --- /dev/null +++ b/assemblies/modules/decision-engine/ref-cep-temporal-operators.adoc @@ -0,0 +1,456 @@ +[id='ref-cep-temporal-operators_{context}'] += Temporal operators for events + +In stream mode, the {DECISION_ENGINE} supports the following temporal operators for events that are inserted into the working memory of the {DECISION_ENGINE}. You can use these operators to define the temporal reasoning behavior of the events that you declare in your Java class or DRL rule file. Temporal operators are not supported when the {DECISION_ENGINE} is running in cloud mode. + +* `after` +* `before` +* `coincides` +* `during` +* `includes` +* `finishes` +* `finished by` +* `meets` +* `met by` +* `overlaps` +* `overlapped by` +* `starts` +* `started by` + +after:: ++ +-- +This operator specifies if the current event occurs after the correlated event. This operator can also define an amount of time after which the current event can follow the correlated event, or a delimiting time range during which the current event can follow the correlated event. + +For example, the following pattern matches if `$eventA` starts between 3 minutes and 30 seconds and 4 minutes after `$eventB` finishes. If `$eventA` starts earlier than 3 minutes and 30 seconds after `$eventB` finishes, or later than 4 minutes after `$eventB` finishes, then the pattern is not matched. + +[source] +---- +$eventA : EventA(this after[3m30s, 4m] $eventB) +---- + +You can also express this operator in the following way: + +[source] +---- +3m30s <= $eventA.startTimestamp - $eventB.endTimeStamp <= 4m +---- + +The `after` operator supports up to two parameter values: + +* If two values are defined, the interval starts on the first value (3 minutes and 30 seconds in the example) and ends on the second value (4 minutes in the example). +* If only one value is defined, the interval starts on the provided value and runs indefinitely with no end time. +* If no value is defined, the interval starts at 1 millisecond and runs indefinitely with no end time. + +The `after` operator also supports negative time ranges: + +[source] +---- +$eventA : EventA(this after[-3m30s, -2m] $eventB) +---- + +If the first value is greater than the second value, the {DECISION_ENGINE} automatically reverses them. For example, the following two patterns are interpreted by the {DECISION_ENGINE} in the same way: + +[source] +---- +$eventA : EventA(this after[-3m30s, -2m] $eventB) +$eventA : EventA(this after[-2m, -3m30s] $eventB) +---- +-- + +before:: +This operator specifies if the current event occurs before the correlated event. This operator can also define an amount of time before which the current event can precede the correlated event, or a delimiting time range during which the current event can precede the correlated event. ++ +-- +For example, the following pattern matches if `$eventA` finishes between 3 minutes and 30 seconds and 4 minutes before `$eventB` starts. If `$eventA` finishes earlier than 3 minutes and 30 seconds before `$eventB` starts, or later than 4 minutes before `$eventB` starts, then the pattern is not matched. + +[source] +---- +$eventA : EventA(this before[3m30s, 4m] $eventB) +---- + +You can also express this operator in the following way: + +[source] +---- +3m30s <= $eventB.startTimestamp - $eventA.endTimeStamp <= 4m +---- + +The `before` operator supports up to two parameter values: + +* If two values are defined, the interval starts on the first value (3 minutes and 30 seconds in the example) and ends on the second value (4 minutes in the example). +* If only one value is defined, the interval starts on the provided value and runs indefinitely with no end time. +* If no value is defined, the interval starts at 1 millisecond and runs indefinitely with no end time. + +The `before` operator also supports negative time ranges: + +[source] +---- +$eventA : EventA(this before[-3m30s, -2m] $eventB) +---- + +If the first value is greater than the second value, the {DECISION_ENGINE} automatically reverses them. For example, the following two patterns are interpreted by the {DECISION_ENGINE} in the same way: + +[source] +---- +$eventA : EventA(this before[-3m30s, -2m] $eventB) +$eventA : EventA(this before[-2m, -3m30s] $eventB) +---- +-- + +coincides:: +This operator specifies if the two events occur at the same time, with the same start and end times. ++ +-- +For example, the following pattern matches if both the start and end time stamps of `$eventA` and `$eventB` are identical: + +[source] +---- +$eventA : EventA(this coincides $eventB) +---- + +The `coincides` operator supports up to two parameter values for the distance between the event start and end times, if they are not identical: + +* If only one parameter is given, the parameter is used to set the threshold for both the start and end times of both events. +* If two parameters are given, the first is used as a threshold for the start time and the second is used as a threshold for the end time. + +The following pattern uses start and end time thresholds: + +[source] +---- +$eventA : EventA(this coincides[15s, 10s] $eventB) +---- + +The pattern matches if the following conditions are met: + +[source] +---- +abs($eventA.startTimestamp - $eventB.startTimestamp) <= 15s +&& +abs($eventA.endTimestamp - $eventB.endTimestamp) <= 10s +---- + +WARNING: The {DECISION_ENGINE} does not support negative intervals for the `coincides` operator. If you use negative intervals, the {DECISION_ENGINE} generates an error. + +-- + +during:: +This operator specifies if the current event occurs within the time frame of when the correlated event starts and ends. The current event must start after the correlated event starts and must end before the correlated event ends. (With the `coincides` operator, the start and end times are the same or nearly the same.) ++ +-- +For example, the following pattern matches if `$eventA` starts after `$eventB` starts and ends before `$eventB` ends: + +[source] +---- +$eventA : EventA(this during $eventB) +---- + +You can also express this operator in the following way: + +[source] +---- +$eventB.startTimestamp < $eventA.startTimestamp <= $eventA.endTimestamp < $eventB.endTimestamp +---- + +The `during` operator supports one, two, or four optional parameters: + +* If one value is defined, this value is the maximum distance between the start times of the two events and the maximum distance between the end times of the two events. +* If two values are defined, these values are a threshold between which the current event start time and end time must occur in relation to the correlated event start and end times. ++ +For example, if the values are `5s` and `10s`, the current event must start between 5 and 10 seconds after the correlated event starts and must end between 5 and 10 seconds before the correlated event ends. +* If four values are defined, the first and second values are the minimum and maximum distances between the start times of the events, and the third and fourth values are the minimum and maximum distances between the end times of the two events. +-- + +includes:: +This operator specifies if the correlated event occurs within the time frame of when the current event occurs. The correlated event must start after the current event starts and must end before the current event ends. (The behavior of this operator is the reverse of the `during` operator behavior.) ++ +-- +For example, the following pattern matches if `$eventB` starts after `$eventA` starts and ends before `$eventA` ends: + +[source] +---- +$eventA : EventA(this includes $eventB) +---- + +You can also express this operator in the following way: + +[source] +---- +$eventA.startTimestamp < $eventB.startTimestamp <= $eventB.endTimestamp < $eventA.endTimestamp +---- + +The `includes` operator supports one, two, or four optional parameters: + +* If one value is defined, this value is the maximum distance between the start times of the two events and the maximum distance between the end times of the two events. +* If two values are defined, these values are a threshold between which the correlated event start time and end time must occur in relation to the current event start and end times. ++ +For example, if the values are `5s` and `10s`, the correlated event must start between 5 and 10 seconds after the current event starts and must end between 5 and 10 seconds before the current event ends. +* If four values are defined, the first and second values are the minimum and maximum distances between the start times of the events, and the third and fourth values are the minimum and maximum distances between the end times of the two events. +-- + +finishes:: ++ +-- +This operator specifies if the current event starts after the correlated event but both events end at the same time. + +For example, the following pattern matches if `$eventA` starts after `$eventB` starts and ends at the same time when `$eventB` ends: + +[source] +---- +$eventA : EventA(this finishes $eventB) +---- + +You can also express this operator in the following way: + +[source] +---- +$eventB.startTimestamp < $eventA.startTimestamp +&& +$eventA.endTimestamp == $eventB.endTimestamp +---- + +The `finishes` operator supports one optional parameter that sets the maximum time allowed between the end times of the two events: + +[source] +---- +$eventA : EventA(this finishes[5s] $eventB) +---- + +This pattern matches if these conditions are met: + +[source] +---- +$eventB.startTimestamp < $eventA.startTimestamp +&& +abs($eventA.endTimestamp - $eventB.endTimestamp) <= 5s +---- + +WARNING: The {DECISION_ENGINE} does not support negative intervals for the `finishes` operator. If you use negative intervals, the {DECISION_ENGINE} generates an error. + +-- + +finished by:: +This operator specifies if the correlated event starts after the current event but both events end at the same time. (The behavior of this operator is the reverse of the `finishes` operator behavior.) ++ +-- +For example, the following pattern matches if `$eventB` starts after `$eventA` starts and ends at the same time when `$eventA` ends: + +[source] +---- +$eventA : EventA(this finishedby $eventB) +---- + +You can also express this operator in the following way: + +[source] +---- +$eventA.startTimestamp < $eventB.startTimestamp +&& +$eventA.endTimestamp == $eventB.endTimestamp +---- + +The `finished by` operator supports one optional parameter that sets the maximum time allowed between the end times of the two events: + +[source] +---- +$eventA : EventA(this finishedby[5s] $eventB) +---- + +This pattern matches if these conditions are met: + +[source] +---- +$eventA.startTimestamp < $eventB.startTimestamp +&& +abs($eventA.endTimestamp - $eventB.endTimestamp) <= 5s +---- + +WARNING: The {DECISION_ENGINE} does not support negative intervals for the `finished by` operator. If you use negative intervals, the {DECISION_ENGINE} generates an error. + +-- + +meets:: +This operator specifies if the current event ends at the same time when the correlated event starts. ++ +-- +For example, the following pattern matches if `$eventA` ends at the same time when `$eventB` starts: + +[source] +---- +$eventA : EventA(this meets $eventB) +---- + +You can also express this operator in the following way: + +[source] +---- +abs($eventB.startTimestamp - $eventA.endTimestamp) == 0 +---- + +The `meets` operator supports one optional parameter that sets the maximum time allowed between the end time of the current event and the start time of the correlated event: + +[source] +---- +$eventA : EventA(this meets[5s] $eventB) +---- + +This pattern matches if these conditions are met: + +[source] +---- +abs($eventB.startTimestamp - $eventA.endTimestamp) <= 5s +---- + +WARNING: The {DECISION_ENGINE} does not support negative intervals for the `meets` operator. If you use negative intervals, the {DECISION_ENGINE} generates an error. + +-- + +met by:: +This operator specifies if the correlated event ends at the same time when the current event starts. (The behavior of this operator is the reverse of the `meets` operator behavior.) ++ +-- +For example, the following pattern matches if `$eventB` ends at the same time when `$eventA` starts: + +[source] +---- +$eventA : EventA(this metby $eventB) +---- + +You can also express this operator in the following way: + +[source] +---- +abs($eventA.startTimestamp - $eventB.endTimestamp) == 0 +---- + +The `met by` operator supports one optional parameter that sets the maximum distance between the end time of the correlated event and the start time of the current event: + +[source] +---- +$eventA : EventA(this metby[5s] $eventB) +---- + +This pattern matches if these conditions are met: + +[source] +---- +abs($eventA.startTimestamp - $eventB.endTimestamp) <= 5s +---- + +WARNING: The {DECISION_ENGINE} does not support negative intervals for the `met by` operator. If you use negative intervals, the {DECISION_ENGINE} generates an error. + +-- + +overlaps:: +This operator specifies if the current event starts before the correlated event starts and it ends during the time frame that the correlated event occurs. The current event must end between the start and end times of the correlated event. ++ +-- +For example, the following pattern matches if `$eventA` starts before `$eventB` starts and then ends while `$eventB` occurs, before `$eventB` ends: + +[source] +---- +$eventA : EventA(this overlaps $eventB) +---- + +The `overlaps` operator supports up to two parameters: + +* If one parameter is defined, the value is the maximum distance between the start time of the correlated event and the end time of the current event. +* If two parameters are defined, the values are the minimum distance (first value) and the maximum distance (second value) between the start time of the correlated event and the end time of the current event. +-- + +overlapped by:: +This operator specifies if the correlated event starts before the current event starts and it ends during the time frame that the current event occurs. The correlated event must end between the start and end times of the current event. (The behavior of this operator is the reverse of the `overlaps` operator behavior.) ++ +-- +For example, the following pattern matches if `$eventB` starts before `$eventA` starts and then ends while `$eventA` occurs, before `$eventA` ends: + +[source] +---- +$eventA : EventA(this overlappedby $eventB) +---- + +The `overlapped by` operator supports up to two parameters: + +* If one parameter is defined, the value is the maximum distance between the start time of the current event and the end time of the correlated event. +* If two parameters are defined, the values are the minimum distance (first value) and the maximum distance (second value) between the start time of the current event and the end time of the correlated event. +-- + +starts:: +This operator specifies if the two events start at the same time but the current event ends before the correlated event ends. ++ +-- +For example, the following pattern matches if `$eventA` and `$eventB` start at the same time, and `$eventA` ends before `$eventB` ends: + +[source] +---- +$eventA : EventA(this starts $eventB) +---- + +You can also express this operator in the following way: + +[source] +---- +$eventA.startTimestamp == $eventB.startTimestamp +&& +$eventA.endTimestamp < $eventB.endTimestamp +---- + +The `starts` operator supports one optional parameter that sets the maximum distance between the start times of the two events: + +[source] +---- +$eventA : EventA(this starts[5s] $eventB) +---- + +This pattern matches if these conditions are met: + +[source] +---- +abs($eventA.startTimestamp - $eventB.startTimestamp) <= 5s +&& +$eventA.endTimestamp < $eventB.endTimestamp +---- + +WARNING: The {DECISION_ENGINE} does not support negative intervals for the `starts` operator. If you use negative intervals, the {DECISION_ENGINE} generates an error. + +-- + +started by:: +This operator specifies if the two events start at the same time but the correlated event ends before the current event ends. (The behavior of this operator is the reverse of the `starts` operator behavior.) ++ +-- +For example, the following pattern matches if `$eventA` and `$eventB` start at the same time, and `$eventB` ends before `$eventA` ends: + +[source] +---- +$eventA : EventA(this startedby $eventB) +---- + +You can also express this operator in the following way: + +[source] +---- +$eventA.startTimestamp == $eventB.startTimestamp +&& +$eventA.endTimestamp > $eventB.endTimestamp +---- + +The `started by` operator supports one optional parameter that sets the maximum distance between the start times of the two events: + +[source] +---- +$eventA : EventA( this starts[5s] $eventB) +---- + +This pattern matches if these conditions are met: + +[source] +---- +abs( $eventA.startTimestamp - $eventB.startTimestamp ) <= 5s +&& +$eventA.endTimestamp > $eventB.endTimestamp +---- + +WARNING: The {DECISION_ENGINE} does not support negative intervals for the `started by` operator. If you use negative intervals, the {DECISION_ENGINE} generates an error. + +-- diff --git a/assemblies/modules/decision-engine/ref-performance-tuning-decision-engine.adoc b/assemblies/modules/decision-engine/ref-performance-tuning-decision-engine.adoc new file mode 100644 index 0000000..f4baf56 --- /dev/null +++ b/assemblies/modules/decision-engine/ref-performance-tuning-decision-engine.adoc @@ -0,0 +1,37 @@ +[id='ref-performance-tuning-decision-engine_{context}'] += Performance tuning considerations with the {DECISION_ENGINE} + +The following key concepts or suggested practices can help you optimize {DECISION_ENGINE} performance. These concepts are summarized in this section as a convenience and are explained in more detail in the cross-referenced documentation, where applicable. This section will expand or change as needed with new releases of {PRODUCT}. + +Use sequential mode for stateless KIE sessions that do not require important {DECISION_ENGINE} updates:: +Sequential mode is an advanced rule base configuration in the {DECISION_ENGINE} that enables the {DECISION_ENGINE} to evaluate rules one time in the order that they are listed in the {DECISION_ENGINE} agenda without regard to changes in the working memory. As a result, rule execution may be faster in sequential mode, but important updates may not be applied to your rules. Sequential mode applies to stateless KIE sessions only. ++ +-- +To enable sequential mode, set the system property `drools.sequential` to `true`. + +For more information about sequential mode or other options for enabling it, see xref:con-phreak-sequential-mode_decision-engine[]. +-- + +Use simple operations with event listeners:: +Limit the number of event listeners and the type of operations they perform. Use event listeners for simple operations, such as debug logging and setting properties. Complicated operations, such as network calls, in listeners can impede rule execution. After you finish working with a KIE session, remove the attached event listeners so that the session can be cleaned, as shown in the following example: ++ +-- +.Example event listener removed after use +[source,java] +---- +Listener listener = ...; +StatelessKnowledgeSession ksession = createSession(); +try { + ksession.insert(fact); + ksession.fireAllRules(); + ... +} finally { + if (session != null) { + ksession.detachListener(listener); + ksession.dispose(); + } +} +---- + +For information about built-in event listeners and debug logging in the {DECISION_ENGINE}, see xref:con-engine-event-listeners_decision-engine[]. +-- diff --git a/assemblies/modules/decision-services/con-decision-tables-use-case.adoc b/assemblies/modules/decision-services/con-decision-tables-use-case.adoc new file mode 100644 index 0000000..4b8922b --- /dev/null +++ b/assemblies/modules/decision-services/con-decision-tables-use-case.adoc @@ -0,0 +1,96 @@ +[id='con-decision-tables-use-case_{context}'] += Decision table use case + +An online shopping site lists the shipping charges for ordered items. The site provides free shipping under the following conditions: + +* The number of items ordered is 4 or more and the checkout total is $300 or more. +* Standard shipping is selected (4 or 5 business days from the date of purchase). + +The following are the shipping rates under these conditions: + +.For orders less than $300 +[cols="1,1,1", options="header"] +|=== +|Number of items +|Delivery day +|Shipping charge in USD, N = Number of items + +|3 or fewer + +a| +Next day + +2nd day + +Standard + +a| +35 + +15 + +10 + +|4 or more + +a| +Next day + +2nd day + +Standard + +a| +N*7.50 + +N*3.50 + +N*2.50 +|=== + +.For orders more than $300 +[cols="1,1,1", options="header"] +|=== +|Number of items +|Delivery day +|Shipping charge in USD, N = Number of items + +|3 or fewer + +a| +Next day + +2nd day + +Standard + +a| +25 + +10 + +N*1.50 + +|4 or more + +a| +Next day + +2nd day + +Standard + +a| +N*5 + +N*2 + +FREE +|=== + +These conditions and rates are shown in the following example spreadsheet decision table: + +.Decision table for shipping charges +image::kogito/decision-tables/decision-table-example-02.png[Decision table example] + +In order for a decision table to be compiled in your {PRODUCT} project, the table must comply with certain structure and syntax requirements within an XLS or XLSX spreadsheet, as shown in this example. For more information, see xref:proc-decision-tables-creating_decision-tables[]. diff --git a/assemblies/modules/decision-services/con-decision-tables.adoc b/assemblies/modules/decision-services/con-decision-tables.adoc new file mode 100644 index 0000000..4faaf1b --- /dev/null +++ b/assemblies/modules/decision-services/con-decision-tables.adoc @@ -0,0 +1,4 @@ +[id='con-decision-tables_{context}'] += Spreadsheet decision tables + +Spreadsheet decision tables are XLS or XLSX spreadsheet files that contain business rules defined in a tabular format. You can include spreadsheet decision tables as part of your {PRODUCT} project. Each row in a decision table is a rule, and each column is a condition, an action, or another rule attribute. After you create and include your spreadsheet decision tables in your project, the rules you defined are compiled into Drools Rule Language (DRL) rules for the decision service. diff --git a/assemblies/modules/decision-services/con-dmn-boxed-expressions.adoc b/assemblies/modules/decision-services/con-dmn-boxed-expressions.adoc new file mode 100644 index 0000000..d9dc836 --- /dev/null +++ b/assemblies/modules/decision-services/con-dmn-boxed-expressions.adoc @@ -0,0 +1,16 @@ +[id='con-dmn-boxed-expressions_{context}'] += DMN decision logic in boxed expressions + +Boxed expressions in DMN are tables that you use to define the underlying logic of decision nodes and business knowledge models in a decision requirements diagram (DRD) or decision requirements graph (DRG). Some boxed expressions can contain other boxed expressions, but the top-level boxed expression corresponds to the decision logic of a single DRD artifact. While DRDs with one or more DRGs represent the flow of a DMN decision model, boxed expressions define the actual decision logic of individual nodes. DRDs and boxed expressions together form a complete and functional DMN decision model. + +The following are the types of DMN boxed expressions: + +* Decision tables +* Literal expressions +* Contexts +* Relations +* Functions +* Invocations +* Lists + +All Friendly Enough Expression Language (FEEL) expressions that you use in your boxed expressions must conform to the FEEL syntax requirements in the OMG https://www.omg.org/spec/DMN[Decision Model and Notation specification]. diff --git a/assemblies/modules/decision-services/con-dmn-conformance-levels.adoc b/assemblies/modules/decision-services/con-dmn-conformance-levels.adoc new file mode 100644 index 0000000..2ae530f --- /dev/null +++ b/assemblies/modules/decision-services/con-dmn-conformance-levels.adoc @@ -0,0 +1,17 @@ +[id='con-dmn-conformance-levels_{context}'] += DMN conformance levels + +The DMN specification defines three incremental levels of conformance in a software implementation. A product that claims compliance at one level must also be compliant with any preceding levels. For example, a conformance level 3 implementation must also include the supported components in conformance levels 1 and 2. For the formal definitions of each conformance level, see the OMG https://www.omg.org/spec/DMN[Decision Model and Notation specification]. + +The following list summarizes the three DMN conformance levels: + +Conformance level 1:: +A DMN conformance level 1 implementation supports decision requirement diagrams (DRDs), decision logic, and decision tables, but decision models are not executable. Any language can be used to define the expressions, including natural, unstructured languages. + +Conformance level 2:: +A DMN conformance level 2 implementation includes the requirements in conformance level 1, and supports Simplified Friendly Enough Expression Language (S-FEEL) expressions and fully executable decision models. + +Conformance level 3:: +A DMN conformance level 3 implementation includes the requirements in conformance levels 1 and 2, and supports Friendly Enough Expression Language (FEEL) expressions, the full set of boxed expressions, and fully executable decision models. + +{PRODUCT} provides design and runtime support for DMN 1.2 models at conformance level 3, and runtime-only support for DMN 1.1 and 1.3 models at conformance level 3. You can design your DMN models with the {PRODUCT} DMN modeler in VSCode or import existing DMN models into your {PRODUCT} projects for deployment and execution. Any DMN 1.1 models that you import into your {PRODUCT} project, open in the DMN modeler, and save are converted to DMN 1.2 models. DMN 1.3 models are not supported in the {PRODUCT} DMN modeler. diff --git a/assemblies/modules/decision-services/con-dmn-context-expressions.adoc b/assemblies/modules/decision-services/con-dmn-context-expressions.adoc new file mode 100644 index 0000000..1eac375 --- /dev/null +++ b/assemblies/modules/decision-services/con-dmn-context-expressions.adoc @@ -0,0 +1,14 @@ +[id='con-dmn-context-expressions_{context}'] += Boxed context expressions + +A boxed context expression in DMN is a set of variable names and values with a result value. Each name-value pair is a context entry. You use context expressions to represent data definitions in decision logic and set a value for a desired decision element within the DMN decision model. A value in a boxed context expression can be a data type value or FEEL expression, or can contain a nested sub-expression of any type, such as a decision table, a literal expression, or another context expression. + +For example, the following boxed context expression defines the factors for sorting delayed passengers in a flight-rebooking decision model, based on defined data types (`tPassengerTable`, `tFlightNumberList`): + +.Boxed context expression for flight passenger waiting list +image::kogito/dmn/dmn-context-expression-example.png[] + +The following boxed context expression defines the factors that determine whether a loan applicant can meet minimum mortgage payments based on principal, interest, taxes, and insurance (PITI), represented as a front-end ratio calculation with a sub-context expression: + +.Boxed context expression for front-end client PITI ratio +image::kogito/dmn/dmn-context-expression-example2.png[] diff --git a/assemblies/modules/decision-services/con-dmn-decision-tables-hit-policies.adoc b/assemblies/modules/decision-services/con-dmn-decision-tables-hit-policies.adoc new file mode 100644 index 0000000..976cd54 --- /dev/null +++ b/assemblies/modules/decision-services/con-dmn-decision-tables-hit-policies.adoc @@ -0,0 +1,17 @@ +[id='con-dmn-decision-tables-hit-policies_{context}'] += Hit policies in DMN decision tables + +Hit policies determine how to reach an outcome when multiple rules in a decision table match the provided input values. For example, if one rule in a decision table applies a sales discount to military personnel and another rule applies a discount to students, then when a customer is both a student and in the military, the decision table hit policy must indicate whether to apply one discount or the other (*Unique*, *First*) or both discounts (*Collect Sum*). You specify the single character of the hit policy (*U*, *F*, *C+*) in the upper-left corner of the decision table. + +The following decision table hit policies are supported in DMN: + +* *Unique (U):* Permits only one rule to match. Any overlap raises an error. +* *Any (A):* Permits multiple rules to match, but they must all have the same output. If multiple matching rules do not have the same output, an error is raised. +* *Priority (P):* Permits multiple rules to match, with different outputs. The output that comes first in the output values list is selected. +* *First (F):* Uses the first match in rule order. +* *Collect (C+, C>, C<, C#):* Aggregates output from multiple rules based on an aggregation function. +** *Collect ( C ):* Aggregates values in an arbitrary list. +** *Collect Sum (C+):* Outputs the sum of all collected values. Values must be numeric. +** *Collect Min (C<):* Outputs the minimum value among the matches. The resulting values must be comparable, such as numbers, dates, or text (lexicographic order). +** *Collect Max (C>):* Outputs the maximum value among the matches. The resulting values must be comparable, such as numbers, dates or text (lexicographic order). +** *Collect Count (C#):* Outputs the number of matching rules. diff --git a/assemblies/modules/decision-services/con-dmn-decision-tables.adoc b/assemblies/modules/decision-services/con-dmn-decision-tables.adoc new file mode 100644 index 0000000..0a8ecba --- /dev/null +++ b/assemblies/modules/decision-services/con-dmn-decision-tables.adoc @@ -0,0 +1,23 @@ +[id='con-dmn-decision-tables_{context}'] += DMN decision tables + +A decision table in DMN is a visual representation of one or more business rules in a tabular format. You use decision tables to define rules for a decision node that applies those rules at a given point in the decision model. Each rule consists of a single row in the table, and includes columns that define the conditions (input) and outcome (output) for that particular row. The definition of each row is precise enough to derive the outcome using the values of the conditions. Input and output values can be FEEL expressions or defined data type values. + +For example, the following decision table determines credit score ratings based on a defined range of a loan applicant's credit score: + +.Decision table for credit score rating +image::kogito/dmn/dmn-decision-table-example.png[] + +The following decision table determines the next step in a lending strategy for applicants depending on applicant loan eligibility and the bureau call type: + +.Decision table for lending strategy +image::kogito/dmn/dmn-decision-table-example2.png[] + +The following decision table determines applicant qualification for a loan as the concluding decision node in a loan prequalification decision model: + +.Decision table for loan prequalification +image::kogito/dmn/dmn-decision-table-example3.png[] + +Decision tables are a popular way of modeling rules and decision logic, and are used in many methodologies (such as DMN) and implementation frameworks (such as Drools). + +IMPORTANT: {PRODUCT} supports both DMN decision tables and Drools-native decision tables, but they are different types of assets with different syntax requirements and are not interchangeable. For more information about Drools-native decision tables in {PRODUCT}, see xref:con-decision-tables_decision-tables[]. diff --git a/assemblies/modules/decision-services/con-dmn-documentation.adoc b/assemblies/modules/decision-services/con-dmn-documentation.adoc new file mode 100644 index 0000000..732a81e --- /dev/null +++ b/assemblies/modules/decision-services/con-dmn-documentation.adoc @@ -0,0 +1,7 @@ +[id='con-dmn-documentation_{context}'] += DMN model documentation in the {PRODUCT} DMN modeler + +In the {PRODUCT} DMN modeler, you can use the *Documentation* tab to generate a report of your DMN model. The DMN model report contains all decision requirements diagrams (DRDs), data types, and boxed expressions in your DMN model. You can use this report to share your DMN model details or as part of your internal reporting workflow. + +.Example DMN model report +image::kogito/dmn/dmn-documentation.png[] diff --git a/assemblies/modules/decision-services/con-dmn-execution.adoc b/assemblies/modules/decision-services/con-dmn-execution.adoc new file mode 100644 index 0000000..ed94376 --- /dev/null +++ b/assemblies/modules/decision-services/con-dmn-execution.adoc @@ -0,0 +1,18 @@ +[id='con-dmn-execution_{context}'] += DMN model execution + +You can create or import DMN files in your {PRODUCT} project using {CENTRAL} or package the DMN files as part of your project knowledge JAR (KJAR) file without {CENTRAL}. After you implement your DMN files in your {PRODUCT} project, you can execute the DMN decision service by deploying the KIE container that contains it to {KIE_SERVER} for remote access +ifeval::["{context}" == "decision-service-getting-started"] +and interacting with the container using the {KIE_SERVER} REST API. +endif::[] +ifeval::["{context}" == "kogito-dmn-models"] +or by manipulating the KIE container directly as a dependency of the calling application. Other options for creating and deploying DMN knowledge packages are also available, and most are similar for all types of knowledge assets, such as DRL files or process definitions. +endif::[] + +For information about including external DMN assets with your project packaging and deployment method, see +ifdef::DM,PAM[] +{URL_PACKAGING_DEPLOYING_PROJECT}[_{PACKAGING_DEPLOYING_PROJECT}_]. +endif::[] +ifdef::DROOLS,JBPM,OP[] +<<_builddeployutilizeandrunsection>>. +endif::[] diff --git a/assemblies/modules/decision-services/con-dmn-feel.adoc b/assemblies/modules/decision-services/con-dmn-feel.adoc new file mode 100644 index 0000000..646810c --- /dev/null +++ b/assemblies/modules/decision-services/con-dmn-feel.adoc @@ -0,0 +1,6 @@ +[id='con-dmn-feel_{context}'] += Rule expressions in FEEL + +Friendly Enough Expression Language (FEEL) is an expression language defined by the Object Management Group (OMG) DMN specification. FEEL expressions define the logic of a decision in a DMN model. FEEL is designed to facilitate both decision modeling and execution by assigning semantics to the decision model constructs. FEEL expressions in decision requirements diagrams (DRDs) occupy table cells in boxed expressions for decision nodes and business knowledge models. + +For more information about FEEL in DMN, see the OMG https://www.omg.org/spec/DMN[Decision Model and Notation specification]. diff --git a/assemblies/modules/decision-services/con-dmn-function-expressions.adoc b/assemblies/modules/decision-services/con-dmn-function-expressions.adoc new file mode 100644 index 0000000..66e1d04 --- /dev/null +++ b/assemblies/modules/decision-services/con-dmn-function-expressions.adoc @@ -0,0 +1,26 @@ +[id='con-dmn-function-expressions_{context}'] += Boxed function expressions + +A boxed function expression in DMN is a parameterized boxed expression containing a literal FEEL expression, a nested context expression of an external JAVA or PMML function, or a nested boxed expression of any type. By default, all business knowledge models are defined as boxed function expressions. You use boxed function expressions to call functions on your decision logic and to define all business knowledge models. + +For example, the following boxed function expression determines airline flight capacity in a flight-rebooking decision model: + +.Boxed function expression for flight capacity +image::kogito/dmn/dmn-function-expression-example.png[] + +The following boxed function expression contains a basic Java function as a context expression for determining absolute value in a decision model calculation: + +.Boxed function expression for absolute value +image::kogito/dmn/dmn-function-expression-example2.png[] + +The following boxed function expression determines a monthly mortgage installment as a business knowledge model in a lending decision, with the function value defined as a nested context expression: + +.Boxed function expression for installment calculation in business knowledge model +image::kogito/dmn/dmn-function-expression-example3.png[] + +The following boxed function expression uses a PMML model included in the DMN file to define the minimum acceptable PITI calculation (principal, interest, taxes, and insurance) in a lending decision: +//// +//@comment: Excluding until included models is supported in Kogito (Stetson, 5 Mar 2020) +.Boxed function expression with an included PMML model in business knowledge model +image::kogito/dmn/dmn-function-expression-example5.png[] +//// diff --git a/assemblies/modules/decision-services/con-dmn-included-models.adoc b/assemblies/modules/decision-services/con-dmn-included-models.adoc new file mode 100644 index 0000000..d1c07fe --- /dev/null +++ b/assemblies/modules/decision-services/con-dmn-included-models.adoc @@ -0,0 +1,8 @@ +//@comment: Not yet applicable for Kogito. (Stetson, 5 March 2020) + +[id='con-dmn-included-models-con-{context}'] += Included models in DMN files in {CENTRAL} + +In the DMN modeler in {CENTRAL}, you can use the *Included Models* tab to include other DMN models and Predictive Model Markup Language (PMML) models from your project in a specified DMN file. When you include a DMN model within another DMN file, you can use all of the nodes and logic from both models in the same decision requirements diagram (DRD). When you include a PMML model within a DMN file, you can invoke that PMML model as a boxed function expression for a DMN decision node or business knowledge model node. + +You cannot include DMN or PMML models from other projects in {CENTRAL}. diff --git a/assemblies/modules/decision-services/con-dmn-invocation-expressions.adoc b/assemblies/modules/decision-services/con-dmn-invocation-expressions.adoc new file mode 100644 index 0000000..100b9ae --- /dev/null +++ b/assemblies/modules/decision-services/con-dmn-invocation-expressions.adoc @@ -0,0 +1,14 @@ +[id='con-dmn-invocation-expressions_{context}'] += Boxed invocation expressions + +A boxed invocation expression in DMN is a boxed expression that invokes a business knowledge model. A boxed invocation expression contains the name of the business knowledge model to be invoked and a list of parameter bindings. Each binding is represented by two boxed expressions on a row: The box on the left contains the name of a parameter and the box on the right contains the binding expression whose value is assigned to the parameter to evaluate the invoked business knowledge model. You use boxed invocations to invoke at a particular decision node a business knowledge model defined in the decision model. + +For example, the following boxed invocation expression invokes a `Reassign Next Passenger` business knowledge model as the concluding decision node in a flight-rebooking decision model: + +.Boxed invocation expression to reassign flight passengers +image::kogito/dmn/dmn-invocation-example.png[] + +The following boxed invocation expression invokes an `InstallmentCalculation` business knowledge model to calculate a monthly installment amount for a loan before proceeding to affordability decisions: + +.Boxed invocation expression for required monthly installment +image::kogito/dmn/dmn-invocation-example2.png[] diff --git a/assemblies/modules/decision-services/con-dmn-list-expressions.adoc b/assemblies/modules/decision-services/con-dmn-list-expressions.adoc new file mode 100644 index 0000000..3da859a --- /dev/null +++ b/assemblies/modules/decision-services/con-dmn-list-expressions.adoc @@ -0,0 +1,16 @@ +[id='con-dmn-list-expressions_{context}'] += Boxed list expressions + +A boxed list expression in DMN represents a FEEL list of items. You use boxed lists to define lists of relevant items for a particular node in a decision. You can also use literal FEEL expressions for list items in cells to create more complex lists. + +For example, the following boxed list expression identifies approved credit score agencies in a loan application decision service: + +.Boxed list expression for approved credit score agencies +image::kogito/dmn/dmn-list-expression-example.png[] + +The following boxed list expression also identifies approved credit score agencies but uses FEEL logic to define the agency status (Inc., LLC, SA, GA) based on a DMN input node: + +.Boxed list expression using FEEL logic for approved credit score agency status +image::kogito/dmn/dmn-list-expression-example2.png[] + +image::kogito/dmn/dmn-list-expression-example2a.png[] diff --git a/assemblies/modules/decision-services/con-dmn-literal-expressions.adoc b/assemblies/modules/decision-services/con-dmn-literal-expressions.adoc new file mode 100644 index 0000000..33f076e --- /dev/null +++ b/assemblies/modules/decision-services/con-dmn-literal-expressions.adoc @@ -0,0 +1,14 @@ +[id='con-dmn-literal-expressions_{context}'] += Boxed literal expressions + +A boxed literal expression in DMN is a literal FEEL expression as text in a table cell, typically with a labeled column and an assigned data type. You use boxed literal expressions to define simple or complex node logic or decision data directly in FEEL for a particular node in a decision. Literal FEEL expressions must conform to FEEL syntax requirements in the OMG https://www.omg.org/spec/DMN[Decision Model and Notation specification]. + +For example, the following boxed literal expression defines the minimum acceptable PITI calculation (principal, interest, taxes, and insurance) in a lending decision, where `acceptable rate` is a variable defined in the DMN model: + +.Boxed literal expression for minimum PITI value +image::kogito/dmn/dmn-literal-expression-example2.png[] + +The following boxed literal expression sorts a list of possible dating candidates (soul mates) in an online dating application based on their score on criteria such as age, location, and interests: + +.Boxed literal expression for matching online dating candidates +image::kogito/dmn/dmn-literal-expression-example3b.png[] diff --git a/assemblies/modules/decision-services/con-dmn-names.adoc b/assemblies/modules/decision-services/con-dmn-names.adoc new file mode 100644 index 0000000..b38be4a --- /dev/null +++ b/assemblies/modules/decision-services/con-dmn-names.adoc @@ -0,0 +1,27 @@ +[id='con-dmn-names_{context}'] += Variable and function names in FEEL + +Unlike many traditional expression languages, Friendly Enough Expression Language (FEEL) supports spaces and a few special characters as part of variable and function names. A FEEL name must start with a `letter`, `?`, or `_` element. The unicode letter characters are also allowed. Variable names cannot start with a language keyword, such as `and`, `true`, or `every`. The remaining characters in a variable name can be any of the starting characters, as well as `digits`, white spaces, and special characters such as `+`, `-`, `/`, `*`, `'`, and `.`. + +For example, the following names are all valid FEEL names: + +* Age +* Birth Date +* Flight 234 pre-check procedure + +Several limitations apply to variable and function names in FEEL: + +Ambiguity:: +The use of spaces, keywords, and other special characters as part of names can make FEEL ambiguous. The ambiguities are resolved in the context of the expression, matching names from left to right. The parser resolves the variable name as the longest name matched in scope. You can use `( )` to disambiguate names if necessary. + +Spaces in names:: +The DMN specification limits the use of spaces in FEEL names. According to the DMN specification, names can contain multiple spaces but not two consecutive spaces. ++ +-- +In order to make the language easier to use and avoid common errors due to spaces, {PRODUCT} removes the limitation on the use of consecutive spaces. {PRODUCT} supports variable names with any number of consecutive spaces, but normalizes them into a single space. For example, the variable references `First Name` with one space and `First Name` with two spaces are both acceptable in {PRODUCT}. + +{PRODUCT} also normalizes the use of other white spaces, like the non-breakable white space that is common in web pages, tabs, and line breaks. From a {PRODUCT} FEEL engine perspective, all of these characters are normalized into a single white space before processing. +-- + +The keyword `in`:: +The keyword `in` is the only keyword in the language that cannot be used as part of a variable name. Although the specifications allow the use of keywords in the middle of variable names, the use of `in` in variable names conflicts with the grammar definition of `for`, `every` and `some` expression constructs. diff --git a/assemblies/modules/decision-services/con-dmn-relation-expressions.adoc b/assemblies/modules/decision-services/con-dmn-relation-expressions.adoc new file mode 100644 index 0000000..48d52d9 --- /dev/null +++ b/assemblies/modules/decision-services/con-dmn-relation-expressions.adoc @@ -0,0 +1,9 @@ +[id='con-dmn-relation-expressions_{context}'] += Boxed relation expressions + +A boxed relation expression in DMN is a traditional data table with information about given entities, listed as rows. You use boxed relation tables to define decision data for relevant entities in a decision at a particular node. Boxed relation expressions are similar to context expressions in that they set variable names and values, but relation expressions contain no result value and list all variable values based on a single defined variable in each column. + +For example, the following boxed relation expression provides information about employees in an employee rostering decision: + +.Boxed relation expression with employee information +image::kogito/dmn/dmn-relation-expression-example.png[] diff --git a/assemblies/modules/decision-services/con-dmn-support.adoc b/assemblies/modules/decision-services/con-dmn-support.adoc new file mode 100644 index 0000000..7980ac8 --- /dev/null +++ b/assemblies/modules/decision-services/con-dmn-support.adoc @@ -0,0 +1,6 @@ +[id='con-dmn-support_{context}'] += DMN support in {PRODUCT} + +{PRODUCT} provides design and runtime support for DMN 1.2 models at conformance level 3, and runtime-only support for DMN 1.1 and 1.3 models at conformance level 3. You can design your DMN models with the {PRODUCT} DMN modeler in VSCode or import existing DMN models into your {PRODUCT} projects for deployment and execution. Any DMN 1.1 models that you import into your {PRODUCT} project, open in the DMN modeler, and save are converted to DMN 1.2 models. DMN 1.3 models are not supported in the {PRODUCT} DMN modeler. + +In addition to all DMN conformance level 3 requirements, {PRODUCT} also includes enhancements and fixes to FEEL and DMN model components to optimize the experience of implementing DMN decision services with {PRODUCT}. From a platform perspective, DMN models are like any other business asset in {PRODUCT}, such as DRL files or spreadsheet decision tables, that you can include in your {PRODUCT} project and execute to start your DMN decision services. diff --git a/assemblies/modules/decision-services/con-dmn.adoc b/assemblies/modules/decision-services/con-dmn.adoc new file mode 100644 index 0000000..b996cbf --- /dev/null +++ b/assemblies/modules/decision-services/con-dmn.adoc @@ -0,0 +1,6 @@ +[id='con-dmn_{context}'] += Decision Model and Notation (DMN) + +Decision Model and Notation (DMN) is a standard established by the https://www.omg.org/[Object Management Group (OMG)] for describing and modeling operational decisions. DMN defines an XML schema that enables DMN models to be shared between DMN-compliant platforms and across organizations so that business analysts and business rules developers can collaborate in designing and implementing DMN decision services. The DMN standard is similar to and can be used together with the Business Process Model and Notation (BPMN) standard for designing and modeling business processes. + +For more information about the background and applications of DMN, see the OMG https://www.omg.org/spec/DMN[Decision Model and Notation specification]. diff --git a/assemblies/modules/decision-services/con-drl-declarations-enumerative.adoc b/assemblies/modules/decision-services/con-drl-declarations-enumerative.adoc new file mode 100644 index 0000000..26c8a37 --- /dev/null +++ b/assemblies/modules/decision-services/con-drl-declarations-enumerative.adoc @@ -0,0 +1,23 @@ +[id='con-drl-declarations-enumerative_{context}'] += Enumerative type declarations in DRL + +DRL supports the declaration of enumerative types in the format `declare enum __FACT_TYPE__`, followed by a comma-separated list of values ending with a semicolon. You can then use the enumerative list in the rules in the DRL file. + +For example, the following enumerative type declaration defines days of the week for an employee scheduling rule: + +.Example enumerative type declaration with a scheduling rule +[source] +---- +declare enum DaysOfWeek + SUN("Sunday"),MON("Monday"),TUE("Tuesday"),WED("Wednesday"),THU("Thursday"),FRI("Friday"),SAT("Saturday"); + + fullName : String +end + +rule "Using a declared Enum" + when + $emp : /employee[ dayOff == DaysOfWeek.MONDAY ] + then + ... +end +---- diff --git a/assemblies/modules/decision-services/con-drl-declarations-extended.adoc b/assemblies/modules/decision-services/con-drl-declarations-extended.adoc new file mode 100644 index 0000000..4ed4dc8 --- /dev/null +++ b/assemblies/modules/decision-services/con-drl-declarations-extended.adoc @@ -0,0 +1,23 @@ +[id='con-drl-declarations-extended_{context}'] += Extended type declarations in DRL + +DRL supports type declaration inheritance in the format `declare __FACT_TYPE_1__ extends __FACT_TYPE_2__`. To extend a type declared in Java by a subtype declared in DRL, you repeat the parent type in a declaration statement without any fields. + +For example, the following type declarations extend a `Student` type from a top-level `Person` type, and a `LongTermStudent` type from the `Student` subtype: + +.Example extended type declarations +[source] +---- +import org.people.Person + +declare Person end + +declare Student extends Person + school : String +end + +declare LongTermStudent extends Student + years : int + course : String +end +---- diff --git a/assemblies/modules/decision-services/con-drl-declarations-with-metadata.adoc b/assemblies/modules/decision-services/con-drl-declarations-with-metadata.adoc new file mode 100644 index 0000000..10e8730 --- /dev/null +++ b/assemblies/modules/decision-services/con-drl-declarations-with-metadata.adoc @@ -0,0 +1,43 @@ +[id='con-drl-declarations-with-metadata_{context}'] += Type declarations with metadata in DRL + +You can associate metadata in the format `@__KEY__( __VALUE__ )` (the value is optional) with fact types or fact attributes. Metadata can be any kind of data that is not represented by the fact attributes and is consistent among all instances of that fact type. The metadata can be queried at run time by the {DECISION_ENGINE} and used in the reasoning process. Any metadata that you declare before the attributes of a fact type are assigned to the fact type, while metadata that you declare after an attribute are assigned to that particular attribute. + +In the following example, the two metadata attributes `@author` and `@dateOfCreation` are declared for the `Person` fact type, and the two metadata items `@key` (literal) and `@maxLength` are declared for the `name` attribute. The `@key` literal metadata attribute has no required value, so the parentheses and the value are omitted. + +.Example metadata declaration for fact types and attributes +[source] +---- +import java.util.Date + +declare Person + @author( Bob ) + @dateOfCreation( 01-Feb-2009 ) + + name : String @key @maxLength( 30 ) + dateOfBirth : Date + address : Address +end +---- + +For declarations of metadata attributes for existing types, you can identify the fully qualified class name as part of the `import` clause for all declarations or as part of the individual `declare` clause: + +.Example metadata declaration for an imported type +[source] +---- +import org.drools.examples.Person + +declare Person + @author( Bob ) + @dateOfCreation( 01-Feb-2009 ) +end +---- + +.Example metadata declaration for a declared type +[source] +---- +declare org.drools.examples.Person + @author( Bob ) + @dateOfCreation( 01-Feb-2009 ) +end +---- diff --git a/assemblies/modules/decision-services/con-drl-declarations-without-metadata.adoc b/assemblies/modules/decision-services/con-drl-declarations-without-metadata.adoc new file mode 100644 index 0000000..0e36db4 --- /dev/null +++ b/assemblies/modules/decision-services/con-drl-declarations-without-metadata.adoc @@ -0,0 +1,83 @@ +[id='con-drl-declarations-without-metadata_{context}'] += Type declarations without metadata in DRL + +A declaration of a new fact does not require any metadata, but must include a list of attributes or fields. If a type declaration does not include identifying attributes, the {DECISION_ENGINE} searches for an existing fact class in the classpath and raises an error if the class is missing. + +For example, the following DRL file contains a declaration of a new fact type `Person` from a `person` data source and uses no metadata: + +.Example declaration of a new fact type with a rule +[source] +---- +declare Person + name : String + dateOfBirth : java.util.Date + address : Address +end + +rule "Using a declared type" + when + $p : /person[ name == "James" ] + then // Insert Mark, who is a customer of James. + Person mark = new Person(); + mark.setName( "Mark" ); + person.append( mark ); +end +---- + +In this example, the new fact type `Person` has the three attributes `name`, `dateOfBirth`, and `address`. Each attribute has a type that can be any valid Java type, including another class that you create or a fact type that you previously declared. The `dateOfBirth` attribute has the type `java.util.Date`, from the Java API, and the `address` attribute has the previously defined fact type `Address`. + +To avoid writing the fully qualified name of a class every time you declare it, you can define the full class name as part of the `import` clause: + +.Example type declaration with the fully qualified class name in the import +[source] +---- +import java.util.Date + +declare Person + name : String + dateOfBirth : Date + address : Address +end +---- + +When you declare a new fact type, the {DECISION_ENGINE} generates at compile time a Java class representing the fact type. The generated Java class is a one-to-one JavaBeans mapping of the type definition. + +For example, the following Java class is generated from the example `Person` type declaration: + +.Generated Java class for the Person fact type declaration +[source,java] +---- +public class Person implements Serializable { + private String name; + private java.util.Date dateOfBirth; + private Address address; + + // Empty constructor + public Person() {...} + + // Constructor with all fields + public Person( String name, Date dateOfBirth, Address address ) {...} + + // If keys are defined, constructor with keys + public Person( ...keys... ) {...} + + // Getters and setters + // `equals` and `hashCode` + // `toString` +} +---- + +You can then use the generated class in your rules like any other fact, as illustrated in the previous rule example with the `Person` type declaration from a `person` data source: + +.Example rule that uses the declared Person fact type +[source] +---- +rule "Using a declared type" + when + $p : /person[ name == "James" ] + then // Insert Mark, who is a customer of James. + Person mark = new Person(); + mark.setName( "Mark" ); + person.append( mark ); +end +---- diff --git a/assemblies/modules/decision-services/con-drl-declarations.adoc b/assemblies/modules/decision-services/con-drl-declarations.adoc new file mode 100644 index 0000000..d7f79f2 --- /dev/null +++ b/assemblies/modules/decision-services/con-drl-declarations.adoc @@ -0,0 +1,15 @@ +[id='con-drl-declarations_{context}'] += Type declarations and metadata in DRL + +ifdef::KOGITO-COMM[] +.Type declaration +image::kogito/drl/type_declaration.png[align="center"] + +.Metadata +image::kogito/drl/meta_data.png[align="center"] +endif::[] + +Declarations in DRL files define new fact types or metadata for fact types to be used by rules in the DRL file: + +* *New fact types:* The default fact type in the `java.lang` package of {PRODUCT} is `Object`, but you can declare other types in DRL files as needed. Declaring fact types in DRL files enables you to define a new fact model directly in the {DECISION_ENGINE}, without creating models in a lower-level language like Java. You can also declare a new type when a domain model is already built and you want to complement this model with additional entities that are used mainly during the reasoning process. +* *Metadata for fact types:* You can associate metadata in the format `@__KEY__( __VALUE__ )` with new or existing facts. Metadata can be any kind of data that is not represented by the fact attributes and is consistent among all instances of that fact type. The metadata can be queried at run time by the {DECISION_ENGINE} and used in the reasoning process. diff --git a/assemblies/modules/decision-services/con-drl-globals.adoc b/assemblies/modules/decision-services/con-drl-globals.adoc new file mode 100644 index 0000000..cbd80eb --- /dev/null +++ b/assemblies/modules/decision-services/con-drl-globals.adoc @@ -0,0 +1,43 @@ +[id='con-drl-globals_{context}'] += Global variables in DRL + +ifdef::KOGITO-COMM[] +.Global +image::kogito/drl/global.png[align="center"] +endif::[] + +Global variables in DRL files typically provide data or services for the rules, such as application services used in rule consequences, and return data from rules, such as logs or values added in rule consequences. You set the global value in the working memory of the {DECISION_ENGINE} through a KIE session configuration or REST operation, declare the global variable above the rules in the DRL file, and then use it in an action (`then`) part of the rule. For multiple global variables, use separate lines in the DRL file. + +The following example illustrates a global variable list configuration for the {DECISION_ENGINE} and the corresponding global variable definition in the DRL file: + +.Example global list configuration for the {DECISION_ENGINE} +[source] +---- +List list = new ArrayList<>(); +KieSession kieSession = kiebase.newKieSession(); +kieSession.setGlobal( "myGlobalList", list ); +---- + +.Example global variable definition with a rule +[source] +---- +global java.util.List myGlobalList; + +rule "Using a global" + when + // Empty + then + myGlobalList.add( "My global list" ); +end +---- + +[WARNING] +==== +Do not use global variables to establish conditions in rules unless a global variable has a constant immutable value. Global variables are not inserted into the working memory of the {DECISION_ENGINE}, so the {DECISION_ENGINE} cannot track value changes of variables. + +Do not use global variables to share data between rules. Rules always reason and react to the working memory state, so if you want to pass data from rule to rule, assert the data as facts into the working memory of the {DECISION_ENGINE}. +==== + +A use case for a global variable might be an instance of an email service. In your integration code that is calling the {DECISION_ENGINE}, you obtain your `emailService` object and then set it in the working memory of the {DECISION_ENGINE}. In the DRL file, you declare that you have a global of type `emailService` and give it the name `"email"`, and then in your rule consequences, you can use actions such as `email.sendSMS(number, message)`. + +If you declare global variables with the same identifier in multiple packages, then you must set all the packages with the same type so that they all reference the same global value. diff --git a/assemblies/modules/decision-services/con-drl-imports.adoc b/assemblies/modules/decision-services/con-drl-imports.adoc new file mode 100644 index 0000000..7a5221c --- /dev/null +++ b/assemblies/modules/decision-services/con-drl-imports.adoc @@ -0,0 +1,17 @@ +[id='con-drl-imports_{context}'] += Import statements in DRL + +ifdef::KOGITO-COMM[] +.Import +image::kogito/drl/import.png[align="center"] +endif::[] + +Similar to import statements in Java, imports in DRL files identify the fully qualified paths and type names for any objects that you want to use in the rules. You specify the package and data object in the format `packageName.objectName`, with multiple imports on separate lines. The {DECISION_ENGINE} automatically imports classes from the Java package with the same name as the DRL package and from the package `java.lang`. + +The following example is an import statement for a loan application object in a mortgage application decision service: + +.Example import statement in a DRL file +[source] +---- +import org.mortgages.LoanApplication; +---- diff --git a/assemblies/modules/decision-services/con-drl-legacy.adoc b/assemblies/modules/decision-services/con-drl-legacy.adoc new file mode 100644 index 0000000..728514c --- /dev/null +++ b/assemblies/modules/decision-services/con-drl-legacy.adoc @@ -0,0 +1,493 @@ +[id='con-drl-legacy_{context}'] += Legacy DRL conventions + +The following Drools Rule Language (DRL) conventions are no longer applicable or optimal in {PRODUCT} but might be available for backward compatibility. + +== Legacy functions in DRL + +ifdef::KOGITO-COMM[] +.Function +image::kogito/drl/function.png[align="center"] +endif::[] + +Functions in DRL files put semantic code in your rule source file instead of in Java classes. Functions are especially useful if an action (`then`) part of a rule is used repeatedly and only the parameters differ for each rule. Above the rules in the DRL file, you can declare the function or import a static method from a helper class as a function, and then use the function by name in an action (`then`) part of the rule. + +The following examples illustrate a function that is either declared or imported in a DRL file: + +.Example function declaration with a rule (option 1) +[source] +---- +function String hello(String applicantName) { + return "Hello " + applicantName + "!"; +} + +rule "Using a function" + when + // Empty + then + System.out.println( hello( "James" ) ); +end +---- + +.Example function import with a rule (option 2) +[source] +---- +import function my.package.applicant.hello; + +rule "Using a function" + when + // Empty + then + System.out.println( hello( "James" ) ); +end +---- + +== Legacy rule attributes + +The following attributes were used in earlier versions of the {DECISION_ENGINE} to provide grouping of rules across a rule base. These attributes are superseded by DRL rule units and are only available for backward compatibility reasons. If you need to group your rules, use DRL rule units as a clearer and simpler grouping method. + +.Legacy rule attributes +[cols="30%,70%", options="header"] +|=== +|Attribute +|Value + +|`agenda-group` +|A string identifying an agenda group to which you want to assign the rule. Agenda groups allow you to partition the agenda to provide more execution control over groups of rules. Only rules in an agenda group that has acquired a focus are able to be activated. + +Example: `agenda-group "GroupName"` + +|`ruleflow-group` +|A string identifying a rule flow group. In rule flow groups, rules can fire only when the group is activated by the associated rule flow. + +Example: `ruleflow-group "GroupName"` +|=== + +== Legacy DRL rule condition syntax + +In {PRODUCT}, the preferred syntax for DRL rule conditions is through OOPath expressions. For legacy use cases, you can write rules using traditional pattern matching. In this case, you must explicitly indicate the data source using the `from` clause, as shown in the following comparative examples: + +.Example person DRL file using OOPath notation +[source] +---- +package org.acme +unit PersonRules; + +import org.acme.Person; + +rule isAdult + when + $person: /person[ age > 18 ] + then + modify($person) { + setAdult(true) + }; +end +---- + +.Example person DRL file using traditional notation +[source] +---- +package org.acme +unit PersonRules; + +import org.acme.Person; + +rule isAdult + when + $person: Person(age > 18) from person + then + modify($person) { + setAdult(true) + }; +end +---- + +== Legacy DRL rule condition elements + +The following rule condition elements (keywords) are obsolete in {PRODUCT}: + +`from`:: +(Obsolete with OOPath notation) ++ +-- +Use this to specify a data source for a pattern. This enables the {DECISION_ENGINE} to reason over data that is not in the working memory. The data source can be a sub-field on a bound variable or the result of a method call. The expression used to define the object source is any expression that follows regular MVEL syntax. Therefore, the `from` element enables you to easily use object property navigation, execute method calls, and access maps and collection elements. + +ifdef::KOGITO-COMM[] +.from +image::kogito/drl/from.png[align="center"] +endif::[] + +.Example rule with `from` and pattern binding +[source] +---- +rule "Validate zipcode" + when + Person( $personAddress : address ) + Address( zipcode == "23920W" ) from $personAddress + then + // Zip code is okay. +end +---- + +.Example rule with `from` and a graph notation +[source] +---- +rule "Validate zipcode" + when + $p : Person() + $a : Address( zipcode == "23920W" ) from $p.address + then + // Zip code is okay. +end +---- + +.Example rule with `from` to iterate over all objects +[source] +---- +rule "Apply 10% discount to all items over US$ 100 in an order" + when + $order : Order() + $item : OrderItem( value > 100 ) from $order.items + then + // Apply discount to `$item`. +end +---- + +[NOTE] +==== +For large collections of objects, instead of adding an object with a large graph that the {DECISION_ENGINE} must iterate over frequently, add the collection directly to the KIE session and then join the collection in the condition, as shown in the following example: + +[source] +---- +when + $order : Order() + OrderItem( value > 100, order == $order ) +---- +==== + +.Example rule with `from` and `lock-on-active` rule attribute +[source] +---- +rule "Assign people in North Carolina (NC) to sales region 1" + ruleflow-group "test" + lock-on-active true + when + $p : Person() + $a : Address( state == "NC" ) from $p.address + then + modify ($p) {} // Assign the person to sales region 1. +end + +rule "Apply a discount to people in the city of Raleigh" + ruleflow-group "test" + lock-on-active true + when + $p : Person() + $a : Address( city == "Raleigh" ) from $p.address + then + modify ($p) {} // Apply discount to the person. +end +---- + +[IMPORTANT] +==== +Using `from` with `lock-on-active` rule attribute can result in rules not being executed. You can address this issue in one of the following ways: + +* Avoid using the `from` element when you can insert all facts into the working memory of the {DECISION_ENGINE} or use nested object references in your constraint expressions. +* Place the variable used in the `modify()` block as the last sentence in your rule condition. +* Avoid using the `lock-on-active` rule attribute when you can explicitly manage how rules within the same ruleflow group place activations on one another. +==== + +The pattern that contains a `from` clause cannot be followed by another pattern starting with a parenthesis. The reason for this restriction is that the DRL parser reads the `from` expression as `"from $l (String() or Number())"` and it cannot differentiate this expression from a function call. The simplest workaround to this is to wrap the `from` clause in parentheses, as shown in the following example: + +.Example rules with `from` used incorrectly and correctly +[source] +---- +// Do not use `from` in this way: +rule R + when + $l : List() + String() from $l + (String() or Number()) + then + // Actions +end + +// Use `from` in this way instead: +rule R + when + $l : List() + (String() from $l) + (String() or Number()) + then + // Actions +end +---- +-- + +`entry-point`:: +(Superseded by rule unit data sources) ++ +-- +Use this to define an entry point, or _event stream_, corresponding to a data source for the pattern. This element is typically used with the `from` condition element. You can declare an entry point for events so that the {DECISION_ENGINE} uses data from only that entry point to evaluate the rules. You can declare an entry point either implicitly by referencing it in DRL rules or explicitly in your Java application. + +.Example rule with `from entry-point` +[source] +---- +rule "Authorize withdrawal" + when + WithdrawRequest( $ai : accountId, $am : amount ) from entry-point "ATM Stream" + CheckingAccount( accountId == $ai, balance > $am ) + then + // Authorize withdrawal. +end +---- +-- + +`collect`:: +(Obsolete with OOPath notation) ++ +-- +Use this to define a collection of objects that the rule can use as part of the condition. The rule obtains the collection either from a specified source or from the working memory of the {DECISION_ENGINE}. The result pattern of the `collect` element can be any concrete class that implements the `java.util.Collection` interface and provides a default no-arg public constructor. You can use Java collections like `List`, `LinkedList`, and `HashSet`, or your own class. If variables are bound before the `collect` element in a condition, you can use the variables to constrain both your source and result patterns. However, any binding made inside the `collect` element is not available for use outside of it. + +ifdef::KOGITO-COMM[] +.Collect +image::kogito/drl/collect.png[align="center"] +endif::[] + +.Example rule with `collect` +[source] +---- +import java.util.List + +rule "Raise priority when system has more than three pending alarms" + when + $system : System() + $alarms : List( size >= 3 ) + from collect( Alarm( system == $system, status == 'pending' ) ) + then + // Raise priority because `$system` has three or more `$alarms` pending. +end +---- + +In this example, the rule assesses all pending alarms in the working memory of the {DECISION_ENGINE} for each given system and groups them in a `List`. If three or more alarms are found for a given system, the rule is executed. + +You can also use the `collect` element with nested `from` elements, as shown in the following example: + +.Example rule with `collect` and nested `from` +[source] +---- +import java.util.LinkedList; + +rule "Send a message to all parents" + when + $town : Town( name == 'Paris' ) + $mothers : LinkedList() + from collect( Person( children > 0 ) + from $town.getPeople() + ) + then + // Send a message to all parents. +end +---- +-- + +ifdef::KOGITO-COMM[] +`accumulate` alternate syntax for a single function with return type:: +The accumulate syntax evolved over time with the goal of becoming more compact and expressive. +Nevertheless, {PRODUCT} still supports previous syntaxes for backward compatibility purposes. ++ +-- +In case the rule is using a single accumulate function on a given accumulate, the author may add a pattern for the result object and use the "from" keyword to link it to the accumulate result. + +Example: a rule to apply a 10% discount on orders over $100 could be written in the following way: + +[source] +---- +rule "Apply 10% discount to orders over US$ 100,00" +when + $order : /order + $total : Number( doubleValue > 100 ) + from accumulate( OrderItem( order == $order, $value : value ), + sum( $value ) ) +then + // apply discount to $order +end +---- + +In the above example, the accumulate element is using only one function (sum), and so, the rules author opted to explicitly write a pattern for the result type of the accumulate function (Number) and write the constraints inside it. +There are no problems in using this syntax over the compact syntax presented before, except that is is a bit more verbose. +Also note that it is not allowed to use both the return type and the functions binding in the same accumulate statement. + +Compile-time checks are performed in order to ensure the pattern used with the $$"$$``from``$$"$$ keyword is assignable from the result of the accumulate function used. + +[NOTE] +==== +With this syntax, the $$"$$``from``$$"$$ binds to the single result returned by the accumulate function, and it does not iterate. +==== + +In the above example, $$"$$``$total``$$"$$ is bound to the result returned by the accumulate sum() function. + +As another example however, if the result of the accumulate function is a collection, $$"$$``from``$$"$$ still binds to the single result and it does not iterate: + +[source] +---- +rule "Person names" +when + $x : Object() from accumulate(MyPerson( $val : name ); + collectList( $val ) ) +then + // $x is a List +end +---- + +The bound $$"$$``$x : Object()``$$"$$ is the List itself, returned by the collectList accumulate function used. + +This is an important distinction to highlight, as the $$"$$``from``$$"$$ keyword can also be used separately of accumulate, to iterate over the elements of a collection: + +[source] +---- +rule "Iterate the numbers" +when + $xs : List() + $x : Integer() from $xs +then + // $x matches and binds to each Integer in the collection +end +---- + +While this syntax is still supported for backward compatibility purposes, for this and other reasons we encourage rule authors to make use instead of the preferred `accumulate` syntax (described previously), to avoid any potential pitfalls. +-- + +`accumulate` with inline custom code:: +Another possible syntax for the `accumulate` is to define inline custom code, instead of using accumulate functions. ++ +-- +[WARNING] +==== +The use of accumulate with inline custom code is not a good practice for several reasons, including difficulties on maintaining and testing rules that use them, as well as the inability of reusing that code. +Implementing your own accumulate functions is very simple and straightforward, they are easy to unit test and to use. +This form of accumulate is supported for backward compatibility only. + +Only limited support for inline accumulate is provided while using the executable model. +For example, you cannot use an external binding in the code while using the MVEL dialect: + +[source] +---- +rule R +dialect "mvel" +when + String( $l : length ) + $sum : Integer() from accumulate ( + Person( age > 18, $age : age ), + init( int sum = 0 * $l; ), + action( sum += $age; ), + reverse( sum -= $age; ), + result( sum ) + ) +---- +==== + +The general syntax of the `accumulate` CE with inline custom code is: + +[source,subs="+quotes"] +---- +__RESULT_PATTERN__ from accumulate( __SOURCE_PATTERN__, + init( __INIT_CODE__ ), + action( __ACTION_CODE__ ), + reverse( __REVERSE_CODE__ ), + result( __RESULT_EXPRESSION__ ) ) +---- + + +The meaning of each of the elements is the following: + +* __SOURCE_PATTERN__: the source pattern is a regular pattern that the {DECISION_ENGINE} will try to match against each of the source objects. +* __INIT_CODE__: this is a semantic block of code in the selected dialect that will be executed once for each tuple, before iterating over the source objects. +* __ACTION_CODE__: this is a semantic block of code in the selected dialect that will be executed for each of the source objects. +* __REVERSE_CODE__: this is an optional semantic block of code in the selected dialect that if present will be executed for each source object that no longer matches the source pattern. The objective of this code block is to undo any calculation done in the _ACTION_CODE_ block, so that the {DECISION_ENGINE} can do decremental calculation when a source object is modified or deleted, hugely improving performance of these operations. +* __RESULT_EXPRESSION__: this is a semantic expression in the selected dialect that is executed after all source objects are iterated. +* __RESULT_PATTERN__: this is a regular pattern that the {DECISION_ENGINE} tries to match against the object returned from the __RESULT_EXPRESSION__. If it matches, the `accumulate` conditional element evaluates to _true_ and the {DECISION_ENGINE} proceeds with the evaluation of the next CE in the rule. If it does not matches, the `accumulate` CE evaluates to _false_ and the {DECISION_ENGINE} stops evaluating CEs for that rule. + +It is easier to understand if we look at an example: + +[source] +---- +rule "Apply 10% discount to orders over US$ 100,00" +when + $order : Order() + $total : Number( doubleValue > 100 ) + from accumulate( OrderItem( order == $order, $value : value ), + init( double total = 0; ), + action( total += $value; ), + reverse( total -= $value; ), + result( total ) ) +then + // apply discount to $order +end +---- + +In the above example, for each `Order` in the Working Memory, the {DECISION_ENGINE} will execute the __INIT_CODE__ initializing the total variable to zero. +Then it will iterate over all `OrderItem` objects for that order, executing the _action_ for each one (in the example, it will sum the value of all items into the total variable). After iterating over all `OrderItem` objects, it will return the value corresponding to the _result + expression_ (in the above example, the value of variable ``total``). Finally, the {DECISION_ENGINE} will try to match the result with the `Number` pattern, and if the double value is greater than 100, the rule will fire. + +The example used Java as the semantic dialect, and as such, note that the usage of the semicolon as statement delimiter is mandatory in the init, action and reverse code blocks. +The result is an expression and, as such, it does not admit ';'. If the user uses any other dialect, he must comply to that dialect's specific syntax. + +As mentioned before, the __REVERSE_CODE__ is optional, but it is strongly recommended that the user writes it in order to benefit from the __improved performance on update + and delete__. + +The `accumulate` CE can be used to execute any action on source objects. +The following example instantiates and populates a custom object: + +[source] +---- +rule "Accumulate using custom objects" +when + $person : Person( $likes : likes ) + $cheesery : Cheesery( totalAmount > 100 ) + from accumulate( $cheese : Cheese( type == $likes ), + init( Cheesery cheesery = new Cheesery(); ), + action( cheesery.addCheese( $cheese ); ), + reverse( cheesery.removeCheese( $cheese ); ), + result( cheesery ) ); +then + // do something +end +---- +-- + +`eval`:: +The conditional element `eval` is essentially a catch-all which allows any semantic code (that returns a primitive boolean) to be executed. +This code can refer to variables that were bound in the conditions of the rule and functions in the rule package. +Overuse of `eval` reduces the declarativeness of your rules and can result in a poorly performing {DECISION_ENGINE}. +While `eval` can be used anywhere in the patterns, it is typically added as the last conditional element in the conditions of a rule. ++ +-- +.Eval +image::kogito/drl/eval.png[align="center"] + +Instances of `eval` cannot be indexed and thus are not as efficient as Field Constraints. +However this makes them ideal for being used when functions return values that change over time, which is not allowed within Field Constraints. + +For those who are familiar with {PRODUCT} 2.x lineage, the old {PRODUCT} parameter and condition tags are equivalent to binding a variable to an appropriate type, and then using it in an `eval` node. + +[source] +---- +p1 : Parameter() +p2 : Parameter() +eval( p1.getList().containsKey( p2.getItem() ) ) +---- + +{empty} + +[source] +---- +p1 : Parameter() +p2 : Parameter() +// call function isValid in the LHS +eval( isValid( p1, p2 ) ) +---- +-- +endif::[] diff --git a/assemblies/modules/decision-services/con-drl-packages.adoc b/assemblies/modules/decision-services/con-drl-packages.adoc new file mode 100644 index 0000000..60f880b --- /dev/null +++ b/assemblies/modules/decision-services/con-drl-packages.adoc @@ -0,0 +1,26 @@ +[id='con-drl-packages_{context}'] += Packages in DRL + +A package is a folder of related assets in {PRODUCT}, such as data objects, DRL files, decision tables, and other asset types. A package also serves as a unique namespace for each group of rules. A single rule base can contain multiple packages. You typically store all the rules for a package in the same file as the package declaration so that the package is self-contained. However, you can import objects from other packages that you want to use in the rules. + +The following example is a package name and namespace for a DRL file in a mortgage application decision service: + +.Example package definition in a DRL file +[source] +---- +package org.mortgages; +---- + +ifdef::KOGITO-COMM[] +The following railroad diagram shows all the components that may make up a package: + +.Package +image::kogito/drl/package.png[align="center"] + +Note that a package _must_ have a namespace and be declared using standard Java conventions for package names; i.e., no spaces, unlike rule names which allow spaces. +In terms of the order of elements, they can appear in any order in the rule file, with the exception of the `package` and `unit` statements, which must be at the top of the file. +In all cases, the semicolons are optional. + +Notice that any rule attribute (as described in the section xref:rules-attributes-ref-drl-rules[]) may also be written at package level, superseding the attribute's default value. +The modified default may still be replaced by an attribute setting within a rule. +endif::[] diff --git a/assemblies/modules/decision-services/con-drl-queries.adoc b/assemblies/modules/decision-services/con-drl-queries.adoc new file mode 100644 index 0000000..556cede --- /dev/null +++ b/assemblies/modules/decision-services/con-drl-queries.adoc @@ -0,0 +1,69 @@ +[id='con-drl-queries_{context}'] += Queries in DRL + +ifdef::KOGITO-COMM[] +.Query +image::kogito/drl/query.png[align="center"] +endif::[] + +Queries in DRL files search the working memory of the {DECISION_ENGINE} for facts related to the rules in the DRL file. You add the query definitions in DRL files and then obtain the matching results in your application code. Queries search for a set of defined conditions and do not require `when` or `then` specifications. Query names are scoped to the rule unit, so each query name must be unique within the same rule unit. In {PRODUCT}, queries are automatically exposed as REST endpoints. + +The following example is a query definition for an `Alert` object with a `severity` field set to `HIGH`: + +.Example query definition in a DRL file +[source] +---- +package com.acme; +unit MonitoringService; + +query highSeverity + alerts : /alertData[ severity == "HIGH" ] +end +---- + +{PRODUCT} automatically exposes this query through an endpoint `/high-severity`. + +For this example, assume that the `MonitoringService` rule unit class has the following form: + +.Example Java rule unit class +[source,java] +---- +package com.acme; + +import org.kie.kogito.rules.DataSource; +import org.kie.kogito.rules.DataStream; + +public class MonitoringService implements RuleUnitData { + private DataStream temperature = DataSource.createStream(); + private DataStream alertData = DataSource.createStream(); + public DataStream getTemperature() { return temperature; } + public DataStream getAlertData() { return alertData; } +} +---- + +In this case, you can invoke the query using the following command: + +.Example POST request to the `/high-severity` endpoint +[source] +---- +$ curl -X POST \ + -H 'Accept: application/json' \ + -H 'Content-Type: application/json' \ + -d '{ "eventData": [ { "type": "temperature", "value" : 20 }, { "type": "temperature", "value" : 100 } ] }' \ + http://localhost:8080/high-severity +---- + +.Example response (JSON) +[source,json] +---- +{ + "alerts" : [ + { + "severity" : "HIGH", + "message" : "Temperature exceeds threshold: 100" + } + ] +} +---- + +This example submits the data to the `eventData` data source and returns the result of the `highSeverity` query as a response. diff --git a/assemblies/modules/decision-services/con-drl-rule-units.adoc b/assemblies/modules/decision-services/con-drl-rule-units.adoc new file mode 100644 index 0000000..392f954 --- /dev/null +++ b/assemblies/modules/decision-services/con-drl-rule-units.adoc @@ -0,0 +1,305 @@ +[id='con-drl-rule-units_{context}'] += Rule units in DRL + +A DRL rule unit is a module for rules and a unit of execution. A rule unit collects a set of rules with the declaration of the type of facts that the rules act on. A rule unit also serves as a unique namespace for each group of rules. A single rule base can contain multiple rule units. You typically store all the rules for a unit in the same file as the unit declaration so that the unit is self-contained. + +The following example is a rule unit designated in a DRL file in a mortgage application decision service: + +.Example package definition and rule unit designation in a DRL file +[source] +---- +package org.mortgages; +unit MortgageRules; +---- + +To define a rule unit, you declare the relevant fact types and declare the data sources for the types by implementing the `RuleUnitData` interface, and then define the rules in the unit: + +.Example DRL rule unit file +[source] +---- +package org.mortgages; +unit MortgageRules; + +import org.kie.kogito.rules.DataSource; +import org.kie.kogito.rules.DataStream; + +declare Person + name : String + dateOfBirth : Date + address : Address +end + +declare MortgageRules extends RuleUnitData + person: DataStream = DataSource.createStream() +end + +rule "Using a rule unit with a declared type" + when + $p : /person[ name == "James" ] + then // Insert Mark, who is a customer of James. + Person mark = new Person(); + mark.setName( "Mark" ); + person.append( mark ); +end +---- + +To separate the fact types from the rule unit for use with other DRL rules, you can declare the types in a separate DRL file and then use the DRL rule file to declare the data sources by using the `RuleUnitData` interface implementation: + +.Example DRL type declaration as a separate file +[source] +---- +package org.mortgages; + +declare Person + name : String + dateOfBirth : Date + address : Address +end +---- + +.Example DRL rule unit file without explicitly defined types +[source] +---- +package org.mortgages; +unit MortgageRules; + +import org.kie.kogito.rules.DataSource; +import org.kie.kogito.rules.DataStream; + +declare MortgageRules extends RuleUnitData + person: DataStream = DataSource.createStream() +end + +rule "Using a rule unit with a declared type" + when + $p : /person[ name == "James" ] + then // Insert Mark, who is a customer of James. + Person mark = new Person(); + mark.setName( "Mark" ); + person.append( mark ); +end +---- + +In this example, `persons` is a `DataStream` data source for facts of type `Person`. Data sources are typed sources of data that rule units can subscribe to for updates. You interact with the rule unit through the data sources it exposes. A data source can be a `DataStream` source for append-only storage, a `DataStore` source for writable storage to add or remove data, or a `SingletonStore` source for writable storage to set and clear a single element. + +As part of your data source declaration, you also import `org.kie.kogito.rules.DataSource` and the relevant data source support, such as `import org.kie.kogito.rules.DataStream` in this example. + +You can add several rules to the same DRL file, or further break down the rule set and type declarations by creating more files. However you construct your rule sets, ensure that all DRL rule files exist in the same directory and start with the correct `package` and `unit` declarations. + +== Rule unit use case + +As an additional rule unit use case, consider the following example decision service that evaluates incoming data from a heat sensor for temperature measurements and produces alerts when the temperature is above a specified threshold. + +This example service uses the following `types.drl` file in the `src/main/resources/org/acme` folder of the {PRODUCT} project to declare the `Temperature` and the `Alert` fact types: + +.Example DRL type declarations +[source] +---- +package com.acme; + +declare Temperature + value: double +end + +declare Alert + severity: String + message: String +end +---- + +To define DRL rules that pattern-match against `Temperature` values, the example service must expose an entry point for the incoming data to the {DECISION_ENGINE} and publish alerts on a separate channel. To establish this data source for decision data, the example service uses a rule unit with `DataStream` data sources for `Temperature` objects and for `Alert` objects. + +The `DataStream` data source is an append-only store for incoming data, similar to a queue. This type of data source is logical for both sources in this example because the temperature data is coming from an external source (the sensor) and the service publishes the alerts externally as they are produced. + +The example service uses the following `MonitoringService.drl` file in the same `src/main/resources/com/acme` folder of the {PRODUCT} project to declare the data sources for the fact types and defines the rules for the rule unit: + +.Example DRL rule unit file +[source] +---- +package com.acme; +unit MonitoringService; + +import org.kie.kogito.rules.DataSource; +import org.kie.kogito.rules.DataStream; + +declare MonitoringService extends RuleUnitData + temperature: DataStream = DataSource.createStream() + alertData: DataStream = DataSource.createStream() +end + +rule "tooHot" +when + $temp : /temperature[value >= 80] +then + alertData.append(new Alert("HIGH", "Temperature exceeds threshold: " + temp.value)); +end +---- + +The rule unit implements the required `RuleUnitData` interface and declares the data sources for the previously defined types. The sample rule raises an alert when the temperature reaches or exceeds 80 degrees. + +== Data sources for DRL rule units + +Data sources are typed sources of data that rule units can subscribe to for updates. You interact with the rule unit through the data sources it exposes. + +{PRODUCT} supports the following types of data sources. When you declare data sources in DRL rule files, the sources are internally rendered as shown in these examples. + +* `DataStream`: An append-only storage option. Use this storage option when you want to publish or share data values. You can use the notation `DataSource.createStream()` to return a `DataStream` object and use the method `append(T)` to add more data. ++ +.Example DataStream data source definition +[source,java] +---- +DataStream temperature = DataSource.createStream(); +// Append value and notify all subscribers +temperature.append(new Temperature(100)); +---- + +* `DataStore`: A writable storage option for adding or removing data and then notifying all subscribers that mutable data has been modified. Rules can pattern-match against incoming values and update or remove available values. +ifdef::KOGITO-COMM[] +For users familiar with {PRODUCT_DROOLS}, this option is equivalent to a typed version of an entry point. In fact, a `DataStore` is equivalent to an old-style entry point. +endif::[] ++ +.Example DataStore data source definition +[source,java] +---- +DataStore temperature = DataSource.createStore(); +Temperature temp = new Temperature(100); +// Add value `t` and notify all subscribers +DataHandle t = temperature.add(temp); +temp.setValue(50); +// Notify all subscribers that the value referenced by `t` has changed +temperature.update(t, temp); +// Remove value referenced by `t` and notify all subscribers +temperature.remove(t); +---- + +* `SingletonStore`: A writable storage option for setting or clearing a single element and then notifying all subscribers that the element has been modified. Rules can pattern-match against the value and update or clear available values. +ifdef::KOGITO-COMM[] +For users familiar with {PRODUCT_DROOLS}, this option is equivalent to a global. In fact, a `Singleton` is similar to an old-style global, except that when used in conjuction with rules, you can pattern-match against it. +endif::[] ++ +.Example SingletonStore data source definition +[source,java] +---- +SingletonStore temperature = DataSource.createSingleton(); +Temperature temp = new Temperature(100); +// Add value `temp` and notify all subscribers +temperature.set(temp); +temp.setValue(50); +// Notify all subscribers that the value has changed +temperature.update(); + +Temperature temp2 = new Temperature(200); +// Overwrite contained value with `temp2` and notify all subscribers +temperature.set(temp2); +temp2.setValue(150); +// Notify all subscribers that the value has changed +temperature.update(); + +// Clear store and notify all subscribers +temperature.clear(); +---- + +Subscribers to a data source are known as _data processors_. A data processor implements the `DataProcessor` interface. This interface contains callbacks to all the events that a subscribed data source can trigger. + +.Example DataStream data processor +[source,java] +---- +public interface DataProcessor { + void insert(DataHandle handle, T object); + void update(DataHandle handle, T object); + void delete(DataHandle handle); +} +---- + +The `DataHandle` method is an internal reference to an object of a data source. Each callaback method might or might not be invoked, depending on whether the corresponding data source implements the capability. For example, a `DataStream` source invokes only the `insert` callback, whereas a `SingletonStore` source invokes the `insert` callback on `set` and the `delete` callback on `clear` or before an overwriting `set`. + +== DRL rule unit declaration using Java + +As an alternative to declaring fact types and rule units in DRL files, you can also declare types and units using Java classes. In this case, you add the source code to the `src/main/java` folder of your {PRODUCT} project instead of `src/main/resources`. + +For example, the following Java classes define the type and rule unit declarations for the example temperature monitoring service: + +.Example Temperature class +[source,java] +---- +package com.acme; + +public class Temperature { + private final double value; + public Temperature(double value) { this.value = value; } + public double getValue() { return value; } +} +---- + +.Example Alert class +[source,java] +---- +package com.acme; + +public class Alert { + private final String severity + private final String message; + public Temperature(String severity, String message) { + this.severity = severity; + this.message = message; + } + public String getSeverity() { return severity; } + public String getMessage() { return message; } +} +---- + +.Example rule unit class +[source,java] +---- +package com.acme; + +import org.kie.kogito.rules.DataSource; +import org.kie.kogito.rules.DataStream; + +public class MonitoringService implements RuleUnitData { + private DataStream temperature = DataSource.createStream(); + private DataStream alertData = DataSource.createStream(); + public DataStream getTemperature() { return temperature; } + public DataStream getAlertData() { return alertData; } +} +---- + +In this scenario, the DRL rule files then stand alone in the `src/main/resources` folder and consist of the `unit` and the rules, with no direct declarations, as shown in the following example: + +.Example DRL rule unit file without declarations +[source] +---- +package com.acme; +unit MonitoringService; + +rule "tooHot" + when + $temp : /temperature[value >= 80] + then + alertData.append(new Alert("HIGH", "Temperature exceeds threshold: " + temp.value)); +end +---- + +== DRL rule units with BPMN processes + +If you use a DRL rule unit as part of a business rule task in a Business Process Model and Notation (BPMN) process in your {PRODUCT} project, you do not need to create an explicit data type declaration or a rule unit class that implements the `RuleUnitData` interface. Instead, you designate the rule unit in the DRL file as usual and specify the rule unit in the format `unit:__PACKAGE_NAME__.__UNIT_NAME__` in the implementation details for the business rule task in the BPMN process. When you build the project, the business process implicitly declares the rule unit as part of the business rule task to execute the DRL file. + +For example, the following is a DRL file with a rule unit designation: + +.Example DRL rule unit file +[source] +---- +package com.acme; +unit MonitoringService; + +rule "tooHot" + when + $temp : Temperature( value >= 80 ) from temperature + then + alertData.add(new Alert("HIGH", "Temperature exceeds threshold: " + temp.value)); +end +---- + +In the relevant business process in a BPMN 2.0 process modeler, you select the business rule task and for the *Implementation/Execution* property, you set the rule language to `DRL` and the rule flow group to `unit:com.acme.MonitoringService`. + +This rule unit syntax specifies that you are using the `com.acme.MonitoringService` rule unit instead of a traditional rule flow group. This is the rule unit that you referenced in the example DRL file. When you build the project, the business process implicitly declares the rule unit as part of the business rule task to execute the DRL file. diff --git a/assemblies/modules/decision-services/con-drl-rules-actions-advanced.adoc b/assemblies/modules/decision-services/con-drl-rules-actions-advanced.adoc new file mode 100644 index 0000000..6a04e89 --- /dev/null +++ b/assemblies/modules/decision-services/con-drl-rules-actions-advanced.adoc @@ -0,0 +1,102 @@ +[id='con-drl-rules-actions-advanced_{context}'] += Advanced rule actions with conditional and named consequences + +In general, effective rule actions are small, declarative, and readable. However, in some cases, the limitation of having a single consequence for each rule can be challenging and lead to verbose and repetitive rule syntax, as shown in the following example rules: + +.Example rules with verbose and repetitive syntax +[source] +---- +rule "Give 10% discount to customers older than 60" + when + $customer : Customer( age > 60 ) + then + modify($customer) { setDiscount( 0.1 ) }; +end + +rule "Give free parking to customers older than 60" + when + $customer : Customer( age > 60 ) + $car : Car( owner == $customer ) + then + modify($car) { setFreeParking( true ) }; +end +---- + +A partial solution to the repetition is to make the second rule extend the first rule, as shown in the following modified example: + +.Partially enhanced example rules with an extended condition +[source] +---- +rule "Give 10% discount to customers older than 60" + when + $customer : Customer( age > 60 ) + then + modify($customer) { setDiscount( 0.1 ) }; +end + +rule "Give free parking to customers older than 60" + extends "Give 10% discount to customers older than 60" + when + $car : Car( owner == $customer ) + then + modify($car) { setFreeParking( true ) }; +end +---- + +As a more efficient alternative, you can consolidate the two rules into a single rule with modified conditions and labelled corresponding rule actions, as shown in the following consolidated example: + +.Consolidated example rule with conditional and named consequences +[source] +---- +rule "Give 10% discount and free parking to customers older than 60" + when + $customer : Customer( age > 60 ) + do[giveDiscount] + $car : Car( owner == $customer ) + then + modify($car) { setFreeParking( true ) }; + then[giveDiscount] + modify($customer) { setDiscount( 0.1 ) }; +end +---- + +This example rule uses two actions: the usual default action and another action named `giveDiscount`. The `giveDiscount` action is activated in the condition with the keyword `do` when a customer older than 60 years old is found in the KIE base, regardless of whether or not the customer owns a car. + +You can configure the activation of a named consequence with an additional condition, such as the `if` statement in the following example. The condition in the `if` statement is always evaluated on the pattern that immediately precedes it. + +.Consolidated example rule with an additional condition +[source] +---- +rule "Give free parking to customers older than 60 and 10% discount to golden ones among them" + when + $customer : Customer( age > 60 ) + if ( type == "Golden" ) do[giveDiscount] + $car : Car( owner == $customer ) + then + modify($car) { setFreeParking( true ) }; + then[giveDiscount] + modify($customer) { setDiscount( 0.1 ) }; +end +---- + +You can also evaluate different rule conditions using a nested `if` and `else if` construct, as shown in the following more complex example: + +.Consolidated example rule with more complex conditions +[source] +---- +rule "Give free parking and 10% discount to over 60 Golden customer and 5% to Silver ones" + when + $customer : Customer( age > 60 ) + if ( type == "Golden" ) do[giveDiscount10] + else if ( type == "Silver" ) break[giveDiscount5] + $car : Car( owner == $customer ) + then + modify($car) { setFreeParking( true ) }; + then[giveDiscount10] + modify($customer) { setDiscount( 0.1 ) }; + then[giveDiscount5] + modify($customer) { setDiscount( 0.05 ) }; +end +---- + +This example rule gives a 10% discount and free parking to Golden customers over 60, but only a 5% discount without free parking to Silver customers. The rule activates the consequence named `giveDiscount5` with the keyword `break` instead of `do`. The keyword `do` schedules a consequence in the {DECISION_ENGINE} agenda, enabling the remaining part of the rule conditions to continue being evaluated, while `break` blocks any further condition evaluation. If a named consequence does not correspond to any condition with `do` but is activated with `break`, the rule fails to compile because the conditional part of the rule is never reached. diff --git a/assemblies/modules/decision-services/con-drl-rules-actions.adoc b/assemblies/modules/decision-services/con-drl-rules-actions.adoc new file mode 100644 index 0000000..56c1b98 --- /dev/null +++ b/assemblies/modules/decision-services/con-drl-rules-actions.adoc @@ -0,0 +1,21 @@ +[id='con-drl-rules-actions_{context}'] += Rule actions in DRL + +The `then` part of the rule (also known as the _Right Hand Side (RHS)_ of the rule) contains the actions to be performed when the conditional part of the rule has been met. Rule actions are typically determined by one or more _data sources_ that you define as part of your DRL rule unit. For example, if a bank requires loan applicants to have over 21 years of age (with a rule condition `/applicant[ applicantName : name, age < 21 ]`) and a loan applicant is under 21 years old, the `then` action of an `"Underage"` rule would be `setApproved( false )` based on a defined data source, declining the loan because the applicant is under age. + +The main purpose of rule actions is to to insert, delete, or modify data in the working memory of the {DECISION_ENGINE}. Effective rule actions are small, declarative, and readable. If you need to use imperative or conditional code in rule actions, then divide the rule into multiple smaller and more declarative rules. + +.Example rule for loan application age limit +[source] +---- +rule "Underage" + when + /applicant[ applicantName : name, age < 21 ] + $application : /loanApplication[ applicant == applicantName ] + then + $application.setApproved( false ); + $application.setExplanation( "Underage" ); +end +---- + +For more information about using data sources for rule actions, see xref:con-drl-rule-units_drl-rules[]. diff --git a/assemblies/modules/decision-services/con-drl-rules-comments.adoc b/assemblies/modules/decision-services/con-drl-rules-comments.adoc new file mode 100644 index 0000000..6c4e4a4 --- /dev/null +++ b/assemblies/modules/decision-services/con-drl-rules-comments.adoc @@ -0,0 +1,27 @@ +[id='con-drl-rules-comments_{context}'] += Comments in DRL files + +DRL supports single-line comments prefixed with a double forward slash `//` and multi-line comments enclosed with a forward slash and asterisk `/* ... */`. You can use DRL comments to annotate rules or any related components in DRL files. DRL comments are ignored by the {DECISION_ENGINE} when the DRL file is processed. + +.Example rule with comments +[source] +---- +rule "Underage" + // This is a single-line comment. + when + /applicant[ applicantName : name, age < 21 ] // This is an in-line comment + $application : /loanApplication[ applicant == applicantName ] + then + /* This is a multi-line comment + in the rule actions. */ + $application.setApproved( false ); + $application.setExplanation( "Underage" ); +end +---- + +ifdef::KOGITO-COMM[] +.Multi-line comment +image::kogito/drl/multi_line_comment.png[align="center"] +endif::[] + +IMPORTANT: The hash symbol `#` is not supported for DRL comments. diff --git a/assemblies/modules/decision-services/con-drl-rules-conditions.adoc b/assemblies/modules/decision-services/con-drl-rules-conditions.adoc new file mode 100644 index 0000000..1177f75 --- /dev/null +++ b/assemblies/modules/decision-services/con-drl-rules-conditions.adoc @@ -0,0 +1,448 @@ +[id='con-drl-rules-conditions_{context}'] += Rule conditions in DRL + +ifdef::KOGITO-COMM[] +.Rule +image::kogito/drl/rule.png[align="center"] + +.Conditional element in a rule +image::kogito/drl/lhs.png[align="center"] +endif::[] + +The `when` part of a DRL rule (also known as the _Left Hand Side (LHS)_ of the rule) contains the conditions that must be met to execute an action. Conditions consist of a series of stated OOPath expressions of patterns and constraints, with optional bindings and supported rule condition elements (keywords), based on the available data objects in the package. OOPath is an object-oriented syntax extension to XPath for navigating through related elements while handling collections and filtering constraints. + +For example, in a decision service that raises alerts when the temperature reaches or exceeds 80 degrees, a rule `tooHot` contains the `when` condition `/temperature[value >= 80]`. + +NOTE: DRL uses `when` instead of `if` because `if` is typically part of a procedural execution flow during which a condition is checked at a specific point in time. In contrast, `when` indicates that the condition evaluation is not limited to a specific evaluation sequence or point in time, but instead occurs continually at any time. Whenever the condition is met, the actions are executed. + +If the `when` section is empty, then the conditions are considered to be true and the actions in the `then` section are executed the first time the rules are fired. This is useful if you want to use rules to set up the {DECISION_ENGINE} state. + +The following example rule uses empty conditions to insert a fact every time the rule is executed: + +.Example rule without conditions +[source] +---- +rule "start-up" + when + // Empty + then // Actions to be executed once + alerts.add( new Alert("INFO", "System started") ); +end +---- + +Formally, the core grammar of an OOPath expression is defined in extended Backus-Naur form (EBNF) notation in the following way: + +.EBNF notation for OOPath expressions +[source] +---- +OOPExpr = [ID ( ":" | ":=" )] ( "/" | "?/" ) OOPSegment { ( "/" | "?/" | "." ) OOPSegment } ; +OOPSegment = ID ["#" ID] ["[" ( Number | Constraints ) "]"] +---- + +== OOPath expressions and constraints + +An _OOPath expression_ of a pattern in a DRL rule condition is the segment to be matched by the {DECISION_ENGINE}. An OOPath expression can potentially match each fact that is inserted into the working memory of the {DECISION_ENGINE}. It can also contain constraints to further define the facts to be matched. + +In the simplest form, with no constraints, an OOPath expression matches a fact in the given data source. In the following example with a `DataSource` named `person`, the expression matches against all `Person` objects in the data source of the {DECISION_ENGINE}: + +.Example expression for a single fact type +[source] +---- +/person +---- + +Patterns can also refer to superclasses or even interfaces, potentially matching facts from many different classes. For example, the following pattern matches all `Student` subtypes of the `Person` object: + +.Example pattern for subtypes +[source] +---- +/person # Student +---- + +Square brackets in a pattern enclose the constraints, such as the following constraint on the person's age: + +.Example pattern with a constraint +[source] +---- +/person[ age == 50 ] +---- + +A _constraint_ is an expression that returns `true` or `false`. Constraints in DRL are essentially Java expressions with some enhancements, such as property access, and some differences, such as `equals()` and `!equals()` semantics for `==` and `!=` (instead of the usual `same` and `not same` semantics). + +Any JavaBeans property can be accessed directly from pattern constraints. A JavaBeans property is exposed internally using a standard JavaBeans getter that takes no arguments and returns something. For example, the `age` property is written as `age` in DRL instead of the getter `getAge()`: + +.DRL constraint syntax with JavaBeans properties +[source] +---- +/person[ age == 50 ] + +// This is equivalent to the following getter format: + +/person[ getAge() == 50 ] +---- + +{PRODUCT} uses the standard JDK `Introspector` class to achieve this mapping and follows the standard JavaBeans specification. For optimal {DECISION_ENGINE} performance, use the property access format, such as `age`, instead of using getters explicitly, such as `getAge()`. + +[WARNING] +==== +Do not use property accessors to change the state of the object in a way that might affect the rules because the {DECISION_ENGINE} caches the results of the match between invocations for higher efficiency. + +For example, do not use property accessors in the following ways: + +[source,java] +---- +public int getAge() { + age++; // Do not do this. + return age; +} +---- + +[source,java] +---- +public int getAge() { + Date now = DateUtil.now(); // Do not do this. + return DateUtil.differenceInYears(now, birthday); +} +---- + +Instead of following the second example, insert a fact that wraps the current date in the working memory and update that fact between rule executions as needed. +==== + +However, if the getter of a property cannot be found, the compiler uses the property name as a fallback method name, without arguments: + +.Fallback method if object is not found +[source] +---- +/person[ age == 50 ] + +// If `Person.getAge()` does not exist, the compiler uses the following syntax: + +/person[ age() == 50 ] +---- + +You can also nest access properties in patterns, as shown in the following example. Nested properties are indexed by the {DECISION_ENGINE}. + +// FIXME: revisit this in the future +.Example pattern with nested property access +[source] +---- +/person[ address.houseNumber == 50 ] + +// This is equivalent to the following expression: + +/person[ getAddress().getHouseNumber() == 50 ] +---- + +// FIXME: revisit this in the future +// WARNING: In stateful KIE sessions, use nested accessors carefully because the working memory of the {DECISION_ENGINE} is not aware of any of the nested values and does not detect when they change. Either consider the nested values immutable while any of their parent references are inserted into the working memory, or, if you want to modify a nested value, mark all of the outer facts as updated. In the previous example, when the `houseNumber` property changes, any `Person` with that `Address` must be marked as updated. + +You can use any Java expression that returns a `boolean` value as a constraint inside the parentheses of a pattern. Java expressions can be mixed with other expression enhancements, such as property access: + +.Example pattern with a constraint using property access and Java expression +[source] +---- +/person[ age == 50 ] +---- + +You can change the evaluation priority by using parentheses, as in any logical or mathematical expression: + +.Example evaluation order of constraints +[source] +---- +/person[ age > 100 && ( age % 10 == 0 ) ] +---- + +You can also reuse Java methods in constraints, as shown in the following example: + +.Example constraints with reused Java methods +[source] +---- +/person[ Math.round( weight / ( height * height ) ) < 25.0 ] +---- + +[WARNING] +==== +Do not use constraints to change the state of the object in a way that might affect the rules because the {DECISION_ENGINE} caches the results of the match between invocations for higher efficiency. Any method that is executed on a fact in the rule conditions must be a read-only method. Also, the state of a fact should not change between rule invocations unless those facts are marked as updated in the working memory on every change. + +For example, do not use a pattern constraint in the following ways: + +[source] +---- +/person[ incrementAndGetAge() == 10 ] // Do not do this. +---- + +[source] +---- +/person[ System.currentTimeMillis() % 1000 == 0 ] // Do not do this. +---- +==== + +Standard Java operator precedence applies to constraint operators in DRL, and DRL operators follow standard Java semantics except for the `==` and `!=` operators. + +The `==` operator uses null-safe `equals()` semantics instead of the usual `same` semantics. For example, the pattern `/person[ firstName == "John" ]` is similar to `java.util.Objects.equals(person.getFirstName(), "John")`, and because `"John"` is not null, the pattern is also similar to `"John".equals(person.getFirstName())`. + +The `!=` operator uses null-safe `!equals()` semantics instead of the usual `not same` semantics. For example, the pattern `/person[ firstName != "John" ]` is similar to `!java.util.Objects.equals(person.getFirstName(), "John")`. + +If the field and the value of a constraint are of different types, the {DECISION_ENGINE} uses type coercion to resolve the conflict and reduce compilation errors. For instance, if `"ten"` is provided as a string in a numeric evaluator, a compilation error occurs, whereas `"10"` is coerced to a numeric 10. In coercion, the field type always takes precedence over the value type: + +.Example constraint with a value that is coerced +[source] +---- +/person[ age == "10" ] // "10" is coerced to 10 +---- + +For groups of constraints, you can use a delimiting comma `,` to use implicit `and` connective semantics: + +.Example patterns with multiple constraints +[source] +---- +// Person is at least 50 years old and weighs at least 80 kilograms: +/person[ age > 50, weight > 80 ] + +// Person is at least 50 years old, weighs at least 80 kilograms, and is taller than 2 meters: +/person[ age > 50, weight > 80, height > 2 ] +---- + +NOTE: Although the `&&` and `,` operators have the same semantics, they are resolved with different priorities. The `&&` operator precedes the `||` operator, and both the `&&` and `||` operators together precede the `,` operator. Use the comma operator at the top-level constraint for optimal {DECISION_ENGINE} performance and human readability. + +You cannot embed a comma operator in a composite constraint expression, such as in parentheses: + +.Example of misused comma in composite constraint expression +[source] +---- +// Do not use the following format: +/person[ ( age > 50, weight > 80 ) || height > 2 ] + +// Use the following format instead: +/person[ ( age > 50 && weight > 80 ) || height > 2 ] +---- + +== Bound variables in patterns and constraints + +You can bind variables to OOPath expressions of patterns and constraints to refer to matched objects in other portions of a rule. Bound variables can help you define rules more efficiently or more consistently with how you annotate facts in your data model. +// evacchi: I think the "new" convention is to drop $ sign +// To differentiate more easily between variables and fields in a rule, use the standard format `$__VARIABLE__` for variables, especially in complex rules. This convention is helpful but not required in DRL. + +For example, the following DRL rule uses the variable `$p` for an OOPath expression with the `Person` fact: + +.Pattern with a bound variable +[source] +---- +rule "simple rule" + when + $p : /person + then + System.out.println( "Person " + p ); +end +---- + +Similarly, you can also bind variables to nested properties, as shown in the following example: + +[source] +---- +// Two persons of the same age: +/person[ firstAge : age ] // Binding +and +/person[ age == firstAge ] // Constraint expression +---- + +[NOTE] +==== +Ensure that you separate constraint bindings and constraint expressions for clearer and more efficient rule definitions. Although mixed bindings and expressions are supported, they can complicate patterns and affect evaluation efficiency. + +[source] +---- +// Do not use the following format: +/person[ age : age * 2 < 100 ] + +// Use the following format instead: +/person[ age * 2 < 100, $age : age ] +---- +==== + + +// evacchi: not sure these are supported in OOPath maybe move it in the Pattern section + +// The {DECISION_ENGINE} does not support bindings to the same declaration, but does support _unification_ of arguments across several properties. While positional arguments are always processed with unification, the unification symbol `:=` exists for named arguments. + +// The following example patterns unify the `age` property across two `Person` facts: + +// .Example pattern with unification +// [source] +// ---- +// Person( $age := age ) +// Person( $age := age ) +// ---- + +// Unification declares a binding for the first occurrence and constrains to the same value of the bound field for sequence occurrences. + +== Nested constraints and inline casts + +In some cases, you might need to access multiple properties of a nested object, as shown in the following example: + +.Example pattern to access multiple properties +[source] +---- +/person[ name == "mark", address.city == "london", address.country == "uk" ] +---- + +You can group these property accessors to nested objects for more readable rules, as shown in the following example: + +.Example pattern with grouped constraints +[source] +---- +/person[ name == "mark"]/address[ city == "london", country == "uk" ] +---- + +When you work with nested objects, you can use the syntax `__TYPE__#__SUB_TYPE__` to cast to a subtype and make the getters from the parent type available to the subtype. You can use either the object name or fully qualified class name, and you can cast to one or multiple subtypes, as shown in the following examples: + +.Example patterns with inline casting to a subtype +[source] +---- +// Inline casting with subtype name: +/person[ name == "mark"]/address#LongAddress[ country == "uk" ] + +// Inline casting with fully qualified class name: +/person[ name == "mark"]/address#org.domain.LongAddress[ country == "uk" ] + +// Multiple inline casts: +/person[ name == "mark" ]/address#LongAddress/country#DetailedCountry[ population > 10000000 ] +---- + +These example patterns cast `Address` to `LongAddress`, and additionally to `DetailedCountry` in the last example, making the parent getters available to the subtypes in each case. + +// evacchi: not sure this works with oopath +// You can use the `instanceof` operator to infer the results of the specified type in subsequent uses of that field with the pattern, as shown in the following example: + +// [source] +// ---- +// Person( name == "mark", address instanceof LongAddress, address.country == "uk" ) +// ---- + +// If an inline cast is not possible (for example, if `instanceof` returns `false`), the evaluation is considered `false`. + +== Date literal in constraints + +By default, the {DECISION_ENGINE} supports the date format `dd-mmm-yyyy`. You can customize the date format, including a time format mask if needed, by providing an alternative format mask with the system property `drools.dateformat="dd-mmm-yyyy hh:mm"`. You can also customize the date format by changing the language locale with the `drools.defaultlanguage` and `drools.defaultcountry` system properties. For example, the locale of Thailand is set as `drools.defaultlanguage=th` and `drools.defaultcountry=TH`. + +.Example pattern with a date literal restriction +[source] +---- +/person[ bornBefore < "27-Oct-2009" ] +---- + +ifdef::KOGITO-COMM[] +== Auto-boxing and primitive types + +Drools attempts to preserve numbers in their primitive or object wrapper form, so a variable bound to an int primitive when used in a code block or expression will no longer need manual unboxing; unlike early Drools versions where all primitives were autoboxed, requiring manual unboxing. +A variable bound to an object wrapper will remain as an object; the existing JDK 1.5 and JDK 5 rules to handle auto-boxing and unboxing apply in this case. +When evaluating field constraints, the system attempts to coerce one of the values into a comparable format; so a primitive is comparable to an object wrapper. +endif::[] + +//// +//@comment evacchi: I am not sure the following sections still apply/work. I would hide for now (evacchi, 2020-03-16)*> + +== Other Features + +OOPath has several other advanced features. We report them here for completeness + +* Can backreference an object of the graph that was traversed before the currently iterated graph. For example, the following OOPath expression matches only the grades that are above the average for the passed exam: ++ +.Constraints with backreferenced object +[source] +---- +grade: /student/plan/exams/grades[ result > ../averageResult ] +---- +* Can recursively be another OOPath expression, as shown in the following example: ++ +.Recursive constraint expression +[source] +---- +exam: /student/plan/exams[ /grades[ result > 20 ] ] +---- +* Can access objects by their index between square brackets `[]`, as shown in the following example. To adhere to Java convention, OOPath indexes are 0-based, while XPath indexes are 1-based. ++ +.Constraints with access to objects by index +[source] +---- +grade: /student/plan/exams[0]/grades +---- + + + +== Object reactivity in OOPath expressions + +OOPath expressions can be reactive or non-reactive. The {DECISION_ENGINE} does not react to updates involving a deeply nested object that is traversed during the evaluation of an OOPath expression. + +To make these objects reactive to changes, modify the objects to extend the class `org.drools.core.phreak.ReactiveObject`. After you modify an object to extend the `ReactiveObject` class, the domain object invokes the inherited method `notifyModification` to notify the {DECISION_ENGINE} when one of the fields has been updated, as shown in the following example: + +.Example object method to notify the {DECISION_ENGINE} that an exam has been moved to a different course +[source,java] +---- +public void setCourse(String course) { + this.course = course; + notifyModification(this); +} +---- + +With the following corresponding OOPath expression, when an exam is moved to a different course, the rule is re-executed and the list of grades matching the rule is recomputed: + +.Example OOPath expression from "Big Data" rule +[source] +---- +$grade: /student/plan/exams[ course == "Big Data" ]/grades +---- + +You can also use the `?/` separator instead of the `/` separator to disable reactivity in only one sub-portion of an OOPath expression, as shown in the following example: + +.Example OOPath expression that is partially non-reactive +[source] +---- +$grade: /student/plan/exams[ course == "Big Data" ]?/grades +---- + +With this example, the {DECISION_ENGINE} reacts to a change made to an exam or if an exam is added to the plan, but not if a new grade is added to an existing exam. + +If an OOPath portion is non-reactive, all remaining portions of the OOPath expression also become non-reactive. For example, the following OOPath expression is completely non-reactive: + +.Example OOPath expression that is completely non-reactive +[source] +---- +$grade: /student?/plan/exams[ course == "Big Data" ]/grades ) +---- + +For this reason, you cannot use the `?/` separator more than once in the same OOPath expression. For example, the following expression causes a compilation error: + +.Example OOPath expression with duplicate non-reactivity markers +[source] +---- +$grade: /student/plan?/exams[ course == "Big Data" ]?/grades +---- + +Another alternative for enabling OOPath expression reactivity is to use the dedicated implementations for `List` and `Set` interfaces in {PRODUCT}. These implementations are the `ReactiveList` and `ReactiveSet` classes. A `ReactiveCollection` class is also available. The implementations also provide reactive support for performing mutable operations through the `Iterator` and `ListIterator` classes. + +The following example class uses these classes to configure OOPath expression reactivity: + +.Example Java class to configure OOPath expression reactivity +[source,java] +---- +public class School extends AbstractReactiveObject { + private String name; + private final List children = new ReactiveList(); // <1> + + public void setName(String name) { + this.name = name; + notifyModification(); // <2> + } + + public void addChild(Child child) { + children.add(child); // <3> + // No need to call `notifyModification()` here + } +} +---- +<1> Uses the `ReactiveList` instance for reactive support over the standard Java `List` instance. +<2> Uses the required `notifyModification()` method for when a field is changed in reactive support. +<3> The `children` field is a `ReactiveList` instance, so the `notifyModification()` method call is not required. The notification is handled automatically, like all other mutating operations performed over the `children` field. + +//// diff --git a/assemblies/modules/decision-services/con-drl-timers-calendars.adoc b/assemblies/modules/decision-services/con-drl-timers-calendars.adoc new file mode 100644 index 0000000..fa0c6e8 --- /dev/null +++ b/assemblies/modules/decision-services/con-drl-timers-calendars.adoc @@ -0,0 +1,175 @@ +[id='con-drl-timers-calendars_{context}'] += Timer and calendar rule attributes in DRL + +Timers and calendars are DRL rule attributes that enable you to apply scheduling and timing constraints to your DRL rules. These attributes require additional configurations depending on the use case. + +The `timer` attribute in DRL rules is a string identifying either `int` (interval) or `cron` timer definitions for scheduling a rule and supports the following formats: + +.Timer attribute formats +[source,subs=""+quotes"] +---- +timer ( int: __INITIAL_DELAY__ __REPEAT_INTERVAL__ ) + +timer ( cron: __CRON_EXPRESSION__ ) +---- + +.Example interval timer attributes +[source] +---- +// Run after a 30-second delay +timer ( int: 30s ) + +// Run every 5 minutes after a 30-second delay each time +timer ( int: 30s 5m ) +---- + +.Example cron timer attribute +[source] +---- +// Run every 15 minutes +timer ( cron:* 0/15 * * * ? ) +---- + +Interval timers follow the semantics of `java.util.Timer` objects, with an initial delay and an optional repeat interval. Cron timers follow standard Unix cron expressions. + +The following example DRL rule uses a cron timer to send an SMS text message every 15 minutes: + +.Example DRL rule with a cron timer +[source] +---- +rule "Send SMS message every 15 minutes" + timer ( cron:* 0/15 * * * ? ) + when + $a : Alarm( on == true ) + then + channels[ "sms" ].insert( new Sms( $a.mobileNumber, "The alarm is still on." ); +end +---- + +*<@Edoardo, see these paragraphs about active vs. passive modes (fireAllRules vs fireUntilHalt) and then configuring KIE session. Several other places in the DRL/engine content discusses active vs passive, fireAllRules, etc., so need some direction.>* + +Generally, a rule that is controlled by a timer becomes active when the rule is triggered and the rule consequence is executed repeatedly, according to the timer settings. The execution stops when the rule condition no longer matches incoming facts. However, the way the {DECISION_ENGINE} handles rules with timers depends on whether the {DECISION_ENGINE} is in _active mode_ or in _passive mode_. + +By default, the {DECISION_ENGINE} runs in _passive mode_ and evaluates rules, according to the defined timer settings, when a user or an application explicitly calls `fireAllRules()`. Conversely, if a user or application calls `fireUntilHalt()`, the {DECISION_ENGINE} starts in _active mode_ and evaluates rules continually until the user or application explicitly calls `halt()`. + +When the {DECISION_ENGINE} is in active mode, rule consequences are executed even after control returns from a call to `fireUntilHalt()` and the {DECISION_ENGINE} remains _reactive_ to any changes made to the working memory. For example, removing a fact that was involved in triggering the timer rule execution causes the repeated execution to terminate, and inserting a fact so that some rule matches causes that rule to be executed. However, the {DECISION_ENGINE} is not continually _active_, but is active only after a rule is executed. Therefore, the {DECISION_ENGINE} does not react to asynchronous fact insertions until the next execution of a timer-controlled rule. Disposing a KIE session terminates all timer activity. + +When the {DECISION_ENGINE} is in passive mode, rule consequences of timed rules are evaluated only when `fireAllRules()` is invoked again. However, you can change the default timer-execution behavior in passive mode by configuring the KIE session with a `TimedRuleExecutionOption` option, as shown in the following example: + +.KIE session configuration to automatically execute timed rules in passive mode +[source,java] +---- +KieSessionConfiguration ksconf = KieServices.Factory.get().newKieSessionConfiguration(); +ksconf.setOption( TimedRuleExecutionOption.YES ); +KSession ksession = kbase.newKieSession(ksconf, null); +---- + +You can additionally set a `FILTERED` specification on the `TimedRuleExecutionOption` option that enables you to define a +callback to filter those rules, as shown in the following example: + +.KIE session configuration to filter which timed rules are automatically executed +[source,java] +---- +KieSessionConfiguration ksconf = KieServices.Factory.get().newKieSessionConfiguration(); +conf.setOption( new TimedRuleExecutionOption.FILTERED(new TimedRuleExecutionFilter() { + public boolean accept(Rule[] rules) { + return rules[0].getName().equals("MyRule"); + } +}) ); +---- + +For interval timers, you can also use an expression timer with `expr` instead of `int` to define both the delay and interval as an expression instead of a fixed value. + +The following example DRL file declares a fact type with a delay and period that are then used in the subsequent rule with an expression timer: + +.Example rule with an expression timer +[source] +---- +declare Bean + delay : String = "30s" + period : long = 60000 +end + +rule "Expression timer" + timer ( expr: $d, $p ) + when + Bean( $d : delay, $p : period ) + then + // Actions +end +---- + +The expressions, such as `$d` and `$p` in this example, can use any variable defined in the pattern-matching part of the rule. The variable can be any `String` value that can be parsed into a time duration or any numeric value that is internally converted in a `long` value for a duration in milliseconds. + +Both interval and expression timers can use the following optional parameters: + +* `start` and `end`: A `Date` or a `String` representing a `Date` or a `long` value. The value can also be a `Number` that is transformed into a Java `Date` in the format `new Date( ((Number) n).longValue() )`. +* `repeat-limit`: An integer that defines the maximum number of repetitions allowed by the timer. If both the `end` and the `repeat-limit` parameters are set, the timer stops when the first of the two is reached. + +.Example timer attribute with optional `start`, `end`, and `repeat-limit` parameters +[source,java] +---- +timer (int: 30s 1h; start=3-JAN-2020, end=4-JAN-2020, repeat-limit=50) +---- + +In this example, the rule is scheduled for every hour, after a delay of 30 seconds each hour, beginning on 3 January 2020 and ending either on 4 January 2020 or when the cycle repeats 50 times. + +If the system is paused (for example, the session is serialized and then later deserialized), the rule is scheduled only one time to recover from missing activations regardless of how many activations were missed during the pause, and then the rule is subsequently scheduled again to continue in sync with the timer setting. + +The `calendar` attribute in DRL rules is a http://www.quartz-scheduler.org/[Quartz] calendar definition for scheduling a rule and supports the following format: + +.Calendar attribute format +[source,subs="+quotes"] +---- +calendars "__DEFINITION_OR_REGISTERED_NAME__" +---- + +.Example calendar attributes +[source] +---- +// Exclude non-business hours +calendars "* * 0-7,18-23 ? * *" + +// Weekdays only, as registered in the KIE session +calendars "weekday" +---- + +You can adapt a Quartz calendar based on the Quartz calendar API and then register the calendar in the KIE session, as shown in the following example: + +.Adapting a Quartz Calendar +[source,java] +---- +Calendar weekDayCal = QuartzHelper.quartzCalendarAdapter(org.quartz.Calendar quartzCal) +---- + +.Registering the calendar in the KIE session +[source,java] +---- +ksession.getCalendars().set( "weekday", weekDayCal ); +---- + +You can use calendars with standard rules and with rules that use timers. The calendar attribute can contain one or more comma-separated calendar names written as `String` literals. + +The following example rules use both calendars and timers to schedule the rules: + +.Example rules with calendars and timers +[source] +---- +rule "Weekdays are high priority" + calendars "weekday" + timer ( int:0 1h ) + when + Alarm() + then + send( "priority high - we have an alarm" ); +end + +rule "Weekends are low priority" + calendars "weekend" + timer ( int:0 4h ) + when + Alarm() + then + send( "priority low - we have an alarm" ); +end +---- diff --git a/assemblies/modules/decision-services/con-drl.adoc b/assemblies/modules/decision-services/con-drl.adoc new file mode 100644 index 0000000..400d3ac --- /dev/null +++ b/assemblies/modules/decision-services/con-drl.adoc @@ -0,0 +1,51 @@ +[id='con-drl_{context}'] += Drools Rule Language (DRL) + +Drools Rule Language (DRL) is a notation established by the https://www.drools.org/[Drools] open source business automation project for defining and describing business rules. You define DRL rules in `.drl` text files. A DRL file can contain one or more rules that define at a minimum the rule conditions (`when`) and actions (`then`). + +DRL files consist of the following components: + +.Components in a DRL file +[source,subs="attributes+"] +---- +package +unit + +import + +declare // Optional + +query // Optional + +rule "rule name" + // Attributes + when + // Conditions + then + // Actions +end + +rule "rule2 name" + +... + +---- + +The following example DRL rule determines the age limit in a loan application decision service: + +.Example rule for loan application age limit +[source] +---- +rule "Underage" + when + /applicant[ applicantName : name, age < 21 ] + $application : /loanApplication[ applicant == applicantName ] + then + $application.setApproved( false ); + $application.setExplanation( "Underage" ); +end +---- + +A DRL file can contain single or multiple rules and queries, and can define resource declarations and attributes that are assigned and used by your rules and queries. The components in a DRL file are grouped in a defined rule unit that serves as a unique namespace for each group of rules. The DRL package followed by the rule unit definition must be listed at the top of a DRL file, and the rules are typically listed last. All other DRL components can follow any order. + +Each rule must have a unique name within the rule unit. If you use the same rule name more than once in any DRL file in the unit, the rules fail to compile. Rule names generally must follow standard Java identifier conventions. However, you can enclose rule names with double quotation marks (`rule "rule name"`) to prevent possible compilation errors, especially if you use spaces in rule names. diff --git a/assemblies/modules/decision-services/proc-decision-tables-creating.adoc b/assemblies/modules/decision-services/proc-decision-tables-creating.adoc new file mode 100644 index 0000000..0b6f460 --- /dev/null +++ b/assemblies/modules/decision-services/proc-decision-tables-creating.adoc @@ -0,0 +1,84 @@ +[id='proc-decision-tables-creating_{context}'] += Creating spreadsheet decision tables for your {PRODUCT} project + +Spreadsheet decision tables (XLS or XLSX) require two key areas that define rule data: a `RuleSet` area and a `RuleTable` area. The `RuleSet` area of the spreadsheet defines elements that you want to apply globally to all rules in the same package (not only the spreadsheet), such as a rule set name or universal rule attributes. The `RuleTable` area defines the actual rules (rows) and the conditions, actions, and other rule attributes (columns) that constitute that rule table within the specified rule set. A spreadsheet of decision tables can contain multiple `RuleTable` areas, but only one `RuleSet` area. + +IMPORTANT: For each {PRODUCT} project, try to include only one spreadsheet of decision tables, containing all necessary `RuleTable` definitions. Although you can include separate decision table spreadsheets, including multiple spreadsheets in the same project package can cause compilation errors from conflicting `RuleSet` or `RuleTable` attributes and is therefore not recommended. + +Refer to the following sample spreadsheet as you define your decision table: + +.Sample spreadsheet decision table for shipping charges +image::kogito/decision-tables/decision-table-example-02.png[Decision table example] + +.Prerequisites +* You have added the following dependency to the `pom.xml` file of your {PRODUCT} project to enable decision tables for decision services: ++ +.Dependency to enable decision tables for decision services +---- + + org.kie.kogito + drools-decisiontables + +---- + +.Procedure +. In a new XLS or XLSX spreadsheet, go to the second or third column and label a cell `RuleSet` (row 1 in example). Reserve the column or columns to the left for descriptive metadata (optional). +. In the next cell to the right, enter a name for the `RuleSet`. This named rule set will contain all `RuleTable` rules defined in the rule package. +. Under the `RuleSet` cell, define any rule attributes (one per cell) that you want to apply globally to all rule tables in the package. Specify attribute values in the cells to the right. For example, you can enter an `Import` label and in the cell to the right, specify relevant data objects from other packages that you want to import into the package for the decision table (in the format `package.name.object.name`). For supported cell labels and values, see xref:ref-decision-tables-rule-set-entries_decision-tables[]. +. Below the `RuleSet` area and in the same column as the `RuleSet` cell, skip a row and label a new cell `RuleTable` (row 7 in example) and enter a table name in the same cell. The name is used as the initial part of the name for all rules derived from this rule table, with the row number appended for distinction. You can override this automatic naming by inserting a `NAME` attribute column. +. Use the next four rows to define the following elements as needed (rows 8-11 in example): ++ +* *Rule attributes:* Conditions, actions, or other attributes. For supported cell labels and values, see xref:ref-decision-tables-rule-table-entries_decision-tables[]. +* *Object types:* The data objects to which the rule attributes apply. If the same object type applies to multiple columns, merge the object cells into one cell across multiple columns (as shown in the sample decision table), instead of repeating the object type in multiple cells. When an object type is merged, all columns below the merged range will be combined into one set of constraints within a single pattern for matching a single fact at a time. When an object is repeated in separate columns, the separate columns can create different patterns, potentially matching different or identical facts. +* *Constraints:* Constraints on the object types. +* *Column label:* (Optional) Any descriptive label for the column, as a visual aid. Leave blank if unused. ++ +NOTE: As an alternative to populating both the object type and constraint cells, you can leave the object type cell or cells empty and enter the full expression in the corresponding constraint cell or cells. For example, instead of `Order` as the object type and `itemsCount > $1` as a constraint (separate cells), you can leave the object type cell empty and enter `Order( itemsCount > $1 )` in the constraint cell, and then do the same for other constraint cells. + ++ +. After you have defined all necessary rule attributes (columns), enter values for each column as needed, row by row, to generate rules (rows 12-17 in example). Cells with no data are ignored (such as when a condition or action does not apply). ++ +If you need to add more rule tables to this decision table spreadsheet, skip a row after the last rule in the previous table, label another `RuleTable` cell in the same column as the previous `RuleTable` and `RuleSet` cells, and create the new table following the same steps in this section (rows 19-29 in example). +. Save your XLS or XLSX spreadsheet to finish. +. In your VSCode IDE, import the XLS or XLSX spreadsheet file in the relevant folder of your {PRODUCT} project, typically in `src/main/resources`. + +NOTE: Only the first worksheet in a spreadsheet workbook is processed as a decision table when you include the spreadsheet in your {PRODUCT} project. Each `RuleSet` name combined with the `RuleTable` name must be unique across all decision table files in the same package. + +After you include the decision table in your {PRODUCT} project, the rules are rendered as DRL rules like the following example, from the sample spreadsheet: + +---- +//row 12 +rule "Basic_12" +salience 10 + when + $order : /orders[ itemsCount > 0, itemsCount <= 3, deliverInDays == 1 ] + then + insert( new Charge( 35 ) ); +end +---- + +[NOTE] +.Enabling white space used in cell values +==== +By default, any white space before or after values in decision table cells is removed before the decision table is processed by the {DECISION_ENGINE}. To retain white space that you use intentionally before or after values in cells, set the `drools.trimCellsInDTable` system property to `false` in the `application.properties` file of your {PRODUCT} project: + +.Enable white space in `application.properties` +[source] +---- +drools.trimCellsInDTable=false +---- + +You can also set this property as a start-up option when you build your {PRODUCT} project: + +.On Quarkus +[source] +---- +mvn compile quarkus:dev -Ddrools.trimCellsInDTable=false +---- + +.On Spring Boot +[source] +---- +mvn spring-boot:run -Ddrools.trimCellsInDTable=false +---- +==== diff --git a/assemblies/modules/decision-services/proc-dmn-data-types-defining.adoc b/assemblies/modules/decision-services/proc-dmn-data-types-defining.adoc new file mode 100644 index 0000000..d69367f --- /dev/null +++ b/assemblies/modules/decision-services/proc-dmn-data-types-defining.adoc @@ -0,0 +1,125 @@ +[id='proc-dmn-data-types-defining_{context}'] += Creating custom data types for DMN boxed expressions in the {PRODUCT} DMN modeler + +In DMN boxed expressions in the {PRODUCT} DMN modeler, data types determine the structure of the data that you use within an associated table, column, or field in the boxed expression. You can use default DMN data types (such as String, Number, Boolean) or you can create custom data types to specify additional fields and constraints that you want to implement for the boxed expression values. + +Custom data types that you create for a boxed expression can be simple or structured: + +* *Simple* data types have only a name and a type assignment. Example: `Age (number)`. +* *Structured* data types contain multiple fields associated with a parent data type. Example: A single type `Person` containing the fields `Name (string)`, `Age (number)`, `Email (string)`. + +.Prerequisites +* A DMN file is created or imported in your {PRODUCT} project in VSCode. + +.Procedure +. In your VSCode IDE, open the DMN file to view the decision requirements diagram (DRD) in the {PRODUCT} DMN modeler. ++ +-- +If the DRD does not open in the {PRODUCT} DMN modeler, ensure that you have installed and enabled the {PRODUCT} https://github.com/kiegroup/kogito-tooling/releases[VSCode extension]. + +If the {PRODUCT} DMN modeler opens only the XML source of the DMN file and displays an error message, review the reported errors and the DMN model file to ensure that all DMN elements are correctly defined. +-- +. In the DMN modeler canvas, select a decision node or business knowledge model for which you want to define the data types and click the *Edit* icon to open the DMN boxed expression editor. +. If the boxed expression is for a decision node that is not yet defined, click the undefined table to select the type of boxed expression you want to use, such as a boxed literal expression, boxed context expression, decision table, or other DMN boxed expression. ++ +.Selecting the logic type for a decision node +image::kogito/dmn/dmn-decision-boxed-expression-options.png[] + +. Click the cell for the table header, column header, or parameter field (depending on the boxed expression type) for which you want to define the data type and click *Manage* to go to the *Data Types* page where you can create a custom data type. ++ +-- +.Managing data types for a column header value +image::kogito/dmn/dmn-manage-data-types.png[] + +You can also set and manage custom data types for a specified decision node or business knowledge model node by selecting the *Properties* icon in the upper-right corner of the DMN modeler: + +.Managing data types in decision requirements diagram (DRD) properties +image::kogito/dmn/dmn-manage-data-types1a.png[] + +The data type that you define for a specified cell in a boxed expression determines the structure of the data that you use within that associated table, column, or field in the boxed expression. + +In this example, an output column *Credit Score Rating* for a DMN decision table defines a set of custom credit score ratings based on an applicant's credit score. +-- +. On the *Data Types* page, click *New Data Type* to add a new data type. ++ +-- +For this example, click *New Data Type* and create a *Credit_Score_Rating* data type as a `string`: + +.Adding a new data type +image::kogito/dmn/dmn-custom-data-type-add.png[] + +If the data type requires a list of items, enable the *List* setting. +-- +. Click *Add Constraints*, select *Enumeration* from the drop-down options, and add the following constraints: ++ +-- +* `"Excellent"` +* `"Good"` +* `"Fair"` +* `"Poor"` +* `"Bad"` + +.Adding constraints to the new data type +image::kogito/dmn/dmn-custom-data-type-constraints.png[] + +To change the order of data type constraints, you can click the left end of the constraint row and drag the row as needed: + +.Dragging constraints to change constraint order +image::kogito/dmn/dmn-custom-data-type-constraints-drag.png[] + +For information about constraint types and syntax requirements for the specified data type, see the https://www.omg.org/spec/DMN[Decision Model and Notation specification]. +-- + +. Click *OK* to save the constraints and click the check mark to the right of the data type to save the data type. + +. Return to the *Credit Score Rating* decision table, click the *Credit Score Rating* column header, set the data type to this new custom data type, and define the rule values for that column with the rating constraints that you specified. ++ +-- +.Decision table for credit score rating +image::kogito/dmn/dmn-decision-table-example1a.png[] + +In the DMN decision model for this scenario, the *Credit Score Rating* decision flows into the following *Loan Prequalification* decision that also requires custom data types: + +.Decision table for loan prequalification +image::kogito/dmn/dmn-manage-data-types-blank.png[] +-- +. Continuing with this example, return to the *Data Types* window, click *New Data Type*, and create a *Loan_Qualification* data type as a `Structure` with no constraints. ++ +-- +When you save the new structured data type, the first sub-field appears so that you can begin defining nested data fields in this parent data type. You can use these sub-fields in association with the parent structured data type in boxed expressions, such as nested column headers in decision tables or nested table parameters in context or function expressions. + +For additional sub-fields, select the addition icon next to the *Loan_Qualification* data type: + +.Adding a new structured data type with nested fields +image::kogito/dmn/dmn-manage-data-types-structured.png[] +-- +. For this example, under the structured *Loan_Qualification* data type, add a *Qualification* field with `"Qualified"` and `"Not Qualified"` enumeration constraints, and a *Reason* field with no constraints. Add also a simple *Back_End_Ratio* and a *Front_End_Ratio* data type, both with `"Sufficient"` and `"Insufficient"` enumeration constraints. ++ +-- +Click the check mark to the right of each data type that you create to save your changes. + +.Adding nested data types with constraints +image::kogito/dmn/dmn-manage-data-types-structured2.png[] + +To change the order or nesting of data types, you can click the left end of the data type row and drag the row as needed: + +.Dragging data types to change data type order or nesting +image::kogito/dmn/dmn-manage-data-types-structured2-drag.png[] +-- +. Return to the decision table and, for each column, click the column header cell, set the data type to the new corresponding custom data type, and define the rule values as needed for the column with the constraints that you specified, if applicable. ++ +.Decision table for loan prequalification +image::kogito/dmn/dmn-decision-table-example3.png[] + +For boxed expression types other than decision tables, you follow these guidelines similarly to navigate the boxed expression tables and define custom data types as needed. + +For example, the following boxed function expression uses custom `tCandidate` and `tProfile` structured data types to associate data for online dating compatibility: + +.Boxed function expression for online dating compatibility +image::kogito/dmn/dmn-manage-data-types-structured3.png[] + +.Custom data type definitions for online dating compatibility +image::kogito/dmn/dmn-manage-data-types-structured3a.png[] + +.Parameter definitions with custom data types for online dating compatibility +image::kogito/dmn/dmn-manage-data-types-structured3b.png[] diff --git a/assemblies/modules/decision-services/proc-dmn-execution-embedded.adoc b/assemblies/modules/decision-services/proc-dmn-execution-embedded.adoc new file mode 100644 index 0000000..d8fda7c --- /dev/null +++ b/assemblies/modules/decision-services/proc-dmn-execution-embedded.adoc @@ -0,0 +1,157 @@ +[id='proc-dmn-execution-embedded_{context}'] += Embedding a DMN call directly in a Java application + +A KIE container is local when the knowledge assets are either embedded directly into the calling program or are physically pulled in using Maven dependencies for the KJAR. You typically embed knowledge assets directly into a project if there is a tight relationship between the version of the code and the version of the DMN definition. Any changes to the decision take effect after you have intentionally updated and redeployed the application. A benefit of this approach is that proper operation does not rely on any external dependencies to the run time, which can be a limitation of locked-down environments. + +Using Maven dependencies enables further flexibility because the specific version of the decision can dynamically change, (for example, by using a system property), and it can be periodically scanned for updates and automatically updated. This introduces an external dependency on the deploy time of the service, but executes the decision locally, reducing reliance on an external service being available during run time. + +.Prerequisites +* {KIE_SERVER} is installed and configured, including a known user name and credentials for a user with the `kie-server` role. For installation options, see +ifdef::DM,PAM[] +{URL_PLANNING_INSTALL}[_{PLANNING_INSTALL}_]. +endif::[] +ifdef::DROOLS,JBPM,OP[] +<<_installationandsetup>>. +endif::[] +* You have built the DMN project as a KJAR artifact and deployed it to {KIE_SERVER}. Ideally, you have built the DMN project as an executable model for more efficient execution: ++ +-- +[source] +---- +mvn clean install -DgenerateDMNModel=yes +---- + +For more information about project packaging and deployment and executable models, see +ifdef::DM,PAM[] +{URL_PACKAGING_DEPLOYING_PROJECT}[_{PACKAGING_DEPLOYING_PROJECT}_]. +endif::[] +ifdef::DROOLS,JBPM,OP[] +<<_builddeployutilizeandrunsection>>. +endif::[] +-- + +.Procedure +. In your client application, add the following dependencies to the relevant classpath of your Java project: ++ +-- +[source,xml,subs="attributes+"] +---- + + + org.kie + kie-dmn-core + ${{PRODUCT_INIT}.version} + + + + + org.kie + kie-ci + ${{PRODUCT_INIT}.version} + +---- + +The `` is the Maven artifact version for {PRODUCT} currently used in your project (for example, {MAVEN_ARTIFACT_VERSION}). + +ifdef::DM,PAM[] +[NOTE] +==== +Instead of specifying a {PRODUCT} `` for individual dependencies, consider adding the {PRODUCT_BA} bill of materials (BOM) dependency to your project `pom.xml` file. The {PRODUCT_BA} BOM applies to both {PRODUCT_DM} and {PRODUCT_PAM}. When you add the BOM files, the correct versions of transitive dependencies from the provided Maven repositories are included in the project. + +Example BOM dependency: + +[source,xml,subs="attributes+"] +---- + + com.redhat.ba + ba-platform-bom + {BOM_VERSION} + import + pom + +---- + +For more information about the {PRODUCT_BA} BOM, see +ifdef::PAM[] +https://access.redhat.com/solutions/3405361[What is the mapping between RHPAM product and maven library version?]. +endif::[] +ifdef::DM[] +https://access.redhat.com/solutions/3363991[What is the mapping between RHDM product and maven library version?]. +endif::[] +==== +endif::DM,PAM[] +-- +. Create a KIE container from `classpath` or `ReleaseId`: ++ +[source,java] +---- +KieServices kieServices = KieServices.Factory.get(); + +ReleaseId releaseId = kieServices.newReleaseId( "org.acme", "my-kjar", "1.0.0" ); +KieContainer kieContainer = kieServices.newKieContainer( releaseId ); +---- ++ +Alternative option: ++ +[source,java] +---- +KieServices kieServices = KieServices.Factory.get(); + +KieContainer kieContainer = kieServices.getKieClasspathContainer(); +---- + +. Obtain `DMNRuntime` from the KIE container and a reference to the DMN model to be evaluated, by using the model `namespace` and `modelName`: ++ +[source,java] +---- +DMNRuntime dmnRuntime = KieRuntimeFactory.of(kieContainer.getKieBase()).get(DMNRuntime.class); + +String namespace = "http://www.redhat.com/_c7328033-c355-43cd-b616-0aceef80e52a"; +String modelName = "dmn-movieticket-ageclassification"; + +DMNModel dmnModel = dmnRuntime.getModel(namespace, modelName); +---- + +. Execute the decision services for the desired model: ++ +[source,java] +---- +DMNContext dmnContext = dmnRuntime.newContext(); // <1> + +for (Integer age : Arrays.asList(1,12,13,64,65,66)) { + dmnContext.set("Age", age); // <2> + DMNResult dmnResult = + dmnRuntime.evaluateAll(dmnModel, dmnContext); // <3> + + for (DMNDecisionResult dr : dmnResult.getDecisionResults()) { // <4> + log.info("Age: " + age + ", " + + "Decision: '" + dr.getDecisionName() + "', " + + "Result: " + dr.getResult()); + } +} +---- +<1> Instantiate a new DMN Context to be the input for the model evaluation. Note that this example is looping through the Age Classification decision multiple times. +<2> Assign input variables for the input DMN context. +<3> Evaluate all DMN decisions defined in the DMN model. +<4> Each evaluation may result in one or more results, creating the loop. ++ +-- + +This example prints the following output: + +---- +Age 1 Decision 'AgeClassification' : Child +Age 12 Decision 'AgeClassification' : Child +Age 13 Decision 'AgeClassification' : Adult +Age 64 Decision 'AgeClassification' : Adult +Age 65 Decision 'AgeClassification' : Senior +Age 66 Decision 'AgeClassification' : Senior +---- + +If the DMN model was not previously compiled as an executable model for more efficient execution, you can enable the following property when you execute your DMN models: + +[source] +---- +-Dorg.kie.dmn.compiler.execmodel=true +---- +-- diff --git a/assemblies/modules/decision-services/proc-dmn-execution-remote-java.adoc b/assemblies/modules/decision-services/proc-dmn-execution-remote-java.adoc new file mode 100644 index 0000000..6d3faff --- /dev/null +++ b/assemblies/modules/decision-services/proc-dmn-execution-remote-java.adoc @@ -0,0 +1,150 @@ +[id='proc-dmn-execution-remote-java_{context}'] += Executing a DMN service using the {KIE_SERVER} Java client API + +The {KIE_SERVER} Java client API provides a lightweight approach to invoking a remote DMN service either through the REST or JMS interfaces of {KIE_SERVER}. This approach reduces the number of runtime dependencies necessary to interact with a KIE base. Decoupling the calling code from the decision definition also increases flexibility by enabling them to iterate independently at the appropriate pace. + +For more information about the {KIE_SERVER} Java client API, see +ifdef::DM,PAM[] +{URL_KIE_APIS}[_{KIE_APIS}_]. +endif::[] +ifdef::DROOLS,JBPM,OP[] +xref:kie-server-java-api-con-kie-apis[]. +endif::[] + +.Prerequisites +* {KIE_SERVER} is installed and configured, including a known user name and credentials for a user with the `kie-server` role. For installation options, see +ifdef::DM,PAM[] +{URL_PLANNING_INSTALL}[_{PLANNING_INSTALL}_]. +endif::[] +ifdef::DROOLS,JBPM,OP[] +<<_installationandsetup>>. +endif::[] +* You have built the DMN project as a KJAR artifact and deployed it to {KIE_SERVER}. Ideally, you have built the DMN project as an executable model for more efficient execution: ++ +-- +[source] +---- +mvn clean install -DgenerateDMNModel=yes +---- + +For more information about project packaging and deployment and executable models, see +ifdef::DM,PAM[] +{URL_PACKAGING_DEPLOYING_PROJECT}[_{PACKAGING_DEPLOYING_PROJECT}_]. +endif::[] +ifdef::DROOLS,JBPM,OP[] +<<_builddeployutilizeandrunsection>>. +endif::[] +-- +* You have the ID of the KIE container containing the DMN model. If more than one model is present, you must also know the model namespace and model name of the relevant model. + +.Procedure +. In your client application, add the following dependency to the relevant classpath of your Java project: ++ +-- +[source,xml,subs="attributes+"] +---- + + + org.kie.server + kie-server-client + ${{PRODUCT_INIT}.version} + +---- + +The `` is the Maven artifact version for {PRODUCT} currently used in your project (for example, {MAVEN_ARTIFACT_VERSION}). + +ifdef::DM,PAM[] +[NOTE] +==== +Instead of specifying a {PRODUCT} `` for individual dependencies, consider adding the {PRODUCT_BA} bill of materials (BOM) dependency to your project `pom.xml` file. The {PRODUCT_BA} BOM applies to both {PRODUCT_DM} and {PRODUCT_PAM}. When you add the BOM files, the correct versions of transitive dependencies from the provided Maven repositories are included in the project. + +Example BOM dependency: + +[source,xml,subs="attributes+"] +---- + + com.redhat.ba + ba-platform-bom + {BOM_VERSION} + import + pom + +---- + +For more information about the {PRODUCT_BA} BOM, see +ifdef::PAM[] +https://access.redhat.com/solutions/3405361[What is the mapping between RHPAM product and maven library version?]. +endif::[] +ifdef::DM[] +https://access.redhat.com/solutions/3363991[What is the mapping between RHDM product and maven library version?]. +endif::[] +==== +endif::DM,PAM[] +-- +. Instantiate a `KieServicesClient` instance with the appropriate connection information. ++ +-- +Example: + +[source,java] +---- +KieServicesConfiguration conf = + KieServicesFactory.newRestConfiguration(URL, USER, PASSWORD); // <1> + +conf.setMarshallingFormat(MarshallingFormat.JSON); // <2> + +KieServicesClient kieServicesClient = KieServicesFactory.newKieServicesClient(conf); +---- +<1> The connection information: +* Example URL: `\http://localhost:8080/kie-server/services/rest/server` +* The credentials should reference a user with the `kie-server` role. +<2> The Marshalling format is an instance of `org.kie.server.api.marshalling.MarshallingFormat`. It controls whether the messages will be JSON or XML. Options for Marshalling format are JSON, JAXB, or XSTREAM. +-- +. Obtain a `DMNServicesClient` from the KIE server Java client connected to the related {KIE_SERVER} by invoking the method `getServicesClient()` on the KIE server Java client instance: ++ +[source,java] +---- +DMNServicesClient dmnClient = kieServicesClient.getServicesClient(DMNServicesClient.class ); +---- ++ +The `dmnClient` can now execute decision services on {KIE_SERVER}. + +. Execute the decision services for the desired model. ++ +-- +Example: + +[source,java] +---- +for (Integer age : Arrays.asList(1,12,13,64,65,66)) { + DMNContext dmnContext = dmnClient.newContext(); // <1> + dmnContext.set("Age", age); // <2> + ServiceResponse serverResp = // <3> + dmnClient.evaluateAll($kieContainerId, + $modelNamespace, + $modelName, + dmnContext); + + DMNResult dmnResult = serverResp.getResult(); // <4> + for (DMNDecisionResult dr : dmnResult.getDecisionResults()) { + log.info("Age: " + age + ", " + + "Decision: '" + dr.getDecisionName() + "', " + + "Result: " + dr.getResult()); + } +} +---- +<1> Instantiate a new DMN Context to be the input for the model evaluation. Note that this example is looping through the Age Classification decision multiple times. +<2> Assign input variables for the input DMN Context. +<3> Evaluate all the DMN Decisions defined in the DMN model: +* `$kieContainerId` is the ID of the container where the KJAR containing the DMN model is deployed +* `$modelNamespace` is the namespace for the model. +* `$modelName` is the name for the model. +<4> The DMN Result object is available from the server response. + +At this point, the `dmnResult` contains all the decision results from the evaluated DMN model. + +You can also execute only a specific DMN decision in the model by using alternative methods of the `DMNServicesClient`. + +NOTE: If the KIE container only contains one DMN model, you can omit `$modelNamespace` and `$modelName` because the {KIE_SERVER} API selects it by default. + +-- diff --git a/assemblies/modules/decision-services/proc-dmn-execution-rest.adoc b/assemblies/modules/decision-services/proc-dmn-execution-rest.adoc new file mode 100644 index 0000000..c977f4c --- /dev/null +++ b/assemblies/modules/decision-services/proc-dmn-execution-rest.adoc @@ -0,0 +1,883 @@ +[id='proc-dmn-execution-rest_{context}'] += Executing a DMN service using the {KIE_SERVER} REST API + +Directly interacting with the REST endpoints of {KIE_SERVER} provides the most separation between the calling code and the decision logic definition. The calling code is completely free of direct dependencies, and you can implement it in an entirely different development platform such as `Node.js` or `.NET`. The examples in this section demonstrate Nix-style curl commands but provide relevant information to adapt to any REST client. + +For more information about the {KIE_SERVER} REST API, see +ifdef::DM,PAM[] +{URL_KIE_APIS}[_{KIE_APIS}_]. +endif::[] +ifdef::DROOLS,JBPM,OP[] +xref:kie-server-rest-api-con-kie-apis[]. +endif::[] + +.Prerequisites +* {KIE_SERVER} is installed and configured, including a known user name and credentials for a user with the `kie-server` role. For installation options, see +ifdef::DM,PAM[] +{URL_PLANNING_INSTALL}[_{PLANNING_INSTALL}_]. +endif::[] +ifdef::DROOLS,JBPM,OP[] +<<_installationandsetup>>. +endif::[] +* You have built the DMN project as a KJAR artifact and deployed it to {KIE_SERVER}. Ideally, you have built the DMN project as an executable model for more efficient execution: ++ +-- +[source] +---- +mvn clean install -DgenerateDMNModel=yes +---- + +For more information about project packaging and deployment and executable models, see +ifdef::DM,PAM[] +{URL_PACKAGING_DEPLOYING_PROJECT}[_{PACKAGING_DEPLOYING_PROJECT}_]. +endif::[] +ifdef::DROOLS,JBPM,OP[] +<<_builddeployutilizeandrunsection>>. +endif::[] +-- +* You have the ID of the KIE container containing the DMN model. If more than one model is present, you must also know the model namespace and model name of the relevant model. + +.Procedure +. Determine the base URL for accessing the {KIE_SERVER} REST API endpoints. This requires knowing the following values (with the default local deployment values as an example): ++ +-- +* Host (`localhost`) +* Port (`8080`) +* Root context (`kie-server`) +* Base REST path (`services/rest/`) + +ifeval::["{context}" == "kogito-dmn-models"] +Example base URL in local deployment: + +`\http://localhost:8080/kie-server/services/rest/` +endif::[] + +ifeval::["{context}" == "decision-service-getting-started"] +Example base URL in local deployment for the traffic violations project: + +`\http://localhost:8080/kie-server/services/rest/server/containers/traffic-violation_1.0.0` +endif::[] +-- +. Determine user authentication requirements. ++ +When users are defined directly in the {KIE_SERVER} configuration, HTTP Basic authentication is used and requires the user name and password. Successful requests require that the user have the `kie-server` role. ++ +The following example demonstrates how to add credentials to a curl request: ++ +[source] +---- +curl -u username:password +---- ++ +If {KIE_SERVER} is configured with Red Hat Single Sign-On, the request must include a bearer token: ++ +[source,java] +---- +curl -H "Authorization: bearer $TOKEN" +---- + +. Specify the format of the request and response. The REST API endpoints work with both JSON and XML formats and are set using request headers: ++ +.JSON +[source] +---- +curl -H "accept: application/json" -H "content-type: application/json" +---- ++ +.XML +[source] +---- +curl -H "accept: application/xml" -H "content-type: application/xml" +---- + +. (Optional) Query the container for a list of deployed decision models: ++ +-- +*[GET]* `server/containers/{containerId}/dmn` + +Example curl request: + +ifeval::["{context}" == "kogito-dmn-models"] +[source] +---- +curl -u krisv:krisv -H "accept: application/xml" -X GET "http://localhost:8080/kie-server/services/rest/server/containers/MovieDMNContainer/dmn" +---- + +Sample XML output: + +[source,xml] +---- + + + + + http://www.redhat.com/_c7328033-c355-43cd-b616-0aceef80e52a + dmn-movieticket-ageclassification + _99 + + + _3 + AgeClassification + + + + + +---- + +Sample JSON output: + +[source,json] +---- +{ + "type" : "SUCCESS", + "msg" : "OK models successfully retrieved from container 'MovieDMNContainer'", + "result" : { + "dmn-model-info-list" : { + "models" : [ { + "model-namespace" : "http://www.redhat.com/_c7328033-c355-43cd-b616-0aceef80e52a", + "model-name" : "dmn-movieticket-ageclassification", + "model-id" : "_99", + "decisions" : [ { + "decision-id" : "_3", + "decision-name" : "AgeClassification" + } ] + } ] + } + } +} +---- +-- +endif::[] +ifeval::["{context}" == "decision-service-getting-started"] +[source] +---- +curl -u wbadmin:wbadmin -H "accept: application/xml" -X GET "http://localhost:8080/kie-server/services/rest/server/containers/traffic-violation_1.0.0/dmn" +---- + +Sample XML output: + +[source,xml] +---- + + + + + https://github.com/kiegroup/drools/kie-dmn/_60b01f4d-e407-43f7-848e-258723b5fac8 + Traffic Violation + _2CD7D1AA-BD84-4B43-AD21-B0342ADE655A + + + _23428EE8-DC8B-4067-8E67-9D7C53EC975F + Fine + + + _B5EEE2B1-915C-44DC-BE43-C244DC066FD8 + Should the driver be suspended? + + + + + _CEB959CD-3638-4A87-93BA-03CD0FB63AE3 + Violation + + https://github.com/kiegroup/drools/kie-dmn/_60B01F4D-E407-43F7-848E-258723B5FAC8 + tViolation + + + + + _B0E810E6-7596-430A-B5CF-67CE16863B6C + Driver + + https://github.com/kiegroup/drools/kie-dmn/_60B01F4D-E407-43F7-848E-258723B5FAC8 + tDriver + + + + + + + _9C758F4A-7D72-4D0F-B63F-2F5B8405980E + tViolation + + + _0B6FF1E2-ACE9-4FB3-876B-5BB30B88009B + Code + + https://github.com/kiegroup/drools/kie-dmn/_60b01f4d-e407-43f7-848e-258723b5fac8 + string + + + + false + + + _27A5DA18-3CA7-4C06-81B7-CF7F2F050E29 + date + + https://github.com/kiegroup/drools/kie-dmn/_60B01F4D-E407-43F7-848E-258723B5FAC8 + date + + + + false + + + _8961969A-8A80-4F12-B568-346920C0F038 + type + + https://github.com/kiegroup/drools/kie-dmn/_60B01F4D-E407-43F7-848E-258723B5FAC8 + string + + + + false + + + _7450F12A-3E95-4D5E-8DCE-2CB1FAC2BDD4 + speed limit + + https://github.com/kiegroup/drools/kie-dmn/_60b01f4d-e407-43f7-848e-258723b5fac8 + number + + + + false + + + _0A9A6F26-6C14-414D-A9BF-765E5850429A + Actual Speed + + https://github.com/kiegroup/drools/kie-dmn/_60B01F4D-E407-43F7-848E-258723B5FAC8 + number + + + + false + + + false + + + _13C7EFD8-B85C-43BF-94D3-14FABE39A4A0 + tDriver + + + _EC11744C-4160-4549-9610-2C757F40DFE8 + Name + + https://github.com/kiegroup/drools/kie-dmn/_60B01F4D-E407-43F7-848E-258723B5FAC8 + string + + + + false + + + _E95BE3DB-4A51-4658-A166-02493EAAC9D2 + Age + + https://github.com/kiegroup/drools/kie-dmn/_60B01F4D-E407-43F7-848E-258723B5FAC8 + number + + + + false + + + _7B3023E2-BC44-4BF3-BF7E-773C240FB9AD + State + + https://github.com/kiegroup/drools/kie-dmn/_60B01F4D-E407-43F7-848E-258723B5FAC8 + string + + + + false + + + _3D4B49DD-700C-4925-99A7-3B2B873F7800 + city + + https://github.com/kiegroup/drools/kie-dmn/_60B01F4D-E407-43F7-848E-258723B5FAC8 + string + + + + false + + + _B37C49E8-B0D9-4B20-9DC6-D655BB1CA7B1 + Points + + https://github.com/kiegroup/drools/kie-dmn/_60B01F4D-E407-43F7-848E-258723B5FAC8 + number + + + + false + + + false + + + _A4077C7E-B57A-4DEE-9C65-7769636316F3 + tFine + + + _79B152A8-DE83-4001-B88B-52DFF0D73B2D + Amount + + https://github.com/kiegroup/drools/kie-dmn/_60B01F4D-E407-43F7-848E-258723B5FAC8 + number + + + + false + + + _D7CB5F9C-9D55-48C2-83EE-D47045EC90D0 + Points + + https://github.com/kiegroup/drools/kie-dmn/_60B01F4D-E407-43F7-848E-258723B5FAC8 + number + + + + false + + + false + + + + + + +---- + +Sample JSON output: + +[source,json] +---- +{ + "type" : "SUCCESS", + "msg" : "OK models successfully retrieved from container 'Traffic-Violation_1.0.0'", + "result" : { + "dmn-model-info-list" : { + "models" : [ { + "model-namespace" : "https://github.com/kiegroup/drools/kie-dmn/_60B01F4D-E407-43F7-848E-258723B5FAC8", + "model-name" : "Traffic Violation", + "model-id" : "_2CD7D1AA-BD84-4B43-AD21-B0342ADE655A", + "decisions" : [ { + "decision-id" : "_23428EE8-DC8B-4067-8E67-9D7C53EC975F", + "decision-name" : "Fine" + }, { + "decision-id" : "_B5EEE2B1-915C-44DC-BE43-C244DC066FD8", + "decision-name" : "Should the driver be suspended?" + } ], + "inputs" : [ { + "inputdata-id" : "_CEB959CD-3638-4A87-93BA-03CD0FB63AE3", + "inputdata-name" : "Violation", + "inputdata-typeRef" : { + "namespace-uri" : "https://github.com/kiegroup/drools/kie-dmn/_60B01F4D-E407-43F7-848E-258723B5FAC8", + "local-part" : "tViolation", + "prefix" : "" + } + }, { + "inputdata-id" : "_B0E810E6-7596-430A-B5CF-67CE16863B6C", + "inputdata-name" : "Driver", + "inputdata-typeRef" : { + "namespace-uri" : "https://github.com/kiegroup/drools/kie-dmn/_60B01F4D-E407-43F7-848E-258723B5FAC8", + "local-part" : "tDriver", + "prefix" : "" + } + } ], + "itemDefinitions" : [ { + "itemdefinition-id" : "_13C7EFD8-B85C-43BF-94D3-14FABE39A4A0", + "itemdefinition-name" : "tDriver", + "itemdefinition-typeRef" : null, + "itemdefinition-itemComponent" : [ { + "itemdefinition-id" : "_EC11744C-4160-4549-9610-2C757F40DFE8", + "itemdefinition-name" : "Name", + "itemdefinition-typeRef" : { + "namespace-uri" : "https://github.com/kiegroup/drools/kie-dmn/_60B01F4D-E407-43F7-848E-258723B5FAC8", + "local-part" : "string", + "prefix" : "" + }, + "itemdefinition-itemComponent" : [ ], + "itemdefinition-isCollection" : false + }, { + "itemdefinition-id" : "_E95BE3DB-4A51-4658-A166-02493EAAC9D2", + "itemdefinition-name" : "Age", + "itemdefinition-typeRef" : { + "namespace-uri" : "https://github.com/kiegroup/drools/kie-dmn/_60B01F4D-E407-43F7-848E-258723B5FAC8", + "local-part" : "number", + "prefix" : "" + }, + "itemdefinition-itemComponent" : [ ], + "itemdefinition-isCollection" : false + }, { + "itemdefinition-id" : "_7B3023E2-BC44-4BF3-BF7E-773C240FB9AD", + "itemdefinition-name" : "State", + "itemdefinition-typeRef" : { + "namespace-uri" : "https://github.com/kiegroup/drools/kie-dmn/_60B01F4D-E407-43F7-848E-258723B5FAC8", + "local-part" : "string", + "prefix" : "" + }, + "itemdefinition-itemComponent" : [ ], + "itemdefinition-isCollection" : false + }, { + "itemdefinition-id" : "_3D4B49DD-700C-4925-99A7-3B2B873F7800", + "itemdefinition-name" : "City", + "itemdefinition-typeRef" : { + "namespace-uri" : "https://github.com/kiegroup/drools/kie-dmn/_60B01F4D-E407-43F7-848E-258723B5FAC8", + "local-part" : "string", + "prefix" : "" + }, + "itemdefinition-itemComponent" : [ ], + "itemdefinition-isCollection" : false + }, { + "itemdefinition-id" : "_B37C49E8-B0D9-4B20-9DC6-D655BB1CA7B1", + "itemdefinition-name" : "Points", + "itemdefinition-typeRef" : { + "namespace-uri" : "https://github.com/kiegroup/drools/kie-dmn/_60B01F4D-E407-43F7-848E-258723B5FAC8", + "local-part" : "number", + "prefix" : "" + }, + "itemdefinition-itemComponent" : [ ], + "itemdefinition-isCollection" : false + } ], + "itemdefinition-isCollection" : false + }, { + "itemdefinition-id" : "_A4077C7E-B57A-4DEE-9C65-7769636316F3", + "itemdefinition-name" : "tFine", + "itemdefinition-typeRef" : null, + "itemdefinition-itemComponent" : [ { + "itemdefinition-id" : "_79B152A8-DE83-4001-B88B-52DFF0D73B2D", + "itemdefinition-name" : "Amount", + "itemdefinition-typeRef" : { + "namespace-uri" : "https://github.com/kiegroup/drools/kie-dmn/_60B01F4D-E407-43F7-848E-258723B5FAC8", + "local-part" : "number", + "prefix" : "" + }, + "itemdefinition-itemComponent" : [ ], + "itemdefinition-isCollection" : false + }, { + "itemdefinition-id" : "_D7CB5F9C-9D55-48C2-83EE-D47045EC90D0", + "itemdefinition-name" : "Points", + "itemdefinition-typeRef" : { + "namespace-uri" : "https://github.com/kiegroup/drools/kie-dmn/_60B01F4D-E407-43F7-848E-258723B5FAC8", + "local-part" : "number", + "prefix" : "" + }, + "itemdefinition-itemComponent" : [ ], + "itemdefinition-isCollection" : false + } ], + "itemdefinition-isCollection" : false + }, { + "itemdefinition-id" : "_9C758F4A-7D72-4D0F-B63F-2F5B8405980E", + "itemdefinition-name" : "tViolation", + "itemdefinition-typeRef" : null, + "itemdefinition-itemComponent" : [ { + "itemdefinition-id" : "_0B6FF1E2-ACE9-4FB3-876B-5BB30B88009B", + "itemdefinition-name" : "Code", + "itemdefinition-typeRef" : { + "namespace-uri" : "https://github.com/kiegroup/drools/kie-dmn/_60B01F4D-E407-43F7-848E-258723B5FAC8", + "local-part" : "string", + "prefix" : "" + }, + "itemdefinition-itemComponent" : [ ], + "itemdefinition-isCollection" : false + }, { + "itemdefinition-id" : "_27A5DA18-3CA7-4C06-81B7-CF7F2F050E29", + "itemdefinition-name" : "Date", + "itemdefinition-typeRef" : { + "namespace-uri" : "https://github.com/kiegroup/drools/kie-dmn/_60B01F4D-E407-43F7-848E-258723B5FAC8", + "local-part" : "date", + "prefix" : "" + }, + "itemdefinition-itemComponent" : [ ], + "itemdefinition-isCollection" : false + }, { + "itemdefinition-id" : "_8961969A-8A80-4F12-B568-346920C0F038", + "itemdefinition-name" : "Type", + "itemdefinition-typeRef" : { + "namespace-uri" : "https://github.com/kiegroup/drools/kie-dmn/_60B01F4D-E407-43F7-848E-258723B5FAC8", + "local-part" : "string", + "prefix" : "" + }, + "itemdefinition-itemComponent" : [ ], + "itemdefinition-isCollection" : false + }, { + "itemdefinition-id" : "_7450F12A-3E95-4D5E-8DCE-2CB1FAC2BDD4", + "itemdefinition-name" : "Speed Limit", + "itemdefinition-typeRef" : { + "namespace-uri" : "https://github.com/kiegroup/drools/kie-dmn/_60B01F4D-E407-43F7-848E-258723B5FAC8", + "local-part" : "number", + "prefix" : "" + }, + "itemdefinition-itemComponent" : [ ], + "itemdefinition-isCollection" : false + }, { + "itemdefinition-id" : "_0A9A6F26-6C14-414D-A9BF-765E5850429A", + "itemdefinition-name" : "Actual Speed", + "itemdefinition-typeRef" : { + "namespace-uri" : "https://github.com/kiegroup/drools/kie-dmn/_60B01F4D-E407-43F7-848E-258723B5FAC8", + "local-part" : "number", + "prefix" : "" + }, + "itemdefinition-itemComponent" : [ ], + "itemdefinition-isCollection" : false + } ], + "itemdefinition-isCollection" : false + } ], + "decisionServices" : [ ] + } ] + } + } +} +---- +-- +endif::[] + +. Execute the model: + +ifeval::["{context}" == "kogito-dmn-models"] ++ +-- +*[POST]* `server/containers/{containerId}/dmn` + +Example curl request: + +[source] +---- +curl -u krisv:krisv -H "accept: application/json" -H "content-type: application/json" -X POST "http://localhost:8080/kie-server/services/rest/server/containers/MovieDMNContainer/dmn" -d "{ \"model-namespace\" : \"http://www.redhat.com/_c7328033-c355-43cd-b616-0aceef80e52a\", \"model-name\" : \"dmn-movieticket-ageclassification\", \"decision-name\" : [ ], \"decision-id\" : [ ], \"dmn-context\" : {\"Age\" : 66}}" +---- + +Example JSON request: + +[source,json] +---- +{ + "model-namespace" : "http://www.redhat.com/_c7328033-c355-43cd-b616-0aceef80e52a", + "model-name" : "dmn-movieticket-ageclassification", + "decision-name" : [ ], + "decision-id" : [ ], + "dmn-context" : {"Age" : 66} +} +---- + +Example XML request (JAXB format): + +[source,xml] +---- + + + http://www.redhat.com/_c7328033-c355-43cd-b616-0aceef80e52a + dmn-movieticket-ageclassification + + MAP + + 66 + + + +---- + +[NOTE] +==== +Regardless of the request format, the request requires the following elements: + +* Model namespace +* Model name +* Context object containing input values +==== + +Example JSON response: + +[source,json] +---- +{ + "type" : "SUCCESS", + "msg" : "OK from container 'MovieDMNContainer'", + "result" : { + "dmn-evaluation-result" : { + "messages" : [ ], + "model-namespace" : "http://www.redhat.com/_c7328033-c355-43cd-b616-0aceef80e52a", + "model-name" : "dmn-movieticket-ageclassification", + "decision-name" : [ ], + "dmn-context" : { + "Age" : 66, + "AgeClassification" : "Senior" + }, + "decision-results" : { + "_3" : { + "messages" : [ ], + "decision-id" : "_3", + "decision-name" : "AgeClassification", + "result" : "Senior", + "status" : "SUCCEEDED" + } + } + } + } +} +---- + +Example XML (JAXB format) response: + +[source,xml] +---- + + + + http://www.redhat.com/_c7328033-c355-43cd-b616-0aceef80e52a + dmn-movieticket-ageclassification + + MAP + + 66 + + + Senior + + + + + + _3 + + _3 + AgeClassification + Senior + + SUCCEEDED + + + + + +---- +-- +endif::[] +ifeval::["{context}" == "decision-service-getting-started"] ++ +-- +*[POST]* `server/containers/{containerId}/dmn` + +[NOTE] +==== +The attribute `model-namespace` is automatically generated and is different for every user. Ensure that the `model-namespace` and `model-name` attributes that you use match those of the deployed model. +==== + +Example curl request: + +[source] +---- +curl -u wbadmin:wbadmin -H "accept: application/json" -H "content-type: application/json" -X POST "http://localhost:8080/kie-server/services/rest/server/containers/traffic-violation_1.0.0/dmn" -d "{ \"model-namespace\" : \"https://github.com/kiegroup/drools/kie-dmn/_60B01F4D-E407-43F7-848E-258723B5FAC8\", \"model-name\" : \"Traffic Violation\", \"dmn-context\" : {\"Driver\" : {\"Points\" : 15}, \"Violation\" : {\"Type\" : \"speed\", \"Actual Speed\" : 135, \"Speed Limit\" : 100}}}" +---- + +Example JSON request: + +[source,json] +---- +{ + "model-namespace" : "https://github.com/kiegroup/drools/kie-dmn/_60B01F4D-E407-43F7-848E-258723B5FAC8", + "model-name" : "Traffic Violation", + "dmn-context" : + { + "Driver" : + { + "Points" : 15 + }, + "Violation" : + { + "Type" : "speed", + "Actual Speed" : 135, + "Speed Limit" : 100 + } + } +} +---- + +Example XML request (JAXB format): + +[source,xml] +---- + + + + MAP + + + MAP + + speed + + + 100 + + + 135 + + + + + + MAP + + 15 + + + + + +---- + +[NOTE] +==== +Regardless of the request format, the request requires the following elements: + +* Model namespace +* Model name +* Context object containing input values +==== + +Example JSON response: + +[source,json] +---- +{ + "type": "SUCCESS", + "msg": "OK from container 'Traffic-Violation_1.0.0'", + "result": { + "dmn-evaluation-result": { + "messages": [], + "model-namespace": "https://github.com/kiegroup/drools/kie-dmn/_7D8116DE-ADF5-4560-A116-FE1A2EAFFF48", + "model-name": "Traffic Violation", + "decision-name": [], + "dmn-context": { + "Violation": { + "Type": "speed", + "Speed Limit": 100, + "Actual Speed": 135 + }, + "Should Driver be Suspended?": "YES", + "Driver": { + "Points": 15 + }, + "Fine": { + "Points": 7, + "Amount": 1000 + } + }, + "decision-results": { + "_E1AF5AC2-E259-455C-96E4-596E30D3BC86": { + "messages": [], + "decision-id": "_E1AF5AC2-E259-455C-96E4-596E30D3BC86", + "decision-name": "Should the Driver be Suspended?", + "result": "YES", + "status": "SUCCEEDED" + }, + "_D7F02CE0-AF50-4505-AB80-C7D6DE257920": { + "messages": [], + "decision-id": "_D7F02CE0-AF50-4505-AB80-C7D6DE257920", + "decision-name": "Fine", + "result": { + "Points": 7, + "Amount": 1000 + }, + "status": "SUCCEEDED" + } + } + } + } +} +---- + +Example XML (JAXB format) response: + +[source,xml] +---- + + + + https://github.com/kiegroup/drools/kie-dmn/_A4BCA8B8-CF08-433F-93B2-A2598F19ECFF + Traffic Violation + + MAP + + + MAP + + speed + + + 100 + + + 135 + + + + + + MAP + + 15 + + + + + + MAP + + 7 + + + 1000 + + + + + Yes + + + + + + _4055D956-1C47-479C-B3F4-BAEB61F1C929 + + _4055D956-1C47-479C-B3F4-BAEB61F1C929 + Fine + + MAP + + 7 + + + 1000 + + + + SUCCEEDED + + + + _8A408366-D8E9-4626-ABF3-5F69AA01F880 + + _8A408366-D8E9-4626-ABF3-5F69AA01F880 + Should the driver be suspended? + Yes + + SUCCEEDED + + + + + +---- +-- +endif::[] diff --git a/assemblies/modules/decision-services/proc-dmn-included-models-dmn.adoc b/assemblies/modules/decision-services/proc-dmn-included-models-dmn.adoc new file mode 100644 index 0000000..f1ffe88 --- /dev/null +++ b/assemblies/modules/decision-services/proc-dmn-included-models-dmn.adoc @@ -0,0 +1,43 @@ +//@comment: Not yet applicable for Kogito. (Stetson, 5 March 2020) + +[id='proc-dmn-included-models-dmn_{context}'] += Including other DMN models within a DMN file in {CENTRAL} + +In {CENTRAL}, you can include other DMN models from your project in a specified DMN file. When you include a DMN model within another DMN file, you can use all of the nodes and logic from both models in the same decision requirements diagram (DRD), but you cannot edit the nodes from the included model. To edit nodes from included models, you must update the source file for the included model directly. If you update the source file for an included DMN model, open the DMN file where the DMN model is included (or close an re-open) to verify the changes. + +You cannot include DMN models from other projects in {CENTRAL}. + +.Prerequisites +* The DMN models are created or imported (as `.dmn` files) in the same project in {CENTRAL} as the DMN file in which you want to include the models. + +.Procedure +. In {CENTRAL}, go to *Menu* -> *Design* -> *Projects*, click the project name, and select the DMN file you want to modify. +. In the DMN modeler, click the *Included Models* tab. +. Click *Include Model*, select a DMN model from your project in the *Models* list, enter a unique name for the included model, and click *Include*: ++ +-- +.Including a DMN model +image::dmn/dmn-include-model.png[] + +The DMN model is added to this DMN file, and all DRD nodes from the included model are listed under *Decision Components* in the *Decision Navigator* view: + +.DMN file with decision components from the included DMN model +image::dmn/dmn-include-model-list.png[] + +All data types from the included model are also listed in read-only mode in the *Data Types* tab for the DMN file: + +.DMN file with data types from the included DMN model +image::dmn/dmn-include-model-data-types.png[] +-- +. In the *Model* tab of the DMN modeler, click and drag the included DRD components onto the canvas to begin implementing them in your DRD: ++ +-- +.Adding DRD components from the included DMN model +image::dmn/dmn-include-model-drd.png[] + +To edit DRD nodes or data types from included models, you must update the source file for the included model directly. If you update the source file for an included DMN model, open the DMN file where the DMN model is included (or close an re-open) to verify the changes. + +To edit the included model name or to remove the included model from the DMN file, use the *Included Models* tab in the DMN modeler. + +IMPORTANT: When you remove an included model, any nodes from that included model that are currently used in the DRD are also removed. +-- diff --git a/assemblies/modules/decision-services/proc-dmn-included-models-pmml.adoc b/assemblies/modules/decision-services/proc-dmn-included-models-pmml.adoc new file mode 100644 index 0000000..8cbe001 --- /dev/null +++ b/assemblies/modules/decision-services/proc-dmn-included-models-pmml.adoc @@ -0,0 +1,134 @@ +//@comment: Not yet applicable for Kogito. (Stetson, 5 March 2020) + +[id='proc-dmn-included-models-pmml_{context}'] += Including PMML models within a DMN file in {CENTRAL} + +In {CENTRAL}, you can include Predictive Model Markup Language (PMML) models from your project in a specified DMN file. When you include a PMML model within a DMN file, you can invoke that PMML model as a boxed function expression for a DMN decision node or business knowledge model node. If you update the source file for an included PMML model, you must remove and re-include the PMML model in the DMN file to apply the source changes. + +You cannot include PMML models from other projects in {CENTRAL}. + +.Prerequisites +* The PMML models are imported (as `.pmml` files) in the same project in {CENTRAL} as the DMN file in which you want to include the models. + +.Procedure +. In your DMN project, add the following dependencies to the project `pom.xml` file to enable PMML evaluation: ++ +-- +[source,xml,subs="attributes+"] +---- + + + org.drools + kie-pmml + ${{PRODUCT_INIT}.version} + provided + + + + + org.kie + kie-dmn-jpmml + ${{PRODUCT_INIT}.version} + provided + + + org.jpmml + pmml-evaluator + 1.4.9 + provided + + + org.jpmml + pmml-evaluator-extension + 1.4.9 + provided + +---- + +To access the project `pom.xml` file in {CENTRAL}, you can select any existing asset in the project and then in the *Project Explorer* menu on the left side of the screen, click the *Customize View* gear icon and select *Repository View* -> *pom.xml*. + +If you want to use the full PMML specification implementation with the Java Evaluator API for PMML (JPMML), use the alternative set of JPMML dependencies in your DMN project. If the JPMML dependencies and the standard `kie-pmml` dependency are both present, the `kie-pmml` dependency is disabled. For information about JPMML licensing terms, see https://openscoring.io/[Openscoring.io]. + +ifdef::DM,PAM[] +[NOTE] +==== +Instead of specifying a {PRODUCT} `` for individual dependencies, consider adding the {PRODUCT_BA} bill of materials (BOM) dependency to your project `pom.xml` file. The {PRODUCT_BA} BOM applies to both {PRODUCT_DM} and {PRODUCT_PAM}. When you add the BOM files, the correct versions of transitive dependencies from the provided Maven repositories are included in the project. + +Example BOM dependency: + +[source,xml,subs="attributes+"] +---- + + com.redhat.ba + ba-platform-bom + {BOM_VERSION} + import + pom + +---- + +For more information about the {PRODUCT_BA} BOM, see +ifdef::PAM[] +https://access.redhat.com/solutions/3405361[What is the mapping between RHPAM product and maven library version?]. +endif::[] +ifdef::DM[] +https://access.redhat.com/solutions/3363991[What is the mapping between RHDM product and maven library version?]. +endif::[] +==== +endif::DM,PAM[] +-- +. If you added the JPMML dependencies in your DMN project to use the JPMML Evaluator, download the following JAR files and add them to the `~/kie-server.war/WEB-INF/lib` and `~/business-central.war/WEB-INF/lib` directories in your {PRODUCT} distribution: +ifdef::DROOLS,JBPM,OP[] +* https://mvnrepository.com/artifact/org.kie/kie-dmn-jpmml/{COMMUNITY_VERSION_FINAL}[KIE JPMML Integration {COMMUNITY_VERSION_FINAL}] JAR file from the online Maven repository +endif::[] +ifdef::DM,PAM[] +* `kie-dmn-jpmml` JAR file in the *{PRODUCT} {ENTERPRISE_VERSION_LONG} Maven Repository* distribution (`{PRODUCT_FILE}-maven-repository/maven-repository/org/kie/kie-dmn-jpmml/{MAVEN_ARTIFACT_VERSION}/kie-dmn-jpmml-{MAVEN_ARTIFACT_VERSION}.jar`) from the https://access.redhat.com/jbossnetwork/restricted/listSoftware.html?downloadType=distributions&product={PRODUCT_INIT}&version={ENTERPRISE_VERSION_LONG}[Red Hat Customer Portal] +endif::[] +* https://mvnrepository.com/artifact/org.jpmml/pmml-evaluator/1.4.9[JPMML Evaluator 1.4.9] JAR file from the online Maven repository +* https://mvnrepository.com/artifact/org.jpmml/pmml-evaluator-extension/1.4.9[JPMML Evaluator Extensions 1.4.9] JAR file from the online Maven repository + ++ +-- +These artifacts are required to enable JPMML evaluation in {KIE_SERVER} and {CENTRAL}. + +ifdef::DM,PAM[] +IMPORTANT: Red Hat supports integration with the Java Evaluator API for PMML (JPMML) for PMML execution in {PRODUCT}. However, Red Hat does not support the JPMML libraries directly. If you include JPMML libraries in your {PRODUCT} distribution, see the https://openscoring.io/[Openscoring.io] licensing terms for JPMML. +endif::[] + +-- +. In {CENTRAL}, go to *Menu* -> *Design* -> *Projects*, click the project name, and select the DMN file you want to modify. +. In the DMN modeler, click the *Included Models* tab. +. Click *Include Model*, select a PMML model from your project in the *Models* list, enter a unique name for the included model, and click *Include*: ++ +-- +.Including a PMML model +image::dmn/dmn-include-model-pmml.png[] + +The PMML model is added to this DMN file: + +.DMN file with included PMML model +image::dmn/dmn-include-model-list-pmml.png[] +-- +. In the *Model* tab of the DMN modeler, select or create the decision node or business knowledge model node in which you want to invoke the PMML model and click the *Edit* icon to open the DMN boxed expression editor: ++ +-- +.Opening a new decision node boxed expression +image::dmn/dmn-decision-edit.png[] + +.Opening a new business knowledge model boxed expression +image::dmn/dmn-bkm-edit.png[] +-- +. Set the expression type to *Function* (default for business knowledge model nodes), click the top-left function cell, and select *PMML*. +. In the *document* and *model* rows in the table, double-click the undefined cells to specify the included PMML document and the relevant PMML model within that document: ++ +-- +.Adding a PMML model in a DMN business knowledge model +image::dmn/dmn-include-model-expression-pmml.png[] + +.Example PMML definition in a DMN business knowledge model +image::dmn/dmn-function-expression-example5.png[] + +If you update the source file for an included PMML model, you must remove and re-include the PMML model in the DMN file to apply the source changes. + +To edit the included model name or to remove the included model from the DMN file, use the *Included Models* tab in the DMN modeler. +-- diff --git a/assemblies/modules/decision-services/proc-dmn-logic-defining.adoc b/assemblies/modules/decision-services/proc-dmn-logic-defining.adoc new file mode 100644 index 0000000..f6d61b4 --- /dev/null +++ b/assemblies/modules/decision-services/proc-dmn-logic-defining.adoc @@ -0,0 +1,112 @@ +[id='proc-dmn-logic-defining_{context}'] += Defining DMN decision logic in boxed expressions in the {PRODUCT} DMN modeler + +Boxed expressions in DMN are tables that you use to define the underlying logic of decision nodes and business knowledge models in a decision requirements diagram (DRD) or decision requirements graph (DRG). Some boxed expressions can contain other boxed expressions, but the top-level boxed expression corresponds to the decision logic of a single DRD artifact. While DRDs with one or more DRGs represent the flow of a DMN decision model, boxed expressions define the actual decision logic of individual nodes. DRDs and boxed expressions together form a complete and functional DMN decision model. + +You can use the {PRODUCT} DMN modeler in VSCode to define decision logic for your DRD components using built-in boxed expressions. + +.Prerequisites +* A DMN file is created or imported in your {PRODUCT} project in VSCode. + +.Procedure +. In your VSCode IDE, open the DMN file to view the decision requirements diagram (DRD) in the {PRODUCT} DMN modeler. ++ +-- +If the DRD does not open in the {PRODUCT} DMN modeler, ensure that you have installed and enabled the {PRODUCT} https://github.com/kiegroup/kogito-tooling/releases[VSCode extension]. + +If the {PRODUCT} DMN modeler opens only the XML source of the DMN file and displays an error message, review the reported errors and the DMN model file to ensure that all DMN elements are correctly defined. +-- +. In the DMN modeler canvas, select a decision node or business knowledge model node that you want to define and click the *Edit* icon to open the DMN boxed expression editor: ++ +-- +.Opening a new decision node boxed expression +image::kogito/dmn/dmn-decision-edit.png[] + +.Opening a new business knowledge model boxed expression +image::kogito/dmn/dmn-bkm-edit.png[] + +By default, all business knowledge models are defined as boxed function expressions containing a literal FEEL expression, a nested context expression of an external JAVA or PMML function, or a nested boxed expression of any type. + +For decision nodes, you click the undefined table to select the type of boxed expression you want to use, such as a boxed literal expression, boxed context expression, decision table, or other DMN boxed expression. + +.Selecting the logic type for a decision node +image::kogito/dmn/dmn-decision-boxed-expression-options.png[] + +For business knowledge model nodes, you click the top-left function cell to select the function type, or right-click the function value cell, select *Clear*, and select a boxed expression of another type. + +.Selecting the function or other logic type for a business knowledge model +image::kogito/dmn/dmn-bkm-define.png[] +-- +. For this example, use a decision node and select *Decision Table* as the boxed expression type. ++ +A decision table in DMN is a visual representation of one or more rules in a tabular format. Each rule consists of a single row in the table, and includes columns that define the conditions (input) and outcome (output) for that particular row. +. Click the input column header to define the name and data type for the input condition. For example, name the input column *Credit Score.FICO* with a `number` data type. This column specifies numeric credit score values or ranges of loan applicants. +. Click the output column header to define the name and data type for the output values. For example, name the output column *Credit Score Rating* and next to the *Data Type* option, click *Manage* to go to the *Data Types* page where you can create a custom data type with score ratings as constraints. ++ +.Managing data types for a column header value +image::kogito/dmn/dmn-manage-data-types.png[] + +. On the *Data Types* page, click *New Data Type* to add a new data type. ++ +-- +For this example, click *New Data Type* and create a *Credit_Score_Rating* data type as a `string`: + +.Adding a new data type +image::kogito/dmn/dmn-custom-data-type-add.png[] +-- +. Click *Add Constraints*, select *Enumeration* from the drop-down options, and add the following constraints: ++ +-- +* `"Excellent"` +* `"Good"` +* `"Fair"` +* `"Poor"` +* `"Bad"` + +.Adding constraints to the new data type +image::kogito/dmn/dmn-custom-data-type-constraints.png[] + +To change the order of data type constraints, you can click the left end of the constraint row and drag the row as needed: + +.Dragging constraints to change constraint order +image::kogito/dmn/dmn-custom-data-type-constraints-drag.png[] + +For information about constraint types and syntax requirements for the specified data type, see the https://www.omg.org/spec/DMN[Decision Model and Notation specification]. +-- + +. Click *OK* to save the constraints and click the check mark to the right of the data type to save the data type. +. Return to the *Credit Score Rating* decision table, click the *Credit Score Rating* column header, and set the data type to this new custom data type. +. Use the *Credit Score.FICO* input column to define credit score values or ranges of values, and use the *Credit Score Rating* column to specify one of the corresponding ratings you defined in the *Credit_Score_Rating* data type. ++ +Right-click any value cell to insert or delete rows (rules) or columns (clauses). ++ +.Decision node decision table for credit score rating +image::kogito/dmn/dmn-decision-table-example1a.png[] + +. After you define all rules, click the top-left corner of the decision table to define the rule *Hit Policy* and *Builtin Aggregator* (for *COLLECT* hit policy only). ++ +-- +The hit policy determines how to reach an outcome when multiple rules in a decision table match the provided input values. The built-in aggregator determines how to aggregate rule values when you use the *COLLECT* hit policy. + +.Defining the decision table hit policy +image::kogito/dmn/dmn-hit-policies.png[] + +The following example is a more complex decision table that determines applicant qualification for a loan as the concluding decision node in the same loan prequalification decision model: + +.Decision table for loan prequalification +image::kogito/dmn/dmn-decision-table-example3.png[] +-- + +For boxed expression types other than decision tables, you follow these guidelines similarly to navigate the boxed expression tables and define variables and parameters for decision logic, but according to the requirements of the boxed expression type. Some boxed expressions, such as boxed literal expressions, can be single-column tables, while other boxed expressions, such as function, context, and invocation expressions, can be multi-column tables with nested boxed expressions of other types. + +For example, the following boxed context expression defines the parameters that determine whether a loan applicant can meet minimum mortgage payments based on principal, interest, taxes, and insurance (PITI), represented as a front-end ratio calculation with a sub-context expression: + +.Boxed context expression for front-end client PITI ratio +image::kogito/dmn/dmn-context-expression-example2.png[] + +The following boxed function expression determines a monthly mortgage installment as a business knowledge model in a lending decision, with the function value defined as a nested context expression: + +.Boxed function expression for installment calculation in business knowledge model +image::kogito/dmn/dmn-function-expression-example3.png[] + +For more information and examples of each boxed expression type, see xref:con-dmn-boxed-expressions_kogito-dmn-models[]. diff --git a/assemblies/modules/decision-services/proc-dmn-model-creating.adoc b/assemblies/modules/decision-services/proc-dmn-model-creating.adoc new file mode 100644 index 0000000..a2be29b --- /dev/null +++ b/assemblies/modules/decision-services/proc-dmn-model-creating.adoc @@ -0,0 +1,127 @@ +[id='proc-dmn-model-creating_{context}'] += Creating and editing DMN models in the {PRODUCT} DMN modeler + +You can use the {PRODUCT} DMN modeler in VSCode to design DMN decision requirements diagrams (DRDs) and define decision logic for a complete and functional DMN decision model. {PRODUCT} provides design and runtime support for DMN 1.2 models at conformance level 3, and includes enhancements and fixes to FEEL and DMN model components to optimize the experience of implementing DMN decision services with {PRODUCT}. {PRODUCT} also provides runtime-only support for DMN 1.1 and 1.3 models at conformance level 3, but any DMN 1.1 models that you import into your {PRODUCT} project, open in the DMN modeler, and save are converted to DMN 1.2 models. DMN 1.3 models are not supported in the {PRODUCT} DMN modeler. + +.Prerequisites +* https://code.visualstudio.com/[VSCode] 1.43.0 or later is installed. +* The {PRODUCT} https://github.com/kiegroup/kogito-tooling/releases[VSCode extension] is installed and enabled in your VSCode IDE. For information about enabling the VSCode extension, see +ifdef::KOGITO-ENT[] +{URL_CREATING_RUNNING}#proc-kogito-vscode-extension_kogito-creating-running[_{CREATING_RUNNING}_]. +endif::[] +ifdef::KOGITO-COMM[] +xref:proc-kogito-vscode-extension_kogito-creating-running[]. +endif::[] +* You have created a {PRODUCT} project and have included any Java objects required for your {PRODUCT} service. For information about creating a project, see +ifdef::KOGITO-ENT[] +{URL_CREATING_RUNNING}[_{CREATING_RUNNING}_]. +endif::[] +ifdef::KOGITO-COMM[] +xref:chap-kogito-creating-running[]. +endif::[] + +.Procedure +. In your VSCode IDE, create or import a DMN file in the relevant folder of your {PRODUCT} project, typically in `src/main/resources`. +. Open the new or imported DMN file to view the decision requirements diagram (DRD) in the {PRODUCT} DMN modeler. ++ +-- +If the DRD does not open in the {PRODUCT} DMN modeler, ensure that you have installed and enabled the {PRODUCT} https://github.com/kiegroup/kogito-tooling/releases[VSCode extension]. + +If the {PRODUCT} DMN modeler opens only the XML source of the DMN file and displays an error message, review the reported errors and the DMN model file to ensure that all DMN elements are correctly defined. +-- +. Begin adding components to your new or imported DRD by clicking and dragging one of the DMN nodes from the left toolbar: ++ +-- +.Adding DRD components +image::kogito/dmn/dmn-drag-decision-node.png[] + +The following DRD components are available: + +* *Decision*: Use this node for a DMN decision, where one or more input elements determine an output based on defined decision logic. +* *Business knowledge model*: Use this node for reusable functions with one or more decision elements. Decisions that have the same logic but depend on different sub-input data or sub-decisions use business knowledge models to determine which procedure to follow. +* *Knowledge source*: Use this node for external authorities, documents, committees, or policies that regulate a decision or business knowledge model. Knowledge sources are references to real-world factors rather than executable business rules. +* *Input data*: Use this node for information used in a decision node or a business knowledge model. Input data usually includes business-level concepts or objects relevant to the business, such as loan applicant data used in a lending strategy. +* *Text annotation*: Use this node for explanatory notes associated with an input data node, decision node, business knowledge model, or knowledge source. +* *Decision service*: Use this node to enclose a set of reusable decisions implemented as a decision service for invocation. A decision service can be used in other DMN models and can be invoked from an external application or a BPMN business process. + +-- +. In the DMN modeler canvas, double-click the new DRD node to enter an informative node name. +. If the node is a decision or business knowledge model, select the node to display the node options and click the *Edit* icon to open the DMN boxed expression editor to define the decision logic for the node: ++ +-- +.Opening a new decision node boxed expression +image::kogito/dmn/dmn-decision-edit.png[] + +.Opening a new business knowledge model boxed expression +image::kogito/dmn/dmn-bkm-edit.png[] + +By default, all business knowledge models are defined as boxed function expressions containing a literal FEEL expression, a nested context expression of an external JAVA or PMML function, or a nested boxed expression of any type. + +For decision nodes, you click the undefined table to select the type of boxed expression you want to use, such as a boxed literal expression, boxed context expression, decision table, or other DMN boxed expression. + +.Selecting the logic type for a decision node +image::kogito/dmn/dmn-decision-boxed-expression-options.png[] + +For business knowledge models, you click the top-left function cell to select the function type, or right-click the function value cell, select *Clear*, and select a boxed expression of another type. + +.Selecting the function or other logic type for a business knowledge model +image::kogito/dmn/dmn-bkm-define.png[] +-- +. In the selected boxed expression editor for either a decision node (any expression type) or business knowledge model (function expression), click the applicable table cells to define the table name, variable data types, variable names and values, function parameters and bindings, or FEEL expressions to include in the decision logic. ++ +-- +You can right-click cells for additional actions where applicable, such as inserting or removing table rows and columns or clearing table contents. + +The following is an example decision table for a decision node that determines credit score ratings based on a defined range of a loan applicant's credit score: + +.Decision node decision table for credit score rating +image::kogito/dmn/dmn-decision-table-example1a.png[] + +The following is an example boxed function expression for a business knowledge model that calculates mortgage payments based on principal, interest, taxes, and insurance (PITI) as a literal expression: + +.Business knowledge model function for PITI calculation +image::kogito/dmn/dmn-function-expression-example4.png[] +//// +NOTE: This PITI calculation logic can also be expressed as a boxed literal expression outside of a business knowledge model, but because business knowledge models are defined as function expressions, this expression becomes a function in this case. This requirement applies to any expression types that you use in business knowledge models. + +For more details about the types of boxed expressions, see xref:dmn-boxed-expressions-con-dmn-models[]. + +For more details about defining decision logic in boxed expressions, see xref:dmn-defining-logic-proc-dmn-models[]. +//// +-- +. After you define the decision logic for the selected node, click *Back to __MODEL_NAME__* to return to the DRD view. +. For the selected DRD node, use the available connection options to create and connect to the next node in the DRD, or click and drag a new node onto the DRD canvas from the left toolbar. ++ +-- +The node type determines which connection options are supported. For example, an *Input data* node can connect to a decision node, knowledge source, or text annotation using the applicable connection type, whereas a *Knowledge source* node can connect to any DRD element. A *Decision* node can connect only to another decision or a text annotation. + +The following connection types are available, depending on the node type: + +* *Information requirement*: Use this connection from an input data node or decision node to another decision node that requires the information. +* *Knowledge requirement*: Use this connection from a business knowledge model to a decision node or to another business knowledge model that invokes the decision logic. +* *Authority requirement*: Use this connection from an input data node or a decision node to a dependent knowledge source or from a knowledge source to a decision node, business knowledge model, or another knowledge source. +* *Association*: Use this connection from an input data node, decision node, business knowledge model, or knowledge source to a text annotation. +//// +For more details about DRD components and connector rules, see xref:dmn-drd-components-ref-dmn-models[]. +//// + +.Connecting credit score input to the credit score rating decision +image::kogito/dmn/dmn-input-connection-example.png[] + +image::kogito/dmn/dmn-input-connection-example2.png[] +-- +. Continue adding and defining the remaining DRD components of your decision model and save the completed DRD. ++ +-- +The following is an example DRD for a loan prequalification decision model: + +.Completed DRD for loan prequalification +image::kogito/dmn/dmn-example-drd.png[] + +The following is an example DRD for a phone call handling decision model using a reusable decision service: + +.Completed DRD for phone call handling with a decision service +image::kogito/dmn/dmn-example-drd3.png[width=90%] + +In a DMN decision service node, the decision nodes in the bottom segment incorporate input data from outside of the decision service to arrive at a final decision in the top segment of the decision service node. The resulting top-level decisions from the decision service are then implemented in any subsequent decisions or business knowledge requirements of the DMN model. You can reuse DMN decision services in other DMN models to apply the same decision logic with different input data and different outgoing connections. +-- diff --git a/assemblies/modules/decision-services/proc-drl-rules-create.adoc b/assemblies/modules/decision-services/proc-drl-rules-create.adoc new file mode 100644 index 0000000..1d7ef9d --- /dev/null +++ b/assemblies/modules/decision-services/proc-drl-rules-create.adoc @@ -0,0 +1,199 @@ +[id='proc-drl-rules-central-create_{context}'] += Creating DRL rules for your {PRODUCT} project + +You can create and manage DRL rules for your {PRODUCT} project in your integrated development environment (IDE). For {PRODUCT} service, VSCode is the preferred IDE. In each DRL rule file, you define rule conditions, actions, and other components related to the rule, based on the data objects you create or import in the package. + +In {PRODUCT}, you typically define DRL rules in rule units. A DRL rule unit is a module for rules and a unit of execution. A rule unit collects a set of rules with the declaration of the type of facts that the rules act on. A rule unit also serves as a unique namespace for each group of rules. A single rule base can contain multiple rule units. You typically store all the rules for a unit in the same file as the unit declaration so that the unit is self-contained. + +For this procedure, create the following example DRL type declarations and DRL rule unit to define DRL rules in a decision service for a loan application: + +.Example DRL type declarations for a loan application +[source] +---- +package org.mortgages; + +declare Bankruptcy + name: String + yearOfOccurrence: int +end + +declare Applicant + name: String + age: int +end + +declare LoanApplication + applicant: String + approved: boolean + explanation: String +end +---- + +.Example DRL rule unit file for a loan application +[source] +---- +package org.mortgages; +unit MortgageRules; + +import org.kie.kogito.rules.DataSource; +import org.kie.kogito.rules.DataStream; + +declare MortgageRules extends RuleUnitData + bankruptcy: DataStore = DataSource.createStore() + applicant: DataStore = DataSource.createStore() + application: DataStore = DataSource.createStore() +end + +rule "Bankruptcy history" + salience 10 + when + $a : /loanApplication[ applicantName: applicant ] + exists (/bankruptcy[ name == applicantName, yearOfOccurrence > 1990 || amountOwed > 100000 ]) + then + $a.setApproved( false ); + $a.setExplanation( "has been bankrupt" ); + loanApplication.remove( $a ); +end + +rule "Underage" + salience 15 + when + /applicant[ applicantName : name, age < 21 ] + $application : /loanApplication[ applicant == applicantName ] + then + $application.setApproved( false ); + $application.setExplanation( "Underage" ); + loanApplication.remove( $a ); +end +---- + +.Prerequisites +* You have created a {PRODUCT} project and have included any Java data objects required for your {PRODUCT} service. For information about creating a project, see +ifdef::KOGITO-ENT[] +{URL_CREATING_RUNNING}[_{CREATING_RUNNING}_]. +endif::[] +ifdef::KOGITO-COMM[] +xref:chap-kogito-creating-running[]. +endif::[] + +.Procedure +. In your VSCode IDE, open your {PRODUCT} project and create a `src/main/resources/org/mortgages` folder. This folder serves as the package for your DRL files in this example. +. In your new `src/main/resources/org/mortgages` folder, add the following `ApplicationTypes.drl` file to define the fact types for the loan application service: ++ +-- +.Example DRL type declarations for a loan application +[source] +---- +package org.mortgages; + +declare Bankruptcy + name: String + yearOfOccurrence: int +end + +declare Applicant + name: String + age: int +end + +declare LoanApplication + applicant: String + approved: boolean + explanation: String +end +---- + +This DRL file defines the fact types that you can declare in any rule units in the same package for the decision service. Declarations in DRL files define new fact types or metadata for fact types to be used by rules in a DRL files. If you declare these types directly in the DRL rule unit file, you cannot declare them in any other rule units. + +This example defines the following fact types: + +* `Bankruptcy`: Provides data for bankruptcy status, if applicable +* `Applicant`: Provides data about the loan applicant +* `LoanApplication`: Provides data about loan approval status for a specified applicant, with an explanation if needed +-- +. In the same `src/main/resources/org/mortgages` folder of your {PRODUCT} project, create the following `LoanApplication.drl` file to declare the DRL rule unit and data sources: ++ +-- +.Example DRL file with rule unit and data sources +[source] +---- +package org.mortgages; +unit MortgageRules; + +import org.kie.kogito.rules.DataSource; +import org.kie.kogito.rules.DataStore; + +declare MortgageRules extends RuleUnitData + bankruptcy: DataStore = DataSource.createStore() + applicant: DataStore = DataSource.createStore() + application: DataStore = DataSource.createStore() +end +... +---- + +In this example, the rule unit is named `MortgageRules` and the previously defined fact types are declared as `DataStore` data sources. + +Data sources are typed sources of data that rule units can subscribe to for updates. You interact with the rule unit through the data sources it exposes. A data source can be a `DataStream` source for append-only storage, a `DataStore` source for writable storage to add or remove data, or a `SingletonStore` source for writable storage to set and clear a single element. + +This example uses the `DataStore` data source to enable application data to be added or removed as part of the decision service. +-- +. To complete the DRL rule unit file, add the following rules for `"Bankruptcy history"` and `"Underage"` logic: ++ +-- +.Example DRL rule unit file for a loan application +[source] +---- +package org.mortgages; +unit MortgageRules; + +import org.kie.kogito.rules.DataSource; +import org.kie.kogito.rules.DataStream; + +declare MortgageRules extends RuleUnitData + bankruptcy: DataStore = DataSource.createStore() + applicant: DataStore = DataSource.createStore() + application: DataStore = DataSource.createStore() +end + +rule "Bankruptcy history" + salience 10 + when + $a : /loanApplication[ applicantName: applicant ] + exists (/bankruptcy[ name == applicantName, yearOfOccurrence > 1990 || amountOwed > 100000 ]) + then + $a.setApproved( false ); + $a.setExplanation( "has been bankrupt" ); + loanApplication.remove( $a ); +end + +rule "Underage" + salience 15 + when + /applicant[ applicantName : name, age < 21 ] + $application : /loanApplication[ applicant == applicantName ] + then + $application.setApproved( false ); + $application.setExplanation( "Underage" ); + loanApplication.remove( $a ); +end +---- + +The example rules consist of the following rule components: + +* `rule`: Use this segment to define each rule in the DRL file. Rules consist of a rule name in the format `rule "rule name"`, followed by optional attributes that define rule behavior, such as `salience` or `no-loop`, followed by `when` and `then` definitions. Each rule must have a unique name within the rule package. ++ +In this example, the `"Bankruptcy history"` rule has a defined salience of `10` and the `"Underage"` rule has a defined salience of `15`. These values ensure that the `"Bankruptcy history"` rule is executed first. +* `when` and `then`: Use the `when` portion to define the condition patterns and constraints in OOPath syntax and use the `then` portion to define the actions to be executed when the conditions are met. ++ +In this example, the `"Bankruptcy history"` rule states that if an applicant has owed more than 100,000 USD of unresolved debt since 1990 (beginning 1991), then the applicant is considered to have been bankrupt and is not approved for a loan. The application is removed from memory. ++ +If the applicant passes the bankruptcy check, then the `"Underage"` rule states that if the applicant is younger than 21 years old, then the applicant is not approved for the loan. The application is removed from memory. ++ +If the applicant passes both checks, then the loan is approved. +-- +. After you define all components of the data sources and rules, save all DRL files. + +.Additional resources +* xref:con-drl-rule-units_drl-rules[] +* xref:con-drl-rules-conditions_drl-rules[] +* xref:con-drl-rules-actions_drl-rules[] diff --git a/assemblies/modules/decision-services/ref-decision-authoring-assets.adoc b/assemblies/modules/decision-services/ref-decision-authoring-assets.adoc new file mode 100644 index 0000000..be62d44 --- /dev/null +++ b/assemblies/modules/decision-services/ref-decision-authoring-assets.adoc @@ -0,0 +1,44 @@ +[id='ref-decision-authoring-assets_{context}'] += Decision-authoring assets in {PRODUCT} + +{PRODUCT} supports several assets that you can use to define business decisions for your decision service. Each decision-authoring asset has different advantages, and you might prefer to use one or a combination of multiple assets depending on your goals and needs. + +The following table highlights the main decision-authoring assets supported in {PRODUCT} projects to help you decide or confirm the best method for defining decisions in your decision service. + +.Decision-authoring assets supported in {PRODUCT} +[cols="20%,40%,20%,20%", options="header"] +|=== +|Asset +|Highlights +|Authoring tools +|Documentation + +|Decision Model and Notation (DMN) models +a| +* Are decision models based on a notation standard defined by the Object Management Group (OMG) +* Use graphical decision requirements diagrams (DRDs) with one or more decision requirements graphs (DRGs) to trace business decision flows +* Use an XML schema that allows the DMN models to be shared between DMN-compliant platforms +* Support Friendly Enough Expression Language (FEEL) to define decision logic in DMN decision tables and other DMN boxed expressions +* Can be integrated efficiently with Business Process Model and Notation (BPMN) process models +* Are optimal for creating comprehensive, illustrative, and stable decision flows +|{PRODUCT} DMN modeler in VSCode or other DMN-compliant editor +|xref:con-dmn_kogito-dmn-models[] + +|DRL rules +a| +* Are individual rules that you define directly in `.drl` text files +* Provide the most flexibility for defining rules and other technicalities of rule behavior +* Are optimal for creating rules that require advanced DRL options, such as rule units +* Have strict syntax requirements for rules to be compiled properly +|Any integrated development environment (IDE) +|xref:con-drl_drl-rules[] + +|Spreadsheet decision tables +a| +* Are tabular sets of rules that you define in `.xls` or `.xlsx` spreadsheet files +* Support template keys and values for creating rule templates +* Are optimal for business environments that already rely on decision tables for rules +* Have strict syntax requirements for rules to be compiled properly when used in {PRODUCT} +|Spreadsheet editor +|xref:con-decision-tables_decision-tables[] +|=== diff --git a/assemblies/modules/decision-services/ref-decision-tables-attributes.adoc b/assemblies/modules/decision-services/ref-decision-tables-attributes.adoc new file mode 100644 index 0000000..69f7719 --- /dev/null +++ b/assemblies/modules/decision-services/ref-decision-tables-attributes.adoc @@ -0,0 +1,77 @@ +[id='ref-decision-tables-attributes_{context}'] += Additional rule attributes for RuleSet or RuleTable definitions + +The `RuleSet` and `RuleTable` areas also support labels and values for other rule attributes, such as `PRIORITY` or `NO-LOOP`. Rule attributes specified in a `RuleSet` area will affect all rule assets in the same package (not only in the spreadsheet). Rule attributes specified in a `RuleTable` area will affect only the rules in that rule table. You can use each rule attribute only once in a `RuleSet` area and once in a `RuleTable` area. If the same attribute is used in both `RuleSet` and `RuleTable` areas within the spreadsheet, then `RuleTable` takes priority and the attribute in the `RuleSet` area is overridden. + +The following table lists the supported labels (column headers) and values for additional `RuleSet` or `RuleTable` definitions. For column headers, you can use either the given labels or any custom labels that begin with the letters listed in the table. + +.Additional rule attributes for `RuleSet` or `RuleTable` definitions +[cols="25%,20%,55%", options="header"] +|=== +|Label +|Or custom label that begins with +|Value + +|`PRIORITY` +|P +|An integer defining the `salience` value of the rule. Rules with a higher salience value are given higher priority when ordered in the activation queue. Overridden by the `Sequential` flag. + +Example: `PRIORITY 10` + +|`DATE-EFFECTIVE` +|V +|A string containing a date and time definition. The rule can be activated only if the current date and time is after a `DATE-EFFECTIVE` attribute. + +Example: `DATE-EFFECTIVE "4-Sep-2018"` + +|`DATE-EXPIRES` +|Z +|A string containing a date and time definition. The rule cannot be activated if the current date and time is after the `DATE-EXPIRES` attribute. + +Example: `DATE-EXPIRES "4-Oct-2018"` + +|`NO-LOOP` +|U +|A Boolean value. When this option is set to `true`, the rule cannot be reactivated (looped) if a consequence of the rule re-triggers a previously met condition. + +Example: `NO-LOOP true` + +|`ACTIVATION-GROUP` +|X +|A string identifying an activation (or XOR) group to which you want to assign the rule. In activation groups, only one rule can be activated. The first rule to fire will cancel all pending activations of all rules in the activation group. + +Example: `ACTIVATION-GROUP "GroupName"` + +|`DURATION` +|D +|A long integer value defining the duration of time in milliseconds after which the rule can be activated, if the rule conditions are still met. + +Example: `DURATION 10000` + +|`TIMER` +|T +|A string identifying either `int` (interval) or `cron` timer definitions for scheduling the rule. + +Example: `TIMER "*/5 * * * *"` (every 5 minutes) + +|`CALENDAR` +|E +|A Quartz calendar definition for scheduling the rule. + +Example: `CALENDAR "* * 0-7,18-23 ? * *"` (exclude non-business hours) + +|`AUTO-FOCUS` +|F +|A Boolean value, applicable only to rules within agenda groups. When this option is set to `true`, the next time the rule is activated, a focus is automatically given to the agenda group to which the rule is assigned. + +Example: `AUTO-FOCUS true` + +|`LOCK-ON-ACTIVE` +|L +|A Boolean value, applicable only to rules within rule flow groups or agenda groups. When this option is set to `true`, the next time the ruleflow group for the rule becomes active or the agenda group for the rule receives a focus, the rule cannot be activated again until the ruleflow group is no longer active or the agenda group loses the focus. This is a stronger version of the `no-loop` attribute, because the activation of a matching rule is discarded regardless of the origin of the update (not only by the rule itself). This attribute is ideal for calculation rules where you have a number of rules that modify a fact and you do not want any rule re-matching and firing again. + +Example: `LOCK-ON-ACTIVE true` +|=== + +.Sample decision table spreadsheet with attribute columns +image::kogito/decision-tables/decision-table-example-03.png[Example decision table with definitions used] diff --git a/assemblies/modules/decision-services/ref-decision-tables-rule-set-entries.adoc b/assemblies/modules/decision-services/ref-decision-tables-rule-set-entries.adoc new file mode 100644 index 0000000..f23e4f9 --- /dev/null +++ b/assemblies/modules/decision-services/ref-decision-tables-rule-set-entries.adoc @@ -0,0 +1,61 @@ +[id='ref-decision-tables-rule-set-entries_{context}'] += RuleSet definitions + +Entries in the `RuleSet` area of a decision table define DRL constructs and rule attributes that you want to apply to all rules in a package (not only in the spreadsheet). Entries must be in a vertically stacked sequence of cell pairs, where the first cell contains a label and the cell to the right contains the value. A decision table spreadsheet can have only one `RuleSet` area. + +The following table lists the supported labels and values for `RuleSet` definitions: + +.Supported `RuleSet` definitions +[cols="30%,40%,30%", options="header"] +|=== +|Label |Value |Usage + +|`RuleSet` +|The package name for the generated DRL file. Optional, the default is `rule_table`. +|Must be the first entry. + +|`Unit` +|The name of the rule unit for the generated DRL file. +|Recommended for optimal rule grouping and execution. + +|`Sequential` +|`true` or `false`. If `true`, then salience is used to ensure that rules fire from the top down. +|Optional, at most once. If omitted, no firing order is imposed. + +|`SequentialMaxPriority` +|Integer numeric value. +|Optional, at most once. In sequential mode, this option is used to set the start value of the salience. If omitted, the default value is `65535`. + +|`SequentialMinPriority` +|Integer numeric value. +|Optional, at most once. In sequential mode, this option is used to check if this minimum salience value is not violated. If omitted, the default value is `0`. + +|`EscapeQuotes` +|`true` or `false`. If `true`, then quotation marks are escaped so that they appear literally in the DRL. +|Optional, at most once. If omitted, quotation marks are escaped. + +|`Import` +|A comma-separated list of Java classes to import from another package. +|Optional, may be used repeatedly. + +|`Queries` +|One or more query definitions, according to DRL syntax. +|Optional, may be used repeatedly. + +|`Declare` +|One or more declarative types, according to DRL syntax. +|Optional, may be used repeatedly. +|=== + +//@comment Excluded because uncertain in Kogito at the moment. (Stetson 7 Apr 2020) +//// +|`Variables` +|Declarations of DRL globals (a type followed by a variable name). Multiple global definitions must be separated by commas. +|Optional, may be used repeatedly. + +|`Functions` +|One or more function definitions, according to DRL syntax. +|Optional, may be used repeatedly. +//// + +WARNING: In some cases, Microsoft Office, LibreOffice, and OpenOffice might encode a double quotation mark differently, causing a compilation error. For example, `"`A`"` fails, but `"A"` succeeds. diff --git a/assemblies/modules/decision-services/ref-decision-tables-rule-table-entries.adoc b/assemblies/modules/decision-services/ref-decision-tables-rule-table-entries.adoc new file mode 100644 index 0000000..faad7a5 --- /dev/null +++ b/assemblies/modules/decision-services/ref-decision-tables-rule-table-entries.adoc @@ -0,0 +1,80 @@ +[id='ref-decision-tables-rule-table-entries_{context}'] += RuleTable definitions + +Entries in the `RuleTable` area of a decision table define conditions, actions, and other rule attributes for the rules in that rule table. A spreadsheet of decision tables can contain multiple `RuleTable` areas. + +The following table lists the supported labels (column headers) and values for `RuleTable` definitions. For column headers, you can use either the given labels or any custom labels that begin with the letters listed in the table. + +.Supported `RuleTable` definitions +[cols="25%,20%,35%,20%", options="header"] +|=== +|Label |Or custom label that begins with |Value |Usage + +|`NAME` +|N +|Provides the name for the rule generated from that row. The default is constructed from the text following the `RuleTable` tag and the row number. +|At most one column. + +|`DESCRIPTION` +|I +|Results in a comment within the generated rule. +|At most one column. + +|`CONDITION` +|C +|Code snippet and interpolated values for constructing a constraint within a pattern in a condition. +|At least one per rule table. + +|`ACTION` +|A +|Code snippet and interpolated values for constructing an action for the consequence of the rule. +|At least one per rule table. + +|`METADATA` +|@ +|Code snippet and interpolated values for constructing a metadata entry for the rule. +|Optional, any number of columns. +|=== + +The following sections provide more details about how condition, action, and metadata columns use cell data: + +Conditions:: + +For columns headed `CONDITION`, the cells in consecutive lines result in a conditional element: + +* *First cell:* Text in the first cell below `CONDITION` develops into a pattern for the rule condition, and uses the snippet in the next line as a constraint. If the cell is merged with one or more neighboring cells, a single pattern with multiple constraints is formed. All constraints are combined into a parenthesized list and appended to the text in this cell. ++ +If this cell is empty, the code snippet in the cell below it must result in a valid conditional element on its own. For example, instead of `Order` as the object type and `itemsCount > $1` as a constraint (separate cells), you can leave the object type cell empty and enter `Order( itemsCount > $1 )` in the constraint cell, and then do the same for any other constraint cells. ++ +To include a pattern without constraints, you can write the pattern in front of the text of another pattern, with or without an empty pair of parentheses. You can also append a `from` clause to the pattern. ++ +If the pattern ends with `eval`, code snippets produce boolean expressions for inclusion into a pair of parentheses after `eval`. +* *Second cell:* Text in the second cell below `CONDITION` is processed as a constraint on the object reference in the first cell. The code snippet in this cell is modified by interpolating values from cells farther down in the column. If you want to create a constraint consisting of a comparison using `==` with the value from the cells below, then the field selector alone is sufficient. Any other comparison operator must be specified as the last item within the snippet, and the value from the cells below is appended. For all other constraint forms, you must mark the position for including the contents of a cell with the symbol `$param`. Multiple insertions are possible if you use the symbols `$1`, `$2`, and so on, and a comma-separated list of values in the cells below. However, do not separate `$1`, `$2`, and so on, by commas, or the table will fail to process. ++ +To expand a text according to the pattern `forall($delimiter){$snippet}`, repeat the `$snippet` once for each of the values of the comma-separated list in each of the cells below, insert the value in place of the symbol `$`, and join these expansions by the given `$delimiter`. Note that the `forall` construct may be surrounded by other text. ++ +If the first cell contains an object, the completed code snippet is added to the conditional element from that cell. A pair of parentheses is provided automatically, as well as a separating comma if multiple constraints are added to a pattern in a merged cell. If the first cell is empty, the code snippet in this cell must result in a valid conditional element on its own. For example, instead of `Order` as the object type and `itemsCount > $1` as a constraint (separate cells), you can leave the object type cell empty and enter `Order( itemsCount > $1 )` in the constraint cell, and then do the same for any other constraint cells. +* *Third cell:* Text in the third cell below `CONDITION` is a descriptive label that you define for the column, as a visual aid. +* *Fourth cell:* From the fourth row on, non-blank entries provide data for interpolation. A blank cell omits the condition or constraint for this rule. + +Actions:: + +For columns headed `ACTION`, the cells in consecutive lines result in an action statement: + +* *First cell:* Text in the first cell below `ACTION` is optional. If present, the text is interpreted as an object reference. +* *Second cell:* Text in the second cell below `ACTION` is a code snippet that is modified by interpolating values from cells farther down in the column. For a singular insertion, mark the position for including the contents of a cell with the symbol `$param`. Multiple insertions are possible if you use the symbols `$1`, `$2`, and so on, and a comma-separated list of values in the cells below. However, do not separate `$1`, `$2`, and so on, by commas, or the table will fail to process. ++ +A text without any marker symbols can execute a method call without interpolation. In this case, use any non-blank entry in a row below the cell to include the statement. The `forall` construct is supported. ++ +If the first cell contains an object, then the cell text (followed by a period), the text in the second cell, and a terminating semicolon are strung together, resulting in a method call that is added as an action statement for the consequence. If the first cell is empty, the code snippet in this cell must result in a valid action element on its own. +* *Third cell:* Text in the third cell below `ACTION` is a descriptive label that you define for the column, as a visual aid. +* *Fourth cell:* From the fourth row on, non-blank entries provide data for interpolation. A blank cell omits the condition or constraint for this rule. + +Metadata:: + +For columns headed `METADATA`, the cells in consecutive lines result in a metadata annotation for the generated rules: + +* *First cell:* Text in the first cell below `METADATA` is ignored. +* *Second cell:* Text in the second cell below `METADATA` is subject to interpolation, using values from the cells in the rule rows. The metadata marker character `@` is prefixed automatically, so you do not need to include that character in the text for this cell. +* *Third cell:* Text in the third cell below `METADATA` is a descriptive label that you define for the column, as a visual aid. +* *Fourth cell:* From the fourth row on, non-blank entries provide data for interpolation. A blank cell results in the omission of the metadata annotation for this rule. diff --git a/assemblies/modules/decision-services/ref-dmn-data-types.adoc b/assemblies/modules/decision-services/ref-dmn-data-types.adoc new file mode 100644 index 0000000..35baf54 --- /dev/null +++ b/assemblies/modules/decision-services/ref-dmn-data-types.adoc @@ -0,0 +1,231 @@ +[id='ref-dmn-data-types_{context}'] += Data types in FEEL + +Friendly Enough Expression Language (FEEL) supports the following data types: + +* Numbers +* Strings +* Boolean values +* Dates +* Time +* Date and time +* Days and time duration +* Years and months duration +* Functions +* Contexts +* Ranges (or intervals) +* Lists + +NOTE: The DMN specification currently does not provide an explicit way of declaring a variable as a `function`, `context`, `range`, or `list`, but {PRODUCT} extends the DMN built-in types to support variables of these types. + +The following list describes each data type: + +Numbers:: +Numbers in FEEL are based on the http://ieeexplore.ieee.org/document/4610935/[IEEE 754-2008] Decimal 128 format, with 34 digits of precision. Internally, numbers are represented in Java as https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html[`BigDecimals`] with `MathContext DECIMAL128`. FEEL supports only one number data type, so the same type is used to represent both integers and floating +point numbers. ++ +-- +FEEL numbers use a dot (`.`) as a decimal separator. FEEL does not support `-INF`, `+INF`, or `NaN`. FEEL uses +`null` to represent invalid numbers. + +{PRODUCT} extends the DMN specification and supports additional number notations: + +* *Scientific:* You can use scientific notation with the suffix `e` or `E`. For example, `1.2e3` is the same as writing the +expression `1.2*10**3`, but is a literal instead of an expression. +* *Hexadecimal:* You can use hexadecimal numbers with the prefix `0x`. For example, `0xff` is the same as the decimal +number `255`. Both uppercase and lowercase letters are supported. For example, `0XFF` is the same as `0xff`. +* *Type suffixes:* You can use the type suffixes `f`, `F`, `d`, `D`, `l`, and `L`. These suffixes are ignored. +-- + +Strings:: +Strings in FEEL are any sequence of characters delimited by double quotation marks. ++ +-- +Example: +---- +"John Doe" +---- +-- + +Boolean values:: +FEEL uses three-valued boolean logic, so a boolean logic expression may have values `true`, `false`, or `null`. + + +Dates:: +Date literals are not supported in FEEL, but you can use the built-in `date()` function to construct date values. Date strings in FEEL follow the format defined in the https://www.w3.org/TR/xmlschema-2/#date[XML Schema Part 2: Datatypes] document. The format is `"YYYY-MM-DD"` where `YYYY` is the year with four digits, `MM` is the number of the month with +two digits, and `DD` is the number of the day. ++ +-- +Example: +---- +date( "2017-06-23" ) +---- + +Date objects have time equal to `"00:00:00"`, which is midnight. The dates are considered to be local, without a timezone. +-- + +Time:: +Time literals are not supported in FEEL, but you can use the built-in `time()` function to construct time values. Time strings in FEEL follow the format defined in the https://www.w3.org/TR/xmlschema-2/#time[XML Schema Part 2: Datatypes] document. The format is `"hh:mm:ss[.uuu][(+-)hh:mm]"` where `hh` is the hour of the day (from `00` to `23`), `mm` is the minutes in the hour, and `ss` is the number of seconds in the minute. Optionally, the string may define the number of milliseconds (`uuu`) within the second and contain a positive (`+`) or negative (`-`) offset from UTC time to define its timezone. Instead of using an offset, you can use the letter `z` to represent the UTC time, which is the same as an offset of `-00:00`. If no offset is defined, the time is considered to be local. ++ +-- +Examples: +---- +time( "04:25:12" ) +time( "14:10:00+02:00" ) +time( "22:35:40.345-05:00" ) +time( "15:00:30z" ) +---- + +Time values that define an offset or a timezone cannot be compared to local times that do not define an offset or a timezone. +-- + +Date and time:: +Date and time literals are not supported in FEEL, but you can use the built-in `date and time()` function to construct date and time values. Date and time strings in FEEL follow the format defined in the https://www.w3.org/TR/xmlschema-2/#dateTime[XML Schema Part 2: Datatypes] document. The format is `"T