Adding JUnits Test cases for the ADF Model project

Unit test cases are always important to any application built on any technology.

For ADF applications model layer, JUnit is one unit testing framework which helps the developers test the model layer before moving the code to QA team or moving to any different environment.

This is simple to develop and use.

Here, I will provide some simple steps to configure JUnits. (In this sample I am working with ADF BC)

Here, I have an AM method which takes DepartmentId as the input and filters the Employees table based on the department id passes. It will return true if an employee exist in the given department, else it will return false.

Below is the code snippet for the method.

So, how does JUnit help us in testing this method?

JUnit

1. Create a new JAVA project in your application.

2. In the project, create a new Business Components Test Suite.

3. Select the Model.jpr you wish to create test cases for and click OK.

4. It creates several classes as shown below for every EO,VO, AM .. etc just like below.

5. Now open the AppModuleAMFixture.java, Check the AM configuration used.

   _am = Configuration.createRootApplicationModule("model.AppModule","AppModuleLocal");

6. Make sure that the AM configuration points to a DB connection and not weblogic datasource.

7. Now, open AppModuleAMTest.java and initialize the variables like below.

    AppModuleAMFixture fixture1 = AppModuleAMFixture.getInstance();

    AppModuleImpl _amImpl = (AppModuleImpl)fixture1.getApplicationModule();

8. This is the file where we would be writing the testcases for AM methods. We can also see setup() method and teardown() methods which gets executed before every test case and after every test case respectively. We can use these methods for setting up the environment or any pre-requisites to test the method.

9. Now, we are all set and we can test our method. I have written test cases for the method like below.

10. We can test the method by passing null, empty, valid and invalid values to the department id and test the method. You can think of several other testcases and put it down here. This will be a one-time development effort and can be used to test it several times.

11. Now, lets check the results. Right click and run the file.

12. We can see the method failed in some scenarios, It gives warning when passed an invalid value because we have used an assert Statement if Employee is not found case. 

13. Now, lets go and handle the failed cases in our method.

14. Now, lets run the JUnit script again.

15. Perfect, our test cases are passed. And this method is stable.

16. So, in this way if we think in a broader scope we can easily catch regression issues in the development time itself and we need not wait till some points a finger at us.

Hope everyone makes use of this kind of test cases for their ADF model projects and minimize the number of bugs and regression issue. Thanks :)

Appending programmatic Where Clause to VO Query instead of QRSLT

It is usual in ADF to use vo.setWhereClause() programmatically and refresh the table data in the UI.

But, if you have observed the query which gets executed, it would be like below.

SELECT * FROM (SELECT Employees.EMPLOYEE_ID,
       Employees.FIRST_NAME,
       Employees.LAST_NAME,
       Employees.EMAIL,
       Employees.PHONE_NUMBER,
       Employees.HIRE_DATE,
       Employees.JOB_ID,
       Employees.SALARY,
       Employees.COMMISSION_PCT,
       Employees.MANAGER_ID,
       Employees.DEPARTMENT_ID
FROM EMPLOYEES Employees) QRSLT  WHERE (DEPARTMENT_ID = 10)

The where clause is set by using the below code (it is straight forward)

You can clearly see the Where Clause is appended to the QRSLT and not to the actual query.

If you see it in a larger scope, it causes performance issues with tables having large data or on complex queries because inner query gets executed first and then filter is applied.

And one more point to note is, the column you add in the where clause SHOULD BE there in the select clause.

So, how to overcome this? How to append the Where clause to the query itself?

Solution:

You need to generate the VOImpl class for the ViewObject and override the create() method and put setNestedSelectForFullSql(false); as below

After this, you again run the page and test it. Now, the Where Clause gets appended to the VO query itself instead of the QRSLT just like below

SELECT Employees.EMPLOYEE_ID,

       Employees.FIRST_NAME,

       Employees.LAST_NAME,

       Employees.EMAIL,

       Employees.PHONE_NUMBER,

       Employees.HIRE_DATE,

       Employees.JOB_ID,

       Employees.SALARY,

       Employees.COMMISSION_PCT,

       Employees.MANAGER_ID,

       Employees.DEPARTMENT_ID

