Red Hat Training

A Red Hat training course is available for Red Hat Fuse

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.
A JBoss Fuse subscription includes an entitlement to use embedded BRMS (Drools) as a SwitchYard component only. All other uses (for example, with Apache Camel) require a separate BRMS subscription.
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


  • 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

  1. Create a new SwitchYard Rules file in the SwitchYard Editor JBoss Developer Studio plug-in.
  2. The MyService interface can be as simple as this, with no SwitchYard-specific imports:
    public interface Example {
        public void process(MyData data);
  3. The generated rule template looks like this:
    import org.switchyard.Message
    global Message message
    rule "RulesExample"
            // insert conditional here
            // insert consequence here
            System.out.println("service: ExampleService, payload: " + message.getContent());
  4. Input the values into the SwitchYard Editor's SwitchYard Rules File screen.
  5. Click Finish.

8.5.3. Stateless and Stateful Rules Executions


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:
Is this person eligible for a mortgage?
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:
Stock market monitoring and analysis for semi-automatic buying.
Fault finding and medical diagnostics
Parcel tracking and delivery provisioning
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.
  1. 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

    Properties dialog for Rules Component
  2. 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

    Operations Mapping

8.5.7. Map Global Variables

  1. Configure the rules implementation.
    Your 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
  2. 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"
            System.out.println("service: " + service + ", messageId: " + messageId + ", payload: " + payload);
    In 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.