...

System Landscape/Transport- Strategy for BW ASAP BW

by user

on
Category: Documents
46

views

Report

Comments

Transcript

System Landscape/Transport- Strategy for BW ASAP BW
System Landscape/TransportStrategy for BW
ASAP FOR BW ACCELERATOR
BUSINESS INFORMATION WAREHOUSE
A plan to build a system landscape for
running SAP´s BW 2.0
Document Version 1.0
SYSTEM LANDSCAPE/TRANSPORT-STRATEGY FOR BW
ASAP FOR BW ACCELERATOR
Table of Contents
1
SYSTEM LANDSCAPE / TRANSPORT STRATEGY ........................................................................... 3
2
RECOMMENDATION FOR BUILDING A SYSTEM LANDSCAPE ...................................................... 3
2.1
2.2
2.3
3
RECOMMENDED SYSTEM LANDSCAPE ................................................................................................. 3
SETTING UP THE SYSTEM ................................................................................................................... 4
INSTALLING SYSTEMS BY COPY OF EXISTING SYSTEMS......................................................................... 4
TRANSPORT STRATEGY .................................................................................................................... 5
3.1
CONNECTING SYSTEMS...................................................................................................................... 5
3.1.1
Development system OLTP (O1) / Development system BW (B1) ......................................... 6
3.1.2
Consolidation system OLTP (O2) / Consolidation system BW (B2) ........................................ 6
3.1.3
Production system OLTP (O3) / Production system BW (B3) ................................................. 7
3.2
STRATEGY ........................................................................................................................................ 7
3.2.1
Preliminary steps ..................................................................................................................... 7
3.2.2
Categories of transport requests.............................................................................................. 8
3.2.3
Technical background .............................................................................................................. 9
4
UPGRADE STRATEGY ....................................................................................................................... 10
4.1
REQUIREMENTS .............................................................................................................................. 10
4.2
STRATEGIES ................................................................................... ERROR! BOOKMARK NOT DEFINED.
4.2.1
Upgrading BW system from 1.2A to 1.2B in conjunction with the upgrade of extractors on
the OLTP starting with development systems ...................................................................................... 11
4.2.2
Upgrading BW system from 1.2A to 1.2B in conjunction with the upgrade of extractors on
the OLTP starting with a copy of production systems to quality systems ........................................... 12
4.2.3
Upgrading BW production system only .................................................................................. 12
4.3
KNOWN PROBLEMS .......................................................................................................................... 12
5
LITERATURE ....................................................................................................................................... 13
6
OSS NOTES ........................................................................................................................................ 13
1998 SAP AMERICA, INC. AND SAP AG
1 System landscape / Transport strategy
This paper is a recommendation for building a system landscape for running SAP´s Business
Information Warehouse. This paper is intended to describe the differences between the CTS in an R/3
environment and BW environment. It gives you hints for the transport and upgrade strategy within a
BW system landscape.
2 Recommendation for building a system landscape
2.1
Recommended system landscape
A typical system landscape consists of a development, consolidation and production system both on
the R/3 and on the BW side. For each R/3 OLTP system there should be a BW system. Furthermore it
is possible to access the R/3 systems and BW systems via an ITS server (The connection R/3 – ITS
is not drawn in the picture below). There is only one ITS server, but multiple virtual instances are
running on the ITS server. Each instance has to be assigned to one R/3 or BW system. There are no
transport routes among the virtual ITS instances. If one ITS service is defined for the development
system, it has to be checked in into the corresponding R/3 or BW system. This service will be
transported to the next R/3 or BW system and from there it will be checked out into the corresponding
ITS instance.
.
1998 SAP AMERICA, INC. AND SAP AG
3
SYSTEM LANDSCAPE/TRANSPORT-STRATEGY FOR BW
2.2
ASAP FOR BW ACCELERATOR
Setting up the system
The following steps should be performed after an installation of BW in order to setup the change and
transport system, these steps are the same steps as in a R/3 environment.

Check, if not done prior to the installation, if the transport directory has enough free space

Initialize WBO with transaction SE06

Configure the transport management system (TMS) with transaction STMS
2.3

define systems of the transport domain

