Bulk Maintenance of Rate Rule Objects

The Engine uses CER to store rule objects for rate table data on CER's database tables. These stored rule objects act as a "mirror" copy of the rate table data in a form that can be accessed during CER calculations.

The CER rule objects may not accurately reflect the latest rate table data for a number of reasons:

An administrator has changed rates in the application but not yet applied the rate changes to CER.
The administration application contains an "Apply Changes" action, which will request a deferred process to execute which will incrementally make changes to the affected CER rule objects.
The system has been initially deployed into production and no CER rule objects have yet been created for rate table data.
A system operator must arrange to run the RateCreateInitialRuleObjects process (see the Propagating Non Cúram Data For Cúram Express Rules guide).
A database for a development system has been built and no CER rule objects have yet been created for rate table data.
The developer can run the build prepare.application.data target prior to starting the application, or else the creation of rule objects will be performed automatically at application start-up¹.
Changes to rate table data have been made outside of the application's APIs.
Depending on the number of changes to rate table data, a system operator must arrange to either:
- choose the "Apply Changes" action (for small numbers of changes); or
- run the FullPropagationToRuleObjects batch process (for larger numbers of changes - see the Cúram Operations Guide).

¹ Shortly after start-up, the system checks the RuleObjectPropagatorControl table and runs initial propagation if it has not already been run. In a development environment, there is typically no discernible effect; however, in a production environment, the higher data volumes can mean that any initial propagation run after start-up (typically during user login) will cause the database transaction to timeout, depending on application server timeout settings.

To avoid this problem, be sure to run build prepare.application.data prior to starting the application.

Initial propagation is controlled by a single control row on the RuleObjectPropagatorControl table, which is populated by the DMX file included by the application. This control row ensures that initial propagation is only run once in an environment where many JVM instances attach to the database (e.g. during repeated runs of JUnit tests in a development environment, or when many application servers are used in a production environment).

The EJBServer/components/core/data/initial/RULEOBJECTPROPAGATORCONTROL.dmx file included by the application is required for the correct behavior of initial propagation, and so this file must not be customized or removed by customers. The control row populated by this DMX file must be reflected in any production database.