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.
@Override
protected void prepareForDML(int operation, TransactionEvent e) {
super.prepareForDML(operation, e);
if (operation == EntityImpl.DML_INSERT) {
createDummyEmployees();
}
}
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.
