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(“XXWPHomeWorkPlanAM”);