Technical Articles
ADT Relation Explorer
When working with ABAP Development Tools (aka ABAP in Eclipse) you usually have to deal with many different development objects. These objects are stored in the ABAP Repository and are connected to each other in various ways. Sometimes it is difficult to see and understand all these relations.
In the video below you can see how our new tool, the ADT Relation Explorer can help you to explore relations between objects. The tool can currently be used for RAP business object overview, environment analysis, where-used overview and to see objects that are related to a certain CDS view. The video does not only show how the tool can be used, in fact it gives you also an impression about how the tool has been invented.
Now you’ve learned the basics of the ADT Relation Explorer and it’s time to give it a try. Start your IDE, open the Relation Explorer and try it for several objects. If you are already working with RAP business objects I recommend to use it for your CDS views and your behavior definitions.
For detailed information you can also read the documentation.
Thanks for sharing.
For me, your information delivery via a video, where the core idea and starting point is described and what the ideas behind the new tool have been is really a very cool way.
Best regards,
Sebastian
Thank you, but I already suspected that all of this sounds too good to be true:
This is the prerequisite for *err* “on premise” system, right?
Don’t let that discourage you, and I did learn something in the ~10 minutes of fiddling and clicking around the video and documentation, and there will be enough folks who will like the presentation form, but I’m actually mildly irritated about this info not being somewhere at the start or end of the technical article…
I can Alt+Shift+W for Relation Explorer in Project Explorer against a Package from our Namespace, for the system where the Object Relations are not available:
but not against ‘Z’ or any other Package I tried on the quite outdated S4/HANA Sandbox, where Relation Explorer seems to work (with two contexts: Used Objects and Using Objects, which probably has nothing to do with the backend...).
Can the thing really do something with the dependency analysis…–how shall I put it–on a, dare I dream, “Package level”, or is it just a UI oddity of ADT 3.12? Asking from within the "trying to devise "clever ways" of easing getting rid of "legacy" custom code" context...
Thank you and cheers,
Jānis
Hi Jänis,
yes 7.54 is the required onPremise (indicated by the house icon) release.
Well, the article is to promote the video and the video is to promote the new tool. The video is not the documentation, which is instead linked below the video in the article. Maybe you have overseen this link...
The available contexts depend on the selected object. If the object is part of a RAP Business Object for example, the BO contexts is provided. 'Used Objects' and 'Using Objects' are available for any object, except of packages.
The idea of the tool is to improve it further, introduce additional contexts, add more features and maybe also support packages. So, what would you expect to see as relations of a certain package? What needs and ideas do you have here?
Thanks for your feedback and best regards,
Michael
I did find it in the video fairly quickly (thanks for putting it in), it's the documentation I was feeling lost in - probably due to unfamiliarity. 🙂
The immediate context is: I know there are many custom code packages related to: a) Data migration project(s), b) too many to count data analysis and correction "reports", "tools" and "utilities", c) long since disused custom functionality, - on a soon to be 20 years old landscape with one productive system, with roughly 3 million custom code lines in about 1200 packages.
The dead (or rather largely dead...) code (and its DDIC) often relies on custom and SAP functionality and DDIC that is in use, so it pollutes the where-used lists, distorts the "picture" when one tries to figure out what would it take to change productive stuff, and leads to wasted effort of actually refactoring and "extended-check-maintaining" dead code... Cleaning dead stuff piecemeal as one goes along and happens to discover it does not make enough of a difference, I feel. Nobody dares to delete this stuff en-mass (as whole package(s)) because of some comparatively few, I speculate, dependencies going from the "still good code" to "largely dead code".
It would be helpful to know, I speculate, on a level of a presumably "largely dead code and DDIC" package, where, in which packages outside of the "largely dead package(s)" are the elements still being used. A kind of "mass-where-outside-package-range-used-package-list" for all package elements, if that's at all feasible... I'm thinking, perhaps naively 🙂
Thank you and best regards,
Jānis
Hi Jänis,
two comments:
Best regards,
Edo
Yes, thanks - SCMON+SUSG data will become invaluable in a few months time, when it would encompass whole yearly cycle of productive use. Just that last, very much needed reassurance that the code is really dead, before getting rid of it 🙂
cheers
Jānis