Develop Draft Capable Custom Apps Using BOPF Framework – Part1

Hi All,

We are writing this blog to share our knowledge and to help those who wants to develop draft capable custom applications using BOPF Framework. So basically, through this blog you will get to know that how can you create your own custom SAP UI5 applications based on the concept of draft & durable lock functionality.

To achieve this scenario in the application, we have used BOPF Framework and CDS in the back-end. This scenario is already achievable through template-based application in very easy manner but here we are going to explain how you can achieve the same standard functionality in your custom application.

So before explaining the steps through which you can develop the application, let’s start with the introduction of durable lock and how it is different with SAP Traditional Lock and about draft concepts.

Introduction:

SAP Lock Concept (Traditional):

As we all know SAP ERP is equipped with a special Lock mechanism “that synchronizes database access”. The purpose of this synchronization is to prevent the two transaction/program from changing the same data in the database simultaneously.

How it works?

Before applying locking in programs, we must create lock objects for that set of data. Or we can say SAP Lock concept generally defined as lock objects in the Data dictionary.

A lock object definition consists a database table and the key fields. Based on these parameters, lock can be set. So, when we create a lock object in SE11, then the system automatically generates two function modules with names ENQUEUE and DEQUEUE.  These function modules are used to create/set and release lock in our programs.

Types of Locks

In SAP system, lock set based on parameter, scope and lock mode. So, based on the lock mode SAP has segregated the lock into four types which is S, E, X, O.

Shared Lock or Read Lock (S): Several transactions can access the same record/data at a time in display mode. It allows other transaction to read data but not to write.

Exclusive Lock or Write Lock (E): This lock protects write access to an object which means it provide an exclusive read, write capacity to a transaction, where other transaction can neither read nor write.

Exclusive but non-cumulative(X): This lock is an extending version of exclusive lock with difference is that exclusive lock can be requested several times by the same transaction and release one by one whereas exclusive with non-cumulative lock  can be requested once by the transaction and all further lock will be rejected which means it also protects from further access of data from same transaction.

So, above all three locks are known as Pessimistic locks.

Disadvantages of Pessimistic locks: An object will be locked from the time it is accessed in a transaction. So, for others it will be inaccessible which means data will be locked from the point the transaction gets open. To overcome this scenario, one more lock has been introduced and i.e., Optimistic Lock.

Optimistic Lock(O): This lock initially behaves as a shared lock and later it gets converted into exclusive lock, which means object is not actually locked on the access of transaction. It locks when we click on create or save button (during the time operations performed).

So Basically, in optimistic lock version gets created and data has been fetched according to the version.

So, a question arises when to use pessimistic lock and when optimistic?

Answer – Pessimistic is used when collision is more, or we can say for exact data operation it should be used (like in finance apps).

But there is also one disadvantage with optimistic lock i.e., rollback gets triggered by the data access framework upon catching optimistic lock exception and that leads to loss of unsaved data that is done by users.

Suppose there are two users and both users tried to save the data at the same time then for one user the operation will get performed (based on version generated first) but for other, an exception gets triggered by data access framework and also the user will lost the data.

So, to retain the features of optimistic locking and to enable new feature that save the unsaved data of user, a new lock concept has been introduced i.e., known as Durable Lock.

Durable locks are kind of optimistic lock only having additional draft enabled functionality. These types of locks are long lasting lock because they do not depend on the session/commit work/Dequeue FM. They depend upon enqueue context and persist for the longer time.

An enqueue context is a lock phase in which durable locks are assigned with unique ID along with draft.

Draft – As the name suggest draft is something which is just for temporary. A temporary version of your final document. Or we can say draft is an interim version that has not yet been explicitly saved as an active version.

In application like Gmail, outlook we can see the draft concept but there it depends upon us that we want to save the unsaved changes as a draft or not. But here it is an auto save functionality which automatically get saved in the background whenever user add or change the data in edit mode.

How durable lock is different from SAP Traditional Lock?

Durable Lock Flow

Explanation:  Suppose there are two users User A and User B

User A wants to edit the application record S1. Then in background first validation will happen which check whether any exclusive lock is assigned to User B, or not for that record. If locks exist for User B, then an error message will be displayed to user A. If not, then an exclusive lock will be assigned to User B for time period T and also a draft version will get created along with a draft lock for user A which means two set of lock will be assigned to user A( exclusive lock along with draft lock). As said earlier, durable lock released based on the expiry time which is explicitly set in the framework for that application. If user remains inactive for time period T, then the lock will get released having only a draft version of the record. If no then lock will persist for User A.

Note: Using table SDRAFT_LC_CONFIG, we can check what timing has been set by the framework for the application. Or also, we can check the time limit in CDS which consist business objects creation.

Advantage of Durable Lock

1. It enables data to be changed in all parallel dialogs along with no loss of data.
2. Keeps the unsaved changes if an editing activity is interrupted, allowing users to resume editing later.
3. As a locking mechanism to prevent multiple users from editing the same object concurrently, and to make users aware when there are unsaved changes by another user.

Disadvantage:

There is only one disadvantage of the durable Lock that it is only available for specific SAP application or framework.

And the framework which supports this concept is BOPF Framework. Because BOPF framework provides some additional functionalities to support draft concept at the business object level. In addition to the standard BOs, it is possible to create a specific shape of BOs that is suited for implementing draft qualities. Draft business objects provide code exits for implementing the draft contract and extending the BO functionality based on well-defined BOPF APIs.

Actions generated at root node level

In order to consume draft data in a generic manner, the BOPF framework by default creates standard draft actions, such as EDIT, ACTIVATION, PREPARATION, and VALIDATION, for each draft business object.

Activation action performed to convert draft data into active data.

Preparation action performed to create draft data.

Validation action performed to check the consistency of the objects.

So, this was the whole concept of durable lock and drafting. Now I am going to tell you what development we have done to achieve this scenario.

To accomplish this, we have taken sales order scenario in which user can read/create/edit/delete the sales order. Please see the video for more details.

Steps to create custom Draft capable application using BOPF framework 

/n/IWFND/MAINT_SERVICE

Using this tcode, first register the OData service and then the service will be available to be used by the webide to generate the application.

This is whole the backend development we have done to achieve this scenario.

To know the concept in a very deep manner, kindly visit the below mentioned links.

For Sap Traditional Lock:

https://help.sap.com/doc/saphelp_nw73ehp1/7.31.19/en-US/47/df116e6abf296fe10000000a42189b/frameset.htm

For Draft concept:

https://help.sap.com/viewer/cc0c305d2fab47bd808adcad3ca7ee9d/7.52.1/en-US/a14edfb1f263495a894780c82c916664.html

For Durable Lock:

https://help.sap.com/viewer/6568469cf5a1460a8d85c58b83d21ec2/7.5.6/en-US/0cbb4e75240f449daa282afc986f2719.html

Next Step- In the next blog post we are going to show the creation of draft capable custom SAPUI5 application.

Develop Draft Capable Custom Apps Using BOPF Framework – Part2

Hope you find this blog interesting and kindly follow our next blog to know how we have used BOPF framework containing service in our custom SAP UI5 app to achieve durable lock functionality.

Stay safe, stay happy?

Thanks,

Anubhuti