You are on page 1of 13

How to...

Manage BW Transports

SAP BI Practice
How to Paper
Applicable Releases: All releases Revised: September 2003

11/05/07

HOW TO MANAGE BW TRANSPORTS 1 2 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 2.10 2.11 2.12 2.13 3 3.1 3.2 4 4.1 4.2 BUSINESS SCENARIO .................................................................................................................. 3 GENERAL ....................................................................................................................................... 3 Transport Responsibility..........................................................................................................................3 Terminology ..............................................................................................................................................4 Best Practices ............................................................................................................................................4 Sequence of transports .............................................................................................................................6 Transport Collection & Settings..............................................................................................................7 Prior to Exporting a Transport from Development...............................................................................9 Exporting a transport from Development ............................................................................................10 Before importing a transport into Test.................................................................................................10 Importing a transport into Test.............................................................................................................10 Prior to importing a transport to Production ......................................................................................11 Importing a transport into Production (CTO Admin) ........................................................................11 Troubleshooting ......................................................................................................................................11 Tips ..........................................................................................................................................................12 INITIAL TRANSPORT................................................................................................................... 12 Environment Preparation for Test and Production prior to initiating transports ...........................12 Administrative Preparation ...................................................................................................................13 ON-GOING TRANSPORTS .......................................................................................................... 13 Administrative Preparation ...................................................................................................................13 CTO Approval & Migration Process Flow .........................................................................................13

BW TRANSPORTS

PAGE 2 OF 13 - 11/05/07

HOW TO MANAGE BW TRANSPORTS

1 Business Scenario
You want to develop a strategy and instructions document for performing transports in BW. The objective of this document is to provide guidelines on how to perform transports in BW and how to manage them. This material is organized into 3 categories: General - This section includes information that applies to both initial and on-going transports Initial Transports - There are additional steps to prepare for transporting to a new BW environment during the life of a project. In some cases, some of these steps are required for a project sharing an existing BW environment if new connections are added. The audience of this section are new projects getting ready to mass migrate to Test and Production. On-Going Transports - Once a project is implemented, there are additional processes and change control procedures to follow. The audience of this section is DW support team.

2 General
2.1 Transport Responsibility
A. The transport responsibilities for Development/Test must be designated to an experienced BW developer/analyst during the project and post implementation. His/Her backup is the CTO Administrator. For objects that are shared by multiple projects/applications within the same BW landscape, the primary responsibility for all transport activities MUST BE assigned to the CTO Administrator. The responsibilities include: Collecting the objects in a transport Reviewing the transports with CTO Administrator Exporting from Development and Importing to the Test environment Coordinating with the R/3 CTS Transports Analyzing Transport logs Communicating the sequence, errors encountered and resolution to the CTO Administrator, who will track this information in the CTO Tracking Log.

BW TRANSPORTS

PAGE 3 OF 13 - 11/05/07

HOW TO MANAGE BW TRANSPORTS B. The transport responsibility for Production is always designated to the CTO Administrator during the project and post implementation. This role has also been called Transport Coordinator. For consistency, the remainder of this document would refer to this role as CTO Administrator. The responsibilities include: Coordinating the collection of the objects in a transport Coordinating the export from Development and Import to the Test, which may include assistance with transport log analysis Coordinating with the R/3 CTS Transports Importing the transport into Production Analyzing Production Transport logs Maintaining the CTO Tracking Log to include the sequence, errors encountered and resolution Coordinating with multiple applications' transport requirements in the BW landscape.

These responsibilities become even more important as BW instances are shared across multiple applications and projects.

2.2

Terminology
CTS - R/3 Change and Transport System CTO - BW Change and Transport Organizer CTO Tracking Log - an Excel spreadsheet to keep track of the sequence of exports/imports, dependencies, errors and corrections.

2.3

Best Practices
These best practices are based on lessons learned from past projects. Always... 1. Do not start transporting until the development is complete and stable. 2. Leave all objects as $TMP (local objects) until it is absolutely ready to transport 3. Delete any obsolete objects in Development, so that they would not accidentally get transported to Test or Production. 4. Transport objects in the recommended sequence or errors may result. Ensure a successful import of the object before transporting the next set of dependent objects. 5. Organize the contents of the transports To facilitate transporting the objects in the right sequence To keep the CTO small To make error debugging easier

