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

Transcription

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

2 Overview Connecting Systems BEx Development Classes 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

3 Overview 3

4 Recommended System Landscape R/3 Development O1 Consolidation O2 Production O3 RFC RFC RFC BW Development B1 Consolidation B2 Production B3 SAP AG 2002, Using the CTS with SAP BW 4 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

5 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 architecture for BW is the same as for R/3. The same tools / programs are used. 5

6 CTS - Post Installation Activities The following activities have to be performed after an installation: Initialize CTO Create / Choose transport directory Configure transport control program (tp) Configure system landscape Configure transport layers and routes Check TMS SAP AG 2002, Using the CTS with SAP BW 6 6

7 Create transport layers / routes SAP AG 2002, Using the CTS with SAP BW 7 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

8 Checking TMS RFC connection test Transport directory check Transport control program (tp) check SAP AG 2002, Using the CTS with SAP BW 8 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 (TransactionSTMS) 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 availabilityof 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

9 Connecting Systems 9

10 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. SAP AG 2002, Using the CTS with SAP BW 10 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 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

11 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) SAP AG 2002, Using the CTS with SAP BW 11 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 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

12 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 SAP AG 2002, Using the CTS with SAP BW 12 12

13 Transport Process Development O1 Consolidation O2 Production O3 R/3 1 RFC 2 RFC RFC BW 3 Development B1 Consolidation B2 Production B3 SAP AG 2002, Using the CTS with SAP BW 13 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

14 Object Versions 14

15 Object Versions Four object versions in BW: 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 ) The Active version is the one exported in a transport request - make sure correct version is active before transporting! SAP AG 2002, Using the CTS with SAP BW 15 15

16 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) delivery from SAP install BC 2nd delivery from SAP nd install (match) BC SAP AG 2002, Using the CTS with SAP BW 16 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

17 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) export Target system create import activate change M(odified) A(ctive) After import method change SAP AG 2002, Using the CTS with SAP BW 17 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

18 Transports in the source system 18

19 Transports in the source system For BW 2.0 there are only two objects (DataSource and application hierarchy for data sources) to be transported on the source system side DataSources have an automatic transport connection The application hierarchy needs to be tranported manually (note ) Don t forget to transport enhancements (user exits), check whether project is active SAP AG 2002, Using the CTS with SAP BW 19 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 ,

20 Manual Transport (of Several DataSources, RSA6) is also possible Select DataSources to Transport SAP AG 2002, Using the CTS with SAP BW 20 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

21 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 SAP AG 2002, Using the CTS with SAP BW 21 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

22 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 SAP AG 2002, Using the CTS with SAP BW 22 22

23 Replicate DataSources SAP AG 2002, Using the CTS with SAP BW 23 In this case only the selected DataSource will be updated from the source system. 23

24 Transporting Objects in BW 24

25 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). SAP AG 2002, Using the CTS with SAP BW 25 Details about system copies of BW systems are described in note

26 SAP BW Metadata Visualized: Flow of Information source system transfer rule InfoSource update rule infocube query workbook role SAP AG 2002, Using the CTS with SAP BW 26 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

27 Maintain Source system assignment for object collector SAP AG 2002, Using the CTS with SAP BW 27 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 don t want to transport for all source systems. 27

28 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. SAP AG 2002, Using the CTS with SAP BW 28 28

29 Transport Object Selection Choose how you want to view the objects: Data Targets by InfoAreas InfoObjects by Application Component InfoSources by Application Component Roles Object Types Development Classes SAP AG 2002, Using the CTS with SAP BW 29 29

30 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) SAP AG 2002, Using the CTS with SAP BW 30 30

31 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: Last changed on/by Last changed by Transport request Transport order holder Development class SAP AG 2002, Using the CTS with SAP BW 31 31

32 Transporting BW Objects Select Transport objects SAP AG 2002, Using the CTS with SAP BW 32 32

33 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 SAP AG 2002, Using the CTS with SAP BW 33 Create and use your own development classes, don t use SAP development classes. 33

34 Check Transport Status Check status of transport SAP AG 2002, Using the CTS with SAP BW 34 If there are dependent objects already written to other transport requests make sure those other requests are released in time. 34

35 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!) AWB objects are handled in the standard way For BEx objects there is a special implementation as follows SAP AG 2002, Using the CTS with SAP BW 35 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

36 Transport of BEx Objects 36

37 BEx Objects BEx objects relevant to transport are: Workbooks Queries Structures Restricted Key Figures Calculated Key Figures Variables SAP AG 2002, Using the CTS with SAP BW 37 From 3.0A on we have additional BEx Objects: Templates Query Views Items 37

38 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. There is one CTS Request, for example, Standard CTS Request" where changes to the BEx objects can be recorded. You can also specify the CTS Request by Development class. The end user is not prompted for the Request at all. SAP AG 2002, Using the CTS with SAP BW 38 38

