Wednesday, January 11, 2012

External Applicants and Browsers

Right after go-live from Tools 8.49 to 8.51 we started getting calls from external applicants with many different issues.  Most of these callers were using unsupported browsers.  We increased the visibility of our message that told applicants what browsers are supported.  But that didn't help for a couple of reasons.  Number one --some of our applicants get to our system through links from job search sites.  Our message about browsers was on our company careers web page.  The second reason was that people don't pay any attention to those messages.

This issue frustrated the recruiters because the number of applications coming in was down.  And this issue frustrated developers because we couldn't track down a particular page or component that caused it.  It was an intermittent issue that we couldn't reproduce.  The application server logs didn't offer any helpful information about the errors.

After finding this post on AJAX issues, we turned off AJAX for our External Applicant web profile.  Follow the link to get detailed instructions.  The basic idea: on Web Profile Configuration / Custom Properties tab, create a boolean property "AJAX" with a value of "false".  It changes the user experience, but that change was minimal in the application process.  I think there is one search that goes to a search page now, while with AJAX it used the modal search window.



Update:
See the later post on the 501/AJAX error here.

Tuesday, January 10, 2012

Reports not posting after PIA bounce

We also ran into a report server problem during go-live for the Tools patch.  Right after everything was signed-off, we put back the login page and bounced PIA.  Then when someone ran a report, it wouldn't post.  I bounced the Process Scheduler and that  didn't fix it.  We found an Oracle case (660253.1) that addressed the problem.  It has a work-around and a fix for the problem.  The quick work-around is to login through the report server.  Our report server is dedicated, so we don't usually login through it, but the login page is not disabled.  So we logged in and it was all good.

The log term fix is a bit more work, but then you won't have to go through another step each time you bounce PIA on the report server.  You'll need to edit $PS_HOME\webserv\peoplesoft\applications\peoplesoft\PORTAL.war\WEB-INF\web.xml

... 
<servlet> <servlet-name>psp</servlet-name> <servlet-class>psft.pt8.psp</servlet-class> <init-param> <param-name>configDir</param-name> <param-value>D:/pt8.51\webserv/peoplesoft/applications\peoplesoft\PORTAL.war/WEB-INF/psftdocs</param-value> </init-param> <load-on-startup>0</load-on-startup> <!-- add this line --> </servlet>
...
After saving the file, stop PIA, delete the web cache, and start PIA again.

In our test system we use the same web server for login and for the report server, so we never saw this problem in test.   If you do the same in production, you won't need to worry about this issue.