Control of write access to plan data
In a planning project it is crucial that write access to the data is closely controlled. There are several different mechanisms that can control access to plan data. These are fixed locks/permissions that are customized during the project phase by the project team and maintained by the administrator and dynamic locks that are automatically set by the system.The first are necessary to generally control which data a given user is allowed to change. This can be done by maintaining authorizations and/or data slices (see slide in this chapter). The latter are necessary as no two users are allowed to change the same set of data at any given time.
Locking of Plan Data
- When a user is working on plan data and changing it the databbwill be locked against changes by other users.
- All records that are used in the aggregation process for ablevel not containing all characteristics influence the value on that level – all records have to be locked
- Two selections lock each other if they use the same characteristic values and the same key figures. It does not matter if a record for the selections exists or not.
- Characteristics that are not in the level will be locked with ‘*’ (“everything”).
Whenever a user accesses plan data (in change mode) this set of data will be locked against changes by other users. The locks will be held as long as the user is using this set of data, i.e. as long as the data is kept in the planning buffer. Thus the locks are only released if the user leaves planning (web interface, planning folder or planning framework).
If you enter the plan data at a highly aggregated level (i.e. a planning level that does not contain all characteristics of the planning Info Cube) then the system has to aggregate the key figure values over all the characteristics that are not in the planning level. All records that are used in the aggregation influence the result (i.e. the sum) and thus the value that the user sees, as well as the value that the system uses for calculating the delta records after data is changed. Thus all these records influence the result of the planning (and delta records) and have to be locked against changes.
Whenever you analyze whether two selections lock each others you must – because of the rule above – always go down to record level, considering all characteristics in the Info Cube. Two selections will lock each other if they have at least one record in common. This record does not have to exist on the data base yet.
Locking Issues in Projects
Locking is a key issue in large projects – design a concept as early as possible and test it!
Performance/Memory: the more characteristics you have in the Info Cube and the more users you have the more memory and time the system needs to handle the locking .
In manual planning all data in the layout is locked – also the comparison columns! (This is different with planning functions – they can read data purely as reference data that is not locked).
To check the locks that are set in the system at a given time use report UPC_ENQUEUE_READ.
If a user wants to release the locks that he is setting then he has to release the data – i.e. leave the planning application.
Performance/Memory: the more characteristics you have in the Info Cube and the more users you have the more memory and time the system needs to handle the locking .
In manual planning all data in the layout is locked – also the comparison columns! (This is different with planning functions – they can read data purely as reference data that is not locked).
To check the locks that are set in the system at a given time use report UPC_ENQUEUE_READ.
If a user wants to release the locks that he is setting then he has to release the data – i.e. leave the planning application.
When the system locks data it saves the selection on the server. When another user wants to access data the system will check against every characteristic whether the user can access the data or whether it is locked.
Thus every additional characteristic increases the memory needed to save the selection and the time needed to check for common values. If you have a look at the characteristics in the Info Cube you will see that many values are the same for all or at least many users (like the fiscal year variant, the planning year, …) and some are different for every user (such as a cost center in cost center planning). You can set up the system in such a way that it ignores all these characteristics that are equal for all/many users for the locking. This saves memory space and run time.
Controlling Write Access: Data Slices
The user locks set by the system are dynamic – the user has permission to change the data but cannot do so at the same time as another user is working on the data. In a project you also have to set more "permanent" locks that are valid for every user (or a certain number of users).
Data slices are a tool to lock certain selections against changes. They can be switched on and off when needed. When using variables you can make them more flexible and even user-dependent (using variables).
A general locking concept for plan data is necessary, e.g.:
- Actual data should not be overwritten.
- Certain plan versions should not be changed anymore after a certain date.
Data slices in BW-BPS
- Are defined for an entire area
- Lock all entries in a selection against changes (manual planning or planning functions).
- You can use variables in the data slices.
- Toggle for switching data slices on and off.
Planning Profiles
Planning profiles and planning folders are independent from each other.Nevertheless profiles restrict the number of entries in the trees a user can see when creating a planning folder.
Profiles restrict the number of objects in the planning workbench a user works with:
Number of planning areas, planning levels etc. in the planning framework.
Number of variables a user can set.
A user can use one profile at a time.
Architecture and Data Buffer
The SAP BW-BPS uses a buffering mechanism for transaction data as well as for customizing. When You change transaction data or any customizing the system keeps these changes in the buffer so you can work without pressing the save button after every change. This buffer is unique within each system mode (and thus user-dependent).
To fully understand the mechanism we introduce the term "detail application". What is a detail application? In short a detail application is anything that is presented in the right screen of the bps0. Thus for example the layout builder is a detail application as is the execution of a manual planning or a planning function.
Whenever you select some data or use a customizing object by starting one of this detail applications (no matter from which front end) the system first checks whether the requested data is already in the planning buffer. If it is already contained in there the system will use the version from the buffer, otherwise the system will select the data from the data base and keep it in the buffer.
The system writes the data back to the buffer whenever you leave one detail application and call the next one ("Commit event"). This model is used in all of the front ends. Thus if you are working in a manual planning layout and press a button for executing a planning function the system will first write the changed transaction data to the buffer, the planning function will get this data from the planning buffer, change the data and write it back to the buffer. After that the manual planning will select the changed data from the buffer and present it on the screen.
You can only leave a detail application if the data (transaction data or customizing) is in a consistent state. If there are any errors the system cannot leave the detail application and write the data to the buffer. You have to correct the errors or press the cancel button. This action only cancels the current detail application: all the data of previous detail application is already "booked" in the buffer.
If you are satisfied with your work you can press "save" at any time. This will save the data in the data base but will keep the data in the buffer (and thus will keep the lock entries). The system will only release the data from the buffer when you leave the planning application. There are two different ways of saving:
- Save Model ,which only saves the structures you customized in the Planning Framework (only available in the menu in the frame work).
- Save All, which saves the Customizing and the planned data (the SAP save button).
- If you are not satisfied with your work you can leave the planning application without saving. Then no changes will be written to the data base.
- BPS never directly changes the data records in a transactional Info Cube but writes back delta records. These delta records are calculated when writing data back to the buffer and are kept in there as well.
- The system also buffers master data such as characteristic values or hierarchies in order to increase the performance.
Related Posts
No comments :
Post a Comment