On my way to resolve transport request dependencies
In a previous blog post I explained that I was very surprised by SAP not providing any functionality to check transport requests dependencies before importing them into a target system… and I showed a little trick that could be used as a (unsatisfactory) workaround, see:
However, since then it seems SAP has been working on a “CTS plug-in” delivered with the SL Toolset 1.0 to fulfill this requirement (thank you Willi Petri for pinpointing it). Check Boris Rubarth‘s article on SCN: The specified item was not found..
Unfortunately, at the moment this long awaited tool seems to be valid for NON-ABAP requests only. That’s why I kept on trying to develop my own program, which made me go through a lot of tries and errors. Here is the story — short version 🙂
1) First I searched for similar programs
Indeed you can easily find a few initiatives on SCN to automate transport request dependency check. To mention a couple of them:
To be honest I didn’t test any of those because of their missing documentation, or too much complexity.
2) Then I developed my first transport sequencer
The very first version of the program made extensive use of regular expressions and runtime type services (RTTI). The idea was to list every object belonging to a transport request and parse the code (function modules, methods, programs, etc.) to determine dependent objects. But it became soon way too complicated when trying to identify more than just obvious dependencies. In fact, I found myself trying to do the job of the abap compiler which was not really intended.
So I explored another solution: the “test import” functionality available in STMS. I thought I could use this standard tool to simulate the import of a request in a target system without actually transporting it, and analyze the log to look for missing objects. But I was completely misunderstanding the purpose of it! As you can see in the online help, “test import” will only help you determine if the objects in a target system are the originals:
http://help.sap.com/saphelp_nw04/helpdata/en/28/eb253715dfb808e10000009b38f889/frameset.htm. I’m wondering who decided to name “test import” that way… I find it confusing. And also, who decided that it was more important to develop such a functionality instead of a real “transport simulation” or “transport sequencer” program? Just a thought…
In the end I discovered the “Environment analysis”: http://help.sap.com/saphelp_nw04/helpdata/en/d1/801999454211d189710000e8322d00/frameset.htm.
I think everybody knows the “Where-used list” functionality ; in fact, the “Environment analysis” is the exact opposite. For example if you select a function module, it will not give you a list of programs or methods that are using it, on the contrary it will tell you which structures, domains, class, etc. this function module is referencing (i.e. what you need to transport beforehand if you want your function module to work as intended in the target system).
3) “Environment analysis” : is it really that simple?
When I finally discovered this very cool feature, I realized how easy it would be to develop a transport sequencer program… So I’m working on it at this very moment. But I cannot get rid of this idea that there might be another trap somewhere. If it is that simple to get a list of all dependent “things” for one given object (thanks to function module REPOSITORY_ENVIRONMENT_RFC), why wouldn’t SAP have released such a tool a long time ago?
It is so easy that I just can’t stop thinking this might be another dead-end either because the environment analysis is still quite buggy, or no longer supported, etc.
Anyway, I created a program that you can find here: How-to check dependencies between transport requests