Skip to main content

Updating supporting business data before committing the transaction

In some specific business scenarios you may need to manipulate(create/modify/delete) related business records before committing the parent record(EntityObject). For example, inserting entries in to an audit table whenever some business data changes. Here the audit table its not updated by a user, instead the table is populated based on the updated data from the transaction tables. This post discusses a recommended pattern for such scenarios where you may need to create/modify child/supporting entities whenever the parent entity changes.

Where do I keep the extra 'code' to deal with related entities?

Here you are looking for a place to hook your logic for creating/modifying supporting entities whenever the parent entity gets modified. The right place to keep this 'extra' logic is your parent EntityObject's prepareForDML(int operation, TransactionEvent e) method. With this approach, the newly created EntityObject(s) would get a chance to participate in the 'entity validation and post' cycle. ADF BC run time would take care the rest :)

You can download the sample workspace from here.
[Runs with Oracle JDeveloper 11g R1 PS2 + HR Schema]

A glance at the implementation

This example would let you to create Department records. For each newly created department record, system would generate a dummy employee record. This is done be overriding DepartmentsEntityImpl::prepareForDML(int operation, TransactionEvent e) as shown in the following code snippet.
protected void prepareForDML(int operation, TransactionEvent e) {
super.prepareForDML(operation, e);
  if (operation == EntityImpl.DML_INSERT) {

How to run this sample?

Run the main.jspx. This page displays Departments-Employees hierarchy. You can create new Department by clicking the 'Create Dept' button. When you commit the data by pressing 'Commit' button, behind the scene, system would create a dummy employee record for each new Department.


Anonymous said…
Hi Jobinesh,

Is there any method in AM which could be use for same purpose as well. (BeforeCommit throws JBO-28202: Invalid entity instances found in the transaction in the beforeCommit phase.)

We tried beforeValidate as well but noticed that it seems to get invoked on any form submit not just during commit/save.
Jobinesh said…
Nothing I'm aware of. What is the use case?
Anonymous said…
We have a taskflow based on EOs/VOs owned by some other team but on save time, we need some additional business logic run when rows are added/deleted etc. Only thing we own is AM, so trying to find a method at AM level.
Hi Jobinesh,

I'm following the similar approach as you have suggested. But I'm hit upon the following issue.

Please let me know how this can be solved.


Naveen Darisi
Naveen Darisi said…
Hi Jobinesh,

Can you please look into this issue if you get chance.


Naveen Darisi

Popular posts from this blog

How to set Bind Variable Values at runtime ?

In this post I'm sharing a couple of approaches for programmatically setting bind variables values at run time. This post is an attempt to explain 'When to use what ?'[ In case if you are familiar with 'Bind Variables' in ADF BC, please refer Section 5.10, Working with Bind Variables in Fusion Developer's Guide ]

1. Set the Bind Variable value using RowSet::setNamedWhereClauseParam(...)

You can use use the setNamedWhereClauseParam(...) method on the ViewObject interface (which extends oracle.jbo.RowSet) to set the value for bind variables. Please note this sets the value on default RowSet. In other words, this doesn't have any effect on the secondary RowSets that you/system generates.
ViewObject vo = am.findViewObject("EmployeesView1"); vo.setNamedWhereClauseParam("bindVarDeptId", new Number(10)); vo.executeQuery();
2. Set the Bind Variable value using ViewObject's VariableValueManager::setVariableValue(...)

VariableValueManager Ma…