02 OUAF Overview

2
Config Tools Refresher
3-1
Copyright 2010, Oracle and/or its affiliates. All rights reserved.
Agenda
This section reviews important concepts from the Config Tools
training class
2-2
4-Tier Architecture
3-3
The Location Of The Business Rules
Web
Server
Application
Server
There are no business rules

on the Web Server
All business rules on the UI tier are
redundant (e.g., a drop-down that
contains valid choices is not a
substitute for a backend business rule
that checks the user's choice is valid)
2-4
DB
There are no business rules

in the database (i.e., no
stored procedures or
PL/SQL)
This is where youll find all of the

business rules and all of the
database access
Entity Relationship
Diagramming Standards
2-5
Colors and Mnemonics Highlight A Table's Class

And Features
SP Type
Disconnect
Location
Contact
Contact /
SP
The dashed line means the

FK is not in a dedicated
column. Rather, the FK is in
a multi-use column that can
reference practically any FK
in the system
2-6
Service
Point
Time
Zone
Legend
Lookup
Child Table
Related
Object
Activity
ST, CH, X
Tran. Data
Admin Data
Master Data
FW Data
The Application Viewer
2-7
The Table and Field Metadata

Every table has an entry in the table metadata
Every field has an entry on the field metadata
Table
A table has 1 or more

fields; a field can be on
one or more tables
Table /
Field
Constraint
A table has constraints to

define its prime key and its
foreign keys
Constraint
/ Field
Field
2-8
The Application Viewer Is The Primary

Documentation Of Tables And Fields
Many ERDs are used in this class
These ERDs are logical subsets used to reinforce important
concepts; there are typically many more tables involved in a
functional area than shown on the slides
The complete data model is viewable using the Application
Viewer
2-9
The Application Viewer Is Generated From

Metadata
The application viewers Data Dictionary is generated by a batch
process that converts the systems table / field metadata into
XML documents that drive this graphical representation
This same table / field metadata is also used to create the
services that add, change, delete and read data
This means that the data dictionary is reliable documentation
In other words, if the data dictionary is wrong, the system is
wrong
2 - 10
Practice 3-1 (15 minutes)

During this exercise, you will use the following transactions
Admin Application Viewer
Admin Table
You will see that the table and field metadata is identical to that
illustrated in the application viewer
2 - 11
Common Data Design Patterns
3 - 12
No Recurring Groups
Recurring groups of columns are rarely used on the tables
Rather, child tables normalize the relationship so each implementation can
have as many entries as it needs
Contact
Contact /
ID
The contact table doesn't
contain two columns one for
social security number and
another for drivers license.
Rather, a contact's various ID's
are kept on the Contact / Id
table (where each entry
references an identifier type).
2 - 13
ID Type
Contact /
Phone
Phone
Type
The same is true for a

contact's phones (and
names, and email). You'll
find this pattern throughout
the system.
Prime Keys
The prime key of most
"admin" tables is a userassigned mnemonic
Contact
Type
"Child" tables frequently have

concatenated prime keys
The prime key of many "non

admin" tables is a systemassigned, random number
Contact
Contact /
ID
ID Type
2 - 14
Prime and Foreign Keys In The Application Viewer
PK is gold
FKs are
blue
2 - 15
Language Tables
The admin tables support multiple end-user languages
An earlier diagram implied
that theres a column on the
Contact Type table that
holds its description this is
NOT true
Contact
This design allows each
contact type to have a different
description depending on the
end-user's language
Contact
Type
Language
Contact
Type /
Language
The description that
matches the users
language appears on
the UI
2 - 16
Maintenance Objects
3 - 17
MO Definition
Most logical transactions are made up of several tables
The term maintenance object (MO) is used to describe the
group of tables that hold an objects physical data
The contact
maintenance object's
data is held in several
tables
Contact
Contact
D1_CONTACT
Contact ID
Contact / ID
CI_LOOKUP_FIELD
D1_CONTACT_ID
Contact /
Name
Contact /
Phone
D1_CONTACT_NAME
D1_CONTACT_PHONE
Name Type
CI_LOOKUP_FIELD
2 - 18
Phone Type
CI_LOOKUP_FIELD
Note, this is a simplification

as this MO has more than
4 tables
MO, Table, Field Metadata

