ASCP Data Collection Technical Workshop GOOD | Oracle Database ...

Data Collection Technical Workshop Sanjeev Kale Oracle Corporation

Introduction This paper focuses on understanding Data collection architecture. Data Collection is a process that pulls data from designated data sources into its planning data store. The Data collection process consists of the ‘ pull  pull  process’   and ‘Operational Data Store (ODS) load process’ . Note: This Note: This document is intended for use as a reference document. Certain sections of the text are intentionally repeated throughout the document, so that each section can be read and understood independently of one another. This document is designed to supplement Oracle Advanced Supply Chain Definitions Planning and Oracle Global ATP Server Oracle Applications Data Store (ADS) User’s Guide and other APS training class Represents all the source data tables used to notes. build and maintain the planning data store within Oracle ASCP. It represents a single source data instance. E.g. transaction tr ansaction system Overview of Running (Source Instance)

Collections

Data Collection programs move data from the Operational Data Store (ODS) Part of Oracle

Pull program Collects the data from the ADS, and stores the data into the staging tables. This pull program is a registered AOL concurrent program that could be scheduled and launched by a system administrator. If you are using a legacy program, you must write your own pull program. The pull program performs the following f ollowing major processes. Refresh snashots.  Launch the pull Workers to perform  pulls from the appropriate source tables and insert the data in the Staging tables. ODS Load  A PL/SQL program which performs the data transform and moves the data from the staging tables to the ODS. This collection program is a registered AOL concurrent program that could be scheduled and launched by the system administrator. The Launch_Monitor procedure performs the following major processes: 

Key Transformation - Generate new local ID for global attributes such as items, items, category set, set , vendor, vendor

workbench is used to verify that the intended data has been collected – If necessary, troubleshoot errors in data collection and rerun the data collection program.

Data Collection Setup Steps The Data Collection can be implemented in two configurations – Centralized configuration and Decentralized or configuration. Distributed configuration. Centralized configuration is where the transaction (Source) instance and destination (APS) instance is on the same instance. Decentralized configuration is where the transaction (Source) instance and Destination (APS) instance are two diff erent instances instance s. These two instances could be on different machines. Depending on the type of configuration that is selected, selected, the setup steps will change. E.g. For Centralized configuration there is no need to set up database links, whereas in Decentralized configuration, configuration ,  the database links will have to be set up before proceeding with any other setup steps.

source instance (known as the Planning Database Link). Both the links are bidirectional. The Planning Database link is used for Data collection from transaction source  to the planning instance. When an action, action ,  such as releasing a  planned order or requisition, requisition ,  occurs in the APS planning system, the data is “published” to the transaction instance. The first step in this process is to send a signal via the Planning database link to the transaction instance. This initiates a remote procedure that pulls the planned order or requisition from the planning instance to the transaction instance. The Application Database link is used for Completing the “Publishing” process. The remote procedure that pulls the planned order or requisition record from the planning instance to the transaction instance does so by using the Application Database link. • •

Centralized vs. Distribution Configuration •

This refers to the deployment of planning and ERP modules.

•

plans and link them up by feeding the supply schedule of one on e org as demand schedule of another.

Example of a Database link

Following database link is created in Source instance: In source (Application Database Link) ============================= create public database link APS connect to apps identified by apps using using 'APS 'APS.wo .worl rld'; d';

Following database Planning instance:

link

is

created

in

In APS (Planning Database Link) ========================= create public database link vis1153 connect to apps identified by apps using using 'vis115 'vis1153.wo 3.world' rld'; ;

Test the APS link as follows: In APS SQL*Plus: ==================== select sysdate from dual@vis1153;

Test the source link as follows:

 Advanced  Advanced Supply Chain Planner Planner Setup Instances The Database Administrator uses this form to setup instance names and to specify the release version of the source database,  Application Database link and Planning Database link associated with the instance names. Complete the following Field and Flag in the  Application  Application Instance Window. Window. Set up Organizations by clicking on the Organizations Button. The Organizations window lists the organization within the instance. To enable data collection for an organization within an instance, select the enabled check box. The database links can be confirmed by running the following SQL scripts after the instances are defined. In vis1153 SQL*Plus ================ Select db_link from from dba_d dba_db_ b_lin links ks where db_link = 'APS'; DB_LINK

DB_LINK ------vis1153 select m2a_dblink,a2m_dblink from from msc_apps msc_apps_ins _instanc tances; es;

