Skip navigation.

Andrejus Baranovski

Syndicate content
Blog about Oracle technology
Updated: 7 hours 16 min ago

Tab Navigation Performance in UI Shell and Multi Task Flow

Tue, 2014-05-27 13:36
I was investigating performance impact of navigating between tabs in UI Shell template. To compare, as alternative solution for UI Shell, I was using dynamic tabs with Multi Task Flow binding (Building Custom UI Shell with ADF 11g R2). When you switch between tabs in UI Shell, you could notice slight delay. This is normal delay (differently to browser tabs, where no delay), as there should be generated response from the server and JSF tree must be updated. However, it is not clear what is the impact of such delay to application performance. The goal of my post is to answer this question.

Sample application - MultiTaskFlowApp_v2.zip, contains two UI projects. One implements UI Shell and second Multi Task Flow binding based page for dynamic tabs:


Multi Task Flow binding is a new feature since ADF 11g R2, list of task flows can be referenced from the Page Definition:


This list can be rendered on UI with dynamic tabs, each tab would be physically created (in UI Shell case, only one region is rendered at a time):


Second project is using UI Shell template:


UI Shell doesn't render real tabs, instead it is using navigation pane component with links, displayed as a tabs:


Only one region is rendered at a time, the one you select. This means, when tab is changed - different region will need to be rendered again:


I was navigating through tab items for both solutions and recording tab opening time. Here are the results.

Multi Task Flow Binding: 

- Departments: 0.29 sec.



- Employees: 0.47 sec.


- Locations: 0.59 sec.


Average: 0.45 sec.

UI Shell:

- Employees: 0.61 sec.


- Locations: 0.55 sec.


- Departments: 0.28 sec.


Average: 0.48 sec.

You can see, both are almost the same. There is 0.5 second delay to open tab for a relatively simple UI with a form and editable table components. In the real scenario, with more complex UI, delay could grow to couple of seconds.

One second or couple of seconds delay is generally acceptable in UI Shell, for navigation between tabs. If delay is longer than that, something must be wrong in your application - slow data fetch or slow table initialisation, could be one of the reasons.

Personalising ADF Query with MDS User Persistence

Mon, 2014-05-19 22:24
I bet you are familiar with ADF Query UI having many criteria items. This may look irritating to the users, as there are so many options to use for the search. I will describe alternative approach in this post, with MDS user persistence and personalisation involved. It might be more user friendly, to offer only few criteria items by default and allow to add other items through ADF Query advanced option, together with MDS user persistence feature enabled for personalisation. Post is based on sample application from - ADF Query Saved Search in ADF 12c.

Here is updated sample application, for today post - SavedSearchApp_v2.zip. As you can see, there is minimal criteria set is available by default:


User could add additional criteria items he needs, like Email and save modified criteria for the future use:


Logout/login and personalised criteria for this user will remain available - quite cool. User could work only with criteria items he finds useful, this would make screen lighter also:


I hope such quick insight about ADF Query personalisation and criteria items optimisation will be useful for your project.

Implementing Dynamic Date Type Formatting with ADF BC

Wed, 2014-05-14 22:06
You may have a requirement to apply different format for date type attributes, based on username, as for example. Different users, may use different date formats - in such case, formatting for date type attributes must be set dynamically. This can be achieved, using approach described in my previous post - Controlling ADF BC Mandatory Attribute Validation Conditionally. I would extend explained technique and apply it for date formatting.

Sample application for download - DynamicFormatADFApp.zip. Here you can see two different browser sessions, two different users and different date formats applied in both cases. dd/MM/yyyy is applied for redsam1 and yyyy/MM/dd for redsam2:


ADF UI is standard for a inputDate component in a form - format is set through a standard EL expression in convertDateTime tag by referencing format property from AttributeDef object:


EL expression to get a format for the attribute, rendered in ADF table is changed slightly (otherwise, with default EL expression, overridden getFormat method is not invoked):


Generic View Row Implementation class must override createViewRowAttrHints and getAttributeHints methods - this would allow pass a custom format to be applied on ADF UI dynamically:


Finally CustomViewRowAttrHintsImpl class overrides framework method getFormat (this method is invoked from ADF UI EL for format property automatically). Here we could check for a username and return dynamic format (in real use case, this logic can be more complex):

Comparing ADF View Object and Row Fetch Execution Times

Sun, 2014-05-11 02:40
I bet one of the most common doubts ADF developer, or may be DB admin, has - why VO SQL executes slower than the one identical from SQL Plus? This is often the case, but there is nothing VO SQL to blame about. Usually VO SQL executes in almost same time, as it would execute in SQL Plus - but there is extra added time of row fetch. When ADF UI page is rendering, data becomes available after VO is executed and rows are fetched from result. These two separate technical actions, look like one for ADF UI user - data will not be displayed, until it is not fetched. So, there is extra time for row fetch on top of VO SQL query execution. This is why - displaying data in ADF UI, could be slower than displaying it in SQL Plus.

You should tune number of rows fetched by VO's, the worst practice is to set Range Size = -1 and fetch all rows at once. This is going to consume significant amount of memory to create many ViewRowImpl objects and waste time. Make sure to fetch only such amount of rows, close to be required for display on UI or any back-end operation.

I'm going to show you with a practical test - how time differs between VO SQL execution and row fetch for simple Employees table with 107 rows fetched as total. Here you can download sample test case application - ADFFetchApp.zip.

There is one iterator in Page Definition, for Employees VO:


I have set this iterator with Range Size = -1, to fetch all rows. I have seen the use cases, while reviewing and tuning ADF applications, where developers are using Range Size = -1 without actually understanding what a side effect for runtime performance it could create. Afterwards, it is common to blame ADF for a mystery, well hard to blame. Anyway, here is my test case Range Size = -1 setting for Employees iterator:


Sample application comes with a generic VO implementation class. There are two methods overridden here - executeQueryForCollection and createRowFromResultSet. In the first method, I'm tracking how long it takes to execute SQL for given VO. Second method tracks total time to fetch all available rows from Employees table (remember Range Size = 1 from above):


Fetch time is initialised, before constructing first ViewRowImpl object and stopped with the last row.

Just run sample application, after test page with Employees rows will be rendered you could check execution times and compare them:


In average it runs as following: 15 milliseconds for VO SQL query execution vs. 94 milliseconds for total row fetch:


As you can see, time added by row fetch operation could be quite significant and it makes sense to tune and ensure optimal row fetch in your application. SQL query is not only one thing to blame, when VO performance is slow, it could be you are fetching too many rows.