One way globals are normally used in Drools is as a way to externally parameterize the condition of a rule. The idea is to use globals instead of hardcoded values in the conditions of our rules.

As an example, let's go back to our eShop example. Let's say that we want a Drools session to detect suspicious operations for customers in our eShop application. We will define a suspicious operation as a customer with pending operations summing more than 10,000 dollars.

The input of our session will be the customers of our application and their orders. For each customer with pending orders for more than 10,000 dollars, we are going to insert a new object of the SuspiciousOperation type. The SuspiciousOperation class has the following structure:

public class SuspiciousOperation {    
    public static enum Type {
        SUSPICIOUS_AMOUNT,
        SUSPICIOUS_FREQUENCY;
    }    
    private Customer customer;
    private Type type;
    private Date date;
    private String comment;

    public SuspiciousOperation(Customer customer, Type type) {
        this.customer = customer;
        this.type = type;
    }
  
    //setters and getters
}

The following rule is enough to accomplish our goal of detecting suspicious operations:

rule "Detect suspicious amount operations"
when
    $c: Customer()
    Number( doubleValue > 10000.0 ) from accumulate (
        Order ( customer == $c, state != OrderState.COMPLETED, $total: total),
        sum($total)
    )
then
    insert(new SuspiciousOperation($c, SuspiciousOperation.Type.SUSPICIOUS_AMOUNT));
end

The rule is straightforward: for each Customer, it collects any Order whose OrderState is not COMPLETED and calculates the sum of their totals. If the total is more than 10,000, then the rule is activated. When the RHS of the rule is executed, it will insert a new object of the SuspiciousOperation type in the session.

As we already know, if we want to execute this rule, we need to include it as part of a knowledge base, create a session from it, and provide some facts to it, as follows:

    //Create a customer with PENDING orders for a value > 10000
    Customer customer1 = new CustomerBuilder()
                .withId(1L).build();
    Order customer1Order = ModelFactory.getPendingOrderWithTotalValueGreaterThan10000(customer1);

    //Create a customer with PENDING orders for a value < 10000
    Customer customer2 = new CustomerBuilder()
                .withId(2L).build();	
    Order customer2Order = ModelFactory.getPendingOrderWithTotalValueLessThan10000(customer1);

    //insert the customers in a session and fire all the rules
    ksession.insert(customer1);
    ksession.insert(customer1Order);
    ksession.insert(customer2);
    ksession.insert(customer2Order);

    ksession.fireAllRules();

A running example of the preceding code can be found in the code bundle under the chapter-05 module.

The previous example works fine as long as the threshold for what we consider a suspicious operation remains unchanged. However, what if we want to make this threshold variable?

One way of the many different ways to achieve this is to replace the hardcoded value in our rule with a global variable that can be defined whenever we want to run our session, as follows:

global Double amountThreshold;

rule "Detect suspicious amount operations"
when
    $c: Customer()
    Number( doubleValue > amountThreshold ) from accumulate (
        Order ( customer == $c, state != OrderState.COMPLETED, $total: total),
        sum($total)
    )
then
    insert(new SuspiciousOperation($c, SuspiciousOperation.Type.SUSPICIOUS_AMOUNT));
end

In the preceding example, we can see how the hardcoded threshold is no longer present in the DRL. We are now using a global of the Double type in the condition of our rule. Using this approach, the threshold of what we consider a suspicious operation can now be modified among the different executions of the session.

One important thing to mention is that when global variables are used as part of a rule constraint, the global must be set before the pattern where it is being used is evaluated. To avoid race conditions, it is considered good practice to set the global variables of a session before any fact is inserted. A downside of using global variables in the constraints of our rules is that their values are not cached by Drools. Every time a global variable needs to be evaluated, its value is accessed. In large knowledge bases, this could create performance issues.

Another common pattern related to globals is their usage as data sources for a session. Usually, this type of globals encapsulate the invocation of a service (database, in-memory map, web service, and so on) that introduces new objects into the session. This usage pattern always involves the from conditional element.

In order to demonstrate this scenario, we are going to modify the example introduced in the previous section and introduce a service call to retrieve the orders of our customers. The service will be modeled as an OrderService interface, containing a single method—getOrdersByCustomer—as shown in the following code:

