Technical Articles
abapGit and transport layer
Dear community, during the days I stumbled upon a problem with abapGit and transport layer of a package in customer namespace. First of all: abapGit works perfectly well. It was just the constellation that created the problem. Perhaps other community members will face the same problem one day. Here’s the solution that has worked for me so far.
Requirement
I wanted to use abapGit in an offline scenario (ZIP file) to update a development of a customer namespace in a development system in a different system landscape. So the target system was not the original development system.
It’s important to know that this development system had already received the development objects in the past that should be now updated by transport request. So the namespace was already there along with a repair license. The package in the customer namespace and a lot of development objects, too.
Problem
I used the “Import zip” function and compared some differences. Everything was fine. When using the “Pull zip” function, I was asked to choose a transport request what I did. And then nothing happened…
Solution
The “Log” function of abapGit revealed what happened. The transport request I choosed was not of the right type to be used. That wondered me a little so I did some further investigation. After all, I followed these instructions. What should be wrong?
It turned out that the transport layer of the package in the customer namespace was not adapted in the past to the new system landscape. After doing that via SE80, everything worked fine! Small cause, big effect, fast fix!
Best regards, thanks for reading and please stay healthy
Michael
P.S.: Check our new “Virtual Wishing Well for Blogging“.
P.S.S.: Not tired of reading blogs? Don’t miss this one, Clean ABAP book is coming…
Anything that can be changed in abapGit to surface this kind of error better?
I'm guessing that editing the objects directly via SE80 also caused an error?
Lars, you are the fastest support I’ve ever seen!
Changing the transport layer of the package in the customer namespace was not a problem at all. At least in this case.
The only proposal I would made for an improvement could be a message “Your abapGit log contains errors” after ending the function “PULL zip” if there are any errors. Or log should be shown automatically with focus on first error. The log revealed the situation very fast.
Actually I don’t see a chance to check the transport layer before executing the “PULL zip” function. But maybe some of the other community members have a good idea/proposal for that situation?
cool, I think there are already some open issues regarding better surfacing the log 🙂
I'm not sure I understood the case.
How was the issue related to customer namespace and ended up by changing the transport layer?
I try to explain and to give the necessary information.
The target development system was already loaded with the development objects by a "classic" transport in the past. So the package existed. But transport layer in this package was not changed to fit the transport landscape of this system constellation. I assume that was not necessary because the landscape isn't under control of a Solution Manager. So you can easily use a transport of copies in the landscape to bring your development objects to production.
If you use now abapGit in an offline scenario and you activate "PULL zip" function, you are asked to choose a transport request to note the changes abapGit will do on the developement objects. As the transport layer of the package doesn't fit the system landscape, that will result in a local transport request. A transport request of this type is not ok to note the changes you plan to do and that is shown in the abapGit protocol.
In my constellation, the package and development objects are in a registered customer namespace. Unfortunately that made things a little bit more complicated. But I suppose same situation will occur with Z- or Y-namespace objects as long as the transport layer in the package is wrong (doesn't fit to the system landscape).
I hope this is better understandable 🙂
Thanks for the clarification.
So basically the namespace issue was just a bonus.
The real issue was an invalid transport layer.
You may change the title so it may better describe the real issue.