Skip to Content

SAP NetWeaver 7.0 EhP2 brings useful improvements to ABAP external debugging (of course in the New ABAP Debugger!), that is debugging of HTTP and RFC requests which arrive in your ABAP backend system.

This blog introduces the new type of external debugging in ABAP – Request-based Debugging. With request-based debugging you can capture any external HTTP or RFC request for debugging, without regard to the user who submitted the request or the application server at which the request is processed. The execution of the requests of other users is not affected, which makes it possible to debug problems in production systems without disrupting normal operations.

A companion blog focuses on the new user breakpoint, which is now valid on all application servers of an ABAP system:

News in ABAP External Debugging – New User BreakpointIf you are interested in a live demonstration of the Request-based Debugging, just take a look at this short video:


1.  Motivation

Why do you need a request-based debugging? Let’s start with a short motivation. Imagine a Web Dynpro application which represents an online store where you can buy different articles. You want to buy a book, which costs about $50. You put it into the shopping basket and then confirm your online order. After you press the “Confirm invoice” button you notice that suddenly your charge for the book amounts to $13.700. Since you don’t want to spend such a large sum of money for only one book, you need to find out what is going on here. You decide to debug this action.

Imagine you know the Web Dynpro application for this online store and therefore know where to set a breakpoint. The Web Dynpo application is located in the ABAP backend system “ABC”. When you press the “Confirm invoice” button, an RFC call is executed in the ABAP backend system “XYZ”. This RFC call triggers the execution of the function module which processes your shopping order. Therefore you need to set an external user breakpoint in this function module.  After you set a user breakpoint, you start your online store again in browser, buy your book, press “Confirm invoice” button and expect the ABAP debugger to come up. But this does not happen. Instead you once again have spent $13.700. It looks like your external user breakpoint does not work. Why are you having this problem?

 

There can be different reasons for this behavior. One reason could be load balancing. An ABAP backend system can consist of multiple application servers. Load balancing decides which server an external request is assigned to. If your user breakpoint is only active on the application server on which it was set, then a request that is executed on another server does not stop.  However this should not happen to you on NetWeaver 7.0 EhP2, since a user breakpoint is now valid on all application servers of an ABAP system. For details take a look at this blog:

News in ABAP External Debugging – New User BreakpointIf this still happens, then the checkbox Only Current Application Server is checked in the debugger settings of your ABAP system and you just need to uncheck it (Utilities->Settings->Debugging dialog).

The second reason could be user mapping. For example, you start your Web Dynpro application with the User A in the “ABC” system and then a mapping to another User B is executed in the RFC. It can also be a mapping to a generic user – perhaps there is an active job that is running in the “XYZ” system and which maps all external requests to a generic user (e.g. “purchaser”). In this case your user breakpoint does not work because the request belongs to another “mapped” user.

The third reason could be generic user itself. Let’s say you start a Web Dynpro application in a browser with a generic user (if you don’t need to logon because a generic user is stored in the logon data). In this case your user breakpoint does not work because you execute your function as a generic user. If you want your breakpoint to work, you need to set it for this generic user. That means that every user of the Web Dynpro application will end up in the ABAP Debugger, which will come up because of your generic user breakpoint!

The solution to all these problems is provided by request-based debugging. Request-based debugging lets you address a specific computer end user and his or her request. A user breakpoint is set for a specific computer end user, and the debugger is told to stop only for requests of this computer end user.

Contrary to debugging with a user breakpoint the following is ensured:´

  • It does not matter which user submitted the request and which application server currently processes the request.
  • Processing of requests of other end users is not affected, which is essential in a production system.

2.  How to debug HTTP or RFC requests sent from browser

       Let’s take a look how request-based debugging works in the case of our online store Web Dynpro application and in general for all HTTP and RFC requests which are initiated from a browser via HTTP.

