| Oracle® Fusion Applications Developer's Guide 11g Release 4 (11.1.4) Part Number E15524-09 |
|
|
PDF · Mobi · ePub |
| Oracle® Fusion Applications Developer's Guide 11g Release 4 (11.1.4) Part Number E15524-09 |
|
|
PDF · Mobi · ePub |
This chapter provides an overview of ADF Business Components, validators, list of values (LOVs), and data types. It also discusses migrating PL/SQL to Java, batch processing, and extensibility and reusability. Also included is an overview of services.
This chapter includes the following sections:
The core business logic is implemented in one or more business components that are provided in ADF Business Components. Entity objects, view objects, and application modules are the key business components that are discussed in this section.
An entity object represents a row in a database table. It encapsulates the business logic and database storage details of your business entities. It simplifies modifying its data by handling Data Manipulation Language (DML) operations automatically. There are two general classifications of business logic that are placed on the entity object:
Standard business and validation logic
Specialized business functions
An entity has a life cycle; customized business rules can be added to an entity object at various places to be executed in different phases of its life cycle.
The entity object should contain all logic that is invoked during entity object life cycle events. This comprises logic for create, initDefaults, all validation (including attribute validation, entity validation and cross entity validation), DML, and so on. In other words, the entity object encapsulates the rules that ensure the entity object is created and remains in a valid state.
Note:
All logic existing in one entity object Java class not required. It's valid for the entity object to call utility classes for code modularity purposes.
If a business rule can be defined declaratively, you should always use the declarative approach. For example, if an attribute has a constant default value, then you should specify it in the Entity Object wizard rather than coding it. You should also first consider using declarative validators for your validation logic, which is explained in Section 4.2, "Understanding Validators".
The life cycle of an entity object begins with being created as a new entity object or fetched from the database as an unmodified entity object. The entity object can then be modified or removed. Only new, modified, or removed entity objects are in the transaction pending change list and are posted to the database when the transaction is committed.
For more information about the key events in the entity objects life cycle and where you can add entity object business logic programmatically, see the Introduction to Programmatic Business Rules section in the "Implementing Validation and Business Rules Programmatically" chapter in the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework (Oracle Fusion Applications Edition).
The entity object is the core business object that is used to encapsulate task-level business logic. It is shared by both user interfaces (UIs) and services. Core business functions and tasks should be placed on the entity object as custom methods for maximum reusability. Corresponding methods on the view object and application modules should delegate to these functions on the entity object. Examples of business functions are approvePurchaseOrder and hireApplicant. Internally, these custom methods can be implemented using Java or may invoke legacy PL/SQL.
Custom business functions that are not invoked during entity object life cycle events should be placed in either the entity object or model application module. Generally these are the custom business functions that are required by the UI and Service application module.
A view object represents a SQL query and also collaborates with entity objects to consistently validate and save the changes when end users modify data in the UI. The relationships between view objects are captured using view links. View objects are used to present your business data for the specific needs of a given application scenario or task, and generally don't contain business logic.
However, view objects may have additional attributes that do not exist in the underlying entity objects, which are used to store some calculated values. Usually you define different view objects for supporting services and UIs:
Service view object: Represents an outfacing business object and contains only the attributes in the business object. For example, it contains the foreign key ID attribute such as SupplierID, but it does not contain foreign key reference attributes such as SupplierName.
UI view object: This view object may contain addition UI flags and calculated attributes that are used for a particular UI. In addition, the UI view object may join to other tables for additional foreign key attribute references.
Note:
A service view object must be versioned to support service versioning. However, there is no versioning requirement for an internal UI view object.
An application module encapsulates an active data model and the business functions for a logical unit of work related to an end-user task. The active data model is defined as a collection of view object instances.
The methods on the application module are used to encapsulate task-level business logic, although these methods should delegate to the methods on entity objects whenever possible. If you have an option to put your business logic either on an entity object or an application module, then you should always put it on the entity object. This is because the entity object owns the business object and also for better reusability. The task-level validations that span multiple related parent-child entities, such as purchase order header and lines, should be put on the parent entity. It is also important that the entity object should not trust the incoming data and always perform all validations.
Application modules can be used to support UIs or define services. Usually you want to have two separate application modules for the two different purposes because:
UI application modules may contain additional view objects and context values that are only required for a particular UI, but not needed by a business service.
Application modules that define public services are versioned, but internal UI application modules are not.
UI application modules and service application modules share the underlying entity objects as shown in Figure 4-1. A UI application module can also call a service.
In Fusion, you should use validators to implement the validation logic. Validators are added declaratively, which provides visibility and personalizability to customers as well as the benefit of being easy to use and maintain. Validation view objects can be attached to entity objects declaratively as view accessors, which can then be used in declarative validators.
For more information about how to use validators and Groovy (a Java-like scripting language), see Chapter 6, "Defining Defaulting and Derivation Logic."
List of Values (LOV) is the mechanism to specify a list of valid values for an attribute in a view object. There are basically two parts involved when a LOV is defined: the base object and the LOV object. The base object is a view object, which contains the attribute whose list of valid values need to be defined, such as a PurchaseOrder view object containing a BuyerId attribute. The LOV object is a normal view object that contains the list of valid values, such as a Buyer view object containing all the valid buyers. You should use the view object design time wizard to add a List Value on the BuyerId attribute to associate with the Buyer view object.
In Fusion, the LOV metadata is defined on the server using ADF Business Components, and this drives and defaults the UI controls to automatically render the LOV bound items accordingly when you define a page, such as LOV and poplist controls.
It's important to define the LOV and entity validators to share the same view object instance to avoid redundant database round-trips for validation. To achieve this, the LOV view object should be added as a view accessor in the entity object, and the view accessor should be used to define entity level validators. The same view accessor is available at the view object level and should be used to define the LOV. When the user picks up a row from LOV on the UI, the row is placed on the LOV view object cache. The entity object validation then hits the cache instead of going against the database. A LOV/validation view object can also be defined as a global data source that is shared among all the users.
For more information, see the "Sharing Application Module View Instances" chapter, in the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework (Oracle Fusion Applications Edition).
Depending on the use case, different approaches should be considered to achieve the best performance.
For the use case of complicated bulk processing, such as very high volume or multiple step processing, then a combination of multiple techniques needs to be considered. For example, ADF Business Components, C, PL/SQL, SOA, Oracle Enterprise Scheduler (ESS), and so on.
For the other use cases, such as integration with third- parties or data migration, if the data volume is low to medium, then ADF Business Components service should be used. Internally, a combination of interface table and PL/SQL can be used to handle large amount of data, complicated processing, and validation logic. The inbound data is loaded into an interface table through a service and then the PL/SQL API is executed to process the data
Note:
You should still provide services for all objects, and double code the high performance alternatives when necessary.
Fusion web applications are extensible applications, which can be tailored to fit the business practices specific to a customer, locale or an industry. Adaptation through Business Editor enables you to extend Oracle applications declaratively, which satisfies most of the extensibility requirements. You can also use the programmatic extensibility feature to address additional use cases.
A service is a set of operations defined by an interface that can be used by other components. In Fusion, applications use both ADF Business Components services and SOA services. ADF Business Components services should be created to manage business objects and SOA services are for orchestration and business processes.
In Fusion, you make your data and business logic available via UIs and services. For more information about services, see Chapter 5, "Developing Services."
When building your model objects, you should use the declarative approach whenever possible. For example, when defining your view objects, use declarative SQL mode whenever possible, base your view objects on entity objects, and utilize view criteria.
When you define your view objects, use declarative SQL mode wherever possible. The next option is to use normal SQL mode.
When building your view objects, use declarative SQL mode wherever possible. Reasons for not using declarative SQL include:
You have a complicated query and the WHERE clause cannot be implemented using view criteria.
Your query includes derived attributes that cannot be implemented as calculated attributes based on a SQL expression.
If you are unable to use declarative SQL mode, you should try and use normal SQL mode, which gives you full control over the WHERE clause. Only use expert mode if other modes do not work. However, you should still base the view object on an entity object when the query supports it.
Non-expert mode view objects are metadata based and more declarative instead of SQL based. The declarative approach gives you benefits such as:
Increased development productivity:
Proven experience from PeopleSoft and Siebel.
Removes the requirement for you to tune each view object.
Easier to perform dependency and impact analysis.
Can be extended more robustly.
Declarative SQL mode is recommended because it is an even more declarative approach to defining the view object than normal mode.
The runtime query optimization feature is enabled only when you use declarative SQL mode. ADF Business Components makes runtime changes to the SQL based on usage such as column pruning to improve performance.
Declarative SQL optimization means you can consider creating view objects that can be reused in multiple UIs without impacting runtime performance.
For more information about how to set the SQL mode, see the Working with View Objects in Declarative SQL Mode section of the "Defining SQL Queries Using View Objects" chapter in the Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework (Oracle Fusion Applications Edition).
All view objects (including read-only view objects) should be based on entity objects unless:
Entity object based view objects are not supported for the SQL statement you are using, for example:
Union
Select Distinct
Group By
Your data doesn't come from the database. For example, the data comes from external files.
Even if you have to use expert mode view object, you should still base your view object on top of entity objects because:
The attributes from the entity object are still declaratively defined so that you can partially benefit from the declarative approach.
Multiple view objects based on the same entity object can automatically see updates made by any one of them.
Updated reference information is reflected when foreign key attribute values are changed.
Metadata, (UI hints, associations, and other attributes), are automatically propagated up to the view objects from entity objects.
New row management, such as view link consistency, only works with an entity object-based view object.
findByKey doesn't work for view objects with no entity usage unless you turn on the key management at the view object level (and this will add significant resources and CPU time). The findByKey method is a frequently invoked by any operation that involves setting the current row, such as clicking a row on an ADF Faces rich client table:
findByKey does not find the matching view row in the view object cache if the key management is not enabled.
findByKey adds the row fetched from the database into view object cache even if the view object already has the same row in cache if the key management is not enabled.
Updatable view objects must be based on entity objects so that view objects can coordinate with the underlying entity objects to perform DML.
Instead of directly setting the WHERE clause, use declarative named view criteria whenever possible. Named criteria can be re-used in the UI and in the service interface. Also, it supports customization better and is required for declarative SQL mode.
In parallel, always use named bind parameters. Define the named bind parameters during design time if possible. Otherwise, add the named bind parameters programmatically. Named bind parameters are much easier to understand and manage than the indexed bind parameters so therefore, the code is easier to develop and maintain. If the same bind parameter appear multiple times in the WHERE clause, you only need to bind it once.
|
 Copyright © 2011, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
