Académique Documents
Professionnel Documents
Culture Documents
TECHNICAL DESIGN
Team: Technology
Creation Date: 22 May 2009
Created By: Brendan Furey (BrendanPF@Yahoo.com)
Last Updated: 4 September 2009
Control: 21729560.doc
Version: 1.1
Approvals:
Document Control
Change Record
Document Control ii
Contents
Document Control iv
Introduction
FNDLOAD is an Oracle Unix utility that allows for the transfer of a wide range of Oracle Foundation
(FND) data from one instance to another. It works by downloading the data in the source instance into
a text file (the LDT file) that can then be uploaded into target instances. It is most often used for
transferring concurrent program definitions one at a time between development and test and
production instances. However, it can also be used when there is a requirement to transfer (or load)
large batches of records such as responsibilities and user assignments, which may arise for example
when new operating units are added. Its use in such cases can save a very large amount of time
compared with manual migrations, but there are a number of possible pitfalls that need to be avoided,
so that careful planning and design are important.
This document describes our approach to such a batch transfer, explaining how FNDLOAD has been
used along with Unix scripting and Oracle API calls to transfer a large batch of responsibilities (around
188), with their profile option values (around 216), and associated user assignments (around 3,638).
The requirement arose from a project to add three additional operating units to a system previously
transacting through a single operating unit. The document deals with technical and functional
problems encountered, and how they were resolved, and includes designs for the Unix and PL/SQL
scripts written.
Technical Overview 5
Technical Overview
Entity-Relationship Diagram
The entities that need to be transferred (or loaded) are shown on the ERD below. The entities depicted
are all Oracle foundation entities, except for the two HR entities on the right, and details of the table
structures can be found in REF-1. If the notation is not obvious, refer to REF-2.
Transfer/Load Methods
Three basic methods are used to transfer (or load) the different entities, as follows:
FNDLOAD Download/Upload
Responsibility and Exclusion records are downloaded via FNDLOAD. Each responsibility is
downloaded individually, and appended onto a cumulative LDT file by means of a Unix script
Technical Overview 6
appropriate value is specified, and replaces the placeholder as the template file is appended onto the
cumulative LDT files, which are iniitialised using the header files.
Implementation Notes
Data Integrity
FNDLOAD allows for the download of individual entity instances or groups of entity instances. For
example, all responsibilities couild be downloaded within a specified application. However, this creates
a serious risk of uploading bad data from development into production. For this reason, we download
only specified individual entity instances that are assumed to have been fully tested. We then
combine the LDT files into one file (or a small number of files) for installation convenience.
A second risk factor arises from the fact that FNDLOAD downloads referenced entity instances as well
as the named entity instance. For example, downloading a concurrent program results in all value sets
referenced also being downloaded into the LDT file. Since referenced entities may not be part of the
relevant development project, they may have been separately modified. In general, only what has
been modified as part of the development, and hence tested, should be uploaded. For this reason, we
post-process each downloaded LDT file to remove referenced entities (but not the references to them
of course).
Who Columns
‘Who’ columns are standard Oracle columns storing the users who created and last updated the
record, with the datetimes. FNDLOAD normally uploads the update values from the source system,
and the same values for the creation columns for new records. We believe this is inappropriate for
system-generated updates (for auditing reasons), and so we substitute SYSADMIN for the user, and
use a placeholder for the update/creation date for processing as discussed in the previous section.
Forcing Updates
FNDLOAD uses an algorithm to determine whether an entity instance that exists on the target system
should be overwritten or not, depending on such things as the update user and datetime on each side.
We are in fact only uploading new records, but in the case of updates, as long as the data integrity
measures outlined above have been taken, it would be appropriate to pass the parameter
CUSTOM_MODE=FORCE, which causes the updates to happen disregarding the usual algorithm.
Technical Overview 7
Batch Size
FNDLOAD was found to fail with an error message concerning a variable’s size being exceeded when
the number of top-level entity instances in the LDT file exceeded about one hundred. Therefore files
were split where necessary.
The diagrams below show the high level flow of data and processes. The flowchart convention of
rectangles for processes and parallelograms for datastores is followed. Red rectangles correspond to
Unix scripts that we have developed, and that are described in the detailed design sections following.
Technical Overview 8
Responsibilities Transfer
Notes
The diagram shows the processes involved in creating the three header files and the template that will
be used in the main download script.
Technical Overview 9
Notes
• The diagram shows the processes involved in the main download script, with its inputs and
outputs.
• Note that the Responsibility/Profile List datastore is actually contained in the script itself.
• The output files may be split up into multiple smaller files where necessary, and the profiles
files can be combined if desired
Technical Overview 10
Notes
• The diagram shows the processes involved in the main responsibility upload scripts, with their
inputs and outputs.
• The processes are repeated for each input file where necessary
Technical Overview 11
User Responsibilities Load
Notes
The diagram shows the processes involved in the main user responsibility upload script, with its inputs
and outputs.
Technical Overview 12
Unix Script List
Description Script
Download Profile Value XX_DownPR.x
Download Responsibility XX_DownRy.x
Download Responsibilities XX_GW_Down_CRP_RSP.x
Upload Profiles XX_UpPR.x
Upload Responsibilities XX_UpRy.x
Upload User Responsibilities XX_UpURG.x
Technical Overview 13
Module Designs
Parameters
Name Description
Apps Password Password of apps Oracle user
Profile Name Internal name of profile
Responsibility Key Responsibility key
FNDLOAD Parameters
Position Name Value
1 User/Password apps/[Apps Password]
2 0
3 Y
4 Upload/Download? DOWNLOAD
5 Control File $FND_TOP/patch/115/import/afscprof.lct
6 LDT File [Profile Name]_PR.ldt
7 Entity Code PROFILE
8 Entity Value PROFILE_NAME=[Profile Name]
9 Profile Level LEV=RESPONSIBILITY
10 Profile Level Value LEV_NAME=[Responsibility Key]
Process
• Validate parameters
Download Responsibility
Parameters
Name Description
Apps Password Password of apps Oracle user
Responsibility Key Responsibility key
Application Short Name Application short name
FNDLOAD Parameters
Position Name Value
1 User/Password apps/[Apps Password]
2 0
3 Y
4 Upload/Download? DOWNLOAD
5 Control File $FND_TOP/patch/115/import/afscursp.lct
6 LDT File [Responsibility Key]_Ry.ldt
7 Entity Code FND_RESPONSIBILITY
8 Entity Value RESP_KEY=[Responsibility Key]
9 Profile Level Value APPLICATION_SHORT_NAME=[Application Short Name]
Technical Overview 14
Process
• Validate parameters
• Remove all Application blocks from the temporary LDT file and copy to the output LDT file
• Search LDT file and report on success or failure, writing out the number of function and menu
exclusions
Download Responsibilities
This script creates the LDT files for all the responsibilities included in the file, together with LDT files
for the Operating Unit and HR User type profile values. A local procedure is defined to do the
processing for each set of responsibilities. It is passed the Application short name, the Operating Unit
Id, a flag to indicate whether to set the HR User Type profile or not (if so, it’s set to ‘PER’), followed by
the list of responsibility keys.
Parameters
Name Description
Apps Password Password of apps Oracle user
o Append the tail of the file to the cumulative output LDT file
o Append the profile template file to the cumulative Operating Unit LDT file, replacing
placeholders with actual values (or Org Id placeholder)
Append the profile template file to the cumulative HR User Type LDT file,
replacing placeholders with actual values
o End If
• End Loop
Technical Overview 15
• Assign values to local variables, including actual Operating Unit ids, or placeholders as
applicable
• Replace owner with SYSADMIN in all output files, and last update date with placeholder
sysdate
Upload Profiles
This script uses FNDLOAD to upload from a profile values LDT file that may contain either or both
types of profile.
Parameters
Name Description
Apps Password Password of apps Oracle user
Input File Name Profile values LDT file name
FNDLOAD Parameters
Position Name Value
1 User/Password apps/[Apps Password]
2 0
3 Y
4 Upload/Download? UPLOAD
5 Control File $FND_TOP/patch/115/import/afscprof.lct
6 LDT File [LDT File Name]
Process
• Validate parameters
• Replace Operating Unit and sysdate placeholders in input file with new Operating Unit id and
today’s date respectively, to create the actual LDT file to upload
• Obtain lists of profiles and responsibility keys from the input file into local variables
• List the profile values uploaded, passing to SQL the local variables as lexical parameters
(SQL session)
Upload Responsibilities
Technical Overview 16
Parameters
Name Description
Apps Password Password of apps Oracle user
Input File Name Responsibilities LDT file name
FNDLOAD Parameters
Position Name Value
1 User/Password apps/[Apps Password]
2 0
3 Y
4 Upload/Download? UPLOAD
5 Control File $FND_TOP/patch/115/import/afscursp.lct
6 LDT File [LDT File Name]
Process
• Validate parameters
• Replace sysdate placeholders in input file with today’s date, to create the actual LDT file
• Obtain list of responsibility keys from the input file into local variable
• List the responsibilities uploaded, with the number of function and menu exclusions, passing
to SQL the local variable as a lexical parameter (SQL session)
Parameters
Name Description
Apps Password Password of apps Oracle user
Input File Name Input CSV file name
Technical Overview 17
API Parameters
Position Name Value
1 User Name [User Name]
2 Responsibility Key [Responsibility Key]
3 Application Short Name [Application Short Name]
4 Security Group ‘STANDARD’
5 Owner ‘SYSADMIN’
6 Start Date SYSDATE
7 End Date NULL
8 Description 'Added by API'
9 Last Update Date SYSDATE
Process
• Create temporary SQL Loader control file
• Call SQL Loader to load input data file into temporary table
Loop over temporary table, outer-joining User, Responsibility, and User Assignment records
Set status to N
Set status to M
Else
Call API to load Assignment, with start date today and end date null
Set status to C
End If
End Loop
• Commit
Technical Overview 18
• Remove temporary SQL Loader control file
Technical Overview 19
References
REF Document Location
https://etrm.oracle.com/pls/trm11510/etr
REF-1 Oracle, eTRM, R11.5.10
m_search.search
http://www.scribd.com/doc/15723877/A-
REF-2 A Structured Approach to SQL Query Design Structured-Approach-to-SQL-Query-
Design
Technical Overview 20