As part of our effort to make Kogito usable in an event-driven fashion, this article introduces a new addon: the event-driven rules addon.
It is available since Kogito v1.12.0 and its behavior resembles what the event-driven decisions addon (presented here) already does for decisions.
Key concepts
The new addon enables the evaluation of DRL rule unit queries in an event-driven fashion, so that it can be used as part of an event processing pipeline.
Like the other addon, it comes in two flavours: Quarkus and Spring Boot, and, in order to use it, the developer only needs to include the correct version as dependency of his Kogito app and configure it. The Kogito code-generation and framework specific CDI are then leveraged to do the wiring.
The execution is triggered upon receiving an event containing the input facts in a specified Kafka topic. The result is then sent to a Kafka output topic (which may be the same). Both input and output events are formatted as CloudEvents.
It is implemented to behave like the REST endpoints: the output event contains the same output data the REST response would return if called with the same input facts.
Event structure
Input event
A model evaluation is triggered by a specific event called RulesRequest.
Here is the list of supported fields, including the optional ones:
| Field | Purpose | Mandatory | Default |
|---|---|---|---|
data | Input facts | yes | – |
id | CloudEvent ID | yes | – |
kogitoruleunitid | ID of the rule unit to evaluate | yes | – |
kogitoruleunitquery | Name of the selected query belonging to the rule unit | yes | – |
source | CloudEvent source | yes | – |
specversion | Must be equal to 1.0 as mandated by CloudEvent specification | yes | – |
subject | If specified, the engine will put the same value as the subject of the output event. Its usage is up to the caller (e.g. as correlation ID). | no | null |
type | Must be equal to RulesRequest | yes | – |
Example of RulesRequest event
{
"specversion": "1.0",
"id": "a89b61a2-5644-487a-8a86-144855c5dce8",
"source": "SomeEventSource",
"type": "RulesRequest",
"subject": "TheSubject",
"kogitoruleunitid": "org.kie.kogito.queries.LoanUnit",
"kogitoruleunitquery": "FindAllApplicationAmounts",
"data": {
"maxAmount": 5000,
"loanApplications": [
{
"id": "ABC10001",
"amount": 2000,
"deposit": 100,
"applicant": {
"age": 45,
"name": "John"
}
},
{
"id": "ABC10002",
"amount": 5000,
"deposit": 100,
"applicant": {
"age": 25,
"name": "Paul"
}
},
{
"id": "ABC10015",
"amount": 1000,
"deposit": 100,
"applicant": {
"age": 12,
"name": "George"
}
}
]
}
}
Output event
If the request is evaluated successfully, the system returns a RulesResponse event with matching kogitoruleunitid, kogitoruleunitquery and subject (if present) containing the output facts in the data field.
Example of RulesResponse event
{
"specversion": "1.0",
"id": "d54ace84-6788-46b6-a359-b308f8b21778",
"source": "find-all-application-amounts",
"type": "RulesResponse",
"subject": "TheSubject",
"kogitoruleunitid": "org.kie.kogito.queries.LoanUnit",
"kogitoruleunitquery": "FindAllApplicationAmounts",
"data": [
{
"amounts": 8000
}
]
}
Error event
If, for some reason, the request event is malformed or contains wrong information so that the evaluation can’t be triggered, a RulesResponseError is sent as output.
In this case the data field contains a string that specifies the error type:
| Error Type | Meaning |
|---|---|
BAD_REQUEST | Malformed input event (e.g. when some mandatory fields are missing) |
QUERY_NOT_FOUND | The specified rule unit or query can’t be found in the current service |
Examples
The Kogito Examples repository contains two examples, one for Quarkus and one for Spring Boot, that you can use as a starting point to practice with this addon.
They also contain tests for every possible variation in the structure of the input/output events supported by the addon in the src/test/resources/events subfolder.
Conclusion
If you liked this article and are interested in the evolution of Kogito, stay tuned for more news!
Thanks for reading.
