Debugging HTML and/or Webspeed applications - Forum - OpenEdge General - Progress Community

Debugging HTML and/or Webspeed applications

 Forum

Debugging HTML and/or Webspeed applications

  • I have an application that I inherited from someone who is no longer here.  It has HTML, Speedscript and 4GL code in it.  I have set up a webspeed broker on my desktop, it has debug enabled, it's set to Development, it has only 1 agent and it runs fine.  However I want to debug it to understand the flow of certain things the users can do and/or enter and have been unable to figure out how to do so.  I have Opened the OE Debugger and tried to attach to the process (should only be 1 since I only have 1 agent).  I use the "Get List" button and only 1 item shows up but if I try to attach to it, it comes back with an error saying it's busy.  I've read things about the -debugReady on startup, but that seems to be more the 4GL stuff in the .pf file (at least I think) and not for an HTML web page.  Can someone give me step by step instructions on how to run my program on http://localhost(....) so that I can use the OE debugger, set breakpoints etc?  I don't want to do the messages in the code if I can help it because it's a complex app that calls many other programs based on what the user's authority is at login, what parameters they have set on their profile etc and I don't want to have to put messages in tons of programs.  Doing messages seems archaic given that the 4GL can be debugged with breakpoints etc with the debugger.

  • You can definitely use -debugReady startup parameter.  You can put the -debugReady startup parameter in either a .pf or directly in the agent startup parameters.  Both OpenEdge Explorer and Progress Explorer have a place for startup parameters where you can add it. 

    If you are only using a single agent you can provide a port number after the -debugReady option.  If you don't, OpenEdge usually starts with 9999 and decrements for each agent based on whatever port is available.  You can check the server.log file for the port number as the agent will add a message indicating which port it is using.  Once you have the port number, provide the host and the port number and the debugger should attach to the agent.

    You can find the 10.2B docs here:

    http://communities.progress.com/pcom/docs/DOC-103525

    Fidn the one named Debugg and Troubleshooting.  It has a lot of information about your options.

  • In my setup, there is a port for the Broker and a port range for the agents. Which port do I need to use? When I look at my logs, I see connected messages but it's not a number even close to the port range. I see messages like "The client C-0002 has disconnected from the broker. (8084)" and I don't know if 0002 is the port. I do see the port used for my broker in a header part of the message that looks like this "[10/06/17@13:57:58.122-0600] P-000996 T-L-3057 3 UB Basic". My broker is set to use 3057 but I don't know what the T-L-3057 is. I see a T-C-0002 so I'm assuming that is the connection for the client C-0002 it refers to above. I have the -debugReady flag set in my agent startup parameters, but no port because I didn't know what to put.

    Thanks for responding!

  • Never mind. I finally got it working! Now maybe I can make some headway into this problem! Thanks!!

  • I'm glad you got it working.

    Your said broker is set to use port 3057.  This is the port that the Webspeed messenger uses to communicate with the broker.  The debugger will have its own port specified using -debugReady

    For -debugReady you can use any port above 1024.  Usually 9999, but really anything will work as long as it isn't already in use.

  • This message: "The client C-0002 has disconnected from the broker. (8084)"

    The C-002 is the client thread identifier.  If you have a message statement in your code you would see this number as part of the beginning of the message line where your message was printed.

    The message format always includes the date, the process id, the thread where the message came from, the logging level, the logging subsystem, and the type.

    "[10/06/17@13:57:58.122-0600] P-000996 T-L-3057 3 UB Basic"

    In this case, the thread identifier is T-L-3057.  This is broker thread, and it includes the port number as part of the name of the thread.

    This is all to help you figure out where a message came from.  For example, if you have  multiple agents, and they all print messages, it is helpful to know which agent is printing the message.

  • I did get it working using 9999 so thanks for the confirmation.

    So one more question. My debugger attaches now, but if I run my html code, it comes up saying "No Debugger listing file available for web\objects\web-disp.p. I answered ok and then clicked on the 'Step Out' button but Over in the right hand side of the debugger pane, I never see my program that I want to add the breakpoint to. I created a DEBUG.p program that does nothing but display a message and I added the call to this at the top of my html code. If I keep clicking Step Out or Step Into, it brings eventually brings up my main screen without me ever getting a chance to add a breakpoint on the line in DEBUG.p. I know it's calling it because there is a message in the log.

    Any thoughts? Is it because there isn't a listing file for DEBUG.p? Usually it gives an error like the one above saying so but I never see that.

    Kristi

  • There are several different ways to set break points.  The two following are probably easiest.

    1.  What you want to do  is (after you attach the debugger) select edit->breakpoints.  On the  procedure name field type in the name of your program or the name of a  procedure in your program where you want to stop.  Usually you want the  name of one of your procedurese, And then run your program from the  browser.   The debugger should stop on that procedure.

    2.  Another way to is add this line of code to your program:

    debugger:set-break().

    This will make the debugger stop on that line (assuming it is attached), and then you can continue from there.

    web\objects\web-disp.p is the "main" program for Webspeed.  You can view the source for it in your install directory under src/web/objects/web-disp.p.  You don't want to do "step out" on this program as there is no program to return to since this is the startup program (-p parameter for the agent).  Doing that is the same as "run until it finishes".

    How you debug Webspeed programs depends on how your program is written.  If you used "cgi-wrappers" in which everything is just a .p program with some includes and a whole bunch of {&out} statements, you can simply open the file (from file->open) in the debugger, and then set a breakpoint.  If you used speedscript where  you write a .html file, and then compile it, then things are harder.

    The stand-alone OpenEdge ABL debugger (the one you are using) works on debug listings.  Debug lists are preprocessed to merge the .p and all of the include files into a single output file.  This output file is what the debugger uses to display line information and to set breakpoints. Hence the message about the missing debug listing.

    If you are using speedscript style programs, then these files are preprocessed and written out to an intermediate file before they are compiled.  The AppBuilder and the WebTools program normally hides this file from you.  This changes the line numbers and also prevents you from getting a proper debug listing.

    If you open web-disp.p using file->open you can set break points on it that way if you want to see the internals of webspeed.

  • THANK YOU, THANK YOU, THANK YOU! You have helped me tremendously! I had added breakpoints just by viewing the listings and I didn't know you could do it with the Edit method. I'm very new to Progress 4GL and Webspeed so still learning!

    Thanks!

  • Wow, I thought I was good to go, but I'm not. So I added my breakpoint and it works. But from what I read from someone on the web, if I did it this way, then I would supposedly be able to step into the html and speedscript code. That doesn't appear to be happening. Within the html, there is speedscript code that contains .p source and it's inside of this that I want to debug. How do I debug the html/speedscript stuff? It just tells me there isn't a listing, which is true because I didn't compile it the same as I do the .p code. Using Webspeed's workshop, there is a compile button but I don't see that it gives you the option anywhere to create a listing file and the debugger wants that.

  • Using Webspeed's workshop, there is a compile button but I don't see 
    that it gives you the option anywhere to create a listing file and the
    debugger wants that.

    From the webspeed workshop, which is the web browser interface to WebSpeed, AFTER you compile a file, there is an option to save the .w file.

    So I added my breakpoint and it works.  But from what I read from
    someone on the web, if I did it this way, then I would supposedly be
    able to step into the html and speedscript code.  That doesn't appear to
    be happening.  Within the html, there is speedscript code that contains
    .p source and it's inside of this that I want to debug.  How do I debug
    the html/speedscript

    Normally WebSpeed won't run a .html without compiling it first into a .r file.  This ends up limiting the debugger for generating debug listing files.  There are some developer level options that can be enabled through environment varibles.  You should use the compile-on-fly option.  To enable this, add an environment variable to the "environment variables" section in your config tool of choice  (oe explorer, or progress explorer).

    COMPILE_ON_FLY=OnTheFly;NoSave

    Then remove any r-code for any of the speedscript .html files that you want to debug (leave the .html speedscript files of course :), and restart the broker.

    What this will do is change WebSpeed to allow you to run uncompiled .html files.  By doing this, if the debugger is attached, then it can generated the debug listings for the debugger.  The debug listing should have all of the html statements from the SpeedScript file "turned inside out" so that they now become display statements as part of the SpeedScript instead of raw html.  You can step through them this way.

    There is a guide on WebSpeed development here.  This one has a section titled "Debugging Applications" which may provide some interesting information.

    http://documentation.progress.com/output/OpenEdge102b/pdfs/aswsp/aswsp.pdf

    You can read the WebSpeed developer's guide here:

    http://documentation.progress.com/output/OpenEdge102b/pdfs/gswsp/gswsp.pdf