Dude, where’s my table? – The difficulties of accessing data in APO

[Former Member]

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)