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.
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:
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:
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.
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.
If you would please remember a few things after reading this, I would like them to be:
Okumaya devam et...
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.
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
Okumaya devam et...