LiveCache locking for SNP planning area

[Former Member]

This article explains the use of “Activate Livecache lock” in a custom SNP planning area.

Background

We faced below issue after APO upgrade from version 7.0 to version 7EHP2. A number of SNP copy  jobs  /SAPAPO/RTSCOPY  started failing . SAP informed that locking logic has been improved for SNP (note  1318667 - Incorrect lock entry for SNP aggregate 9AMALO). In our case the note got implemented as a part of the upgrade and after upgrade jobs in our quality system  failed with message "Lock table overflow".

The number of locks in SM12 are controlled by profile parameter  enque/table_size.This is maintained by BASIS team. The parameter value shouldn’t be increased beyond a certain limit.

Possible solutions to this problem can be

1. To limit the selection of copy. Each large step has to be replaced with smaller selection steps . This can lead to more maintenance issue as the selections need to be updated regularly.

2 Use a macro to copy – If the system has large number of time series KF  then a unique macro needs to be created for each copy. Macro will have more run time.

3 Use the “Activate LC lock “option for the custom SNP planning area.This option was implemented and details are below.

Consider a Custom planning area with three time-series KF as shown below.

Case 1 : "Activate livecache lock" is unchecked.

/SAPAPO/RTSCOPY was run with below selection.

SM12  shows a very large number of locks . This is a representative screen shot and in our actual test the job failed with table overflow.

Case 2 :"Activate livecache lock" is checked.

SM12 locks show only one entry with reference to LCA_GUID_STR .

Report  /SAPAPO/TS_LC_DISPLAY_LOCKS   shows the below and more information is visible in the details button.

SAP note :1988958 ( Data is locked: How to find out locked planning objects when using liveCache locking logic) explains the above report.

If the planning area has inconsistency then the report fails with the below message . Same can fixed by running consistency reports and OM17.

The change in locking logic of planning area can have huge impact and must be tested thoroughly. Some of the scenario which we tested are :

1. Same selections + Same planning version : Locking logic is working as expected  and second occurrence is locked out . The first user was in change      mode and second user got "selection locked" message.
2. Same selection + Different version : No Locking  message for 2ned user as expected
3. Different selection + Same version : No Locking message  for 3 users as expected.

Conclusion: "Activate Livecache lock" is a good option for SNP planning area  and will prevent table overflow error.