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 Breakpoint. If you are interested in a live demonstration of the Request-based Debugging, just take a look at this short video:
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 Breakpoint. If 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:´
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:
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.
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:
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
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.
Here are step-by-step instructions for doing this:
1. User B activates request-based debugging and sets 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.
Here are step-by-step instructions for doing this:
1. User B activates request-based debugging and sets 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.
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 Breakpoint. If 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 Breakpoint. If 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.
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 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.
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.
- SAP Managed Tags:
12 Comments
| User | Count |
|---|---|
| 4 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