39 Assigning Changes of BEx Objects The system has a two level process for choosing the CTS Request for recording the changes. First, the system looks for the CTS Request which is assigned to the development class of the BEx object. If it s not found then use the Standard CTS Request. SAP AG 2002, Using the CTS with SAP BW 39 39

40 Setting Up the BEx Development Classes 40

41 Maintain Request BEx Select Request BEx If this has already been maintained, then this message appears SAP AG 2002, Using the CTS with SAP BW 41 This button will no longer be available in BW 3.0 (see below) 41

42 Change the Standard BEx transport request To change the Standard BEx transport request, select BEx development classes SAP AG 2002, Using the CTS with SAP BW 42 42

43 Reassign Standard BEx transport request The Standard BEx transport request is visible here. To change this, select Assign / delete SAP AG 2002, Using the CTS with SAP BW 43 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

44 New transport request for BEx Create a new transport request, or choose an existing one. SAP AG 2002, Using the CTS with SAP BW 44 44

45 Add a Development class Select Insert row Then Enter the development class SAP AG 2002, Using the CTS with SAP BW 45 45

46 Request Assigned to Development class Create a new transport request (Workbench), or choose an existing one. The Development class now has a Request assigned. SAP AG 2002, Using the CTS with SAP BW 46 46

47 Changing a request for a development class Highlight the transport request, and then select Change request SAP AG 2002, Using the CTS with SAP BW 47 47

48 Executing the Transport 48

49 Transport Organizer (SE09), Development System Enter the User Choose Workbench requests for BW transports Select Modifiable for Request status and then Display SAP AG 2002, Using the CTS with SAP BW 49 49

50 Releasing a Task Select the task and then Release directly SAP AG 2002, Using the CTS with SAP BW 50 50

51 Creating Documentation Enter any documentation on this transport that is needed. Once finished select Save and then Back SAP AG 2002, Using the CTS with SAP BW 51 51

52 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 SAP AG 2002, Using the CTS with SAP BW 52 52

53 Task and Request Released Since both the Task and Request have been released successfully, this can now be transported to the target system SAP AG 2002, Using the CTS with SAP BW 53 Make sure that requests with dependent objects are released in the right order. 53

54 Import Transport Request (STMS), Target System SAP AG 2002, Using the CTS with SAP BW 54 Make sure that requests with dependent objects are released in the right order. 54

55 Import Queues SAP AG 2002, Using the CTS with SAP BW 55 Make sure that requests with dependent objects are released in the right order. 55

56 Import Queue Import All (entire queue) Import highlighted request SAP AG 2002, Using the CTS with SAP BW 56 Make sure that requests with dependent objects are released in the right order. 56

57 Transporting a Role 57

58 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 SAP AG 2002, Using the CTS with SAP BW 58 58

59 Transporting Roles (RSOR) SAP AG 2002, Using the CTS with SAP BW 59 59

60 Transporting a Customer-defined Role (PFCG) Next, choose Transport role First, select an existing Role SAP AG 2002, Using the CTS with SAP BW 60 60

61 Information about Transporting Roles SAP AG 2002, Using the CTS with SAP BW 61 61

62 Transporting Role objects These options allow you to transport Role objects along with the Role SAP AG 2002, Using the CTS with SAP BW 62 62

63 Additional Information SAP AG 2002, Using the CTS with SAP BW 63 63

64 Standard Transport System (automatic transport connection) 64

65 Standard Transport System Activation in BW The developers should choose a development class and a request, immediately when creating a new object. (automatic transport connection for all objects) Advantages: Maintenance with object collector not required Change authorizations via tasks Easier maintenance for several development classes 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 ) SAP AG 2002, Using the CTS with SAP BW 65 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 don t 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

66 (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. SAP AG 2002, Using the CTS with SAP BW 66 66

67 Object Alterability 67

68 Changing Object Types SAP AG 2002, Using the CTS with SAP BW 68 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

69 Transport Strategy 69

70 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? SAP AG 2002, Using the CTS with SAP BW 70 70

71 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 SAP AG 2002, Using the CTS with SAP BW 71 71

72 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) SAP AG 2002, Using the CTS with SAP BW 72 72

73 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) SAP AG 2002, Using the CTS with SAP BW 73 73

74 Responsibility If you have complex scenarios / system landscape / several projects organizing transport may be a crucial issue Central management may be necessary to decide Which Which In object is assigned to which development class objects are collected in one transport request which order and when do the transports take place SAP AG 2002, Using the CTS with SAP BW 74 74

75 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 don t 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 developmentor consolidation systems) SAP AG 2002, Using the CTS with SAP BW 75 75

76 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. On On Several One project level data target level ones for each data target for each query Transport management of BEx requests Agreement Creation on when transport request is released of a new one immediately after (or before) releasing the old one SAP AG 2002, Using the CTS with SAP BW 76 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

77 Trouble Shooting 77