Postback Payload Size Optimization

Nowadays application performance has become one of the critical aspects of application delivery agreement and when it comes to ADF we have to think/work little extra than other application based on the different frameworks.

Recently working on an application performance optimization improvement task I came across property called oracle.adf.view.rich.POSTBACK_PAYLOAD_TYPE. This property helps to optimize postback payload size.

By default, ADF partial request is executing HTTP post with values from all fields including, which means when you submit a form it initiates action including all fields from the form and which gets worse when we have a large form with many fields.

When postback property is set to dirty, it will include only changed values into HTTP post action. As result - the server will get only changed attributes, which leads to less server processing time and make an HTTP request size smaller.

Postback optimization property can be set in web.xml. By default it's value is full, change it to dirty:

Small small improvements will definitely lead application to better performing application.

Get Changed Rows for Entity Based View Object in ADF

While application development we usually come across a common situation where we need a changed/updated row or added row. I have seen usually developer tends to achieve such a requirement by iterating view object and we never think about application turn around time or kind of complexity we introduced to an application and which will definitely lead to low application performance.

How to get all updated/added rows in the transaction, without iterating through entire VO? It turns out to be pretty simple with ADF BC API method - getAllEntityInstancesIterator, which is invoked for Entity Definition attached to current VO.

This method even keep track of changes made in VO's Range Pagination mode, which means suppose we have a VO with access mode as a range pagination and we drag/drop as an updatable table on a page and if we make some changes on the rows belonging first range size ( e.g. 1-10 ) and some rows belonging to middle range size ( e.g. 40-50) then if we want all changes made during a current transaction this method provides an effective solution without iterating through complete VO.

In my experiment, I changed a couple of rows on the first page:

 And a couple of rows in the 5th page. Also, I removed the row and created one:

 The method returns information about all changed rows, as well as deleted and new:

Example of getAllEntityInstancesIterator method usage in VO Impl class. This method helps to get all changed rows in the current transaction, very handy: