Memory-based Planning Engine

Memory-based Planning Engine

The Memory-based Planning Engine efficiently manages all the processes which constitute a complete planning run. It utilizes a high degree of concurrency among the snapshot tasks, eliminates nonvalue-added operations, and combines related tasks into a single task. It moves long running tasks, such as deleting previous planning data and loading snapshot data into the MRP snapshot tables out of the critical path. It also utilizes interprocess communication to manage all the planning tasks. The Memory-based Planning Engine is the only engine supported in the Oracle MRP product.

Instead of waiting for all the data to be loaded into files and tables, the Memory-based Planning Engine begins planning once calculations are loaded in memory. Greater control over planning activities improves the planner's efficiency. The planning process passes through fewer phases, greatly reducing planning lead time.

Tip: These topics are technical and are not intended for most users. It is not necessary to read them to be able to use Oracle MRP.

There are eight main features of the Memory-based Planning Engine:

• enhanced method of low-level code calculation: because component changes from Work in Process and Bill of Material information appear in a single structure, the planning engine performs loop-checking and low-level code calculation in one step

• database loads performed in parallel, not sequentially

• enhanced loop-checking: you can detect loops introduced by discrete and nonstandard job component requirements, and by WIP component changes

• flexible configuration: you can specify the number of Workers available to perform snapshot tasks, taking advantage of hardware resources

• locked tables not required: the Memory-based Planning Engine gathers consistent views of supply and demand data without locking users out of the system

• efficient explosion technique, which occurs alongside the snapshot process

• reduced number of tasks and simplified process dependencies

• preprocessing and setup times: the memory-based engine performs netting calculations based on snapshot data in memory

The Memory-based Planning Engine plays a significant role in several functions of Oracle MRP. In some cases, the performance of functions and procedures are enhanced by the engine. In other cases, you can perform functions and procedures only when the current plan was generated with the engine. The following list contains all such functions and procedures:

• auto-release planned orders

• byproduct planning

• comparing current and snapshot data

• full pegging

• graphical display of planning data

• net change replan

• phantom assembly planning

• supply chain planning

See Also

• Phases of the Planning Process

• Processing Steps

• Processes

• Snapshot Tasks

• Read Consistency

• Interprocess Communication

• Configuring the Memory-based Planning Engine

Processing Steps

The Memory-based Planning Engine executes the planning run in the following sequence:

1. Snapshot preprocessing. This is the first step preformed as a part of the Snapshot. It consists of tasks that need to be done prior to the Snapshot. These tasks include calculating repetitive planning periods for all the planned organizations and auto-reducing the master production schedules.

2. Item list determination. This step involves determining the items that will be planned as part of the current planning run. The plan-level option included items determines the items that will be planned. All other Snapshot activities cannot start until this step is complete.

3. Deleting old data. This step consists of cleaning all the snapshot and planner output data from the previous planning run.

4. Creating flat files of snapshot data. This step involves selecting the data from the system tables and writing them to flat files. Since this data is written to flat files, the deletes are not a prerequisite for this task.

5. Loading flat files into the database. This step loads the Snapshot flat files into the MRP Snapshot tables.

6. Snapshot post-processing. This step consists of cleanup activity and execution of the user-defined Snapshot tasks (such as updating item categories and ABC classes) in MRP_SYSTEM_ITEMS.

7. Netting. This step performs the gross-to-net explosion, during which suggested supply orders are generated.

See Also

• Phases of the Planning Process

• Processes Snapshot Tasks

• Read Consistency

• Interprocess Communication

• Configuring the Memory-based Planning Engine

• Parallel Processing

When executing the planning run, the above steps are carried out by one or more of the following seven processes:

• Memory-based snapshot. This is the main Snapshot process. It is launched by the Launch Planning Process form. It's primary task is to prepare the list of planned items and perform the pre- and post-processing steps. Once it performs these steps, the memory-based snapshot behaves like a Snapshot Worker.

• Snapshot monitor. This controls the rest of the planning process. It is launched by the memory-based snapshot and it in turn launches the snapshot workers, delete workers, loader workers, and the memory-based planner. The number of delete worker launched by the snapshot monitor is determined by the MRP:Snapshot Workers profile option. It launches the Delete Workers after it prepares the list of delete tasks (see Figure 45). The snapshot monitor also maintains a list of snapshot tasks and delete tasks and the current status of each task. It uses this list to provide the next snapshot task to the memory-based snapshot and snapshot workers. It uses the status of the delete tasks to determine if the flat files created by the memory-based snapshot and snapshot workers can be loaded into the database by the loader workers. The snapshot monitor is also responsible for ensuring the read consistency of the data captured by the memory-based snapshot and the snapshot workers.