MSC_APPS_INSTANCES table will list all the source instances from which destination (APS) instance can pull data from.

FIELD/FLAG Instance Code Instance Type

Version  Application Database Link Planning Database Link Enable Flag GMT Difference

DESCRIPTION Choose from Multiple instances Discrete, Process, Discrete and Process or Other. If the source is discrete, only the discrete entites are collected. IF Process, then only OPM related entities are collected Unique version for the specified instance  A link to connect to the  Application database to Oracle  ASCP  A link to connect to the Oracle Oracle  ASCP to the Application Application database Select this option to enable the collection Process The difference between instance time zone and GMT

Example 1: Complete Refresh = Yes (Complete Refresh Mode), Pull Items = Yes, Pull BOM/Routings = No – After the Data collection, the ODS will contain items but no information about bills and routings.

When Complete Refresh is set to No (Incremental Refresh - Net Change mode), then the data collection is performed in incremental refresh mode Net Change. The data existing in the ODS is not purged. The data that have flags set to Yes will be refreshed.

2) BOM/Routing: Any change in BOM/Routing, except for substitute components. In the case of using alternate/simultaneous resources, the change of the resource step number is not supported. 3) Supply/Demand: Any change chang e in supply/demand, includes onhand quantities and hard reservations. 4) Resource: a) The department resource capacity changes defined in the simulation set. b) WIP line resource changes c) WIP job's resource requirement changes. d) Supplier's capacity changes In the Data pull parameters form the number of workers to be employed can be specified.

ODS Load Paramters – Following parameters

are specified.

sources. Setting the Recalculate Recalculate Sourcing History flag to Yes will cause the sourcing history to be recalculated. recalculated.

The Data Collection Process To understand the Data Collection process first we need to understand the architecture of the data in the source instance. For that we need to understand the following.

Snapshot -  A snapshot snapshot is a replica of a target master table at a single point-in-time. Whereas multimaster replication tables are continuously being updated by other master sites, Snapshots are updated by one or more master tables via individual batch updates, known as a refresh, from a single master site . The following Snapshots are defined in the source instance. For each snapshot there is a synonym defined. Using these synonym and other production tables in the source instance there are various views created. SNAPSHOT NAME MTL_SUPPLY_SN MTL_U_SUPPLY_SN MTL_U_DEMAND_SN MTL_SYS_ITEMS_SN MTL_OH_QTYS_SN

SYNONYM NAME MRP_SN_SUPPLY MRP_SN_U_SUPPLY MRP_SN_U_DEMAND MRP_SN_SYS_ITEMS MRP_SN_OH_QTYS

Refresh Snapshot process completes successfully. This can be illustrated with an example. example .  In the example we will see the flow of data for a given Bill of Material. The following BilI is defined in the source instance. SK-DCTEST01 SK-DCTEST02 - Component SK-DCTEST03 - Component Once this bill is defined the following tables are populated. SELECT SELECT ASSEMB ASSEMBLY_ LY_ITE ITEM_I M_ID D ITEM_I ITEM_ID, D, SEGMENT1, BOM.ORGANIZATION_ID ORG_ID, BILL_S BILL_SEQU EQUENC ENCE_I E_ID D BILL_S BILL_SEQ_ EQ_ID ID FROM BOM_BILL_O BOM_BILL_OF_MAT F_MATERIAL ERIALS S BOM, MTL_ MTL_S SYSTE YSTEM M_ITE _ITEMS MS MTL MTL WHER WHERE E ASSE ASSEMB MBLY LY_I _ITE TEM_ M_ID ID = 8307 8307 AND AND BOM. BOM.OR ORGA GANI NIZA ZATI TION ON_I _ID D = MTL.ORGANIZATION_ID AND ASSEMBLY_ITEM_ID = INVENTORY_ITEM_ID; ITEM_I ITEM_ID D SEGMEN SEGMENT1 T1 ORG_ID ORG_ID BILL_S BILL_SEQ_ EQ_ID ID ------- ----------- ------ ----------8307 SK-DCTEST01 207 18328 SELECT COMPONENT_ITEM_ID ITEM_ID, SEGMENT1, COMPONENT_QUANTITY COMPONENT_QTY FROM BOM_INVENT BOM_INVENTORY_C ORY_COMPON OMPONENTS ENTS COMPS, COMPS, MTL_SYSTEM_ITEMS MT L WHER WHERE E BILL BILL_S _SEQ EQUE UENC NCE_ E_ID ID = 1832 18328 8