define transport layers and routes
Installing systems by copying existing systems
It is common practice to install an R/3 system with the help of a database backup of another R/3
system. In a BW environment this procedure needs some additional steps as transfer structures and
communication structures are generated using the logical system name of the BW system. If a BW
system is setup this way several BW specific steps have to be performed:

Delete the R/3 source system in the AWB (administrator workbench, transaction RSA1) in the BW
target system (Table RSBASIDOC should have no entries with values <logical BW System> in
field RLOGSYS and <logical OLTP System> in the field SLOGSYS).

Delete the target system from the transport domain

Perform the database copy with all the usual follow up work

Disable the existing RFC connections once defined for R/3 and BW systems in the copied
systems by deleting the RFC connection. (Attention: In the 1.2B release, don’t delete the RFC
destination just remove the IP address or host name. Otherwise the next step will fail, because
the function module to delete the source system looks up the RFC connection)

Delete the old logical system of the old OLTP system, in order to do this use the function module
RSAR_LOGICAL_SYSTEM_DELETE. Check in the AWB that the source system is deleted.

Create a new logical system and assign it to the source client (The system has to be restarted for
the new values to take affect)

Alignment of number ranges for EDIPORT in the new BW system with its R/3 source system

Create new RFC connection

Create new R/3 source system in the AWB

Redefine mapping of source systems

Update InfoSource metadata
2000 SAP AG
4
SYSTEM LANDSCAPE/TRANSPORT-STRATEGY FOR BW
ASAP FOR BW ACCELERATOR
An alternative would be to copy a pair of systems. You can copy the BW system and the connected
R/3 system.
3 Transport strategy
3.1
Connecting systems
You must ensure that the relevant release-dependent extractors are implemented on the R/3 systems,
either the so called PI or PI-A (The BW-BCT extractors won’t work). It is recommended to use the
most current version of the extractors.
Transports are only possible between R/3 systems (O1, O2 and O3) or BW systems (B1, B2 and B3).
It is not possible to transport between R/3 and BW systems. The communication between R/3 and
BW systems during the upload process takes place via RFC.
As of release 2.0A the transport management system (TMS) in the BW system is switched off by
default, it is not possible to switch it on. If objects are created in a BW system they will be assigned to
the development class $TMP, as a result of this fact they will be created as local objects. No pop up
for a transport request will occur. If an object should be transported, its development class has to be
reassigned to a none local development class and the object has to be linked to a transport request.
To do this assignment choose transaction RSA1  GOTO  Transport connection.
2000 SAP AG
5
SYSTEM LANDSCAPE/TRANSPORT-STRATEGY FOR BW
ASAP FOR BW ACCELERATOR
In this transaction it is possible to choose the objects via drag and drop. Just drag the objects to be
transported from the window “all objects” (left window) to window “collected objects” (middle window).
The major advantage of this method is that all dependent objects will be collected in the transport
request automatically. If , for example, an info cube should be transported, not only the info cube has
to be transported but the info areas and info sources belonging to this cube as well. Once an object is
linked to a none local development class this link persists – if not changed manually. If such an object
will be changed, the user will be asked for a transport request. From now on the behavior for this
object is like in an ordinary R/3 system.
3.1.1
Development system R/3 (O1) / Development system BW (B1)
The BW development system is connected to the R/3 development system. Ensure that the
development systems are identical to the production systems with respect to customizing settings and
metadata content. Adjustments to the R/3 production system must be reflected in the R/3
development system. Extractor enhancements (like view names used in RO* tables) and metadata
changes are recorded automatically in transport requests. These changes have to be transported
from the development system to the consolidation system and further on into the production system.
3.1.2
Consolidation system R/3 (O2) / Consolidation system BW (B2)
The BW consolidation system is connected to the R/3 consolidation system. As the consolidation
systems are for consolidation issues only, the servers on which these systems are installed can be
servers with smaller configuration. The customer can check / test in these systems the influence of
transports to the functionality of the system.
2000 SAP AG
6
SYSTEM LANDSCAPE/TRANSPORT-STRATEGY FOR BW
ASAP FOR BW ACCELERATOR
Ensure that the consolidation systems are identical to the production systems with respect to
customizing settings and metadata content. Adjustments to the R/3 production system must be
reflected in the R/3 consolidation system.
3.1.3
Production system R/3 (O3) / Production system BW (B3)
The BW production system is connected to the R/3 production system.
If available, the extractor enhancements from the R/3 development / consolidation system must be
imported into the R/3 production system. A metadata upload must be carried out in order to make any
new metadata available in the BW production system. It is not possible to transport the uploaded
metadata from the development BW system into the following systems. This is done because a
transport of these metadata could lead to inconsitencies in the target system if later a meta data
upload will be performed in the target system.
The no change switch for the R/3 system ensures that no repository objects can be changed in the
production system.
3.2
3.2.1
Strategy
Preliminary steps
During metadata upload the metadata will not be assigned to any development class, the uploaded
metadata can’t be transported between BW system. The metadata upload has to be done for each
pair of systems (R/3 OLTP – BW) separately.
Before transfer structures can be transported between BW systems you have to maintain the
conversion table RSLOGMAPSYS (via menu in RSA1 –> Tools –> Mapping of the source system
names). The conversion table is maintained in the target BW system, into which the transport will be
imported. InfoSources mapped to a source system are converted during the transport using this
conversion table.
Before the first transport between the BW systems (B1, B2 and B3) takes place, a metadata upload
from the connected R/3 systems to the BW systems should be done in order to avoid possible errors
in the transports. For example: If a TransferStructure is transported it can only be activated if the
relevant DataSource already exist in the target system.
2000 SAP AG
7
SYSTEM LANDSCAPE/TRANSPORT-STRATEGY FOR BW
ASAP FOR BW ACCELERATOR
If enhancements are made to extractors on the R/3 side, these enhancements should at first be
transported from R/3 development to R/3 consolidation or R/3 production system followed by a
metadata upload to the connected BW systems.
3.2.2
Categories of transport requests
We logically distinguish between 3 categories of transport requests:

