Running Collections

Oracle ASCP has a component architecture that allows a single instance of Oracle ASCP to plan one or more transaction instances. The transaction instances can be a mixture of releases. The Oracle ASCP planning instance (referred to as the planning server) can sit on the same instance as one of the transaction instances, or be a separate instance altogether. In either case (even if the planning server shares an instance with the transaction instance to be planned), data to be planned is brought from the transaction instance(s) to the planning server via a process called Collection.

Oracle ASCP uses a data store based on the planning data model that is exposed through interface tables. The data is pulled from the designated data sources into its data store; Oracle ASCP Collections are responsible for synchronization as changes are made to the data sources.

The configurability of the collections is enabled through a pull program based on AOL concurrent program architecture. Thus, for example, different business objects can be collected at different frequencies. Supplies and demands, which change frequently, can be collected frequently. Routings and resources, which change relatively less often, can be collected less frequently.

Standard collections process: Using the standard collections process, you can manually run three types of collection methods including a complete refresh, a net change refresh, or a targeted refresh on specific business entities.

Continuous collections process: The continuous collections process is an automated process of data collection that efficiently synchronizes the data on the planning server by looking up the sources. If you opt for continuous collections, the system
automatically determine the type of collection that needs to be run on entities selected by you. The continuous collections process collects data from the sources with the least user intervention. The Continuous Collections concurrent program
performs continuous collections.

Definitions:
You should be familiar with the following terms before examining the data collections architecture:
Applications Data Store (ADS): The set of source data tables in each transaction instance that contain data relevant to planning.
Data Pull: The data collection process consists of the Data Pull and the Operational Data Store (ODS) Load. The collection process lets you collect across several Oracle  aplication versions. It supports several configurations. The two types of collections process are standard and continuous.
Operational Data Store (ODS): The planning data tables in the planning server that act as destination for the collected data from each of the data sources (both ADS and Legacy).
Planning Data Store (PDS): The outputs of the planning process. The PDS resides in the same data tables as the ODS. However, PDS data are marked with plan IDs that show which plans they correspond to, while ODS data are marked with plan ID = -1.
Collection Workbench: The Collection Workbench is a user interface for viewing data collected over to the planning server from the transaction instances. The functionality here is similar to Planner Workbench functionality. For more information on the Planner Workbench

Standard Data Collection: The standard data collection process enables you to select the mode of data collection from a complete refresh, an incremental refresh, or a targeted refresh.
Standard data collection consists of the following processes:

• 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.
• 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.