Prototyping an ABAP OData Entity Data Model Generator : Table Relationships

Moving further from first part of this application, explained in my previous post Prototyping an ABAP OData Entity Data Model Generator : Simple Transformation, I’ve now put together some details about the main ABAP executable program.
...Continued from previous post

So we now have the simple transformation program in place and next step is to develop an ABAP executable program that will take header/main database table name as input, fetch details of table meta-data/foreign-key relationships, populate a variable of type structure ZRAM_EDMX_CSDL_SCHEMA using selected data and then finally use "call transformation" to convert data to XML. I'll write about this prototype program....

Technical Details:

As mentioned above there were 3 main challenges to develop this program:

1. How to get the table relationship (incoming / outgoing) information for the main SAP table?
2. Once the relationship data is obtained then how will we prepare the data as per the requirements of OData EDMX/CSDL and populate the data in a quite complex ABAP structure?
3. How the data will finally be converted from ABAP structure to EDMX/CSDL XML?

Third one is mostly completed as explained in my last post. So now some background on getting the table relationship information from SAP. Like every lazy developer working with a package software e.g. SAP, I will first try to find a similar existing application that can provide me a hint or even better - a reusable component for my purpose.

Apart from lower level information available in data-dictionary meta-data tables, we know that SAP has a primitive data-modeller ( Transaction SD11 ) with graphical display of data-model. Also, in transaction SE11, you can use the “Graphic” icon to show the table relationships. e.g. for table SPFLI (Flight schedule) the graph is as below:

Since this graph-application is at a higher abstraction level – it seems to be a good one for the purpose of finding any standard API/Functions that might provide the data we need – rather than we ourselves figuring out the details directly from DDIC meta-data tables. Reading/debugging the code of this standard application, I found the function 'RS_DD_FOREIGNTABLES_GET' that could easily fetch the relationships as required.

For a given table(s), this function gets the related tables from database table GRAPH_TABL based on the direction ( > , < or space ) specified in the function parameter. Initially, I setup the program to just get other tables where input main/header table is specified as a checktable ( direction as “>” ). But later I changed the program to use direction as space and get both incoming as well as outgoing relations. Now it gets all related tables – i.e. tables where main-table is a checktable as well as the tables which are specified as checktables for main-tables’ fields.

The method/routine written to cover the above part is as below:

 method get_related_tables.
    "IMPORTING i_tabname type DD02L-TABNAME
    "RETURNING VALUE(et_CHECKTABLES) type SDG1_CHECKTAB.

    data : lt_tablenames type sdg1_table,
           wa_tablenames like line of lt_tablenames,
           wa_checktables like line of et_checktables.

    wa_tablenames-tabname = i_tabname.
    append wa_tablenames to lt_tablenames.

    call function 'RS_DD_FOREIGNTABLES_GET'
      exporting
        direction              = ' '
        list_exceed            = 100 " a bit too much
        type                   = 'TABL'
      tables
        tablenames             = lt_tablenames
        checktables            = et_checktables
*       TABLENAMES_ALREADY_GOT =
      exceptions
        parameters_fault       = 1
        no_selection           = 2
        others                 = 3.
    if sy-subrc <> 0.
* Implement suitable error handling here
      return.
    endif.
  endmethod.                    "get_related_tables

Above part was relatively easy - Now last but the toughest one is to adapt the relationship information to the EDMX/CSDL specification format – e.g. prepare and populate the EntitySets, AssociationSets, Entity, Propertied, Navigation Properties and Associations etc.

Now if you excuse my ramblings - One thing I noticed about the way we write designs or technical documents for SAP Developments - the structure of explanation might imply that the development process was based on a waterfall approach. I think it’s a misconception that development process in SAP follows more-or-less a waterfall approach or even V-model without much scope for agility/iteration. As if it’s actually feasible to complete even a slightly non-trivial application using waterfall. In my view, the truth is - designers & developers have been un-officially following an iterative approach to get the development completed, while somehow maintaining the outlook of a pseudo-waterfall/V-model approach just to adjust the delivery-dates/timelines as per management/users expectations. For a successful SAP application development, there is always an element/essence of Agile - especially on development side and to the extent that it was possible without involving non-developer groups. However now with “Design Thinking” and some elements of Agile coming into mainstream, these approaches are more acceptable to other sides – e.g. management and users – hence can be applied officially. Which is good progress.

I’ll be back with another post, probably the final one regarding this prototype, very soon.