As architecture of APO is different from R/3. Transactional data you will not find in tables and you cannot execute database commands (Select/Update/insert etc.). Data is stored in LiveCache (Memory) hence data will be extracted/updated using BAPIs/FM. Technically Developer should have good knowledge of BAPI and FM.
So potential issues (from ABAP point of view) but in reality these are not issues, just little difference in concept. Infact it make APO rich
1. Developer cannot see data in se11/se16 sort of transactions
2. R/3 data is transferred to APO via CIF (Core InterFace), issues arises when there is failure in CIF, result in data delay and data inconsistency.
3. We cannot directly access data from LiveCache, first need to find certain parameters like matid/orderid/guuid.
4. APO's data is always dependent to other systems hence connections could be one issue. BI-->APO , R/3 <--> APO
Moreover for technical person it looks difficult to understand functional terms otherwise in programming there is not much difference
This is a broad topic to be discussed. APO works in a different way compared to the normal ECC coding. There are many differences. For example, if you consider a product in ECC, it has 18 characters and you will find the same data element in APO. However, when you're trying to use a standard APO BAPI, you will observe that the number of characters defined is 40 for a product number. So, technically if you're trying to pass a temporary variable with the 18 character material number, none of the BAPIs work. You need to define a 40 char variable with the additional zeros preceded to make it work as per the definition of APO.
I am not saying this is the only challenge. We would have many challenges apart from this. It is to be understood well as we work in APO as part of an implementation / supporting the APO application.
Other terms like GUIDs, Live Cache data, Planning Area locks etc., are tricky and as a ABAP developer, it is good to know upfront.
You should read the new book on Programming in SAP APO by Ankush Agrawal
http://www.tmhshop.com/six-ideas-that-shaped-physics-unit-c-conservation-laws-constrain-interactions-4995
Hi,
As architecture of APO is different from R/3. Transactional data you will not find in tables and you cannot execute database commands (Select/Update/insert etc.). Data is stored in LiveCache (Memory) hence data will be extracted/updated using BAPIs/FM. Technically Developer should have good knowledge of BAPI and FM.
So potential issues (from ABAP point of view) but in reality these are not issues, just little difference in concept. Infact it make APO rich
1. Developer cannot see data in se11/se16 sort of transactions
2. R/3 data is transferred to APO via CIF (Core InterFace), issues arises when there is failure in CIF, result in data delay and data inconsistency.
3. We cannot directly access data from LiveCache, first need to find certain parameters like matid/orderid/guuid.
4. APO's data is always dependent to other systems hence connections could be one issue. BI-->APO , R/3 <--> APO
Moreover for technical person it looks difficult to understand functional terms otherwise in programming there is not much difference
This is a broad topic to be discussed. APO works in a different way compared to the normal ECC coding. There are many differences. For example, if you consider a product in ECC, it has 18 characters and you will find the same data element in APO. However, when you're trying to use a standard APO BAPI, you will observe that the number of characters defined is 40 for a product number. So, technically if you're trying to pass a temporary variable with the 18 character material number, none of the BAPIs work. You need to define a 40 char variable with the additional zeros preceded to make it work as per the definition of APO.
I am not saying this is the only challenge. We would have many challenges apart from this. It is to be understood well as we work in APO as part of an implementation / supporting the APO application.
Other terms like GUIDs, Live Cache data, Planning Area locks etc., are tricky and as a ABAP developer, it is good to know upfront.
Thanks,
Babu Kilari