The idea of request-based debugging is that there is a GUID (a Terminal ID) which is unique for each end user on a specific computer (PC, laptop,…). After debugging via Terminal ID is activated in the debugger settings, the Terminal ID for this end user on the specific frontend computer is generated and stored on the frontend. If then a Web Dynpro application is started from this computer, then the Terminal ID is sent with the external request using a special browser plug-in. This terminal ID is routed through the browser, then through the Web Dynpro application, then with the HTTP request through ABAP system “ABC” and lastly, is propagated with the RFC request to the ABAP system “XYZ”. The Terminal ID is transmitted with every external request. The debugger starts once the Terminal ID of the request matches the Terminal ID in the user breakpoint.  You can download the browser plug-in that is required for sharing the Terminal ID using the Microsoft Internet Explorer from OSS note 1041556.

 

Here are step-by-step instructions for using request-based debugging for external HTTP or RFC requests initiated from a browser.

1. Activate the request-based debugging and set a user breakpoint:

  • Open your program in the ABAP Editor (SE38) or Object Navigator (SE80)
  • Call debugger settings via menu path Utilities->Settings->Debugging
  • Ensure that you use the New ABAP Debugger (New Debugger checkbox on)
  • Check the Terminal-Id checkbox to turn on the request-based debugging and press Enter. Terminal ID gets generated (you will see it in the input field) and stored on the frontend
  • Set a user breakpoint

2. Download and unpack the browser plug-in from the OSS note 1041556

3. Start the browser plug-in; it in turn will start the browser

4. Start a Web Dynpro application (or BSP application,…)

5. Press Start Transaction button on the browser plug-in* *to transmit the Terminal ID with each request

6. Execute your request

7. The debugger starts and stops at the user breakpoint since the transmitted Terminal ID matches the Terminal ID of the user breakpoint.

 

3.  How to debug RFC requests sent from SAP GUI

Now let’s take a look how to use request-based debugging to capture and debug external RFC requests that come from the SAP GUI frontend program.

To debug SAP GUI requests, you need only enter “/htid” in the Ok code field of your SAP GUI window. The SAP GUI will then send the Terminal ID along with all requests coming from the particular SAP GUI window (more exactly: from the particular external mode). If you then activate request-based debugging in the debugger and set a user breakpoint in your remote function module, you are ready. If an external SAP GUI request is initiated from this SAP GUI window, the debugger will appear and stop at your user breakpoint.

Here are step-by-step instructions for doing this:

1. Activate request-based debugging and set a user breakpoint:

  • Open your program in the ABAP Editor (SE38) or Object Navigator (SE80)
  • Call debugger settings via menu path Utilities->Settings->Debugging
  • Ensure that you use the New ABAP Debugger (New Debugger checkbox on)
  • Check the Terminal-Id checkbox to turn on the request-based debugging and press Enter. Terminal ID gets generated (you will see it in the input field) and stored on the frontend.
  • Set a user breakpoint

2. Open your SAP GUI window and type “/htid” into OK code field. The message “The terminal ID<TID> was set for outgoing requests” appears on the status bar

3. Start your ABAP application in this SAP GUI window

4. Execute your RFC request

5. The debugger starts and stops at the user breakpoint since the transmitted Terminal ID matches the Terminal ID of the user breakpoint

 

4. How to debug HTTP or RFC requests sent by other users

There are also situations in which the user who sets a breakpoint and the user who sends an external request are two different end users and the request is coming physically from a different frontend computer (PC or laptop). You can experience such situations for example in support, when a customer runs a Web Dynpro application that calls a remote function module, which you in turn wish to debug locally on your own PC. It could also be that you need to logon into the customer network (with SAP GUI remote or with a Browser via WTS) and initiate there an HTTP or RFC request which you need to debug locally on your computer.

So let us see how to use request-based debugging in these situations. We will demonstrate this for both types of external requests:  RFC and HTTP.

