Our company upgraded from WF 8009 to 8201 and have been having numerous problems with our self-serve applications. One of the latest issues is the disappearing and reappearing of our list box content. Most of our list boxes are populated via fex programs that read data from Oracle tables that gets outputted to XML. The self-serve pages were created in WF 7.6 and were working during the 8009 upgrade. Now, with the 8201 upgrade we are having issues that we never experienced before. We have run numerous traces that have not shown any error messages or any information that points to the reason why the list box content appears and disappears sporadically. Our self-serve pages generally have about 4 list boxes. When we display the page, generally one list box is populated, the others are blank. Help! Help! Thanks.

This message has been edited. Last edited by: FP Mod Chuck,

Michele,

Can you share some sample code, it may help to find where could be the issue ?

If you change the output format of these fex programs to - for example - HTML, do you get the expected output? If not, are there any errors in the output HTML source?

I'm guessing this has nothing to do with the actual fexes that generate the XML files, but something to do with the HTML file that calls them. Actually, not really the HTML file, but how the WebFOCUS Client behaves with the HTML file. If each of the programs properly output XML when run independently, either the client is misbehaving or the JavaScript that controls the XML files is not up to scratch, specially if it was written in WebFOCUS 7.6 days.

Francis, the XML when run independently is successful. Do you have any suggestions on how we can work with IBI to determine if there is a problem with the client and/or JavaScript that controls the XML files? Or, what we need to do to fix the problem with the client and/or JavaScript. No doubt both were written in 7.6. Thanks for your feedback.

Once in a blue moon an audit is done on our HTML pages, either hand-coded or GUI developed. This is mainly to determine how many HTTP requests are made by one page. From my past experience, most WebFOCUS related HTML pages make dozens of HTTP requests (and can be quite inefficient - WEBFOCUS 8.0.09 Portal was an example of inefficiency, allegedly), which might bog down the web server and the web browser. Perhaps some web server settings could be tweaked in the upgraded environment. Did you upgrade Apache Tomcat? Perhaps you can compare old and new environments.

Michelle, I'd take a look at this website (or others like it): HTTP Requests Checker. They suggest one should look into a page that makes more than 20 HTTP requests.

Francis, do know how we would use the link page
internally. Do we have to purchase that software? Thanks.

Michelle, sorry, that free online tool can't handle intranet sites (I should have realized that). I'm not sure what the IT systems people would use.

For testing purposes, try eliminating a drop-down and see what happens. are any of the drop-down lists very large? Test with reduced numbers.

Also, I would take a look at Apache Tomcat settings (of which I personally know almost nothing about). If you still have the old environment around, ask the administrator to compare Tomcat environment settings - my guess is that the old environment was tweaked and the new one is at the default settings - only a wild guess.

Will do. Thanks Francis.

I would also hit F12 on the browser to debug and look at "RemoteValues" to see header request/response etc.,