Application Data allows for objects to be made available to Conditions and Consequences without having to assert them into the Working Memory.
To use Application Data you must first declare them in your DRL, after any import declarations.
<application-data identifier="amount">java.lang.Integer</application-data>
The above lets my Rule Set know that a variable named "amount" is available in each condition and consequence and is of the type java.lang.Integer. With the Application Data now declared we can set their values in the Working Memory, the method signature is:
setApplicationData(String name, Object data)
Only objects can be added to the Application Data; primitives must be wrapped:
workingMemory.setApplicationData("amount", new Integer(3));
If you are using the Java semantic you must unwrap your primitives on comparisons:
<java:condition>marbes.getCount() == amount.intValue()</java:condition>
However Groovy performs autoboxing so the following is possible:
<groovy:condition>marbes.getCount() == amount</groovy:condition>
Any object can be made available and is automagically bound to the variable name specified.
If an identifier is not declared in a Rule Set it will not be available to any Conditions or Consequences, even if another Rule Set declares it and sets the value in the Working Memory.
If an Application Data identifier is declared more than once for different Rule Sets in a single RuleBase then they reference the same object in the Working Memory and must be of the same type - a RuntimeException is thrown if the types are different.
The Pet Store Example illustrates Application Data being used to pass a JFrame reference to a Consequence to allow user feedback.