Recording Time for Transports

Use

With a standard transport system, when developers create a new BW 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 BW transport connection, however, BW objects are first created automatically as local objects in package $TMP because this makes it possible to create test objects. For this reason, no dialog window appears asking whether the object should be written to a transport request when a new object is created. Only when the BW 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:

Use the object collector to create a consistent amount of objects to be transported.
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 again used for transport when additional objects are created.

Comparison

To transport BW objects from a source system to a target system, you can choose between the standard transport system and the BW transport connection. The following table compares the advantages of the standard and the BW transport systems so that you can decide which strategy is the more suitable for you.

Criterion	Standard transport system	BW 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. Recommendation Since the object target is determined using the package, we would recommend this process when you Have more than one target system Already know to exactly which target system the objects are to be transported Already know exactly which objects are to be transported Caution Under certain circumstances, if all objects are written to a request immediately, test objects and productive objects can be combined in one request. Additional effort 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. Caution 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 catalog entries are created with the original system SAP. This can lead to problems when the objects are transported at a later date. Recommendation 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. Recommendation 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 BW 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. Recommendation This process guarantees that the coordinator has an overview of which developer processes which objects.	The authorization to create new objects does have to be displayed using the BW authorization objects.
Handling BEx objects	The standard transport system does not provide for the special handling of BEx objects. Recommendation Under some circumstances, the standard transport system is preferable to the simplification in the BW 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 BW transport connection. It is also possible to specify a BEx request for each package. BEx objects are written directly to the requests and not to the developer tasks. This makes it possible to edit BEx objects without transport dialog boxes in Web interfaces.

Criterion

Standard transport system

BW 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.

Recommendation

Since the object target is determined using the package, we would recommend this process when you

Have more than one target system
Already know to exactly which target system the objects are to be transported
Already know exactly which objects are to be transported

Caution
Under certain circumstances, if all objects are written to a request immediately, test objects and productive objects can be combined in one request. Additional effort 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.

Caution

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 catalog entries are created with the original system SAP. This can lead to problems when the objects are transported at a later date.

Recommendation

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.

Recommendation

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 BW 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.

Recommendation

This process guarantees that the coordinator has an overview of which developer processes which objects.

The authorization to create new objects does have to be displayed using the BW authorization objects.

Handling BEx objects

The standard transport system does not provide for the special handling of BEx objects.

Recommendation

Under some circumstances, the standard transport system is preferable to the simplification in the BW 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 BW transport connection. It is also possible to specify a BEx request for each package.

BEx objects are written directly to the requests and not to the developer tasks.

This makes it possible to edit BEx objects without transport dialog boxes in Web interfaces.

More information:

Defining the Recording Time for Transports