Transport requests for “normal” BW objects

Transport requests for Roles

Transport requests for all BEx objects
The transport behavior for “normal” BW objects has been described above. However, the behavior for
the other two types of transport requests differ slightly from the described behavior.
Roles are client dependent objects, thus they have to be recorded in customizing requests. The
transport of these customizing requests has to be performed in the same way as in an OLTP R/3
system.
For the first time a BEx object will be transported the behavior is like for “normal” BW objects, they will
be assigned to the $TMP development class. As soon as the BEx objects are assigned to a non local
development class the behavior differs from the behavior of “normal” BW objects. All BEx objects are
always recorded into one special transport request, which has to be created by the system
administrator. This has to be done in the transport connection within the AWB. As soon as the the
BEx transport request is released the administrator has to create a new one. This behavior is
designed this way to avoid to choose transport requests when the user works with the frontend.
2000 SAP AG
8
SYSTEM LANDSCAPE/TRANSPORT-STRATEGY FOR BW
3.2.3
ASAP FOR BW ACCELERATOR
Technical background
BW uses logical transport objects, so called TLOGO objects, defined in transaction SOBJ. These
objects are listed in the table below. Where entries numbered with A# are objects which are not
specific to BW, but used by BW as well.
2000 SAP AG
Nr. TLOGO Objekt
TLOGO
1
Currency translation type
CTRT
2
InfoArea
AREA
3
Application
APCO
4
Routine
ROUT
5
InfoObject
IOBJ
6
Hierarchy
HIER
7
InfoObject Catalog
IOBC
8
ODS Object
ODSO
9
InfoCube
CUBE
10
Aggregate
AGGR
11
InfoSource transaction data
ISTD
12
Communication Structure
ISCS
13
Update rules
UPDR
14
Source system
LSYS
15
File DataSource
ISFS
16
Transfer rules
ISMP
17
Transfer Structur
ISTS
18
Info Package
ISIP
19
Info Package Group
ISIG
20
Element (Report)
ELEM
21
Report Agent Setting
RASE
22
Report Agent Package
RAPA
23
BW: RRI InfoCube Recipient
RRCA
24
BW: RRI Query Recipient
RRQA
25
Workbook
XLWB
26
Event- Administration Chains
EVEN
A1
Authorization Object
SUSO
A2
Authorization
AUTH
A3
Authorization Profile
SUSP
A4
Role
ACGR
A5
ABAP Query: User group
AQBG
A6
ABAP Query: Functional area
AQSG
A7
ABAP Query: Query
AQQU
9
SYSTEM LANDSCAPE/TRANSPORT-STRATEGY FOR BW
ASAP FOR BW ACCELERATOR
4 Upgrade strategy
4.1
Requirements BW upgrade
You need BW 1.2B with 4.5B Kernel (and Oracle 8.0.5 if you have an Oracle database) for upgrading
to BW 2.0. The upgrade of a BW system works in the same way as for an ordinary R/3 system, the
tool R3up is used for the upgrade. The only difference is that for a BW upgrade always strategy A_off
is used.
4.2
Requirements R/3 OLTP upgrade
Performing an upgrade of an OLTP system with an installed extractor is a bit more crucial. Consider
the following system configuration: OLTP R/3 release 3.1H with BW-BCT extractor. After the upgrade
the system should be an OLTP R/3 release 4.6B with PI-2000. If such an upgrade has to be
performed, it has to be done in multiple steps.
1. Upgrade BW-BCT extractor for release 3.1 H  PI-2000 for release 3.1H
2. Upgrade R/3 3.1H  R/3 4.6B, bind the PI-2000 upgrade CD to the upgrade, as a result of this
binding the PI-2000 for release 4.6B will be installed.
4.3
Strategies
Before starting the upgrade you should backup the system you plan to upgrade.
You should follow the transport route of your system landscape. That means the upgrade should start
with the development system. It is recommended to start the upgrade with the BW server, in long
running phases of this upgrade it is possible to upgrade the extractors.
After the upgrade, please install the language CD and the released patches for BW 2.0A/B.
2000 SAP AG
10
SYSTEM LANDSCAPE/TRANSPORT-STRATEGY FOR BW
ASAP FOR BW ACCELERATOR
4.3.1
Upgrading BW systems in conjunction with the upgrade of extractors on R/3
starting with development systems
In this scenario the whole functionality of BW after the upgrade can be tested. After the upgrade you
can redo modifications.
2000 SAP AG
11
SYSTEM LANDSCAPE/TRANSPORT-STRATEGY FOR BW
ASAP FOR BW ACCELERATOR
4.3.2
Upgrading BW systems in conjunction with the upgrade of extractors on R/3
starting with a copy of production systems to quality systems
The advantage of this scenario is, that tests after the upgrade can run with mass data.
At first create a full database copy of BW and R/3 production systems. After copying the production
systems to the quality systems disable the existing RFC connections once defined for R/3 and BW
production systems in the copied systems.
At first start the upgrade of the copied BW system. When the upgrade is finished you can redo
modifications in BW. Then test the functionality in BW (Analyzer, Web Reporting, Queries, Admin.Workbench, InfoCubes, etc.)
In parallel you can do the upgrade of the extractors on the copy of R/3. After this upgrade is finished
you can redo modifications, enable the RFC connection and test metadata and data upload with mass
data.
4.3.3
Upgrading BW production system only
At first create a full database copy of the BW production system to a standalone system. After copying
the production systems to the standalone systems disable the existing RFC connections once defined
for R/3 production systems in the standalone system.
In this environment you can only test a limited functionality of BW after the upgrade. As there is no
connection to an R/3 system, data upload from R/3 can’t be tested.
4.4
Known problems
Known problems concerning the upgrade to BW 2.0B are published in note 183396. This note is
related to all databases, there are special notes for each database.
2000 SAP AG
12
SYSTEM LANDSCAPE/TRANSPORT-STRATEGY FOR BW
ASAP FOR BW ACCELERATOR
5 Literature and Training
Additional information concerning the Change and Transport Organizer can be found in the online
documentation of BW and in the online documentation of R/3. SAP offers a 3 day training course
(BC325) concerned with the setup of a system landscape. Please also note the course TABW90,
covering this topic especially for BW.
6 OSS Notes
Check OSS from time to time concerning notes corresponding to CTS and BW. Especially there is an
OSS note for every available BW support package. Make sure to read these notes before applying the
support packages in order to avoid known problems.
The following notes exist so far for patches for a BW 2.0B system:

213081 BW Support Package 01

213141 BW Support Package 02
Furthermore check the following notes:

176143 Q&A Transfer BC, transport connection, Object Browser

130691 gives a general overview of all BW related notes
2000 SAP AG
13
Fly UP