Patchbuilder User Guide

AIM
MD.050 APPLICATION
EXTENSIONS FUNCTIONAL DESIGN
Patchbuilder - User Guide

$Author:: baran.sari $
$Date:: Jul 16 2013 16:03:28 $
$Revision:: 1.1 $

Author: Ali Baran Sari
Creation Date: 03-May-2012
Last Updated: 16-Jul-2013
Document Ref: KT
Version: 1.0

Approvals:
Jose Segura Martinez

Copy Number _____
MD.050 Application Extensions Functional Design

File Ref: Document1

Doc Ref:
Document Control ii
Document Control

Change Record

Date Author Version Change Reference

03-May-2012 Ali Baran Sari 0.1 First draft
16-Jul-2013 Ali Baran Sari 1.1 OAF, SOA related changes are explained.

Reviewers

Name Position

Jose Segura Martinez Capgemini Technical Team Lead

Distribution

Copy No. Name Location

1 Library Master Project Library
2
3
4

Note To Holders:
If you receive an electronic copy of this document and print it out, please write your
name on the equivalent of the cover page, for document control purposes.
If you receive a hard copy of this document, please write your name on the front
cover, for document control purposes.

File Ref: Document1

Doc Ref:
Document Control iii
Contents
Document Control .................................................................................................................. ii
Functional Requirements ....................................................................................................... 4
Purpose of document ...................................................................................................... 4
Background....................................................................................................................... 4
Functionality ..................................................................................................................... 4
Navigator .......................................................................................................................... 6
Build .................................................................................................................................. 7
Header Information ......................................................................................................... 8
Basic Information ............................................................................................................. 9
Application ..................................................................................................................... 10
DB User ........................................................................................................................... 11
DB Objects ....................................................................................................................... 12
$AU_TOP/resource....................................................................................................... 14
$AU_TOP/forms ........................................................................................................... 15
Forms ............................................................................................................................... 16
Reports ............................................................................................................................ 18
Server Files ...................................................................................................................... 20
Import Files ..................................................................................................................... 21
BI Publisher Data Definitions ....................................................................................... 22
Business Event / Subscription ..................................................................................... 23
Workflow ........................................................................................................................ 24
Information ..................................................................................................................... 25
OAF Modules ................................................................................................................. 26
Dependencies ................................................................................................................. 31
SOA Files ......................................................................................................................... 32
Overview......................................................................................................................... 34
Closed .............................................................................................................................. 35
Using Patchbuilder Illustrated Example ................................................................... 36
Appendix-I Verification Script ..................................................................................... 41
Appendix-II Workflow Installations with Patchbuilder .......................................... 43
Appendix-III Patchbuilder return codes .................................................................... 47
Appendix- IV Patchbuilder Directory Structure ....................................................... 48

File Ref: Document1

Doc Ref:
Functional Requirements 4
Functional Requirements

Purpose of document
This document outlines the Patchbuilder application which is used for creating
automated patches in Oracle EBS environments.

Background
This application was written to solve the following requirements/problems:
Simplification of the procedure to move Oracle Applications customizations
from one environment to another one.
Reduction of the enormous time required to build a patch (before up to 4
hours, now max.3minutes)
Reduction of the endless fight with the database administrators about
permissions for copying files or creating directories
Reduction of the build up from user accounts on the environments
Version control of the patch components to stop the latest version being
overwritten with an older version

Functionality
This application offers you the following functionality:
Multi language compatible without changing source-code
Building patches in different languages
Building patches to export database information, to import database
information, to extract database information for both export and import
Building a runable patch script to apply customizations on the target
environment
Building a patch description to give the installer an overview of what will be
installed on the target environment
Building new patch modules in test mode without disturbing the
simultaneous building of patches in run mode
Expansion of file extensions
Compression of the whole patch as a zip file to enable easier install on the
target environment
Pre- and Post- verification for invalid objects
Verification of the existence of particular server objects (rdf file, fmx file etc)
Verification of the existence of particular database object (package body,
view, index, table)
The patchbuilder installation script returns proper exit code (for success / >
for any type of failure during installation or verification)

