Debugging when navigating out of the web application URL

Greetings,

I have a web application that consumes some screens produced by other dependent web applications. This scenario works fine during runtime. However, when debugging, the debugger stops the debug session as soon as the consumer app navigates out to the external URL (the one of the producer's web application).

Isn't this a valid scenario that promotes the re-use of screens across applications? How is it possible to have the debugger not stop the session? I am not necessarily asking to hit breakpoints in the producer's screens, but have the debugger gracefully resume when back to the consumer web application.

(In this scenario, my consumer's web app passes along the resume URL, that the producer's web app navigates to after its screen terminates, in effect simulating a web-subroutine pattern; perhaps that pattern isn't supported?)

Hoping that this clear enough

Thanks!



Hi Jean-Paul,

I believe this would be possible if the modules consumed those screens as direct references - using an external URL, even if it ends up pointing to an OutSystems application causes debug to stop.

If I understand your last paragraph correctly, you can't do this because you have a callback effect. Are the URLs too dynamic to rely on direct references, or would this cause circular references?

Hello Jean-Paul

If you can't make a direct reference to the screen (because you are not yet on platform 11, or for architecture reasons), I would try a small workaround:

I would have two SS open, one for the Consumer app, other for the Producer App, with the debugger turned on on both.

When leaving from consumer to producer, even if the debugger on the first stops, the debugger on the producer would attach to the request and you would be able to keep going.

In the consumer, you could turn on the debugger again, to when a request is made to it.

Didn't test, and I would prefer to not have to do it this way, but I think it should work.

I'll ask from OutSystems about this.

What's the version of the SS you are using?

Cheers.

Hi Jean-Paul,

If you're using URL's to get to the other module's screen, you can simply also put a debug breakpoint in the preparation of that screen and enable debugging in that module. This way the debugger will also stop when the preparation of that screen is reached.

Afonso Carvalho wrote:

Hi Jean-Paul,

I believe this would be possible if the modules consumed those screens as direct references - using an external URL, even if it ends up pointing to an OutSystems application causes debug to stop.

If I understand your last paragraph correctly, you can't do this because you have a callback effect. Are the URLs too dynamic to rely on direct references, or would this cause circular references?

Hi Alfonso,


To your suggestion, I tried to navigate to an external reference (with an expression computing the dynamic URL), and yet the debugger would stop too.

My last paragraph was just explaining how the consumer's web application regains control after invoking the external screen. There is no circular reference in play here.


Eduardo Jauch wrote:

Hello Jean-Paul

If you can't make a direct reference to the screen (because you are not yet on platform 11, or for architecture reasons), I would try a small workaround:

I would have two SS open, one for the Consumer app, other for the Producer App, with the debugger turned on on both.

When leaving from consumer to producer, even if the debugger on the first stops, the debugger on the producer would attach to the request and you would be able to keep going.

In the consumer, you could turn on the debugger again, to when a request is made to it.

Didn't test, and I would prefer to not have to do it this way, but I think it should work.

I'll ask from OutSystems about this.

What's the version of the SS you are using?

Cheers.

Hi Eduardo,


I am running v11.6.13 of Service Studio.

The workaround that you suggested (to restart the debugging session after the first session stopped) works fine indeed. I was wondering it, that was possible without having to restart. Please let me know if any feedback from OutSystems!


Cheers,

JP


As soon as I have something, I'll let you know.
In any case, I passed this topic to them and maybe they can answer here as well. 

Cheers!

Lennart Kraak wrote:

Hi Jean-Paul,

If you're using URL's to get to the other module's screen, you can simply also put a debug breakpoint in the preparation of that screen and enable debugging in that module. This way the debugger will also stop when the preparation of that screen is reached.


Hi Lennart,


My issue was not to hit a breakpoint in the other module, but to keep the debugging session running on the first (caller) module. Also in my case, using Reactive Web, there is no preparation logic. Thank you anyhow!

Best,

JP

Solution

Ok, I received news from OutSystems.

Because it is a reactive application (this also happens with mobile), the debugging session needs a connection to the browser (that's why you need to debug from the browser launched by the debugger).

When you navigate away, this connection is lost.

So, in this case, indeed, the only way to keep with debugging is to start it again.

Cheers.

Solution

Eduardo Jauch wrote:

Ok, I received news from OutSystems.

Because it is a reactive application (this also happens with mobile), the debugging session needs a connection to the browser (that's why you need to debug from the browser launched by the debugger).

When you navigate away, this connection is lost.

So, in this case, indeed, the only way to keep with debugging is to start it again.

Cheers.


Thank you so much for this update and explanation, Eduardo!

I'll mark your response as a solution. One additional question though: from what you said, I understand that in the case of a traditional web app, the debugger does not need a connection to the browser (or in addition to a connection to the browser), needs a connection to the server. In either case, what is are the protocols that the debugger uses to connect with a) the browser and b) the server?


Best,

JP

Hi Jean-Paul,

I'll ask this to the OutSystems R&D team :)

Eduardo Jauch wrote:

Answer: https://chromedevtools.github.io/devtools-protocol/

Thank you, Eduardo, this is very useful. Now, with respect to traditional web apps (but also for any type of app, when it comes to debugging through server-side actions), I am assuming that OutSystems debugger somehow manages to channel these interactions via the browser...


Best,

JP


I can't affirm, but I would say that server side there is no real difference between web and react. Before being possible to debug client actions in mobile, you could debug server side. Client and server are isolated. But the underlying technology is, indeed, different...