Architecture

This chapter covers the following topics:

Overview

Oracle Value Chain Planning Suite has a component architecture that separates the transaction data and processing, for example, inventory receipts and order entry, in a source instance and the planning calculations done in a destination instance. This results in:

The source can be any ERP system, but out-of-the-box integration to the Oracle Value Chain Planning Suite destination instance (planning server) exists in some cases but not in all cases.

Both source and destination database instances must be on the same major release of the Oracle database; see Source and Destination Instance Setup.

Oracle Value Chain Planning's data collection architecture, shown in the figure below, depicts the data objects, procedures, and data flow between source data and Oracle planning applications. The major repositories are ADS, ODS, and PDS. Procedures enable data cleansing, data collecting, data communication, and net-change handling between data repositories.

the picture is described in the document text

Supported Configurations

Oracle VCP supports the following planning configurations for installation and deployment:

These configurations offer you enough flexibility to design a mode of planning that suits your business objectives. Both configurations are supported using a consistent architecture as outlined in the previous section. The sole distinction is that centralized planning does not use database links to pull data into the Oracle VCP server data store.

To make more detailed machine deployment decisions, review :

Centralized

This figure shows the centralized planning configuration.

the picture is described in the document text

In a centralized scenario, Oracle VCP and its source data reside in the same database. No database link is required in this case. Two components can communicate through the planning object APIs and the interface tables defined in Oracle Applications.

In this configuration, shown in the following figure, a simplified architecture is used, and the data transformation is not required.

When patching for a centralized installation, all patches are applied to the single instance. Ignore references in the patch readme for centralized and distributed installation and apply all patches to your single instance. Most patches mention to just apply the patch to your instance when centralized.

Decentralized

The following figure shows the decentralized planning configuration:

the picture is described in the document text

In this scenario, Oracle VCP works as a central Planning Server across one or more source data instances. The collection program is installed on the planning server and the data stripped by instance is moved into staging tables within Oracle VCP during the data collection process.

After the planning process, results can be pushed back to each instance. The planning process is generally done by a planner via the Planners Workbench.

Benefits of distributed installation:

Patching for a distributed installation requires careful attention to the patch readme to make sure the patches are applied to the correct instance and that prerequisite and post-requisite patches are applied to the correct instance. Patch readme should be clear on where the patch is to be applied. Usually, the patch refers to the EBS source instance and to the VCP destination instance where the patch is to be applied.

General VCP Products Machine Implementation Options

Consider from among these machine implementation options if you are implementing VCP products that use collected data other than Rapid Planning. For Rapid Planning, see Rapid Planning Machine Implementation Options.

Oracle Demand Planning also uses a third instance, an OLAP Analytic Workspace (AW) database, to hold data while multidimensional manipulation of demand data occurs.

One-Machine Implementation

For small implementations, source, destination, and Express can reside on the same machine and be in the same instance. The following figure illustrates this configuration.

Note: This example uses ASCP and DP. ASCP means Advanced Supply Chain Planning and DP means Demand Planning.

the picture is described in the document text

Two-Machine Implementation

For larger implementations where system throughput is more important, the various instances can be deployed on separate machines. A two-machine deployment configuration is appropriate when the size of the demand planning data is relatively small. The following figure illustrates this configuration.

the picture is described in the document text

Three-Machine Implementation

A three-machine deployment allows for the manipulation of high-dimensionality, large-scale demand planning data to occur on a machine separate from the planning calculations done on the planning server. The following figure illustrates this configuration.

the picture is described in the document text

Four-Machine Implementation

The Advanced Supply Chain Planning concurrent manager may also be deployed on a separate machine. This creates even greater system performance. The following figure illustrates the four-machine implementation.

the picture is described in the document text

In all deployment configurations, a collection process brings data from the EBS source tables to the VCP destination tables. A build process brings data form the VCP destination tables to the OLAP Analytic Workspace (AW) for Demand Planning. Finally, a publish process moves data from the AW to the VCP Destination tables to be used for planning and can also publish data back to the EBS source instance.

Global Order Promising and Inventory Optimization planning calculations are also performed on the planning server.

Rapid Planning Machine Implementation Options

Consider from among these machine implementation options if you are implementing Rapid Planning. For VCP products that use collected data other than Rapid Planning, see General VCP Products Machine Implementation Options.

Rapid Planning has these components:

Single Machine Architecture

All the components are on one machine. The Source ERP application and the Value Chain Planning planning server use the same database tier and application tier.

Use this option with these data volumes:

If you use this configuration with higher data volumes, you can overload your server.

Two Machine (Distributed) Architecture

The source ERP application is on one machine. The Value Chain Planning planning server and the WebLogic Server are on one machine.

This is how the machines communicate for collections and release when the source ERP application is:

Three Machine Architecture

The source ERP application is on one machine, the Value Chain Planning planning server is on one machine, and the WebLogic Server is on one machine.

This is how the machines communicate for collections and release:

Tier Sizing for Machine Architecture

See: