JDeveloper and the art of the rollback

It's tempting for beginner ADF programmers to map the Cancel button to the Rollback operation on an edit page within an ADF BC/Faces application, to lose the current changes the user has made within the edit page. However issuing a rollback in a JDeveloper application using ADF BC can have a gotcha for beginner programmers, or those coming from a traditional Forms background.

A side-effect of issuing a rollback is that any open iterators have their current row pointer reset to the first record in the record set. This presents a confusing situation to the user on navigating back to (for example) a page showing a read-only table with a record selector, as the table will be "magically" reset to the first record in the table, which could in fact be a different row set in the table.

The following describes the steps in implementing a method for overriding the side-effects of the rollback, and an alternative method from calling the Rollback at all. Which you use is your choice based around the functionality you require.

Restore current row after rollback

The first method is based on Steve Muench's undocumented example Restore Current Row After Rollback #68. This method changes the manner in which the ADF BC framework handles rollbacks for specified View Objects. It can be applied to all View Objects or a selective set as implemented by the programmer.

The changes for this solution lie in both your ADF BC Model project and your ADF Faces ViewController project. Follow these steps to implement:

ADF BC Model Project

1) Create a new class in your model layer called CustomViewObjectImpl similar to the recommendations in the Advanced Business Components Techniques section of the ADF Guide for Forms/4GL Programmers. Copy the same Java class code from Steve Muench's example into this new class, specifically the beforeRollback and afterRollback methods. Change the package declaration to where ever you've placed the new class.

2) In your existing ApplicationModuleImpl, add this routine:

protected void prepareSession(Session session) {
super.prepareSession(session);
getDBTransaction().setClearCacheOnRollback(false);
}

3) For all View Objects where you want to avoid the rollback side effect, you need to extend their ViewObjectImpl custom classes as follows:

public class myViewObjectImpl extends CustomViewObjectImpl

....and import the CustomViewObjectImpl.

4) In addition in each custom ViewObjectImpl class, and the following routine:

protected void create() {
super.create();
setManageRowsByKey(true);
}

ADF Faces ViewController Project

5) In *each* web page where you have a rollback button, instead of calling the Rollback actionBinding defined within the pageDef, we want the button to call the following code:

public void executeRollbackActionAfterDisablingExecuteOnRollback() {
FacesContext fc = FacesContext.getCurrentInstance();
ValueBinding vb = fc.getApplication().createValueBinding("#{bindings}");
DCBindingContainer bindings = (DCBindingContainer)vb.getValue(fc);
if (bindings != null) {
bindings.setExecuteOnRollback(false);
OperationBinding ob = bindings.getOperationBinding("Rollback");
if (ob != null) {
ob.execute();
} else {
throw new RuntimeException("Binding container has no 'Rollback' action binding");
}
}
}

Note that this solution still requires the pageDef for each page with the rollback button includes the "Rollback" binding. If you deleted the rollback button from the JSF page, JDeveloper will have automatically deleted the pageDef Rollback binding, so you will need to recreate it if need be.

6) Rather than duplicating the above code in each backing bean, it would better be placed and defined once in a utility class. In Steve's example he creates a class RollbackHelperBase, wrapping the above code in the following method spec:

public void executeRollbackActionAfterDisablingExecuteOnRollback() { ... }

7) The button then makes a call to its associated backing bean method onRollback on as follows:

<af:commandButton text="Rollback" immediate="true" action="#{TestPage.onRollback}">

8) The backing bean should extend the RollbackHelperBase:

public class myBackingBean extends RollbackHelperBase { .... }

9) and the onRollback method makes a call to the parent's method executeRollbackActionAfterDisablingExecuteOnRollback as follows:

public String onRollback() {
executeRollbackActionAfterDisablingExecuteOnRollback();
return "navigateToWhereEver";
}

Now when you run your webpage and test the rollback button, for any web page iterator that has been extended with the custom View Object class, the iterator row currency will not be reset.

Steve's solution has the advantage that it a generic enough that it can be applied across all ViewObjects and their associated iterators. The disadvantage of this approach is it requires more code, and to be effective across your app you need to extend each ADF BC ViewObjectImpl to the custom CustomViewObjectImpl class, as well as each rollback button with ADF Faces calling the executeRollbackActionAfterDisablingExecuteOnRollback functionality. The code changes however can be minimised through the use of a customer ADF BC framework.

Drop the current row changes

An alternative approach to Steve's solution is to not change the rollback functionality, but instead just lose the changes to the current row the user is editing. This can be done on the JSF side by retrieving the current row from the iterator, and instructing the row to drop any changes since the beginning of the transaction, including dropping any new rows.

To implement this solution, follow these steps:

1) In your edit page, create a new commandButton whose action attribute makes a call to the following backing bean code:

public String dropChangesAndReturn() {
FacesContext fc = FacesContext.getCurrentInstance();
ValueBinding vb = fc.getApplication().createValueBinding("#{bindings}");
DCBindingContainer bc = (DCBindingContainer)vb.getValue(fc);

DCIteratorBinding iterator = bc.findIteratorBinding("EmployeesView1Iterator");
ViewObject vo = iterator.getViewObject();
Row row = vo.getCurrentRow();

if (row != null) {
row.refresh(row.REFRESH_UNDO_CHANGES | row.REFRESH_FORGET_NEW_ROWS);
iterator.getDataControl().commitTransaction();
}
return "SomeNavigationRule";
}

2) For the commandButton, set it's immediate attribute to true.

That's it. A smaller solution but dependent on you knowing the iterator name, and adding to all edit pages where you want to drop the row.

Thanks and final comments

Thanks to Steve Muench for giving permission to document his undocumented example # 68, and if I remember correctly to Frank Nimphius and Didier Laurent for their original assistance on the second solution on OTN and via Support way back in 2004 when I was a wee JDeveloper schnapper.

As there is a large amount of text above I've surely made an error at some point. If you find an error please include a comment and any fix and I'll append the above post to the benefit of other readers - thanks!