Required step before changing locking logic in planning area to Live Cache lock

[sourabh_jain66]

Hi Experts,

In our company we are using common planning area and book for multiple time jones, and because of this we are encountering frequent locking conflicts. Currently we are using detailed locking in place in our planning area. CVCs in each time jone are different, so the idea of using common planning area and books.

After reading lots of threads and SAP help information, i could reach on a conclusion that changing locking logic to live cache lock can resolve our issue.

I need your help on below points;

1) What all precautionary steps, i need to take before changing locking logic in planning area to live cache lock.

2) Is it possible somehow to change locking logic in planning area without deactivating it?

3) Is it required to take data back up before changing locking logic.

4) Other points which i need to take care of before making this change.

Your help is highly appreciated.

Regards

Sourabh

[Former Member · Accepted solution]

Hi Sourabh,

It is great to give suggestions to the experts.

Some users will have Super User access and they will be doing changes.

Get the process chains logs when you got locking issues and check for which user it got locked. Then check the Authorizations.

when you are doing changes at Planning area level it is better to have a backup. ALso suggest other teams and Basis before doing the changes. So that data transfers can be blocked at that time.

Thanks,

Bala.

[sourabh_jain66 · Accepted solution]

Hi Bala,

Thanks for your answer, you are the expert here and i am on the receiving side, so the term expert is subjective .

So, yes there are some user having authorizations to make changes in any of the region, but the issue comes when somebody doesn't have authorization for making change in one specific region and background job gets failed because of locking from that user.

This is happening very frequently.

We have detailed locking in place, can you think of anything which might be the cause of this issue.

Do let me know if you need some more details.

Rgds

Sourabh

[Former Member · Accepted solution]

Hi Sourabh,

Right now I am not sure of other ideas, may be our experts can suggest you..

Thanks,

Bala.

[Former Member · Accepted solution]

Hi Sourabh,

I think in ur PA, there is check box ticked for Detailed lock and Keyfigure specific lock.

But ideally, as per my knowledge, we need to have checkbox ticked for "Activate Livecache lock" and "key figure specific lock".

Using Activate livecache lock will help in avoiding the issues in ur case. If this is checked, if any CVC is being accessed by a BG job in livecache, the same CVC cannot be accessed by any user.

Try this scenario in ur sandbox if you have.

Thanks,

Raj

[sourabh_jain66 · Accepted solution]

Hi Experts,

Can somebody please help me understand this behavior, after putting lot of effort analyzing the system, i am still clueless on this.

Please help.

Rgds

Sourabh

[jagannadhb · Accepted solution]

Hi Sourabh,

We have a similar situation in our project, where a code is written to lock/unlock Planning area only for a particular selection of Users.

So if one Timezone is starting their jobs, they just need to run this Job for their particular user group (created in SU01).

Probably your ABAPer can help you.

Here BAPI_USER_LOCK was used. For further information on this, you can see this thread

Regards

JB

[Former Member · Accepted solution]

Hi Sourabh,

As JB rightly said, try developing a custom program which will kickout the user before the planning starts in your process chain.

Most of the projects does this. This could be one solution to avoid user lock issues.

As you said, the planning area is same for all other markets as well, you can speak to your developer and design the solution.

Thanks,

Raj

[sourabh_jain66 · Accepted solution]

Hi JB,

This is one possible solution, but there are global planners who sits in Europe region and adjust the plan for whole globe.

In case i lock all the users from other regions using this program this will not alow central planners as well to work.

Is there any other workaround / suggestion you can think of in order to allow central planners to keep working and background job also doesn't fail, i might sound silly but that's what we are trying to achieve.

Your help here is really appreciated.

Rgds

Sourabh

[jagannadhb · Accepted solution]

Hi Sourabh

In Our project, we have a LOCK/UNLOCK program with selections of which user groups to lock/unlock. The user groups can be maintained in SU01. Also we have a table where we can maintain exceptions.

Your ABAPer can help you.

Regards,

JB

[Former Member]

Hi Sourabh,

We can change the locking logic of planning area without bringing it down.

The samething i have done in SCM 7.0 environment .

I am not sure about prior version.

Regards,

Mukesh Pandey

[sourabh_jain66]

Hi Mukesh,

Did you took backup of data before changing locking logic, and generate time series after changing locking logic into planning area.

Rgds

Sourabh

[Former Member]

Hi Sourabh,

There is no loss of data if you will check or uncheck the check-boxes in the planning area settings in the locking logic tab. So there is no need of any data back up at all. You can try the same thing in dev/qa system and then you can apply the same in prd system.

Regards,

Mukesh pandey

[sourabh_jain66]

Hi Mukesh,

Thanks a lot for your reply, i will check this in development and quality.

Rgds

Sourabh

[Former Member]

Hi Sourabh,

First of all, as per my knowledge, if you are using the same planning area for different time zones, then there must be dedicated CVCs for each region.

CVCs for APAC region would be different from CVCs for EU region. In this case atleast the planning books or the data views could be different. When a CVC is being accessed by any transaction in livecache, it will lock that CVC and the same CVC will not be available for change for any background process or a user as well.

1) What all precautionary steps, i need to take before changing locking logic in planning area to live cache lock.

You better take the backup of the planning area before u deactivate, change and activate the planning area. And create timeseries.

2) Is it possible somehow to change locking logic in planning area without deactivating it?

I don't think it is possible. And not suggestible.

3) Is it required to take data back up before changing locking logic.

Yes, to be on safer side.

4) Other points which i need to take care of before making this change.

Please get in touch with you Basis team to get some pointers. If they have any dependency to restart the livecache or something like that. Not sure though.

Thanks,

Rag

[sourabh_jain66]

Hi DP experts,

Raj first of all thanks for replying this, can you help me understanding the locking behavior we are seeing in our system.

We have detailed locking activated in planning area, every time zone has its own CVCs, so no common CVCs between timezones.

During night time when a process chain runs in Asia Pacific, there are users still working in Europe region on same planning area / planning book, CVCs are different.

Some times we see process chain encounters locking issue, and sometime there is no locking.

Can you help me understanding this behavoir.

Rgds

Sourabh

[Former Member]

Hi Sourabh,

As per my knowledge, for each region CVCs might be different. As long as the CVC is different there should not be a problem.

Firstly, we have to investigate this. If you have a BG job failed, please check with which user it got failed and which region the user belong to. Check in the spool or the individual messages in RSPCM.

This might happen when data is being accessed in aggregate levels and changes are made. Not sure though.

Thanks,

Raj

[sourabh_jain66]

Hi Raj,

We have done our investigation on this, CVCs for each region are different, no clashes there.

Yes background jobs are getting failed because of locking, the users belongs to region other then for which background job is running.

We have detailed lock in place.

I am not able to understand this behavior, can you please help.

Do let me know if you need some more details.

Rgds

Sourabh