Understanding Optimization Application Record Design

You use PeopleSoft Application Designer to design optimization application records to contain source data, result data, and other data. You also decide how the optimization engine uses these records for synchronization. For each record that you create, decide:

• Which data fields the record should contain.

  Among other data, these records contain the data from the PeopleSoft application database that is used in the optimization process.

• How the optimization engine uses the record for synchronization.

  If the record is read once, the optimization engine reads this data during the initial load only. If the record is readable, the optimization engine checks for updates with every optimization transaction. If the record is writable, the optimization engine is allowed to modify the data in the database. All records except read-once records must have a VERSION field.

• Whether the record should be scenario-managed.

  A record should be scenario-managed if it contains data pertaining to multiple analytic instances. Such records must have a PROBINST key field, which the optimization engine uses as an additional key for storing and retrieving multiple solutions.

In PeopleSoft Optimization Framework, scenario management is the mechanism to manage different source and result data sets using the same tables. A set of source data and associated result data is called an analytic instance. You can break down large optimization problems into smaller, more manageable problems (or analytic instances) that can each be solved independently. Individual analytic instances can share common data.

This concept can be extended to what-if scenarios to plan for potential business situations. Separate analytic instances can be created with what-if data and solved using optimization separately, without fear of affecting live data.

In terms of the exercise example, any number of people might want exercise schedules using the optimization application. Exercise goal data and the optimization-generated exercise schedule data are unique to each person. However, different people share the same set of exercise machines. In this case, it is logical to treat the generation of an individual person's exercise schedule as a separate analytic instance.

In the exercise example, you would mark the data that is specific to each person (such as exercise goals and exercise schedules) as scenario-managed, and the data that is shared by all people (such as exercise machines) as nonscenario-managed. All scenario-managed records must include the PROBINST field as part of the primary key. This 20-character field identifies data that is specific to an analytic instance. During runtime, the optimization engine loads data for scenario-managed records based on the user-specified value for the PROBINST field. At any moment, the optimization engine contains data for only one analytic instance.

The following record, QE_ROSM_BIODATA, contains the name of a person who exercises, and physical data about the person. This record is read once and is scenario-managed. Notice the use of the PROBINST field:

Image: QE_ROSM_BIODATA record

The following diagram illustrates the Record fields in QE_ROSM_BIODATA Record.