The MO, table and field metadata is very important as it is used to
generate the Java classes (and services) that add, change, delete and
read a maintenance object
If its wrong, the system wont work
Table
MO Def /
Table
MO
Table / Field
Field
2 - 19
MOs Are Also In The App Viewer

If you click this icon, you'll be
transferred to this table's MO (if the
table is part of multiple MOs, there are
multiple icons)
You are now shown the MO's

tables
These are all of the MOs

2 - 20
MOs Encapsulate Core Business Rules

In addition to defining data structures, MOs encapsulate core
business rules (e.g., validation logic)
These business rules are written in Java
These core business rules can be extended by an
implementation team
Note well - implementations cannot change or remove core
business rules; however, additional rules may be added as
described in the next section
2 - 21
Many MOs Have Characteristics
3 - 22
Characteristics Extend
Birth Date =
12/10/64
Contacts
County Parcel ID =
A234993
Service Points
Elevation =
1000ft
Customer
Count = 4
Subscriptions
Devices
Other
Things
2 - 23
Number
Wires = 3
...
Volts
= 240
Many MOs Support Characteristics
We use the term characteristic rather than user-defined field

Implementations set up a characteristic type for each user-defined
field needed by any MO
A child table holds an MOs user-defined fields
In other words, most MOs can have an unlimited number of
characteristics
Service
Point
SP / Char
Char
Type
An implementation can set

up an unlimited number of
user-defined fields for their
service points
2 - 24
There Are 4 Types Of Char Types

Each characteristics char type defines its category
The upcoming slides provide examples of each
Char
Type
Predefined
Value
2 - 25
Ad hoc
Value
Foreign Key
Reference
File
Location
Predefined Char Types

Predefined char types are used when the user-defined field has
a discreet set of valid values
Char
Type
Gender
Male
Female
2 - 26
Predefined
Value
Ad hoc
Value
Foreign Key
Reference
Valid Value
File
Location
Ad Hoc Characteristic Types

Ad hoc char types are used when the user-defined field holds a
date, a string, or a number
Birth
Date
Defined
Value
2 - 27
Ad hoc
Value
Char
Type
Foreign Key
Reference
File
Location
Foreign Key Reference Characteristic Types

FK char types are used when the user-defined field holds a
foreign key
Char
Type
Defined
Value
Ad hoc
Value
Property
manager
Foreign Key
Reference
File
Location
An FK ref char type must reference an FK ref

In this example, the foreign key reference
char type would reference the Contact FK
ref. This means that the char value must
be a foreign key to the contact table.
2 - 28
FK
Reference
File Location Characteristic Types

File location char types are used when the user-defined field
holds a reference to a file location or URL
Char
Type
Defined
Value
2 - 29
Ad hoc
Value
Foreign Key
Reference
Customers
Contract
File
Location
Characteristic Values Are Effective-Dated On

Some Entities
Note that the char collection of some MOs contains an effective
date, which allows the char value to change over time
SP
2 - 30
SP / Char
Char Type
A Char Type Can Be Used On Multiple Entities

When a char type is set up, in addition to defining its category
(ad hoc, predefine, FK ref, file location), you must define which
entities / MOs that it can be defined on
Char
Type
Entity
Char Type
/ Entity
2 - 31
Values:
- Contact
- Service Point
- Device
- Usage Subscr.
- etc
Data Ownership
3 - 32
Owning Metadata
The metadata is an integral part of the system
Much of this metadata is interpreted at execution time and is
therefore shipped with our software
The base-package metadata cannot be changed because:
These changes could cause the system to malfunction
(e.g., removing a field from a table would be very bad)
Future upgrades rely on the fact that we know how tables
(and MOs) look (imagine what would happen if an
implementation added a field to a table and then, in a future
upgrade, we did too)
To prevent inadvertent changes, most metadata tables have a
column called owner flag
2 - 33
Owner Flag ERD

The owner flag is simply a column on a table that references
the product that owns it
The installation record references the product that owns the
installed system. For example,
In an MDM development environment, this record
references the D2 (meter data management) owner
In a customers environment, this record references the
CM (customer) owner
This flag cannot be changed after the system is installed
Owner Flag
2 - 34
Installation FW
Owner Flag Is Ubiquitous

MO
Field
Owner Flag
Table
Char Type
You've only been exposed
to a small percentage of the
tables that have "owned"
metadata
2 - 35
The System Stamps Owner Flag On New

