Memory Based Planning Process is an improved planning engine that utilizes a memory based architecture to help you achieve drastically reduced planning run times. The new 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 non-value added operations, and combines related tasks into a single task. The new architecture also moves long running tasks such as deleting previous plan data and loading snapshot data into the MRP snapshot tables out of the critical path. Memory Based Planning Process uses an efficient system of inter-process communication to manage all the planning tasks. This essay describes the architecture and technical features of the Memory Based Planning Processes.
The Memory Based Planning Process provides you with the features you need to be able to satisfy your performance requirements:
Shorter overall planning run time You will be able to complete planning runs with drastically reduced run times.
Reduced processing The Exploder process that determined the list of planned items and calculated low level codes is eliminated. The Exploder tasks are now done by the Snapshot processes.
Consistent Supply and Demand information You will be able to get read consistent snapshots of all the supply and demand data without locking users out of the system.
Flexible configuration You can specify the number of Workers to perform your snapshot tasks and take advantage of the hardware resources.
Enhanced loop checker You can detect loops introduced by Discrete and Non Standard Job component requirements. Component changes from WIP are read and merged into a single structure along with BOM information, where loop checking is performed. Both loop checking and calculation of low level codes are performed in one pass.
Improved inter-process communication You can take advantage of improved communication between the processes that manage the planning processes efficiently.
In-memory processing The process performs the planning calculations in memory.
The Memory Based Planning Process consists of the following steps:
This is the first step performed as a part of the Snapshot process and it consists of tasks that need to be done before data can be snapshoted. These tasks include calculating repetitive planning periods for all the planned organizations and auto-reducing the MPS schedules.
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 to be planned. All other Snapshot activities cannot start until this step is complete.
Deleting old data
This step consists of cleaning all the snapshot and planner output data from the previous planning run.
Creating flat files of snapshot data
This step involves selecting the data from the system tables i.e. WIP, INV, PO, and BOM and writing the snapshot data to flat files. Since this data is written to flat files, the deletes are not a pre-requisite for this task.
Loading flat files into database
This step loads the snapshot flat files into the MRP snapshot tables.
This is the last step in the Snapshot process and it consists of
clean-up activity and execution of the user-defined Snapshot tasks like updating item categories, ABC classes etc. in MRP_SYSTEM_ITEMS.
Netting This is the gross-to-net explosion and involves the netting of supply against demand and creating new supply orders.
Processes A group of seven processes make up the basic structure of Memory Based Planning Processes:
1. Memory Based Snapshot
2. Snapshot Monitor
3. Snapshot Workers
4. Snapshot Delete Workers
5. Loader Workers
6. Memory Based Planner
7. Planner Delete Worker
Following is a brief functional description of each of the planning processes:
1. Memory Based Snapshot is the main Snapshot process. It is launched by the character mode Launch Planning Process and 10SC Launch MRP/DRP/MPS Planning Processes form. It’s primary task is to prepare the list of planned items. In addition to preparing a list of planned items the Memory Based Snapshot performs the pre-processing and the post-processing tasks. After preparing the list of planned items and snapshoting the item information the Memory Based Snapshot behaves like a Snapshot Worker.
2. The Snapshot Monitor is the process that controls the rest of the planning processes. 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 Workers launched by the Snapshot Monitor is determined by MRP:Snapshot Workers profile. It launches the Delete Workers after it prepares the list of delete tasks ( See Figure 1). 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 to the database by the Loader Worker. The Snapshot Monitor is also responsible for ensuring the Read Consistency of the data snapshoted by the Memory Based Snapshot and the Snapshot Workers, the next section describes this in more detail.
3. Snapshot Workers are launched by Snapshot Monitor based on the MRP:Snapshot Workers profile. If this profile is set to one, the Snapshot runs as a single threaded process. If the profile is set to more than one the Snapshot runs as a multi-threaded process. The Snapshot Workers snapshot BOM, WIP, on-hand, PO, Firm Planned Orders, Routings and WIP job resource requirements. The Snapshot Worker is controlled by the Snapshot Monitor and receives instructions on which task to perform next. The Snapshot Worker snapshots the data to flat files and communicates the completion of the task and the name of the file to the Snapshot Monitor. You can configure the Snapshot process to run as single threaded or multi-threaded process, by selecting a value for the profile option MRP:Snapshot Workers.
4. Snapshot Delete Workers are launched by the Snapshot Monitor. The Snapshot Delete Workers delete the planning data from the last run. Each worker reads MRP_SNAPSHOT_TASKS to get the next delete task. After it competes the delete it updates the completion date in MRP_SNAPSHOT_TASKS to indicate the completion of the task.
5. Loader Workers are launched by the Snapshot Monitor. One loader worker is launched for loading each table. 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 (See Figure 2). The loader worker uses sql*loader to load the data. The profile option MRP:Direct Load controls whether direct load or conventional load is used by sql*loader.
6. Memory Based Planner performs the gross-to-net explosion. It is launched by the Snapshot Monitor or when the user just chooses to launch Planner. It 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 launched by the Memory Based Planner.
7. Planner Delete Worker is launched by the Memory Based Planner. It is not launched as part of the Memory Based Planning Processes but is launched only when the Memory Based Planning Processes run without the Snapshot. It is responsible for deleting data from the planner output tables such as MRP_RECOMMENDATIONS, MRP_GROSS_REQUIREMENTS, MRP_FULL_PEGGING.
One of the advantages of the memory-based architecture is the availability of consistent image of all the data snapshoted without having to lock users out of the system. The Memory Based Snapshot and Snapshot Workers snapshot all supply and demand data as it existed after the item list has been snapshoted. All changes made to the data after that are not included.
This is accomplished by using the Oracle DBMS feature-set transaction read only. The advantage in using read only option is that you do not need exclusive table locks which lock the users out of the table for the entire duration of the Snapshot. Since the snapshoting of data is performed by multiple processes, the set transaction read only has to be executed at the same time by the Memory Based Snapshot and the Snapshot Workers.
The plan parameter lock tables, controls the degree of Read Consistency attained by the Memory Based Snapshot and Snapshot Workers. If lock tables is set to Yes the Snapshot Monitor ensures that the set transaction read only is executed at the same time by the Memory Based Snapshot and the Snapshot Workers. It also ensures that no transactions are performed while the snapshot processes are trying to set transaction to read only . In order to ensure this the Snapshot Monitor gains an exclusive lock and instructs the Memory Based Snapshot and Snapshot Workers to do a set transaction read only (See Figure 1). As soon as Snapshot Monitor receives a confirmation from the snapshot processes of the set transaction read only, it releases the lock. The advantage here is that we get a read consistent snapshot with minimal locking of users out of the system.
When the plan parameter lock tables is set to No, the processes still execute a set transaction read only but Snapshot Monitor does not coordinate the execution of set transaction read only between processes.
Thus both Memory Based Snapshot and Snapshot Worker could be executing set transaction read only at different times, not necessarily far apart from each other. There is a possibility of some inconsistencies creeping into the system but it is fairly remote. The new planning engine gives you much better results when compared to the old Snapshot which runs without lock tables.
The memory-based architecture uses a combination of database pipes and databases tables for inter-process communication. The Memory Based Snapshot and Snapshot Workers communicate with the Snapshot Monitor via database pipes. These messages include requests for new tasks, task completion, initiate set transaction read only etc. (See Figure 3). Refer to Oracle 7 Application Developer’s Guide for more information on database pipes.
The Snapshot Monitor communicates with the Snapshot Delete Workers through the table MRP_SNAPSHOT_TASKS. The Snapshot Delete Workers read the table to get the next delete task and update the completion date in the table to indicate the completion of the task. The Snapshot Monitor queries this table to verify the completion of delete tasks.
A brief functional description of some of the snapshot tasks follows:
Purchasing information: This task retrieves supply information regarding purchase orders, purchase requisitions, intransit shipments, intransit receipts and purchase orders in receiving from the database.
WIP and BOM component information: This task loads BOM structures, pending ECOs, component requirements from discrete jobs, repetitive schedules, and non-standard jobs. It also calculates low level codes and checks loops introduced by both WIP components and BOMs.
Delete: This task deletes data from relevant MRP tables which belongs to the previous plan.
WIP information: This task loads discrete jobs, non-standard jobs, repetitive schedules and calculates aggregate repetitive schedules.
Capacity information: This task loads job resource requirements and capacity resource information.
Demand information: This task loads independent gross requirements and material reservations.
Safety stock: This task loads time phased safety stock information.
Inventory information: This task loads information regarding inventory lots.
Substitute items information : This task loads substitute items.
MPS orders information: This task loads MPS planned orders.
MRP orders information: This task loads MRP firmed planned orders.
Item Information: This task loads inventory items, primary vendors, item categories, item classifications, quantity on hand and cost information.
MRP: Snapshot Workers
You can configure the Snapshot to determine the number of Snapshot Workers to launch. This profile option determines the number of Snapshot Workers that the Snapshot launches . A larger value means that more tasks are performed in parallel. Too many workers, however can result in increased inter-process communications, system degradation and diminishing performance benefits. Too low a value for this profile option means that a potential advantage of parallel processing is not utilized. Memory Based Snapshot launches the same number of Delete Workers as the number of Snapshot Workers.
MRP: Snapshot pause for lock
With this profile option you can make the Snapshot process pause for the amount of time chosen by you to obtain locks. You can choose a value for this profile option depending on the amount of data, transaction volume, and the number of Snapshot Workers.
A choice to use Direct Load, loads the data into the tables faster than conventional loading. If the choice is not to use the Direct load, the Loader Workers use conventional load. Please refer to Oracle 7 Server Utilities User’s guide for more information on sql*loader.
MRP: Environment variable to set path for MRP files
A variable specified by the user will set the appropriate paths for the MRP files. If this profile is not used the files are written to
A process which controls and coordinates all the processes related to Memory Based Planner.
A process, which loads data from operating system files to the corresponding tables.
Snapshot Delete Worker
The Snapshot Delete Worker performs database delete operations, it removes previous planning data from the tables.
Snapshot Workers A planning process which snapshots current supply and demand information required to calculate net material requirements.
Memory Based Snapshot
A planning process that determines the list of items to be planned and performs some of the snapshot activities.
A consistent view of all the data, which consists of all the data committed by other transactions at the time of the read and all the changes made by the user up to the time of read.
Set Transaction read only
A standard feature available on Oracle database which provides transaction-level Read Consistency.
Pipe Pipes allow sessions in the same instance to communicate with each other. Each pipe works asynchronously, allowing multiple readers and writers of the same pipe.
Planner Delete Worker
The Planner Delete Worker performs database delete operations, it removes old planning information from the tables.
Memory Based Planner A planning process that performs netting calculations.
Thanks & Regards,
S.Grace Paul Regan
Monday, July 13, 2009
With today's rapidly changing business conditions, you need a planning tool that surpasses the traditional latency of disconnected planning processes or Excel planning spreadsheets. You can leverage Advanced Supply Chain Planning to be more responsive. You can perform simultaneous material and capacity planning across multiple distribution and manufacturing facilities and time horizons in a single planning run, while at the same time accounting for the latest consensus forecast, sales orders, production status, purchase orders, and inventory policy recommendations. You can choose to start immediately with more advanced constrained and optimized planning, leveraging the out-of-the-box optimization, or you can decide to get to that point gradually by starting with unconstrained planning.