Locking Transaction Data 
Concept
If a planner requests transaction data in change mode the system locks the requested data exclusively for this user. BW-BPS uses the SAP lock server to do this. However it uses it in a particular way so that multidimensional data can also be locked using selection tables. This lock concept will now be explained in more detail.
Locks are created independently of the existing transaction data. The system locks exactly that data that is covered by the selection in the planning package and, where applicable, the planning layout (see below in the section “examples”).
The data that is to be locked is specified in a selection table. The selection table is created from the planning package and, where applicable, from selections from the planning layout. Every characteristic that does not exist in the planning level is therefore locked generically as summarization is performed on this characteristic. The selection table contains selections for the characteristics from the planning level. These are single values or intervals of characteristic values. However the selection cannot be restricted for one characteristic. The following rules apply:
· If variables are contained in the planning level, in the parameter groups of functions or in the planning layout these are replaced when the selection is determined.
Replacing variables always leads to a (potentially empty) quantity of single values or intervals. In Customizing take into account that replacing variables of type hierarchy node, attribute, and authorization can lead to a very large number of characteristic values:
¡ Hierarchy nodes: The system calculates all characteristic values from the leaves of the selected subtree for hierarchy basis characteristic und puts these in the selection.
¡ Attribute: The system reads all characteristic values for attribute selection and puts these in the selection.
¡ Authorization: The system determines the authorized characteristic values. These are included in the selection table individually.
· In manual planning the selection of characteristics in the header area is taken from the planning package. This is also the case for the characteristics in the lead columns, as long as the rows in the lead columns are not defined individually.
For data columns and individually defined rows in the planning layout (and also for comparison rows or columns) the selection comes from the planning layout.
· Key figures that are used in manual planning or in a planning function are also relevant in terms of locking: The key figures are seen as characteristic values for characteristic '_BKENNZAHL'.
Selection tables are stored on the lock server in compressed form. So that an adequate number of users can work in planning the system limits the number of records possible in a compressed selection table. The limit is currently 999.
If a user requests new data in change mode the selections already stored on the lock server are read, decompressed and compared with the new selection. During this process no other user in BW-BPS can request locks for transaction data from the basic planning area in question. To this end, the lock server itself is locked for the basic planning are in question with lock structure 'UPC_YS_LOCK_ENQSERVER' and lock entry 'SEM_BPS_TRANSACTION_DATA'. Transaction data in multi-planning areas is always locked using the basic planning areas.
Exceptions to the Lock Concept
In particular circumstances a scenario may occur where the system cannot lock the requested data. For the user, this means that s/he is not able to edit the data. The system analyzes the causes and produces lock messages accordingly.
Case 1: The data requested for a planning area (planning level, planning package) is already locked by another user.
Proposed solution: To avoid this lock situation, Customizing has to be modeled so that different users work with independent data records. If this is not possible, the user who is waiting can notify the user who has set an exclusive lock for the requested data. As soon as this user leaves the planning transaction the locks will be removed.
Case 2: The requested data is covered by a selection table that already contains more than the highest permitted number of records in its compressed version on the lock server. The requested data cannot be locked for this reason.
Proposed solution: Make sure that the selections, and therefore the selection tables, are simplified.
Case 3: The lock server is currently processing other lock requests for the required planning area and can therefore not answer this new lock request. The system renews the lock request after a certain amount of time (seconds). This lock request may also fail if the lock server is overloaded.
Ensure, using transaction SM12, that a lock 'SEM_BPS_TRANSACTION_DATA' is visible for lock structure 'UPC_YS_LOCK_ENQSERVER'. This situation points to complex Customizing:
· A large number of users are using manual planning or planning functions; the planning functions are being executed online.
· Different data is constantly being selected from the database in change mode, for example, by a large number of planning functions within one planning sequence.
· The individual selections are extremely complex; they contain several hundred or even thousand single values or intervals.
Proposed solution: In most cases it is possible to solve the problem by simplifying Customizing. The following points are important:
· Planning sequences that run for a long time should run in background processing.
· The number of records on the lock server must be kept as low as possible. Ensure that selections are simplified. Use intervals in selections whenever possible. Intervals can be locked exactly so that whole areas can be locked by a few records in the selection.
For more information, see Customizing with Reference to the Locking Concept.
If you cannot avoid these problems despite having checked the Customizing, BW-BPS provides an infrastructure that allows you to determine per planning area those characteristics that are to be consulted when setting locks. Normally just a few characteristics are enough to make different users’ selections disjunctive. In cost center planning this could be the cost center (and the controlling area).
For more information, see SAP Note 635244.
Examples
The following examples illustrate the rules for locking transaction data.
The example data in the following table is used as the basis:
Example data
Year |
Customer Group |
Customer |
Revenue |
Costs |
2004 |
IT |
SAP |
1000 |
500 |
2004 |
IT |
IBM |
2000 |
1000 |
2004 |
CARS |
BMW |
3000 |
2000 |
2004 |
CARS |
VW |
4000 |
3000 |
Example 1
In the definition of the planning level the following values have been determined:
Characteristic: Key Figure:
Year = 2004 Revenue
The result would be as follows:
Results table for example 1
Year |
Revenue |
2004 |
10000 |
The system has locked the key figure revenue for all four records (blue area in the example data table) as all records are required to calculate the total value. Any change to one data record will cause the total value to be changed. For this reason, a data record may not be used by another user simultaneously.
Example 2
In the definition of the planning level the following values have been determined:
Characteristic: Key Figure:
Customer group = CARS Costs
The result would be as follows:
Results table for example 2
Customer Group |
Costs |
CARS |
5000 |
The system has locked the key figure costs for the two records for customer group “CARS” as these records are required to calculate the total value. Any change made to a data record would cause the overall total to be changed and therefore may not be used by another user simultaneously.
In the examples given the selection criteria are concordant with the existing records. As this is not normally the case (for example, no transaction data is available), the system creates locks on the basis of the selection criteria. This means that new records that are created during planning are also locked. In this way the system ensures that each user in an exactly specified area can change and create transaction data.