skip to main content

SAP NetWeaver Newbie

SAP Transaction Steps

SAP uses a 3 layer architecture. The presentation layer is typically where an end user triggers an SAP transaction; the application layer runs the programs required to fulfill the transaction using database layer for persistence.

  1. When the user has triggered a transaction (at t0), the request flows through their front-end to the application server, over the network.
  2. The request reaches the dispatcher (at t1). If the dispatcher finds a free work process that can cater to the request, the request is assigned to the WP. Otherwise, the request will be held in the dispatcher queue until a free WP is available (t2)
  3. An SAP transaction is usually a series of logical units of work. Each logical step may be executed by different WPs. During the change in the WP executing the transaction steps, the user context (internal tables, variables, screen lists etc) is retained in roll memory through roll-ins and roll-outs. The WP copies the user context from roll memory into its local memory (roll-in at t3) to begin processing the request.
  4. The SAP programs, screens and CUA objects are maintained in SAP buffer. The WP uses them to process the request. If these objects are not available in the buffer, they are loaded (from the database) or generated  (if required) at t4
  5. Now that the WP has the programs, user context with it, it start processing the request. A typical transaction involves accessing and/or changing database records. Before it begins the changes, it request for an enqueue (t5) and once the enqueue is set (t6) it sends the database SQL query (t7). The work process resumes further processing when it receives the response from the database (t8).
  6. When the WP completes the request, it sends the output to the front-end (t9) and rolls out user context. (note the two t9's in the diagram). The output is displayed to the end-user at t10 completing the transaction.


  1. Keep up the good work,
    Yes it is explaned clearly.


  2. Thanks for the wonderful explanation, it clarifies many of my questions. Just wondering one more thing, in the step 3 you mentioned each logical step may be executed by different WPs. Then how dispatcher knows how many units of work need to be assigned to WPs and how the other WPs know if previous WP has finished?

    1. Hi Jeff, Let us assume you have called a txn code ABC. As soon as you call ABC, a screen to input values is presented to you. This is done by a WP(i). You now feed values. While you are entering the values, there is no WP waiting for you to finish. Once you have input the values, you save them. The saving of values is executed by WP(ii).

      So, you, the user, are the one in charge of executing the transaction. Dispatcher/WP doesn't know what you are going to do next. During each LUW (calling txn code, pressing save button after entering data), a call is sent to the dispatcher which assigns a free WP.


Email Subscription

Get every new post into your inbox by subscribing us.

Want a reason to subscribe?
1. This sitemap might convince you to subscribe.
2. We do not misuse email IDs. We respect privacy.

© 2008 - 2017 sapnwnewbie. All rights reserved.