Initial Setup

This chapter covers the following topics:

Implementation Steps

The following steps are recommended when you are planning to implement Value Chain Planning:

If you are planning to import legacy data, see Loading Data from Flat Files for more information.

Implementation Considerations

Major features of the collections process include:

Multiple Source Instances

You can register any number of source data instances and non-Oracle data sources on each Oracle VCP installation.

Pull Architecture

You can collect new source data instances into Oracle VCP with minimal impact. The data is pulled from the source data instance by Oracle VCP. Each instance can have its own refresh interval. A failure in one instance will not affect data collections from other instances.

Collect Net Changes from Oracle Applications to the Oracle VCP Planning Server

You can collect net changes in Oracle EBS Source instances and the Oracle VCP Planning server using the Net Change mode. Thus, only the changed source data is collected each time, reducing the computational burden on the collection process.

Note: Only certain business entities can be collected in Net Change mode.

See Data Changes that can be Collected in Net Change Mode

Multi-Process Collection Architecture

You can enhance the performance of the pull program by distributing the tasks to multiple collection workers.

Data Consolidation

The collection program can consolidate the entities shown in the following table across instances based on the corresponding user-defined keys.

Table Name Entity User Key
MTL_SYSTEM_ITEMS_B Items Concatenated Item Segments
MTL_CATEGORIES Items Concatenated Category Name
MTL_CATEGORY_SETS Items Category Set Name
PO_VENDORS_VIEW Suppliers/Customers/Orgs Vendor Name
PO_VENDOR_SITES_ALL Suppliers/Customers/Orgs Vendor Site Code
RA_CUSTOMERS Suppliers/Customers/Orgs Customer Name
HZ_CUST_ACCT_SITES_ALL Suppliers/Customers/Orgs Customer Name, Site Use Code, Location Operating Unit
MTL_UNITS_OF_MEASURE Units Of Measure UOM Code

For all the entities not described in the table, the instance ID together with the entity key in each instance uniquely identifies each row.

Projects/Tasks and Seiban Numbers

You can consider Projects, Tasks, and Seiban Numbers to be unique within the context of an Oracle Applications instance; no consolidation is required.

Support for Several Configurations

You can implement centralized or decentralized configurations based on the scale of the enterprise and specific business needs. Source data applications and Oracle VCP can reside on one server or on separate servers.

Tablespace Considerations

When implementing Value Chain Planning, it is important to understand its space requirements, and how space is consumed in the VCP tablespaces. Because data for MSC tables grows very quickly, you must plan your disk space needs and configure the tables and tablespaces. The Rapid Install of Oracle Application in 11.5.10 and above uses the Oracle Applications Tablespace Model (OATM), a consolidated model of just a couple of dozen tablespaces. For more information about OATM, see Oracle Applications Concepts 11.5.10.2.

Evaluating the System:

For a full implementation of the VCP Applications, the Sizer for APS is available internally at http://www-apps.us.oracle.com/aps/. Click the APS Sizer button. Use this tool to determine some of the initial sizing for the database. Alternatively, you can download the sizer spreadsheet template.

Note: The Sizer for APS is separate from the standard sizing information available for an EBS applications install.

If Data Collections for Order Management ATP is the only part of the VCP implementation being used, the sizing tool will not provide a correct sizing because it is not set up for this type of implementation. In this case, the DBA can use SQL #28 -- Get Table Sizes for Tables Exceeding 10 MB to evaluate tables in the EBS source schemas for INV, BOM, WIP, and ONT for size and then come to a determination on the sizing for the MSC schemas based on the experience of running Data Collections. Generally, a very rough estimate of the sizing that could be used is:

(total bytes of MTL_SYSTEM_ITEMS + MTL_ITEM_CATEGORIES )* 3 + 50%

Although this should allow for enough space initially, it is still possible that certain system setups will outstrip this estimate and it is not guaranteed. For example, if your BOM or WIP is highly used and very large, then increase this estimate. Once Data Collections has been run, then the system can be evaluated again for sizing and adjustments made as needed.

Note: After Data Collections are run for all organizations to be collected and before any ASCP plans are run, the space used is approximately 40% of the total space needed just for Data Collections to be run successfully. All the data being collected exists more than two times during Data Collections. This is because the MSC_ST% tables are populated during the Planning Data Pull process with all the data that will be in the base tables after the end of Data Collections. Then, during ODS Load, TEMP tables are created to process data in the MSC_ST% staging tables. Data loaded in the TEMP tables is moved into the MSC base tables using RDBMS Exchange Partition technology. Lastly, the MSC_ST% staging tables are purged at the end of the Data Collections cycle. More space is required for each plan that is run.

If you are loading large amounts of data during the implementation, review the Loading Large Amounts of Data for Implementation section in the Managing MLOGs chapter for additional configuration suggestions.

Appendix E contains a number of SQL commands that are useful for determining how the system has been set up and its space usage:

See Also:

Installing Patches

