CTS With SAP BW

Using the Corrections and Transport System (CTS) with SAP BW
Overview Connecting Systems Object Versions Transports in the source system Transporting Objects in BW BEx Objects Transporting BEx Objects
BEx Development Classes Executing the Transport Transporting a Role Standard Transport System Object Alterability Transport Strategy Trouble Shooting
SAP AG 2002, Using the CTS with SAP BW 2
Overview
Recommended System Landscape
Development O1
Consolidation O2
Production O3
R /3
RFC RFC RFC
BW
Development B1 Consolidation B2 Production 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.
SAP TMS - Architecture and Terms
Change and Transport System (CTS)
Transport Organizer (CTO)
Transport 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.
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
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.
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.
Connecting Systems
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
Development O1
Consolidation O2
Production O3
R /3
1
RFC
2 3
RFC
RFC
BW
Development B1
Consolidation B2
Production 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
Four object versions in BW:

n n n n D - SAP Delivered version M - Modified or Changed version A - Active version T - temporary version for source system dependent objects (like M-Version, details in note 411574)
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) A(ctive) D(elivery) 1 1
delivery from SAP
1 1
1 1 1 1
1 1 1 1 2 2
2 2 1 1 2 2
2nd install (match) BC
2 2 2 2 2 2
1 1
install BC
1 1
2nd delivery 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

All BW meta objects are activated by the common After Import Method RS_AFTER_IMPORT
Source system
M(odified) A(ctive)
create
1 1
1 1 1 1
2 2 1 1
export
activate change
import
Target system
M(odified) A(ctive)
1 1 3 3
1 1 1 1
change
4 4 1 1
After import method
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
In the menu Grouping you can determine how many objects should be taken into consideration. The groupings summarize all the objects of an area.
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 system
transfer rule
InfoSource
update rule
infoCube
query
workbook
role
The graphic is embedded in an HTML page and encoded in VML (XML based Vector Markup Language). VML is supported by Internet Explorer 5 and other vendors. It is not available in IE 4. 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
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
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 several objects
3. Write to transport request
New Objects (Development Class $TMP) are marked automatically 2. Drag & Drop objects (or use context menu)
30
Transport Information
Objects that are not yet assigned to a transportable development class are automatically flagged for transport Other objects can be flagged manually if e.g. import failed and transport should be redone (might already be locked by other requests, though) 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 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
BEx objects relevant to transport are:

n n n n Workbooks Queries Structures 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
For BEx objects, the first transport works as described above. 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.
The end user is not prompted for the Request at all.
38
Assigning Changes of BEx Objects
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 queue)
Import highlighted request
56
Transporting a Role
57
Transporting Roles
Roles are customizing objects so you need a customizing request. Roles that are delivered in the SAP Business Content can be transported via the Transport connection. Customer-defined Roles can also be transported manually using the role maintenance (PFCG). 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 u
Maintenance with object collector not required 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.)
CAUTION! 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
What is my system landscape? How many different projects are working on that system? How complex are my scenarios? Who is responsible for transports / development classes (central, decentral)? Which kind of system (development, consolidation, production)? How can the transport of BEx objects be organized?
70
System Landscape
In a standard three system landscape one development class may be sufficient, transport using object collector 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
Basically the system landscape considerations also apply for projects You have to distinguish between common objects and project specific ones You may want to be prepared to split up into different systems later on (e.g. for performance reasons)
72
Complexity of Scenarios
In very complex scenarios dependencies of objects can also be complex Activating automatic transport connection ensures that no objects are forgotten but the order of the imports is then very important The object collector helps you find the dependent objects but transport requests may contain many objects In case of problems split up transports (into parts of the data flow)
73
Responsibility
If you have complex scenarios / system landscape / several projects organizing transport may be a crucial issue Central management may be necessary to decide
l
Which object is assigned to which development class Which objects are collected in one transport request In which order and when do the transports take place
74
Type of System
The above considerations are focussed mainly on development systems 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 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
Since BEx Objects (once they are assigned to a transportable development class) are transported in a special way there are special considerations: All changes of BEx objects (in one development class) in a certain period are transported together (unless standard transport system is activated) Granularity of development classes for BEx objects is important for flexibility in transports, e.g.
l
On project level On data target level Several ones for each data target One for each query
Transport management of BEx requests

