Model Processing
This topic explains model processing details such as model storage, data extraction, server cache population, cache validity, repository cache rebuild, and parallel processing of models.
Model Storage and Publishing
- The product, offer ID mapping, and action are stored in the DATA_MODEL table in the database so that they can be loaded from the database on the next engine restart.
The plan fragment model is stored in the PLAN_FRAGMENT table so that a particular plan fragment model can be accessed by Orchestrator anytime during the plan execution.
-
The plan fragment model payload is converted into the process component model and published on a designated topic mentioned in the table below. The Jeopardy Management System component subscribes to this topic. On receiving the message, Jeopardy Management System creates in-memory objects for using the models readily.
The DATA_MODEL table is the primary storage location for all loaded models.
Data Extraction
The process of extracting model information is the same regardless of the online or offline model processing mode. The XML data models information is extracted from the files and the in-memory cache objects are populated with that information.
Server Cache Population
- The model cache is broken down into multiple model types. These types are PRODUCT, ACTION, and OFFERID. Based on the published models, cache information for each category is populated in the SERVER_CACHE table.
- Based on the maximum size of the in-memory model information for each model cache, this information is broken down into multiple rows.
- When Automated Order Plan Development (deployed either as a standalone or collocated instance) starts up, embedded model load engine components first checks to see if valid cache information exists in the SERVER_CACHE table. If cache information does not exists in the table or is not valid, the XML models are read from the DATA_MODEL table and the in-memory server cache information is regenerated.
- If valid cache information exists in the SERVER_CACHE table, this information is read instead of processing the XML models. This step saves a considerable amount of processing time as SERVER_CACHE information stores the pre-processed XML information.
- When a designated member instance processes all the models and writes information to the SERVER_CACHE table, this instance sends out a notification on the TIBCO EMS topic (tibco.aff.oms.events.refresh.cache) for all Automated Order Plan Development instances to read the updated cache information from the SERVER_CACHE table. Until this notification is processed, and Automated Order Plan Development continue to hold the existing in-memory information.
- While processing models for creating in-memory repository information, all the models are processed. The existing configuration parameter "Max No of Model cached" is still honored by Automated Order Plan Development.
Cache Validity
- The SERVER_CACHE table maintains cache validity that signifies if the cache information stored in the table is valid or not. The value one (1) signifies a VALID cache and value zero (0) signifies an INVALID cache.
- All the offline or online models are posted by the application and application cache is written to the database after all the models are processed. Cache validity is switched to valid one (1) after all the database write operations are performed.
Repository Cache Rebuild
When the SERVER_CACHE table is empty or has an invalid cache validity, the restarting application server processes the corresponding XML models from the DATA_MODEL table and repopulates the cache information in the SERVER_CACHE table. It also sets the validity of all the rows for the model type to a VALID (value of 1) status.