When installing and using VCP applications, you must begin by installing the entire EBS application on the EBS server. Next, you need to install ASCP and your other VCP applications on either the EBS server for centralized installations or the VCP server for decentralized installations. There is no standalone install package limited to VCP applications.

Install the latest release of EBS applications and during the implementation cycle, if a new release of EBS becomes available, plan to install that release as soon as possible. If not running any ASCP plans, then no plan partitions are required and can be dropped. See Drop Partition Request for more information.

Please refer to My Support Oracle Note #1361221.1 -- FAQ - Getting Started With 12.2 for Value Chain Planning (VCP) Applications for the latest patches for 12.2, the supported integrations to earlier releases, and any patches that need to be installed on a separate EBS source instance.

For a distributed installation, you may have to apply patches on the EBS source instance.

If Demantra integration is required, review My Oracle Support Note #470574.1 - List Of High Priority Patches For Oracle Demantra Including EBS, Siebel and E1 Integrationsfor the list of high priority patches for Oracle Demantra including EBS integration.

Creating Links

When a separate VCP destination instance is used from the EBS source instance, there must be a database link on the destination that allows programs running on the destination to launch programs (like Refresh Collection Snapshots) on the source or read data from the source (like Planning Data Pull). Similarly, there must be a database link on the source that allows programs running on the source to pull data from the destination to the source. An example of this happens when planned orders generated by the planning process are implemented by releasing them to the source instance. The data flow for such a release includes code that runs on the EBS source instance that pulls released planned order data from the destination to the source so that the requisition or job can be created on the source.

Setting Up TNSNAMES for the Source and Destination Instances

Add the source and destination TNSNAMES to IFILE in the tnsnames.ora file. This file is created for the purpose of maintaining information outside of the AutoConfig managed files.

In this example, our EBS source instance is called NIC and located on the server copernicus.us.oracle.com. The VCP destination instance is called KEPLER and located on server kepler.us.oracle.com. We will create two db-links:

  1. Sign in as an ORACLE user.

    [iracke@cioerbucyks ~]$ cd $TNS_ADMIN
[oracle@copernicus admin]$ 1s
listener.ora tnsnames.ora
[oracle@copernicus admin]$ more tnsnames.ora
################################################
#
# This file is automatically generated by AutoConfig. It will be read and
# overwritten. If you were instructed to edit this file, or if you are not
# able to use the settings created by AutoConfig, refer to Metalink Note
# 387859.1 for assistance.
#
################################################

nic=
             (DESCRIPTION=
  ....

    At the bottom of the file, we see the IFILE info: IFILE=/d04/oracle/nic/inst/apps/nic_copernicus/ora/10.2.0/network/admin/nic_copernicus_ifile.ora

  2. Open the IFILE nic_copernicus_ifile.ora and add connection information for the VCP destination instance.

    more /d04/oracle/nic/db/tech_st/10.2.0/network/admin/nic_copernicus/nic_copernicus_ifile.ora

kepler=(DESCRIPTION= (ADDRESS=(PROTOCOL=tcp)
        HOST=kepler.us.oracle.com)  PORT=1521))
         (CONNECT_DATA=(SERVICE_NAME=kepler) (INSTANCE_NAME=kepler)))

  3. Open the IFILE kepler_kepler_ifile.ora and add connection information for the EBS source instance.

    [oracle@kepler kepler_kepler]$ more kepler_kepler_ifile.ora

nic=  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp) (HOST=copernicus.us.oracle.com)(PORT=1520))
              (CONNECT_DATA=(SERVICE_NAME=nic)(INSTANCE_NAME=nic)))

Creating and Testing the DB_LINKS

  1. Sign in as the SYSTEM User (or sysdba) in SQL*Plus on the EBS source instance NIC and create, query and check the DB_LINK.

    A. Create the DB_LINK

SQL> create public database link NIC_TO_KEP
     connect to apps
     identified by apps
     using 'kepler';

B. Query the setup:

SQL> select * from dba_db_links;
select * from dba_db_links where db_link like 'NIC%KEP%'
     
OWNER        DB_LINK                           USERNAME         HOST          CREATED
PUBLIC       NIC_TO_KEP.US.ORACLE.COM          APPS             kepler        4/3/2009 10:40:29 AM

C. Check the DB_LINK:

SQL> select instance_name from v$instance@NIC_TO_KEP;

INSTANCE_NAME
  KEPLER

  2. Sign in as the SYSTEM User (or sysdba) in SQL*PLUS on the VCP destination instance KEPLER and create, query and check the DB_LINK.

    A. Create the DB_LINK

SQL> create public database link KEP_TO_NIC
     connect to apps
     identified by apps
     using 'nic';

B. Query the setup:

SQL> select * from dba_db_links where db_link like 'KEP%%NIC%'
     
OWNER        DB_LINK                           USERNAME         HOST          CREATED
PUBLIC       KEP_TO_NIC.US.ORACLE.COM          APPS             nic        4/3/2009 2:57:42 PM

C. Check the DB_LINK:

SQL> select instance_name from v$instance@KEP_TO_NIC;

INSTANCE_NAME
  NIC