Effect of Planning Areas and POSs on lIve Cache

[Former Member]

Hai,

The design of Planning Areas(PAs) and Planning Object Structures(POSs) is very important as it has great influence in processing performance of Live Cache.

In a APO system, What constraints and precautions do we need to consider while designing a PA and POS to optimize the Live Cache performance?

Sorry, this is not an interview question....just my doubt.

[somnath_manna · Accepted solution]

Hi Vishu,

First of all I just want to mention that hardware is so much cheaper now - hence really you need not worry about system performance if you have sufficient RAM in the APO App / LC Server. Also newer versions of LC are more optimised resulting in better performance.

But then coming to your question - here are the fundamentals:

1. POS is where you define the characteristics which when filled with a unique value creates a key called CVC.

2. PA is where you define the keyfigures. You also define the periodicity i.e. the lowest time granularity at which the keyfigure data will be stored. The next is when you initialise a planing version - you essentially define how many buckets in past and future data for each keyfigure x CVC will be initialised.

Each keyfigure you add in the planning area will have a direct bearing on the amount of LC memory space being considered.

So if you have 50000 CVCs x 50 keyfigures x 150 time buckets (100 weeks in past and 50 weeks in future) = 375 million units, the performance will be worse compared to 100000 CVCs x 20 keyfigures x 120 time buckets (2 years in past in weeks x 20 weeks in future) = 240 million units.

The key is to decide on what would be the lowest level of characteristics - does users ever plan at this level, are all the keyfigures required in the planning area (means you can store and extract the data) or you can actually use some as planning book keyfigures (which display intermediate computation results in the planning book but are not saved) and also the time buckets really required.

Hope this gives some idea.

Thanks,

Somnath

[Former Member · Accepted solution]

Hai Somanth and Harish,

Thanks for the reply. Thats exactly what I want. One final question. If I use these "Auxiliary key figures", the data is not stored in database after planning run. Then how is this data transferred to ECC or PP/DS? or are the Auxiliary key figures such a kind of key figures that you need not transfer the data to any next level?

Thank you.

[Former Member · Accepted solution]

Auxillary KF are normally used for display of interactive Planning calculations and are not saved back to the planning area.

You create these in the planning book using the Keyfigures attributes Tab and used to display calculation results

pre-4.0 you could save this type of KF to the database but in the later versions you cannot.

i remember seeing a thread on your post about days of supply, that the BAPI GETDETAIL can extract this from the planning area . Am not sure if this works...

Pl note, in addition you have temporary KF rows which are used in calculations in Macros and are not visible but are used as a temp storage in between calculations.

[Former Member]

Just to add to what Somnath said ... and though this might seem a little bit off on a tangent, the result is on LC performance

a lot of your PA/POS design will depend on how yoou are going to use it... so

try to get an idea of how your planning books/data view will look like before you create your PA/POS

Define Dimensions logically according to the characterisitics and matching a selection criteria

If you have optimized your planning books/Data views to different sets of users and you know the leels at which the characteristics are going to be accessed regularly, then try to use the concept of Aggregates while creating POS. Data is stored as aggregates at this level and can be retrieved faster -hence giving a semblance of better performance

Do not add too many un-necesary KF if they can be done with temp KF/ planning book KF

Do not load too many macros as default in a book unless necessary. Add them at the correct level. move macros used for batch processing to a different book