Procurement Suite Patching Strategy For One-Off Requests and RUPs
(Doc ID 602754.1)
Last updated on APRIL 24, 2020
Applies to:Oracle Sourcing - Version 11.5.10 to 12.2 [Release 11.5 to 12.2]
Oracle iSupplier Portal - Version 11.5.10 to 12.2 [Release 11.5 to 12.2]
Oracle iProcurement - Version 11.5.10 to 12.2 [Release 11.5 to 12.2]
Oracle Purchasing - Version 11.5.10 to 12.2 [Release 11.5 to 12.2]
Information in this document applies to any platform.
Information in this document applies to any platform.
Procurement releases regular and scheduled rollup patches (RUPs). 11i10 RUP schedule is once in 2 months. Following the release of E-Business Suite 12.0.4 Release Update Pack on January 15, 2008, Procurement has started regular R12 RUPs once every month starting June, 2008. Oracle recommends that customers apply RUPs at regular scheduled intervals. One-off patches should be requested on an exception basis only.
Oracle's objective is to release Procurement RUPs regularly. Approved one-off patches will be certified and released in the same QA/development cycle and thus will be released every four weeks and every two months for R12.0 and 11i respectively. Should there be a requirement for a one-off patch outside of the cycle this will be considered based on the customer's business impact and milestone/critical date.
Rollup patches will go through full Quality Assurance (QA) testing.
For both R12 and 11i, one-offs will be released for all Severity levels strictly based on customer business impact and approval fo the One Off Patch Request by Oracle management.
- ** P1 one-offs are made available for controlled download (Distribution by Support in most cases) as soon as they complete the QA testing.
- ** All other one-offs (including Esc Sev 2) will be approved by Oracle based on customer business need and business justification and an ETA will be provided to the customer.
Points to Note:
- Oracle aims to minimize separate one-off certifications so that we can improve the quality of the code and the risk associated with a one-off.
- Releasing rollups regularly will reduce the need for a one-off.
- One-off patches have limited testing due to adhoc/emergency basis of these patches. These patches are not regression tested within the entire code line.
- One-off patches are not always technically feasible.
- The full implications of an individual patch are not always known.
- Numerous one-off patches are inherently less predictable.
- Environments with numerous one-off patches are non-standard which can cause unique type problems that are more difficult to diagnose and fix.
- Regular code upgrades (rollup patches) which have been fully tested will naturally increase overall stability.
Release 12.2 Considerations:
- Purchasing has been working in R12.2 on several projects to improve the product. Due to these projects, the list of dependent files has been growing to a large number creating a challenge in the release of smaller one off patches. A One off patch is intended to solve one problem only but it must include any dependent file to ensure that it will not create file version inconsistencies at some customers. This is the reason you might see large patches released as one off patches.
- Due to the increasing sizes of one off patches, development decided to create a well tested base line patch (also called consolidated patch), <Patch 22467373:R12.PO.D>. This baseline is built to ensure all dependencies are correctly included and hence reduces risk of patch applications on top of this baseline.
- The baselines patch, <Patch 22467373:R12.PO.D>, is being included in newer patches on top of Release 12.2. for Purchasing product and it is required in order to prevent unexpected version inconsistencies and problems at customer's instances that can be very difficult to find and correct.
- A smaller one off for Release 12.2. would be considered after customer has the baseline patch applied directly or indirectly and after proper patch impact analysis (see below) is done. Note that the patch will be applied if you apply any new PO patch that includes it, ie., you might already have it.
- Note: As of today, <Patch 22467373:R12.PO.D> is released internally because it is expected to be transparent for customers when they apply any other new PO patch that includes it. Development is considering releasing this patch to customers who want to apply it standalone. Please check the status of this patch always as it might change soon.
- iProcurement is facing similar challenges and they are adopting a similar approach. iProcurement development is encouraging customers to apply the iProcurement consolidate <patch 22575334:R12.ICX.D> at your earliest convenience. This patch is currently available for download.
For you, the customer:
1) We ask that schedule for and apply rollup patches at regular intervals or as required.
2) If you cannot schedule and apply a rollup, we will review your situation and provide the ETA for the one-off. Development will do their best to prioritize your request.
For one-off requests or smaller patch request:
Support will be required to obtain the following information from the customer when requesting a one-off patch:
- Strong business justification for the one-off.
- Milestone dates.
- Functional & Financial impact.
- What is the last rollup applied?
- Provide the output to SQL to Determine Release 11i or Release 12 Procurement Code Level (dependent on Release installed) in <Note:222339.1> "Procurement Family Patch Release History".
- Expected timeline the customer is planning to apply the next RUP?
- Latest rollup impact analysis. Please apply the latest rollup applicable to their release, with the option "adpatch apply=no" and provide this output.
(For R12.2 and higher, the syntax for applying a patch in test mode is "adop phase=apply apply=no patches=[patchnum]".)
- Impact analysis for the patch you require. Every patch comes with a list of dependent files included that might or might not be already in your system. The impact analysis intends to provide the actual list of files that are being changed or added to your specific installation. You can get this list by applying the patch you are require using the test mode parameter(same command as in previous bullet point). Alternatively, you can use the Patch wizard utility to run this impact analysis, See document <Note:976188.1> "R11i/R12 : Patch Wizard Utility [Video]"
- For PO release 12.2, verification that customer has the baseline patch (see above in 'Release 12.2 considerations') applied.
These rollup patches should not be confused with the traditional Recommended Patch List (RPL) patches from Development.
Navigation path for RPL: Metalink > Patches & Updates > E-Business Suite Recommended Patch List > Maintenance Release = 11.5.10 CU.2 > Select your product (i.e. Purchasing, iProcurement) with 11i.SCM.PF.J
RPLs additionally continue to be highly recommended from development.
Some customers may be concerned with the size of rollup patch. There are standard scripts to check how many changes a rollup will make to a customer's system. For example, a customer can choose to try 'adpatch apply = no' to see how many changes will happen.
The history of patch sets, mini-packs, family packs and rollup patches released and planned for Procurement-related products is located in <Note:222339.1> "Procurement Family Patch Release History".
(*) *****All scheduled releases are subject to change without notice.*****
To view full details, sign in with your My Oracle Support account.
Don't have a My Oracle Support account? Click to get started!
In this Document