The main data items used with CER are:
A rule object is an instance of a rule class from a CER rule set; for example, the rule object for the person "John Smith"; and
An attribute value is the value of a CER rule attribute on a particular rule object; for example John Smith's date of birth.
All interaction with CER rule objects and attribute values occurs within a CER Session. These interactions include the creation, retrieval and/or removal of CER rule objects, and any calculation or recalculation of attributes on rule objects.
Each CER Session is created by use of the curam.creole.execution.session.Session_Factory class.
When a CER Session is created, the following must be specified:
The strategy for handling a request to recalculate a CER attribute value within a CER session1.
The strategy for handling a request to recalculate a CER attribute value; for example whether to recalculate immediately, defer the recalculation to another transaction, or disallow the recalculation altogether.
The storage mechanism2to use for persistent rule objects; for example in-memory only (which will be lost when the session goes out of scope), database storage, or snapshot storage.
In turn, implementations of data storage must specify a rule object factory to use. This factory governs whether rule objects are created in a strongly-typed or interpreted-only way.
The application includes these implementations:
Throws an error if any recalculation within the CER session is attempted.
Performs recalculations immediately (synchronously, within the same database transaction).
Defers recalculations (for stored attribute values) to another database transaction.
Defers recalculations (for stored attribute values) to another database transaction.
Keeps rule objects in memory only. Rule objects in this data storage are only available while the data storage is in scope - typically for a single database transaction only.
Retrieves external3rule objects from either:
Creates an XML document containing details of a set of rule objects involved in the dependencies of one or more attribute calculations. Provides an "audit trail" of the data ultimately used in that calculation. Typically the XML document can be stored on a database table so that the snapshot of rule objects can be queried (but not altered) by a subsequent database transaction.
External rule objects are available for retrieval and manipulation by subsequent database transactions.
Combines behavioral aspects of InMemoryDataStorage and DatabaseDataStorage. Reserved for Cúram internal use only.
Creates and retrieves rule objects as instances of Java classes generated by the CER Test Code Generator (see CER Test Code Generator). Must not be used in production code.
Creates and retrieves rule objects in a fully-interpreted (and thus dynamic) way. (see The Rule Set Interpreter).
Behavior is not guaranteed if more than one CER Session (in the same transaction) attempts to retrieve or query the same rule object from the database.
Use an InMemoryDataStorage (for speed of execution) with a StronglyTypedRuleObjectFactory (so that generated Java classes can be used in tests), and RecalculationsProhibited (so that tests do not accidentally change data part-way through).
Use a DatabaseDataStorage (so that rule objects are available across transactions) with an InterpretedRuleObjectFactory (so that rule sets are fully dynamic), and RecalculationsProhibited, and use the features provided by the Dependency Manager (see The Dependency Manager) to perform any requests to recalculate CER values in a new (and independent) CER session.
Use a SnapshotDataStorage (so that rule objects are read from an unalterable XML document) with an InterpretedRuleObjectFactory (so that rule sets are fully dynamic), and RecalculationsProhibited (snapshots do not support changes).
The CER recalculation strategy interface and implementations are provided for backwards compatibility only.
Importantly, the choice of data storage does not affect the semantics of your rule expressions. This means that you can use a light-weight (in-memory) data storage for your JUnit tests (so that large numbers of JUnit tests can execute quickly), and a persistent (database) data storage for your production logic (so that rule objects are persisted across transactions), without any differences in your underlying calculations.
For example, some rule object converters may not support the execution of a readall (without a nested match), and/or place restrictions on which rule attributes can be named in the match 's retrievedattribute value.
Any violations of the rule object converter's limitations will result in an exception being thrown at runtime. You should ensure that your rule set tests include logic which invokes the rule object converters (i.e. which runs against Database Data Storage) - in contrast to the majority of your rules logic tests which will use In Memory Data Storage (and which thus do not invoke the rule object converters).
See the documentation for each rule object converter implementation to understand any limits it imposes on its support for readall.