External Debugging of an Application of another SAP User in other Location in another Machine/System

Share on Facebook36Share on LinkedIn203Tweet about this on TwitterShare on Google+0
Please Share!!

Today, we would look into a very useful tip in ABAP which I did not know in my more than a decade-long SAP career. As we keep on saying, no one can know everything in ABAP. If someone claims s/he knows almost everything in ABAP then either s/he is lying or s/he is GOD! Reverve her/him. 🙂

The other day, one of our end user reported an issue in one of our application program in our pre-production system. Everything worked properly and as per business need in development and quality system. But something went wrong in pre-production. I did not have the authorization to execute the t-code/program in my pre-production system (as it was the copy of actual production system). Being a developer, I had debug access and wanted to debug and see what was going wrong but I could not as I did not have the authorization to execute the t-code/program. The other problem was, the user being an end user, did not have authorization to Debug.

This was a catch 22 situation. The user can execute but cannot debug. I can debug but cannot execute. And the user was on the west coast of the country and at that time I was at the eastern part of our country.

The easiest alternative would have been to raise a service request to get authorization for me to execute the t-code in pre-prod. But it would have taken some time to get the approvals from all departments.

Luckily one of my friends told me he read something about /hext user = username somewhere. This gives the person who executes this command to allow the other user mentioned in the command line to take over his/her session and debug.

Confused?? Let us take a real example with real names.

Say Business end user’s name is Karyn (sap user id 00217) and Developer’s name is Sergio (sap user id 00951).

Since Karyn has the authorization to execute the t-code, she will put the command as /hext user = 00951 in her system in SAP sitting far away on the west coast. Important to notice here is, she put the user id of Sergio, not herself. This means she would like Sergio to do the Debugging. She would just enable the debugger and execute the session.

PS: There should be a space between /hext and user and = and username.

external debugging

Since Sergio wants to debug he needs to put an external break point in his system.

External Debugging of others Session and Application

Since Sergio wants to debug a session of Karyn, he needs to maintain Karyn’s id in the External Debugger username as shown below.

External Debugger user name

If you get the message “You are not authorized for the external debugging of user 00217” while trying to save the other user’s id, then go to the bottom of this post for another trick. Bonus Trick. 🙂

You are not authorized for the external debugging of user

Now ask Karyn (end user) to execute the t-code and enter the command /hext user = 00951.

In the above screen shot check at the bottom right, it has Karyn’s user id (00217) and in the command, we wrote Sergio’s user id (00951).

She will get a below pop up message. Basically, it is a warning to the user that his/her session would be debugged by someone else.

Ask her to press ok and execute the program. The moment she hits the execute button.. abracadabra…

You would see a debugging session on your screen far away on the east coast as shown below. 🙂

Check at the bottom right of the below screenshot, it has Sergio’s user id (00951).

Now, you are a happy ABAPer. Debug, get the root cause and provide the solution. No need of screen share, not need to get special approval to execute the program and no need to be on the same machine/system and no need to be in the same location. How convenient. Isn’t it? 🙂

The end user, Karyn should not cancel the session in her machine when Sergio is debugging. If she cancels or exits from it, then the debugging session will end at Sergio’s end. In case, Karyn really wants to forcefully exit, she can put the command /hx and both of them would exit.

Also ReadHow to enable table entries maintenance in SE16N 

Now the bonus tip for today which we promised above. If you ever get the error message “You are not authorized for the external debugging of user XXXXX”, go to se37 and open FM “SUSR_CHECK_DEBUG_ABILITY”. Put a debugger as shown below.

Do your activity again, i.e assign another user and hit OK.

It will stop at the breakpoint in the FM. Just change the SY-SUBRC to 0. You are done. 🙂

SUSR_CHECK_DEBUG_ABILITY

Of all the power give to ABAPers, I think, Debug with Replace is the strongest one. This is key to any closed doors for the ABAPers.

But as Spiderman said, “With great power comes great responsibility”. So it is our duty to not misuse it but use it responsibly.

Viva os ABAPers (Long live the ABAPers in Portuguese)!!

We put a lot of effort in conceptualizing, testing and writing each and every article. If you could pass this link to at least 5 colleagues/friends who you think would benefit from our post, it would be a great favor to our team. We want our articles to reach to as many audiences as possible so that everyone would benefit and our team would remain motivated and our work does not get lost in this huge ocean of the internet.

Please, please share our post in your professional and social media and introduce your friends/colleagues/co-workers to our blog page.

Also, check our popular step by step tutorials on some of the important topics of SAP ABAP.

1. ABAP for SAP HANA Tutorials
2. ABAP Web Dynpro Tutorials
3. GOS Tutorial
4. OOPs ABAP Tutorial
5. HANA Tutorial
6. SAP Netweaver and OData Tutorial
7. SAP Adobe Form Tutorial
8. SAP Fiori Tutorial
9. SAPUI5 Tutorial
10. SAP Screen Personas Tutorials

 

Share on Facebook36Share on LinkedIn203Tweet about this on TwitterShare on Google+0
Please Share!!

About the Author

Sérgio Serra
Sérgio Serra

Sérgio is an SAP Certified Consultant who was pursuing a Computer Sciences Engineering Degree at the reputed Instituto Superior Técnico, Portugal. He currently works at RTL Group, Luxembourg. He has more than 11 years of IT experience and loves to take walks with his dog and, only occasionally, his wife.

