With a standard transport system, when developers create a new BI object, they specify in a series of dialog boxes whether the object is to be transported and to which package it belongs. They also specify to which request the object is to be added.
With the BI transport connection however, BI objects are first created automatically as local objects in package $TMP because this makes it possible to create test objects. For this reason, when a new object is created, no dialog window appears asking whether the object is to be written to a transport request. Only when the BI objects are to be transported for the first time must the user take the following steps manually in the Transport Connection functional area of the Data Warehousing Workbench:
...
1. Use the object collector to create a consistent amount of objects to be transported.
2. Specify a transportable package and a transportable request.
The new objects (package = $TMP or empty) are written to the specified request.
Once an object is assigned to a transportable package, it is subject to the automatic transport connection from that point on. The system automatically records changes to the objects in the development system, that is, the changed objects are automatically written to a request.
All objects that are not transported are treated as test objects and remain as local objects in the development system.
The object collector is used to transport again when additional objects are created.
To transport BI objects from a source system to a target system, you can choose between the standard transport system and the BI transport connection. To help you decide which strategy is the more suitable for you, the following table compares the advantages of the standard and the BI transport systems.
Criterion |
Standard Transport System |
BI Transport Connection |
Time when a target system is decided upon |
When creating a new object, the developer specifies a package and, if necessary, a request.
Since the object target is specified using the package, we recommend this process when you: ● Have more than one target system ● You already know to exactly which target system the objects are to be transported ● You already know exactly which objects are to be transported
Under certain circumstances, if all objects are written to a request immediately, test objects and productive objects can be combined in one request. Additional work is required to clean up these requests.
|
Initially, new objects are created automatically as local objects in the package $TMP. Therefore, the objects are not directly written to a transport request. Objects are not assigned to a transportable package until they are to be transported for the first time. Each object is then subject to automatic change recording.
To ensure that this process functions correctly, the software component LOCAL has to have the status Changeable in transaction SE06 ($TMP objects are located in this software component). However, if the status of this component is Restricted Modifiability, the object directory entries are created with the original system SAP. This can lead to problems when the objects are transported at a later date.
You can develop new scenarios without having to consider the transport. When the scenario is completed, only the objects required in the productive system are collected in the transport connection and written to a request. The objects that are not required remain local objects and are not transported. Users in the productive system can create local queries and workbooks without having to make decisions in the transport dialog boxes.
If you want to change the packages for the collected objects after they have been collected, additional effort is required. |
Authorization to create new objects |
The authorization to create new objects does not have to be displayed using the BI authorization objects. Instead, the coordinator has the exclusive authorization to create requests and tasks. The coordinator creates one or more requests together with tasks for the developer responsible. Other developers cannot save objects (excluding private objects that they save locally), because they have to write these to a request.
This process guarantees that the coordinator has an overview of which developer processes which objects. |
The authorization to create new objects has to be created using the BI authorization objects. |
Handling BEx objects |
The standard transport system does not support special handling for BEx objects.
Under some circumstances, the standard transport system is preferable to the simplification in the BI transport system, for example, when the coordinator needs to know which developer processed which objects. In a BEx request, the coordinator cannot see which developer worked on which tasks. |
BEx objects (queries, workbooks and Web templates) are written to a fixed BEx request in the BI transport connection. It is also possible to specify a BEx request for each package. BEx objects are written directly to these requests and not to the developer tasks. This makes it possible to edit BEx objects without transport dialog boxes in Web interfaces. |
Defining the Recording Time for Transports