BW TRANSPORTS

PAGE 4 OF 13 - 11/05/07

HOW TO MANAGE BW TRANSPORTS 6. Import dependent transports into production in the same sequence as they were imported into Test, otherwise the results in the Production environment would not reflect what was user tested and accepted in Test environment. Import into Production even those transports that ended with errors in Test. There may be some exceptions that will affect the sequence. 7. Keep track of transport errors in Test and the action steps taken to correct them in the CTO Tracking Log. These action steps will come in very handy when importing those same transports into Production. 8. Avoid making any changes directly in Test or Production. All changes should be made in Development and transported. 9. Verify that objects are reflected in the transport. This should be jointly performed by the developer and CTO Administrator. 10. Assign all infoobjects to an InfoobjectCatalog. It is recommended to split out the Infoobject Catalog by Subject Area by Characteristics and Key Figures. 11. Verify that the R/3 transports that are required for the BW transports are successfully imported and tested with RSA3 and replicate data sources in BW, prior to initiating the BW transports. 12. Make note of R/3 dependencies in the CTO Tracking Log. This would assist in the grouping of BW CTOs that can be transported and breakpoints to wait for the R/3 transport to occur. 13. Create Development Class as follows: A single development class is needed for all variables (if there are multiple projects in the same BW instance, they all share the same development class for variables.) A single development class is needed for all backend objects. Development classes can be assigned as follows depending on the frontend design to manage BEX (frontend) objects: Separate development class for each Infocube, ODS or Multicube Development class to group Infocubes and ODS Development class to group Multicubes and the Infocubes that make up the multicube.

Just remember that you can assign multiple development classes to 1 CTO, but you cannot assign 1 development class to more than 1 CTO. 14. Use a CTO naming standard to manage CTOs if BW instances are shared by multiple projects and developers are responsible for creating their own CTO's. e.g. : Format of the CTO request = Project: Description. Where Description must be as descriptive as possible in order to remember what the CTO includes. Ask yourself "Will I remember what I meant by this a month from now?"

BW TRANSPORTS

PAGE 5 OF 13 - 11/05/07

HOW TO MANAGE BW TRANSPORTS

2.4

Sequence of transports
Not all transports will have every type of BW objects listed below. However, if applicable, the BW objects should be transported in the following order: R/3 - R/3 objects must be transported in a CTS before BW transports can begin Development Class - for backend objects Developer Security Roles - End user roles for projects can be transported later. Application Component - Including InfoAreas Custom Tablespace/Custom Data Class - DBA creates custom tablespaces and Basis' data class entries must be transported InfoObject (only object definition, no infosource or rules) & InfoObject Catalogs Data Sources. Remember to replicate datasources prior to importing objects listed below. InfoSource - Master data and Text Data Targets for Transaction Data Cubes and ODSs. This can potentially be grouped with the two following items (infosources transaction data). InfoSource - Transaction Data ODS (includes Update Rules, Communication Structures, Transfer Rules, Transfer Structures, Infopackages) InfoSource - Transaction Data Infocubes (includes Update Rules, Communication Structures, Transfer Rules, Transfer Structures, Infopackages) Multicube Development Class - for frontend objects Infoset Queries End User Security Roles Variables Customer exit code Workbooks/Queries/Structures/Calculated Key Figures/Restricted Key Figures (in the correct development class!) Workbook folders (needs to be transported whenever NEW workbooks are created). Jump Targets Process Chains

If there is only one project in its own BW landscape then the above grouping of objects can be simplified into 5 major categories. The purpose of the above detailed grouping is to have sufficient granularity to manage transports across multiple applications if their project life cycle and transport schedule or readiness is different. R/3 Infoobjects Backend

BW TRANSPORTS

PAGE 6 OF 13 - 11/05/07

HOW TO MANAGE BW TRANSPORTS Bex query objects including variables Roles and workbooks

2.5

Transport Collection & Settings


