How To: Debug a Webservice/NAS Session in NAV 2013/NAV2015 and above

debugger-featured
FacebookTwitterGoogle+LinkedInWhatsAppEvernoteShare

Finally! How many hours have I spent debugging sessions without UI with MESSAGEs and ERRORs… The good old days.

If you have done that, like me, then you will probably agree that it was not the most elegant way of finding the source of the problem. Have you ever forgotten to delete a funny MESSAGE after a session debugging with that method and had the client bring it up? I know I have.

In any case, we can finally use the debugger tool incorporated in NAV to debug the sessions without UI. That’s great. And this includes ADCS sessions too!

This is something we have been able to do for a while now, but I did not want to lose the chance of writing a post about it.

How can we do this you might say?

Let’s get to it!

First, for all of you that don’t know how to launch the debugger, you need to do this by going to the development environment and go to Tools>Debugger>Debug Session

This will open up a screen similar to this:

debugger-general

 

In there you will find the sessions that are currently opened by any of the access methods Dynamics NAV has available. In my case you can see I have a Windows Client session (you can tell by the “Client Type” column).

Let’s say now that I want to capture a webservice error that I am getting but since the webservice call is too fast I can’t seem to catch it in this window. This also works the same way for NAS sessions.

For this I created a very simple codeunit with a function that raises an error like so:

Codeunit 50000 – Function RaiseAnError(ShowError : Boolean) : Text[50]

IF ShowError THEN
 ERROR('I am an error')
ELSE
 EXIT('Everything is fine');

debugger-codeunitThe code is supposed to raise an error if the parameter we use is set to TRUE. Otherwise it will just show a message saying “Everything is fine”. Fine so far. Let’s test this using SoapUI (you can check out how to do this in the following link).

First, with the parameter set to FALSE.

debugger-test-false

And it works. Sweet.

Now, with the parameter set to TRUE.

debugger-test-trueAnd now we get an error. Great.

If we go to the debugger we will see something like this:

debugger-web-serviceYeah! We got the web service session! Now all we have to do is click on “Debug”…

debugger-error

 

And yes, I tried refreshing the debugger. The session is there active but cannot be opened. This is because the call has already finished but the session stays “Reserved” for a while.

So in order to save this what we can do is click on the “Debug Next” button and trigger the webservice/NAS call that raises the error.

debugger-ribbon

 

(This will open up a debugging window waiting for a break)

And right after calling the webservice that raises the error…

debugger-error-captureIf we accept the message we will see exactly where the code has stopped.

debugger-error-capture-2And by adding a Watch on the ShowError parameter we were able to detect that the reason the error was raised is because the parameter was set to true. Nice debugging! :-)

Of course in the case of a webservice, the webservice call might run into a “Timed out” exception when debugging. It’s natural, we are only human and can only work so fast.

Have a good day, and for those of you still on vacation, enjoy yourselves!

 

2 Comments

Leave a Reply to Tomas Cancel reply