Tuesday, December 6, 2011

Did You Hear That?: ATG 12.1.3 Release Update Pack Required by Feb 2012 for Premier Support

I'm quoting my friend Floyd Teter, who is quoting Steven Chan from Oracle.

"ATG 12.1.3 Release Update Pack Required by Feb 2012 for Premier Support"

umm... It's December 6th. You're all getting ready for the holidays. Or your plant shutdown. Or your year end code freeze. And I just wanted to say, if you're on Release 12 and you're not on Release 12.1.3, then you need to get there. By February. And when I say February, I think that means January 31st. Not February 29th. You've probably been thinking you have until February 28th, but this year is a Leap Year (I am an expert on years in which the Leap occurs, because I only get anniversary gifts every four years). In spite of the extra day provided by Leap Year, the deadline for getting the ATG 12.1.3 Release Update Pack in is February 1, 2012. Which is, like, really soon.

To get you started down the path to R12.1.3, here are some tips:
  • First, be sure to read MOS Doc. ID: 1066312.1, Oracle E-Business Suite Applications Technology Readme for Release 12.1.3 (R12.ATG_PF.B.delta.3, Patch 8919491).
  • Make sure you're current on your RDBMS Interoperability Patches - the appropriate MOS Note will depend on which version of the RDBMS you are currently running. I see new patches for various RDBMS versions periodically, so don't skip this step. Here's the one if you're running RDBMS 11gR2: MOS Doc. ID: 1058763.1, Interoperability Notes Oracle E-Business Suite Release 12 with Oracle Database 11g Release 2 ( Of course, that said, I want you to upgrade to, but we'll talk about that later.
  • There's been a change to the steps for applying R12.1.3, Patch 8919491 - there's a new patch, 12964564, that Oracle says you should merge with Patch 8919491. If you're in the middle of testing and didn't notice this change, MOS Doc. ID: 1066312.1 says you can tack it on afterward as a post-upgrade step if you need to.
  • Don't forget the Post 12.1.3 patches from MOS Doc. ID: 1066312.1.
And then, just when you think you've got all the patches you could possibly apply, you need to apply more!
  • If you haven't done so already, apply a patch to Patch Wizard, a free tool provided by Oracle as part of Oracle Application Manager (OAM), which is also free. But Patch Wizard needs to be patched or you'll rip your hair out trying to figure out why it isn't working. See Patch Wizard Utility [ID 976188.1], Patch Wizard FAQ [ID 976688.1], Patch:10629916 for the latest version of Patch Wizard in Oracle E-Business Suite (Release 12.0), and Patch:10629956 for the latest version of Patch Wizard in Oracle E-Business Suite (Release 12.1).
  • Run a query to see what modules are either shared or installed in your environment.
  • Configure Patch Wizard (I swear, it's really easy; you just need to check boxes for the modules you have either shared or installed in your environment). If you configure Patch Wizard, then it will tell you just the patches you need for your modules. If you don't, then it will tell you every patch for every module that Oracle offers.
  • Run Patch Wizard. Sort the results to make "Unapplied" patches pop to the top, Copy the unapplied patches that are listed into a spreadsheet or Word document, read all the readmes looking for additional pre-requisite patches, post-patches, or extra steps. Update your spreadsheet. Apply the patches.
  • Consider patching your applications server while you're at it - there's an Application Server Release 3 (10.1.3) Patchset 5 ( Release 12.1.1 implemented There are several Forms fixes consolidated in bundle Patch 9593176.
  • Oh, go on, consider patching your RDBMS Version as well - Version is now certified. And if you do that, then make sure you check for additional Interoperability patches for Version with Release 12.1.3. And if you're going to do that, you might as well look for a higher PSU for Version 
  • We'll leave testing and applying the January 2012 CPU, due out in mid-January, for another day.
And BOOM, you're there. I've done this several times for an assortment of upgrades from 12.1.1 to 12.1.3, and I'm going to go out on a limb here and say that you'll probably have a lot of patches to apply (I'll say less than 200, but Release 12.1.3 counts as a pretty darned big patch), but they probably won't cause you issues in applying them. So, applying the patches will probably not be a bad experience, so be kind to your test team and get that part out of the way ASAP so they can have as much time as possible to test what you've given them.

You can download a free copy of Red River's Oracle E-Business Suite Release 11i & Release 12 Patching 101, which steps you through how to set up and use Patch Wizard. I have a vested interest in this book, as I wrote it with John Stouffer, and Mike Swing from TruTek provided the test environment for pounding through Patch Wizard issues. We'll release a new issue right before Collaborate 2012 to update the patch list and other modifications that Oracle has made since last year.

Shared HR Customers: Now That You've Made it to R12.1.3, Should You Upgrade to HR RUP4?

I am working right now with an E-Business Suite client who is a shared HR/Payroll user. My client is testing the upgrade from Release to Release 12.1.3+. If you've gone through the upgrade, you may sympathize when I say that every time I tell the client that there's one more patch to apply, I can actually hear his eyes rolling around in his head.

So, when you upgrade to Release 12.1.1, you upgrade to HR RUP3. And if you run patchsets.sh afterward, you'll notice that HR RUP4 is now available. And if you patch Patch Wizard and run Patch Wizard, it will tell you about some one-off patches for HR, as well as recommend that you apply HR RUP4. So here's the question: must you?

I did a little research. First, I have to tell you that I've become a My Oracle Support Known Issues Note Junkie. Oracle creates Known Issues documents to correspond to big patches that they've released. The Known Issues notes track outstanding issues and patches for those issues if they are available. And yes, there's a Known Issues Note for HR RUP3. So if you've upgraded to Release 12.1.3, you're already behind and need to take a look at the Known Issues Note. There's also a Known Issues Note for HR RUP4.

I trudged through those two Known Issues notes, and found that for HR RUP3, there are 55 additional recommended patches. That's as of 11/24/2011, the last time I looked. There may be more by now. And for HR RUP4, there were 24 additional recommended patches. Hmmm... 55 patches... 24 patches. I weeded through the Readmes for both MOS notes, tracked any additional pre-requisites, built myself a list for HR RUP3 and HR RUP4, waffled several times over what to do, and finally made this recommendation to my client:

Upgrade to HR RUP4, and apply the Known Issues patches for HR RUP4 that apply to your environment.

We weeded out, for example, patches that were legislative related. Shared users don't apply legislative patches. We weeded out patches for modules that weren't installed. By the time we were done, for this client, we were able to cut down to the HR RUP4 patch plus six additional patches from the HR RUP4 Known Issues document.

My client applied the patches and they all went in smoothly. We haven't tested yet, as he is sorting through the Patch Wizard-recommended patches today, but still, what we did apply applied smoothly. I can't guarantee that you'll be so lucky, since your data is different and you may have different shared and fully installed modules, but I did find it comforting to be able to say that for this client, applying HR RUP4 did not cause any issues during the application process.

Back to the original question: Must you upgrade to HR RUP4? Could you apply the HR RUP3 patches and let it go at that? Could you skip the extra HR RUP3 patches?

I think the answer to this kind of question always falls back to how risk averse you are. And maybe how solid your test team is. Oh, and it really matters if you're a fully installed HR/Payroll user or a shared installed HR/Payroll user.

If you have a super solid test team and they've thoroughly tested your R12.1.3 instance and they aren't seeing any issues, and if you've passed the HR RUP3 Known Issues patch list by them, and they don't believe that any of those patches are necessary, and if you're an HR/Payroll shared mode user, then you could probably stop where you are. Probably. Me, I'm so freaking risk averse that I would feel compelled to apply more patches. My concern is always that a change in a patch that is described in a readme will affect something that isn't described in the software that I care about.

On the other hand, my understanding is that if you are a fully installed HR/Payroll user, then you're supposed to stay current on patches, so you need to apply HR RUP4, and you need to follow the instructions that describe running hrglobal.drv for legislations, and you need to find the HR RUP4 Known Issues document and apply those patches, and you need to continue to monitor the HR RUP4 Known Issues document for more patches.

That said, I'm very interested in HR right now, so if you have any opinions, I'd love to hear from you.

psst... I found a MOS Note that describes how to switch from Fully Installed to Shared for HR

A couple of weeks ago I was trolling around on My Oracle Support, something I do quite frequently to stay current on the latest patches for Release 12.1.3, and I found a super-interesting MOS Note:

Changing Oracle Human Resources Installation from FULL HR/FULL Payroll Install to SHARED HR/SHARED Payroll Install [ID 461063.1]

Now that's exciting. Aren't you excited? If you're not familiar with HR, the issue here is that traditionally, Oracle has said that they wouldn't support changing the status of your HR module from fully installed to shared install. So seeing instructions on how to do so, and the caveats to consider, is just plain interesting.

The note describes two supported ways of making the change: 

1.  If you've never run the hrglobal.drv program against your instance, then it is very easy to switch from fully installed to shared installed. Customers in this situation likely inadvertently chose to fully install HR/PAYROLL when installing the E-Business Suite in the first place, but really had no intention of using the additional functionality or licensing those modules. Those customers correctly ignored instructions in various patches to run hrglobal.drv over the years, because they didn't need to run it. So, if you really intended to be a shared user, and you never ran hrglobal.drv, then MOS Note 461063.1 includes a script that will flip the switch on the STATUS column in the FND_PRODUCT_INSTALLATIONS table. MOS Note 461063.1 also includes a script you can run to see if you've run hrglobal.drv, so it's very easy to figure out if you're in this situation. The MOS note also includes a script to change the status of some other HR/Payroll-related modules.

Now, I couldn't resist checking at one of my clients who is already in shared mode, so they ran the query for me, and it turns out that they've run hrglobal.drv twice, once in 2006 and again in 2011. I mention this because to me this suggests that folks are confused about what they're supposed to be doing when it comes to HR. I looked over various MOS notes, and have to admit that I was confused. You have to understand what Oracle is talking about when they discuss legislations, and if you don't, then it would be easy to conclude that applying something you might not need is easier than not applying something you might need. Personally, I think it would be nice if any patch that includes hrglobal.drv also checks to see if HR/Payroll is fully installed, but I am not an Oracle programmer so the solution may be more involved than my simple perspective surmises. 

Anyway, the MOS document includes some more queries and changes that you need to make to fully apply these changes, so check it out if you're interested.

2. The more difficult scenario occurs if you have HR fully installed, you wish you hadn't, and you have run hrglobal.drv. I'm copying straight from the MOS note to avoid any misinterpretation here:

To be SUPPORTED as a SHARED HR Installed instance you will have to do the following:

3a. Create a 'brand new instance' installed as SHARED HR Install (also you will have to verify the STATUS for the other HR related products and change their STATUS appropriately (Oracle provides a list in the MOS Note))

3b. You will then need to export your table data from your FULL HR Install instance to your newly created SHARED HR Install instance where the hrglobal.drv script has 'never been run'. This means 'all of your table data for all Oracle applications'.

3c. This is the process for changing Oracle Human Resources Installation from FULL HR Install to SHARED HR Install where the hrglobal.drv script has been run (legislations ARE installed on your instance).

I have to admit, I'm utterly intrigued by this option, but concede I would be worried that I might accidentally include table data related to being fully installed in the import from the original Full HR instance described in Step 3b. But I'm betting that logging an SR with Oracle could result in enough information to do the deed. You can see that making this change is a significant undertaking, and your test team would definitely have to put your instance through a thorough test process. But it's nice to see that there is a way to get there if you want to.

With all that said, if you've followed this process, or come up with your own process for making this change, I would love to hear more details about it and whether you ran into any additional issues. Also, how did your test team test that the conversion worked? Do tell me. I'm all ears.

The Subtleties of CPU Application Between Releases

I've been plugging away on an R11.5.10 to R12.1.3 upgrade over the last couple of weeks, and ran into an issue. My client made it all the way in a test upgrade to Release 12.1.3 and then created a merged patch of some additional recommended patches, including the October 2011 CPU. And, well, it failed. Here's the message he saw:


sql /yyy/a/oraapp/xxx/apps/apps_st/appl/fnd/12.0.0/patch/115/sql/afmimefilext.sql &un_fnd &pw_fnd

Start time for statement below is: Thu Dec 01 2011 15:36:49

INSERT INTO FND_MIME_TYPES ( mime_type_id, mime_type, ctx_format_code,
last_update_date, last_updated_by,creation_date, created_by,
last_update_login,file_ext, allow_file_upload ) VALUES (
fnd_mime_types_s.NEXTVAL, 'application/zip', 'IGNORE', sysdate, -1,
sysdate,-1, -1, 'zip', 'N')

AD Worker error:

The following ORACLE error:

ORA-00001: unique constraint (APPLSYS.FND_MIME_TYPES_U2) violated

With research, we concluded that the problem was occuring with the Oct 2011 CPU for Release 12, which includes two patches, 12794417 and 12921332. With more research, we realized that as part of the RUP7 "Known Issues" document, we had already applied the Oct 2011 CPU, but on Release 11i, rather than on Release 12. And with more research, we realized that Oracle gives the Release 11i CPU patch a different patch number than the Release 12 CPU.

Hmmph. I did not know that. I had been counting on adpatch to screen out duplicate patches between Release 11i and Release 12, so it hadn't occured to me to worry about whether the latest CPU had already been applied.

Our solution? For this pass of the upgrade (a test pass), we rolled back to before the post-Release 12.1.3 merged patch was applied, but after the Release 11i Oct 2011 CPU had been applied (because that occurred at the very beginning of the upgrade), took the Release 12 Oct 2011 CPU out of our merged patch, and then applied the merge again, with no problems.

Considerations? Well, for the next pass, we'll remove the Release 11i Oct 2011 CPU from our collection of patches that we apply to Release 11i before upgrading. We'll add the Release 12 Oct 2011 CPU back in to the merge that we ran after upgrading to Release 12.1.3. And for future upgrades, we'll make sure we're tracking which CPU has been applied on which E-Business Suite release more carefully, because it sure doesn't work to apply the CPU twice.