Use Transport Connection from the Administrator Workbench in the Development instance. 1. To collect InfoObjects in InfoObject catalogs, ensure the setting is as follows: Grouping = 'only necessary objects' Note: If grouping = 'in dataflow before', it would bring in transfer rules. Note: If grouping = 'in dataflow afterwards', it would bring in infocubes.

Collection Mode = 'start manual collection'

2. To collect Master data infosources, ensure the setting is as follows: Grouping = 'in dataflow before' Collection Mode = 'start manual collection' Verify that you see transfer structures, transfer rules and infopackages. You may choose not to transport InfoPackages and just create them manually in production, or link their transport more closely with that of process chains instead. Note: if an infosource refers to an infoobject with its own infosource, it will nest the transfer rules. Note: it may show previously collected Infoobjects in another CTO. That CTO would have to be imported first There is no collector for Master Data InfoSources. The best way to collect these is to 1) Collect the InfoObject normally (Only Necessary). 2) Later, in another CTO, re-collect it again In Data Source Before (which will get your transfer rules, etc). 3. To collect ODS/Infocubes and transaction infosources, ensure the setting is as follows: Grouping = 'in dataflow before' Collection Mode = 'start manual collection' Verify that you see ODS, infocube, communication structures, infopackages, infosource, transfer structure, transfer rules, routines, update rules

4. To collect Infosets & InfoSet queries, ensure the setting is as follows: Grouping = 'only necessary objects'

BW TRANSPORTS

PAGE 7 OF 13 - 11/05/07

HOW TO MANAGE BW TRANSPORTS Collection Mode = 'start manual collection'. Infoset queries should be collected after Infosource. The grouping may seem backwards, since infosource comes before infoset query. First collect the InfoSet ('only necessary objects') and then collect the InfoSet queries with the same setting.

5. To collect Workbooks/Queries, ensure the setting is as follows: Grouping = 'only necessary objects' Collection Mode = 'start manual collection' Make sure that the transport is created for the appropriate development class (this is only for making changes). When using the collector to collect objects, it doesn't look for a CTO assigned to the right development class. If a table entry already exists for that development class with an old transport #, you must first delete and re-add the development class with the new transport #. Verify that objects (queries, calculated key figures, restricted key figures) conform to naming standards.

6. To collect Jump Targets (RRI), Create a workbench transport via SE09 or SE01 Use the backend development class. Go into BEX query or query jump targets. Need to know the query to jump from or the Infocube to jump from.

7. To collect Application Hierarchy, From RSA1, go to the drop down menu: 'Tools' --> ' Hierarchy Transport' --> 'Application Hierarchy'

8. Miscellaneous Notes: Drag the objects over from left to right in the Transport Connection screen. Be careful when you collapse and expand the tree in the collected area. Sometimes check boxes can revert to earlier setting if you use collection mode = 'collect automatically'. If needed, you can click on a tree node and right click to say 'do not transport any below'. Objects are not locked until they are added to a transport. Objects are not added to a transport until you click the transport truck. Security Roles require 'customizing request'

BW TRANSPORTS

PAGE 8 OF 13 - 11/05/07

HOW TO MANAGE BW TRANSPORTS Workbook Folders require 'customizing request'. Folders are roles without authorization attached to them. Backend objects require 'workbench request' Frontend objects require 'workbench request', assigned to a development class

Customizing and Workbench request can be created via transaction SE09. For frontend objects, first create a workbench request via SE09 and make sure a workbench task with your name exists under it, then go to the transport connection and assign the CTO to the development class via the BEX Development Classes icon. NOTE: Do not use the 'BEx Request' icon v.s. the 'BEx Development Class' icon to assign the development class, as it creates a GENERIC BEx request that all frontend changes are saved to. New objects would prompt for a development class Followup on any errors when adding the collected objects into a transport.

2.6

Prior to Exporting a Transport from Development