FROM EMPLOYEES Employees WHERE (DEPARTMENT_ID = 10).

Hope it is clear and useful :)

Restricting the VO query execution on page load.

In ADF, all the iterators are executed on page load by default.

So, if we have more than 2-3 tables in the page, the initial rendering of the page takes time and causes performance issues.

In this blog, I will explain a way to restrict the iterator's execution on the page load.

Go to your page bindings, select the iterator and set the Refresh property to "ifNeeded" and RefreshCondition to "#{!adfFacesContext.postback}" as below.

 This way, we can clear performance issue on page load and execute the iterator only when required.

Solution to "Select All checkbox in column header not working."

It is a very common requirement or usecase to have a Boolean Checkbox in the column header of an af:table and checking that would select all rows and unchecking that would deselect all rows. (all the rows in the table will be having a checkbox column)

So, recently I was also having the same requirement and tried to implement it as it is a pretty straight forward task. (have the autosubmit of the column header checkbox to true and on value change, iterate through the records, set the boolean variable to true and refresh the table.)

Then I run the page and see the funny thing, the value change doesn't work for the first time. From second time onwards it starts working.

Solution:

After the end of iteration and partial trigger, try to reset the table's state like below.

     yourtTableBinding.resetStampState();

What this does is, it refreshes the data with the updated model and clears the submitted value.

Hope this helps. :)

Writing ADF Loggers to a specific file.

Its been a while since I blogged last.

Here, in this post I am going to explain about adding loggers in ADF.

It is good to have loggers implemented for any ADF application. It makes life easier for the developers and the support team to  debug any errors once the code is moved to DEV, QA or PROD instances.

Generally, developers use ADF loggers. But, by default the ADF logger statements will be written to the default server log. As we know the server log has lots of other things also, it is difficult to separately analyze the logger statements.

So, most of them who have a requirement to write loggers to a specific file use log4j.

In this blog I am going to explain you a way to write ADF loggers to a specific file.

1. Create a log handler in the logging.xml file.

To configure log handler, open the logging.xml file. The logging.xml file will be present in the below location.

        yourDefaultDomain\config\fmwconfig\servers\DefaultServer\logging.xml

You have to add the log handler like below.

<log_handlers>

...

  <log_handler name='applicationHandler' class='oracle.core.ojdl.logging.ODLHandlerFactory' filter='oracle.dfw.incident.IncidentDetectionLogFilter'>

   <property name='path' value='${domain.home}/servers/${weblogic.Name}/logs/yourApplication.log'/>

   <property name='maxFileSize' value='14979657'/>

   <property name='maxLogSize' value='104857600'/>

   <property name='rotationFrequency' value='daily'/>

   <property name='retentionPeriod' value='week'/>

   <property name='encoding' value='UTF-8'/>

   <property name='useThreadName' value='true'/>

   <property name='useSourceClassAndMethod' value='ERROR'/>

  </log_handler>

...

</log_handlers>

2. Create a logger in the same file.

<loggers>

...

  <logger name='applicationLog' level='FINEST' useParentHandlers='false'>

   <handler name='applicationHandler'/>

  </logger>

...

</loggers>

3. In your application you have to define the logger like below. The name should be same as the logger name given in the logging.xml file.

      ADFLogger logger = ADFLogger.createADFLogger("applicationLog");

4. After this, add log statements in your code where necessary. Usually at the start of the method, end of the method in try, catch blocks ... etc.

While you write log statements it is better to check logger level like below.

        if (logger.isFine())
            logger.info("Start of init() method.");

Say, after you move the code to production and you don't want to print the loggers, then you can change the server level to WARNING. So, FINE messages will not appear.

5. So, you can check your ADF logger file in the location

       yourDefaultDomain\servers\DefaultServer\logs\yourApplication.log

Hope this post helps you all in configuring ADF loggers.