The ABAP report RSDG_TRFN_ACTIVATE is well known to activate transformations (and the corresponding DTPs) mainly in in productive and quality environments. However, the report can also be handy during the development phase and potentially save a lot of time. This is what I would like to focus on here.
Let’s have a look at the following data model having one data target with several inbound transformations.
If you change now the data target, it will result in a deactivation of all Transformations and Data Transfer Processes:
Typically, you would now make the required changes to the transformations, activate and add them to a transport. This can be a pretty time consuming task, especially if only an activation is required in most cases.
Usage of RSDG_TRFN_ACTIVATION
Here the ABAP RSDG_TRFN_ACTIVATE can be very handy. If you run the ABAP for the given InfoProvider as shown in the screenshot, you will have activated and assigned all inactive objects to a transport in a fraction of time doing it manually one-by-one in RSA1:
The tickbox “Transport recording …” ensures that you get a transport pop-up for every transformation and DTP:
The only disadvantage is that you have to confirm each object by pressing enter (but you also have the flexibility to assign the objects to different transports). Finally you will have all DTPs and Transformations activated and assigned to a transport.
Other Usage Scenarios
- It can make sense to create a variant in case you are working regularly on the same model:
For example, I take care of one data model with one central DSO and about 20 source providers and 5 data targets. Changing the central DSO inactivates around 30 transformations and 70 DTPs. For this purpose I’ve created a variant which contains the necessary transformations. It takes then only a few minutes to activate and assign all these objects to a transport.
- The program can also be used to collect transformations and DTPs easily. By changing the field Object Status to ACT it will activate and assign the objects to transports even if they are not inactive.
- Sometime it makes sense not transporting the activations. For instance if overtakers are to be expected due to parallel developments. Then you can use the report to activate the inactive transformations in the target system (even if these objects are protected against changes by system settings). The transport log tells you which transformations have to activated:
The downside from my perspective is that this has to be done in all target system. Having the objects on a transport is therefore the preferred way for me.
Tickbox for Transport missing?
Just in case you are missing the Transport tick box in your system. It was introduced with the correction from the note 2080574 – Mass activation programs unintentionally load generated programs into main memory, termination due to memory overflow. This correction is only available as of BW 7.3. Actually the flag was always there but it was hidden. The following screenshot is taken from a BW 7.0 system:
If you run the program in debugging mode you can change the value of with_cto to “X” and then you can also assign the objects to a transport in the same way as with newer releases.