This batch process is the heavyweight multiple-stream process that identifies the dependents which are potentially affected by the changes in the submitted precedent change set, and recalculates them. The time taken to run this process will vary according to how many dependent recalculations are required, and may be considerable.
The Perform Batch Recalculations From Precedent Change Set step must be executed multiple times - once for each dependent type registered with the Dependency Manager (see the output produced by the previous step Submit Precedent Change Set). You are free to choose the most appropriate order in which to process the dependent types; for example, it is likely to be more critical to your business to reassess case determinations (see the Inside Cúram Eligibility and Entitlement Using Cúram Express Rules guide) than it is to identify out-of-date advice (see the Advisor Configuration Guide). You are also free to spread the processing for different dependent types over several days, but note that further precedent change items queued for batch cannot be processed until the currently-submitted precedent change set has completed the full Dependency Manager batch suite.
The Perform Batch Recalculations From Precedent Change Set step uses Cúram's Batch Streaming Architecture (see the Cúram Batch Performance Mechanisms Guide) and as such the processing is divided into these phases:
A phase, which must be run as a single process, that identifies the dependents (of a given dependent type) potentially affected by changes in the submitted batch precedent change set. The IDs of the identified dependents are written to "chunks" for processing by the next phase.
A phase, amenable to concurrent execution by multiple processes, that takes a chunk of identified dependents and recalculates each dependent.
To run this batch process for a particular dependent type, execute the following command (on one line):
build runbatch -Dbatch.program=
curam.dependency.intf.PerformBatchRecalculationsFromPrecedentChangeSet.process
-Dbatch.username=SYSTEM
-Dbatch.parameters="dependentType= code-for-dependent-type "
By default the single process will perform both phases; however, you can run additional "Stream" processes concurrently on other machines to perform the second phase in parallel (see the Cúram Batch Performance Mechanisms Guide for more information on parallel processing and the environment variables which govern the parallel processing behavior of this Perform Batch Recalculations From Precedent Change Set process). To run a "stream" process for a particular dependent type, execute the following command (on one line):
build runbatch -Dbatch.program=
curam.dependency.intf.PerformBatchRecalculationsFromPrecedentChangeSetStream.process
-Dbatch.username=SYSTEM
-Dbatch.parameters="dependentType= code-for-dependent-type "
The batch process will fail to start with a fatal error if any of the following occur:
Otherwise, the batch process will start, and attempt to identify and recalculate the affected dependents. The result of attempting to recalculate a particular dependent will be either:
The dependent was found and recalculated correctly and processing continues normally.
The dependent was not found and so could not be processed. This situation can occur if a client of the Dependency Manager decides that a dependent should no longer exist, but neglects to request the Dependency Manager to remove dependency records for that dependent. Under these circumstances, the Dependency Manager automatically removes the extraneous dependency records and writes a warning to application log/batch stream output.
An exception was thrown during the recalculation of the dependent (for example, if a CER calculation encountered a "division by zero" problem). The thrown exception is written to the batch stream output and recovery processing is handled by the Cúram's Batch Streaming Architecture's "skip" processing.
When this Perform Batch Recalculations From Precedent Change Set process has completed, a comprehensive report is written with details of how many dependents were processed successfully, vs. not found, vs. encountered errors. If any errors were encountered, you should examine the output logs from your batch streams to obtain details of the errors.
This output may be helpful in understanding why a particular dependent was identified as requiring a recalculation.
As such, this kind of accidental additional run for a dependent type will not harm the system but may use up valuable processing time.
Take careful note of the list of dependent types and keep track of which dependent types you have processed and which remain to be processed.
Verbose logging can adversely affect performance and scalability in a production system.