OA
Framework Best Practices
·
AM
Retention : Retaining the AM where not
required, Not retaining it wherever required – both are
dangerous!!
The AM should be retained whenever you are navigating
away from a page and when you know that there is a possibility to come back to
the page again and data is to be retained. Example : Any navigation link
that opens in a new page or any navigation which has a back button to come back
to the initial page.
The AM should not be retained for two independent
pages, especially if they have common VOs which fetch different result sets. In
such cases, retaining the AM may not remove the cache of VOs and so the result
may not be as expected.
·
Setting
dynamic whereClause : Avoid setting where
clauses dynamically as far as possible. And when required, set the where clause
and where clause params to null before setting your new where clause. Remember
that the where clause once set will be retained through out. So it’s a best
practice to make it null wherever it is not required. Creating two VOs is
always better than using a single VO with two dynamic where clauses.
·
Fetch
Profile Value : Fetching the values like
profile , orgId, testFunction etc can be done in two ways.
1. Fetching
it from pageContext.
Syntax : pageContext.getProfile(‘XXWHO_ENTITY’);
2. Write
a VO to query the values directly from the data base.
Syntax: SELECT
FND_PROFILE.VALUE(‘XXWHO_ENTITY’) FROM DUAL
The first option brings the data from the cache, so it takes time for the
changed values to be reflected in front-end. But the second option is costly
performance wise. So its better to invalidate cache regularly and use the first
option to fetch such kind of values.
·
Whenever you are executing a VO
or creating rows in a VO in the process request, do it conditionally. Let it
not get executed every time the process request is
called.
Ex: if(fromPage
== “CorrectPage”) {
vo.executeQuery();
}
This avoids duplicate data or data loss whenever your
page is rendered from a dialog page or back button etc.
·
If you want any values of your
CO to be available in your EO, put those values in transaction. Do this only if
it is very much required. Should not create unnecessary transactions anywhere.
Only get the already existing transaction object from AM using getTransaction()
Method.
·
Make it a point to remove all
the session parameters and transaction parameters soon after their utilization.
Should be very careful with session parameters because they result in
unnecessary data and it’s often difficult to debug.
·
Passing too many parameters
through hashmap not only effects the performance but it also effects the UI
·
Avoid writing huge code in CO.
No business logic should be written in the CO or AM. Try creating private
methods in controller wherever you have redundant code.
·
Create separate interface per
module for declaring all your constant variables rather than hardcoding the
values in the code.
Ex : You want to use a lookup name n number of times
in your coding. Instead of hardcoding it everywhere, declare it in your
constants interface and use the constant in your code. Tomorrow, If you have to
change the lookup, you can change it at a single place (in the constants
interface) and save time.
·
Whenever you have to get or set
values of a VO use get/set<Attribute_name> method instead of
getAttribute(index) method. Because the getAttribute(index) traverses through
the entire attributeset in order to find the required attribute which is a
performance issue
Ex: Say, you have an attribute called SelectFlag with
attribute index as n . To get the value, use getSelectFlag instead of
getAttribute(n).
·
HGrid
cache: Hgrid is one of the components in OAF
which gives major surprises to the developer everytime. Should be very careful
while creating the viewlink. Remember to clear the cache of the hgrid each time
the hgrid is rendered or the hgrid query is executed.
Syntax : hgridBean.clearCache();
To expand the hgrid upto nth level by default (i.e to
expand the tree structure upto nth child), use the following syntax :
hgridBean.setAutoExpansionMaxLevels(n);
·
Better to
call sequences from the create method of EO rather than calling them from
custom methods in AM. Infact, set all the default values or who columns for
attributes here only.
·
Always reset a VO before
iterating it. Especially when getting the values of a radio button selection
etc.
Ex :
vo.reset();
while(vo.hasNext()){
// get handle of the vo’s current row and perform ur operations;
// break the loop after reaching the last record of the current rowset.
}
·
Set any VO’s where clause and
where clause params in VOImpl class rather than creating directly in CO. This
increases reusability and modularity. But you don’t have to set any where
clause or where clause params and should directly execute the query, then need
not use VOImpl for calling the executeQuery() method.
·
Exception
Handling : Proper exception handling is a
must. Put your code in proper try –catch blocks wherever possible.
If your code ,which is in try-catch block, have to throw
OAException anywhere, that will be caught and will not be shown to the user.
Hence use the following statement in the catch block to throw the OAExceptions
to the user :
try{throw new OAException(“APP_CODE”, “ERROR_MSG”);
}catch(Exception _exception) {
throw OAException.wrapperException(_exception);
}
Use the following syntax for logging your exception in the log
file
if(pageContext.isLoggingEnabled(4)) {pageContext.writeDiagnostics(getClass().getName()+”.processFormRequest”, “Exception Details : “, 4);
}
Do not catch your exceptions wherever they occurred (ex in AM).
The exception must always be thrown back to the calling method . So all the
exceptions must be finally caught in the CO.
Calling AM methods in CO :
Those of you who have used invokeMethod() in CO to call the AM methods might
have observed that it’s the most tedious way of calling methods, especially
when you have to send serialized parameters. Importing the AMImpl class in your
controller allows you to access the AM methods directly without the use of
invokeMethod() but it breaks the basic OAF standards coz u r accessing a class
in the server package from a class in the webui package. To overcome the above,
the best practice is to create an Interface of the AMImpl (which neither
belongs to server nor webui) and use this AM Interface in your CO rather than
AMImpl class. To create an interface in Jdeveloper, double click on the AM ,
select ‘client methods’ and shuttle the required methods to right side. It
automatically creates an interface for you with the selected methods.
Example for getting the object of the interface :
XXWPHomeWorkPlanAM
workPlanHomeAM = (XXWPHomeWorkPlanAM)pageContext.getApplicationModule(webBean).findApplicationModule(“XXWPHomeWorkPlanA
No comments:
Post a Comment