R12 Building OA Framework Applications: Basics of The Model

Copyright 2007, Oracle. All rights reserved.
R12 Building OA Framework Applications

Basics of the Model
Copyright 2007, Oracle. All rights reserved. 3 - 2
Lesson Objectives
After completing this lesson, you should be able to:
Discuss BC4J and the Model layer of MVC
Discuss Application Modules (AMs)
Discuss Entity Objects (EOs)
Discuss View Objects (VOs)
Discuss how BC4J interacts with the database
Discuss other Model-layer components
Model-layer BC4J Objects
Encapsulation
The Reuse Onion
Each layer only knows about
the layers below it.
This encapsulation promotes
easier reuse of components.
General Reuse Rules
Model code should never reference controller code directly.
Never reference/import any server-side implementation
classes or interfaces on the client-side.
If you need the server code to do work for you, always route
your call through the root application module.
Never include JDBC or other server-side processing directly
in your client-side code.
Recommended Build Approach
1. Create any business components packages that you
need for your BC4J model objects.
2. Implement declarative BC4J application modules,
entity objects, view objects and others as needed for
your page(s). Add view objects to your root application
module(s) as appropriate.
3. Create the menu definition for your application.
4. Create the OA user interface components for your page(s).
5. Create and implement controller code.
6. Implement UI application module code supporting your
pages.
7. Implement entity object business logic.
Business Component (BC4J) Packages
While not formally a BC4J component, every BC4J
component must belong to a BC4J package.
BC4J packages contain the following:
The naming/pathing structure for the BC4J components
it stores.
The database connection associated to the package for
your development environment.
Is mostly used for showing the relationship amongst
related BC4J components by storing related
components together, and then using a standardized
naming structure to highlight the relationship.
BC4J Package Naming Standards
BC4J packages also correspond to directory paths.
EO-related (business logic) .java and .xml files in
oracle.apps.<application shortname>.
<module>.schema.server
AM and VO (UI-related logic) .java and .xml files in
<module>.server
Poplist- and LOV-related VO and AM .java and .xml files
in oracle.apps.<application
shortname>.<module>.poplist.server and
<module>.lov.server
Application Modules
Defines the logical data model and business methods
needed to support an application task
Handles transactions
Interacts with clients
Application Modules
Encapsulates Server/Middle tier View Objects
Container for view objects and view links
View objects are defined by view instance names
which are the names referenced by UI framework
Allows definition of master/detail view links
Encapsulates Server/Middle tier controller-like logic
Initialize and perform view object query
Custom functions to process view objects
For example: copying data between VOs.
Custom functions to access entities.
Application Modules
Root AM holds BC4J Transaction object
Nested AMs reference the root AM Transaction
object
OA Framework groups pages together by Root AM
Pages with same Root AM name, and RetainAM=Y
URL flag, are handled as one AM/Transaction
instance shared for both pages
Useful for multi-page updates
Useful for sharing expensive queries across several
pages
Transaction Object
Holds Database Connections
Holds all Entities centrally, separate from Application
Modules and View Objects
Holds list of EOs that require:
Validation
Posting to database
Commit notification
Application Module Files
Each AM should have:
<YourName>AM.xml
Declarative information about AM
<YourName>AMImpl.java
Add methods to invoke assign VOs initQuery
methods if needed
Entity Objects
Map to a database table or other data source
Each entity object instance represents a single row
Contains attributes representing database columns
Fundamental BC4J object through which all
inserts/updates/deletes interact with the database
Entity Objects
Central point for business logic and validation related to a
table
Encapsulates attribute-level and entity-level validation logic
Can contain custom business methods
Entity Object Creation Standards
Include all table columns in the EO.
Base your EOs on the _ALL tables rather than on
organization-restricted views.
Always generate accessors (setters/getters).
Speeds up performance in attribute lookups
because you can use named accessors
Entity Object Automatic Features
Validation, locking and posting order of children
Handled by Composite Associations
Who Columns (Record History)
Set automatically during EO create() or doDML()
EO should have following attributes:
CreationDate
CreatedBy
LastUpdateDate
LastUpdatedBy
LastUpdateLogin
Entity Object Files
Each EO should have:
<YourName>EO.xml
Declarative information about EO
<YourName>EOImpl.java (optional)
Add create(), remove(), validateEntity(), and setter
methods.
View Objects
Represent a query result.
Are used for joining, filtering, projecting, and sorting your
business data.
Can be based on any number of entity objects.
Can also be constructed from a SQL statement.
View Objects
View Object is designed to:
Manage collection of data
Main collection interface into the database data