File Ref: Document1

Doc Ref:


File Ref: Document1

Doc Ref:

Navigator
The Menu XXFND Patchbuilder is an Add-On to Oracle Applications for Release 12.
You need to have the responsibility XXFND patchBuilder (Standard) in order to
access this menu. Also PatchBuilder administrator should give to your user the rights
of create/close patch so that you can use the full functionality. Before, every
developer used to have his/her own patchbuilder user. But currently, we use
CBS_INTERFACE user for CBS patch creation and INTERFACE user for CCI patch
creation.


File Ref: Document1

Doc Ref:

Build
This menu is used to build Patches to apply customizations on different servers.
There are many tabs to enter information and each tab is going to be described
detailed below.


File Ref: Document1

Doc Ref:

Header Information
The information entered on this screen is the Header information of our patch.

Name/Filename The name given here is the unique identifier of the patch that is
going to be created. We obey the Tri.Can-Build Standards MD04 document for
naming a patch. Basically a name is the combination of CH number, system, version
number, SR/CR number.

Area : Select the customization area that this patch is related with; this
information will be written to the XXFND.XXFND_ADD_PATCH_HEADERS tables
in each installed environment.
Description : Give a meaningful description to the patch.
Internal Code : This is not a mandatory field, it can be used for extra comments.
Language : Leave the default value US.
Environment : Leave the default value Unix.


File Ref: Document1

Doc Ref:

Basic Information

Download / Upload : Select a patch type (Download / Upload / Both)
Allowed values are:
Download : only the sections Application/DB-User/Import
Files/Workflow/Information are enabled
Upload : all sections are enabled please make sure that every patch
component you want to upload includes a version control string (for example
from PVCS)
Both : includes all steps from above the patch installer will be
asked during the execution of the patch script if he wants to upload or
upload the application
Patch Directory : This is the Unix directory that your patch and all its
directory structure is going to be created. Depending on the modules that you are
creating the patch, this directory changes. Generally application TOP directory
($XXCB_TOP, $XXAR_TOP, $XXONT_TOP etc...) is followed by
/patch/115/import/US. You need to make sure that the directory entered really
exists in the Unix server.
Patch LOG-Directory : This directory is used to copy the patch log after
installation of a patch. But now it is not used anymore. All the log files are copied into
a centralized directory called $CUST_TOP/install/log.
Show Patch description? : Enable checkbox if a patch description should be created
Backup Files? : Enabled the checkbox if the patch has to backup server
files like forms, reports, sql scripts,etc. that exists before the installation.

File Ref: Document1

Doc Ref:

Application

Name : Select an existing application from the list of value. You should fill in
this information if you will have any server file such as forms, reports, .prog files
etc... that are going to be installed with PatchBuilder. Otherwise, selecting an
application and not supplying any server files will raise an error.
SQL Username: This field is not being used currently, but just to know it is the
database user name for SQL*PLUS.


File Ref: Document1

Doc Ref:

DB User

Name : Select an existing database user with which the components should
be installed. If you have to install database trigger or packages please select APPS
from the list of values. If you have to install other components like database tables,
sequences that needs to be created by using the schema owner, etc. please select the
custom database user such as XXAR, XXCB.

Note that the Connect as LOV values that you will see in the next DB Objects screen
are coming from here.


File Ref: Document1

Doc Ref:

DB Objects

Name : Type in the file name to install (without the file extension). As the
filename is case sensitive, the file name should be the same as the real file name that
you have checked in to PVCS.
Description : Type in the file description will be shown in the patch description.
Connect as : Select the database user from the list of values for database trigger
and packages please select APPS, for all other components select the custom database
user.
Type : Select the file type from the dropdown list every file type contains a
sequence number which makes sure that patchBuilder installs the components in the
right order (only necessary for the UPLOAD mode). For instance, a file with the type
table will get a lower sequence than a file with the type package; because table can be
used in a package, hence has a dependency. Therefore Patchbuilder needs to install
the table first, and then the package. Please do not play with the Line/Seq fields
unless you have a complicated database object dependency and you know what you
are doing.

