Customize ADF Entity Object

Like most business components, individual entity objects are partially defined by XML files. These files specify:

1. Simple metadata about the datasource, such as the table name and attribute definitions and

2. Simple business logic, such as the business logic that represents most column constraints and simple validation and security logic.

In addition to XML files, entity object definitions comprise up to three Java classes:

a) The entity object class - an instance of this class (an entity object instance) represents a single row from the datasource (oracle.jbo.server.EntityImpl)

b) The entity collection class - an instance of this class represents the collection of rows currently in memory for a single user(oracle.jbo.server.EntityCache)

c) The entity definition class - the singleton instance of this class represents the entire datasource object(oracle.jbo.server.EntityDefImpl)

To access an entity row, you use a related object called the entity definition. At runtime, each entity object has a corresponding entity definition object that describes the structure of the entity and manages the instances of the entity object it describes.

If an XML file satisfies your needs for a particular entity object, you may not need to extend any classes or write any Java code.
If you have any requirement to override any framework method, follow below steps.

1. Create your SomeEntityImpl.java Class which extends EntityImpl.java.
2. Open SomeEntityImpl.java file and go to source which is available between Run and Versioning option. And click on Override Methods option.



You can see the methods from framework which you can override in your SomeEntityImpl.java file.

oracle.jbo.server.EntityImpl

This class implements the middle-tier representations of database rows. An Entity Object provides an object-oriented representation of the data it caches from a database object, such as a table or view.
Some methods from Framework are listed below.

getEntityState() method

Determine the state of the entity instance, irrespective of whether it has already been posted in the current transaction (but not yet committed)
public byte getEntityState()
Gets this Entity Object's current Entity-state in the transaction. The possible Entity-states that can be returned are:

1. STATUS_UNMODIFIED - if this Entity Object originated in the database and is unmodified, or if modifications have been committed to the database.
2. STATUS_MODIFIED - if this Entity Object originated in the database, and has been modified in the current transaction.
3. STATUS_NEW - if this Entity Object is new in the current transaction.
4. STATUS_DELETED - if this Entity Object has been deleted in the current transaction.
5. STATUS_DEAD - if this Entity Object is new in the current transaction and has been deleted.


handlePostChangesError()

protected void handlePostChangesError()
Called when a problem occurs while posting changes and restores an EntityImpl's state.

For example, when a user performs an operation (such as a commit) that posts changes, the framework will go through each EntityImpl instance that was modified during this transaction and call postChanges() to post the changes to database. If something goes wrong during this process and an exception is caught, then the framework notifies those EntityImpls by calling handlePostChangesError. The default implementation of handlePostChangesError essentially restores the EntityImpl's state.

In a composition post cycle, when the posting of one of the detail Entities throws an exception, the framework calls this method on the master Entity which internally calls this method on all of the composite Entities
A user can create a custom EntityImpl (by extending EntityImpl), and handle such an error differently from the default implementation by overriding handlePostChangesError and adding custom error-handling logic.
If this method is overridden, then the default implementation must be called with super.handlePostChangesError() to restore the Entity post states, as well as notify posted "child" Entities to handle post changes errors.


doDML

protected void doDML(int operation,TransactionEvent e)

Performs INSERT/UPDATE/DELETE processing for the row. Override this method to provide custom logic for processing inserts, updates, and deletes. Note, do not set any of this Entity's attributes in this method if this entity needs to work alike in both batch and non-batch-mode cases. Perform all setAttributes that needs to done in postChanges() phase in prepareForDML().

This method calls buildDMLStatement() to build the DML string based on the DML operation to be performed. For insert and update, the DML statement will only set the values that have been modified/changed. Other attributes do not participate in the DML.

Next, bindDMLStatement() is called to bind the DML statement with values to be updated and any other where-clause and returning parameters. After this, it executes the jdbc-statement or adds the current DML as a batch operation into a batched jdbc-statement, to be executed in Transaction.postChanges().

Here is sample code for overriding the doDML() method of any Entity Object's EntityImpl class to invoke a stored procedure, and pass arguments. For example, given a PL/SQL stored procedure like:

PROCEDURE updateDepartment( p_Deptno NUMBER,p_Dname VARCHAR2,p_Loc VARCHAR2 )

The code to call it when an Entity is updated would look like this: Note: The following code assumes only updates are possible, disallowing inserts and deletes by ignoring them in thedoDML() method.

public void doDML(int operation, TransactionEvent e) {
// Don't call the superclass. This procedure handles only updates
//super.doDML(operation, e);
CallableStatement stmt = null;
// ONLY Perform updates, this Entity won't allow inserts/deletes.
if (operation == DML_UPDATE)
{// Prepare JDBC CallableStatement with the Stored Procedure Call
String updateStr = "{call updateDepartment(?,?,?)}";
stmt = getDBTransaction().createCallableStatement(updateStr, 1);
try{
// Bind the Statement Parameters and Execute this Statement
stmt.setString(1, getDeptno().toString());
stmt.setString(2, getDname().toString());
stmt.setString(3, getLoc().toString());
stmt.execute();
}catch (Exception ex){
throw new oracle.jbo.JboException(ex);

}finally{
try{
stmt.close();
}catch (Exception nex)
{

}
}
}
}

Parameters:
operation - the integer representation of DML_INSERT, DML_UPDATE, or DML_DELETE.
e - this Entity Object's transaction event.