OA Framework was designed with durable extensibility capabilities. Durability of OA Framework extensibility is largely attributed to the declarative architecture and the object-oriented approach underlying the implementation. The JDeveloper wizards and built-in personalization UI make it easier to extend the Oracle E-Business Suite. In addition, Oracle customers can take advantage of the extensibility offered by Flexfields (Oracle E-Business Suite Flexfields Guide) and Oracle Workflow (Oracle Workflow Administrator's Guide).
OA Framework extensibility is geared to enable customers to add new functionality and override or extend existing business logic beyond what can be accomplished via personalization. This includes the following extensibility scenarios:
Adding new pages or complete flows.
Adding a new attribute (i.e. field) to a prepackaged page.
Extending attribute defaulting logic.
Extending validation logic.
To understand how extensibility works, one must understand how OA Framework applications are built. Please refer to the following sections in the OA Framework Developers Guide:
Chapter 2: OA Framework Essentials: Anatomy of an OA Framework Page
Chapter 3: Building an OA Framework Application: Implementing the Model
Chapter 3: Building an OA Framework Application: Implementing the View
Extensibility is often observed in the UI, but implementation is mostly centered on the underlying business objects. The following diagram depicts the BC4J objects involved when extending an OA Framework application.
The first row of the diagram represents an exhaustive list of all possible objects a developer might create when creating an entity object. The first box illustrates that when creating an entity object, two files are generated: the meta-data definition XML file and the actual implementation Java class file. Entity Objects handle attribute level and record level validations. These validations often need to use other View Objects, called Validation View Objects (VVO). Validation View Objects are grouped under a Validation Application Module (VAM). Like Entity Objects, creating a VVO and a VAM generates a meta-data definition XML file and an implementation java class file for each object.
Finally, the Entity Object sometimes relies on a helping class to offer, among other services, a validation service optimized for usage by other Entity Objects. This helper class is called the Entity Expert and is linked to the Entity Object through an Entity Object property.
Note: The diagram illustrates a case in which all objects are extended, which is not always the case. In most of the situations, you may be satisfied with extending just a portion of these objects.
Caution: Never edit the base definition of an object or make a copy of a base object. Always extend the relevant object and use BC4J substitutions to reference the extended object.
For example, you may be satisfied with extending the Entity Expert to override a validation method such as isSupplierValid. In such a case, it is not wise to reference the extended Entity Expert (MyEntityExpert) directly from the base Entity Object (EntityEO.XML), as such an approach does not survive upgrades.
A durable approach requires extending the base Entity Object (using the JDeveloper Wizards) and updating the entity expert property on the extended Entity Object to point to the extended Entity Expert.