SAP vs. DB Transactions

I ve been in the SAP world for a little over 3 years now and I ve come in contact with several SAP consultants. About 60% of these consultants have been ABAPers. Of this percentage, about 80 stand out as the people who know ABAP syntax and little else. This to me is astonishing – in the SAP world(or at least in India) ABAP has been reduced to a collection of keywords used for report writing(more accurately, to fetching data and displaying it as a list).

I have come across very few consultants who grasp the idea behind ABAPs’ Transaction Model and understand why Update Function Modules exist. This post tries to clarify that qualitatively – I will not be giving any examples(code snippets) but will be giving an outline of the entire update process and the need for the same.

The ABAP stack in NetWeaver executes user requests of logged on users using something called Work Processes. There are different kinds of work processes, but the relevant ones for us are the Dialog and the Update work process. To execute any input, such as entering Sales Order data and saving it, from the user a Dialog work process is used. To aid in scalability, each time that a program being executed is waits for some user input, the work process that ran the code until that point is released so that it is available for some other users request. This process of sharing a work process between several users is called ‘Work Process Multiplexing’. It implies 2 things – first that the number of dialog work processes is far less than the number of users in the system and second, each time a work process is multiplexed, all of the user data needs to be rolled-out from the the work process’s local memory so that the next work process can roll-in this data to continue execution.

NetWeaver during this multiplexing ensures that the database underneath remains in a consistent state. It does so by sending a COMMIT WORK to the database each time a user-context(ie user data such as authorizations, currently being executed program data etc.) gets rolled out of a work process.

Now, generally all SAP transactions or programs consists of multiple screens which means that once a screen has been drawn for user input the work process can be released. Therefore, most SAP transactions consist of several implicit COMMITs – implicit because this is done not by the developer but by the application server automatically. The developer issues an explicit COMMIT only at the end of the SAP transaction. This is in essence the difference between an SAP transaction and a database transaction.

Lets take an example to understand this better. Suppose a user fires up VA01, which is for Sales Order creation. What is the sequence of steps that follows?

  1. Program execution starts and the first screen is shown asking for Order Type and Sales Area
  2. Since user input is required, the WP is released. Implicit commit occurs
  3. User enters the data and hits enter. The program processes user input and based on this draws up the next screen which requires the user to enter the Order Header data
  4. Implicit commit occurs
  5. Once header data is entered, user moves ahead another screen to enter the administrative data
  6. Implicit commit occurs
  7. Next the user proceeds to enter the item data after successfully entering which, he presses Save
  8. Explicit commit occurs

The entire sequence above is One SAP Transaction, but consists of Four Database Commits(3 implicit and 1 explicit). It is the job of the developer to ensure that all of the logically related data be updated in the database only during the explicit commit. For the simplified example above, the Sales Order data is split into 3 tables – VBAK(Org data and Header), VBKD(Administrative data) and VBAP(Item data). It is important here to understand, that in case the concept of SAP Transactions did not exist, these three tables would have been updated in their individual DB transactions. This is extremely dangerous since it would mean that in case there occurred a problem while updating the item data, I would have a freak Sales Order with only the header and administrative data and no item data. Database transactions ensure table level consistency at the database but not transactional consistency for business data.

To ensure this, developers use Update Function Modules. These kind of function modules, when called correctly are executed by the Update Work Process(instead of the Dialog Work Process) asynchronously. The way it works is that the developer, instead of passing data to the database in each dialog step, sends all of the related transactional data together in one bucket at the end of the program.

I will not be going into Update Function Modules and Update Tasks now, however the way that the above example of Sales Orders would proceed in this case is as below:

  1. Program execution starts and the first screen is shown asking for Order Type and Sales Area
  2. Since user input is required, the WP is released. Implicit commit occurs
  3. User enters the data and hits enter. The program processes user input and based on this draws up the next screen which requires the user to enter the Order Header data
  4. Implicit commit occurs
  5. Once header data is entered, user moves ahead another screen to enter the administrative data. The header data is passed on to an Update Function Module(UFM)
  6. Implicit commit occurs
  7. Next the user proceeds to enter the item data after successfully entering which, the program passes all this item data to another UFM. The presses Save
  8. Explicit commit occurs. This triggers the execution of  the two UFMs by the update task.

The important thing to note in Step 8 above is that both UFMs(or in other words the sales data for two tables) are conceptually part of one Logical Unit of Work. This means that if either of the 2 UFMs fails(ie. throws an exception) then the database transaction of the other is rolled back.

In this discussion, I have not delved into the workings of Update Function Modules, the different modes of updates and how to use them all in ABAP; nevertheless I hope it has helped clarify the difference between Database and SAP Transactions.

 

Comments

3 comments on “SAP vs. DB Transactions”
  1. Nathan Leach says:

    This is a decent description of the transaction model in SAP.

    I have to wonder, is it really that wise to alienate 48% of the SAP consultants you’ve met in your three years in the field? One of the main strengths of SAP is its community, and while it is growing you will be surprised how small it can be. Those people you alienate may be the ones you need help from later…whether to answer a question or get hired for a job. It’s worth being careful.

    I also respectfully take issue with your description of ABAP as “a collection of keywords used for report writing”. While ABAP is (and always has been) an excellent tool for data extraction and reporting…it is certainly more than that, wherever it is used. You need only take a look at the object oriented capabilities, service oriented architecture, or multiple user interface technologies available to the ABAP developer to get a small test of the larger spectrum of ABAP capabilities.

    Keep writing…in a thoughtful way…and keep learning about ABAP!

  2. adarshatwar says:

    Thanks for your comments Nathan.

    I’m definitely not alienating the 48% of consultants – this post is aimed at them. I absolutely agree with your feelings on the SAP community. We all need each other.

    Also, my personal take on ABAP is not that of it being a mere collection of keywords. As I said in the post, that is how it is perceived as by most of the ABAPers I ve met.

    There are two factors I can think of for this:
    1. If you take a look at the general scene of SAP consultants in India(which I ve pointed out in my post), most of them have a C++ or a Java background(by which I mean they have taken a crash course on the language with no principles of software design). They transition over to ABAP by mapping the language constructs of it with those in C++/Java. This has a big disadvantage – most of the C++/Java literature around focuses on client side programming with no concept of transactions or LUWs while any significant ABAP program is based on it.
    2. The majority of ABAP consultants in India are employed by companies that have a support oriented portfolio of projects. So most of these consultants are not involved in the design/implementation stage of any project. They are solely concerned with maintenance of existing code.

  3. Amazing! Its really amazing piece of writing, I have got much clear idea about from this
    paragraph.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s