Conversion Process
General
Conversion Process
- I get
the functional spec from my client through my TL- To satisfy Business
Needs
- I
Prepare my Technical spec analyzing the Functional Spec
Ø I will do Data Mapping, Data Cleaning, Filtering the columns
(Required, Conditional Required, Default, Derived)
Ø Prepare my Pseudo Code
Ø In my Pseudo Code- I will decide the tables and the logic
(Package, Procedure)
- Send
it for Approval
- After
getting the Approval I will create the staging table with the available data file
- I will
load the data’s into my staging table through Sql*Loader using Concurrent
Program
Ø Here I will do Translation, Transformation.
- From
my staging table I will load the data’s into interface tables with custom
procedure/package using Concurrent Program
Ø I will do my validation
- I will
make sure that the data’s loaded into interface table from my staging
table will be pure
- Then I
will run Open interface programs to hit the Oracle base Tables
Suppose I am Using Any Api. I will not do any validations
The Api will take care of it
New Form –Extension
·
I start with template.fmb
and Rename it
·
In the template.fmb I
delete the existing blocks, Canvas, Windows
(Detail block, Block Name)
·
I create my own Blocks,
Canvas, Windows as Required and attach the Required Property Class
·
I change the Previous
Navigation, Next Navigation Block As Required
·
In the form level trigger I
modify the following Triggers
Ø Pre-form- app_window.set_window_position ('Window Name',
'FIRST_WINDOW');
Ø In the New form Instance I give my Form Name
·
In the Block Level
triggers- I create to triggers
Ø Pre-Insert-I set the Who Columns (fnd_standard.set_who)
Ø Pre-Update- I set the Who Columns (fnd_standard.set_who)
Ø Pre-Record-I set the window title
Ø
Post-Query-This may be
confusing to the user when the user is asked to save changes without having
knowingly made any
• Add the following to your POST-QUERY triggers to
reset the record status when appropriate
set_record_property (:system.trigger_record,
: system.trigger_block, STATUS,
QUERY_STATUS);
• Make sure these block-level POST-QUERY triggers use
Execution Hierarchy set to after
·
In the App_custom Package I set
the window name which is to be closed
·
I compile the form, Then
·
Using ftp I will put the form in the corresponding top
·
I will generate fmx using f60gen in Unix environment
Ø Parameters in f60gen-
userid, module= corresponding fmb/custom.pll
Module_type=form/library
output_file=aaa.fmx
Then, I go for
registration.
Form
Registration:
In Application
Developer
·
I register my form – form name,Appl name, User from name
·
I create my function-Function name,User function name
Ø Property- type-form
Ø Form- attach my user
form name, my application name and the corresponding Parameters
(We can have any no of functions for the single form
by changing the parameter)
·
I create my menu- Menu
name,User Menu Name
·
I attach my function to it
·
I will mail to sysadmin
If they ask abt the concept
Just say, In the responsibility I will attach my
Menu
Then I attach my responsibility to the corresponding
user
New Report
·
I get the functional spec
from my TL (with structures like font, size etc)
·
I prepare the technical
spec with my functional spec
Ø I create sample queries, base table, join conditions
·
We send it for approval
·
After getting the approval
·
Using report builder I
create my report as per requirements (queries, groups, columns)
·
In the user parameter
Ø I give p_conc_request_id as a must parameter
Ø In the report trigger (before) I give the SRW.USER_EXIT (FND
SRWINIT)- Fetches the concurrent request id and set profile options
Ø In the report trigger (after) I give the SRW.USER_EXIT (FND
SRWEXIT)- Frees the allocated memory spaces
Ø Diff between fnd_global.apps_initialize and srwinit is
It will create temp table space
(srwinit)
Both will initialize the global
variables (fnd_global, srwinit)
Report Registration:
In
Application Developer
·
I create a executable with
executable method as Oracle reports
·
I create a program and
attach my executable wit it
·
I create any required
parameters in the parameter window
·
I will give token name- it
is to identify which user parameters in reports
·
I will attach the program
to my custom request group
Custom pll
The CUSTOM library allows extension of
Oracle Applications without modification of Oracle Applications code.
Use the CUSTOM
library for customizations such as Zoom (such as moving to another form and
querying up specific records), enforcing business rules (for
example,
vendor name must be in uppercase letters), and disabling
fields that do
not apply for your site.
Custom package
1.Zoom_Available
(function)
2.Style
(function) – To override the execution hierarchy.
The
following package variables should be used as return values:
• custom.before
• custom.after
• custom.override
• custom.standard
3.Event
(procedure) –allows to execute your code at specific events.
Events Passed to custom library
1.WHEN-NEW-FORM-NAVIGATE
2.WHEN-NEW-FORM-INSTANCE
3.WHEN-NEW-BLOCK-INSTANCE
4.WHEN-NEW-RECORD-INSTANCE
5.WHEN-NEW-ITEM-INSTANCE
6.WHEN-VALIDATE-RECORD
7.SPECIALN
app_special2.instantiate(’SPECIAL14’,’Special
14 CUSTOM’);
8.ZOOM
9.EXPORT
10.KEY-Fn
Ø Logic
you code for WHEN–FORM–NAVIGATE, WHEN–NEW–
BLOCK–INSTANCE,
WHEN–NEW–RECORD–INSTANCE, or
WHEN–NEW–ITEM–INSTANCE fires after
any existing logic in those
triggers for the form, block or item.
Ø Logic
you code for WHEN–NEW–FORM–INSTANCE,WHEN-VALIDATE-RECORD fires during the call
to APP_STANDARD.EVENT. That call may be anywhere within existing
WHEN–NEW–FORM–INSTANCE logic in the form.
Ø Logic
you code for SPECIALn, where n is a number, fires before any
logic in the existing SPECIALn
trigger
Attaching Other Libraries to the CUSTOM Library
• APP_ITEM_PROPERTY2
• APP_DATE2
• APP_SPECIAL2
No comments
Note: Only a member of this blog may post a comment.