How to analyze S/4HANA tables with proxy objects

Since we, the BI folks need to deal with ERP quite a bit, it is also sometimes handy to understand how things are structured “out there”. So, this writing is about proxy-objects / replacement views and associated topics. I will do it based on two examples that came from real-life questions so we can generalize afterwards.

First and foremost, we are dealing with a “new” ERP now, which is called S/4HANA. You may ask me now why is this important? Well, because that has changed things for us (BW folks) under the hood. To illustrate it I have made a GIF out of a slide that has been ever presented on a TechEd, wherein it is visible per area which of the tables lost their original importance and have been at least partially replaced by something.

(slide source 2018 SAP TechEd presentation CNA244)

Table disappeared completely

This never really happens (to be absolutely precise that was the case in one of the ancient versions of S/4, but now they’re back). While strictly speaking tables have not disappeared, they may have been replaced by the view. An example of such a table is GLT0 (G/L account master record transaction figures). If I recall it correctly, it was a monthly summary table, filled from BSEG/BKPF on regular basis. If we look in the system, indeed in SE11 it will show that it is not a table anymore but a view

While it is tempting to go and see what this view is about, we can try having a look, but not in SE11. Unfortunately, this is not a regular dictionary view that you can look at like this in SE11, it is an ABAP CDS view, actually, and all the new features, including ABAP CDS views are available in ABAP Development Tools in Eclipse, so you need to get them for yourself and add an ABAP project there.

When you’ve done so, you can search for things using the magic button

and typing what are you searching for there

While this code may be enjoyable for some, it could be less enjoyable for others, therefore I recommend you having a graphical overview of major building blocks in this view by right-clicking and choosing Open With → Dependency Analyzer

What we see then is that our view GLT0 is a result of a serious sandwich of other views (8 layers of them) and that it actually gets its data directly from ACDOCA.

So, we can summarize here a few thoughts:

◉ There are a bunch of tables that are gone

◉ They’re not gone completely, because otherwise the system would’ve been ruined, so they are replaced by views

◉ In our particular example a hugely summarized table has been replaced by a view on Universal Journal, or simply put a line-item data

◉ All of this is beautiful because the summary tables like this do not need to be filled and serviced anymore

◉ On the other hand we understand that line-items is some heavy stuff, so we hope it runs very very smooth

Table almost disappeared

Let us have another example of a table behaving in a certain interesting way, this is a COEP table that has CO object line items inside.

Contrary to the first example, this one is not a view (says Transparent Table up there), but I have some suspicions… So, if I check it in Extras → Proxy Object… I will see something being filled there

Analyzing the view V_COEP_VIEW is done in exact same fashion as we have already done with GLT0, so again, I know I am dealing with ACDOCA data with some additional modeling on top of it (9 layers of CDS views on top of a line-item table with quite significant “something”).

Coming to an intermediate stop in here let us realize what we have:

◉ a transparent table COEP that holds no data anymore

◉ a CDS view V_COEP_VIEW which does provide the data

I can already sense you asking “how does that all work together?”. It works the following way: any SELECT operation on COEP will go to the view (Program / FM / Views / BW DataSource, etc.), so, that the data will be as fresh as it gets  any INSERT / UPDATE / DELETE operation will still run on an original table (because you can’t, obviously manipulate data in a view). This is done by SAP for easier transition of those cases where a customer may have some custom code working on those tables with proxy objects.

Table disappeared partially

Now, this may sound confusing but please, stay with me. There are some tables that (contrary to our last example with COEP) still do hold some data, but just not everything they originally did. Let us take an example of MARC, which is Plant-dependent Material Master. Using the same ideas we can see a proxy object NSDM_E_MARC

which, interestingly enough, is based on a table MARC!

– WHAT???

– Calm down and read on

To my humble understanding, most of the fields of MARC are still stored where they used to, it is just some part of them that is no longer being stored in a table MARC itself, but are rather calculated on the fly. Since we are here for learning the basic principles, I will just tell you that some Quantity fields are no longer needed to be stored in MARC, so they do get calculated every time we call for them. And judging on the screenshot above they are calculated based on MATDOC_EXTRACT table, which hints at relatively up-to-date information.

Wrap up

If you would please remember a few things after reading this, I would like them to be:

◉ Some tables have changed

◉ Use “Proxy Object” of a table to find the view. If for some reason you need all of tables with proxy objects, find it in DD02L with setting the filter VIEWREF<>”

◉ Try reading the ABAP CDS, but if you’re not into it, use dependency analyzer for higher-level view

◉ If you need to dig into field-level detail, try doing so, it’s not that scary