Provide view-like shaping of data
Leverage SQL to join tables and corresponding
EOs
View Objects
A View Object should:
Always delegate to other objects such as the EO or
PL/SQL for business logic
ensures better reuse of business logic
Contain only the attributes required for a specific
purpose
Do not select more attributes (columns) than
required for a page/transaction UI
View objects should be considered specific to a
particular UI and are not expected to be reused
View Object Creation Methods
View Object can be created in one of three ways, based
on:
Generated SQL based on EOs
Add where clause at design-time, not run-time for
best performance
Expert Mode custom SQL with no underlying EOs
Read-only Data
Expert Mode custom SQL manually mapped to EOs
ExpertMode View Objects
Use ExpertMode custom SQL, manually mapped to EOs,
for:
Unions
Complex SQL
SQL is encapsulated within an inner view to support
additional View Link bindings: select * from (your-sql-
here)
View Objects with Entity Objects
VO can be mapped to multiple
Updateable EOs, though often just the primary EO
Reference EOs, used for additional joined data
including description lookups
View Object Rows
A view object controls many view rows.
Each view row represents a row of the data that is queried
from the database.
An entity object gets instantiated for each view row.
Creating View Objects
When you want aliases in the query, make sure that the
attribute settings in the VO wizard include the alias
names.
When you create or modify an "Expert mode" VO using
the View Object wizard, be careful to make sure that the
attribute mappings match the expressions in the query.
View Object Java Files
Create VO Java class (VOImpl) if needed
VOs should not contain business or validation logic,
except transient attribute logic
Always create View Row Java class (ViewRowImpl) and
accessors (setters/getters)
View Object Files
Each VO should have:
<YourName>VO.xml
Declarative information about VO
<YourName>VOImpl.java (optional)
Add initQuery method if needed
<YourName>ViewRowImpl.java (required)
Contains accessors (setters and getters) for VO
attributes
Behind the scenes, these accessors call
corresponding methods in your EOImpl.java
BC4J Database Interactions
Examine the following scenarios:
Pure object-oriented (non-BC4J) method
View Objects without Entity Objects (read-only queries)
View Objects with Entity Objects
Step 1: View Object initial query
Step 2: Entity Object population
Step 3: Entity Object reuse
Step 4: Entity-derived attributes
Step 5: Entity Object fault-in
Step 6: Entity Object references
EO/VO merge
ReqId
PK
Number
SupplierId
FK
SupplierNum
CalcField1
Entity-Derived
Requisition Supplier
Entity
UI Row
Database
ReqId PK SupplierId PK
Multiple I/Os to fetch Entities
Entities are used
to create Row
Non-BC4J Method
Read-only Queries
ReqId
PK
4534
Number
123
SupplierId
FK
456
SupplierId
PK
456
SupplierNum
1234
CalcField2
SQL-Derived
"CalcValue2"
CalcField1
Entity-Derived
View
Object
Row
Database
VO queries directly from
database - one VO can fetch
multiple rows
ReqId
PK
4534
Number
123
SupplierId
FK
456
SupplierId
PK
456
SupplierNum
1234
CalcField2
SQL-Derived
"CalcValue2"
CalcField1
Entity-Derived
View
Object
Row
Database
VO queries directly from
database - one VO can fetch
multiple rows
Step 1: Initial Query
Step 2: Entity Object Population
Entity
View
Object
Row
Database
ReqId
PK
4534
Number
123
SupplierId
FK
456
CalcField1
Entity-Derived
SupplierId
PK
456
SupplierNum
1234
Closed
Code
Misc
Field1
Misc
Field2
ReqId
PK
Number SupplierId
FK
SupplierId
PK
SupplierNum CalcField2
SQL-Derived
"CalcValue2"
CalcField1
Entity-Derived
Query data is used to instantiate
and partially populate Entities
Step 3: Entity Object Reuse
Requisition
Entity
2nd
View
Object
Row
Database
ReqId
PK
4554
Number
124
SupplierId
FK
456
CalcField1
Entity-Derived
SupplierId
PK
456
SupplierNum
1234
Closed
Code
Misc
Field1
Misc
Field2
ReqId
PK
SupplierId
FK
SupplierId
PK
SQL-Derived
"COMP"
CalcField2
SQL-Derived
"CalcValue2"
Number CalcField1
Entity-Derived
CalcField1
Entity-Derived
ReqId
PK
Number SupplierId
FK
SupplierId
PK
SupplierNum
VO reuses same
Supplier EO for 2nd Row
Step 4: Entity-derived Attributes
Entity
View
Object
Row
Database
ReqId
PK
4534
Number
123
SupplierId
FK
456
CalcField1
Entity-Derived
"CustValue"
SupplierId
PK
456
SupplierNum
1234
Closed
Code
Misc
Field1
Misc
Field2
ReqId
PK
Number SupplierId
FK
SupplierId
PK
SQL-Derived
"CalcValue2"
CalcField1
Entity-Derived
UI getCalcField1()
Calculate Entity-Derived
attributes on demand
Step 5: Entity Object Fault-in
Entity
View
Object
Row
Database
ReqId
PK
4534
Number
123
SupplierId
FK
456
CalcField1
Entity-Derived
"CalcValue"
SupplierId
PK
456
SupplierNum
1234
Closed
Code
"OPEN"
Misc
Field1
Misc
Field2
ReqId
PK
Number SupplierId
FK
SupplierId
PK
SQL-Derived
"CalcValue2"
CalcField1
Entity-Derived
Framework faults-in and merges
missing attributes from DB on demand
EO.getClosedCode()
Step 6: Entity Object References
Supplier
Entity
View
Object
Row
Database
ReqId
PK
4534
Number
123
SupplierId
FK
507
CalcField1
Entity-Derived
"CustValue"
SupplierId
PK
507
SupplierNum
1289
Closed
Code
Misc
Field1
Misc
Field2
ReqId
PK
Number SupplierId
FK
SupplierId
PK
SQL-Derived
"CalcValue2"
CalcField1
Entity-Derived
UI setSupplierIdFK(507)
Supplier 507 is
automatically fetched
Read-only
1289 = getSupplierNum()
Requisition
Entity
Database
ReqId
PK
4534
Number
123
Description
"NewDesc"
Closed
Code
"OPEN"
Modified entity already exists in
transaction cache. Attribute is
marked as dirty
EO/VO Merge
Step 1: EO/VO Merge Resolution
Entity
View
Object
Row
Database
ReqId
PK
4534
Number
123
SupplierId
FK
456
Description
"NewDesc"
SupplierId
PK
456
SupplierNum
1234
Closed
Code
"OPEN"
Misc
Field1
Misc
Field2
Query brings in older values that don't
match new EO attributes
ReqId
PK
4534
Number
123
SupplierId
FK
456
SupplierId
PK
456
SupplierNum
1234
Description
"OldDesc"
Closed
Code
"OPEN"
Step 2: EO/VO Merge Resolution
Entity
View
Object
Row
Database
ReqId
PK
4534
Number
123
SupplierId
FK
456
Description
"NewDesc"
SupplierId
PK
456
SupplierNum
1234
Closed
Code
"OPEN"
Misc
Field1
Misc
Field2
Original Attribute values are not
merged with EO
ReqId
PK
Number SupplierId
FK
SupplierId
PK
SupplierNum Description Closed
Code
VO will display new EO values "OldDesc"
Other Model-layer Objects
Association Objects (AOs)
View Links (VLs)
Entity Experts
Validation Application Modules (VAMs)
Validation View Objects (VVOs)
Association Objects
Define a relationship between entity objects.
Facilitate access to data in related entity objects
May be based on database constraints
May be independent of database constraints
Consist of a source (master) and a destination (detail)
entity
Source Destination
OrdersByAO
Association
CustomerEO OrderEO
Association Objects
Two types of Association Objects
Reference
Composition
Both types can be referenced via association attributes
on Entity.
Reference Association Objects
Reference Association
Used for weak associations between Entities, such as
foreign keys for lookups
No special runtime behavior
Example: Requisition - Supplier association
Composition Association Objects
Composition Association
Used for composite objects with strong "owning"
relationship
Use if: child entity cannot exist without parent; child
is deleted when parent is deleted
Example: RequisitionHeader - RequisitionLine
association
Create by checking the Composition check box in the
BC4J association wizard
Composition Association Object Behavior
Behavior of Composition Association
When child is dirtied, parent is dirtied automatically
When child is locked, parent is locked first automatically
Parent is brought into memory automatically if not
already in memory
Validation order is child first, parent second - parent has
final veto power on child modifications
Insert/Update order is parent first, child second
Delete order is child first, parent second
View Links
A view link is an active link between view objects.
You can create view links by providing the following:
Source and destination views
Source and destination attributes
Source
view object
Destination
view object
Order4ItemVL
Link
InvItemVO LineItemVO
View Links
Use a View Link to create a Master-Detail relationship
between view objects.
Allows dynamic synchronization between parent and
child VO
Child rowset is refreshed when the current parent row
changes
Entity Experts
Simple common code or, more commonly, validation
routines that can be called by other EOs that avoids the
overhead of instantiating an entire EO.
Validation AMs and Validation VOs
Validation VOs (VVOs): Allows simple SQL statements
to be executed at the entity-layer. Most commonly,
these are SELECT statements done to validate data.
Validation AMs (VAMs): VOs must be contained within
AMs. VAMs are the containers for VVOs.
Summary
In this lesson, you should have learned how to:
Discuss BC4J and the Model layer of MVC.
Discuss Application Modules (AMs).
Discuss Entity Objects (EOs).
Discuss View Objects (VOs).
Discuss how BC4J interacts with the database.
Discuss other Model-layer components.

R12 Building OA Framework Applications: Basics of The Model

Uploaded by

Copyright:

Available Formats

R12 Building OA Framework Applications: Basics of The Model

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

R12 Building OA Framework Applications: Basics of The Model

Uploaded by

Copyright:

Available Formats

Copyright 2007, Oracle. All rights reserved.

R12 Building OA Framework Applications

You might also like