Monday, July 30, 2012

No Longer Stuck in Processing, updated

We finally have a "solution" to the issue where a user was stuck in processing.  I've discussed it here and here. The solution comes from document 1367044.1.

Open the PORTAL_REFRESHPAGE (HTML) object in Application Designer and make
the following changes:

function fadeInPagelet(pgltName){
//hideLoadingImg(pgltName); //JDN: remove this line
setTimeout(function(){hideLoadingImg(pgltName);}, 0); //JDN:add this line
ptCommonObj.fadeElement("ptpgltbody_" + pgltName, 0, 20, 100, 40, 10);
var pgltData = document.getElementById(pgltName + "_Data");
if (pgltData){
if (browserInfoObj.isIE)"";

After applying the changes, make sure the browser cache is cleared before
trying out the changes.

We've tested it and we're planning when to apply it to production.

Update: "It worked in test."
While it seemed great in test, it hasn't completely solved the problem in production.  I've heard from users that it's better, but they still get stuck in processing.  If I get more details from them, I'll put that info out on the blog.

Update #2: See Stuck-in-Processing Solved

Tuesday, May 22, 2012

The Page Stuck in Processing

We applied Tuxedo patch level 089 (from 069) over the weekend, and it didn't help with the issue users have with getting stuck in processing.  It happens most often when a user clicks the magnifying glass to look up a value.  The processing pinwheel starts spinning, and it doesn't ever come back.  It's the same issue I listed here.

I just got an update from Oracle that this issue is fixed in PeopleTools 8.51.17.  It is "Report ID: 13865710       The Page Struck[sic] in Processing".  We are in the middle of upgrading from HCM 8.9 to 9.1 and a PeopleTools patch does not fit in our upgrade timeline.  I've asked to get an individual fix pulled out from the patch.  Responses to requests like this are hit or miss.  I'll let you know if we get lucky.

Update: See Stuck-in-Processing Solved

Tuesday, May 8, 2012

Best Practices for Upgrading PeopleSoft Enterprise

I came across this Oracle White Paper recently titled, Best Practices for Upgrading PeopleSoft Enterprise.  It's a useful reference document for what Oracle considers "best practices".

From pages 12 & 13:

Tip #3—Use Change Management Appropriate for an Upgrade

During an upgrade, it is imperative to freeze metadata and system data in your production environment. With respect to the new release, ensure all relevant patches available are applied appropriately. There are two types of new release patches to manage throughout the upgrade project: "required for upgrade" patches and "regular product" patches. For each upgrade pass, required for upgrade patches only are applied to your upgrade environment. For each user acceptance test rollout or environment, apply regular product patches to the test environment only and never to the upgrade environment. Failure to appropriately manage these different
change management requirements can result in upgrade step failures and unexpected user acceptance test results.

Tuesday, February 28, 2012

PeopleTools 8.51 & Exchange 2010 revisited

We went into production on the Exchange 2010 server last Friday.  The Exchange server admins were able to set the TarpitInterval based on where the email was originating.

Also we changed the code that sends hundreds of emails in TAM to a batched process.  

Here are the exchange commands we used and the settings changed.

Set-ReceiveConnector –Identity servername\relayconnectorname –ConnectionTimeout  00:20:00
Set-ReceiveConnector –Identity servername\relayconnectorname -TarpitInterval  00:00:00
Set-ReceiveConnector –Identity servername\relayconnectorname –MaxAcknowledgementDelay 00:00:00

Wednesday, February 22, 2012

Update on the 501 / AJAX error

I originally thought that the Microsoft bug was just for IE 7 & IE 8 on Windows XP.  We had fixed the problem in XP with IE 7.  But we had people upgrading to Windows 7 with IE 8 and they started getting the problem again. That XP only info was tied to something read from a blog post. With more careful reading of the actual MS article, it looks like this bug applies to all users of IE 7 & IE 8, no matter what version of Windows you are using.  The linked Microsoft KB article has instructions for how to apply the fix to your registry.

Monday, February 13, 2012

Three Intermittent Issues

We have three Tools related issues we are continuing to work on.  The first is something that we thought was solved.  Users intermittently get http 501 errors.  In "External Applicants and Browsers" we addressed AJAX issues, including the 501 error.  The PeopleSoft Experts blog entry has a great deal of information about issue and the Microsoft registry fix.  Microsoft documents the error as a problem for IE 7 & 8 users on Windows XP.  We had IE 7 users on XP, applied the registry patch, and all was good.  But now users upgrading to Windows 7, using IE 8, and having the problem again.  This issue may be related to bug 11870611.

The second issue we are seeing is that a user is actively using PeopleSoft and their session times out.  It's not a common occurrence.  The user has used the New Window link to open a second window.  This issue could be related to report ID 13096404.

The last one is where users are stuck in a processing state.  They can sit at a page for ten minutes or longer, and it will stay in processing.  But if they log out and log back in, they can complete the transaction right away.  I thought that this issue was related to bug 11625722, but support said that bug doesn't relate to us since we are on Tools 8.51.13.  They have us cleaning up some errors in the application server logs.  I'll be surprised if it makes any difference.

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

2nd Update
See the latest users stuck in processing here.

3rd Update: See Stuck-in-Processing Solved

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.

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.