CTS With SAP BW

Using the
Corrections and
Transport System
(CTS) with SAP BW
1
Overview BEx Development Classes
Connecting Systems Executing the Transport
Object Versions Transporting a Role
Transports in the source system Standard Transport System
Transporting Objects in BW Object Alterability
BEx Objects Transport Strategy
Transporting BEx Objects Trouble Shooting
SAP AG 2002, Using the CTS with SAP BW 2
2
Overview
3
Recommended System Landscape
Development Consolidation Production

O1 O2 O3
R /3
RFC RFC RFC
BW
B1 B2 B3
A typical system landscape consists of a development, consolidation and

production system both on the R/3 and on the BW side. 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.
From BW 3.0 Web Application Server is used as a basis, ITS is then no longer
necessary for standard web reporting.
4
SAP TMS - Architecture and Terms
Change and Transport System (CTS)
Transport
Transport Organizer (CTO) Management
System (TMS)
Transport Tools (low level programs: tp, R3trans)
CTS architecture for BW is the same as for R/3. The same tools / programs are
used.
5
CTS - Post Installation Activities
The following activities have to be performed after an

installation:
n Initialize CTO
n Create / Choose transport directory
n Configure transport control program (tp)
n Configure system landscape
n Configure transport layers and routes
n Check TMS
6
Create transport layers / routes
SAP provides two editors for configuring additional transport routes for more complex system
landscapes:
Hierarchical list editor - The BW Systems in the transport domain and their transport routes are
displayed in a tree structure.
Graphical editor - The BW Systems and their transport routes are displayed graphically. The BW
Systems can be positioned and linked using the mouse. To call the graphical list editor, use
Transaction code STMS. Then, choose Overview -> Transport routes.
To create transport routes, use the mouse to drag the appropriate BW Systems from the node area,
and drop them in the display area. To create a transport route between these BW Systems, from
the screen Display Transport Routes, choose Configuration -> Transport Route -> Create
Transport Route. The mouse pointer becomes a stylus. Using the stylus, draw a line connecting
the two BW Systems between which a transport route is desired. In the dialog box Create
Transport Route, enter the required information for either the consolidation or delivery route.
Save.
7
Checking TMS
RFC connection test
Transport directory check
Transport control program (tp) check
All BW Systems in a transport domain communicate with each other using RFC
connections.
To check these RFC connections in the TMS overview, from the TMS initial screen
(Transaction STMS) choose Overview -> Systems -> R/3 System -> Check ->
Connection test. The connection test is performed in both directions . If you find that
there are connection problems with BW Systems having several application
servers, you can change the server configured for the TMS.
To verify the availability of the transport directories of all systems within the domain,
from the TMS initial screen (Transaction STMS) choose Overview -> Systems ->
R/3 System -> Check -> Transport directory.
To test the transport control program tp , from the TMS initial screen (Transaction
STMS) choose Overview-> Systems -> R/3 System -> Check -> Transport tool.
8
Connecting Systems
9
Connecting Systems
PI must be installed on R/3 (most current version recommended)
Transports only between R/3 systems or between BW systems.
Communication between R/3 and BW systems via RFC.
Default system setting: New BW objects are created as local

objects. Transports of new objects have to be done with the
Transport connection in the AWB.
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 wont
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 BW release 2.0A the Change and Transport Organizer (CTO) component in
the BW system is always switched ON. It was possible to switch off CTO in 1.2.
There is special logic implemented for BW objects. New BW objects are created as
local objects. Transports of new objects have to be done with the Transport
connection in the AWB. Here dependent objects are collected and the user can
assign a non local dev. class and a transport request to the collected objects.
10
Maintain Source System Mapping (Target System)
For source system specific objects a mapping

must take place during transport:
Different BW systems in the system landscape are connected to different

source systems.
During transport source system specific objects (transfer rules) must be

converted accordingly.
This is done with a mapping table (RSLOGSYSMAP).

