SAP BW Transport

SAP BW Transport Best Practices

 In this entry I will be discussing how to properly migrate your SAP BW objects from one environment to another.  Migration errors are extremely frustrating to both the developer and the basis team who is moving the transports.  It requires a good amount of rework and explanation as to why your objects went in with errors to another environment.  In this article we will go into detail as to how transports can effectively be migrated without issues from a lower environment to a test or production environment.

Tip #1 – Transports in the BW environment can only contain like objects. 

Transport #DKR0001 contains two InfoObjects and no other object types that could potentially cause an error.

Transport #DKR0002 contains two InfoObjects AND a transformation object.

The second transport #DKR0002 will fail during migration due to mixed object types contained in the same transport.  Because this migration failure occurred, we will need to create an additional transport request and place the transformation in there by itself.  Don’t forget to keep all like objects together!
Don’t upset the basis team.  You will always want them on your good graces to help you out in a pinch!

Tip #2 – SAP BW Object Migration Order

Ask yourself, “Does this object rely on another object in order to function?” You can’t have an active DSO without InfoObjects assigned, so why would you ever migrate a DSO before the InfoObjects have been migrated? When migrating objects out of the development environment to a test environment, objects must enter the upper environment in the descending sequence indicated below.

• InfoArea
• InfoObject
• InfoProvider
• InfoSet
• Roles
• DataSource
• OpenHub
• InfoSpoke
• Transformation
• DTP [DO NOT MIGRATE] – Manually create in target environment
• InfoSource
• Transfer & Update Rules
• InfoPackage [DO NOT MIGRATE] – Manually create in target environment
• Process Chain [Can be migrated, however, we recommened to manually create in target environment]
• Queries & Query Variables

Tip #3 – Don’t Release That Transport…Until You Double Check Everything!

• Make sure that additional objects were not added accidentally (business content, other user error, etc.)
• If the object already exists in the Target environment, ensure that communications have gone out to discuss the impact of the modified object.

If the object is brand new:

• Review the data model
• Look over performance testing documentation
• Review load testing
• Regression testing complete?
• Is there a MultiProvider?
• Are there any indexes built?

If you follow these helpful tips we discussed today, you will save yourself countless hours of rework and headaches.  Remeber to use correct naming conventions and always double check your transports.  It helps to have a detailed migration plan containing all objects, transport numbers, migration order, and migration instructions so the Basis team can easily migrate your objects from one environment to another without issue.