HI All,
Here i try to analyze different Data loading methods available...and some other debatable issues..
Best Practices:
1.Always have the rightly balanced teams.
A typical ratio for medium complexity process would be(1:1:2 )(Functional:Technical Designer:Developers).
Techical designer should be a guy who understands both the importance of business and technical limitations.
And the rule should be , technical designer should always be involved at the Functional Discussions with the customer.
This always help for not committing things which are not technically feasible..(Nothing is impossible ..but the effort needed to make it happen is worth or not??)
2.The other big Question is how should I divide my project team???
Method A>Functional,Technical( With in technical people by technologies they are good at like ..reports ,Forms & OAF ...)
Method B> One Process one team.(Atleast team size should be more than 20 to implement this)
There are advantages & disadvantages of both the ways..I am part of implementations which are done both ways....Lets me list some of them...
Method A:
Advantages: Less time is taken for development of components..(As technical people are doing what they are good at..)
Disadvantages:
1.I don't know whether I am correct or not in quoting this but the truth is you will find a clear divide between the two teams..And once things start going wrong people start blaming each other...I think every one might have experienced it already..
2.For technical people it is even bigger loss because you work on different components belonging to different process and never understand how your component fits in the overall solution. At the end of day it will be just a
piece of code...
3.Any change in the process during the course of development is very difficult to handle, as there will be inter dependencies among components
Method B:
Advantages:
1.Every one will feel the ownership of the process and better team spirit.
2.Technical team will also have better understanding of the processes and will able to implement the changes faster (as In a development project change is unavoidable ) as they have all the components with them
Disadvantages:
1.Development time might be a bit long as the technical people in u r team might not have expertise in all the technologies involved in the process
My views might be a bit biased as I am strong supporter for method B..
Technical:
Coming to our today's technical discussion ...data loading..This will be one of the first steps(development) and the last step(before live) of a implementation..
The typical way of data loading is a three step process.
1.To load data from the legacy/Flat files to temporary tables.
2..Perform all the validations on the temporary table data and load it to the open interfaces or API's
3.Run the Open interface Concurrent programs/API's to load data to the standard tables.
First let me figure ways of data movement in oracle apps..
1.Open Interfaces-- used for live interfaces(every day activity) & one time loading
2.API's--Almost same as Open interfaces but are easy to handle.(validation & integrity logic is taken care by them)
3.Out Bound Interfaces--Required if we integrate oracle apps with third party or legacy systems
4.EDI--automation process..we will talk about them later
For loading data
SQL Loader:
1.Used when data is available in flat files(tab delimited,Comma delimited)
2.Faster & Easier way of loading data
3.Can use sql functions to modify data
DB Links: if the legacy systems is on oracle data base the best thing is to get access to the data customer want to import through db links
Data loader tool : These are third party tools used for loading ,which automates the process of punching data.There are very much user friendly and not much technical expertise is required to work with them.
But the biggest disadvantage of these tools is they are slow.If you have huge data it is not advisable to use them(unless u r patient enough to see thru :-) )
The data loaded will be valid because it is as good as manual punching..
XML: Oracle Provides Apis to import XML data and to export data into XML.This should be most convenient way for data interaction as most of the other technology systems are able to parse XML data easily.
There are some limitations(can be easily overcome) also for these in oracle like while importing XML data into oracle tables oracle can't parse huge files
WEBADI: These are oracle provided templates for data loading into some standard interfaces.Easy to use. we can create the custom api's and use for data loading..i felt this is one of the best ways of loading data
UTL_FILE: it is PL/SQL way of loading data into oracle tables.This packages gives us the API to read and data into flat files.This method is very useful when the data to be loaded is less and more validations are required
before loading.One of the limitations of this pacakge it reads data in lines and the maximum length it can read is 1022 charecters..In writing data to files it can write only 32K in one shot..later we need to close the file
and reopen it again..
External Table:This concept concept comes from Oracle 9i onwards.This is one of the easiest way of loading data.Once you create the external table you can simple use the select stament to query the table.
On performance basis this is as good as Direct path loading of SQLLDR.(Technical People Give a try for this...)
Caution:Disable any indexes on the table before loading data..other wise it will slow down the process of loading data.
On summary for all conversions(one time data movement) use External Tables or SQL Loader
For interfaces use PL/sql,dblinks or XML
HI all i have not used SQL loader much..most of the time i have used External tables ,UTL_FIle and XML.So people who has much exposure can come up with any limitations or advantages of it..
Plz let me know if any thing is wrong or any other suggestions to make this better....
Monday, March 31, 2008
BARCODE in XML Reports
For generating reports with barcodes
1) You should have barcode font in your system i.e. Font name FREE3OF9 (Find as attachment)
2) Copy and paste the attached “Free 3of9” font in your machine directories “C:\WINDOWS\Fonts” and $JAVA_HOME\ lib\fonts
Example Java path “C:\Program Files\Java\j2re1.4.2_10\lib\fonts”
3) There is one configuration file i.e. file name is “xdo” as attachment)
4) Copy and paste the configuration file in your “XML Publisher Desktop\Template Builder for Word\config”
Example “C:\Program Files\Oracle\XML Publisher Desktop\Template Builder for Word\config”
?xml version = '5.5.0' encoding = 'UTF-8'?
config version="1.0.0" xmlns="http://xmlns.oracle.com/oxp/config/"
fonts
font family="Free 3 of 9" style="normal" weight="normal"
truetype path="C:\Program Files\Java\j2re1.4.2_12\lib\fonts\FREE3OF9.TTF"/
/font
/fonts
/config
include the tags..i removed the tags.as some problems when posting..check the configuration file once..
5) Once you have done the above setups, you can see the “Free 3of 9” font type under your MSWORD font.
6) Which column you have to display as barcode, just put this font to that column.
One thing to take care is convert the data to upper case before generating the XML
do it at the SQL level only..
1) You should have barcode font in your system i.e. Font name FREE3OF9 (Find as attachment)
2) Copy and paste the attached “Free 3of9” font in your machine directories “C:\WINDOWS\Fonts” and $JAVA_HOME\ lib\fonts
Example Java path “C:\Program Files\Java\j2re1.4.2_10\lib\fonts”
3) There is one configuration file i.e. file name is “xdo” as attachment)
4) Copy and paste the configuration file in your “XML Publisher Desktop\Template Builder for Word\config”
Example “C:\Program Files\Oracle\XML Publisher Desktop\Template Builder for Word\config”
?xml version = '5.5.0' encoding = 'UTF-8'?
config version="1.0.0" xmlns="http://xmlns.oracle.com/oxp/config/"
fonts
font family="Free 3 of 9" style="normal" weight="normal"
truetype path="C:\Program Files\Java\j2re1.4.2_12\lib\fonts\FREE3OF9.TTF"/
/font
/fonts
/config
include the tags..i removed the tags.as some problems when posting..check the configuration file once..
5) Once you have done the above setups, you can see the “Free 3of 9” font type under your MSWORD font.
6) Which column you have to display as barcode, just put this font to that column.
One thing to take care is convert the data to upper case before generating the XML
do it at the SQL level only..
Friday, March 28, 2008
White Paper on Oracle Apps Migration Project
Things to take care in a migration project..
These are all my personal observations if any one has anything new to add plz put out a mail i will incorporate them also..
Now a days we are coming across many migration projects..comparitviely these are supposed to be easy and straight forward..
But if we take care of few more things..it would be even smoother...
What is a migration project.??
It is moving from a product of lower version to a product of higher version(the other way is also called migration only)
What will the customer expect??
He expects a higer performance from the system
Added new Functionality
Better support from oracle
The system is supposed to work the same way as it operates..But look and feel might be a bit different..Functionality should remain intact
What are the major challenges for it?
1.The amout of customization in the legacy system
2.Type of Customization--whether custom built modules /Standard process customised
3.Integration with other systems
4.Support of new environments
5.Amount of change in the product from old to new version
6.Whether Standards Followed while customising the standard obejcts like (standard reports,standard forms,workflow..)
What are different phases in it?
1.MIgration phase..First we will take a clone of the instance migrate the applications to the new version with the old data)
Oracle provide the scripts to migrate the data and the software will install the new application objects.
2.Optimised migration--We redo the migration phase again in short span of time to calculate the exact cut over time
3.MTP--Movement to production
What all we need to take care???
Environmental change: some time the old systems might be in a different environment and new system will be on a different environment.
like old one in AIX and new ones in red hat linux.
One of the problem to expect is some commands in AIX might not work in Linux environments.
So if we have shell scripts in or host script files..those need to be checked and changed for the new environment
Database Layer Change:As the product is migrated there might be a database change happend like new not null columns getting added up
so incase you have any direct inserts happening into the oracle tables even interfaces they might need to be corrected
and values need to be populated to the new not null columns
Standard Report Modifications:Because the upgrade will get new application objects any modification done to the standard report objects will be lost.
it is better to rename those objects and re-register them to keep intact the object for future migration
Custom reports migration :For reports we need to just open the report in the new version of the report builder in case the report builder version difference exists
use shift+cntrl+k to compile the objects and save it.This should make the reports work.
But from my personal experience we need to run all the reports and data validation should be done for all..
This might be tedious task if there are huge number of reports ,But it has to be done.
Project plan should include the testing of each and every report(Just data level validation)
One more important thing i heard the compilation of the report builder will not validate the query ..
so any column changes will not get reflected at migration time they can only be find out at run time
Standard Form object migration: Migration will take care of the upgradation of standard objects. Hope that there are no customisation at
the code level for the standard objects.In case if there are any try to redo the customisation using the new feautures
like forms personalizations,custom.pll.One more important thing is before doing the customisation check whether those are really required
in the new system also..Even the customer process also might have changed ..so check with the customer
also before redoiing them .
Custom Form Objects Migration:This is not as simple as the reports..There is a FLINT60(upto 11.5.10.2) or Corresponding utility available to
upgrade the forms from the previous version to the new version.The major road block is if the forms are not developed
as per oracle application standards.Like property paletter not defined,seperate button to popup lov's
and other..In that case the form has to migrated using the flint60 utility and manually changes need to be made to have
the same look and feel of the new version.
For detailed steps of using flint60 and custom form migration check my blog http://oracleappstechnicalworld.blogspot.com/
Legacy Sytem Integration:This will be one of the big task..The first step we need to do is figure out how the legacy systems are integrated
1.Through File system
2.Through DB Links
3.Third party softwares
1.For file system integration check the directory permission and UTL_DIR_PATH variables in the legacy and new system
2.For dblinks one check whether the dblinks can be created between the new database version and the database version of the legacy system.Better to confirm at the assesment stage itself in case not, time need to be allocated for alternative solution implementation
3.Check througthly the compatabilities in case some thing like this exists
Pro*c Programs : The pro*c files need to be recompiled on the new instance.Pro*C Environment need to be set on the new application .If there any custom pro*c programs Pro*c enviromental
setup should be a task in the migration.process.
General Observations: One important thing to remember is the migration will get overwrite all the standard objects and standard application data ex:FND Messages.Suppose in the old instance you have changed the standard message text , then that change will be lost in the migration process.Those changes has to be redone.
These are all my personal observations if any one has anything new to add plz put out a mail i will incorporate them also..
Now a days we are coming across many migration projects..comparitviely these are supposed to be easy and straight forward..
But if we take care of few more things..it would be even smoother...
What is a migration project.??
It is moving from a product of lower version to a product of higher version(the other way is also called migration only)
What will the customer expect??
He expects a higer performance from the system
Added new Functionality
Better support from oracle
The system is supposed to work the same way as it operates..But look and feel might be a bit different..Functionality should remain intact
What are the major challenges for it?
1.The amout of customization in the legacy system
2.Type of Customization--whether custom built modules /Standard process customised
3.Integration with other systems
4.Support of new environments
5.Amount of change in the product from old to new version
6.Whether Standards Followed while customising the standard obejcts like (standard reports,standard forms,workflow..)
What are different phases in it?
1.MIgration phase..First we will take a clone of the instance migrate the applications to the new version with the old data)
Oracle provide the scripts to migrate the data and the software will install the new application objects.
2.Optimised migration--We redo the migration phase again in short span of time to calculate the exact cut over time
3.MTP--Movement to production
What all we need to take care???
Environmental change: some time the old systems might be in a different environment and new system will be on a different environment.
like old one in AIX and new ones in red hat linux.
One of the problem to expect is some commands in AIX might not work in Linux environments.
So if we have shell scripts in or host script files..those need to be checked and changed for the new environment
Database Layer Change:As the product is migrated there might be a database change happend like new not null columns getting added up
so incase you have any direct inserts happening into the oracle tables even interfaces they might need to be corrected
and values need to be populated to the new not null columns
Standard Report Modifications:Because the upgrade will get new application objects any modification done to the standard report objects will be lost.
it is better to rename those objects and re-register them to keep intact the object for future migration
Custom reports migration :For reports we need to just open the report in the new version of the report builder in case the report builder version difference exists
use shift+cntrl+k to compile the objects and save it.This should make the reports work.
But from my personal experience we need to run all the reports and data validation should be done for all..
This might be tedious task if there are huge number of reports ,But it has to be done.
Project plan should include the testing of each and every report(Just data level validation)
One more important thing i heard the compilation of the report builder will not validate the query ..
so any column changes will not get reflected at migration time they can only be find out at run time
Standard Form object migration: Migration will take care of the upgradation of standard objects. Hope that there are no customisation at
the code level for the standard objects.In case if there are any try to redo the customisation using the new feautures
like forms personalizations,custom.pll.One more important thing is before doing the customisation check whether those are really required
in the new system also..Even the customer process also might have changed ..so check with the customer
also before redoiing them .
Custom Form Objects Migration:This is not as simple as the reports..There is a FLINT60(upto 11.5.10.2) or Corresponding utility available to
upgrade the forms from the previous version to the new version.The major road block is if the forms are not developed
as per oracle application standards.Like property paletter not defined,seperate button to popup lov's
and other..In that case the form has to migrated using the flint60 utility and manually changes need to be made to have
the same look and feel of the new version.
For detailed steps of using flint60 and custom form migration check my blog http://oracleappstechnicalworld.blogspot.com/
Legacy Sytem Integration:This will be one of the big task..The first step we need to do is figure out how the legacy systems are integrated
1.Through File system
2.Through DB Links
3.Third party softwares
1.For file system integration check the directory permission and UTL_DIR_PATH variables in the legacy and new system
2.For dblinks one check whether the dblinks can be created between the new database version and the database version of the legacy system.Better to confirm at the assesment stage itself in case not, time need to be allocated for alternative solution implementation
3.Check througthly the compatabilities in case some thing like this exists
Pro*c Programs : The pro*c files need to be recompiled on the new instance.Pro*C Environment need to be set on the new application .If there any custom pro*c programs Pro*c enviromental
setup should be a task in the migration.process.
General Observations: One important thing to remember is the migration will get overwrite all the standard objects and standard application data ex:FND Messages.Suppose in the old instance you have changed the standard message text , then that change will be lost in the migration process.Those changes has to be redone.
Tuesday, March 18, 2008
Useful Information about LOG & OUT Files
Recently we came around a scenario whether the naming convention of the out files need to be changed.After some R&D we find some good document regarding this..
Where do concurrent request or manager logfiles and output files go?
The concurrent manager first looks for the environment variable
$APPLCSF. If this is set, it creates a path using two other
environment variables: $APPLLOG and $APPLOUT
It places log files in $APPLCSF/$APPLLOG, output files go in
$APPLCSF/$APPLOUT
So for example, if you have this environment set:
$APPLCSF = /u01/appl/common
$APPLLOG = log
$APPLOUT = out
The concurrent manager will place log files in /u01/appl/common/log,
and output files in /u01/appl/common/out
Note that $APPLCSF must be a full, absolute path, and the other two
are directory names.
If $APPLCSF is not set, it places the files under the product top of
the application associated with the request. For example, a PO report
would go under $PO_TOP/$APPLLOG and $PO_TOP/$APPLOUT
Logfiles go to: /u01/appl/po/9.0/log
Output files to: /u01/appl/po/9.0/out
All these directories must exist and have the correct permissions.
Note that all concurrent requests produce a log file, but not necessarily
an output file.
Concurrent manager logfiles follow the same convention, and will be
found in the $APPLLOG directory
What are the logfile and output file naming conventions?
Request logfiles: l.req
Output files: If $APPCPNAM is not set:.
If $APPCPNAM = REQID: o.out
If $APPCPNAM = USER:.out
Where: = The request id of the concurrent request
And: = The id of the user that submitted the request
Manager logfiles:
ICM logfile: Default is std.mgr, can be changed with the mgrname
startup parameter
Concurrent manager log: w.mgr
Transaction manager log: t.mgr
Conflict Resolution manager log: c.mgr
Where: is the concurrent process id of the manager
Where do concurrent request or manager logfiles and output files go?
The concurrent manager first looks for the environment variable
$APPLCSF. If this is set, it creates a path using two other
environment variables: $APPLLOG and $APPLOUT
It places log files in $APPLCSF/$APPLLOG, output files go in
$APPLCSF/$APPLOUT
So for example, if you have this environment set:
$APPLCSF = /u01/appl/common
$APPLLOG = log
$APPLOUT = out
The concurrent manager will place log files in /u01/appl/common/log,
and output files in /u01/appl/common/out
Note that $APPLCSF must be a full, absolute path, and the other two
are directory names.
If $APPLCSF is not set, it places the files under the product top of
the application associated with the request. For example, a PO report
would go under $PO_TOP/$APPLLOG and $PO_TOP/$APPLOUT
Logfiles go to: /u01/appl/po/9.0/log
Output files to: /u01/appl/po/9.0/out
All these directories must exist and have the correct permissions.
Note that all concurrent requests produce a log file, but not necessarily
an output file.
Concurrent manager logfiles follow the same convention, and will be
found in the $APPLLOG directory
What are the logfile and output file naming conventions?
Request logfiles: l
Output files: If $APPCPNAM is not set:
If $APPCPNAM = REQID: o
If $APPCPNAM = USER:
Where:
And:
Manager logfiles:
ICM logfile: Default is std.mgr, can be changed with the mgrname
startup parameter
Concurrent manager log: w
Transaction manager log: t
Conflict Resolution manager log: c
Where:
Saturday, February 16, 2008
Migrating Custom Forms--4.5 to 6i
Hi,
Currently i am doing a migration project ..and migrating forms...
But for migrating forms there is oracle standard process to do..but unfortunately many people didn't do that way...But this process is the recommended one.
Currently i am facing some issues with FLint60 utility...i will post them also here
1."ERROR ? Item BLOCKNAME.RADIO_BUTTON81 (Radio Group) requires Hint Text "
"ERROR ? Library Location 'APPCORE.pll' for Attached Library APPCORE must not contain a path or extension
ERROR ? Library Location 'APPDAYPK.pll' for Attached Library APPDAYPK must not contain a path or extension
Any problems like above or with the libraries just delete the libraries in the older version form
and then reattach and use the flint60 untility
2.Error like radio group hint text can be ignored
3.One important thing is check how the forms are desinged and see that they are upgraded to the 11.5.10 feautures like lov and others..This is really important make sure that your custom forms look and feel match with oracle latest apps version standards
Upgrading Custom Forms to Release 11i
This section covers upgrading custom forms built with Oracle Forms 4.5, the Oracle Applications coding standards, and Oracle Application Object Library. It applies to custom forms built to integrate with Releases 10SC, 10.7 NCA, and 11.
Upgrading your custom forms to Release 11i consists of the following basic steps:
1. On your developer client machine convert your Oracle Forms 4.5 forms to Oracle Forms 6i using the Oracle Forms 6i Form Generator and make any required changes related to converting to PL/SQL 8
If you have any library files which you attached to your form you must first convert the library files prior to attempting to upgrade your form module. To convert your 4.5 form to a 6i form load a copy of your 4.5 form into 6i form builder and save 'only', DO NOT re-compile it.
By loading the library or form module the developer will perform a number of steps to prepare the files for the new developer environment once successfully saved you may proceed the the next steps outlined below.
2. Move the newly converted 6i form to the Forms server in the $AU_TOP/forms/US directory. Use the Oracle Applications upgrade utility (flint60) on the Oracle Forms 6i .fmb file to apply changes that help your form conform to Release 11i standards.
Release 11i of applications provides an upgrade utility called flint60 which performs a number changes to custom forms previously developed for Oracle Applications 10.7SC/NCA and 11.0.x. The changes include 11i enhancements and applications coding standards verification. The utility may be run multiple times against the custom developed form during the development process.
**** This utility is only for the form module. There
**** is no such utility provide nor needed for custom
**** developed library files.
NOTE: Flint60 is a 32 bit utility that runs on your forms server tier (i.e. it will not run on any machine that is not certified as a forms server like ... Windows95 or Windows 3.11 )
To successfully run the flint60 utility, the flint60.ora file must be created and contain proper values.
Setting Up the Configuration File
The flint60 utility requires a configuration file, flint60.ora, to hold the database username and password and other information. The flint60.ora file is a simple text file that should have the following information:
server_host=your_web_server_name
message_file=location_of_the_message_help_file_on_web_server
connect=[y|n]
userid=database_username_and_password
The web server host name that will be used to access the .html log files the virtual path and filename of the message descriptions file, fnderr.html boolean that indicates whether to verify blocks against the database if database=y, then this is the ORACLE username and password to use to connect to the database.
Note that when attempting to connect to the database, flint60 uses the table ACCESSIBLE_COLUMNS (actually a public synonym for SYS.ALL_TAB_COLUMNS) to determine the constraints (data type, length, null allowed) for a database item?s column. If ACCESSIBLE_COLUMNS is inaccessible, flint60 will generate multiple fatal errors in the log file (if the option to connect to the database is selected).
Example:
server_host=www-apps.us.oracle.com
message_file=/r115/fnderr.html
connect=y
userid=apps/apps@devdb
You must set an environment variable, FLINT60_CONFIG (for Unix) that points to the flint60.ora configuration file. If the FLINT60_CONFIG environment variable is not set then flint60 will search for the file flint60.ora in the current directory. If you see the message
?LRM-00109: could not open parameter file ?? ? when you try to run flint60, then the configuration file could not be loaded. If you run the flint60 utility without the configuration file, the .html log file will not be able to provide context-sensitive links to the help file that describes each of the messages generated by flint60, and the utility may be unable to connect to the database (which would create additional errors in the log file).
Verify Your Environment
It is important to verify that you are pointing to the correct versions of Oracle Forms and Oracle Applications before running the upgrade utility, or you may get spurious or misleading error messages. For example, your environment must point to the correct versions of APPSTAND.fmb and APPCORE.pll. Ensure that the environment is configured properly and is pointing to an Oracle Forms 6i environment.
Verify that the FORMS60_PATH (Unix environment variable, or NT registry setting) points to the directories that hold the correct versions of APPSTAND.fmb and APPCORE.pll.
Ensure the DISPLAY environment variable is set and valid (for Unix only).
To run flint60 utility the command line execution would look like the
following:
Command line switches
The flint60 utility can accept one, two, or no switches on the command line, as shown:
flint60 -u.fmb .fmb ...
flint60 -uc.fmb .fmb ...
flint60.fmb .fmb ...
-u Parameter: This is the ?upgrade? mode. Include the -u
(?upgrade?) switch if you want the flint60 utility to write a new .fmb file with any required changes.
-c Parameter: Include the -c switch if you want the flint60 utility to not clear out hint text. Use the -c switch when you are running flint60 again after the initial upgrade and you have added hint text that you do not want the utility to clear out (of the new file written by the utility because of the -u switch). If you have not added hint text manually, you do not need to use this switch. The -c switch is ignored if the -u switch is not present.
If no values or switches are passed to the flint60 ultity then this is the ?standards compliance checker? mode.
If you do not use the -u switch, the flint60 utility simply performs various checks on your form and writes out a log file listing any standards compliance errors or warnings.
Form name arguments
The flint60 utility expects form names on the command line:
flint60 -uc.fmb .fmb ...
The filenames can be fully qualified with paths and/or environment variables (for Unix):
flint60 $fnd/forms/US/.fmb
/custgldev/custgl/11.5/forms/US/.fmb ...
To run flint60 for all forms in the current directory (if using an appropriate Unix shell that expands file wildcards, such as tcsh):
flint60 *.fmb
To run flint60 for all forms in a specific directory (if using an appropriate Unix shell that expands file wildcards, such as tcsh):
flint60 $fnd/forms/US/*.fmb
If you are running the flint60 utility on Windows NT, you may need to create a .bat script to run multiple commands because NT does not support expanding command line wildcards.
Reviewing flint60 Log File Output
The flint60 utility provides a detailed log file of messages as it goes through your form. The log file is called form_filename.fmb.html, and you can read it using any standard browser. The utility provides one log file for each form, located in the current directory.
The message types are:
Status: an informational message
Action: each action taken by the flint60 utility, such as changing a
piece of boilerplate to an associated prompt
3. Correct any errors found by the upgrade utility, and run the utility again to verify your changes
When utilizing the forms upgrade utility an HTML output file is created which provides detail of the changes made to the form module. Additionally, the output file provides warning and suggested changes that should be considered for custom form development which if followed will ensure custom form is 11i Oracle look and feel.
4. Perform any required manual changes that may be necessary, such as changes to internal menu names
Performing Required Manual Changes on Your Forms
Menu calls
If you have hardcoded calls in your form that modify the default
(pulldown) menu, such as calls that enable or disable menu entries, you may need to modify your menu calls because the internal names of the menu names have changed to be consistent with the rearranged menu.
Changes to Internal Menu Names from Release 11 to Release 11i (See page 27 - 42)
You can typically find these calls by using the ?Find and Replace PL/SQL? feature in the Oracle Forms 6i Form Builder (under the Program menu choice) to search for the following strings (do not search as case sensitive):
SET_MENU_ITEM_PROPERTY
GET_MENU_ITEM_PROPERTY
FIND_MENU_ITEM
APP_SPECIAL.ENABLE
These calls must be evaluated and changed if necessary.
Toolbar block calls
If you have code in your form that calls anything in the pre-11i toolbar, such as calls to enable or disable toolbar buttons, you must modify your code. Behind the scenes, the toolbar has been reimplemented to not use a distinct TOOLBAR block. It is now part of the menu, and toolbar icons are now enabled and disabled automatically when you programmatically enable or disable menu entries using the APP_SPECIAL routines.
Changes to Internal Menu Names from Release 11 to Release 11i (See page 27 - 42)
APP_SPECIAL: Menu and Toolbar Control (See page 10 - 15)
You can typically find these calls by using the ?Find and Replace PL/SQL? feature in the Oracle Forms 6i Form Builder (under the Program menu choice) to search for the string (including the single quote and the period):
?TOOLBAR.
Note that the TOOLBAR canvas has not been removed, because it serves as a holding area for certain Oracle Applications fields (such as switcher fields).
5. Perform optional manual changes, such as converting alternative regions to tabbed regions and enhancing special menus, as desired
6. Use the Oracle Forms 6i generator to generate the .fmx file for your upgraded form
Ctrl-T will compile and generate your form. Should first be performed on you development environment to ensure that all the code compiles and has been resolved prior to loading the form into the production environment.
7. Test your upgraded form within Oracle Applications 11i To test your form you will need to run the form within the applications environment only. It is possible to run the form stand alone using the forms server and the static login html file whereas the following line in the html file would initially look like:
serverArgs="module=Q:\oa\appltst\fnd\11.0.28\forms\US\FNDSCSGN
userid=applsyspub/pub@VD11 fndnam=apps"
serverArgs="module=Q:\oa\appltst\fnd\11.0.28\forms\US\FNDSCSGN
userid=apps/apps@VD11"
Note: While it is technically possible to skip the first step and go directly to the Oracle Applications upgrade utility step, we recommend that you do the first step separately to better isolate the changes to your form should there be any problem with either upgrade step.
Currently i am doing a migration project ..and migrating forms...
But for migrating forms there is oracle standard process to do..but unfortunately many people didn't do that way...But this process is the recommended one.
Currently i am facing some issues with FLint60 utility...i will post them also here
1."ERROR ? Item BLOCKNAME.RADIO_BUTTON81 (Radio Group) requires Hint Text "
"ERROR ? Library Location 'APPCORE.pll' for Attached Library APPCORE must not contain a path or extension
ERROR ? Library Location 'APPDAYPK.pll' for Attached Library APPDAYPK must not contain a path or extension
Any problems like above or with the libraries just delete the libraries in the older version form
and then reattach and use the flint60 untility
2.Error like radio group hint text can be ignored
3.One important thing is check how the forms are desinged and see that they are upgraded to the 11.5.10 feautures like lov and others..This is really important make sure that your custom forms look and feel match with oracle latest apps version standards
Upgrading Custom Forms to Release 11i
This section covers upgrading custom forms built with Oracle Forms 4.5, the Oracle Applications coding standards, and Oracle Application Object Library. It applies to custom forms built to integrate with Releases 10SC, 10.7 NCA, and 11.
Upgrading your custom forms to Release 11i consists of the following basic steps:
1. On your developer client machine convert your Oracle Forms 4.5 forms to Oracle Forms 6i using the Oracle Forms 6i Form Generator and make any required changes related to converting to PL/SQL 8
If you have any library files which you attached to your form you must first convert the library files prior to attempting to upgrade your form module. To convert your 4.5 form to a 6i form load a copy of your 4.5 form into 6i form builder and save 'only', DO NOT re-compile it.
By loading the library or form module the developer will perform a number of steps to prepare the files for the new developer environment once successfully saved you may proceed the the next steps outlined below.
2. Move the newly converted 6i form to the Forms server in the $AU_TOP/forms/US directory. Use the Oracle Applications upgrade utility (flint60) on the Oracle Forms 6i .fmb file to apply changes that help your form conform to Release 11i standards.
Release 11i of applications provides an upgrade utility called flint60 which performs a number changes to custom forms previously developed for Oracle Applications 10.7SC/NCA and 11.0.x. The changes include 11i enhancements and applications coding standards verification. The utility may be run multiple times against the custom developed form during the development process.
**** This utility is only for the form module. There
**** is no such utility provide nor needed for custom
**** developed library files.
NOTE: Flint60 is a 32 bit utility that runs on your forms server tier (i.e. it will not run on any machine that is not certified as a forms server like ... Windows95 or Windows 3.11 )
To successfully run the flint60 utility, the flint60.ora file must be created and contain proper values.
Setting Up the Configuration File
The flint60 utility requires a configuration file, flint60.ora, to hold the database username and password and other information. The flint60.ora file is a simple text file that should have the following information:
server_host=your_web_server_name
message_file=location_of_the_message_help_file_on_web_server
connect=[y|n]
userid=database_username_and_password
The web server host name that will be used to access the .html log files the virtual path and filename of the message descriptions file, fnderr.html boolean that indicates whether to verify blocks against the database if database=y, then this is the ORACLE username and password to use to connect to the database.
Note that when attempting to connect to the database, flint60 uses the table ACCESSIBLE_COLUMNS (actually a public synonym for SYS.ALL_TAB_COLUMNS) to determine the constraints (data type, length, null allowed) for a database item?s column. If ACCESSIBLE_COLUMNS is inaccessible, flint60 will generate multiple fatal errors in the log file (if the option to connect to the database is selected).
Example:
server_host=www-apps.us.oracle.com
message_file=/r115/fnderr.html
connect=y
userid=apps/apps@devdb
You must set an environment variable, FLINT60_CONFIG (for Unix) that points to the flint60.ora configuration file. If the FLINT60_CONFIG environment variable is not set then flint60 will search for the file flint60.ora in the current directory. If you see the message
?LRM-00109: could not open parameter file ?
Verify Your Environment
It is important to verify that you are pointing to the correct versions of Oracle Forms and Oracle Applications before running the upgrade utility, or you may get spurious or misleading error messages. For example, your environment must point to the correct versions of APPSTAND.fmb and APPCORE.pll. Ensure that the environment is configured properly and is pointing to an Oracle Forms 6i environment.
Verify that the FORMS60_PATH (Unix environment variable, or NT registry setting) points to the directories that hold the correct versions of APPSTAND.fmb and APPCORE.pll.
Ensure the DISPLAY environment variable is set and valid (for Unix only).
To run flint60 utility the command line execution would look like the
following:
Command line switches
The flint60 utility can accept one, two, or no switches on the command line, as shown:
flint60 -u
flint60 -uc
flint60
-u Parameter: This is the ?upgrade? mode. Include the -u
(?upgrade?) switch if you want the flint60 utility to write a new .fmb file with any required changes.
-c Parameter: Include the -c switch if you want the flint60 utility to not clear out hint text. Use the -c switch when you are running flint60 again after the initial upgrade and you have added hint text that you do not want the utility to clear out (of the new file written by the utility because of the -u switch). If you have not added hint text manually, you do not need to use this switch. The -c switch is ignored if the -u switch is not present.
If no values or switches are passed to the flint60 ultity then this is the ?standards compliance checker? mode.
If you do not use the -u switch, the flint60 utility simply performs various checks on your form and writes out a log file listing any standards compliance errors or warnings.
Form name arguments
The flint60 utility expects form names on the command line:
flint60 -uc
The filenames can be fully qualified with paths and/or environment variables (for Unix):
flint60 $fnd/forms/US/
/custgldev/custgl/11.5/forms/US/
To run flint60 for all forms in the current directory (if using an appropriate Unix shell that expands file wildcards, such as tcsh):
flint60 *.fmb
To run flint60 for all forms in a specific directory (if using an appropriate Unix shell that expands file wildcards, such as tcsh):
flint60 $fnd/forms/US/*.fmb
If you are running the flint60 utility on Windows NT, you may need to create a .bat script to run multiple commands because NT does not support expanding command line wildcards.
Reviewing flint60 Log File Output
The flint60 utility provides a detailed log file of messages as it goes through your form. The log file is called form_filename.fmb.html, and you can read it using any standard browser. The utility provides one log file for each form, located in the current directory.
The message types are:
Status: an informational message
Action: each action taken by the flint60 utility, such as changing a
piece of boilerplate to an associated prompt
3. Correct any errors found by the upgrade utility, and run the utility again to verify your changes
When utilizing the forms upgrade utility an HTML output file is created which provides detail of the changes made to the form module. Additionally, the output file provides warning and suggested changes that should be considered for custom form development which if followed will ensure custom form is 11i Oracle look and feel.
4. Perform any required manual changes that may be necessary, such as changes to internal menu names
Performing Required Manual Changes on Your Forms
Menu calls
If you have hardcoded calls in your form that modify the default
(pulldown) menu, such as calls that enable or disable menu entries, you may need to modify your menu calls because the internal names of the menu names have changed to be consistent with the rearranged menu.
Changes to Internal Menu Names from Release 11 to Release 11i (See page 27 - 42)
You can typically find these calls by using the ?Find and Replace PL/SQL? feature in the Oracle Forms 6i Form Builder (under the Program menu choice) to search for the following strings (do not search as case sensitive):
SET_MENU_ITEM_PROPERTY
GET_MENU_ITEM_PROPERTY
FIND_MENU_ITEM
APP_SPECIAL.ENABLE
These calls must be evaluated and changed if necessary.
Toolbar block calls
If you have code in your form that calls anything in the pre-11i toolbar, such as calls to enable or disable toolbar buttons, you must modify your code. Behind the scenes, the toolbar has been reimplemented to not use a distinct TOOLBAR block. It is now part of the menu, and toolbar icons are now enabled and disabled automatically when you programmatically enable or disable menu entries using the APP_SPECIAL routines.
Changes to Internal Menu Names from Release 11 to Release 11i (See page 27 - 42)
APP_SPECIAL: Menu and Toolbar Control (See page 10 - 15)
You can typically find these calls by using the ?Find and Replace PL/SQL? feature in the Oracle Forms 6i Form Builder (under the Program menu choice) to search for the string (including the single quote and the period):
?TOOLBAR.
Note that the TOOLBAR canvas has not been removed, because it serves as a holding area for certain Oracle Applications fields (such as switcher fields).
5. Perform optional manual changes, such as converting alternative regions to tabbed regions and enhancing special menus, as desired
6. Use the Oracle Forms 6i generator to generate the .fmx file for your upgraded form
Ctrl-T will compile and generate your form. Should first be performed on you development environment to ensure that all the code compiles and has been resolved prior to loading the form into the production environment.
7. Test your upgraded form within Oracle Applications 11i To test your form you will need to run the form within the applications environment only. It is possible to run the form stand alone using the forms server and the static login html file whereas the following line in the html file would initially look like:
serverArgs="module=Q:\oa\appltst\fnd\11.0.28\forms\US\FNDSCSGN
userid=applsyspub/pub@VD11 fndnam=apps"
serverArgs="module=Q:\oa\appltst\fnd\11.0.28\forms\US\FNDSCSGN
userid=apps/apps@VD11"
Note: While it is technically possible to skip the first step and go directly to the Oracle Applications upgrade utility step, we recommend that you do the first step separately to better isolate the changes to your form should there be any problem with either upgrade step.
Folder Options in Forms -Part2
Steps to create Folder Form
Step – 1 Create Folder Objects
• Reference Folder Object
Every folder form must contain the folder objects (such as the windows that are used for saving folders and changing prompts) included in the STANDARD_FOLDER object group. If this object group does not already exist in your form, reference it from APPSTAND. $AU_TOP/au/11.5.0/forms/US/APPSTAND.fmb
• Attached the Folder library
Every folder form must have the library APPFLDR.pll attached. The library file is $APPL_TOP/au/11.5.0/resource/APPFLDR.pll.
• Create the Content/Fixed Canvas
Create a content canvas, as you would for any window. Assign it the property class CANVAS, and assign it to the appropriate window. This canvas will hold the block scroll bar, the record indicator, and the folder_open and folder_title objects. This canvas will also hold any fields that would not be part of the folder block, such as required primary key fields.
Note: The name of the content canvas cannot be a substring of the name of the stacked canvas, as this will cause errors. For example, if the content canvas is called ORDERS, then the stacked canvas cannot be called ORDERS_FOLDER, but ORDERS_MAIN and ORDERS_FOLDER would be acceptable.
• Create the Stack Canvas
Create a stacked canvas; it holds prompt fields and displayed fields of the folder block, as well as the ORDER_BY# buttons.
Determine the appropriate Y position for the top of the folder block (this corresponds to the Y position for the top of the Folder Open button and the Folder Title). This value is referred to as Y_OFFSET, and is used to calculate the correct positions for items and canvasses. Typically Y_OFFSET should be .25 inches (that is, the top of the Folder Open button should be one character down from the top of the window) if the folder is the first block in the window.
Set the following properties for the stacked canvas:
Sequence : After the content canvas.
Property Class : CANVAS_STACKED
Displayed :True for the stacked canvas that will be shown
immediately upon entering the block; False for any
others.
Window : Same as for the content canvas.
View Height :.5” + (.25” * number of rows to be displayed)
Display X Pos : .5” (May be adjusted later)
Display Y pos : Y offset + .25
View Horiz
Scroll Bar : True
Step – 2 Create Folder block item
• Folder Block Item
Create a block to hold the fields of the folder, as you would any other block. The block scroll bar must be on the content canvas.
Suggestion: Although the scroll bar must be on the content canvas, most of the fields belong on the stacked canvas. If you are using the default block functionality, this can be achieved most easily by specifying the stacked canvas when creating the default block, and then changing the Scroll Bar Canvas property after the block has been created. One or more fields may be on the content canvas. These fields must always be the leftmost fields in the block, and will not respond to folder events (e.g. Move Right, Widen, Hide). Identify which, if any, fields will be on the content canvas, and move them there. Sequence these fields before any of the fields that will be on stacked canvasses.
Adjust the Display X Position for the stacked canvas view so that it is .1” to the right of the fields on the content canvas. For each item to be displayed as part of the folder, set the properties as follows:
TYPE: Text Item, Check box or List only.
X Position: Positioned at runtime
Y Position: If on content canvas, Y_OFFSET + .5”; otherwise, .25”
Width: Set at runtime
Canvas: The content or stacked canvas
Displayed: If part of the default display, True; otherwise False. Fields on the content canvas must be Displayed.
Note: The position and width of any field on the content canvas must be set accurately in the Designer. Also, the width of a check box should be set accurately to 0.3”. Check boxes with width 0.2” are acceptable, but do not save space since APPFLDR always allocates at least 0.3” for a check box.
• Folder Switcher Item
Create a switcher field for the block. In a combination block, this should be called ’SWITCHER’, and in any other folder block, it should be called ’FOLDER_SWITCHER’. It must be sequenced first in the block, and must use the SWITCHER property class. Place it on the content/fixed canvas. This field must not have a corresponding field in the prompt block. Attached the following trigger to the switcher item:-
Trigger: WHEN–NEW–ITEM–INSTANCE (Execution Style: Override)
On field SWITCHER:
app_folder_move_cursor(’1’);
• Create Current Record Indicator/Drilldown Record Indicator
Create a record indicator for the block. It must be called either CURRENT_RECORD_INDICATOR or DRILLDOWN_RECORD_INDICATOR. Do not include a corresponding field in the prompt block. The folder code disables certain functions automatically, but it is developer responsibility to write the code to manage the indicator. The WHEN–NEW–ITEM–INSTANCE trigger for CURRENT_RECORD_INDICATOR must call
app_folder_move_cursor(’1’).
Step – 3 Create Block Level Trigger
• Trigger: WHEN–NEW–BLOCK–INSTANCE (Execution Style: Before)
app_folder.event(’WHEN–NEW–BLOCK–INSTANCE’);
This trigger instantiates the folder block(if necessary), attempting to load the user’s default if on exists.
• Trigger: KEY-NEXT-ITEM
app_folder.event (’KEY–NEXT–ITEM’);
This trigger navigates to the next folder–sequenced item. Moves to next record if needed. Fire in Enter Query mode must be TRUE.
• Trigger: KEY-PREV-ITEM
app_folder.event(’KEY–PREV–ITEM’);
This trigger navigates to the prior folder–sequenced item. Moves to
prior record if needed. Fire in Enter Query mode must be TRUE.
• Trigger: PRE–BLOCK (Execution Style: Before)
app_folder.event(’PRE–BLOCK’);
This trigger establishes values for the folder block (when more than one is defined). It re-enables the folder menu upon entering the block.
• Trigger: POST–BLOCK (Execution Style: Before)
app_folder.event(’POST–BLOCK’);
This call disables the folder menu.
• Trigger: PRE–QUERY (Execution Style: Before)
app_folder.event(’PRE–QUERY’);
This call builds the order by clause for the query.
• Trigger: POS–QUERY (Execution Style: Before)
app_folder.event(’POST–QUERY’);
If the folder block is the master of a master–detail relationship, this trigger is required. It extracts the WHERE clause from SYSTEM.LAST_QUERY. Without this trigger, the detail block’s query can be extracted instead, which can lead to saving an invalid query with the folder.
• Trigger: User–named trigger FOLDER_RETURN_ACTION
<
Step – 1 Create Folder Objects
• Reference Folder Object
Every folder form must contain the folder objects (such as the windows that are used for saving folders and changing prompts) included in the STANDARD_FOLDER object group. If this object group does not already exist in your form, reference it from APPSTAND. $AU_TOP/au/11.5.0/forms/US/APPSTAND.fmb
• Attached the Folder library
Every folder form must have the library APPFLDR.pll attached. The library file is $APPL_TOP/au/11.5.0/resource/APPFLDR.pll.
• Create the Content/Fixed Canvas
Create a content canvas, as you would for any window. Assign it the property class CANVAS, and assign it to the appropriate window. This canvas will hold the block scroll bar, the record indicator, and the folder_open and folder_title objects. This canvas will also hold any fields that would not be part of the folder block, such as required primary key fields.
Note: The name of the content canvas cannot be a substring of the name of the stacked canvas, as this will cause errors. For example, if the content canvas is called ORDERS, then the stacked canvas cannot be called ORDERS_FOLDER, but ORDERS_MAIN and ORDERS_FOLDER would be acceptable.
• Create the Stack Canvas
Create a stacked canvas; it holds prompt fields and displayed fields of the folder block, as well as the ORDER_BY# buttons.
Determine the appropriate Y position for the top of the folder block (this corresponds to the Y position for the top of the Folder Open button and the Folder Title). This value is referred to as Y_OFFSET, and is used to calculate the correct positions for items and canvasses. Typically Y_OFFSET should be .25 inches (that is, the top of the Folder Open button should be one character down from the top of the window) if the folder is the first block in the window.
Set the following properties for the stacked canvas:
Sequence : After the content canvas.
Property Class : CANVAS_STACKED
Displayed :True for the stacked canvas that will be shown
immediately upon entering the block; False for any
others.
Window : Same as for the content canvas.
View Height :.5” + (.25” * number of rows to be displayed)
Display X Pos : .5” (May be adjusted later)
Display Y pos : Y offset + .25
View Horiz
Scroll Bar : True
Step – 2 Create Folder block item
• Folder Block Item
Create a block to hold the fields of the folder, as you would any other block. The block scroll bar must be on the content canvas.
Suggestion: Although the scroll bar must be on the content canvas, most of the fields belong on the stacked canvas. If you are using the default block functionality, this can be achieved most easily by specifying the stacked canvas when creating the default block, and then changing the Scroll Bar Canvas property after the block has been created. One or more fields may be on the content canvas. These fields must always be the leftmost fields in the block, and will not respond to folder events (e.g. Move Right, Widen, Hide). Identify which, if any, fields will be on the content canvas, and move them there. Sequence these fields before any of the fields that will be on stacked canvasses.
Adjust the Display X Position for the stacked canvas view so that it is .1” to the right of the fields on the content canvas. For each item to be displayed as part of the folder, set the properties as follows:
TYPE: Text Item, Check box or List only.
X Position: Positioned at runtime
Y Position: If on content canvas, Y_OFFSET + .5”; otherwise, .25”
Width: Set at runtime
Canvas: The content or stacked canvas
Displayed: If part of the default display, True; otherwise False. Fields on the content canvas must be Displayed.
Note: The position and width of any field on the content canvas must be set accurately in the Designer. Also, the width of a check box should be set accurately to 0.3”. Check boxes with width 0.2” are acceptable, but do not save space since APPFLDR always allocates at least 0.3” for a check box.
• Folder Switcher Item
Create a switcher field for the block. In a combination block, this should be called ’SWITCHER’, and in any other folder block, it should be called ’FOLDER_SWITCHER’. It must be sequenced first in the block, and must use the SWITCHER property class. Place it on the content/fixed canvas. This field must not have a corresponding field in the prompt block. Attached the following trigger to the switcher item:-
Trigger: WHEN–NEW–ITEM–INSTANCE (Execution Style: Override)
On field SWITCHER:
app_folder_move_cursor(’1’);
• Create Current Record Indicator/Drilldown Record Indicator
Create a record indicator for the block. It must be called either CURRENT_RECORD_INDICATOR or DRILLDOWN_RECORD_INDICATOR. Do not include a corresponding field in the prompt block. The folder code disables certain functions automatically, but it is developer responsibility to write the code to manage the indicator. The WHEN–NEW–ITEM–INSTANCE trigger for CURRENT_RECORD_INDICATOR must call
app_folder_move_cursor(’1’).
Step – 3 Create Block Level Trigger
• Trigger: WHEN–NEW–BLOCK–INSTANCE (Execution Style: Before)
app_folder.event(’WHEN–NEW–BLOCK–INSTANCE’);
This trigger instantiates the folder block(if necessary), attempting to load the user’s default if on exists.
• Trigger: KEY-NEXT-ITEM
app_folder.event (’KEY–NEXT–ITEM’);
This trigger navigates to the next folder–sequenced item. Moves to next record if needed. Fire in Enter Query mode must be TRUE.
• Trigger: KEY-PREV-ITEM
app_folder.event(’KEY–PREV–ITEM’);
This trigger navigates to the prior folder–sequenced item. Moves to
prior record if needed. Fire in Enter Query mode must be TRUE.
• Trigger: PRE–BLOCK (Execution Style: Before)
app_folder.event(’PRE–BLOCK’);
This trigger establishes values for the folder block (when more than one is defined). It re-enables the folder menu upon entering the block.
• Trigger: POST–BLOCK (Execution Style: Before)
app_folder.event(’POST–BLOCK’);
This call disables the folder menu.
• Trigger: PRE–QUERY (Execution Style: Before)
app_folder.event(’PRE–QUERY’);
This call builds the order by clause for the query.
• Trigger: POS–QUERY (Execution Style: Before)
app_folder.event(’POST–QUERY’);
If the folder block is the master of a master–detail relationship, this trigger is required. It extracts the WHERE clause from SYSTEM.LAST_QUERY. Without this trigger, the detail block’s query can be extracted instead, which can lead to saving an invalid query with the folder.
• Trigger: User–named trigger FOLDER_RETURN_ACTION
<
>
This trigger is fired each time the folder does certain operations that you may need to further process. ’global.folder_action’ contains the name of the process, and ’global.folder_field’ holds the name of the relevant field, if any, stripped of the block name. Specific callbacks may populate other global variables. The FOLDER_RETURN_ACTION trigger is optional. You should code it if you need to perform logic on any of the supported events.
Example:-
Following is code written in FOLDER_RETURN_ACTION trigger to allow update for ‘COL1’, ‘COL2’ and ‘COL3’ in the folder block:-
DECLARE
field_name VARCHAR2(30);
BEGIN
IF (:global.folder_action = ’SHOW–FIELD’) THEN
field_name:= NAME_IN(’global.folder_field’);
IF (field_name IN (’COL1’, ’COL2’, ’COL3’)) THEN
app_item_property.set_property (
’’||’.’||field_name,
ALTERABLE,
PROPERTY_ON);
END IF;
END IF;
END;
Step – 4 Create Prompt Block
Create a one record block to hold the fields that act as prompts for the folder block. For every item in the folder block that may be displayed, the prompt block must contain an item of the same name (except for the record indicator and the switcher). The initial settings of the prompts drive the layout of the Default Screen, including item width and tabbing sequence.
Typically one would name the prompt block _PROMPT, for example, ORDERS_PROMPT.
Each ’prompt’ field must have the following characteristics:
Property Class: DYNAMIC_PROMPT
Sequence: Must match the name of an item in the folder block. Sequence the first
set of fields to be displayed properly, starting at 1. This drives the
folder TAB order.
X Position: Positioned at runtime.
Y Position: .05.
Width: Dictates the width of the corresponding field. Make sure the width is adequate to display the text for the prompt fully. The width only needs to
account for English text – no translation expansion space is needed. Specifying the width as 0.1” causes it to adjust automatically based on the text it contains. For checkboxes, specify a width of 0.1”
Alignment: Usually Start, but follows alignment of data in corresponding folder
block field. Prompts for check boxes are always Center aligned.
Canvas: Stacked canvas.
Default: The text for the prompt. The translation tool translates this
automatically.
Displayed: True only for those fields you want displayed on the default screen;
otherwise, False.
Create Special Fields in Prompt Block
The following special fields must exist in the prompt block:-
Field: FOLDER_OPEN
PROPERTY CLASS: FOLDER_OPEN
X POSITION: 0.1”
Y POSITION: Y_OFFSET
CANVAS: content canvas
Field: FOLDER_TITLE
PROPERTY CLASS: DYNAMIC_TITLE
X POSITION: 0.4”
WIDTH: 4”
Y POSITION: Y_OFFSET +.05
CANVAS: content canvas
Field: FOLDER_DUMMY
PROPERTY CLASS: FOLDER_DUMMY
CANVAS: TOOLBAR
Field: ORDER_BY1,ORDER_BY2,ORDER_BY3
PROPERTY CLASS: FOLDER_ORDERBY
X POSITION: Set at runtime.
Y POSITION: For content canvas Y_OFFSET+.5+(.25*Rows)
For stack canvas .25+(.25*Rows)
CANVAS: If it’s a fixed field specify content canvas otherwise specify stack
canvas.
Step – 5 Code Form Level Trigger
The following form–level triggers must exist in order for a folder block to operate correctly:
• Trigger: WHEN–WINDOW–RESIZED:
IF :system.event_window IN (’<>’) THEN
app_folder.event(’WHEN–WINDOW–RESIZED’);
END IF;
• Trigger: KEY–CLRFRM:
app_folder.event(’KEY–CLRFRM’);
This call must be made anywhere a clear_form is issued. This cause the folder code to repaint the prompts and folder titles as if they were normal boilerplate.
• Trigger: WHEN–NEW–FORM–INSTANCE:
app_folder.define_folder_block('OBJECT NAME',
’’,
’’,
’’
’’,
[’’]);
Note: All parameters must be passed in UPPERCASE.
Example:
App_flolder.define_folder_block(‘PO_HEADER’
,’POHEADER’
,’POHEADER_PROMPT’
,’POHEADER_STK’
,POHEADER_MAIN’)
Choose the object name carefully; it must be unique across all products. Prefix it with the application short name, for example ’FND_ALERTS’. This object name identifies all folder definitions that users define and save for your folder, and it appears in the Administer Folders form as the Folder Set, so you should make the object name descriptive and readable.
’DISABLED FUNCTIONS’ can be a string combining any of the following. Specifying that a function is disabled prevents the user from performing it.
• OPEN
• TOOLS: Disables everything except OPEN. Note that if the profile FOLDERS:ALLOW_CUSTOMIZATION is ’N’, all tools are automatically disabled except Open.
• ORDERBY
• NEW
• SAVE: Disables Save and Save As.
• AUTOQUERY: Should be disabled for any detail block.
• PUBLIC
• DEFAULT
• DELETE
• SHOW
• HIDE
• MOVE
• WIDEN
• SHRINK
• AUTOSIZE
• PROMPT
• QUERY
Following example will disable ‘ORDER BY’ and ‘HIDE’ function in the folder form:
App_flolder.define_folder_block(‘PO_HEADER’
,’POHEADER’
,’POHEADER_PROMPT’
,’POHEADER_STK’
, POHEADER_MAIN’
,’ORDERBY HIDE’);
• User-named Trigger: FOLDER_ACTION
app_folder.event(:global.folder_action);
Do not insert additional code in this trigger. It is used to allow the menu and folder toolbar to communicate with the folder library that is attached to the form.
• User-named Trigger: FOLDER_RETURN_ACTION
NULL;
This trigger must exist at form–level to handle the case in which it has not been coded at block–level.
The FOLDER_RETURN_ACTION trigger supports the following events:
• SHOW_FIELD: The field in :global.folder_field has just been made visible. In updateable blocks, you may need to set some properties (such as Update Allowed, Required, etc.). Fields can become visible in Enter Query mode or normal mode. When a folder is opened, all fields currently displayed are hidden, even if they are in the new folder; thus this call is made for each field as it is redisplayed.
• ADD_FILED: Populates :global.folder_field. Called at the end of a user–initiated ’Show Field’ event that results in a field being displayed. The ’SHOW–FIELD’ callback is also triggered before this callback.
• HIDE_FIELD: Populates :global.folder_field. Called at the end of a user–initiated ’Hide Field’ event that results in a field being hidden.
• OPEN_FOLDER: Called at the end of an ’Open Folder’ event that results in a folder being loaded, but before the folder autoqueries. Populates global.folder_id.
• SET-WHERE-CLAUSE: Called during a ’Save Folder’ event, before setting the where clause that will be saved with the folder. Sets global.folder_action_allowed ’TRUE’. If the value of :global.folder_action_allowed is changed to anything but ‘TRUE’ by the FOLDER_RETURN_ACTION trigger, the WHERE clause saved with the folder is null.
• RESET-WHERE-CLAUSE: Called when the block WHERE clause is set back to the developer’s WHERE clause, because the user has selected Folder–>Reset query from the menu, or because the user has selected Folder–>New from the menu.
• SAVE-FOLDER: Called at the end of a ’Save Folder’ event, immediately before the Commit. Populates :global.folder_id.
• DELETE-FOLDER: Called during a ’Delete Folder’ event, immediately before the Commit. Populates :global.folder_id.
• CONFIRM-HIDE-FIELD: Called during a user–initiated ’Hide Field’ event, immediately after doing all other checks that the field can be cut (for example, it is not on the content or fixed canvas, it is not the only field on the stacked canvas, etc.). The variable ’global.folder_action_allowed’ is seeded with ’TRUE’. If this variable is changed to anything but ’TRUE’, the action is aborted and the user cannot hide the field. By default, if the user attempts to hide a required field, CONFIRM–HIDE-FIELD automatically prevents it, and users are allowed to hide non–required fields. You can override this behavior by changing the value of :global.folder_action_allowed to either ’TRUE’ (allow hiding) or ’FALSE’ (prevent hiding non–required fields) in the CONFIRM–HIDE–FIELD callback to the FOLDER_RETURN_ACTION trigger.
• AUTOQUERY: Called when a folder loads and automatically executes a query.
• CONFIRM-AUTOQUERY: Called when a folder that is designed to autoquery opens. ’GLOBAL.FOLDER_ACTION_ALLOWED’ is seeded with ’TRUE’. If this variable is changed to anything but ’TRUE’, the folder does not autoquery.
Example: Prevent Hiding a Field
Prevent the user from hiding the (non–required) ’PERIOD_NAME’ field:
Trigger: FOLDER_RETURN_ACTION (block–level):
IF(:global.folder_action = ’CONFIRM–HIDE–FIELD’) THEN
IF :global.folder_field = ’PERIOD_NAME’ THEN
:global.folder_action_allowed := ’FALSE’;
END IF;
END IF;
Monday, February 11, 2008
Folder Options in Custom Forms--Part1
Folder option is one of the good concepts available to reduce the Future customization in many custom Forms.Here i am putting basic functionality of
the folders and will try to put the simple steps to do them.
These thing are available in the metalink with a little search but i putting for ready reference...for technical people
Functions of the Folder
Folders provide the following functions to the user:
• Customizable display of retrieved data, including:
Columns to be displayed
Width of columns to be displayed
Sequence of columns
Prompts associated with columns
Record ordering (with some exceptions)
• Persistent storage of folder definitions
• Automatic rerun of a previously defined query
• Public and private access to persistent configurations
• Default configuration specification
In addition, system administrators can prevent users from creating or modifying folders by setting the profile option FOLDERS: ALLOW_CUSTOMIZATION to ’N’. This setting disables all folder functions (except opening a predefined folder) for individual users.
Actions in Folder Forms
Folder form allows the user to perform the following functions:
• New: Creates a new folder. The user must enter a new, unique (per entity and user) folder name. This function is not available at enter query mode.
• Open: Loads a previously defined folder. A user can select from a list of his own folders, and any public folders, for the current entity.
• Save/Save As: Saves the current folder. If it has never been saved then revert to ‘Save As’ functionality.
• Delete: Allows a user to delete any folder that they created for the current entity. If another user is referencing the folder as their default, that reference is deleted as well.
• Show Field: Opens an LOV displaying fields that can be shown and are not currently shown. Selecting a value adds the field after the current cursor position.
• Hide Field: Hides the current field. The cursor moves to the field sequenced after the field that was just hidden. By default, required fields cannot be hidden.
• Move Right: Swaps the current field with the one to its right.
• Move Left: Swaps the current field with the one to its left.
• Widen: Increases the width of the current field, up to a maximum size of 20 inches, in .2 inch increments.
• Shrink: Decreases the width of the current field, to a minimum size of 0.3 inches, in .2 inch increments.
• Auto Size: Sizes each stacked–canvas field based on a small sample of records within the block. Uses the prompt width to establish a minimum width. Lists are sized based on the elements they contain, and check boxes are sized based on the prompt only. This function is not available in ‘Enter Query’ mode.
• Show Order By: Allows the user to toggle the order by buttons on and off. When they are shown, the user can set the ordering of first three base-table items currently shown. Each column can be set to Ascending, Descending, or Exclude. The three settings are applied left–to–right when data is fetched and sorted.
• View Query: Allows the user to view the WHERE clause of the folder.
• Reset Query: Clears the current WHERE clause. Similar to New, except that the current folder name and all of its definitions are retained.
Following are the feature which developer can customize:
• Developers can disable all folder functions independently. For instance, a developer could create a folder that prevents the user from moving fields, setting the ordering, and specifying that a folder can autoquery upon being opened.
• Developers can use the folder technology to lay out a block, but not expose any folder functions to the user.
• Developers can prevent users from hiding specific fields. This allows including mandatory fields in enterable blocks (mandatory fields should always appear).
• Most of the folder form functionality customization is done in user defined trigger ‘Folder Return Action‘ which comes with folder form template.
Behavior of a Folder Block
• Instead of boilerplate text, the prompts are actually display items in a single row block. The prompts are all painted on a single line.
• The initial settings of the prompts drive the layout of the Default Screen, including item width and tabbing sequence.
• Some field properties, including widths, X–positions, and prompts are set at runtime. Any values that remain static while the form is run are the responsibility of the developer. These include visual attributes, Y–positions, etc.
• The descriptive flexfield must exist on the stacked canvas, rather than the content or fixed canvas where it is always visible, so that the user can resize, move, and label it as needed.
the folders and will try to put the simple steps to do them.
These thing are available in the metalink with a little search but i putting for ready reference...for technical people
Functions of the Folder
Folders provide the following functions to the user:
• Customizable display of retrieved data, including:
Columns to be displayed
Width of columns to be displayed
Sequence of columns
Prompts associated with columns
Record ordering (with some exceptions)
• Persistent storage of folder definitions
• Automatic rerun of a previously defined query
• Public and private access to persistent configurations
• Default configuration specification
In addition, system administrators can prevent users from creating or modifying folders by setting the profile option FOLDERS: ALLOW_CUSTOMIZATION to ’N’. This setting disables all folder functions (except opening a predefined folder) for individual users.
Actions in Folder Forms
Folder form allows the user to perform the following functions:
• New: Creates a new folder. The user must enter a new, unique (per entity and user) folder name. This function is not available at enter query mode.
• Open: Loads a previously defined folder. A user can select from a list of his own folders, and any public folders, for the current entity.
• Save/Save As: Saves the current folder. If it has never been saved then revert to ‘Save As’ functionality.
• Delete: Allows a user to delete any folder that they created for the current entity. If another user is referencing the folder as their default, that reference is deleted as well.
• Show Field: Opens an LOV displaying fields that can be shown and are not currently shown. Selecting a value adds the field after the current cursor position.
• Hide Field: Hides the current field. The cursor moves to the field sequenced after the field that was just hidden. By default, required fields cannot be hidden.
• Move Right: Swaps the current field with the one to its right.
• Move Left: Swaps the current field with the one to its left.
• Widen: Increases the width of the current field, up to a maximum size of 20 inches, in .2 inch increments.
• Shrink: Decreases the width of the current field, to a minimum size of 0.3 inches, in .2 inch increments.
• Auto Size: Sizes each stacked–canvas field based on a small sample of records within the block. Uses the prompt width to establish a minimum width. Lists are sized based on the elements they contain, and check boxes are sized based on the prompt only. This function is not available in ‘Enter Query’ mode.
• Show Order By: Allows the user to toggle the order by buttons on and off. When they are shown, the user can set the ordering of first three base-table items currently shown. Each column can be set to Ascending, Descending, or Exclude. The three settings are applied left–to–right when data is fetched and sorted.
• View Query: Allows the user to view the WHERE clause of the folder.
• Reset Query: Clears the current WHERE clause. Similar to New, except that the current folder name and all of its definitions are retained.
Following are the feature which developer can customize:
• Developers can disable all folder functions independently. For instance, a developer could create a folder that prevents the user from moving fields, setting the ordering, and specifying that a folder can autoquery upon being opened.
• Developers can use the folder technology to lay out a block, but not expose any folder functions to the user.
• Developers can prevent users from hiding specific fields. This allows including mandatory fields in enterable blocks (mandatory fields should always appear).
• Most of the folder form functionality customization is done in user defined trigger ‘Folder Return Action‘ which comes with folder form template.
Behavior of a Folder Block
• Instead of boilerplate text, the prompts are actually display items in a single row block. The prompts are all painted on a single line.
• The initial settings of the prompts drive the layout of the Default Screen, including item width and tabbing sequence.
• Some field properties, including widths, X–positions, and prompts are set at runtime. Any values that remain static while the form is run are the responsibility of the developer. These include visual attributes, Y–positions, etc.
• The descriptive flexfield must exist on the stacked canvas, rather than the content or fixed canvas where it is always visible, so that the user can resize, move, and label it as needed.
Subscribe to:
Posts (Atom)