In the case of HTTP requests from a remote browser you activate request-based debugging via the Terminal ID of your user on your local machine and set a user breakpoint. You then inform the user at the remote browser about this Terminal ID. You can send it via e-mail or relay it by phone. The user of the remote browser downloads the browser plug-in from the OSS note 1041556 and starts it. The browser plug-in starts the browser, the remote user starts a Web Dynpro application and types the Terminal ID in the TermID field of the browser plug-in (or you do it yourself, in case you serve the remote browser).  From then on, all requests from this remote browser are associated with the Terminal ID of your user and your local machine. If an HTTP request is initiated from the Web Dynpro application within the browser, then the debugger will start locally on your machine and stop at your user breakpoint.

/wp-content/uploads/2011/05/rbd_gui_diff_users_100253.jpgHere are step-by-step instructions for doing this:

1. User B activates request-based debugging and sets a user breakpoint:

  • Open your program in the ABAP Editor (SE38) or Object Navigator (SE80)
  • Call debugger settings via menu path Utilities->Settings->Debugging
  • Ensure that you use the New ABAP Debugger (New Debugger checkbox on)
  • Check the Terminal-Id checkbox to turn on the request-based debugging and press Enter. Terminal ID gets generated (you will see it in the input field) and stored on the frontend.
  • Set a user breakpoint

2. User B informs the User A about his Terminal ID (e.g. sends it by e-mail)

3. User A opens his SAP GUI window and types “/hset tid=<tid>” into OK code field. The message “Terminal ID for outbound requests was set” appears on the status bar

4. User A starts an ABAP application in the SAP GUI window

5. User A executes an RFC request

6. The debugger starts up at the user breakpoint of User B, since the transmitted Terminal ID from User A (which is the Terminal ID of User B!) matches the Terminal ID of the user breakpoint.

In the case of HTTP requests from a remote browser you activate request-based debugging via the Terminal ID of your user on your local machine and set a user breakpoint. You then inform the user at the remote browser about this Terminal ID. You can send it via e-mail or relay it by phone. The user of the remote browser downloads the browser plug-in from the OSS note 1041556 and starts it. The browser plug-in starts the browser, the remote user starts a Web Dynpro application and types the Terminal ID in the TermID field of the browser plug-in (or you do it yourself, in case you serve the remote browser).  From then on, all requests from this remote browser are associated with the Terminal ID of your user and your local machine. If an HTTP request is initiated from the Web Dynpro application within the browser, then the debugger will start locally on your machine and stop at your user breakpoint.

/wp-content/uploads/2011/05/rbd_http_diff_users_100254.jpg

Here are step-by-step instructions for doing this:

1. User B activates request-based debugging and sets a user breakpoint:

  • Open your program in the ABAP Editor (SE38) or Object Navigator (SE80)
  • Call debugger settings via menu path Utilities->Settings->Debugging
  • Ensure that you use the New ABAP Debugger (New Debugger checkbox on)
  • Check the Terminal-Id checkbox to turn on the request-based debugging and press Enter. Terminal ID gets generated (you will see it in the input field) and stored on the frontend.
  • Set a user breakpoint.

2. User B informs the User A about his Terminal ID (e.g. sends it by e-mail)
3. User A downloads and unpacks the browser plug-in from the OSS note 1041556
4. User A starts the browser plug-in; it in turn will start the browser
5. User A starts his Web Dynpro application (or BSP application,…)
6. User A types the Terminal ID into the TermId field of the browser plug-in
7. User A presses Start Transaction button on the browser plug-in to transmit the Terminal ID with each request
8. User A executes a HTTP request
9. The debugger starts up at the user breakpoint of User B, since the transmitted Terminal ID from User A (which is Terminal ID of User B!) matches the Terminal ID of the user breakpoint.

To report this post you need to login first.

12 Comments

