CER Sessions

The main data items used with CER are:

Rule Objects
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
Attribute Values
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:

Recalculation Strategy
The strategy for handling a request to recalculate a CER attribute value within a CER session¹.

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.
Data Storage
The storage mechanism²to 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:

Recalculation Strategy:
- curam.creole.execution.session.RecalculationsProhibited
  Throws an error if any recalculation within the CER session is attempted.
- curam.core.sl.infrastructure.propagator.impl.ImmediateRecalculationStrategy
  Performs recalculations immediately (synchronously, within the same database transaction).
- curam.core.sl.infrastructure.propagator.impl.DeferredRecalculationStrategy
  Defers recalculations (for stored attribute values) to another database transaction.
  
  Defers recalculations (for stored attribute values) to another database transaction.
Data Storage:
- curam.creole.storage.inmemory.InMemoryDataStorage
  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.
- curam.creole.storage.database.DatabaseDataStorage
  Retrieves external³rule objects from either:
- curam.creole.execution.session.RuleObjectsSnapshot.SnapshotDataStorage
  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.
  - a Rule Object Converter registered with the Database Data Storage. Each rule object converter nominates the rule classes that it handles, and when invoked⁴the rule object converter will read underlying business tables to obtain the appropriate data and populate rule objects in memory and return them to Database Data Storage; or
  - CER's own database tables for storing rule objects, if no rule object converter is registered to handle the rule class requested.
  External rule objects are available for retrieval and manipulation by subsequent database transactions.
- curam.creole.storage.hybrid.HybridDataStorage
  Combines behavioral aspects of InMemoryDataStorage and DatabaseDataStorage. Reserved for Cúram internal use only.
Rule Object Factory:
- curam.creole.execution.session.StronglyTypedRuleObjectFactory
  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.
- curam.creole.execution.session.InterpretedRuleObjectFactory
  Creates and retrieves rule objects in a fully-interpreted (and thus dynamic) way. (see The Rule Set Interpreter).

CAUTION:

In general you should not use more than one CER Session within one database transaction. The in-memory copies of rule objects in a CER Session are independent of in-memory copies of rule objects in all other CER Sessions.

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.

Unit tests
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).
Production logic with dynamic rule sets
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.
Snapshots
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 ability for CER to perform recalculations directly is now superseded by the Dependency Manager (see The Dependency Manager).

The CER recalculation strategy interface and implementations are provided for backwards compatibility only.

² Since Cúram V6, CER offers a choice of data storage implementations. These data storage implementations affect whether rule objects, created or changed in one transaction, can be retrieved and/or changed in another transactions.

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.

³ As an optimization, only external rule objects and their attribute values are retrieved from data in the Cúram database. Internal rule objects and their attributes, by their nature, can be reliably recomputed later, whereas external rule objects typically contain data from external sources and thus cannot be recomputed.

⁴ Note that each rule object converter is permitted to impose limits on its support for readall and readall expressions.

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.