Vous êtes sur la page 1sur 27

www.kpit.

com

Customizations in Oracle E-Business Suite R12.2

Oct 2015

1 11/17/2015 © KPIT Technologies Limited


Customizations Releases 12.1

2 11/17/2015 © KPIT Technologies Limited


3 11/17/2015 © KPIT Technologies Limited
12.2 Architecture
Dual File System and Edition-Based Redefinition

Run File System Edition-Based Redefinition Patch File System


Oracle HTTP Server (OHS) Oracle HTTP Server (OHS)

WebLogic Server (WLS) WebLogic Server (WLS)

Developer 10.1.2 Developer 10.1.2

APPL_TOP APPL_TOP
Synchronization Managed Automatically
COMMON_TOP COMMON_TOP

INST_TOP Non-Editioned File System INST_TOP


APPL_TOP_NE

PATCH_TOP

LOGS

4 11/17/2015 © KPIT Technologies Limited


Customizations in Oracle E-Business Suite R12.2

5 11/17/2015 © KPIT Technologies Limited


Maintain Customizations with Online Patching in R12.2

6 11/17/2015 © KPIT Technologies Limited


R12.2 Development and Deployment Process

• Customizations Deployment extend the Cutover Phase


• Deployment targets the Run File system and Run Edition

7 11/17/2015 © KPIT Technologies Limited


Oracle E-Business Suite 12.2 and Online Patching

 Efficiently stores multiple copies of Application


definitions in the same database

 Provides an isolation mechanism (“Edition”) that


allows pre-upgrade and post-upgrade schemas to
co-exist

 Client code chooses the particular “Edition” that it


wants to connect to

8 11/17/2015 © KPIT Technologies Limited


Key differences compared to prior releases
 To be patched Online they have to comply with Online Patching:

 Development Standards
 Patching Procedures

 Exist in both file systems (dual file systems)

 Custom Schemas with dependencies on EBS objects must be editions enabled

 Register custom tops with adsplice

 keep custom code in sync between file systems


 – CUSTOM_TOP must reside within the APPL_TOP

9 11/17/2015 © KPIT Technologies Limited


12.2 Development Standards for Custom Code
Decide Which Standards Compliance Level to Target

10 11/17/2015 © KPIT Technologies Limited


Utilities available for the Analysis

11 11/17/2015 © KPIT Technologies Limited


Online Patching Standards Compliance Report

12 11/17/2015 © KPIT Technologies Limited


Code Naming Standards

– Table Names must be unique within the first 29


characters
– Column Names must be unique within the first 28
characters
– Table Names cannot end with the “#” character
– Object Names must end in alphanumeric character
– Index names must contain at least one “_” character
– Constraint Names must contain at least one “_”
character
– Materialized Views Name cannot exceed 29 characters
13 11/17/2015 © KPIT Technologies Limited
Code Naming Standards

14 11/17/2015 © KPIT Technologies Limited


Compliance to 12.2 standards e.g

1 Custom Prod Code ( E.g > 8


chars, 3rd Party Schema like
Oracle 12.2 Coding Std
Apex)
1. Custom Prod Code restrictions
2. Custom TOP location restrictions
3. Custom tables under custom
schema
2 Compliance Name Count
4. Tables accessed via synonyms Invalid Objects 22
Database Recyclebin is not off 1
5. Synonyms must point to objects Synonym don't point to an object 77
6. Objects must be valid Custom Table onwed by APPS 303
Column Name has '#' as last character 1
7. Table name can’t end with # Base Column Name not unique within 28 bytes 242
______________________ Query/DML statements don't access Tables via
26823
Synonym or Editioning View
______________________ Index Name doesn't contain an underscore ('_') 55
______________________ Index Key Size greater than 3215 3
Constraint Name doesn't contain an underscore ('_') 52
______________________
______________________
______________________

15 11/17/2015 © KPIT Technologies Limited


Online Patching Readiness Reports
ADZDPSUM.sql

– Identifies Custom Schemas with objects that have dependencies on EBS Code
– Generates statements to register identified schemas with the application
ADZDPMAN.sql
– Identifies Objects that violate the Minimal Compliance standards which require
manual intervention
– Each section header provides a description of standards violation and how to fix
them
ADZDPAUT.sql
– Identifies Objects that violate the Minimal Compliance standards and are
automatically fixed by the
Online Patching Enablement process. There is no action required on the output of
this report