public interface OrderService {
    public Collection<Order> getOrdersByCustomer(String customerId);
}

The idea here is to use this interface as a global that our rule can use to retrieve all the orders related to a customer. The final version of the DRL for this example will look similar to the following code:

global Double amountThreshold;
global OrderService orderService;

rule "Detect suspicious amount operations"
when
    $c: Customer()
    Number( doubleValue > amountThreshold ) from accumulate (Order ( state != OrderState.COMPLETED, $total: total) from         orderService.getOrdersByCustomer($c.customerId),sum($total))
then
    insert(new SuspiciousOperation($c, SuspiciousOperation.Type.SUSPICIOUS_AMOUNT));
end

In this version of our example, we are still using a global to hold the threshold of what we consider a suspicious operation, but we now also have a new global called orderService. Our rule is now invoking the global's getOrdersByCustomer method to get all the orders for a particular customer instead of getting the orders from the customer's orders property.

In this simple example, we may not realize the advantage of this approach—the orders of a customer are now being fetched only when/if required. In the previous version of the rule, we had to prefetch all the orders for all the customers before inserting them into the session. We didn't know, at the insertion time, whether the session will actually require all the orders for all the customers or not.

As mentioned earlier, we need to remember to set the value of the orderService global before we insert any Customer into the session, as follows:

OrderService orderServiceImpl = new OrderServiceImpl();
//a concrete implementation of OrderService.
ksession.setGlobal("orderService", orderServiceImpl);
ksession.insert(customer1);
ksession.insert(customer2);
ksession.fireAllRules();

One important thing to notice in the previous code is that we are no longer inserting the Orders as facts. The Orders will be retrieved on demand by the rules themselves. There is a catch though, a condition of a rule could be evaluated multiple times while rules are being executed. Every time the rule is re-evaluated, the data source will be invoked. When using this kind of pattern, the latency of the data source has to be taken into account.

We saw how to use a global as an interface to an external system in order to retrieve and introduce (but not insert) new information into the session. The question now is how to extract the generated SuspiciousOperation objects out of the session?

The rule from the previous example inserted a SuspiciousOperation object for each suspicious operation found. The problem is that these facts are not accessible from outside the session. A common pattern to extract information from a session is by using globals.

The idea behind this pattern is to use a global variable to collect the information we want to extract from the session. As the global is accessible from outside the session, any fact, object, or value that it references will also be accessible. The most common class of this type of globals is any instance of java.util.Collection or java. util.Map.

We are now going to modify the knowledge base we used in the previous section by adding a new rule that will collect any SuspiciousOperation fact into a global set:

global Double amountThreshold;
global OrderService orderService;
global Set results;

rule "Detect suspicious amount operations"
when
    $c: Customer()
    Number( doubleValue > amountThreshold ) from accumulate (Order ( state != OrderState.COMPLETED, $total: total) from orderService.getOrdersByCustomer($c.customerId),sum($total))
then
    insert(new SuspiciousOperation($c, SuspiciousOperation.Type.SUSPICIOUS_AMOUNT));
end

rule "Collect results"
when
    $so: SuspiciousOperation()
then
    results.add(
$so);
end

The code shows that we now have a new global called results and a new rule that will collect any instance of the SuspiciousOperation class into it.

The relevant Java code to execute this new version of the example is shown in the following:

Set<SuspiciousOperation> results = new HashSet<>();
ksession.setGlobal("results", results);

ksession.insert(customer1);
ksession.insert(customer2);
ksession.fireAllRules();

//variable 'results' now holds all the generated SuspiciousOperation objects.

After the rules are executed, the global set will contain the references of any SuspiciousOperation object generated during the session's execution. We can then use these objects outside the session where they were created.

The last common usage pattern regarding globals that we are going to cover is the usage of globals on the right-hand side of a rule as a way to interact with an external system. The idea behind this pattern is simple, we saw that we can use a global to introduce new information into a pattern (using the from conditional element). We can also use a global to interact with external systems on the right-hand side of a rule. The interaction with this external system could be unidirectional (getting information from the system or sending information to the system) or bidirectional (sending and receiving information from the system).