NOTE: We have also adjusted the Patchbuilder so that it automatically extracts the
newly created database object names by parsing the files located under the install/
directory. Then, stores this information in the table xxfnd_add_patch_dba_objects so
that we will know which database objects are created by which install-file and patch
in the future. All we have to pay attention is the MD040 Build Standards; we should
write the CREATE, CREATE OR REPLACE statements within one line.
For instance:
CREATE OR REPLACE TRIGGER xxra_customer_trx_bur
CREATE GLOBAL TEMPORARY TABLE AR.AR_REVENUE_ASSIGNMENTS_GT
(
SESSION_ID NUMBER NOT NULL,

CREATE OR REPLACE PACKAGE xxar_atg_invoice_pkg IS
CREATE OR REPLACE FORCE VIEW ra_interface_lines
(
interface_line_attribute15,


File Ref: Document1

Doc Ref:
If we query at the new objects table xxfnd_add_patch_dba_objects:


File Ref: Document1

Doc Ref:

$AU_TOP/resource

Name : Type in the file name of the bespoke library (without the file
extension).
Action : Select an action from the dropdown list

Allowed values are:
Convert : The Ascii-File (PLD) of the form will be converted to a
binary file (PLL) after its revision has been checked. The binary file (PLL) will
be compiled to a binary file (PLX) as well.
Compile :The binary file (PLL) will be compiled to a binary file
(PLX) and no revision control will happen

Create Custom Library : Select an action for the custom library (CUSTOM.pll) is
needed.

Allowed values are:
Convert : The Ascii-File (PLD) of the form will be converted to a
binary file (PLL) after its revision has been checked. The binary file (PLL) will
be compiled to a binary file (PLX) as well. As we are keeping the custom
library as ascii-file in PVCS, we are using this value.
Compile : The binary file (PLL) will be compiled to a binary file
(PLX) and no revision control will happen.


File Ref: Document1

Doc Ref:

$AU_TOP/forms

Name : Type in the file name of the bespoke library (without the file
extension).
Language : Select the install language.

Allowed values are:
Convert : The Ascii-File (FMT) of the form will be converted to a
binary file (FMB) after its revision has been checked. The binary file (FMB)
will be compiled to a binary file (FMX) as well. As we are keeping the forms
as ascii-file in PVCS, we are using this value.
Compile : The binary file (FMB) will be compiled to a binary file
(FMX) and no revision control will happen.


File Ref: Document1

Doc Ref:

Forms

Name : Type in the file name of the bespoke form (without the file
extension). The LOV values comes from the custom form definitions. If you are
creating a new custom form, logically it should be defined in the Application->Form
menu.


File Ref: Document1

Doc Ref:


Allowed values are:
Convert : The Ascii-File (FMT) of the form will be converted to a
binary file (FMB) after its revision has been checked. The binary file (FMB)
will be compiled to a binary file (FMX) as well. As we are keeping the forms
as ascii-file in PVCS, we are using this value.
Compile : The binary file (FMB) will be compiled to a binary file
(FMX) and no revision control will happen.


File Ref: Document1

Doc Ref:

Reports

Name : Type in the file name of the bespoke report (without the file
extension). The LOV values comes from the custom concurrent program definitions
whose type is Oracle Reports. If you are creating a new custom report, logically its
concurrent program executable should be defined as well.


File Ref: Document1

Doc Ref:

Allowed values are:
Copy : The binary file (RDF) will be copied without revision control.
Convert : The Ascii-File (REX) of the report will be converted to a
binary file (RDF) after its revision has been checked. The binary file (RDF)
will be copied to its target directory. As we keep the report files in PVCS as
ascii-file in PVCS, we are using this value.
Compile : The binary file (RDF) will be compiled to a binary file
(REP) and no revision control will happen. Server Files


File Ref: Document1

Doc Ref:

Server Files

Name : Type in the file name of the bespoke server file (without the file
extension).
Object Type : Select an object type from the dropdown list.

Most used server files can be listed as .prog, .jsp , .sql. The mentioned server files will
be copied from the related patchbuilder directory into the corresponding Application
directory defined. For instance, we should put the .progfiles into the bin directory
of Patchbuilder. And this file will be copied into the $<APPLICATION DIR>/bin
directory.

Note that: if you are using the Server Files section, then you have to fill in the
Application section as well.

File Ref: Document1

Doc Ref:

Import Files
If we want to load any Value Set, Lookup, Concurrent Program Definition by using
Oracle FNDLOAD utility, we use the Import Files tab. We use this functionality only
for newly defined entity objects. If you are going to modify a concurrent program or
a value set, this should be done through MD120 Post-Installation section.

Name : Select the loader script from the list of value the appended sequence
will tell the loader script in which sequence it should be executed (only necessary for
the UPLOAD mode).
File Name : Type in the file name for the loader file to be created (without the file
extension).
Parameter : Modify the parameter list (replace all <<PARAM>> wild cards).

Important Note-1 : Please do not delete the apostrophe around the wild cards !!!
Important Note-2 : Every prog file should have the PVCS header, if you have
downloaded the prog file manually (not using the Patchbuilder Download
functionality), the PVCS header wont be there, so you should manually put the
header at the top of the file.


File Ref: Document1

Doc Ref:

BI Publisher Data Definitions
We can download BI Publisher data definitions of a Single Data Source, all
application or complete data definitions of an instance via the Import Files screen.

the UPLOAD mode).
extension).
Parameter : Modify the parameter list (replace all <<PARAM>> wild cards).

