Working with Oracle Readiness Reports

Oracle provides a set of Readiness Report scripts that analyze your environment and identify the objects that do not comply with the R12.2 development standards. Unfortunately, these Readiness Report scripts are not user friendly at all, and do not provide background information on the issues detected, information on how to fix them or a description of the impact in case you don’t remediate the reported issues .

The Readiness Report scripts are meant to be used when you upgrade your environment to R12.2, which means they analyze the complete environment. They are not particularly useful if you want to only check a set of programs you recently developed and are planning to send it to production once you’re already running on R12.2.

These issues make working with the Readiness Report scripts a little complex and require several weeks of analysis and study of the documentation. Here’s a few recommendations for working with the Readiness Reports:

1) Make sure you completely understand the development standards. Being familiar with them and their importance in your environment is key to understanding the readiness report output and defining a plan to fix the issues.

2) Consolidate your standards knowledge and remediation steps to fix each violation. This can be seen as an exercise prior to getting to the real violations, but all preparation you can snatch in advance will make it easier for you to address the readiness report results.

3) Readiness Reports output can be thousands of lines long. Forget the length of the report, focus on your recently acquired understanding of the standards to identify the most important ones. Sometimes a standard may have hundreds of violations (that is, hundreds of programs that don’t follow the standards), but the fix can be quick and simple. Oher violations can only occur on a few programs, but be extremely complex to fix.

4) Readiness Report results are not independent issues. Analyze the results of the readiness reports considering them as a whole and not as independent issues, since making modifications to fix some of the standards may have consequences on the compliance with other standards.

5) Devise an action plan. we suggest you address the schema-level issues first, as those will help you better layout your custom components and make sure your custom object storage practices follow the best practices implemented by the application.

6) Define parallel projects to address different groups of issues. You can have different teams address different types of issues (such as having a team focus on the schema issues, another one working in parallel on the object name issues, and thrid team working on required custom program redesign).

7) Estimate the amount of work and include it into your overall upgrade project plan. Fixing customizations to meet R12.2 development standards can be a considerable challenge, so having an accurate measure of how much time it will take is important for your project manager.

8) Take advantage of Productivity Analysis tools. Save time by working with tools that help you analyze your environment and provide information about the standards and identified violations, such as descriptions of how a standard is not met, what to do to fix it, what will happen if you don’t address the issue, and what’s the effort required to remediate it.

IT Convergence has developed a Development Standards Analyzer (DSA) tool that identifies, analyzes and reports violations to the standards in your customizations. The DSA tool provides details of the nature of the standard, reasons why it is required, instructions on fixing the issues and impact analysis. Contact us to learn more.