16 11/17/2015 © KPIT Technologies Limited


Edition Enabling : Qualification Criteria

 All schema objects can be divided in 2 groups, editionable and non-editionable:


 Editionable objects (No Data) are synonyms (except public synonyms), views, and all PL/SQL object
types (functions, libraries, packages and package bodies, procedures, triggers, types and type bodies).
 All other objects (holds data) are non-editionable (e.g. tables, indexes, materialized views, database
links, etc.)

 A non-editioned object cannot depend on an editioned object. For example:


 A function-based index cannot depend on an editioned function.
 A materialized view cannot depend on an editioned view.
 A table cannot have a column of a user-defined data type (collection or ADT) whose owner is editions-
enabled.
 A materialized view cannot depend on editioned function

 A new schema APPS_NE (APPS Non-Editioned) introduced in R12.2 to hold potentially editioned objects
for which these dependencies would not be removed. Online patching would not be able to patch these
objects

17 11/17/2015 © KPIT Technologies Limited


Editioning View Concept in R12.2.x

 Editioning View Concept in R12.2.x:

 R12.1.x

APPS – Synonym MOAC/VPD PO – Base table


PO_HEADERS_ALL PO_HEADERS_ALL
PO_HEADERS X

 R12.2.x
APPS – Synonym MOAC/VPD Editioning View PO – Base table
PO_HEADERS_ALL PO_HEADERS_ALL# PO_HEADERS_ALL
PO_HEADERS X

 Virtual Private Database (VPD) Policy must be on the Editioning View or Table
Synonym, not the base table
 You must use the Editioning View in order to get the correct column
representation, that is consistent for your Edition
 A crossedition trigger propagates data changes made by the old edition into the
new edition’s columns, or (in hot-rollover) vice-versa
 This provides the filtered representation of the Editioning View to ensure you get a
consistent representation of the data.

18 11/17/2015 © KPIT Technologies Limited


Edition Based Redefinition (EBR)

Edition-Based Redefinition depends upon three new kinds of object:


 the edition,
 the editioning view,
 the crossedition trigger.

 If the application upgrade will change only views, synonyms, and PL/SQL objects, then the
edition alone is sufficient to allow these changes to be made while the application remains
on line. This type of change is common when, for example, new presentations of data or
new workflows are required.

 If changes to table data or structure are restricted to only those tables that are not
changed via the ordinary end-user interfaces, then the edition together with the editioning
view are sufficient to allow these changes to be made while the application remains on line.
Tables whose data parameterizes the user interface layout or workflows meet this
condition. So do tables that hold the catalog of wares for a shopping application.

 If changes to table data or structure are required for those tables that are changed
routinely by the end-user, then the edition, the editioning view, and the crossedition trigger
must be used in concert to allow these changes to be made while the application remains
on line.

19 11/17/2015 © KPIT Technologies Limited


Run & Patch Edition Concept
As a developer, you will
For all of below you will have a RUN and PATCH edition: connect to the Run Edition
•Database Objects (Synonyms, Views, Function, Library, Package, Procedure, Trigger, Type etc.) whenever you are engaged
•Seed Data, Meta Data in normal development
•File system Objects activity on the system.

Patch Patch
Patch Patch

Development Test/SIT UAT Production

 All Custom  Prepare: Online  Prepare: Online  Prepare: Online


Development has to Patching Patching Patching
happen in “Run”  Cutover: From  Cutover: From  Cutover: From
edition. “Patch” to “Run” “Patch” to “Run” “Patch” to “Run”
 Unit Testing would  Unit/System Testing  UAT Testing  Verify Changes
be performed in  Rework back to  Rework back to  No direct code
“Run” mode. Development Development changes in “Run”
 Download changes  Success: Move Patch  Success: Move Patch edition manually.
as patch. to next instance to next instance  “Patch” will contain
 Promote patch.  No direct code  No direct code Code you are
changes in “Run” changes in “Run” changing.
Code changes are edition manually.
edition manually.
installed in the privacy of  “Patch” will contain
 “Patch” will contain
a new edition . Code you are Code you are
changing. changing.
20 11/17/2015 © KPIT Technologies Limited
How it works

Database File System Configuration Patch Cutover

Start Online Run Patch Patch Run


Patching Cycle Run Patch Patch

Configure the patch Apply Patches. Configure the


