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.

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.

"Processing" and cache

Right at go-live from 8.49 to 8.51 we had some people that complained about sitting and waiting for the "Processing".  At first I thought they were using the old term for the new spinning pinwheel.  Then I got the same thing.  On one page, I got that old flashing gif that symbolized "I'm working on it, please wait".

I deleted my browser cache and the problem went away.  A bunch of other problems went away too.  In particular, the eRecruit job search started working.  This happened at the live system checkout after we applied Tools 8.51.  We had all the testers delete their browser cache, and many issues cleared up.

We sent out communication to the users so that everyone who ran into issues would delete their browser cache.  Then we started getting complaints from external job applicants, who we also had delete their browser cache.

We needed a better solution.  We had never had this type of problem with a Tools upgrade before.  I suspect that Oracle rewrote many Javascripts this time, rather than replacing them.  After some research, we found the following to address the problem.

On the Web Profile Configuration  / Caching, go to the Directories section.  Change the name of all of the directories.  I added the Tools version to the end.  So for our current version of 8.51.13, it's set like this:

Remember to change it for all of your Web Profiles.  We have a separate one for external applicants.

Patching to PeopleTools 8.51.13

We applied a patch to PeopleTools 8.51 this last weekend.  It went fairly smoothly and according to schedule.  The patch brought us from PT 8.51.11 to 8.51.13.

The main reason for applying the patch was to get the session timeout to work.  At patch level 11 we had problems with the session timeout not working.  It would occasionally work, but there wasn't a pattern to when it would or wouldn't.  A session would sit there past the warning time and timeout.  Then the user would click on a link or tab, and then they would get a login screen.  This login lead to a different set of problems.  After this re-logging in, the users would either get an "Authorization error - Contact your security administrator", or they re-login and the breadcrumbs were missing.  We had this problem on 8.51.07 too.

Opening another new window

Okay, not on upgrading today ... more of an enhancement.

On most pages there's a link for opening a "New Window".  The newwin servlet can do the same thing, if you have the URL to open.  Over at PeopleSoft Wiki they have a function that takes your current URL and gives you a new URL that will open as a second window with the "_1".  The limitation with the listed code is that if you already have a second window open, it won't work.  So here's an improvement.

/******************************************************
AnotherWinUrl(&strUrl)
This function modifies a URL to return a new window URL. It allows a new state block to be generated in a separate browser instance.
http://servername:port/psp/ps/EMPLOYEE/HRMS/c/...
 or
http://servername:port/psp_1/ps/EMPLOYEE/HRMS/c/...    (or _2, etc)
 becomes
http://servername:port/psp/ps_newwin/EMPLOYEE/HRMS/c/...  
 which the web server turns into  
http://server:port/psp/ps_1/EMPLOYEE/HRMS/c/...        (or _3, etc)
Input parameters: &strUrl - a URL to manipulate Output parameters:
&strUrlModified - New URL with _newwin parameter
************************************************/
Function AnotherWinUrl(&strUrl As string) Returns string;
   Local string &sRegEx, &sReplace, &NewWinURL;
   /* Declare java object */
   Local JavaObject &jUrl;


   &sRegEx =
   "/(ps[cp])/([^\/_]*)?(_[1-9])?/([^\/]*)?/([^\/]*)?/([csehtqwnf]{1})/";
   &sReplace = "/$1/$2_newwin/$4/$5/$6/";

   /* Instantiate objects */
   &jUrl = CreateJavaObject("java.lang.String", &strUrl);
   &NewWinURL = &jUrl.replaceAll(&sRegex, &sReplace);

   /* Return modified URL */
   Return &NewWinURL;
End-Function;

The original second pattern ($2) said it was made of non-slash characters. I added that it should also not be an underscore. Then I added a pattern ($3) of an underscore followed by a number. Then this third pattern is excluded in the replace string.

The PeopleSoft Wiki had a link to this site, http://gskinner.com/RegExr/ which makes testing these much easier.