Skip to Content

Semantic Web Technologies Part 3 – Looking Into AS ABAP

In part 1 of this weblog series a gave a short introduction into Semantic Web technologies and in part 2 I discussed possible business cases. Now I want to show how to use Semantic Web Technologies to look into AS ABAP. 

Package Usages within AS ABAP

The former development classes in ABAP have been replaced by packages. The biggest advantage is that we are able to control dependencies between packages. AS ABAP offers tools to define them and report violations of package interfaces.

Now we want to solve a simple problem: We want to visualize dependencies between packages. Therefore we create a simple RDF vocabulary which we use to express usages. In the following example we state two facts:

  1. package SWW uses package SILM
  2. package SWW uses package SIRM

The RDF/XML syntax of those facts is a bit awkward but I’ll use it instead of a better syntax like N3 because XML can be generated easily using XML transformations and can be imported quickly in most RDF tools:


Now we can use a RDF visualization tool like RDF Gravity to look at those two simple facts – we only have to load the data as a file:


Getting All the Information

Now lets get all package dependencies with no error severity of the NSP demosystem. This is simple using the following report:

REPORT  z_rdf_package_usages.

TYPES: BEGIN OF t_access,
         client_pak TYPE devclass,
         pack_name  TYPE devclass,
       END OF t_access.

  lt_packages TYPE STANDARD TABLE OF t_access,
  lv_out TYPE xstring.

SELECT p1~client_pak p2~pack_name
  FROM permission AS p1 LEFT OUTER JOIN intf AS p2 ON p1~intf_name = p2~intf_name
  WHERE p1~err_sever = 'NONE'.

SORT lt_packages.
DELETE lt_packages WHERE pack_name IS INITIAL.

CALL TRANSFORMATION z_rdf_package_usages
  SOURCE root = lt_packages
  RESULT XML lv_out.

    xml_string      = lv_out
    title           = 'Paketverwendungen'
    no_xml_document = 1
    OTHERS          = 2.
IF sy-subrc <> 0.
  MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno
          WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.

Within the report I’m using following Simple Transformation which transforms the internal table containing facts into XML/RDF:

<?sap.transform simple?>
<tt:transform xmlns:tt="" xmlns:rdf="" xmlns:ex="">

  <tt:root name="ROOT"/>

      <tt:loop ref="ROOT">
          <tt:attribute name="rdf:about" value-ref="$ref.client_pak"/>
              <tt:attribute name="rdf:about" value-ref="$ref.pack_name"/>


If you load the result of this report into an RDF Viewer it will be difficult to discover anything, even if you look only at small parts of the result like this one here:


Querying Package Usages using RDQL 

If we want to explore the structure of package dependencies we can use RDF query languages to give our more information. The RDF Gravity tool supports RDQL which allows SQL like queries. I very simple one is the following:

WHERE (?x , ex:usage, <S_IRM>)

I’m asking for all packages that use package S_IRM. The result can be displayed within RDF Gravity:


Of course this tiny example is very limited. The package S_IRM is not a proper resource but it would be an easy task to create a proper resource containg more package information that could be exposed be a REST web services for example.

And what it is good for?

You might think that this tiny example is boring because we can the same with an ABAP  eport and an additional graph viewing tool. But think of the case  you want to expand your model ro express  more complicated facts about packages:

  • software components with different releases,
  • switches and enhancement spots
  • date of creation,
  • date of last modification,
  • error severities of use accesses,
  • violations of package interfaces,
  • implicit usages (perhaps using dynamic calls like BDT),
  • package hierarchies…

I think the strength of a generic vocabulary and ontologies will become more obvious. And last but not least you can use query languages and reasoners to explore the the set of facts.


In the instalment of this weblog series we learned that Semantic Web Technologies can be used to express facts about technical resources like package usages of AS ABAP. 

You must be Logged on to comment or reply to a post.
  • Hi Tobias,
    This is so perfectly cool, it’s pure SemWeb Magic: a great example of the power of standards and how far you can go if you employ existing standards in a lean and smart way.
    I’d love to see this kind of thing with a propped-on natural language interface that is smart enough to ask back questions to resolve ambiguities… you could have near-Socratic dialoges with your SAP system about its software structure. 🙂
    • Magic? Perhaps… I have so many questions about the strength of query languages like RDQL and SPARQL and computable properties so I hope I can supervise a diploma thesis about this topic for our company. Perhaps we can even create a neat prototype of a new product.


  • Hi!

    Really neat idea! Next step for me would be to combine the stated dependencies of packages with the real (static and maybe even dynamic) use of single development objects to get the whole picture. Even more of use for degenerated ABAP applications that do not know of package interfaces and dependency declarations. 🙂

    Hope to see even more interesting projects and ideas from you.

    • Yes, I’ll write about it. At the moment I’m doing experiments with other development objects using ontologies and of course reasoners. At first I tried to  create something like a global ontology of all TADIR but I think  this is too much: without proper database queries take much too long, this ontology gets too complicated and questions are difficult to formulate. So I think it could be more interesting analyse certain aspects that are intransparent within the SAP system.

      But how we get overall transparency? I’m thinking about a kind of semantic desktop for SAP systems. Please imagine the following: I’m dragging a set of lines of customizing from SM30 onto a desktop and see all its related information: Which applications use the underlying table? When was this piece of customizing transported? In which BC Sets does it occur? Of course one should be able to add own facts and save them: Why did I change a customizing value? In this case semantic web technologies could bridge the gap between an SAP system and associated concepts (documents and other artefacts) outside the SAP system.

      Perhaps this could be a proper and pragmatic way for documentation of customizing changes or administration activities. At the moment many companies try to master this complexity by doing more and more bureaucracy: there exist documents for every development aspect and nearly every transport, there are  enhancements of the ABAP transport system with additional attributes and checks and so on. Of course this activities are useful and necessary, but I think they could be much more effective if metadata would keep all information together – and perhaps we could even be able to avoid redundancy and work more efficiently.

      Should this be a topic for another blog? Could it even be a community project? We can code cool desktops using Adobe Flex and using the SAP Netweaver Composition Environment to have access to reasoners and RDF databases.

      • Hi!

        I would value even the “normal” dependencies and connections between specific development objects (Where-Used-List and Environment Analysis for classes, interfaces, function modules, tables and so on) that you can get manually for a single object very easy, but get lost when trying to build the transitive hull for a whole tree of connections. These informations are quite easy to gether programmatically. Transformation into RDF oder RDF-like representation is a low-brainer, as you ST fragement demonstrates.
        Information about these connections could be used in way more ways than I can imagine at the moment. Asking for all transactions that are influenced by a single customizing table would be just one of them.
        The only block in the way to get these informations I see at the moment is the historically grown design time repository in ABAP, where you have to go to the gritty details very fast and sometimes end up the ABAP compiler class (not so well documented…). My dream would be to have well-formed and well-designed API for the ABAP repositiory, similar to the RTTI classes. DTTI (Design-Time Type Information) could be a name for it. 🙂

        • Actually I’m doing this for transformations because XSLT and ST programms are not well supported concerning use accesses. In the next time I want to publish it as Open Source: or start a new project (DTTI is a great name).

          Calculating use accesses indeed is simple and we could expose usages of a single TADIR object using a REST Web Service and of course the whole set of usages as OWL document.

          At the moment my ontolgy is quite simple and has only predicates “includes”, “imports” and “calls” which are derived form the transitive property “uses”. Do you want to review it?