Synchronize the file patch edition
Create a new database system patch edition with edition for use by the Run is still Live to become the
patch edition the run edition patching tools and no impact
new run
edition
 Briefly, a new database is established as true copy of the extant database on a second hardware system dedicated to that
purpose.
 For a period, the new database tracks the old database.
 Then the new database is taken off line, noting the moment at which this is done.
 The new database’s system software is upgraded as required and then it is put back on line and tracking of the old
database is turned on again so that it “catches up” with the changes to customer objects that were made in the old
database while the new database was not tracking it.
 Finally, the new database is declared to be the canonical one and end user sessions start to use it.
 This requires a brief period of downtime to ensure that no end-user sessions use the new database until the old one has
been formally closed for such sessions.
 Then the hardware that supported the old database can be returned to the pool of available hardware to restore the
status quo of hardware use by the application.
 This approach is viable also when it is required to upgrade the operating system software; it is viable, too, even if the goal
is to migrate the database to brand new hardware which possibly has a different operating system

21 11/17/2015 © KPIT Technologies Limited


Developing & Deploying Customizations

Customization Guidance

Application In Release 12.2, you should use adsplice to register your application in order to ensure that the application is
set up for online patching. Do not use the Applications window to register applications in this release. Do not
use the Applications window to register applications in this release.

Editioned Database Objects