Continuing the previous example, let's say that now we want to notify each SuspiciousOperation found to an external audit system. We have two options here, we now know that we can access these generated facts using the global set introduced in the previous section. We could, from within the Java code, iterate over this list and send each of its elements to the audit system. Another option is to leverage this in the session itself.

This new interface will be represented in our code by an interface called AuditService. This interface will define a single method—notifySuspiciousOperation—as shown in the following code:

public interface AuditService {
    public void notifySuspiciousOperation(SuspiciousOperation operation);
}

We need to add an instance of this interface as a global and create either a new rule that invokes its notifySuspiciousOperation method or modify the Collect results rule so that it now invokes this method too. Let's take the first approach and add a new rule to notify the audit system:

...
global AuditService auditService;
...
rule "Send Suspicious Operation to Audit Service"
when
    $so: SuspiciousOperation()
then
    auditService.notifySuspiciousOperati
on($so);
end

In the preceding code snippet, we are only showing the new code that we have introduced in the previous example. The new rule we have created is using the new global that we defined to notify the audit system about each generated SuspiciousOperation objects. It is important to remember that Drools will always execute the rules in a single thread. Ideally, the RHS of our rules should not involve blocking operations. In the case where blocking operations are required, the introduction of an asynchronous mechanism to execute the blocking operation in a separate thread is considered as a good option most of the time.

We have covered the four common usage patterns of globals in Drools. We are now going to introduce a similar concept: channels.

A query is evaluated on-demand by invoking KieSession's getQueryResults method:

public QueryResults getQueryResults(String query, Object... arguments);

This method takes the name of the query and the list of its arguments (if any). The order of the arguments corresponds to the order of the parameters in the query definition. The result of this method is a QueryResults object:

public interface QueryResults extends Iterable<QueryResultsRow> {
    String[] getIdentifiers();    
    Iterator<QueryResultsRow> iterator();    
    int size();
}

The QueryResults interface extends Iterable and represents a collection of QueryResultsRow objects. The getIdentifiers() method returns an array of the query's identifiers. Any bound variable defined in the query will became an identifier in its result. For example, our Get All Suspicious Operations query only defined one identifier, $so. Identifiers are used to retrieve the concrete value of a bound variable when a query is executed.

The following code can be used to execute the Get All Suspicious Operations query:

QueryResults queryResults = ksession.getQueryResults("Get All Suspicious Operations");
for (QueryResultsRow queryResult : queryResults) {
    SuspiciousOperation so = (SuspiciousOperation)queryResult.get("$so");
    //do whatever we want with so
    //...
}

The preceding code executes the Get All Suspicious Operations query and then iterates over the results extracting the value of the $so identifier, in this case, instances of the SuspiciousOperation class.

On-demand queries are used when we want to execute a particular query at a particular point in time. Drools also provides another way to execute queries, it allows us to attach a listener to a query so that we can be notified about the results as soon as they become available.

Live queries are executed using the following Kie Session's method:

public LiveQuery openLiveQuery(String query,Object[] arguments,ViewChangedEventListener listener);

Just like with on-demand queries, the first argument we need to pass to this method is the name of the query we want to attach a listener to. The second parameter is the array of arguments that the query is expecting to receive. The third parameter is the actual listener that we want to attach to the query. The result of this method is a LiveQuery class instance.

Let's take a closer look at the ViewChangedEventListener interface:

public interface ViewChangedEventListener {
    public void rowInserted(Row row);
    public void rowDeleted(Row row);
    public void rowUpdated(Row row);
}

As we can see, the ViewChangedEventListener interface is used not only for receiving new facts matching the specified query, but we can also detect modifications or retractions of these facts. Drools engine will notify this listener as soon as a fact matches the specified query, when a previously matching fact gets modified or the modifications of a previously matching fact excludes it from the query's filter.

In the previous section, we saw how to use global variables to communicate the results, actions, and general rule execution information to the outside world. However, what if we wanted to do so in a generic way—for every rule—without modifying existing rules? To do so, we have other mechanisms such as Event Listeners.