You must be Logged on to comment or reply to a post.

  1. Mike Howles
    This was a great post.  As a habitual debugger, this is great news.  Debugging HTTP and BSP in Ehp1 can be a pain at times, especially when more than 1 app server is used.
    (0) 
  2. Trevor Naidoo
    Hi Olga, thanks for this blog.

    I was wondering though, are there any plans to take this a step further. Let’s say for example I don’t want to be tied down to using an Internet Explorer reliant plug-in. I want to be able propagate the TID in the HTTP header of the HTTP request. So user B will still go through the steps you’ve mentioned in the blog (breakpoint & TID) & then forward the TID to who ever is doing the HTTP call, they will populate the TID & pass it through in the HTTP header, the Abap web service / SOAP runtime is able to recognize this TID header value and if external debugging has been activated for TID processing then the debugging session will kick off on user B’s terminal.

    At the moment, you can activate the external debugging for a particular user, the whole app server or by virtual host, why not add TID? One can also set things like logon language in the HTTP header already. If it’s done this way it would eliminate the Internet Explorer (which I only use if there is a dependancy on it but prefer not to) dependance & the person initiating the HTTP request can use any technology he can possibly imagine that can initiate an HTTP call.

    Just a thought 🙂

    (0) 
  3. Peter Cutting
    Hi
    * I have just started working on WAS/ABAP support and I can tell you that error tracing is a PITA because debugging is basically not possible as things are. Which is pathetic considering its 2011

    * Unfortuntately I dont see the TID setting in SE37 so I guess we have an old NetWeaver version. Oh well

    * I am not sure I understand the TID usage. I guess the TID is generated in SE37 and then *pasted* into the IE plugin. Is this correct?

    * Is it reasonable to ask an end user (having a problem) to install the plugin in order to debug. Probably not, which is a shame. Still atleast I may be able to debug my own requests one day

    * If an end user could just add /tid=IjustMadeThisTIDUp to a URL – that would be fantastic from a debugging perspective. This should be SAPs goal

    * Often I initially do not know which RFC is interesting and its a PITA to find out. Why cant I set a breakpoint for ALL incomming requests with a defined TID?

    Peter

    (0) 
    1. Olga Dolinskaja Post author
      Hi Peter,
      thank you for your useful comments. I will try to give a reply to some of them.

      * You have TID setting starting with NetWeaver 7.0 EhP2 which is now generally available for all customers.

      * For error analysis you may want to try out in the EHP2 the new transaction SAT, successor of the SE30(see my correspoding SDN blogs about it). In some cases the SAT tracing is more effective error analysis then debugging.

      * After you activate debugging via TID in SE37, TID is generated and stored in the Registry for your user on your machine (PC, laptop etc.). After you started your application with IE plugin, TID gets transmitted with each RFC or HTTP request to your target backend system.

      * In the chapter 4 of the blog you can see how you can debug in support customer requests with TID on your machine.

      * If you activated debugging via TID and set a breakpoint, the request-based debugging becomes active for ALL incoming requests, which trasmit TID to your system via browser plugin or via SAPGUI)

      * TID in the HTTP header and browser independence would be great, but unfortunately due to the limited development capacity in the corresponding development units it has to be proritized along with other development requests. Anyway I will discuss it with the development

      Best regards,
      Olga.

      (0) 
      1. Yuri Ziryukin

        Hello Olga,

        did you update the blog recently? Chapter 4 of the blog is not shown on my PC. Am I the only one having this issue?

        This article is interesting for me, especially debugging customer’s requests with TID on my machine. If possible, could you please resend me the complete article per mail to my SAP e-mail address?

        Thanks in advance,

          Yuri

        (0) 
  4. Riccardo Escher
    Dear Olga,
    thank you very much for you blog, I can hard hadly wait for EHP2.

    But already I had a look at the SAP note 1041556 you mention, which leads me to note 1435190, where with BIG disappointment I can read that the SAP Client Plug-In is only available for MS Internet Explorer (obviously only for Windows).

    When will SAP stop the embargo of non MS clients?

    (0) 
        1. Olga Dolinskaja Post author

          Hi Riccardo,

          I’ve just repaired the blog. Unfortunately it went corrupt during the SCN migration to the new platform.

          Now all links should work and the content should be correct.

          Best,

          Olga.

          (0) 

Leave a Reply