The Business Information Warehouse generally uses one modification to the Basis standard transport system:
In BW, new objects are firstly stored automatically as local objects in the package $TMP. For this reason, when a new object is created, no dialog window appears asking whether or not it should be written to a transport request.
When the objects are transported for the first time, you must perform the following steps in the function area Transport connection of the Administrator Workbench:
• Collect objects with all dependent objects.
• Specify a transportable package and request.
The system writes the objects to the specified request. After this point, the objects are subject to automatic transport connection. Changes to the objects in the development system are highlighted automatically, that is, the modified objects are automatically written to a request.
You should only use the object collector for transporting again when you newly create additional objects.
The advantages of the BW transport system are:
• Firstly, you can develop new scenarios without thinking about the transport. When the scenario is completed, only objects you need in the productive system are collected in the transport connection and written to a request. The objects not required remain as local objects and are not transported.
Whereas if all objects were written to requests from the start, test objects and productive objects may be mixed up in a request. Extra effort would be needed to clean up these requests.
• Users in the productive system can create local queries and work folders without having to take decisions about transport in the dialog window.
Activating the standard transport system
To activate the standard transport system , select in the function area Transport connection of Administrator Workbench Edit -> Transport -> Activate Standard
(You can de-activate the standard transport system via Edit -> Transport -> De-activate Standard)
When the standard is activated and you have created however many new objects (also when BEx objects such as queries, work files and Web templates have been created), access a dialog window for a package query, and if necessary an additional window for a request query. In addition, when creating an object, you must decide whether the object is to be transported and which package it should belong to.
• Advantages of the standard transport system: It is clear from the beginning which objects are to be transported. When creating a new object, the developer decides immediately on a development class and, if necessary, on a request.
This process is above all interesting when you have several target systems since the object target is determined via the package. (when transporting via the object collector, the same package is assigned to all collected objects. Changing the package with the collected objects would require more work if done after collection).
• The authorization to create new objects is not established via the BW authorization objects. Instead, only the co-ordinator has the authorization to create requests and tasks. The co-ordinator creates one or more requests with tasks for the approved developers. Other developers are not allowed to save ojects (except for local private objects), since they would have to write these to a request. This process gives the co-ordinator an overview of which developers processed which objects.
• In the BW transport system, BEx objects (queries and work folders) are written to a fixed BEx request. In addition, you can optionally determine a BEX request per package. BEx objects are written directly to a request and not to a developer’s task. In some circumstances, the standard transport system is preferable to this simplification ,for example when the co-ordinator requires information about which developer processed which object.
