Dude, where’s my table? – The difficulties of accessing data in APO
APO doesn’t use standard tables.
That is not true, of course, but is what a person from the ECC/R3 world may think when trying to extract information directly from tables in APO. APO can be very confusing and I hope that I don’t make it more confusing by trying to explain the situation in this post.
In my view, there are two main reasons why APO direct access to data is perplexing from the ECC perspective:
Use of internal ID codes
ECC tables use the object name as the table key and as link to other tables.
For the material tables the key is the material number and for production orders tables, the order number.
APO changes this approach and assigns internally an ID with a cryptic combination of 22 characters with no real world meaning and challenging to dictate. Here is one I made before (0CyjdOvAfKcdDzTgZlF1Y0).
This makes the ID quite unique, that is a good idea considering that APO can aggregate multiple ECC and external system that may have the bad luck of choosing the same number for different things.
If you manage to find that the table holding the material information at the plant level (/SAPAPO/MATLOC) you may be surprised to find out that it doesn’t include as fields the material or the plant (product and location in APO’s terminology). Instead it have IDs that needs to be referenced to other tables in order to get the usual material and plant numbers.
Equipped with this knowledge it becomes possible to build a query to display the equivalent to ECC’s MARC table in APO by linking /SAPAPO/MATLOC to the product table (/SAPAPO/MATKEY) and the location table (/SAPAPO/LOC) as shown below.
This is painful but doable, until you start looking for transactional data – for example the production order table.
Don’t waste your time, the table is not there. At least not as a standard table.
Tables in LiveCache
LiveCache is the precursor of HANA in the sense that data is stored in speedier memory rather than in slow to reach hard disks. I’m not going to bother you with the technical details of how it works, I will only say that accessing the data raises to a new level of pain.
Transactional data in APO is stored in LiveCache to give data intensive processes – like the optimized – a fighting chance to finish what they need to do in a workable amount of time. The time required to access a standard table would be prohibitive.
One way to access the data is to use functions calls. In my next blog I will be showing how to access and display information from the production order with an ABAP query.
One problem with the difficult access to the data in LiveCache is that the few tools SAP provide feel “bloated”.
This is the case of standard transactions like /SAPAPO/RRP4 or BAPIs like BAPI_MOSRVAPS_GETLIST2 that are designed to cater for many different needs to access data in LiveCache. For example, they may bring all kind of information that we don’t need but add extra checks and processing time to the run.
A query or program using more direct function calls can be much faster and efficient. After the information is transferred to internal tables, more complex calculations and checks can be archived.
So, to continue with the automotive simile, your car has not been stolen; it is just parked in a different level than the one you thought it was.
(This post was first published in my professional blog)
Nice write up. On the last point regarding the query, would it be a SQL DB procedure that you're talking about ? What if I would like to read the list of orders that are on delivery block ? Is it possible ? I know APO works at line item level in terms of gATP. But, is it possible to find such indicators by grouping all the POSGUIDs to one ORDERID and identifying if there is a block ? Do we have such SQL Native DB procedures that calls LC to get this info ?
Thanks for your comments.
For the order you don't need to use the SQL procedure directly as there are functions like /SAPAPO/OM_ORDER_GET_DATA that encapsulate the SQL procedure with very little overhead.
With the specific case of the delivery block, as I understand the information is not stored in LC but in table /SAPAPO/SHIPPING. Function /SAPAPO/ATP_SD_ORDER_GET can give you back what you are looking for but it seems to be looking at the tables anyway.
As you point out the trick is how to link the IDs and combine LC and table information to display what you need.
If the information is there, it is always possible to display it. The devil is in the details, of what the user really needs shown and the way to get it (in that order).
I hope this helps.
I am aware of this. In fact, I wrote a short blog on this in the past. You may go through the below link.
What I am interested in knowing is, when a CIF queue is posted in gATP system. Does it always leave 2 copies of the information. 1) DB table 2) Live Cache. It leaves the data in DB tables for application users visibility and in LC purely for ATP calls and other gATP processing.
I don't know the answer to your question.
That is no wonder as you have a deeper knowledge of GATP that I do.
But I doubt SAP will build that kind of redundancy. If they put the block field in that table they probably think accessing the information would not be as frequent and having it in LC is not needed. But, then again, I'm just speculating.
Thanks for the link. I will have a close read at your post, looks meaty.
Thanks for posting.
For convenience, SAP provides some standard database views that joins the relevant tables, so they can be immediately used in trx SE16 for example.