Metadata Rows
When you add a row to a metadata table, the system flags it with the
implementations active owner flag
Remember, the implementations owner flag is on the installation
record
The system will not allow changes to a row if the rows owner flag is
not the same as the implementations owner flag
For example, an implementation will not be able to change data
owned by the base-package
For example, if an implementation adds a new MO, the MO will be
marked with an owner flag of CM (given this is the value on the
implementation's installation record)
CM
Owner Flag
2 - 36
Installation FW
If you were to look at an

implementation's installation,
you'll find an owner flag of CM
(customer modification)
Dont Even Think About It

If you dont like something someone else owns and you think
that youll just change the rows owner flag outside of the
application (e.g., via ad hoc SQL), DONT DO IT
If you do, when you next upgrade, the upgrade scripts will
override any such changes (as ownership is reapplied during an
upgrade)
Similarly, if you use SQL to change data on a row that your
implementation doesn't own, the next upgrade will revert your
changes
2 - 37
2
Security
3 - 38
Database and Operating System Security

Browser:
provides logon prompt,
keeps a session cookie that holds
the authentication certificate
SSL encryption can be used here if
desired; managed by Web server
Web Server
App Server
Database
Server
2 - 39
Web server:
provides authentication,
allows you to use your operating
systems authentication: Windows,
Unix, authorization services are NOT
used
Application security is described in
the next section
The database sees one User
(controlled by the application server)
Sessions expire when:

Web server times out,
browser is closed
Browser caches the
users application
security values
Application Services Are Secured

Every securable transaction (e.g., business object, portal, page
transaction, zone, etc.) has a corresponding application service
When you link a user group to an application service, you are
granting all users in the group access to the application
services transaction
Application
Service
User Group
User Group /
App Svc
2 - 40
User Group /
User
User
A user's membership
in a user group has
an expiration date
Application Services Have Valid Actions

Every application service has valid actions
For example, update-oriented transactions have actions of read,

add, change, and delete
When you grant a user group access to an application service, you define
which valid actions it has rights to (read, add, change, )
Application
Service
Valid Action
User Group
User Group /
App Svc
Permissible
Action
2 - 41
User
User Group /
User
This defines the actions the users in

the group have access to
Field-Level Security
The system allows you to define the various fields which are
secured
Field-level security could be anything:
From:
Only certain users can change a field
To:
User group A can authorize bills less than $500
User group B can authorize bills less than $2,000
User group C can authorize any bill
While the system allows you to define the types of field-level

security you have and the authorization levels, your
implementation must add the code to user exits to enforce these
restrictions
2 - 42
Field-Level Security Overview

Every secured field has a security type associated with it
Every security type will have authorization levels
For example, the bill authorization security type would have 3 levels
Each user group is linked to the appropriate level for the security type for
the application service
Application
Service
Security Type
App Service /
Security Type
Authorization
Level
2 - 43
User Group
User Group /
App Svc
User Group /
User (Edate)
UG /
AppSvc / Sec
Type / Author
Level
User
Security Rights Are Cached

If you change anything thats security oriented, you must clear the
cache
To do this, replace cis.jsp with flushAll.jsp in the address field.
For example,
if the standard URL was http://sf-pdnt-009:7031/cis.jsp,
You would enter http://sf-pdnt-009:7031/flushAll.jsp to flush the
server cache
The framework will show this to indicate that the cache has been flushed. You
must restart the system with cis.jsp?debug=true (and it will take a little longer
than normal as it will rebuild the cache)
2 - 44
Business Objects
3 - 45
Maintenance Objects Versus Business Objects

MOs are designed to be
abstract and generic so
that they can be used in
multiple geographies and
vertical markets
Contact Maintenance Object (MO)

Contact
Contact
Name
Contact Id
Residential Contact BO
Individual
Contact ID
Name
E-mail
SSN
Home Phone
Date of Birth
Spouse
2 - 46
Contact
Char
Contact
Phone
Business objects are

specialized versions of MOs
that are designed to match the
business. For example, an
implementation could set up
BOs for different types of
businesses rather than work
with the generic contact MO
Commercial
Contact BO
Corporate
Contact ID
Corporate Name
Employer ID
Main Phone
Date of Incorporation
Corporate Officers
A Maintenance Object Has Fields,

A Business Object Has Elements
The term element is used to describe an individual piece of
information that a BO holds
This term is used rather than field or column because XML
documents are used to communicate with BOs (and XML
documents contain elements)
2 - 47
A BOs Elements Must Physically Reside

Somewhere In Its MOs Tables
Contact (D1_CONTACT)
Residential Contact
Elements
Contact ID
Contact
Type
Name (Name)
Name
E-mail
SSN
SSN (ID)
Home Phone
Phone (Phone)
Home
Work Phone
Work Phone
(Phone)
Extension
Date
Birth Ext. (Phone)
Work of
Phone
2 - 48
Contact ID
123
Contact Type
PER
Names (D1_CONTACT_NAME)
Type
Name
Primary
Brazil, Mark
Ids (D1_CONTACT_IDENTIFIER)
Type
ID Number
SSN
777
Phones (D1_CONTACT_PHONE)
Type
Phone Number
Home
973-777-7777
Work
973-451-7777
Ext
111
Characteristics (D1_CONTACT_CHAR)
Type
Value
DOB
1961-11-15
BOs Encapsulate Business Rules

In addition to defining the data structure of an object, a BO also
encapsulates business rules specific to the object
A BO's rules can never violate an MOs core business rules, as
the BO is a specialized version of the MO; the BO defines
additional business rules that are applicable to its instances
2 - 49
BOs and SOA

XML service calls are used to communicate with BOs (just like
MOs)
The main difference between MO and BO services is that the
XML for a BO service matches the BO's elements, thus making
it more intuitive to understand (and therefore simpler to invoke)
2 - 50
BO Elements and Rules
3 - 51
A BOs Elements Are Defined In Its Schema
Recall that each element must reside somewhere in its MO's

physical tables (notice the mapField and mapChild attributes)
2 - 52
"Real" Columns versus CLOBs
An element can reside in a real column or as XML stored in a CLOB

If the element will never be referenced in an SQL WHERE
statement, it can reside in a CLOB
Otherwise it must reside in a real column
Service
Point
SP / Char
Char
Type
XML
Elements that are not referenced

in WHERE statements can reside
as XML stored in a CLOB
2 - 53
Schema Configuration Is Used To Implement

Simple Rules
Recall the various validation-oriented attributes that can be
defined in a BO's schema:
<birthDate mdField="BIRTH_DT" >
validates the element is formatted as per the field's metadata
<propertyManager fkRef="SA" >
validates the element is a foreign key to the reference

table
<birthDate required="true" >
validates the element is specified
<customerType default="R" >
applies a default value if an element is left blank
<status dataType="lookup" lookup="STATUS_FLG" >
Validates the element is formatted as per the

dataType (and, in this case, checks the element's
value is a valid value for the specific lookup)
2 - 54
Validation Rules
Ad
BO d
A validation algorithm can be plugged in on a BO if more sophisticated

validation than can be defined using the schema attributes is required
Notice how validation algorithms are executed after the MO processing (e.g.,
core validation rules)
Individual Taxpayer
Ad
M d
O
Enter
2. MO Processing
2 - 55
Exit
Person MO
(Service)
3. Validation algorithms
To Create A New Algorithm, Follow These Steps

Write your logic (in Java or Scripting)
Create an algorithm type that references your program or script
Create an algorithm that references your algorithm type
Plug the algorithm in on the BO
Note - a Dashboard zone on the Business Object page contains a wizard that
will set up the above meta-data (you just have to write the script afterwards)
Programming
Language
Business
Object
BO
Algorithm
2 - 56
3
4
Algorithm
1
2
Algorithm
Type
Other Types Of Rules
In
vo
BO ke
In addition to validation rules, a BO can have:

Pre-processing rules to default elements into the BO's schema
Post-processing rules to perform additional logic after add /
change / delete operations
Audit rules to store audit trails after add / change / delete
operations
Enter
In
v
M oke
O
1. Pre-processing rules
2. MO Processing
2 - 57
Individual Taxpayer
Exit
Person MO
(Service)
5. Audit rules
4. Post-processing rules
3. Validation rules
BO Hierarchies
3 - 58
Reuse Scenario Post Processing Rule

Let's assume that whenever a new contact is added, a "welcome
letter" is sent, regardless of the type of contact
This could be implemented by plugging in a post processing algorithm
on all relevant BO's
However, some object-oriented adherents might argue this is
redundant
BO: ResidentialContact
lastName
firstName
driversLicense
Post Processing: Send

welcome letter on add
2 - 59
BO: CommercialContact
businessName
employerIdentityNbr

Put Common Rules On A Parent BO

You can define parent BO's in the meta-data
Some OO adherents would refer to this as a super class
You can then plug-in rules on the parent BO
Parent BO: GenericContact
BO: ResidentialCustomer
2 - 60
lastName
firstName
driversLicense
A post processing rule

defined on a parent BO
applies to all of its
children
businessName
employerIdentityNbr

Parent BO ERD
A parent BO is simply a BO that is
referenced by other BO's
Note, the parent and its children
must reference the same MO
Business
Object
There's a FK on BO
that references a
parent BO (this is
optional)
Algorithm
If a BO references a parent
BO, the parent's rules
automatically apply (no
compilation it's immediate)

2 - 61
lastName
firstName
driversLicense
businessName
employerIdentityNbr

Grandchildren and Great Grandchildren and

A child BO can have children (and so on)
lastName
firstName
driversLicense
Post Processing: Check
credit history
BO: CorporateContact

When this type of customer is
added, only a welcome letter is
sent
2 - 62
BO: PartnershipContact

When these types of customers are added, a welcome

letter is sent and their credit history is checked
Inheritance and Ownership
3 - 63
Only The Owning Implementation Can Change A

BO's Schema
Refresher:
BO's are owned
You can't change a BO's schema that you dont own
BO: Contact
Owner: D1 (Meter Data Foundation)
<name ... />
<customerId ... />
...
2 - 64
You can only modify this BO's

schema if the owner flag on the
installation record is D1 (and
typically only the base-package team
will have such an installation record)
Including A BO You Don't Own

While you can't change the schema of a BO that your
implementation doesn't own, you can add to it by creating a BO
and including the other BO's schema
Note, this implies that the
included BO must be the
parent; this is not true. You
can include a BO in any
other BO (but avoid
recursion!)
BO: Contact
Owner: D1
<name ... />
<customerId ... />
...
This shows how a "CM"

implementation can add
additional elements to a
base-package BO
This means that when elements are added
to Customer in a future release by the basepackage team, the implementation will get
them too (for better or for worse)
2 - 65
BO: MyContact
Owner: CM
<includeBO name="Customer" />
<employerIdentityNumber ... />
<marketingContact ... />
...
Avoiding Unnecessary Child BO's

However, what if you're happy with the base-package functionality,
but you just want to add additional logic?
BO: GenericCustomer
Let's assume you just want to

add another post-processing
algorithm to this BO that's
owned by the basepackage

BO: HumanCustomer
lastName
firstName
driversLicense
BO: BusinessCustomer
Post Processing: Check
credit history
BO: CorporateCustomer

2 - 66
BO: PartnershipCustomer

You Can Add Algorithms To BO's You Don't Own

You can add algorithms to
BO's you don't own
BO: GenericCustomer
Owner: D1
Owner: D1
Post Processing: Send welcome letter on add
Notice the 2nd algorithm's owner

flag (CM) differs from the owner of
the BO (C1)
We did this so you could add
additional validation / processing
without having to create a child BO
Owner: D1
Owner: D1
Post Processing: Check credit history
Owner: CM
Post Processing: Create To Do entry
2 - 67
Foreshadowing: Disabling Base-Package

Algorithms
While you cannot remove a base-package algorithm from a BO; you can tell
the OUAF not to execute an base-package algorithm by creating a BO
option (where the option type is Inactivate Algorithm)
Owner: D1
Owner: D1
Post Processing: Check credit history
Sequence: 10
Owner: D1
Post Processing: Create To Do entry
Sequence: 15
2 - 68
Any algorithm can be inactivated by

adding a BO option of Inactivate
Algorithm that references the algorithm's
code
Business Object Lifecycle
3 - 69
Each BO Can Have A Different Lifecycle

Because the lifecycle rules are declared in the BO meta-data, you can have
completely different lifecycle rules for BO's belonging to the same MO
Here are examples of 2 BO's with radically different lifecycles that belong to
the same MO
Literature Request Lifecycle
High Bill Complaint Lifecycle
Literature
Sent
Lodged
Preliminary
Investigation
Follow Up
Not Interested
Refer To
Salesperson
Canceled
Investigation
In Progress
Decision
Checkpoint
Cancel / Rebill
Approved
2 - 70
Rejected
State-Specific Rules
Earlier, you learned how you can plug-in algorithms on a BO
For example, you learned how you could develop validation
plug-ins to validate the elements on different types of
customers
But what if you need to perform validation that only applies
when a BO enters a given state?
For example, what if a field activity BO must have a
cancellation reason before it's allowed to enter the
Canceled state
2 - 71
State Transition Rules
Exit
Error
Exit algorithms execute when an object

attempts to leave a state (and errors roll
back to the prior state)
2 - 72
Enter
For each state in a BO's lifecycle, you can define the following types
of business rules
Logic to take place when a BO enters the state
Logic to take place when the BO exits the state
For example,
You could develop an algorithm that requires a cancellation
reason before a given BO is allowed to enter the Canceled state
You could develop a different algorithm that clears out error
messages when a given BO exits the Error state
Canceled
Enter algorithms execute before the
BO enters a state (and errors roll
back to the prior state)
Monitor (State Monitoring) Rules

You can add algorithm(s) to monitor a BO while it's in a state
This type of logic is used for two distinct purposes:
Check if the conditions necessary to transition the BO to
another state exist (and, if so, transition the BO)
Perform ancillary work while an object is in a state
For example,
You could transition a BO to the Canceled state if it's been
in the Error state too long
You could update statistics held on the object while it's in
the Active state (we'll discuss this in a later chapter)
Error
Canceled
Monitor
2 - 73
State-Specific BO Rules ERD

The BO meta-data supports the definition of algorithms to
execute when a BO enters and/or exits the state
Business
Object
Valid
Status
BO / State /
Algorithm
You have the same programming palette

as before (Scripting, Java, Cobol)
Algorithm
System
Event
Algorithm
Type
Valid Values:
Enter
Exit
Monitor
This allows you to define plugins for individual states under a

BO
2 - 74
BO Rules vs. BO State Rules

You plug-in rules on the BO for logic that is true regardless of the BO's
state
You plug-in rules on the BO / State for logic that only applies to an
object when it enters (or exits) a state
Business
Object
BO /
Algorithm
System
Event
Valid
Status
BO / State /
Algorithm
2 - 75
System
Event
Valid Values:
Pre processing
Validation
Post processing
Valid Values:
Enter
Exit
Monitor
Deferred Monitoring Batch Process ERD

If you want to defer the execution of monitoring algorithms to a batch process,
reference the monitoring batch process on the state
If the framework sees a batch process referenced on a state, it will NOT
invoke the state's monitoring algorithms when the object enters the state;
rather, it assumes that the batch job will do this
Business
Object
Valid
Status
BO /
Status /
Algorithm
2 - 76
Batch
Control
The presence of this FK can be thought of as
a switch that tells the FW to not execute the
monitor plug-in when the object initially
enters the state
System
Event
Valid Values:
Enter
Exit
Monitor
Inheriting Lifecycle
3 - 77
Reuse Scenario Lifecycle

Let's assume:
You have many different types of field activities (install meter, investigate
service theft, read meter, remove meter, exchange meter, )
You're going to create a separate BO for each type of activity
Every type of activity has the same valid states
Some activity types have special processing that takes place when they
enter / exit some states
If you knew nothing more, you'd be forced to define the same valid states on
every BO
BO: InstallMeter
Pending
Canceled
Dispatched
Complete
2 - 78
BO: RemoveMeter
Pending
Canceled
Dispatched
Complete
BO: ReadMeter
Pending
Canceled
Dispatched
Complete
Reuse The Lifecycle

Rather than repeat the lifecycle again and again, you can set
up a parent BO and declare the lifecycle on it
Parent BO: GenericFieldActivity
Pending
Canceled
Dispatched
Complete
BO: InstallMeter
2 - 79
BO: RemoveMeter
BO: ReadMeter
You Have No Choice

If a BO references a parent BO, it always inherits its lifecycle
from the topmost BO in the hierarchy
BO: GenericFieldActivity
Pending
Canceled
Dispatched
All BO's beneath the line

have the lifecycle of the
topmost BO in the hierarchy
Complete
BO: InstallMeter
BO: InstallComplexMeter
2 - 80
BO: ReadMeter
BO: InstallSimpleMeter
Enter, Exit and Monitor On Child BO's

You can plug-in Enter, Exit and Monitor algorithms on the child
BO's
Parent BO: GenericFieldActivity
Pending
Canceled
Dispatched
Complete
BO: InstallMeter
Status: Complete
System Event: Enter
Algorithm: Create
Installation Charge
2 - 81
BO: InvestiSvcTheft
BO: ReadMeter
Only states defined on the

topmost parent BO can be
referenced
2
Check Point
3 - 82
Algorithm System Event Summary ERD

MO
MO /
Algorithm
System
Event
BO
Algorithm
BO /
Algorithm
System
Event
Valid
Status
BO / State /
Algorithm
2 - 83
System
Event
Valid Values:
Info
Transition
Transition Error
Determine BO
Valid Values:
Validation
Pre Processing
Post Processing
Audit
Info
some designs
introduce these
Valid Values:
Enter
Exit
Monitor
In
vo
BO k e
Algorithm Execution Summary

Individual Taxpayer
Enter
In
v
M oke
O
1. Pre-processing rules
Exit
8. Audit rules (BO)
Person MO
2. Determine status field.
If changed proceed with
old value (Keep new
value for later)
3. MO Processing
This incluedes MO-level
validation and inserts /
updates to the database.
7. Post-processing rules (BO)

6. State-transition rules (BO)
If status has changed, execute
> Exit rules (old status)
> Update status to new value
> Enter rules (new status)
> If no error, Transition (MO)
> If error (and save points)
Transition Error (MO)
otherwise, return the error
> Monitor (new status)
> If monitoring, repeat #6
5. Validation rules (BO)
4. Determine BO (MO)
2 - 84
Entity Relationship
Diagramming Standards Revisted
2 - 85
Colors and Mnemonics Highlight A Table's Class

And Features
ST the object has a
configurable lifecycle
CH the object has a
collection a characteristics
X the table has a CLOB
Contact
ST, CH, X
Contact /
SP
SP Type
CH, X
Service
Point
ST, CH, X
Disconnect
Location
Time
Zone
Legend
Lookup
Child Table
Tran. Data
Related
Object
Activity
Admin Data
ST, CH, X
Master Data
FW Data
ST - Status
CH - Characteristics
X - CLOB
2 - 86
Additional Diagramming Techniques
Service
Point
ST, CH, X
XML
Disconnect
Warning
FW4 introduced the extendable

lookup (used when the lookup value
is longer than 4 bytes or when the
lookup value has attributes in
addition to its description). This
symbol highlights when this type of
lookup is used.
Ext
Legend
When a relationship is held in a

CLOB, this diagramming
technique is used
Lookup
Child Table
Tran. Data
Admin Data
Master Data
FW Data
ST - Status
CH - Characteristics
X - CLOB
2 - 87
Odds and Ends
3 - 88
Localization Support
The following values can be defined on the users profile
Date / Time display formats
Position of Year, Month, Day
Time Format (e.g., 24-hour clock versus AM/PM)
Currency and quantity format

Decimal point symbol
Thousands separator
Position of negative sign
In addition, the address components may differ per country
2 - 89
Review Questions
2 - 90

02 OUAF Overview

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

02 OUAF Overview

Hochgeladen von

Copyright:

Verfügbare Formate

2

Config Tools Refresher

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

The Location Of The Business Rules

There are no business rules

There are no business rules

This is where youll find all of the

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Colors and Mnemonics Highlight A Table's Class

The dashed line means the

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

The Application Viewer

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

The Table and Field Metadata

A table has 1 or more

A table has constraints to

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

The Application Viewer Is The Primary

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

The Application Viewer Is Generated From

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Practice 3-1 (15 minutes)

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Common Data Design Patterns

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

The same is true for a

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

"Child" tables frequently have

The prime key of many "non

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Prime and Foreign Keys In The Application Viewer

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Note, this is a simplification

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

MO, Table, Field Metadata

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

MOs Are Also In The App Viewer

You are now shown the MO's

These are all of the MOs

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

MOs Encapsulate Core Business Rules

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Many MOs Have Characteristics

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Many MOs Support Characteristics

We use the term characteristic rather than user-defined field

An implementation can set

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

There Are 4 Types Of Char Types

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Predefined Char Types

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Ad Hoc Characteristic Types

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Foreign Key Reference Characteristic Types

An FK ref char type must reference an FK ref

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

File Location Characteristic Types