Find more about him on LinkedIn.

30 Comments on "External Debugging of an Application of another SAP User in other Location in another Machine/System"

  1. Great wiki, really usefull, easy and works nice … the thing is .. I´m not sure if I want to my users know this functionallity XD

    congrats for this blog, it is awesome.

  2. Gerhard Lang | July 12, 2017 at 1:32 am | Reply

    I appreciate this hint, making life for devs much easier when it comes to support remote locations.
    Thank you Sergio!

    • Thank you Gerhard. We are glad, you think this hint would help you do your work better. Please keep visiting and leaving your feedback.

      Thanks to Segio for sharing such useful information.

      Regards,
      Team SAPYard.

  3. Aditya Bhargava | July 3, 2017 at 3:29 am | Reply

    I have a question here.. if the Dev doesn’t have debug access and only general access to that system to view programs and all.. Will this still work ? As, Devs maybe given General access but not Debug access.

    • Hi Aditya – Developers need to have debug access. Ideally this trick is useful in Quality system where Developers have debug access but no access to run a particular t-code.

      Thank you for stopping by and leaving your question.

      Regards,
      Team SAPYard.

  4. Loved it. A very new thing in ABAP for me.

  5. From which ECC version its available? I am using EHP6, it says function not possible

    • Hi Murali – It should be available in EHP6. Make sure to have space between words.
      /hext User = Username

      Also make sure, the Username is not of the person who is logged in. It should be of the other person who want to debug. Also, the other person should have SAP session opened and external breakpoint set for the person who is using /hext User.

      Initially, I also got that message. But once I took care of the above points, it worked.

      Try and let us know.

      Regards,
      Team SAPYard.

  6. Thanks Raju for the response. A very useful tip indeed.

    • Thank you Anbu. We are glad, we were able to explain you properly. 🙂 Please keep visiting and leaving your feedback.

      Regards,
      Team SAPYard.

  7. Wouldn’t the developer require a debug change right for this?

    • Hi Mohit – Thank you for leaving your question. Yes, the developer would need Debug access (but debug with change not necessary).

      Regards,
      Team SAPYard.

  8. Didn’t know the user command, but use the User settings in ABAP Editor -Debugging tab a lot!

    • Thanks Steven – True.

      Seems not many know about this variant of debugging. But I think this trick comes handy when the developer does not have access to execute certain t-code while the business/end user does not have access to debug.

      Regards,
      Raju.

    • Sérgio Serra Sérgio Serra | July 6, 2017 at 4:39 am | Reply

      Hello, the user settings-> Debugging tab is useful to debug WebDynpro applications, for example, but I could never get it to work while simply debugging someone else’s user that is currently in SAPGui.
      Especially when that user is using a remote connection. With this tip, that finally works.

  9. If we just keep an external debugger with the end user’s id that should not be enough ?
    Am confused, what is the additional advantage we get here with this commanda ?

    • Dear Anbu,

      End User is executing the t-code in her machine. That t-code session becomes visible in your machine now. Does that ring the bell? There is movement of session from one system to other system seamlessly.

      With just external debugger with the end user’s id, you can debug it in your own system/machine only. If the end user does not have authorization to debug, she will not be able to debug in your machine. If you do not have authorization to execute that t-code, you cannot debug.

      With this command, end user who does not have authorization to debug but has access to execute the t-code can trigger the debugging session in her machine and the ABAPer who has access to debug can see that session on his/her machine.

      You need to read the article one more time to appreciate it. :-). I would suggest, do it practically. Ask one of your colleague to execute some t-code in his/her system. You sit at your desk remotely and see his/her session in your machine.

      Please let us know, if you still do not get it.

      Regards,
      Team SAPYard.

  10. Great info. Thanks a lot. Didn’t know this after >20 years SAP, most of it in development.

    • Dear Martin – Thank you very much for stopping by and leaving your comment. Good to learn that we were able to provide something useful to a hands on development consultant with more than 20 years of experience. 🙂

      Please keep visiting and leaving your feedback.

      Regards,
      Team SAPYard.

  11. Srinivas Rao Srinivas Rao | June 17, 2017 at 12:23 pm | Reply

    Wow…!! This is something which even I did not know in my decade long career. Thanks for sharing Sergio.. 🙂 Excellent blog !!

    • True Srinivas. No one in our SAPYard Team knew about this too. 🙂 . Thanks to Sergio for this enlightening post. We are sure, all our readers would definitely benefit from this trick.

      Regards,
      Team SAPYard.

  12. Kuldeep Joshi kuldeep joshi | June 16, 2017 at 1:42 am | Reply

    bravo raju

    • Hi Kuldeep — Long time. Thanks for visiting and going through this beautiful trick.

      Bravo to Sergio who shared this tip. 🙂

      Regards,
      Team SAPYard.

  13. Pratham kapoor | June 16, 2017 at 12:20 am | Reply

    This is really helpful.. Thanks a lot Serigo

  14. prakash reddy | June 16, 2017 at 4:01 am | Reply

    Thank you Serigo. Nice post ..

  15. Thank you Carmelo. Glad you liked it.

    Special Thanks to our expert Sergio who shared this useful tip.

    Regards,
    Team SAPYard.

  16. Nice post!! Thxs for sharing!

Leave a Reply to SAP Yard Cancel reply

Your email address will not be published.


*