Package/Procedure/Functio Step 1: An application developer can create or replace editioned database objects in the run edition of a
development database using whatever scripts or tools they normally use. Typically this involves editing SQL
n/View/Type/Synonym/Trigg
scripts that contain DDL statements, and then applying the scripts to the development database. E.g.
er • Sqlplus> apps/<apps_password> @XYZUTILS.pls"
sqlplus> apps/<apps_password> @XYZUTILB.pls"
sqlplus> apps/<apps_password> exec ad_zd.compile --recompile invalid objects
sqlplus> quit
Step 2: Create the patch
Patch files in the above example would be:
fnd/patch/115/sql/XYZUTILS.pls
fnd/patch/115/sql/XYZUTILB.pls
The manual apply actions for the file system would be:
cp fnd/patch/115/sql/* $FND_TOP/patch/115/sql
The manual apply actions for the database would be:
Sqlplus> apps/<apps_password> @$FND_TOP/patch/115/sql/XYZUTILS.pls
sqlplus> apps/<apps_password> @$FND_TOP/patch/115/sql/XYZUTILB.pls

22 11/17/2015 © KPIT Technologies Limited


Developing & Deploying Customizations

Customization Guidance
Effectively Editioned Database Objects

Custom Table - New Step 1: Create the initial table definition in your development database. This step includes creation of any required
indexes, storage properties, and so on.
Step 2: Upgrade the table for Online Patching using the AD_ZD_TABLE.UPGRADE procedure. This will generate an
Editioning View (EV) for the table and then create an APPS synonym that points to the Editioning View. Table is
now ready to use from APPS schema. Generated EV name would be same as table and suffix by “#”.
Step 3: Extract the table definition from your development database using the xdfgen.pl utility. Due to a database
requirement you must first insert at least one row into the table before extraction will work.
Step 4: Create the patch.
Patch Files:
fnd/patch/115/xdf/xyz_user_service.xdf

Manual apply phase actions for the file system:


cp fnd/patch/115/xdf/* $FND_TOP/patch/115/xdf

Manual apply phase actions for the database:


xdfcmp.pl <applsys_user>/<applsys_password>@$TWO_TASK
$FND_TOP/patch/115/xdf/xyz_user_service.xdf <apps_user>/<apps_password>

When the patch is applied, XDF will create the table and index, and will automatically call the
AD_ZD_TABLE.UPGRADE procedure to generate the editioning view and APPS table synonym.

23 11/17/2015 © KPIT Technologies Limited


Developing & Deploying Customizations
Customization Guidance

New Logical Column to Step 1: Create new column in table by using alter command. When adding Not Null column it is
recommended to choose default value.
Table
Step 2: Regenerate Editioning View (EV) using AD_ZD_TABLE.PATCH upgrade the table for Online
Patching using the AD_ZD_TABLE. The PATCH procedure looks at the physical table columns and
then generates the editioning view which presents the logical columns for that table.
Step 3: Extract the table definition from your development database using the xdfgen.pl utility.
Step 4: Create the patch.
Patch Files:
fnd/patch/115/xdf/xyz_user_service.xdf
Manual apply phase actions for the file system:
cp fnd/patch/115/xdf/* $FND_TOP/patch/115/xdf

Manual apply phase actions for the database:


$FND_TOP/patch/115/xdf/xyz_user_service.xdf <apps_user>/<apps_password>
When the patch is applied, XDF will add new column and automatically call the
AD_ZD_TABLE.PATCH procedure to target system.

New Index Step 1: Create new index on selected table by using Create Index command
Step 2: Extract the table definition from your development database using the xdfgen.pl utility.
Step 3: Create the patch.
Patch Files:
fnd/patch/115/xdf/xyz_user_service.xdf
Manual apply phase actions for the file system:
cp fnd/patch/115/xdf/* $FND_TOP/patch/115/xdf
Manual apply phase actions for the database:
$FND_TOP/patch/115/xdf/xyz_user_service.xdf <apps_user>/<apps_password>

24 11/17/2015 © KPIT Technologies Limited


Developing & Deploying Customizations
Customization Guidance
Update an Existing Column Step 1: To update existing data without disturbing the running application we must create a new physical column (called a
revised column) to hold the updated data. Create a revised column in your development database. Revised columns use a
Values
naming standard of COLUMN_NAME#REVISION, where a later REVISION tag must be alphabetically greater than the earlier
revision. Alter the table in your development database to add the new revised column, and remember to call the
AD_ZD_TABLE.PATCH procedure whenever you change the table structure manually.
Step 2: Regenerate Editioning View (EV) using AD_ZD_TABLE.PATCH
Step 3: Create a Forward Crossedition Trigger to populate the revised column. A Forward Crossedition Trigger (FCET) is a table
trigger with a special rule about how it fires: During online patching, the FCET is created in the Patch Edition, but (being a
crossedition trigger) it will only fire on changes made in the parent (Run) edition. To create an FCET, start with the Forward
Crossedition Trigger Template and add the data upgrade logic to the trigger body.
Step 4: Execute the SQL script to create the trigger and then call the AD_ZD_TABLE_APPLY script to apply the trigger
Step 5: To fix managed objects after revising an existing logical column, call the AD_ZD.FINALIZE, AD_ZD.CUTOVER and
AD_ZD.CLEANUP procedures manually in your development database
Step 6: Extract the table definition from your development database using the xdfgen.pl utility.
Create the patch.
Patch Files:
fnd/patch/115/xdf/xyz_user_service.xdf, fnd/patch/115/sql/XYZ_USER_SERVICE_X1.sql
Manual apply phase actions for the file system:
cp fnd/patch/115/xdf/* $FND_TOP/patch/115/xdf,
cp fnd/patch/115/xdf/* $FND_TOP/patch/115/xdf
Manual apply phase actions for the database
xdfcmp.pl <applsys_user>/<applsys_password>@$TWO_TASK $FND_TOP/patch/115/xdf/xyz_user_service.xdf
<apps_user>/<apps_password>
sqlplus apps/<apps_password> @$FND_TOP/patch/115/sql/XYZ_USER_SERVICE_X1 APPLSYS
sqlplus apps/<password>@$AD_TOP/patch/115/sql/AD_ZD_TABLE_APPLY XYZ_USER_SERVICE_F1

25 11/17/2015 © KPIT Technologies Limited


Edition View
Customization Guidance

AD_ZD_TABLE.UPGRADE This will generate an Editioning View (EV) for the table and then
create an APPS synonym that points to the Editioning View. E.g.
exec ad_zd_table.upgrade('APPLSYS', 'XYZ_USER_SERVICE')
xdfgen.pl utility This produces a file called 'xyz_user_service.xdf' that contains
the definition of the table along with any related indexes,
sequences, and policies
perl xdfgen.pl
<apps_user>/<apps_password>@<DB_Instance_Name>
XYZ_USER_SERVICE
AD_ZD_TABLE.PATCH Whenever you directly alter the structure of a table, you must
call the AD_ZD_TABLE.PATCH procedure. The PATCH procedure
looks at the physical table columns and then generates the
editioning view which presents the logical columns for that
table. The PATCH procedure is called automatically when
applying table structure changes using XDF or ODF.

26 11/17/2015 © KPIT Technologies Limited


Questions

27
27 11/17/2015
11/16/2015 ©
© KPIT
KPIT Technologies
Technologies Limited
Limited

Vous aimerez peut-être aussi