SELECT COUNT(*) FROM FROM MRP_ MRP_SN SN_B _BOM OMS S WHERE ASSEMBLY_I ASSEMBLY_ITEM_I TEM_ID D = 8307; COUNT(*) ---------0 SELECT COUNT(*) FROM FROM MRP_SN MRP_SN_IN _INV_C V_COMP OMPS S WHERE BILL_SEQUE BILL_SEQUENCE_I NCE_ID D = 18328; 18328; COUNT(*) ---------0

ITEM_I ITEM_ID D ------8317 8309

SEGMEN SEGMENT1 T1 USAGE_ USAGE_QTY QTY ----------- --------SK-DCTEST03 2 SK-DCTEST02 2

If you look at the LOAD_BOM procedure for data pull, pull , it pulls the Bill of Material data from the above two views and populates the following two staging tables. MSC_ST_BOMS and MSC_ST_BOM_COMPONENTS

 Additionally  Additionally,, there are some views complete , and before the created on the snapshot synonyms which are  After the data pull is complete, used in the data collections process to load purge staging process is started , the following the data from the source instance into the SQL scripts can be run. ‘MSC staging’ tables. In this example ,  there SELECT CT ASSE ASSEMB MBLY LY_I _ITE TEM_ M_ID ID ITEM ITEM_I _ID, D, are two views that are used to load the Bill of SELE SEGMENT1, Material data into the staging tables. They are BOM.ORGANI BOM.ORGANIZATIO ZATION_ID N_ID ORG_ID, ORG_ID, MRP_AP_BOMS_V and MRP_AP_BOM_COMPONENTS_V  After the Refresh Snapshot Snapshot Process is successfully run, run, r un un the following SQL scripts. SELE SELECT CT ASSE ASSEMB MBLY LY_I _ITE TEM_ M_ID ID SEGMENT1, BOM.ORGANI BOM.ORGANIZATIO ZATION_ID N_ID BILL_SEQUENCE_ID

BILL_SEQUENCE_ID BILL_SEQ_ID FROM MSC_ST_BOMS BOM, MTL_SYSTEM_ITEMS MTL WHER WHERE E ASSE ASSEMB MBLY LY_I _ITE TEM_ M_ID ID = 8307 8307 AND AND BOM. BOM.OR ORGA GANI NIZA ZATI TION ON_I _ID D = MTL.ORGANIZATION_ID AND ASSEMBLY_ITEM_ID = INVENTORY_ITEM_ID;

ITEM ITEM_I _ID, D, ORG_ID, ORG_ID,

ITEM_I ITEM_ID D SEGMEN SEGMENT1 T1 ORG_ID ORG_ID BILL_S BILL_SEQ_ EQ_ID ID ------- ----------- ------ ----------8307 SK-DCTEST01 207 36656

MSC_BOMS MSC_BOM_COMPONENTS Before the data is populated in the above tables, there is a process of Key transformation that takes place where the Source Inventory Item Id are Mapped to the inventory Item Id’ in the Planning instance. For Inventory item Id, Id ,  the mapping is stored in the following table: table : MSC_ITEM_ID_LID SELECT SR_INVENTORY_ITEM_ID SR_ITEM_ID, INVENTORY_ITEM_ID ITEM_ID FROM FROM MSC_IT MSC_ITEM_ EM_ID_ ID_LID LID WHERE sr_invento sr_inventory_it ry_item_id em_id IN (8307,8309,8317); SR_ITEM_ID ITEM_ID ---------- ------8307 2333 8309 2334 8317 2335 SELECT SELECT INVENT INVENTORY ORY_IT _ITEM_ EM_ID ID ITEM_I ITEM_ID, D, ITEM_NAME, SR_INVENTORY_ITEM_ID SR_ITEM_ID, ORG ORGANIZ ANIZA ATION TION_I _ID D ORG_I RG_ID D FROM FROM MSC_SY MSC_SYSTE STEM_I M_ITEM TEMS S WHERE ITEM_NAME ITEM_NAME LIKE 'SK-DC%'; 'SK-DC%'; ITEM_ID ITEM_ID ITEM_NAME ITEM_NAME SR_ITEM_ID SR_ITEM_ID ORG_ID ORG_ID ------- ----------- ---------- ------