• Snapshot workers. The number of these workers launched by the snapshot monitor is based on the MRP:Snapshot Workers profile; setting the number to one makes the Snapshot run as a single-threaded process. The snapshot workers collect data on bills of material, work in process, on-hand quantities, purchasing, firm planned orders, routings and work in process job resource requirements. The snapshot monitor controls the snapshot workers and receives instructions on which tasks to perform next. The snapshot worker places the data into flat files and communicates the completion of the task and the file name to the snapshot monitor.

• Snapshot delete workers. These workers are launched by the snapshot monitor and delete the planning data from the last planning run. Each worker reads MRP_SNAPSHOT_TASKS to get the next delete task. After it completes the delete, it updates the completion date in MRP_SNAPSHOT_TASKS.

• Loader workers. The snapshot monitor launches one loader worker for each table requiring a load. The snapshot monitor launches the loader worker after the flat file for the snapshot data has been written and the last planning run data has been deleted. The loader worker uses SQL*Loader to load the data. The profile option MRP:Use Direct Load Option controls whether SQL*Loader uses direct loading or conventional loading methods.

  Warning: If you use Direct Load, the database grows, potentially leading to increased storage space. One way to counter this side effect is to export and reimport the tables affected by the planning processes.

• Memory-based planner. The memory-based planner performs the gross-to-net explosion. Launched by the Snapshot Monitor or separately by the user, the memory-based planner loads the snapshot flat files into memory, nets the supply and demand for planned items and writes the output to flat files. These flat files are loaded into the database by loader workers.

• Planner delete worker. This worker is launched by the memory-based planner. It runs only when the memory-based planner is run without the snapshot. It is responsible for deleting data from planner output tables, including MRP_RECOMMENDATIONS, MRP_GROSS_REQUIREMENTS, and MRP_FULL_PEGGING.

  

Figure 7-44 illustrates the Snapshot Monitor Process logic under the Memory-based Planning Engine. Below is a detailed explanation of the logic.

1. Launch X Snapshot Workers via the Concurrent Manager, where X is the number of Snapshot Workers to launch, as defined by the profile option MRP:Snapshot Workers.

2. Begin Snapshot Preprocessing. These tasks include calculating repetitive planning periods for all the planned organizations, and relieving the MPS.

3. List the items that the planning engine will include in the current run. The plan-level option Included Items determines this list.

4. The Snapshot Monitor launches Snapshot Delete Workers to clean old snapshot and planning output from the tables.

5. Snapshot Workers select data from system tables, including work in process, inventory, purchasing, and bill of materials and write the data to flat files. Since the data is written to flat files, the deletes are not a prerequisite for this step.

6. Loader Workers load the flat files from step 5 into the MRP snapshot tables.

7. Once the workers complete the list of items for planning, lock the tables if Snapshot Lock Tables is set to Yes, then ask the Snapshot and Snapshot Workers to set transaction to read-only.

8. Loop until the workers complete.

9. Snapshot post-processing begins, which consists of cleanup activities and the execution of user-defined Snapshot Tasks.

After these steps, the Memory-based Planner performs the gross-to-net explosion and creates new supply orders.

If the user ran the Memory-based Planner without the Snapshot, the Memory-based Planning Engine launches Planner Delete Workers, which delete data from the planner output tables.

See Also

• Phases of the Planning Process

• Snapshot Tasks

• Read Consistency

• Interprocess Communication

• Configuring the Memory-based Planning Engine

• Parallel Processing

Snapshot Tasks

Once MRP_SYSTEM_ITEMS is loaded, then all other tasks can proceed. Each of the following tasks is responsible for creating a set of files that correspond to the database tables:

• Capacity information: loads job resource requirements and capacity resource information

• Delete: deletes data from relevant MRP tables which belongs to the previous plan

• Demand information: loads independent gross requirements and material reservations

• Inventory information: loads information regarding inventory lots

• Item information: loads inventory items, primary suppliers, item categories, item classifications, quantity on hand and cost information

• MPS orders information: loads MPS planned orders

• MRP orders information: loads MRP firmed planned orders

• Purchasing information: retrieves supply information regarding purchase orders, purchase requisitions, intransit shipments, intransit receipts and purchase orders in receiving from the database

• Safety stock: loads time-phased safety stock information

• Substitute items information: loads substitute items

• WIP and BOM component information: loads BOM structures, pending ECOs, component requirements from discrete jobs, flow schedules, repetitive schedules, and non-standard jobs; calculates low level codes and checks loops introduced by both WIP components and BOMs

• WIP information: loads discrete jobs, flow schedules, non-standard jobs, repetitive schedules and calculates aggregate repetitive schedules

When a given file is complete, each tasks submits a request to the Snapshot Monitor. The Snapshot Monitor then checks the dependency and begins loading the file, for use by the Memory-based Planner.

