The Page Stuck in Processing

We applied Tuxedo 10.3.0.0 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

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.

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

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.

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.

Update:
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