ITEM_NAME, COMPS.ORGA COMPS.ORGANIZAT NIZATION_I ION_ID D ORG_ID, ORG_ID, USAGE_QUANTITY USAGE_QTY FROM FROM MSC_BO MSC_BOM_C M_COMP OMPONE ONENTS NTS COMPS, COMPS, MSC_SYSTEM_ITEMS MTL WHERE BILL_SEQUE BILL_SEQUENCE_I NCE_ID D = 36656 AND AND COMP COMPS. S.IN INVE VENT NTOR ORY_ Y_IT ITEM EM_I _ID D = MTL.INVENTORY_ITEM_ID AND AND COMP COMPS. S.OR ORGA GANI NIZA ZATI TION ON_I _ID D = MTL.ORGANIZATION_ID; ITEM_ID ITEM_ID ------2334 2335

ITEM_NAME ITEM_NAME ORG_ID ORG_ID USAGE_QTY USAGE_QTY ----------- ------ --------SK-DCTEST02 207 2 SK-DCTEST03 207 2

User has the flexibility in determining when a snapshot of information from the source system should be taken, and in deciding what information to capture with each job. The data collection program can be set to run upon submission of a job request, and at specified time intervals, and to collect different type s of information with different frequenc ies. ies. For example, example ,  dynamic data such as sales orders can be collected frequently, while static data , such as department resources, resources ,  can be collected at longer intervals. The objective is to set up data collection as needed to create a current replica of information for the APS system to use in its

The concurrent manager allows only one stage in a request set to run at a time. When one stage is complete, complete ,  the following stage is submitted. A stage is not considered to be complete until all of the requests in the stage are complete. One advantage of using stages is the ability to run several requests in parallel and then move sequentially to the next stage. In Data collection there are two stages ,  Data Pull Stage and ODS Load Stage. In the Data Pull Stage – Planning Data Pull, Refresh Snapshot and Planning Data Pull Worker requests requests  are run. In the ODS Load Stage – Planning ODS Load, Planning ODS Load Worker, and Planning Data Collection Purge Staging tables request s are run. Six different processes comprise the structure of Data Collection process. process .  Each of these processes are launched during the Data collection run.

CONCURRENT PROGRAM

SHORT NAME

Planning Data Pull Refresh Snapshot Planning Data Pull Worker Planning ODS Load Planning ODS Load

MSCPDP MSRFWOR MSCPDPW MSCPDC MSCPDCW

•

•

Complete refresh – Ignores the most recent refresh data and collects all data. Incremental refresh – Collects only the incremental changes since the most recent refresh.

Refresh Snapshot (MSRFWOR) Refresh Snapshot Process consistently refreshes refreshes one  one or more snapshots. The refresh snapshot uses Oracle's replication management API’s following packages : DBMS_SNAPSHOT.REFRESH. A Commaseparated list of snapshots is provided and the Type of refresh to perform for each snapshot listed; 'F' or 'f' indicates a fast refresh, 'C' or 'c' indicates a complete refresh.

The refresh snapshot process is started , and purge the staging tables process is also submitted while  while  the refresh snapshot process is running. For purging the staging tables, tables , the MSC_CL_COLLECTION.PURGE_STAGIN G_TABLES_SUB procedure is called. The purpose of calling this procedure is that there is a COMMIT after every task – If the

Please refer to the appendix for a complete list of tasks and procedures called. called.

Planning ODS Load (MSCPDC)

MRP:Cutoff Date Offset Months  Months  profile option is used for resource availability. Please refer to the appendix for a complete list of tasks and procedures called. called.

Planning Data load is launched by Planning ODS Load process. This is the process which launches and then controls the remaining Planning Data Collection – Purge Staging Tables (MSCPDCP) Data load processes. Key transformation takes place here before the source data is made is available to APS. Key transformation takes place only for Items, Categories, Suppliers, and Customers. Customers . 





Key Transformation – To track data entities back to the source instance,  APS transforms each each unique ID within  APS.  APS. This process is called as Key Transformation. Generate new local ID for global attributes such as items, items, category set, set , vendor, vendor site, site , customer  and  and customer site. site. Launch the ODS Load Workers to perform Create, Update, and Delete operations for each entity in ODS (MSCPDCW). Recalculate the sourcing history based on the latest sourcing information and the data from tr ansaction systems. systems.