See Also

• Phases of the Planning Process

• Processing Steps

• Processes

• Read Consistency

• Interprocess Communication

• Configuring the Memory-based Planning Engine

Read Consistency

Certain tasks require a database lock in order to guarantee a consistent read. For example, discrete job information and inventory quantities require a lock on the inventory transactions table in order to guarantee a consistent read. Consider the situation where you have a subinventory with a quantity of 100 units, and a discrete job for 25 units. Between the time the Snapshot reads the inventory information and the time the Snapshot reads the discrete job information, 10 units are completed from the job. The Snapshot needs to guarantee that it populates the MRP tables with inventory of 100 and discrete job quantity of 25, or inventory for 110 and discrete job quantity of 15. Because each task may be processed by independent processes, the Snapshot cannot guarantee that both tasks are executed at the same time. Therefore, by locking the inventory transactions table, the Snapshot guarantees a consistent read.

One of the advantages of the Memory-based Planning Engine is its ability to get a consistent image of all planning data without locking users out of the system. The planning engine accomplishes this with the ORACLE RDBMS feature called "set transaction read-only". With this option, you do not need to lock tables for the duration of the planning run. The Memory-based Snapshot and Snapshot Workers capture all supply and demand data as it existed after a snapshot of the item list has been taken. All changes made to the data after that are not included.

The advantage in using the read-only option is that you do not need exclusive table locks, which lock users out of the table for the entire duration of the Snapshot. Instead, you simply co-ordinate the snapshots performed by the Memory-based Snapshot and Snapshot Workers. Since the collection of data is performed by multiple processes, the "set transaction read-only" feature has to be executed at the same time by the Memory-based Snapshot and Snapshot Workers.

You can achieve two degrees of read consistency under the Memory-based Planning Engine. Set the Snapshot Lock Tables field (Plan Options window) to Yes. This forces the Snapshot Workers and the Memory-based Snapshot to execute the set transaction feature simultaneously. It also ensures that no transactions are performed while the snapshot processes are trying to set the transactions to read-only. To ensure this, the Snapshot Monitor gains an exclusive lock on the tables and instructions the Memory-based Snapshot and Snapshot Workers to execute the set transaction feature. As soon as the Snapshot Monitor receives confirmation from the snapshot processes the set transaction feature is complete, it releases the lock. In this way, you get a read-consistent snapshot with little time spent locking users out of the system.

Locking tables gives you the highest degree of data consistency, but you cannot perform any transactions while this lock is on. If you set the Snapshot Lock Tables field to No, the Snapshot Workers and the Memory-based Snapshot may execute the set transaction feature at different times. There is a remote possibility of some inconsistencies with this method.

See Also

• Phases of the Planning Process

• Processing Steps

• Processes

• Snapshot Tasks

• Interprocess Communication

• Configuring the Memory-based Planning Engine

• Parallel Processing

Oracle MRP breaks tasks into smaller tasks that are executed concurrently by independent processes (workers). The programs that execute these tasks concurrently need to communicate in order to coordinate their actions.

Inter–Process Communication

The Memory-based Planning Engine uses a combination of database pipes and database tables for inter-process communication. The Memory-based Snapshot and Snapshot Workers communicate with the Snapshot Monitor via database pipes. These pipes carry messages that include requests for new tasks, task completion, and initiate the set transaction read-only RDBMS feature. The Snapshot Delete Workers communicate via the database table MRP_SNAPSHOT_TASKS. See also: Interprocess Communication

See Also

• Phases of the Planning Process

• Processing Steps

• Processes

• Snapshot Tasks

• Read Consistency

• Configuring the Memory-based Planning

• Engine Parallel Processing

Configuring the Memory–based Planning Engine

To configure the memory-based planning engine:

• Set profile options

• Define a number of target processes

Profile options

In addition to MRP:Snapshot Workers, you can define the following profile options to improve Memory-based Planning Engine performance:

• MRP:Environment variable to set path for MRP files

• MRP:Snapshot Pause for Lock (Minutes)

• MRP:Snapshot Workers

• MRP:Use Direct Load Option

See: Profile Options

Warning: If you use Direct Load, the database grows, potentially leading to increased storage space. One way to counter this side effect is to export and reimport the tables affected by the planning processes.

Setting up

To run the Memory-based Planning Engine, you must define a number of target processes in the concurrent processes in the concurrent manager. Use the following the formula to determine the number you require:

T=4+2S

where

T = the number of target processes required to run the Memory-based Planning Engine

S = the number of snapshot defined in MRP:Snapshot Workers

See: Managing Concurrent Programs and Requests, Oracle Applications User's Guide

See Also

• Phases of the Planning Process

• Processing Steps

• Processes

• Snapshot Tasks

• Read Consistency

• Interprocess Communication