l
Agreement on when transport request is released 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
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
Check whether the BEx default transport request or the development class-dependent transport request is maintained or released. 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 n n n n n n n n n n 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. Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors. Microsoft , WINDOWS, NT , EXCEL , Word, PowerPoint and SQL Server are registered trademarks of Microsoft Corporation. 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. ORACLE is a registered trademark of ORACLE Corporation. INFORMIX-OnLine for SAP and Informix Dynamic ServerTM are registered trademarks of Informix Software Incorporated. UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group. Citrix, the Citrix logo, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, MultiWin and other Citrix product names referenced herein are trademarks of Citrix Systems, Inc. HTML, DHTML, XML, XHTML are trademarks or registered trademarks of W3C, World Wide Web Consortium, Massachusetts Institute of Technology. JAVA is a registered trademark of Sun Microsystems, Inc. JAVASCRIPT is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape. 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

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

CTS With SAP BW

Hochgeladen von

Copyright:

Verfügbare Formate

Using the Corrections and Transport System (CTS) with SAP BW

SAP AG 2002, Using the CTS with SAP BW 2

Recommended System Landscape

SAP AG 2002, Using the CTS with SAP BW 4

SAP TMS - Architecture and Terms

Change and Transport System (CTS)

Transport Organizer (CTO)

Transport Management System (TMS)

Transport Tools (low level programs: tp, R3trans)

SAP AG 2002, Using the CTS with SAP BW 5

CTS - Post Installation Activities

The following activities have to be performed after an installation:

SAP AG 2002, Using the CTS with SAP BW 6

Create transport layers / routes

SAP AG 2002, Using the CTS with SAP BW 7

SAP AG 2002, Using the CTS with SAP BW 8

SAP AG 2002, Using the CTS with SAP BW 10

Maintain Source System Mapping (Target System)

SAP AG 2002, Using the CTS with SAP BW 11

Maintain Source System Mapping (Target System)

SAP AG 2002, Using the CTS with SAP BW 12

SAP AG 2002, Using the CTS with SAP BW 13

Four object versions in BW:

SAP AG 2002, Using the CTS with SAP BW 15

2nd delivery from SAP

SAP AG 2002, Using the CTS with SAP BW 16

Metadata: Versions and Transport

After import method

SAP AG 2002, Using the CTS with SAP BW 17

Transports in the source system

Transports in the source system

SAP AG 2002, Using the CTS with SAP BW 19

Manual Transport (of Several DataSources, RSA6) is also possible

Select DataSources to Transport

SAP AG 2002, Using the CTS with SAP BW 20

Data Source Maintenance (RSO2): Change Object Directory Entry Manually

Choose a transportable Dev. class

SAP AG 2002, Using the CTS with SAP BW 21

Replicate DataSources in BW (Target System)

First, select Source Systems

SAP AG 2002, Using the CTS with SAP BW 22

SAP AG 2002, Using the CTS with SAP BW 23

SAP AG 2002, Using the CTS with SAP BW 25

Details about system copies of BW systems are described in note 184754.

SAP BW Metadata Visualized: Flow of Information

SAP AG 2002, Using the CTS with SAP BW 26

Maintain Source system assignment for object collector

SAP AG 2002, Using the CTS with SAP BW 27

SAP AG 2002, Using the CTS with SAP BW 28

Transport Object Selection

Choose how you want to view the objects:

SAP AG 2002, Using the CTS with SAP BW 29

1. Select one or several objects

3. Write to transport request

SAP AG 2002, Using the CTS with SAP BW 30

SAP AG 2002, Using the CTS with SAP BW 31

Select Transport objects

SAP AG 2002, Using the CTS with SAP BW 32

Transport BW Objects For the First Time

Create a request or choose an existing one

SAP AG 2002, Using the CTS with SAP BW 33

Check Transport Status