1. Verify the contents of the transport in SE09 or SE01. This is the responsibility of the developer. The CTO administrator cannot know everything that the developer is working on. If using the collector, it is still a good idea to go back to SE09/SE01 to verify the contents. 2. If objects are in the wrong CTO or need to move to another CTO, in order to manage the sequence of transports, delete the objects one at a time with SE09 or SE01 or you can also do mass deletes via SE03 (request help if you have never done this before - it is not intuitive). Once deleted, "touch" the object (i.e. add a character to the name, save it, delete the character and then save it, and activate the object). This would prompt for a CTO request, and you can assign the correct transport #. You can also re-collect the object and assign to the correct CTO. NOTE: Deletions from CTOs are not to be taken lightly. It is recommended that only few people, with extensive experience in CTO, manage these deletions. 3. In the event that you need to copy the contents of one transport to another, Hi-lite the new transport From the drop down menu: 'Request/Task' (top upper left of the SE09 screen), select Object List --> Include Object. Specify the source transport from which to copy the contents.

4. In the event that you need to manually add objects outside of the Transport Collector, use transaction SE03 (this is not recommended unless you know what you are doing and understand the dependencies of objects). 5. Typically, for the initial transport, the CTO Administrator is the owner of the tasks. However, subsequent transports may be best released by the developer. You can have multiple tasks to multiple developers within one transport. Note: A task cannot be released if there is nothing assigned to it. 6. Each transport can have "attributes" and/or "documentation" assigned to it. You can use this to explain CTO contents, dependencies, etc. for easy reference later when you are ready to transport to the Production instance.

BW TRANSPORTS

PAGE 9 OF 13 - 11/05/07

HOW TO MANAGE BW TRANSPORTS

2.7

Exporting a transport from Development


1. After all the tasks within a transport are documented and released, the transport can be released or exported via SE09/SE01. 2. Always review the transport logs for errors. Return codes of 0 or 4 are good and follow-up for any returncode 4 is recommended (these indicate impact like deactivation of update rules due to your CTO, etc.). Anything higher must be followed-up.

2.8

Before importing a transport into Test


Log on to the Test Instance. 1. Verify data source exists. If not, replicate data source. For new data source, check R/3 ROOSOURCE to know which node. 2. Make sure R/3 transports have been successfully imported in the Test environment. Check returncodes in the CTS and check datasources additionally by running RSA3. 3. Run Replication for data source/source system if there have been changes on the R/3 side since the last replication; otherwise, BW will be out of sync with R/3 and transports could fail. Likewise for BW source system.

2.9

Importing a transport into Test


1. Use standard functionality for imports. To keep track of them, list open transports and transports with condition code 8. Note - there is no difference in the appearance of transports with a return code of 8. It is up to you to keep track of these, as they are handled differently on the 2nd (or higher) attempt. 2. Select the desired transport and click on truck button to import. You can either hi-lite several transports and it would import them in the sequence it was released or do single imports, line at a time. 3. Always review the transport logs for errors. Return codes of 0 or 4 are good. A return code of 8 means the transport ended with errors - some of the objects may have been imported, but something is missing. This must be followed up on to ensure all objects are transported. A return code of 12 means the import was cancelled. Anything higher must also be followed-up. 4. The import time in the CTO Tracking Log is maintained by the CTO Admin. If the import failed, the symptoms and the correction taken will be noted in the CTO Tracking Log, as well. You will be extremely grateful that this is done now, so that importing into Production will be much easier. 5. If a transport has to be re-imported, make note of the sequence and keep the CTO Admin informed if sequencing changes are warranted for import to Production. These changes to the sequences are stored in the CTO Tracking Log by the CTO Admin.

BW TRANSPORTS

PAGE 10 OF 13 - 11/05/07

HOW TO MANAGE BW TRANSPORTS

2.10 Prior to importing a transport to Production


