Sie sind auf Seite 1von 7

Oracle ASCP for beginners

Hi,
This is my first post on Oracle ASCP concepts. I am planning to use this space for posting more details on
Oracle ASCP concepts in future. I plan to start with the basic concepts of planning in Oracle and then we
would slowly progress to more complex things. Before I start this journey I would also like to gauge if
there is really a need for such a blog or are we already flooded with enough knowledge on the subject
matter. If the answer to that question is yes then probably I would not be adding any value.
Unfortunately I dont have any mean to gauge that so let me get started and I would assess based on
the kind of feedback I get from the community.
Oracle ASCP, better known as Oracle Advanced Supply Chain Planning corresponds to MRP2 in the
evolution of planning systems. MRP1 took care of unconstrained planning and mostly addressed the
BOM explosion and lead time offset requirements for simplistic planning. But since MRP1 did not take
care of in-house and out-sourced, vendors capacities the need for an advanced planning system which
can take care of such constraints was realized and Oracle enhanced its simple MRP solution to come out
with a more advanced constrained based planning solution. This let to the advent of Oracle ASCP
module.
Oracle ASCP comes as a separate module in Oracle Applications suite with separate licensing
requirements.
Let me start by dwelling onto some of the initial topics on ASCP configuration from system perspective.
Typically there are two kinds of architectures supported to incorporate Oracle ASCP module with your
ERP system.
1. Centralized Architecture
2. Distributed Architecture
Centralized architecture essentially means that your transactional modules and planning module be
sitting on the same application instance and would be pointing to the same database for data storage.
This architecture is preferred where the transactional data volume is not very high. Since planning
engine can put significant amount of load on the hardware it is very important to assess the overall data
volume load at the inception of ASCP implementation itself. From IT costing perspective centralized
architecture is good because there are obvious cost savings that can be seen as this requires only one
application tier and one database tier. But then as mentioned earlier this decision should be strictly
governed by the current data volume and the kind of growth you are expecting for your business in
future.
Distributed architecture, as the name suggests points to having planning modules installed on a
different instance. Again the decision to go for this architecture has to be governed by the transactional
data volume. This architecture has the inherent benefit that you can always keep your planning data
separate and continue your planning functions even when your transactional system is down to due
maintenance or patching activities etc.
To start with I would keep this post till here only and would dig deeper in the future posts. To highlight
what could be coming your way in future I would put down some of the topics here: Technical
architecture of ASCP, Engine logic for optimization, mapping constraints in EBS, plan output analysis etc

Oracle ASCP for beginners Part2
Last time i posted about the distributed and centralized architecture followed usually for ASCP
implementations. This post would focus more on the technical architecture of ASCP. Let me first start
with the data flow for ASCP cycle. Generally speaking an ASCP driven planning cycle would involve the
following steps:
1. Master data setup, which involves item, BOM, Routing and sourcing setups as applicable
2. Transaction Data. Usually if you already have an EBS instance with transactions running on it, ASCP
would consider those transactions depending up the planning attributes setups for the associated items
3. Running Planning Data Collection In this post we are going to focus on data flow of planning data
collection process
4. Setting up the plan options To be discussed in future posts
5. Running the plan- To be discussed in future posts
Data flows from transaction instance to planning instance through the planning data collection process.
(Assumption here is that both ERP instance and planning instance are on Oracle e-business suite
application. Other form of collection would be dealt separately in future posts)
Planning data collection process consists of two stages. First, Planning Data Pull and second, Planning
ODS Collection.
Planning Data Pull stage is triggered off through the concurrent request called Planning Data Pull on
the planning instance. This stage triggers off a process on OLTP instance called Refresh Collection
snapshots. Lets discuss in some more details about Refresh Collection snapshots process here before
moving further.
Before we understand the Refresh Collection snapshot process, lets spend a couple of minutes
understanding the underlying data flow, which makes in necessary to run the refresh collection
snapshot process.
When the transactions are performed on the OLTP instance, the corresponding data sits in multiple
Oracle base tables. These transactional data tables are segregated based on various functional areas e.g.
purchasing, manufacturing, sales etc. For any planning process, we need to work on a frozen set of data,
which remains static during the planning run cycle. Oracle has designed a set of snapshots to ensure that
static data at a given time instance sits in these static tables and is further used by the planning process.
Just like the transactional data, these snapshots are also segregated based on the functional areas i.e.
there are separate snapshots for master data, PO data, WIP data etc. These snapshots can be viewed on
the EBS database by using the following SQL:
select object_name from dba_objects where object_name like M%_SN';
Above query would result the various snapshots used by the planning process.
Refresh snapshot creation process, instructs the data base to refresh these snapshots on a given time
instance when the request is triggered off. Refresh on these snapshots means that data stored in these
static tables would be updated with the latest data lying in the base Oracle tables.
Refresh Collection snapshot process launches multiple workers on the EBS side to refresh the
individual snapshots relating to various entities. There are two ways in which these snapshots can be
refreshed, Complete refresh mode and Fast refresh mode.
Since this topic is slightly detailed and should be understood well to gain the overall understanding,
considering the space and time constraint, i would end this post at this stage and we would continue
dealing with these refresh modes in next posts.

