Hello Progress Community,
I am a newbie to Progress Webspeed. I am strongly feeling the need of a debugger that could make my life easier. I have gone through the Application debugger that comes with Open Edge, but I am not sure if I can use this debugger to debug my HTML files. I have speedscript code into the HTML file and would like my debugger to keep a watch on the variables that are mentioned in the file.
When I open AppBuilder I can see "Debug" option into the Compile menu tab - but it's grayed out (disabled). I have gone through some debugging documents provided on the progress website, but they do not talk about debugging HTML files or how to configure the debugger in order to do so.
Your help is much appreciated and thanks in advance.
Regards,
JT
You don't say what version of Progress you are using which is always important.
I would suggest you read the document: OpenEdge Application Server: Developing WebSpeed Applications, specifically chapter 9: Debugging applications.
Hello Kevin,
Thanks for replying to my question. I went through the chapter that you have mentioned in the thread post. I am coming from the .NET/Java world and there we simply put breakpoints (in HTML, .java, .c); and add a watch to variables that we want to inquire about. After going through the chapter, it seems like there's no concept of using breakpoints for the webspeed files. And instead we use message along with IF CAN-DO (debug-options, "something") to see the results in the server.log file.
But one thing bothers me is that we have a debugger provided by Progress that works perfectly for .p files and we can use breakpoints to pause the execution and watch variables step-by-step. If that could work, why can't we debug HTML files with embedded speedscript and put breakpoints using AppBuilder tool.
I am running OpenEdge Version 10.2A.
If you could direct me to a source that has documentation on how to debug HTML files with embedded speedscript would be of great help.
I really appreciate your time for answering to my questions.
Regards,
JT
You can try running the debugger in 'attachable' mode..
The Knowledge Centre has an article explaingin how to do it (P124313).
Good luck.
Debugging webspeed using embedded speedscript can be done, but it isn't straight forward. The issue is that the .html file is actually converted to a .p before it is compiled. This changes all the line numbers. In addition, there are several include files added to the .p that when compiled further change the line numbers. The result is that your original .html file has gone through a couple of preprocessed transformations before it is actually compiled. The OpenEdge debugger works on the listing files. The line numbers in the r-code debug block actually correspond to the listing file line numbers, and not the original source.
I haven't debugged webspeed stuff in a while but here is one technique. I'm sure others may have other suggestions.
When setting up the Webspeed broker, set the min and max number of agents to 1. This will ensure that you only have to attach to a single agent process and all webrequests will go through that same agent. This avoids the issue with try to debug more than a single sessions at once which complicates things. And you won't miss any webrequests.
Make sure that the webspeed agents have debugging enabled. You need to do this through the Progress Explorer tool, or you can edit the ubroker.properties file, but I don't recommend this.
After you start webspeed, but before you are actually ready to run stuff, attach the debugger to the one webspeed agent.
At the top of your .html file include a speedscript section that runs a very simple .p. Just put a single line of code in that file that prints a message or something. Then you can set a breakpoint on that file and you don't have to worry about line offsets or file name conversions. When the program is run, the debugger will interrupt at the first executable line in the program. Then use step out. This will step back into the program you really want to debug. The debugger will then load the listing file for the and you can debug as normal from there.