You’ve been working long and hard on a very important development. You’ve created your classes, WDA’s, programs, function modules, and the related DD elements, domains, table types and structures.
Everything looks fine. Your transport is ready to go. You release it to the Q system, and everything still looks fine. Users are happy, and so are you. You get the green light. The transport makes it to production. You leave the office, happy that yet another accomplishment is done.
…you arrive at the office. You’ve barely had time to gulp down those first few drops of caffeine before your mailbox starts to inflate. Or the phone rings. Or both. -Hey, we have situation. In Prod. And it seems to be, uh, your fault.
Or your development, more precisely.
MY development? Can’t be. It was tested. Double checked. It’s watertight.
Except we’re not talking functional issues. The thing failed to generate. It won’t work. Why? Because one of your tables refer to domain ZZ_WHATEVER, and ZZ_WHATEVER doesn’t seem to be included in the transports…
Uh. Right. OK. Um…
Turns out ZZ_WHATEVER is on another transport, created by your colleague Bob, in the next cubicle. Now good old Bob created ZZ_WHATEVER for one of his own projects, and it looked so good you decided to use it for one of your own table fields.
No use re-inventing the wheel, right?
…although Bob’s transports have gone all the way to Q, they’re still in test phase… so that nice domain of his, ZZ_WHATEVER, is not in Prod. Which is why your table fails to generate.
I guess this situation has occurred to many of you. Every once in a while, it might happen that a transport released to a downstreams system “misses” one or two vital components. This could happen for several reasons:
- you have created a new development that re-uses an existing class or DD element, which has not been previously transported
- you want to import the development into a freshly installed system (without using SAPlink), and you have manually compiled a transport containing all the parts, but forgotten one or two pieces
- an emergency fix has been implemented that relies on some other custom development objects, and you didn’t think of adding these to the current transport (or maybe they are locked in other transports)
The solution (well, one solution, anyway)
Whatever the reason is, it would be nice to have a tool to analyze your transport, before releasing it, just to check for inconsistencies. This is where the Transport Consistency Analyzer come in handy. It will do the following:
- create a list of all objects in the transport
- scan all code lines (programs, includes, functions (including the whole function group), classes)
- iteratively scan all objects referred to or used in the master object list (down to the n’th level) to obtain a complete list of code objects
- scan the final, complete list of objects and compile an exhaustive list of all DD objects, functions, programs, includes, classes etc. that are used or referred
- provide the opportunity to add the missing pieces to your original transport – or create a new one, automatically
How & Where?
I started working on this tool more than 2 years ago. It was originally a small(ish) report, but has been properly “Object-Oriented” along the way. Now, I’ve decided to set up a project on Code Exchange for it. The TCA is, in it’s current version (which I humbly call 0.9), already a tool that does all of the above. It is currently in “test phase”, and is being continuously worked on. I am providing it as a Code Exchange project because I believe it already has a certain value, and would welcome inputs and comments – as well as any corrections that the community might find it worthwhile to point out!
Please note that as this is still a preliminary version, there might be bugs and issues. I take no responsibility for any flaws or incorrect results, or their possible consequences, and would like to encourage ABAP geeks out there to examine the results closely before relying on the output of the program. Nevertheless, I believe the tool provides decent functionality as of now, and that it has a certain “business value”.
Here’s a direct link: Transport Consistency Analyzer
Collaborative projects like the Code Exchange are one of the many areas where SDN/SCN proves it’s undisputed value to the SAP community. From the humble beginnings, it is now becoming a vibrant scene for developers all around the world. Just one more reason to get involved and contribute!