Oracle ASCP for beginners Part3
In my last post, we talked about Fast refresh and Complete refresh for collection snapshots. Let me try
to dig deeper into this concept.
Complete refresh process ensures that complete data in the materialized view (snapshot) is recreated
after dropping the old data, whereas Fast refresh process ensures that only incremental data is added to
the snapshot table. It is recommended that before you run the very first collection process on your
planning instance, you run complete refresh process for all the snapshots on the ERP side once because
for the first time the process would try to get bulk of data into snapshot tables. Once the planning
collection process is established, future runs could be for only incremental (fast) refresh mode.
Planning data collection process launches the refresh collection snapshot process on the ERP side in the
Fast mode thereby ensuring a faster performance during the data collection step.
Once the refresh collection snapshot concurrent workers are successfully completed normally, planning
data collection process moves to the next stage, which is pulling the data from snapshot tables into
planning staging tables. Planning staging tables can be seen from the oracle data base using the below
simple query:
select * from all_tables where table_name like M%_ST'; Staging tables will have _ST at the end of
their names
Once the data is pulled into staging tables successfully, first stage of planning collection, Planning Data
Pull, is completed. ASCP follows the architecture of two step collection to provide the flexibility to pull
the data from various sources and also if required some data validation can be carried out at the staging
layer. When you want to pull the data from legacy system, staging table area is used for data validation
and also for any kind of manipulation if required to make it compatible with ASCP data model.
After Planning Data Pull stage the collection process initiates the next stage called Planning ODS
Load. This stage ensures that data from staging area is pulled into base ASCP tables for the planning
process to consume it.
Successful completion of Planning Data Pull parent request and subsequent child workers requests
ensure that all the relevant data from your transactional system is now available into your planning
instance to start the planning process.
We will dwell upon some more details of the planning collection process in my next post before we can
get on to the details of planning process.
Oracle ASCP for beginners Part4
Last time i touched upon Planning ODS Load process which is the second stage of planning data
collection process. I will try to go a little deeper in this post on the planning ODS load process and a little
bit about staging tables structure.
As i mentioned in my earlier post that after the first stage i.e. Planning Data Pull data comes into
staging tables, which can be queried using table_name like MSC%_ST string. After first stage data
resides in these sets of table. Oracle ASCP architecture has tried to replicate all the planning tables in
the staging area as well. So general rule of thumb would be if you know the base table for Demands on
the planning side i.e. msc_demands, staging table for the same data entity would be called as
msc_st_demands. This rule of thumb is applicable to almost all the tables.
In case of Legacy data collection, the data is pulled into staging area using flat file load and then a
validation process is run on the staging data to make sure that the data pulled from the legacy system is
compatible with Oracle ASCPs built it rules. In case some data entities fail the validation stage, error
message is stored back into the staging tables for the corresponding data entities, which can be fixed
and sent back for the processing.
When you are running the planning data collection on your instance for the first time, Planning ODS load
process also takes care of generating unique IDs for various entities like Item, BOMs, routings, trading
partners, trading partner sites etc. These ids are then form the basis of data modeling on ASCP side. IDs
generated on planning side are not the same as what you see for the same entities on the transaction
system side, that is why it is important to understand this piece of logic in the planning data collection
process.
Once IDs are generated and the data in the staging table is validated, ODS load process flushes the data
into base table. These unique IDs are generated only at the first time and then on the planning data
collection process tries to use the same IDs for subsequent runs. During the last stage of ODS load
process, first the data from base tables on the planning side is purged and then the new set of data is
inserted.
Once the base tables on the planning side are successfully populated, the last request of the planning
data collection, which is called as Purge planning stage tables is launched and this ensures that the data
is deleted from the staging tables. This ensures that staging area is now once again ready for the
subsequent planning data collection runs. If the planning staging tables are not successfully purged, you
might run into subsequent planning data collection failures.
Successful completion of purge staging tables process ends the planning data collection process. In case
of collaborative planning setups, there could be some subsequent processes which are also launched by
planning data collection process to prepare the data for collaborative planning process.
In my subsequent posts we will start going through the details of planning process.