Your transport guide – SAP BW
Your transport guide – SAP BW
Hey everyone,
A couple of months ago I encountered a rather big task to perform at my customer.
I had to transport 600+ transport requests.
600+ I hear you think? Well, we had been working on a greenfield BW/4HANA system with 6 other full-time consultants for months without there being a productive environment.
With a very large part of our team being withdrawn from the project and the creation of the production environment, I decided not to wait for the “go-live” week to start transporting.
With this small article, I want to share my personal experience, some basic know-how, and also some tips and tricks to make your life easier when transporting.
1. Transporting?
Why do we need multiple systems, is one not enough?
We need multiple systems so that we can develop and make changes to one system without bothering the end-users of the other system by breaking something or taking up too many resources.
Why do we transport?
We need a way to bring our tested developments over to the productive environment where the end-users can access the data, this is done through a transport mechanism.
Transport requests?
For this exercise, let’s compare a transport request with a moving box and the different systems with different buildings.
Imagine that you and your flatmate are moving to a bigger apartment but you want to keep all the furniture you build/bought over the years. You would need loads of moving boxes to get both of your stuff to the new apartment.
Exactly the same will happen in the case of the transport requests, one transport request can carry multiple items/developments that you or your colleagues developed. We need to bring these ‘boxes’ from the development system to the productive environment.
How do I put an object in a transport request?
You can switch on the popup-option by going to transaction code RSA1, go to transport connections, and then selecting “switch on standard” in the following menu:
Now, you’ll get a popup when creating something new (IOBJ, ADSO, TRF, DTP, …) on the development system. In this popup, they will always ask you the (transport) package you want to use. Standard, it will be $TMP, but this means that you don’t want to transport it.
Changing it to the custom package (in our case ZBW_INTERFACES, but I advise to search with Z*) and continuing will prompt you a window where you can choose between existing transport requests or create a new one. The custom package is normally created by the Basis or IT team.
Another way would be to execute transaction code RSA1, go to the transport connection, and collect the necessary items into your transport request. (see point ‘c’ under ‘releasing transports’ below)
2. Transport routes
The transport routes are the routes between the different systems that the transport request will follow to deliver configurations from one system to another.
You can look at the transport routes by going to the transport management system (TMS) on your “domain controller” by using the transaction code STMS.
Click on the icon that I’m hovering over on the screenshot below to see the transport routes.
Depending on how many systems you have this might look different. The transport routes are in most cases setup by a basis or IT team.
If you find yourself in a situation where you have to do it yourself and have no knowledge whatsoever, you could always start from the standard configuration templates.
Another thing that might be good to know is that there are transport layers, a transport layer identifies the route that transportable objects must follow.
Normally you would have two layers:
- A layer called Zxxx (with xxx = SID of your system) -> used for your own developments.
- A layer called “SAP” -> used for transporting SAP objects (like SNOTES)
Without the “SAP” layer in place, repairs would be non-transportable.
Remember the package that I talked about? ($TMP and ZBW_INTERFACES)
Each transport package belongs to a transport layer, this configuration can be found by using transaction code SE80.
You can also change the transport layer and system-client of a specific route (when selected) via the edit menu.
When working with multiple clients on the sending system (development), make sure to fill in the client specific transport routes. At my customer I had to add the second line (see screenshot below) before we could use transportroute ZB1P from client 200.
So our unreleased transport requests on the B1D know that they have to use transport layer ZB1P, and this on its turn points at B1P client 100.
You’ll see this in the properties pane of your transport request:
Our customer chose a two-tier landscape instead of a three-tier landscape. If they would’ve gone with a three-tier landscape, the recommendation would’ve been to implement the approval procedures on the QA system:
3. Preparing production
The next step I performed was for preparing the productive environment, so that the translation between systems was correctly set up.
a) Make sure all connections to the source systems are available
-> Job for the BASIS or IT-team
You can check the availability of the systems here:
b) Set up the conversion between systems
-> This makes sure that “S4D” from Development becomes “S4P” in Production
c) Set up the source system ID’s
-> This can especially come in handy when using the standard InfoObject 0SOURSYSTEM in your transformations to add the source info to your data.
d) Make sure the settings for the external HANA views are the same on both systems
-> Tcode RS2HANA_ADMIN
e) Replicate the BW authorizations to HANA (optional)
-> With Tcode RSHANA_GEN
-> You could also put this process in a process chain and run this each x-hours…:
4. Structuring transports
The next thing that I want to mention is the structuring of the transports. The first thing you should always keep in mind is having strict naming conventions as this could save you many hours, especially when working with multiple developers.
Choosing a naming convention is no exact science, it should be something that is clear for everyone in the team. We went with the following naming convention;
Structure:
BI – xxxxxxxx – yy [#]
Legend:
| Abbreviation | Explanation |
| BI | Business Intelligence team |
| xxxxxxxx | Module or subject |
| yy | Items: S -> DataSource (& Infopackage) I -> InfoObjects A -> ADSOs O -> ODSOs C -> CUBEs H -> Hana views T -> Transformations D -> DTPsP -> Process ChainsX -> Extras (like FM, ABAP programs, etc.) |
| # | Release sequence number [1-9] |
Examples:
Example 1:
B1DK901512 ANDMA 16.01.2021 BI – FIGL – P [7]
B1DK901510 ANDMA 15.01.2021 BI – FIGL – D [6]
B1DK901508 ANDMA 14.01.2021 BI – FIGL – T [5]
B1DK901506 ANDMA 14.01.2021 BI – FIGL – H [4]
B1DK901504 ANDMA 14.01.2021 BI – FIGL – A [3]
B1DK901502 ANDMA 13.01.2021 BI – FIGL – S [2]
B1DK901500 ANDMA 13.01.2021 BI – FIGL – I [1]
Example 2:
B1DK900570 ANDMA 16.02.2021 BI – External subject – H [4]
B1DK900568 ANDMA 09.02.2021 BI – External subject – X [7]
B1DK900566 ANDMA 05.02.2021 BI – External subject – D [6]
B1DK900563 ANDMA 04.02.2021 BI – External subject – T [5]
B1DK900562 ANDMA 04.02.2021 BI – External subject – P [8]
B1DK900560 ANDMA 01.02.2021 BI – External subject – I [1]
B1DK900558 ANDMA 01.02.2021 BI – External subject – S [2]
B1DK900556 ANDMA 01.02.2021 BI – External subject – A [3]
Why do we not put everything in one transport?
You could put everything into one transport. When importing it on the production system a logical order of activation of objects will take place, but I do not recommend doing that. Splitting them up in several transports gives you more flexibility and it will be easier to solve in case of errors
When creating the transports you have to keep the dependencies in your mind. For instance, you’ll need an ADSO before you can have a transformation, and you’ll need a transformation before you can have a DTP.
Some of my colleagues even extended our naming convention and added a “P” or “D” before the item abbreviation for the ADSOs, TRFs and DTPs to seperate the “PSA-block” and “DATA-block”.
I think it’s a great addition and really seperates the two in order to prevent errors. But that’s depending on the structure of your warehouse, and will not be covered here.
Dependency is checked when releasing the transport request.
Dependency is also why I would recommend that one of the first transport requests – when working with multiple developers – is the the one containing all infoareas. The second might be a shared transport request with the standard (Business Content) InfoObjects.
This is not needed when every developer has his/her own subject to focus on. If that is the case you could just put it in the list with sequence code [0] or [1].
Releasing transports
When releasing a transport request, you have to make sure that all tasks inside that request are released. You can do this by putting your cursor on the task or request and clicking the red truck icon.
When you added something to a wrong task/request there are a couple of steps you should follow to delete it from the task and add It to the correct one.
First you should be aware if you need to delete only one/two objects, or multiple.
a) If it’s only one or two, you could just double click the task, go into edit mode, select the items, and remove them.
But note, that the objects are locked and he will ask you to confirm each object.
b) If you have multiple objects that you want to delete, you want to first unlock the request.
First copy the task id you want to unlock (ctrl+y)
Afterward go to transaction code SE03 and unlock the request
Afterward, it’s the same as in a) but you can delete multiple at once without confirmation.
c) Now you can go back to the transport workbench (tcode RSA1), select the object you want to add to a transport request and click on “change package”.
You can also use this option to change objects in the package $TMP to a transportable package…
Importing the transport requests
First we have to go to the Transport Management System (TMS) with transaction code STMS and go to the import overview.
In this overview, you double-click the system into which you want to import the transport package.
Note that the lines with the blue icon in the RC column are the new transport requests in the queue.
Here you can click on ONE line and click the blue truck to import it or you could select multiple lines with “F9” on your keyboard or the select option next to the descending sort symbol on the top of the screen.
After clicking the blue truck icon you’ll get following screen;
-> The options on tab 3 could be useful when you encounter an error that concerns versions, or when importing objects that are manually changed in the production system etc.
When you encounter an error while importing, I would always advise you to double click the red icon in the rc column and expand the issue to get something readable.
Happy transporting!
Mattia
