8.5. Rules
8.5.1. Rules Component
The Rules component is a pluggable container in SwitchYard which allows you to expose business rules as a service. You can add a custom interface to your rules and annotate its methods to define which methods should execute the rules. The Rules component supports Drools as the rule engine.
Note
In a SwitchYard Rules service implementation
java:comp/BeanManager
lookup via JNDI is not supported. There is no supported alternative.
8.5.2. Create a Rules Service
Prerequisites
- File Name: the name of the file that is used to create a new template rules definition.
- Service Name: the name of the service that your rules provide.
- Interface Type: the contract for the service being provided. Rules services support Java and WSDL contract types.
- Package Name: package name used for the new Rules file.
Procedure 8.10. Create a Rules Service
- Create a new SwitchYard Rules file in the SwitchYard Editor JBoss Developer Studio plug-in.
- The MyService interface can be as simple as this, with no SwitchYard-specific imports:
package com.example.switchyard.docs; public interface Example { public void process(MyData data); }
- The generated rule template looks like this:
package com.example.switchyard.docs import org.switchyard.Message global Message message rule "RulesExample" when // insert conditional here then // insert consequence here System.out.println("service: ExampleService, payload: " + message.getContent()); end
- Input the values into the SwitchYard Editor's SwitchYard Rules File screen.
- Click Finish.
8.5.3. Stateless and Stateful Rules Executions
Introduction
By default, service method invocation creates a new Drools knowledge session, execute it given the passed-in domain data and then be disposed cleanly.
However, it is possible to configure SwitchYard so that a stateful knowledge session is used. To do this, you use the FIRE_ALL_RULES action type instead of EXECUTE.
There is also a capability which allows you to insert facts into a stateful knowledge session without firing the rules. In this case, use the INSERT action type.
8.5.4. Stateless Knowledge Session
Stateless session that does not utilize inference is the simplest use case for JBoss Rules. A stateless session can be called like a function. It can be passed some data and then receive some results back.
Here are some common use cases for stateless sessions:
- Validation
- Is this person eligible for a mortgage?
- Calculation
- Compute a mortgage premium.
- Routing and Filtering
- Filter incoming messages, such as emails, into folders.Send incoming messages to a destination.
8.5.5. Stateful Knowledge Session
A stateful knowledge session is one which persists in memory, allowing it to span multiple invocations. They can change iteratively over time. In contrast to a Stateless Session,
the dispose()
method must be called afterwards to ensure there are no memory leaks, as the Knowledge Base contains references to Stateful Knowledge Sessions when they are created. StatefulKnowledgeSession also supports the BatchExecutor
interface, like StatelessKnowledgeSession, the only difference being that the FireAllRules command is not automatically called at the end for a Stateful Session.
Here are some common use cases for Stateful Sessions:
- Monitoring
- Stock market monitoring and analysis for semi-automatic buying.
- Diagnostics
- Fault finding and medical diagnostics
- Logistics
- Parcel tracking and delivery provisioning
- Compliance
- Validation of legality for market trades.
8.5.6. Mapping Global Variables
You can map variables from your SwitchYard Exchange, Context or Message into JBoss Rules globals with MVEL expressions.
- To map the variables, hover the mouse over the Rules component in
switchyard.xml
and click Properties icon.Figure 8.3. Properties dialog for Rules Component
- In the Properties dialog, click Implementation. From the right hand side panel, click Operations tab to view Operation Mapping tooling window.
Figure 8.4. Operations Mapping
8.5.7. Map Global Variables
- Configure the rules implementation.NoteYour expression can use the variables exchange (
org.switchyard.Exchange
), context (org.switchyard.Context
) or message (org.switchyard.Message
).Context can be accessed in the expression as a java.util.Map. When accessing it as such, the default properties Scope is IN. This can be overridden using the contextScope attribute by changing it to OUT or EXCHANGE - Use these global variables in your JBoss Rules Drools Rule Language file:
package example global java.lang.String service global java.lang.String messageId global com.example.Payload payload rule "Example" when ... then ... System.out.println("service: " + service + ", messageId: " + messageId + ", payload: " + payload); end
NoteIn a more realistic scenario, the payload would be accessed in rule firing because it was inserted into the session directly by the RulesExchangeHandler, and thus evaluated (rather than being accessed as a global).
8.5.8. Mapping Facts
The object which is inserted into the rules engine as a fact by default is the SwitchYard message's content. However, you can override this by specifying your own fact mappings.
8.5.9. Notes About Mapping Facts
- If you specify your own fact mappings, the SwitchYard message's content is not inserted as a fact. You can add a fact mapping with an expression of "message.content" if you want to still include it.
- There is no point in specifying the "variable" attribute of the mappings (as done for global mappings), as the result of each expression is inserted as a nameless fact.For stateless execution, the full list of facts is passed to the StatelessKnowledgeSessions'
execute(Iterable)
method.For stateful execution, each fact is individually inserted into the StatefulKnowledgeSession. - If the result of the mapping expression implements Iterable (for example, a Collection), then the result is iterated over, and each iteration is inserted as a separate fact, rather than the parent Iterable itself being inserted. This is not recursive behavior (because it is only done once).
8.5.10. Auditing a Service
SwitchYard supports basic audit mechanism to audit the Drools rules execution. For auditing a service, SwitchYard requires a CDI environment to run. You can write custom auditors for your service and use listeners to monitor them. For example, you can use listeners to audit a BPM process and save the audit details into a database while the process progresses. The listener then reports the audit details at a later time.
8.5.11. Consuming a Service from the Rules Component
Consuming a SwitchYard Service from within the Rules Component leverages the Channels capability. You can configure channels within your process that executes business rules.