1. Repeat the steps of 'Prior to importing a transport to Test' in the production environment. 2. Ensure that users have tested and accepted the changes in Test and the approval from the business has been documented. 3. Designated person must now 'Approve' the transports in the Test environment. (We can still have blanket approval from the business, but the designated approver has to physically approve the CTO's for import, this is a technical QA action: Select the desired transport and click on the green 'approved' checkmark. )

2.11 Importing a transport into Production (CTO Admin)


1. Check the CTO Tracking Log on import problems encountered during Test, and corrective steps to prevent any surprises in Production. 2. Use standard functionality in the Production instance to import. 3. Import in the same sequence as how the transports were imported into Test. However, if a transport that erred in Test was followed by a correcting transport and then the errored transport was re-imported successfully, the order into production can be reversed in order to prevent the error from occurring. 4. Always review the transport logs for errors. Return codes of 0 or 4 are good. A return code of 8 means the transport ended with errors - some of the objects may have been imported, but something is missing. This must be followed up on to ensure all objects are transported. A return code of 12 means the import was cancelled. Anything higher must also be followed-up. Note the import time in the CTO Tracking Log.

2.12 Troubleshooting
Below are some major errors and solutions to resolve. 1. You get an error that the Development system does not exist as a source system. Solution: RSLOGSYSMAP is not updated which must be done prior to importing the first transports. 2. An object is missing in the target system. Solution: Collect the missing object using the transport connection, transport it into the target system and reimport the failed transport or recreate it as a new transport. 3. A transport does not activate all the objects even though they are in a valid state. Solution: An error may have occurred during Method execution or a conversion of a table was needed. Make sure that the objects are in a valid state and execute program RSDG_AFTER_IMPORT_FOR_CORR which executes the method execution step of the transport again. Choose only the object type of the inactive object. 4. An ODS object does not activate.

BW TRANSPORTS

PAGE 11 OF 13 - 11/05/07

HOW TO MANAGE BW TRANSPORTS Solution: A reference to a unit may have changed and the table needs to be converted or data deleted before the change can be imported correctly.

2.13 Tips
Some helpful programs to resolve errors (i.e. to activate an object if it is not activated correctly after method execution) RSDG_AFTER_IMPORT_FOR_CORR - Executes the method execution again for a transport (no need to reimport) RS_COMSTRU_ACTIVATE_ALL - Activates communication structure RS_TRANSTRU_ACTIVATE_ALL - Activates transfer rules RSDG_IOBJ_ACTIVATE - Activates Info object RSDG_CUBE_ACTIVATE - Activates Info cube RSDG_ODSO_ACTIVATE - Activates ODS object RSDG_IOBJ_REORG - Repair InfoObjects RSDG_IOBJ_REORG_TEXTS - Reorganization of texts for InfoObjects RSDG_MPRO_ACTIVATE - Activating MultiProviders RSDG_REPAIR_NUMBER_RANGES - Repairing characteristics with inconsistent number ranges

3 Initial Transport
3.1 Environment Preparation for Test and Production prior to initiating transports
1. Request Basis to set up R/3 connections, BW connections, DBConnect, and/or DBLink connections. 2. Create Source System 3. Update source system mapping table (RSLOGSYSMAP) 4. Update source system id (RSSOURSYSTEM) 5. Perform Replicate Data Source for each new source system 6. Set up any Global Parameters (e.g. permitted characters) 7. Execute ABAP program rsdg_objnumg_create_interval once in Test and Production before you begin any Transport Activities, otherwise transports will fail because time dependent fields will not be buffered. 8. Inform Basis of any upcoming mass transport activities to ensure sufficient resources. 9. Consider requesting a backup of the environment

BW TRANSPORTS

PAGE 12 OF 13 - 11/05/07

HOW TO MANAGE BW TRANSPORTS

3.2

Administrative Preparation
1. Request approval from the business for the mass migration of transports for project implementation. This prevents having to get business approval for each individual transport during this period of time. 2. Request transport role be granted to the designated CTO Administrator 3. Do not under-estimate the effort to do initial transport migration for a project implementation.

4 On-Going Transports
This section describes the application change control process once a project has implemented and the support has transitioned to the support organization.

4.1

Administrative Preparation
1. Transition transport responsibilities from project to support 2. Request Access from Basis to do imports and approvals 3. Request transport role be granted to the designated CTO Administrator 4. Remove blanket approval for mass migration

4.2

CTO Approval & Migration Process Flow

The specific process depends highly on the organizations structure and division of responsibilities. Make sure the process is well documented before transitioning CTO to the support organization. Pay attention: There may be Audit requirements in how approvals are granted once the system is live.

BW TRANSPORTS

PAGE 13 OF 13 - 11/05/07