The data in the staging tables is purged after the planning ODS load is successfully completed. The data collection process will attempt to purge the already extracted data and any data orphaned as a result of a termination of the Data Collection process. MRP:Purge Batch Size  Size  profile option is used to determine the number of records to be deleted at a time. The tables which are purged by the Purge Staging tables process are: • • • • • • •

MSC_ST_BOM_COMPONENTS MSC_ST_BOMS MSC_ST_DEMANDS MSC_ST_ROUTINGS MSC_ST_COMPONENT_SUBSTITUTES MSC_ST_ROUTING_OPERATIONS MSC_ST_OPERATION_RESOURCES

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • •

MSC_ST_SOURCING_RULES MSC_ST_SR_ASSIGNMENTS MSC_ST_SR_RECEIPT_ORG MSC_ST_SR_SOURCE_ORG MSC_ST_INTERORG_SHIP_METHODS MSC_ST_SUB_INVENTORIES MSC_ST_ITEM_SUPPLIERS MSC_ST_SUPPLIER_CAPACITIES MSC_ST_SUPPLIER_FLEX_FENCES MSC_ST_SUPPLIES MSC_ST_RESOURCE_REQUIREMENTS MSC_ST_TRADING_PARTNERS MSC_ST_TRADING_PARTNER_SITES MSC_ST_LOCATION_ASSOCIATIONS MSC_ST_UNIT_NUMBERS MSC_ST_PROJECTS MSC_ST_PROJECT_TASKS MSC_ST_PARAMETERS MSC_ST_UNITS_OF_MEASURE MSC_ST_UOM_CLASS_CONVERSIONS MSC_ST_UOM_CONVERSIONS MSC_ST_BIS_PFMC_MEASURES MSC_ST_BIS_TARGET_LEVELS MSC_ST_BIS_TARGETS MSC_ST_BIS_BUSINESS_PLANS MSC_ST_BIS_PERIODS MSC_ST_ATP_RULES MSC_ST_PLANNERS MSC_ST_DEMAND_CLASSES MSC_ST_PARTNER_CONTACTS

Package Body Procedures for the Data Collection process. process. PACKAGE NAME

MSCCLAAB.pls

DESCRIPTION

This package

MRPCLHAB.pls MRPCLHAS.pls

This package has some functions used while collections.

Important SQL scripts Following are the SQL scripts that are used to create to the database objects used in the Data Collection Process. The following SQL Scripts are for reference only; only ; They are provided here for debugging purpose s.

Snapshot Logs

Create Snapshot Tables

BOMMPS BOMMPSNL. NL.sql sql MTLMPS MTLMPSNL. NL.sql sql MRPMPS MRPMPSNL. NL.sql sql WIPMPS WIPMPSNL. NL.sql sql POMPSN POMPSNAL. AL.sql sql OEMPSN OEMPSNAL. AL.sql sql

BOMMPS BOMMPSNP. NP.sql sql MTLMPS MTLMPSNP. NP.sql sql MRPMPS MRPMPSNP. NP.sql sql WIPMPS WIPMPSNP. NP.sql sql POMPSN POMPSNAP. AP.sql sql OEMPSN OEMPSNAP. AP.sql sql

Create Synonyms

Create Views

MRPMPS MRPMPSNS. NS.sql sql

MRPMPC MRPMPCRV. RV.sql sql

Create Triggers

APPENDIX Planning Data Pull Worker (MSCPDPW ) task list. The procedures are defined in the package body MSC_CL_PULL_WORKER, MSCCLAAB.pls. TASK NAME TASK_ITEM1 TASK_ITEM2 TASK_ITEM3 TASK_PO_SUPPLY TASK_WIP_SUPPLY TASK_OH_SUPPLY TASK_MPS_SUPPLY TASK_MDS_DEMAND TASK_WIP_DEMAND TASK_SALES_ ORDER TASK_BIS

TASK_BOM TASK_ROUTING TASK_CALENDAR_ DATE TASK_SCHEDULE TASK_RESOURCE TASK_TRADING_ PARTNER TASK_SUB_INVENTORY