These are the possible parameters to fill in depending on the selected download
mode:
APPLICATION_SHORT_NAME='<<PARAM>>'
DATA_SOURCE_CODE='<<PARAM>>'

Important Note-2 : Every ldt file should have the PVCS header, if you have
downloaded the ldt file manually (not using the Patchbuilder Download


File Ref: Document1

Doc Ref:

Business Event / Subscription
We can download the Business Events and Subscriptions created in SOA Gateway
via the Import Files screen.

the UPLOAD mode).
extension).
Parameter : Modify the parameter list (replace all <<PARAM>> wild cards) with
the Business Event name or the Subscription name.

One example parameter for downloading a Business event can be:

"xxcnn.oracle.apps.ar.receipt.create" EVENTS

Important Note-2 : Every ldt file should have the PVCS header, if you have
downloaded the ldt file manually (not using the Patchbuilder Download


File Ref: Document1

Doc Ref:

Workflow
Workflow installations can be done also by using patchbuilder
Exception : Workflow Builder is also using WFLOAD and it does not support
removal of an existing Process. This has to be done manually and advised to do the
removal manually as a post installation setup. Please see Appendix-II for detailed
information.
So, what does the current solution support?
Modifying existing Processes: adding, removing, modifying nodes
Adding new Processes

Name : Type in the physical file name of the workflow (without the file
extension).
Original Name: Type in the original workflow name saved in the database (this will
be used for backup/validity check reasons).
Save as : Type in the file to be backup as (without the file extension - will be
automatically appended by _BAK).

File Ref: Document1

Doc Ref:

Information
We do not use this information field much, but if you want to show special
instructions to the DBA before the installation, you can also fill in this form.

Press button LOAD TEMPLATE to generate the default patch description
Type in the date of the functional MD05document
Type in the name of the functional consultant
Change No to Yes in the section CHANGES MADE if needed
Type in special instructions in the section SPECIAL INSTRUCTIONS if
needed
Press button RENUMBER to renumber the lines of the patch description if
needed.


File Ref: Document1

Doc Ref:

OAF Modules
This tab is used for OAF related installations (.java, .xml, .jpx).

Select OAF Copy Files if you want to copy the whole OAF directory to be
copied under the $JAVA_TOP. %99 percent of OAF installations should include this
step first. All you have to do is put the same existing directory structure under the
Patchbuilders java/ directory. Version control of each file will be done
automatically.

Select OAF Compile Java Files if you have .java files under the Patchbuilders
java/ directory and you need to compile and create the .class executables. Detection
of each java file and compilation will be done automatically.


File Ref: Document1

Doc Ref:

Select OAF Import Page Definitions if you have .xml page definition files. As
a general practice, we have to create our page definition files under the webui
directory. This is necessary for Patchbuilder to differentiate the page definition xml
files from other xml files.


File Ref: Document1

Doc Ref:

Select OAF Import Personalizations if you have personalisations. As a general
practice, we have to create personalization related xml files under the
personalisations directory. This is necessary for Patchbuilder to differentiate the
personalisation xml files from other xml files.


File Ref: Document1

Doc Ref:

Select OAF Import VO Substitutions if you have .jpx files for View Object
substitutions.


File Ref: Document1

Doc Ref:


File Ref: Document1

Doc Ref:

Dependencies

Patch Name : Select the Patch that your patch has a dependency, it will be checked
during the installation if the dependent patch is already installed to the installation-
environment or not.


File Ref: Document1

Doc Ref:

SOA Files
This tab is used for SOA Suite related installations; such as creation of custom
integration interface (iLDT) file and installing an iLDT file automatically.

If you only want to create the iLDT file, then the Download/Upload mode of the
patch should be Download. If you already have the iLDT file and want to upload it,
then Upload mode should be selected.

Seq : Type in a sequence number that will determine the
download/upload of the ildt files order.
Name : Type in the plsql package name that you put under the
Patchbuilders soa/ directory.
Description: Type in the description for the file.
Product : Type the application name that you want to use the interface.
Version : If you are generating a new iLDT file for an already uploaded
interface you need to add a higher version number then the last uploaded..
Object Type : Select the plsql package type, so far pls is supported.

If you are downloading the iLDT file, place the pls package as below under the soa
directory of Patchbuilder.

File Ref: Document1

Doc Ref:

If you are uploading the iLDT file that youve already checked into Subversion, then
place the iLDT file under the soa/ directory.

If the plsql package hasnt yet exist in the database, then you should also place the
package spec/body under the install/ directory of Patchbuilder and create the
database object records in patchbuilder as we do in normal package installations.


File Ref: Document1

Doc Ref:

Overview
The Overview screen will show you the created patches with their creation data, last
update date and created by user. You can delete or close any patch shown in the
screen.


File Ref: Document1

Doc Ref:

Closed
The Closed screen will show you the closed patches; a patch is closed whenever the
zip file is created for that patch. You have to reopen a patch if you want to do some
modifications on it.

Using the Query-Find function you can search for an installed patch name or the
internal code of the patch.
If you press the button REOPEN you have the choice to open an already compressed
patch again. If the button is disabled you have no privileges to execute this
functionality. The concurrent process behind this button will rename the existing
compressed patch file and reactivate the patch header database record. The reopened
patch is will disappear from the above screen.

File Ref: Document1

Doc Ref:

Using Patchbuilder Illustrated Example

If we understood everything described above, how/when to use mentioned screens,
we are ready to create patches using Patchbuilder.

Imagine we are going to create the CBS-patch CH59786V001CBSCR2812. Note that
because of environment differences (such as unix directory structure, Taviz directory,
languages supported) we have two versions of Patchbuilder, one for CBS and one for
CCI.
All the necessary information that we have to supply is as follows:

1. Enter the Header information and Basic information

2. We dont have any server file to copy, so we have to leave the application
empty.

3. Select the APPS user which is mandatory.


File Ref: Document1

Doc Ref:

4. Select the database objects. Here because of the complex package
dependencies, the Line Numbers are manually adjusted.

5. Select the Convert Compile as the change has CUSTOM.pll object.


File Ref: Document1

Doc Ref:
6. Save your work (Ctrl+S).

7. Go to Tools->Create PROG-File

8. Open a Putty or SSH connection for the Unix environment that you are
working with (example, for CBS Patchbuilder is installed into EUCBDA, for
CCI ERPPTH instance).

As we selected the $XXONT_TOP/patch/115/import/US as patch-directory,
the patch should be created under this directory in Unix with the name of
CH59786V001CBSCR2812. So, go to Unix and change the directory, we will
see it clearly:

>>cd $XXONT_TOP/patch/115/import/US/CH59786V001CBSCR2812

Open an FTP connection and go to the patch-directory. You will see that
Patchbuilder created directory structure and the .prog file under the
patchdrv directory.


File Ref: Document1

Doc Ref:

9. Now copy each file into the right directory. See Appendix-IV for the usage of
each directory.
Make sure the right binary and ASCII modes are selected while
transferring the files via FTP.
Make sure that each file is version controlled and has the PVCS header.
Otherwise, Patchbuilder will complain and stop installation.
Make sure that you are not down-grading any file, if an upper version of
a file is installed previously, Patchbuilder will complain if you try to
install a lower version.
10. If we are installing any database object such as package, view, trigger etc..
then we need to supply the verification.sql script that can be found under the
PVCS.
11. Make a test installation, this is very important, you have to submit a patch
that can be installed without any ERROR. Otherwise, DBAs will reject your
change.
12. If we are sure that everything worked as expected and we copied all the
necessary files, now we can create the zip file. Now go back to the
Patchbuilder application and run Tools->Create ZIP-File

File Ref: Document1

Doc Ref:

13. We can see that in Unix our patch is archived under the zip directory and it is
ready to submit for Development-QA.


File Ref: Document1

Doc Ref:

Appendix-I Verification Script

Verification of the existence of particular database object (package body, view, index, table)

The verification.sql file is more or less the same verification script that we were attaching into
MD120.

Template of the script can be found in PVCS under CBS:\Pathcbuilder\sql directory.

Developers will change the verification.sql file and put it inside the CHXXXXX/patchdrv/ directory
without checking it into PVCS. It is already excluded from version check.

If we have a file (except workflow (.wft) files) in the CHXXXXX/install directory but we do not have
the verification script, we will get an error as below and the installation will not start.

***** Patch $APATCHID has NOT been installed *****
***** The developer's verification.sql file does not exist *****

There are 2 parts that you have to change in the verification script: changed object count and
object list, apart from that youd better not to modify anything, especially the dbms_output.

A sample verification file is:

--
--+=============================================================================+
--| Canon Europa N.V. |
--| European IT Competence Center (EITCC) |
--+=============================================================================+
--| $Workfile: verification.sql $ $Revision: 1.0 $ $Date: 16 Mar 2010 09:35:00 $
$Author: baran.sari $ |
--| |
--| Description : Script to check the validity of changed objects |
--| |
--| Usage : 1- Change the l_chd_object_count variable to the number of |
--| objects that this CH will change |
--| 2- Change the object_list inside the s_all_object cursor |
--| 3- Never modify the dbms_output outputs |
--| |
--| Modification History : |
--| ---------------------- |
--| |
--| Author Date Version Remarks |
--| ------------------ --------- ---------- ---------------------------------- |
--| A.B. Sari 26-Apr-10 1.0 Initial Revision |
--|=============================================================================+
--
DECLARE

-- 1. Please change the l_chd_object_count with the number of VALID objects
-- that this CH will modify
l_chd_object_count NUMBER := 2;

l_installed_count NUMBER := 0;

CURSOR s_all_object IS
SELECT
substr(object_name,1,30) object_name
, last_ddl_time
, object_type
, status
, owner
FROM
dba_objects
WHERE
object_name IN
(
-- 2. Please change the object list below
'XXCSF_COMMON_PKG'
)
ORDER BY owner, object_type, object_name;

BEGIN

File Ref: Document1

Doc Ref:

dbms_output.put_line('***********Verification Script
Result*********************************************');
dbms_output.put_line( rpad('OBJECT_NAME',30) || rpad('LAST_DDL_TIME',22) ||
rpad('OBJECT_TYPE',18) || rpad('STATUS',7) ||
rpad('OWNER',30));

FOR r_object IN s_all_object
LOOP
dbms_output.put_line( rpad(r_object.object_name,30) ||
rpad(TO_CHAR(r_object.last_ddl_time,'DD-MON-RRRR HH24:MI:SS'),22) ||
rpad(r_object.object_type,18) || rpad(r_object.status,7) ||
rpad(r_object.owner,30));
IF r_object.status <> 'INVALID' AND r_object.last_ddl_time >= SYSDATE-1/24
THEN
l_installed_count := l_installed_count +1;
END IF;
END LOOP;
IF l_installed_count = l_chd_object_count THEN
dbms_output.put_line('***********Installed DB objects are
VALID**************************************');
ELSE
dbms_output.put_line('***********Some installed DB objects are
INVALID********************************');
END IF;

END;
/


File Ref: Document1

Doc Ref:

Appendix-II Workflow Installations with Patchbuilder

Workflow installations can be done also by using patchbuilder

Exception: Workflow Builder is also using WFLOAD and it does not support removal of an existing
Process. This has to be done manually and advised to do the removal manually as a post
installation setup.

So, what does the current solution support?

o Modifying existing Processes: adding, removing, modifying nodes
o Adding new Processes

Example-1: (Allowed)

Before Installation

After Installation


File Ref: Document1

Doc Ref:

Before Installation

After Installation


Before Installation

File Ref: Document1

Doc Ref:

After Installation

Example-4: (Not Allowed)

Before Installation

File Ref: Document1

Doc Ref:

After Installation

Note that; in case a new workflow is introduced, it is not recommended to run the patchbuilder
script in SILENT_MODE.


File Ref: Document1

Doc Ref:

Appendix-III Patchbuilder return codes

The patchbuilder installation script returns proper exit code (0 for success / > 0 for any type of failure during
installation or verification).

The return values of the patchbuilder script are as follows:

0 SUCCESS
1 PVCS Versioning Error
2 PLSQL Error
3 Invalid Count Increased Error
4 Input Error (like exiting with wrong database instance, etc)
5 - New Server File does not exists Error
6 Verification Script Error
7 Copy File Error
8 Form Convert/Compile Error
9 Report Copy/Convert Error
10 Workflow Backup Error
11 AU_TOP/forms Convert/Compile Error
12 - AU_TOP/resource Convert/Compile Error


File Ref: Document1

Doc Ref:

Appendix- IV Patchbuilder Directory Structure

We told that Patchbuilder creates a directory structure with the very first creation of
our .prog file. If we do not know the usages of these directories, we cannot create
installable patches. Below we will describe each directory one by one.

au_top : We have to put the libraries, forms, CUSTOM.pll that are going to be
copied into $AU_TOP.
backups : This folder is used internally by the patchbuilder during the
Workflow installation. Before the installation of a workflow file, patchbuilder takes a
backup before and after the installation for security reasons.
bin : We have to put the server files such as .prog into this direcroty.
doc : We have to put all the documents such as MD120, MD070, MD050
here.
forms : Form files (fmt) are going to be placed here.
html : Web related files (html, jsp, js etc...) are going to be placed here.
install : All the database object such as sql, pls, pkg, pkb, etc.. are going to be
placed here.
java : All the OAF objects such as java, xml, jpx, etc.. are going to be placed
here.
loadapps : ldt files are placed here.
patchdrv : The patchbuilder prog file is created here. We should place the
verification.sql file if we are installing any database object here. After the patch
installation, installation log file will also be created here.
reports : Report files (rdt) are going to be placed here.
soa : All the SOA objects such as iLDT, pls are going to be placed here.
sql : sql files which are going to be used as a concurrent program
executable are going to be placed here.
taviz : Any file that you want to upload into Taviz-server should be placed
here.
zip : The archive file (.tar.gz) is going to be created here.

Note that except from the directories patchdrv, doc, zip, backups any other folder
should include files which has PVCS headers.

Patchbuilder User Guide

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Patchbuilder User Guide

Enviado por

Direitos autorais:

Formatos disponíveis

AIM

Você também pode gostar