Original source system (typically development system) is mapped to target
source system (typically consolidation or production system)
During metadata upload the metadata will not be assigned to any development class, the uploaded
metadata cant 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 RSLOGSYSMAP (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 exists in the target system.
The original source system is typically the development system for the consolidation system as well as
for the production system.
If this entry is missing no mapping takes place and the objects are imported without being transformed.
11
Maintain Source System Mapping (Target System)
Example: In the system B2 you specify

that objects coming from O1 are mapped
to be dependent on O2. If the logical
system name of O1, O2 are TB3CLNT003,
QB3CLNT003 respectively, mapping in B2
looks like below
12
Transport Process

O1 O2 O3
R /3
1
RFC 2 RFC RFC
3
BW
B1 B2 B3
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.
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. 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.
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 thesemetadata could lead to inconsistencies 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.
Before 1st transport from B1/B2 do a metadata upload in B2 to avoid possible problems in transports and maintain
conversion table (RSLOGSYSMAP) in B2.
From 3.0A on step 2 will be done automatically so there is no user action required.
13
Object Versions
14
Object Versions
l Four object versions in BW:

n D - SAP Delivered version
n M - Modified or Changed version
n A - Active version
n T - temporary version for source system dependent objects (like
M-Version, details in note 411574)
l The Active version is the one exported in a transport request -

make sure correct version is active before transporting!
15
SAP BW Object Versions
An upgrade of the Business Content does not affect

the objects which are in productive use.
Version
M(odified) 11 11 11 22 22
A(ctive) 11 11 11 22
D(elivery) 11 11 22 22 22
11 install BC
2nd install
2nd delivery (match) BC
delivery from SAP from SAP
The objects of the Business Content are delivered in delivery version.

Changes are stored in modified version.
Active Business Content is stored in active version.
Only objects in the active version are exported from the development system.
When importing to the target system, these objects are either imported directly to
the active version, or to the modified version, depending on the type of object.
Currency translation types and InfoObject catalogs are examples of objects that are
imported in active version.
InfoObjects and InfoCubes are examples of objects that are first imported to
modified version and then activated after the import.
16
Metadata: Versions and Transport
l All BW meta objects are activated by the common After

Import Method RS_AFTER_IMPORT
Source system
M(odified) 11 11 22
export
A(ctive) 11 11
create activate change

import
Target system
M(odified) 11 11 44
A(ctive) 33 11 11
After
import method change
All modifications made to BW meta objects are written to change requests

After releasing a change request the active versions of the contained objects are
exported from the source system to the file system
When the change request is imported in the target system the objects are written
to the modified version
After the import is finished the so called After Import Methods are executed.
These methods try to activate the imported objects. Dependencies between the
objects (e.g. InfoObjects have to be activated before InfoCubes are activated) are
resolved in this step.
If the after import activation fails, the old active version of the object can still be
used
17
Transports in the
source system
18
Transports in the source system
l For BW 2.0 there are only two objects (DataSource and application
hierarchy for data sources) to be transported on the source system
side
l DataSources have an automatic transport connection
l The application hierarchy needs to be tranported manually (note

382471)
l Dont forget to transport enhancements (user exits), check whether

project is active
If you use business content data sources you can either transport them or activate
them in your source systems.
If you are using CO-PA please read notes 325902, 334991.
19
Manual Transport (of Several DataSources, RSA6)
is also possible
Select DataSources to Transport
This feature can be used if you want to manually create a transport request with
several DataSources, e.g. if a new system should be provided with those
DataSources.
20
Data Source Maintenance (RSO2): Change Object
Directory Entry Manually
First, select DataSource -> Object directory
*Dev. class has not been maintained
Choose a transportable Dev. class
You can manually change the development class of a DataSource in the

maintenance transaction, e.g. if you have created a DataSource as a local object.
21
Replicate DataSources in BW (Target System)
First, select Source Systems
Then, choose a Source System
Finally, select DataSource overview to

replicate one or several DataSources
Select Replicate DataSources to replicate

ALL DataSources from the source system
22
Replicate DataSources
In this case only the selected DataSource will be updated from the source system.
23
Transporting
Objects in BW
24
Grouping
l In the menu Grouping you can determine

how many objects should be taken into
consideration. The groupings summarize all
the objects of an area.
l The setting Save for system copy means that the source system dependent
objects are collected in a transport request. This request can be imported
after a system copy (of BW or source system) in order to map those objects
to the correct source system (with mapping table described above).
Details about system copies of BW systems are described in note 184754.
25
SAP BW Metadata Visualized: Flow of Information
source transfer InfoSource update infoCube query workbook role

system rule rule
l The graphic is embedded in an HTML page and encoded in VML

(XML based Vector Markup Language).
l VML is supported by Internet Explorer 5 and other vendors. It is
not available in IE 4.
l When the graphic was created, no source system was available
with data for the upper InfoSource. Hence, no transfer rules ...
would be created during Business Content installation.
26
Maintain Source system assignment for object
collector
Source system dependent objects are only collected (for transport) if the
corresponding source system is assigned here.
At least one source system needs to be assigned.
In general all source systems should be assigned that have a corresponding
source system in the target BW system, however, this is only a default for the
object collector. You can still suppress transport of such objects after they have
been collected, if you dont want to transport for all source systems.
27
Collection mode
l In the menu Collection mode, you can

determine how you want to collect data.
With collect automatically, the data is
collected directly when selecting
objects. With start manual collection,
the data is collected by first choosing
the pushbutton gather dependent
objects.
28
Transport Object Selection
l Choose how you want to view the

objects:
n Data Targets by InfoAreas
n InfoObjects by Application
Component
n InfoSources by Application
Component
n Roles
n Object Types
n Development Classes
29
Transports connection
1. Select one or
3. Write to
several objects
transport request
New Objects
(Development Class
$TMP) are marked
automatically
2. Drag & Drop

objects (or use
context menu)
30
Transport Information
l Objects that are not yet assigned to

a transportable development class
are automatically flagged for
transport
l Other objects can be flagged

manually if e.g. import failed and
transport should be redone (might
already be locked by other
requests, though)
l Additional information is also

available:
n Last changed on/by
n Last changed by
n Transport request
n Transport order holder
n Development class
31
Transporting BW Objects
Select Transport objects
32
Transport BW Objects For the First Time
Replace $TMP with a

relevant Development class
(customer: Y*, Z*)
Create a request or choose

an existing one
Create and use your own development classes, dont use SAP development
classes.
33
Check Transport Status
Check status of transport
If there are dependent objects already written to other transport requests make
sure those other requests are released in time.
34
Transporting Changes After First Transport
After assignment of a transportable development class BW objects

have an automatic transport connection.
Still they can be transported again with the BW transport connection

(they could be locked, though!)
l AWB objects are handled in the standard way
l For BEx objects there is a special implementation as follows
After an object has been assigned to a transportable development class (usually

after the first transport) changes to those objects are automatically recorded.
BEx obejcts are then handled in a special way but AWB objects are treated in the
standard way, i.e. the user is asked for a change request when changing such
objects.
Still those objects can be transported manually using the transport connection. By
default they are not marked for transport but they are collected and you can mark
them manually to be transported.
35
Transport of BEx
Objects
36
BEx Objects
l BEx objects relevant to transport

are:
n Workbooks
n Queries
n Structures
n Restricted Key Figures
n Calculated Key Figures
n Variables
From 3.0A on we have additional BEx Objects:

Templates
Query Views
Items
37
Transport of BEx objects
l For BEx objects, the first transport works as described above.
l While making changes to the BEx objects which are no longer $TMP,
the system records the changes to a pre-assigned CTS Request.
n There is one CTS Request, for example, Standard CTS Request" where
changes to the BEx objects can be recorded.
n You can also specify the CTS Request by Development class.
l The end user is not prompted for the Request at all.
38
Assigning Changes of BEx Objects
l The system has a two level process for choosing the CTS Request
for recording the changes.
n First, the system looks for the CTS Request which is assigned to the
development class of the BEx object.
n If its not found then use the Standard CTS Request.
39
Setting Up the BEx
Development
Classes
40
Maintain Request BEx
Select Request BEx
If this has already been

maintained, then this
message appears
This button will no longer be available in BW 3.0 (see below)
41
Change the Standard BEx transport request
To change the
Standard BEx
transport request,
select BEx
development classes
42
Reassign Standard BEx transport request
The Standard BEx

transport request is
visible here. To
change this, select
Assign / delete
The standard transport request can be assigned here (additionally to the way
shown before).
From 3.0A on this will be the only way to assign / change the standard transport
request.
43
New transport request for BEx
Create a new
transport request, or
choose an existing
one.
44
Add a Development class
Select Insert row
Then Enter the

development class
45
Request Assigned to Development class
Create a new
transport request
(Workbench), or
choose an existing
one.
The Development
class now has a
Request assigned.
46
Changing a request for a development class
Highlight the
transport request,
and then select
Change request
47
Executing the
Transport
48
Transport Organizer (SE09), Development System
Enter the User
Choose Workbench
requests for BW
transports
Select Modifiable for

Request status and
then Display
49
Releasing a Task
Select the task and

then Release directly
50
Creating Documentation
Enter any
documentation on this
transport that is
needed. Once finished
select Save and then
Back
51
Releasing the Request
Now that the Task has

been released
successfully, select
the Request and then
Release directly.
Make sure other
requests (with
necessary related
objects) have been
released before
52
Task and Request Released
Since both the Task

and Request have
been released
successfully, this can
now be transported to
the target system
Make sure that requests with dependent objects are released in the right order.
53
Import Transport Request (STMS), Target System
54
Import Queues
55
Import Queue
Import All (entire Import highlighted

queue) request
56
Transporting a Role
57
Transporting Roles
l Roles are customizing objects so you need a customizing request.
l Roles that are delivered in the SAP Business Content can be transported via
the Transport connection.
l Customer-defined Roles can also be transported manually using the role

maintenance (PFCG).
l Workbooks that are assigned to a role are transported in a BEx request, so

both the customizing request and the BEx request need to be transported in
order to have a valid link between role and workbook in the target system
58
Transporting Roles (RSOR)
59
Transporting a Customer-defined Role (PFCG)
Next, choose Transport role
First, select an existing Role
60
Information about Transporting Roles
61
Transporting Role objects
These options allow you to

transport Role objects along with
the Role
62
Additional Information
63
Standard Transport
System (automatic
transport connection)
64
Standard Transport System Activation in BW
n The developers should choose a development class and a request, immediately

when creating a new object. (automatic transport connection for all objects)
n Advantages:
u Maintenance with object collector not required
u Change authorizations via tasks
u Easier maintenance for several development classes
n To activate the standard transport system, you must set field TADIRPOPUP of
table RSADMINS for ID 'BW' to 'X'. Before Support Package 18 (2.0B) you
achieve this with the following small program:
UPDATE rsadmins SET tadirpopup = 'X'

WHERE customizid = 'BW'.
Enter the program in Transaction SE38 and execute it.

From Support Package 18 on, this will be changeable from the menu
(note 356018)
You want to activate the standard transport system in BW. In BW, new objects first are created
automatically as local with development class $TMP. Consequently, no dialog box is displayed first when
you create a new object in which you could write the object to a transport request. When you transport
the objects for the first time, these objects and dependent objects must be collected in the transport
connection of the Administrator Workbench first. A transportable development class is assigned after this
and the objects are written to a request.
This procedure has the advantage that first you need not take care of the transport during the development
of new scenarios. After the scenario has been completed , you only have to collect the objects that are
required in the production system in the transport connection and write them to a request. The objects
not required remain there as internal objects and are not transported. If you write all objects immediately
to requests, it can happen that test objects and productive objects are mixed on one request. In this case,
it is complicated to clean up the requests.
If you activate the standard transport system you dont have to use the object collector but you still have to
take care of releasing transport requests in the right order. Authorizations can be handled by tasks in the
standard way. The users might not have the authorizations to create requests /tasks, so they can only
change objects if the administrator has created a task for them. Especially when working with different
development classes the standard transport system makes correct assignments easier because you
decide your assignment for each single object.
65
(cont.)
l CAUTION!
l Only the newly created objects are recorded from now on. You might still
have to transport the old objects via the transport connection of the
Administrator Workbench.
66
Object Alterability
67
Changing Object Types
Use these settings for system that are nod modifiable. Afterwards, the specified
objects can then be changed despite the system settings.
More details and latest information in note 337950
68
Transport Strategy
69
Transport Strategy Considerations
l What is my system landscape?
l How many different projects are working on that system?
l How complex are my scenarios?
l Who is responsible for transports / development classes (central,

decentral)?
l Which kind of system (development, consolidation, production)?
l How can the transport of BEx objects be organized?
70
System Landscape
l In a standard three system landscape one development class may be

sufficient, transport using object collector
l In a complex landscape different objects might have to be transported to

different system (different development classes, transport layers). There are
typically some common objects that need to be transported to all systems
and some specific ones
71
Number of Projects on a System
l Basically the system landscape considerations also apply for projects
l You have to distinguish between common objects and project specific ones
l You may want to be prepared to split up into different systems later on (e.g.
for performance reasons)
72
Complexity of Scenarios
l In very complex scenarios dependencies of objects can also be complex
l Activating automatic transport connection ensures that no objects are

forgotten but the order of the imports is then very important
l The object collector helps you find the dependent objects but transport
requests may contain many objects
l In case of problems split up transports (into parts of the data flow)
73
Responsibility
l If you have complex scenarios / system landscape / several projects

organizing transport may be a crucial issue
l Central management may be necessary to decide
l Which object is assigned to which development class
l Which objects are collected in one transport request
l In which order and when do the transports take place
74
Type of System
l The above considerations are focussed mainly on development systems
l You may want to create some objects in the consolidation system in

exceptional cases. Activation of automatic transport connection for keeping
track of all such objects / changes may be a good approach
l In the productive system you typically dont create objects to be transported

but e.g. queries (ad hoc reporting). Using default BW setting (no automatic
transport connection) is usually the best option (independent of settings in
development or consolidation systems)
75
Transport of BEx Objects
l Since BEx Objects (once they are assigned to a transportable development

class) are transported in a special way there are special considerations:
l All changes of BEx objects (in one development class) in a certain period
are transported together (unless standard transport system is activated)
l Granularity of development classes for BEx objects is important for

flexibility in transports, e.g.
l On project level
l On data target level
l Several ones for each data target
l One for each query
l Transport management of BEx requests

l Agreement on when transport request is released
l Creation of a new one immediately after (or before) releasing the old
one
The only way of grouping BEx objects in a transport (after first transport) is by
development class. So you have to determine the granularity you need for
transporting BEx objects and set up development classes accordingly.
No changes to BEx objects are possible if
No BEx request exists
The old BEx request is released and no new one is created
A new BEx request is already assigned but the old one has not been
released
76
Trouble Shooting
77
Transport Problem when Saving Queries
l In the BEx Analyzer, a user attempts to save a query and receives the
following error:
n "The query could not be saved due to a problem in transport
l Check whether the BEx default transport request or the development

class-dependent transport request is maintained or released.
l The error only occurs for query objects which already have a
transportable development class.
78
Problems Creating Change Request
Objects already assigned to a transportable development class could

be locked (already contained in an unreleased request)
Expand tree and check change request column in BW transport

connection
As of SP 16 (BW 2.0B) a log is displayed with this information
More details in note 407485
79
Activation Problems After Import
Analyze transport protocol, check for error messages in after import

method
If objects are missing or not in the latest version include them and
the original one(s) in another transport (if they are locked release
transport requests)
If objects are not activated because of potential loss of data correct
error in original system (or delete data if applicable)
Try manual activation in target system (e.g. if table conversion is
necessary, if number range objects are missing)
Buffered (old) information might be used for activation (solved with
SP 14 for InfoObjects, SP17 for texts). Repeat import after buffer
synchronisation
Manual conversion of an InfoObject is only necessary if characteristics are deleted

from compounding or fields from text table, attribute changes are done automatically
More details in notes
125499 Activation error after transport of BW objects (manual conversion of tables
with SE14 might be necessary)
381924 The InfoObject import terminates (BRAIN049)
411574 Method execution with RSDG_AFTER_IMPORT_FOR_CORR
376173 Objects (texts) are missing after transport (though they have been imported)
80
Problems With Transported Workbooks
Workbooks (along with dependent views, web templates) are

located in BDS
Problems might be caused by BW objects or by BDS itself.
Note 315687, Old versions displayed after transport (BDS)

In BW 3.0 views, templates and items are transport objects (independent of
workbooks)
81
Problem with Source System Dependencies
Error messages: Data source doesnt exist or field not delivered

by source system might come up
Activate Data Source (again) from Business Content (if applicable) or
Transport DataSource (again)
Replicate DataSource
Import your transport again
In case of a file source system create another transport request

containing also the data source (select all)
More details in note 360951
82
Problems Transporting a DataSource
If a self-created DataSource is transported with RSA6 the extract-structure

is not automatically transported with the DataSource
(error message in target system: Only transparent tables and database
views can be extracted)
Find corresponding extract structure in table ROOSOURCE and include it
in a transport (TLOGO: R3TR TABL)
83
Additional Remarks
Hierarchies are considered data (not metadata)
So they can be loaded (normal staging)
They can not be transported
Currency exchange rates are also loaded from the source system(s),
not transported
84
Additional Remarks (2)
Assignments of reporting authorization objects to InfoCubes / ODS

objects and hierarchy authorizations need to be transported
manually in transaction RSSM
Press button (Transport) Additional Info
Choose the reporting authorization object(s) you want to transport

information for
Select hierarchy authorization(s) you want to transport if applicable
Create or choose a transport request for this information
85
Copyright 2001 SAP AG (All rights reserved)
n No part of this publication may be reproduced or transmitted in any form or for any purpose without the
express permission of SAP AG. The information contained herein may be changed without prior notice.
n Some software products marketed by SAP AG and its distributors contain proprietary software components
of other software vendors.
n Microsoft , WINDOWS, NT , EXCEL , Word, PowerPoint and SQL Server are registered trademarks of
Microsoft Corporation.
n IBM , DB2, OS/2, DB2/6000, Parallel Sysplex, MVS/ESA, RS/6000, AIX, S/390, AS/400, OS/390, and
OS/400 are registered trademarks of IBM Corporation.
n ORACLE is a registered trademark of ORACLE Corporation.
n INFORMIX-OnLine for SAP and Informix Dynamic ServerTM are registered trademarks of Informix Software
Incorporated.
n UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.
n Citrix, the Citrix logo, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, MultiWin and
other Citrix product names referenced herein are trademarks of Citrix Systems, Inc.
n HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C, World Wide Web
Consortium, Massachusetts Institute of Technology.
n JAVA is a registered trademark of Sun Microsystems, Inc.
n JAVASCRIPT is a registered trademark of Sun Microsystems, Inc., used under license for technology
invented and implemented by Netscape.
n SAP, SAP Logo, R/2, RIVA, R/3, SAP ArchiveLink , SAP Business Workflow, WebFlow, SAP EarlyWatch, BAPI,
SAPPHIRE, Management Cockpit, mySAP.com Logo and mySAP.com are trademarks or registered
trademarks of SAP AG in Germany and in several other countries all over the world. All other products
mentioned are trademarks or registered trademarks of their respe ctive companies.
86

CTS With SAP BW

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CTS With SAP BW

Uploaded by

Copyright:

Available Formats

Using the

Connecting Systems Executing the Transport

Object Versions Transporting a Role

Transports in the source system Standard Transport System

Transporting Objects in BW Object Alterability

BEx Objects Transport Strategy

Transporting BEx Objects Trouble Shooting

SAP AG 2002, Using the CTS with SAP BW 2

Development Consolidation Production

RFC RFC RFC

SAP AG 2002, Using the CTS with SAP BW 4

A typical system landscape consists of a development, consolidation and

Change and Transport System (CTS)

Transport Tools (low level programs: tp, R3trans)

SAP AG 2002, Using the CTS with SAP BW 5

The following activities have to be performed after an

SAP AG 2002, Using the CTS with SAP BW 6

SAP AG 2002, Using the CTS with SAP BW 7

RFC connection test

Transport directory check

Transport control program (tp) check

SAP AG 2002, Using the CTS with SAP BW 8

PI must be installed on R/3 (most current version recommended)

Transports only between R/3 systems or between BW systems.

Communication between R/3 and BW systems via RFC.

Default system setting: New BW objects are created as local

SAP AG 2002, Using the CTS with SAP BW 10

For source system specific objects a mapping

Different BW systems in the system landscape are connected to different

During transport source system specific objects (transfer rules) must be

This is done with a mapping table (RSLOGSYSMAP).

SAP AG 2002, Using the CTS with SAP BW 11

Before transfer structures can be transported between BW systems you

Example: In the system B2 you specify

SAP AG 2002, Using the CTS with SAP BW 12

Development Consolidation Production

RFC 2 RFC RFC

SAP AG 2002, Using the CTS with SAP BW 13

The BW development system is connected to the R/3 development system.

l Four object versions in BW:

l The Active version is the one exported in a transport request -

SAP AG 2002, Using the CTS with SAP BW 15

An upgrade of the Business Content does not affect

SAP AG 2002, Using the CTS with SAP BW 16

The objects of the Business Content are delivered in delivery version.

l All BW meta objects are activated by the common After

create activate change

SAP AG 2002, Using the CTS with SAP BW 17

All modifications made to BW meta objects are written to change requests

l DataSources have an automatic transport connection

l The application hierarchy needs to be tranported manually (note

l Dont forget to transport enhancements (user exits), check whether

SAP AG 2002, Using the CTS with SAP BW 19

Select DataSources to Transport

SAP AG 2002, Using the CTS with SAP BW 20

First, select DataSource -> Object directory

*Dev. class has not been maintained

Choose a transportable Dev. class

SAP AG 2002, Using the CTS with SAP BW 21

You can manually change the development class of a DataSource in the

First, select Source Systems

Then, choose a Source System

Finally, select DataSource overview to