PROCEDURE NAME LOAD_ITEM LOAD_ITEM LOAD_ITEM LOAD_PO_SUPPLY LOAD_WIP_SUPPLY LOAD_OH_SUPPLY LOAD_MPS_SUPPLY LOAD_MDS_DEMAND LOAD_WIP_DEMAND LOAD_SUPPLIER_ CAPACITY LOAD_BIS110 for 11.0 source LOAD_BIS107 for 10.7 source LOAD_BIS115 for 11.5 source. LOAD_BOM LOAD_ROUTING LOAD_ CALENDAR_DATE LOAD_SCHEDULE LOAD_RESOURCE LOAD_TRADING_ PARTNER LOAD_SUB_ INVENTORY

Planning ODS Load Worker ( MSCPDCW) task list. The procedures are defined in the package body MSC_CL_COLLECTION, MSCCLBAB.pls TASK NAME TASK_SUPPLY TASK_BOR TASK_CALENDAR_ DATE TASK_ITEM TASK_RESOURCE TASK_SALES_ORDER TASK_ SUBINVENTORY TASK_HARD_ RESERVATION TASK_SOURCING TASK_SUPPLIER_ CAPACITY TASK_CATEGORY TASK_BOM TASK_UNIT_ NUMBER TASK_SAFETY_ STOCK TASK_PROJECT TASK_PARAMETER TASK_BIS_ TARGET_LEVELS TASK_BIS_TARGETS

PROCEDURE NAME LOAD_SUPPLY LOAD_BOR LOAD_ CALENDAR_ DATE LOAD_ITEM LOAD_RESOURCE LOAD_SALES_ORDER LOAD_SUB_ INVENTORY LOAD_HARD_ RESERVATION LOAD_SOURCING LOAD_SUPPLIER_ CAPACITY LOAD_CATEGORY LOAD_BOM LOAD_UNIT_NUMBER LOAD_SAFETY_STOCK LOAD_PROJECT LOAD_ PARAMETER LOAD_BIS_ TARGET_LEVELS LOAD_BIS_

PLANNING DATA COLLECTION

DATA PULL (Request Set Stage)

ODS LOAD (Request Set Stage)

Planning Data Pull

Short Name Execute Method Execute File Name Package Body

: : : :

Planning ODS Load

Short Name Execute Method Execute File Name Package Body

MSCPDP PL/SQL Stored Procedure msc_cl_pull.launch_monitor 

MSCCLFAB.pls

Refresh Snapshot

Short Name Execute Method Execute File Name Package Body

: : : :

mrp_cl_refresh_snapshot.refresh_snapshot

Short Name Execute Method Execute File Name Package Body

: : : :

MSCPDPW PL/SQL Stored Procedure msc_cl_pull.launch_worker  MSCCLFAB.pls

: : : :

MSCPDCW PL/SQL Stored Procedure msc_cl_collection.launch_worker 

MSCCLBAB.pls

Planning Data Collection  – Pur ge Staging Stagi ng tables tabl es –  – Purge

Planning Data Pull Worker  Worker

Short Name Execute Method Execute File Name Package Body

MSCPDC PL/SQL Stored Procedure msc_cl_collection.launch_monitor  MSCCLBAB.pls

Planning ODS Load Worker  Worker

MSRFWOR PL/SQL Stored Procedure MRPCLEAB.pls

: : : :

Short Name Execute Method Execute File Name Package Body APS 13/ 13/14 /14

: MSCPDCP : PL/SQL Stored Procedure : msc_cl_collection.purge msc_cl_collection.purge_staging_table _staging_tables s : MSCCLBAB.pls

DATA COLLECTION SOURCE (TRANSACTION)

CORE APPS • • • • •

DESTINATION (PLANNING – APS) PLANNING DATABASE LINK 

ITEMS BOM RTG MDS SCP

PLANNING DATA

DEFINE RUN / COLLECTIONS

DATA COLLECTION

SOURCE INSTANCES 10.7 11.0 11i

PUBLISH

• •

APPLICATION DATABASE LINK 

•

SOURCE (TRANSACTION)

DESTINATION PLANNING - APS STAGING TABLES

STEP 1 APPLICATION DATA STORE

(ADS)

•

CUSTOM DATA MANIPULATION (if required)

STEP 2

PLANNING DATA PULL •

DEFINE RUN / PLANS

STEP 2

Refresh ADS Snapshot  Net Change Handling

ODS LOAD

ODS LOAD

OPERATION DATA STORE

•

(ODS) P

RUN PLAN

U

B

L APS 14/ 14/14 /14

I

S

H

PLAN FEEDBACK

PLANNING DATA STORE

(PDS) = ODS Snapshot + Plan Output