SAP BW-APO

System Landscape and Interface

Considerations
Global ASAP for BW Accelerator
BUSINESS INFORMATION WAREHOUSE

BW-APO System Landscape Scenarios and

Considerations

Document Version 2.1

BW SYSTEM ARCHITECTURE ASAP FOR BW ACCELERATOR

Table of Contents

TABLE OF CONTENTS.............................................................................................................................2

1 INTRODUCTION......................................................................................................................................3

2 BW AS A BASIS TECHNOLOGY FOR APO...........................................................................................3

2.1 COMPONENTS OF THE SAP ADVANCED PLANNER AND OPTIMIZER (APO ).......................................................3
2.2 BW AS ONE COMPONENT OF THE APO...................................................................................................5
3 INTERFACES BETWEEN APO AND BW...............................................................................................6
3.1 DEMAND-PLANNING.............................................................................................................................7
3.2 SUPPLY CHAIN COCKPIT (KPI'S)..........................................................................................................10
4 SYSTEM LANDSCAPE SCENARIOS....................................................................................................19
4.1 INTRODUCTION..................................................................................................................................19
4.2 APO(STANDALONE ) - R/3.................................................................................................................20
4.3 APO - BW - R/3............................................................................................................................22
5 COMMON INTERFACES.......................................................................................................................24
5.1 R/3...............................................................................................................................................24
5.2 SAPGUI.......................................................................................................................................25
6 MAINTENANCE ISSUES.......................................................................................................................26
6.1 SOFTWARE -COMPONENTS....................................................................................................................26
7 ADDITIONAL INFORMATION...............................................................................................................28
7.1 SAPNET......................................................................................................................................28
7.2 NOTES ...........................................................................................................................................28
7.3 CONTACTS.......................................................................................................................................28
7.4 REFERENCES ...................................................................................................................................29
APPENDIX................................................................................................................................................30

1998 SAP AMERICA, INC. AND SAP AG

1 Introduction
This paper has been written for BW-release 2.0b and APO-release 3.0. BW 2.0b will have a general
release by the end of August 2000.

2 BW as a basis technology for APO

2.1 Components of the SAP Advanced Planner and Optimizer (APO )

SAP APO is SAP's Supply Chain Planning solution, which offers best-in class planning features and
seamless integration with SAP R/3 and Legacy ERP systems.
The SAP Advanced Planner and Optimizer (SAP APO), consisting of a number of integrated
modules using a constraint-based planning and optimization philosophy.

S&DP

1998 SAP AMERICA, INC. AND SAP AG 3

BW SYSTEM ARCHITECTURE ASAP FOR BW ACCELERATOR

Supply Chain Cockpit provides users with a bird's eye view of all activities and applications Supply
Chain Cockpit model, monitor and manage your supply chain with a specially designed graphical user
interface. The Supply Chain Cockpit provides users with a bird's eye view of all activities and
applications

Demand Planning identify and analyze patterns and fluctuations in demand, and create accurate,
dynamic demand forecasts in an long term horizon. Using either algorithms of the statistical toolbox
incl. i.e. Promotion planning and cannibalization effects or creating a consistent, consolidated Plan
taking regional and local information into account

Collaborative Planning The goal of SAP APO Collaborative Planning, as the name suggests, is to
help enterprises carry out collaborative supply chain planning activities with their business partners.

Supply Network Planning match purchasing, production and transportation processes to demand,
and balance and optimize your entire supply network in a mid term horizon.

Production Planning & Detailed Scheduling optimize the use of resources and create accurate
plant-by-plant production schedules in order to shorten production life-cycles and respond rapidly to
changes in market demands forecasts in a short term horizon.

Global Available-to-Promise match supply to demand on a truly world-wide scale, and give your
customers reliable delivery commitments by means of both real-time checks and sophisticated
simulation methods

The SAP Business Information Warehouse (SAP BW), a pre-configured data warehouse ideal for
SAP environments, provides access to both internal and external information from multiple sources, as
well providing sophisticated reporting and analysis tools

SAP BW can now interact with the APO-system in two different ways
1. as a external data provider which supplies consolidated information from different ERP-
systems
2. as one APO-Component which provides certain functions to simulate and store different
planning cycles based on the information coming either from a data warehouse or from
different ERP-systems

Before we describe the interaction between APO and BW in more detail by explaining the different
Interfaces in Chapter 3, I would like to explain the idea of having a BW embedded into the actual
APO-system.
For further information on APO please have a look at the APO-Homepage:
http://sapneth6.wdf.sap-ag.de:1080/apo

 SAP AG 4
BW SYSTEM ARCHITECTURE ASAP FOR BW ACCELERATOR

2.2 BW as one Component of the APO

There are different ways of approaching the production plan of a company. One idea is to use
historical information about customer demands and to use these figures to forecast possible future
sales volumes.
Since planners want to be flexible in selecting the levels of detail (Material Group instead of Material
or Country instead of Customer) a multidimensional model are necessary to provide this kind of
flexibility.
Therefore it has been beneficial to use the same kind of methods already developed for reporting
again for the planning cycle. The only thing which was missing is the ability to write forecasted, i.e.
newly created, figures back to the InfoCube. Usually you would need an InfoSource to bring the data
back to the InfoCube but with some additional functions purely developed for APO this is not
necessary for the demand planning.
Because this APO-Interface has been developed on the BW-Standard-Platform no additional BW-
functions are available in the APO environment, i.e. the entire BW Administrator Workbench is
delivered with the APO.
However it is necessary to perform certain actions before you are able to utilize an InfoCube for
planning purposes! (see 3.1.1)

 SAP AG 5
BW SYSTEM ARCHITECTURE ASAP FOR BW ACCELERATOR

3 Interfaces between APO and BW

As shown in the picture below the APO and BW currently provide two standard interfaces:
- Data Mart for Demand Planning (also from Live Cache)
- Key Performance Indicators in the Supply Chain Cockpit
- Extractor for Standard Business Content for APO
- PPDS (Production Planning, Detailed Scheduling)
- Network Design

S&DP

Additionally both products can be linked to the same OLTP which provides basic information for the
different functions on both system.
BW extracts transactional and master data from a R/3 system for reporting purposes using functions
on the R/3 system which have to be implemented with a Plug-In.
The APO can utilize the same Plug-In functions on the R/3 to extract data for the demand planning.
Additionally the Core Interface (CIF) provides master data as well as production and inventory
information which are crucial for the live-cache features on the APO-system.
Both systems also provide interfaces to non-R/3 systems to incorporate their data for the respective
functions.

 SAP AG 6
BW SYSTEM ARCHITECTURE ASAP FOR BW ACCELERATOR

3.1 Demand-Planning

The following scenario is based on the idea that a BW-system keeps historical sales data for
reporting purposes. The same data can, of course, also be used as a starting point for future sales
planning. Consequently the data does not have to be extracted a second time from the underlying
OLTP but can directly be retrieved from the BW-system.

BW supports this process with the so called DATA MART interface. A DATA MART in this case is a
single InfoCube which can be used as a datasource; i.e. all the data which is kept in the InfoCube
can be extracted and delivered to the APO-system if required. If a subset of this DATA MART is
sufficient selection criteria on the APO-request can delimit the number of records.
Since APO includes all the functions of a BW-system the extraction procedure works in the same
way as it is known from the BW; i.e. the administrator requests data from a source system based on
a data source (InfoSource), the InfoPackage defines what subset of data shell be extracted at what
time using a certain transfer technique (IDOC, PSA) and one or several data targets (InfoCube(s))
The common case is to have just one DATA MART on the BW (Sales InfoCube) which acts as a data
source for the APO. APO extracts the data on a regular basis for the planning process. The historical
data will be stored in an InfoCube and the planned data will be calculated and stored in the Live
Cache. This technique is used for performance reasons.

 SAP AG 7
BW SYSTEM ARCHITECTURE ASAP FOR BW ACCELERATOR

3.1.1 Customizing on InfoCube for planning (APO 2.0)

Technically the APO-InfoCube matches exactly with the BW-InfoCube, i.e. it consists of dimensions,
and a fact table. Since the APO-InfoCube has to support additional functions it is necessary to
perform some more customizing :
Path: Supply Chain Planing - Demand Planning - Environment – current settings – Configure
InfoCube Parameter
Here it is necessary to maintain the following fields. The fields in brackets are optional.
(Factory Calendar), Base Unit of Measure, Statistical Currency, (Fiscal Year Variant)
This customizing has to be done after the InfoCube has been configured.
It cannot be done after data has been loaded!

APO does not deliver any predefined planning scenarios, i.e. there are no sample InfoCubes which
can directly be used. All what is provided is a template which includes the basic InfoObjects essential
for the planning purpose on the APO.
The name of this template-Infocube is DP-REFER

and it includes one characteristic APODPVRSI for the planning version and one key-figure
APODPDANT for Proportional Factors

Consequently you can either copy this cube to already have your mandatory InfoObjects included or
you create your own InfoCube from scratch but must not forget to include these before mentioned
InfoObjects.

3.1.2 Customizing on InfoCube and Live Cache for planning (APO 3.0)

Technically the APO-InfoCube incl. the historical data matches exactly with the BW-InfoCube, i.e. it
consists of dimensions, and a fact table. Since the APO has to support additional functions it is
necessary to perform some more customizing :
Path: Demand Planning - Environment - Current Settings - S & DP Administrations
Here it is necessary to create a planning object structure which should basically include the Info
Objects (Characteristics) which are used in the Info Cube with the historical data. In the next Step a
planning has to be defined. This planning area has to be assigned to the planning Object structure, to
the live Cache and to relevant storage bucket profile which includes the periodicities for the planning
area . In further steps the Key figures have to be chosen and here you add the information whether
the key Figure is part of the Info Cube with the historical data or if it will be stored in Live Cache.
APO does not deliver any predefined planning scenarios, i.e. there are no sample InfoCubes which
can directly be used. All what is provided is a basic InfoObject essential for the planning purpose on
the APO.
key-figure APODPDANT for Propotional Factor

Consequently you have to create your own InfoCube from scratch but must not forget to include this
before mentioned InfoObject. But this is only relevant for the historical data. At the Moment with APO
3.0 it is not yet part of the concept to store planned data in the Info Cube.

 SAP AG 8
BW SYSTEM ARCHITECTURE ASAP FOR BW ACCELERATOR

3.1.3 How to bring historical data into demand planning InfoCube

Activities (where/when/what):

APO-BW BW (external)
1. Define APO as Source System
with Source System Type
“Business Information Warhouse”
2. Define InfoCube for Planning
3. Set up InfoCube Parameters (see 3.1.1)
4.Generate an Export InfoSource
(from existing and filled InfoCube)
right mouse-click on InfoCube
5. Perform MetaData Upload
from BW
6. Define TransferRules
7. Define Update Rules
8.Create InfoPackage for InfoSource
9. Schedule Request

As you can see from the list of activities most of the actions have to be done on the BW embeded in
the APO. None of the activities should be difficult for a BW-Consultant since this is pure BW-
Administration.
For additional questions please refer to note :145 431 FAQ DemandPlanning / BW.

3.1.4 Close the Loop to BW

3.1.4.1 Planning Figures from Demand Planning

To evaluate the planning cycle it is necessary to compare the previous plan with actual sales data
extracted from the OLTP in the BW. The planning figures from the APO-system can be extracted in
the same way the historical data was retrieved from the BW. Since APO includes all BW functions
the DATA MART can be utilized the other way around. Thus in this scenario the planning cube
serves as a DATA MART for the BW; an InfoSource is generated from all the fields defined for the
InfoCube and data can be requested selectively. Accordingly for BW APO acts as an ordinary source
system.
From APO 3.0 there is the option to also keep the InfoCube in the LiveCache. The BW-Administrator
can interact with APO in the same way he was used to in APO 2.0. Thus the Service API on the
APO-site controls the extraction either from the InfoCube or from the LiveCache.

3.2 Supply Chain Cockpit (KPI's)

Key Performance Indicators (KPI's) which enable the production planner to have a clear image about
the current situation can be derived from the linked BW-system.

 SAP AG 9
BW SYSTEM ARCHITECTURE ASAP FOR BW ACCELERATOR

This means that the data is not stored on the APO-system but that the APO calls an existing
workbook -on the BW - including one or many queries which retrieve the data from one or many BW-
InfoCubes.

Consequently BW has to ensure that the relevant data is extracted from the OLTP-system and is
prepared for reporting (see customizing)

 SAP AG 10
BW SYSTEM ARCHITECTURE ASAP FOR BW ACCELERATOR

3.2.1 Business Content

All KPI's which are provided are part of the standard BW-BCT. The BCT is organised according to
roles. Different roles have been defined to support the typical APO-Users in BW:

DataSources for the relevant KPI’s can be APO as well as R/3 or any other source system. This
means that from the Supply Chain Cockpit (APO) you will have access to information not only coming
from the APO but also from all other systems related to the process you have to control and manage
as a typical APO-user. Here are some examples for KeyFigures / KPI’s :
Activities and Key Figures
production program planning
produced quantities
sales quantities, incoming order quantities
market volume, ...

production factor planning

downtimes per work center
capacity utilization per work center
delivery time deviations in the production area
maintenance times

 SAP AG 11
BW SYSTEM ARCHITECTURE ASAP FOR BW ACCELERATOR

production monitoring
order information on header and operation level
detailed confirmation information
available capacity, capacity requirements
downtimes
goods receipt
material consumption, deviations
leadtimes, executiontimes by order, work center
order status

quality management
results of quality tests
inspection lots, notifications, notification items
Production order and confirmation header LIS
Production order operation and confirmation LIS
Material consumption LIS
Standard Capacity Quotation
Downtimes

Repetitive Manufacturing
Quantities, Confirmations and Consumptions

Automotive
sequenced delivery schedule (for Just-In-Time-suppliers)
confirmation data according to reporting point

For further Information please check the BW-BCT Documentation available on SAPNET:
http://help.sap.com/ (mysap.com components, Business Information Warehouse)

3.2.1.1 R/3 - PP Business Content in BW

A typical example for a KPI fed with data from the R/3 is Downtimes which has been newly defined
with BW-BCT 2.0b and Plug-In 2000 on the R/3 side.
Downtimes can be recorded in R/3 and extracted to BW (New functionality of R/3 4.6c).
Production Manager and Shift Manager can therefore analyse on

– Downtimes grouped by downtime categories

– Idletimes per ressource, plant, month, day
– Downtime per ressource, plant, month, day
– Alerts if ressource downtime is above e.g. 30%

 SAP AG 12
BW SYSTEM ARCHITECTURE ASAP FOR BW ACCELERATOR

For further information please have a look at the business content documentation either for a certain
role or application component Production Planning.

3.2.1.2 APO Business Content in BW

Beside data coming from the demand planning there is other data processed in the APO which is
relevant for reporting (PPDS, Network Design). According to this aspect APO has created its own
business content which can be updated into specific InfoCubes on the BW system. This Business
Content is provided in APO 3.0 (Extractors) and BW 2.0b (InfoCubes, Queries).
InfoCubes
0APO_C01 Resource and operation data
DataSources 0APO_PPDS_RESCAPREQ_01 Ressource
0APO_PPDS_OPERATION_01 Operation
0APO_C02 Order data (Header Information)
DataSource 0APO_PPDS_ORDER_01 Order
0APO_C03 Order pegging data
DataSource 0APO_PPDS_PROD_CUST_01Pegging
0APO_C04 Network Design data for products
DataSource 0APO_ND_LOCMAT_01 Network Design
As marked on the following slide you the areas in the APO which are covered by BW-BCT 2.0b.

 SAP AG 13
BW SYSTEM ARCHITECTURE ASAP FOR BW ACCELERATOR

There is an enormous set of functions available to evaluate APO-Planning results with BW.
- Flexibility of reports, drill down, view from any angle
- HTML reports, MS Excel, Graphics, Mini Apps, GIS integration
- Integration with R/3 data
Especially the last fact gives you ability to
- Optimize: Compare Plan A with Plan B (APO Planning Versions)
- Compare with execution data
- Have a overview of actual and historical data :
What will be produced? What is the corresponding ressource load?
- Display the results of network design in a geographical context
(Geographic Information System)

For further Information please check the BW-BCT Documentation available on SAPNET:
http://help.sap.com/ (mysap.com components, Business Information Warehouse)

 SAP AG 14
BW SYSTEM ARCHITECTURE ASAP FOR BW ACCELERATOR

3.2.2 Customizing for the Supply Chain Cockpit

In order to show queries in the APO-system the administrator has to create links to the respective
workbooks in the BW. This can be done in customizing
Transaction: SPRO
Advanced Planner and Optimizer – Supply Chain Cockpit – Maintain SCC Context Menu
where you define the entries for the menu you are going to use to call the KPI's. For the new profile
you need to specify a BW-system which keeps the respective workbooks you want to include into
your APO-Menu. After the system has read the relevant information from the BW you can select from
the available workbooks which you would like to publish to the supply chain cockpit.
Using the right mouse button you will see what workbook is linked to the respective KPI. This is the
relevant information for the BW-administrator to administrate the relevant business content. Queries
in this context are predefined APO-reports which are developed in APO; i.e. these objects are nor
BW specific.

 SAP AG 15
BW SYSTEM ARCHITECTURE ASAP FOR BW ACCELERATOR

Example from APO 2.0

Step 1: Only one

destination setting
works. If you have
defined more than one
the last entry will be
active

Step 2:
See on the next
picture

Step 3:
When you define a new user
the profile defines here is
used as the default.
If you like to change profiles
for existing users you go via
SAPEASYACCESS-Menu
Path: Navigation-
SupplyChain-Settings-
Cockpit
In case there is no entry the
profile “default” will be taken.
The content of the “default”
profile cannot be changed!

 SAP AG 16
BW SYSTEM ARCHITECTURE ASAP FOR BW ACCELERATOR

 SAP AG 17
BW SYSTEM ARCHITECTURE ASAP FOR BW ACCELERATOR

3.2.3 Customizing in the BW

If a workbook is relevant for the APO it is necessary to activate the workbook and the other related
MetaData objects of the respective Standard-BCT. It is, of course, also possible to create your own
workbooks and link them to an APO system. This has to be done before you can create your menu in
the supply chain cockpit since you are referring to these previously created workbooks.
It is important to understand that the APO-user as any other BW user is dependent on the proper
loading and administration procedures in the BW. There is no administration interface from the APO
to the BW for APO-BCT.

3.2.4 Authorization

There is no authorization check for the KPI's on the APO; i.e. Authorization of APO users have to
specified in the BW system.
The RFC-Connection (SM59) to the BW has to be set up for the current user in order to enable the
individual authority check on the BW. Consequently all KPI-Users on the APO System need to be
maintained as reporting users on the BW-System.

 SAP AG 18
BW SYSTEM ARCHITECTURE ASAP FOR BW ACCELERATOR

3.2.5 Restrictions

WEB-Queries cannot be used in APO 3.0 . It is planned to show WEB-Queries in later releases in the
map-window of the Supply-Chain Cockpit.

4 System Landscape Scenarios

4.1 Introduction
When it comes to Landscape considerations all aspects of the different components need to be taken
into account. From the combination of APO and BW the most important one is how you want to use
BW in this environment. Since BW works as a tool for central consolidation and data cleansing for all
source systems it can provide homogenized data for APO, CRM, B2B or any other component. If
you ignore this fact but you still want to work in a multi-system environment using different
components a major effort has to be done to keep all systems insync from the data model point of
view.
Moreover it is possible to use BW within the APO for reporting however it might have some effects on
the performance. Accordingly the priority of reporting in the discussed environment has to be clearly
defined.

 SAP AG 19
BW SYSTEM ARCHITECTURE ASAP FOR BW ACCELERATOR

Different Scenarios for APO / BW - Landscape

Hub & Spoke APO / BW in parallel

Consolidation APO-Standalone

For further information on System Landscape Scenarios please check Global-ASAP-Accelerator.

4.2 APO(Standalone) - R/3

4.2.1 Considerations

There are several reasons why a customer wants to keep BW and APO as one instance. One might
be the lower investment another the reduction of complexity and maintenance. If this is really the
case depends very much on the reporting requirements. Thus it has to be checked how many users
would work with the APO-system as BW-users. Since APO is designed and tuned for planning
functions it is likely that a parallel tuning for the BW demands will contradict with the earlier made
settings.

4.2.2 Demand Planning

With the new BW 2.0b which is included in APO 3.0 it is possible to create the full demand planning
scenario within the same APO-System.

 SAP AG 20
BW SYSTEM ARCHITECTURE ASAP FOR BW ACCELERATOR

Historical Sales Data can be loaded from one or many R/3 or external systems into one InfoCube
which serves as the basis for demand planning. For R/3 you are going to use the same extractors as
you would use for a pure BW-Extraction; i.e. all features available for BW will also be available for
APO, e.g. Delta-Extraction.
On top of this SalesCube you can create a DATAMART which provides the relevant information for
another InfoCube purely used for planning.

4.2.3 Demand Planning (Close the loop)

For reporting you could now decide to either use a multicube on top of both, Planning and
SalesCube, or to use the PlanningCube as a DATAMART for the SalesCube again.

4.2.4 Reporting

Generally there are no limitations on using the Bex-Analyser for InfoCubes created in the APO.
Accordingly you can create flexible reports using variables, restriced key figures, calculated key-
figures, templates and so on. Even WEB-Reporting is possible on an APO-System.
The only limitations we have encountered so far are (APO 2.0 only):
1. If you want to perform reporting directly on the planning cube you have to consider
note: 156695 Request ID for APO Request
Since BW-Reporting is based on Request ID’s which are usually related to a physical load of data
into the InfoCube APO provides a artificial request for their planning figures. Theses requests are
not stored in all relevant tables necessary for BW-Rreporting. Therefore you first have to run a
program which does the relevant settings for you.
2. Aggregates cannot be built on PlanningCubes
This might lead to some performance issues but could be avoided by building a DATAMART and
report on a pure reporting-oriented InfoCube.

4.2.5 KPI's in the Supply Chain Cockpit

Calling KPI's from the Supply Chain Cockpit is no problem even if they are located on the same
system. For this you just have to maintain the logical system accordingly. (see 3.2.2)

4.2.6 Installation

For the installation it is necessary to install an APO-system.

Concerning the BW no further steps are necessary on the server site since all BW-functions are
already included in the APO-Installation.

4.2.6.1 R/3 Plug-In

The Plug-In (PIXX) has to be installed on the R/3 system. A PIXX-A is not sufficient since it is just
relevant for the BW but not for additional functions for the APO.
BW- Support Packages will be included into APO Support Packages therefore no additional effort is
necessary to support the APO-BW technically.

 SAP AG 21
BW SYSTEM ARCHITECTURE ASAP FOR BW ACCELERATOR

Notes:
186928 for APO-BW
181248 General Information on the Plug-In
183813 Conflict resolution transports (CRT's)

4.2.6.2 Client /SAPGUI

If you want to do any kind of reporting on top of the APO you need to have the Business Explorer
components installed. So even if you want to use a third party tool on the client it is still necessary to
have the Business Explorer Analyser available for the definition of the so called Query-Cubes -
interface to the 3rd party frontends.
The relevant BW-frontend-components are delivered with the APO SAPGUI (> 4.5a)
All you need to do is marking the BW-Add-On Component in the SAPGUI-Setup. This will install the
BEx-Components on your desktop. Installation time is not more than 5 minutes.
For Licensing Questions please consult the respective sales manager.

4.3 APO - BW - R/3

This section covers two scenarios, Hub & Spoke and Consolidation, since from an APO perspective
there is no difference. In both scenarios there is just one APO existing which is tightly connected to
just one BW which serves as the data provider. Of course there are still interfaces to R/3 system(s)
from the APO (CIF) but this topic will not be covered in this paper since we just want to concentrate
on the standard interfaces between APO and BW.

4.3.1 Demand Planning

To use two different instances for APO and BW is the recommended approach by SAP. BW serves
as a Data Consolidation and Reporting tool whereas APO is dedicated to specific planning functions.
That kind of information which is neccessary for planning can be retrieved from the BW using the
DATAMART-Interface. This Scenarion has been discussed in section 3.1 already.

4.3.2 Demand Planning (Close the loop)

To be able to compare the previously made planning data needs to be written back to the original
InfoCube which also holds the ‘new’ sales-data. Thus BW is the tool for checking the quality of the
planning process whereas APO is the dataprovider to make comparisons possible.

4.3.3 Reporting

Reporting is defined and performed on the BW-System. BW is tuned to make quick and efficient
reporting possible using tools like compression, aggregates and the entire set of OLAP-Functions.
But also from an administrative point of view BW is the right place. Here you define when data is
loaded (Scheduler) from which system and to whom it may be presented (Authorizations).
Consequently BW is the place where you control the flow of information not only to power- or end-
users but also to other system-components.

 SAP AG 22
BW SYSTEM ARCHITECTURE ASAP FOR BW ACCELERATOR

4.3.4 KPI's in the Supply Chain Cockpit

As described before BW is managing the information but there are options to access this information
like from the supply-chain cockpit. As described in 3.2 BW has to provide the information meaning all
admistrative tasks need to be managed by the BW personell; e.g. Design,Activation, Loading,
Authorization

4.3.5 Installation

APO is going to be installed on one instance, which means one DB-Server and none to many
Application Servers including the LiveCache. APO-BW-Functions are still included in the APO, i.e.
installed on the application server. APO has a unique Logical System Name.
BW is another instance with a seperate DB-Server and none to many Application Servers. BW has a
unique Logical System Name.
Both system can be connected using Standard ALE-Settings to exchange data.

4.3.5.1 R/3 Plug-In

BW uses the Plug-In XX or Plug-In XX-A to access R/3-Systems.

APO uses the Plug-In XX to access R/3-Systems. BW Support Packages will be included into APO
Support Packages therefore no additional effort is necessary to support the APO-BW technically.
Notes:
186928 for APO-BW
181248 General Information on the Plug-In
183813 Conflict resolution transports (CRT's)

4.3.5.2 Client /SAPGUI

Dependent on the user profile a local SAPGUI can contain just APO-, BW- or both functions at the
same time. During the SAPGUI-Setup you can decide which frontend-components shell be
implemented.
According the different patch-schedules maintenance of local SAPGUIS can be quite heavy
especially if they include both components.
Additionally impacts of patches from one component on the other component can occur. (e.g.
chart.ocx). APO requires always valid *.ocx. Since not only a change in the release requires in all
cases new *ocx files but also with every support package it is necessary to install and manually
register (regsvr32) them to the system.

 SAP AG 23
BW SYSTEM ARCHITECTURE ASAP FOR BW ACCELERATOR

5 Common Interfaces

5.1 R/3
Since APO includes the same functions as a BW-system it can also use the same extractors which
are provided with the Plug In (Plug In-A) on the R/3 system. These extractors can be used for APO
purposes, historical sales data for Demand Planning, as well as for BW purposes, i.e. using the
embedded BW as a reporting tool rather than just a planning component. (see 4.1)

5.1.1 Extraction of LIS-Data

With the new Plug-In 2000 it is possible to feed many different systems with the same information,
even delta-information. Thus extraction of LIS-Data does not have any impact on any other system
so that the same datasource can be used for as many systems as you like. Please bear in mind that
this is just a technical freedom. (see 4.1)

5.1.2 Extraction of Master Data

APO uses two different types of master data:

- BW (DATA MART)
- Core Interface (CIF)

5.1.2.1 Master Data from BW

With the DATA MART BW does not only provide generated extractors for transactional data but also
for all characteristics included in the respective InfoCube.
Example:
InfoCube (SalesCube) contains the following InfoObjects
Characteristics 0SOLD_TO, 0MATERIAL, 0SALESORG, 0DIVISION
KeyFigures 0REVENUE, 0QUANTITY
Generated InfoSources
8SalesCube, 8SOLD_TO, 8MATERIAL, 8SALESORG, 8DIVISION
Consequently all generated DATA MART-InfoSources use '8' as a prefix. The master data
InfoSources do include the same attributes as they were defined on the BW system. This
data is going to be extracted on a regular but asynchronous basis.
With APO 3.0 not only master data but also their navigational attributes can be used for planning.
With this background the definition, proper loading and extraction of master data from BW becomes
quite important for the APO-DemandPlanning.
Since demand planning differs from the other APO-functions in its master data utilization it is
necessary to ensure that the planning data can be matched to the existing APO-master data later on
in Supply Network Planning (SNP). If necessary matching rules can be programmed in an user exit.

5.1.2.2 Master Data from the Core Interface (CIF)

The master data which is extracted via the CIF contains pure planning relevant information. Data is
extracted synchronously. APO differentiates between central master data, like weight or size, and
location specific master data, like planning strategy.

 SAP AG 24
BW SYSTEM ARCHITECTURE ASAP FOR BW ACCELERATOR

5.1.2.3 Interdependencies between both techniques

Additional Master data extraction from OLTP to BW does not conflict with APO's CIF (Core Interface)
for R/3.
- CIF for R/3 establishes the integration between R/3 systems and APO meaning the
exchange of master and transactional data as well as planning results.
- Master data for APO Demand Planning are uploaded via DP immanent extractors, which are
similar to BW extractors. Both do not conflict which each other.
- Deltas for BW and Demand Planning do not conflict which each other either.

5.2 SAPGUI
4.6d can be used for APO, BW and R/3 OLTP. (4.5 GUI, APO 2.0, BW 1.2b) Components can be installed
individually or altogether onto the same desktop.
According the different patch-schedules maintenance of local SAPGUIS can be quite heavy
especially if they include both components.
Additionally impacts of patches from one component on the other component can occur. (e.g.
chart.ocx). APO requires always valid *.ocx. Since not only a change in the release requires in all
cases new *ocx files but also with every support package it is necessary to install and manually
register (regsvr32) them to the system.

 SAP AG 25
BW SYSTEM ARCHITECTURE ASAP FOR BW ACCELERATOR

6 Maintenance Issues
The following picture shell give you an overview about the different components which need to be
implemented on the R/3 system in order to extract data for an APO-system.

6.1 Software-Components

• Plug-In’s
The New Dimensions products consist of the servers (APO, CRM, BW, BBP, SEM) and the
respective interfaces (plug-ins) which are installed on the existing R/3 Systems.
The add-ons PI and PI-A replace the old interfaces APO-CIF, CRM-R3A, BW-BCT and B2B-PRO-PI.
PI is a complete package of all interfaces, and PI-A is a part without modifications (at present BW-
BCT for Releases 3.0F, 3.1H, 3.1I, 4.0B, 4.5B, BW-BCT, B2B-PRO-PI for Release 4.6A).
As of R/3 Release 4.6B, PI-A will no longer be available since PI is modification free.

 SAP AG 26
BW SYSTEM ARCHITECTURE ASAP FOR BW ACCELERATOR

• CRT’s
R/3 Plug-in has modified the Standard R/3 code to a certain extent.
Naturally, these modifications may conflict with Standard corrections, which are delivered via Support
Packages (former name: Hot Package (HP)) or Legal Change Packages. Therefore, if you have the
R/3 Plug-in installed in your R/3 system, the system will not allow you to apply a Support Package or
a Legal Change Package, without asking you for the corresponding Conflict Resolution Transport
(CRT).
SAP has separate maintenance tracks for R/3 Plug-in for each R/3 Release, out of which Conflict
Resolution Transports (CRT) are produced.
CRT’s align changes made to objects by CIF and HP.
A CRT for R/3 Plug-in contains
- resolution of conflicts between SP/LCP and R/3 Plug-in
- R/3 Plug-in-specific corrections

• CIF
modifications + enhancements as ‘stand-alone’ layer
• CIF release
functional enhancement to establish integration
similar to PI release
• HP
hot package
regular way to ship R/3 corrections
• LCP
legal change package
HP + HR modifications

 SAP AG 27
BW SYSTEM ARCHITECTURE ASAP FOR BW ACCELERATOR

7 Additional Information

7.1 SAPNET

Available SAPNET alias BW - Release & Maintenance

HW/SW Platforms http://sapneth6.wdf.sap-
ag.de:1080/~sapidb/011000358700006655572000E
General Information SAPNET ALIAS 'BW'
on BW http://sapneth6.wdf.sap-ag.de:1080/bw
General Information SAPNET ALIAS 'APO'
on APO http://sapneth6.wdf.sap-ag.de:1080/apo

7.2 Notes

Please consider the following notes to install and maintain software-components of either the BW or
the APO-System.

General Notes:
145432 DP /BW FAQ
156695 Request ID for APO-Requests
186928 for APO-BW
181248 General for Plug-In
183813 CRT's
BW-Patches are supported with APO Support Packages.

Plug-In-Notes:
181255 “Overview: Notes for PI 99”
181262 “CRT’s for PI 99”
172772 “Installation PI 99”
172773 “Delta-Upgrade PI 99”
181248 “Release Strategy for PI 99”

7.3 Contacts

Kai-Uwe Fechner / Holger Schmidt APO-RIG

 SAP AG 28
BW SYSTEM ARCHITECTURE ASAP FOR BW ACCELERATOR

Nicolai Unterbarnscheidt BW-RIG

Oliver Schuck APO - LGD (Beratung)
Alexander Grages

7.4 References

 SAP AG 29
BW SYSTEM ARCHITECTURE ASAP FOR BW ACCELERATOR

Appendix

KPI_engl.doc

 SAP AG 30