Very Brief Overview of Chapters 4 Through 9

Overview
Historically, we developed products that required a lot of

configuration to satisfy each customer's specific business
requirements
The advent of the ConfigTools has changed how we design, how we
develop, and what we release
Today PD develops solutions that mostly work out-of-the box with a
minimal amount of configuration
Implementation teams use the same tools to extend the products to meet
their specific customer's requirements
The end-result is 100% upgradeable
Bottom line:
Implementation timelines are much faster
Total cost of ownership is reduced
We deliver true COTS software that can be extended and survive the
upgrade
Development time is reduced
1-1 Copyright 2009, Oracle. All rights reserved.

N-Tier Overview
Copyright 2009, Oracle. All rights reserved.

The Location Of The Business Rules
Web Application
Server Server DB
There are no business rules

There are no business rules in the database (i.e., no
on the Web Server stored procedures or
PL/SQL)
All business rules on the UI tier are

This is where youll find all of the
redundant (e.g., a dropdown that
business rules and all of the
contains valid choices is not a
database access
substitute for a backend business rule
that checks the user's choice is valid)

This Course Describes Each Tier's
Configuration Tools and Design Patterns
Web Application
Server Server DB
We wont have time to describe how

We start by explaining the
to create a highly configurable user
database design patterns
experience using portals, zones, UI
espoused by our designs
maps, and business process scripts
We then describe the highly configurable

business objects that manage the backend
business rules and logical data structures

Maintenance Objects

MO Definition
Most objects are made up of several tables

We use the term maintenance object (MO) to reference
the group of tables that hold an object's physical data
The person
Person maintenance object's
data is held in several
Person tables
CI_PER
Person / Person /
Person ID Person / ID Phone Type
CI_ID_TYPE CI_PER_ID Name Phone CI_PHONE_TYPE
CI_PER_NAME CI_PER_PHONE
Name Type
CI_LOOKUP_FIELD

Why MO's?
We don't like logical processing to communicate directly with tables

Rather, we prefer logic to "send messages" to a maintenance object (e.g., read a person, add a
person, change a person, etc.) and then the MO can determine how to satisfy the request
You will find that messages are sent to MO's via an XML document and that the MO will publish an
XML document in response
Person To reiterate most of your

logic will work with MO's,
Person not with individual tables
CI_PER
Person / Person /
Person / ID
CI_PER_ID Name Phone
CI_PER_NAME CI_PER_PHONE

XML Extensions Via CLOBs
Many tables have a CLOB column that holds an XML

document
This XML document holds attributes that are not required
by joins or ad hoc reports
We use the following diagramming technique to highlight
these tables
This means that the person table has a

Person "character large object" column that holds
an XML document (the XML document will
XML
only hold data if business objects have
been configured more about this later)

MO Extensions Via 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 MO's user-defined fields
In other words, most MO's can have an unlimited number of
characteristics
Premise / Char
Premise
Char Type
An implementation
can set up an
unlimited number of
user-defined fields for
their premises (here's
an example of a
premise with 6 chars)

MO's Encapsulate Core Business Rules
When an MO is created, we design both its physical

tables and its core business rules (e.g., validation)
These core business rules can be extended by an
implementation team
Note well:
You cannot change or remove core business rules, you can only
add to them
1 - 10 Copyright 2009, Oracle. All rights reserved.

Data Ownership

Owning Meta-data
The meta-data is an integral part of every product

Much of this meta-data is interpreted at execution time
and is therefore shipped with our products
We don't want implementations to change this meta-data
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
MO's) 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 meta-data tables
have a column called owner flag

Owner Flag Is Ubiquitous
The owner flag is a column on a table that references the

"product" that owns it
MO
Field Owner Flag Table
Char Type

You've only been exposed to a small percentage of
the tables that have "owned" meta-data


Business Objects

Business Objects Are Logical Views of Maintenance Objects
MOs are abstract to handle disparate
requirements (for example, the Person object Business objects are not abstract, notice
doesnt have a column called "daytime phone") how each has specific elements
Person Maintenance Object (MO)

Individual Taxpayer
Legal name
Person
ID (e.g. drivers license)
Person Busines Birth date Commercial Customer
Char
s Spouse Name
Person Objects Tax ID
Name Person Id
Person Number of dependents
Daytime phone Primary SIC code
Phone

Evening phone Accounting phone nbr
Id Type Phone Type Char Type Mailing address Service phone nbr
Mailing address
Credit issues address
They closely represent the business
They are easy to access using the configuration tools (i.e.,
you can easily add, change, delete and read BOs)
They are true subclasses of the MO and therefore take advantage of the
rich, safe, and sophisticated business rules embodied in the base-package
MOs

Foreshadowing Other Reasons To Use BO's
BO's are much more than visual definitions of objects;

you'll soon find out that you can:
Introduce BO-specific business rules without coding in Java
Populate and retrieve effective-dated attributes without
complicated joins to effective-dated table
Set up default values for BO attributes
Hide base-package attributes that must be populated but aren't of
interest to a customer
Extend objects without the need for new tables and columns
Enable the generation of HTML that reflects each element's data
type
Allow external systems to communicate with our system in a more
natural way (rather than in a 3rd normal form way)
And much more

BO Elements and Validation Rules

A BOs Elements Are Defined In Their Schema

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 meta-
data
<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)

Validation Rules
You'd plug-in a validation algorithm on a BO if you need more
sophisticated validation than can be defined using the schema
attributes
Notice how your validation algorithms are executed after the MO
processing (e.g., core validation rules)
BO k e
vo
In
Individual Taxpayer
Enter Exit
M oke
v
O
Person MO
In
3. Validation algorithms
2. MO Processing (Service)

To Create A New Algorithm, Follow These Steps
1. Write your logic (in Java or Scripting)

2. Create an algorithm type that references your program or script
3. Create an algorithm that references your algorithm type
4. Plug the algorithm in on the BO
There's a wizard that sets up the above with 1 click (but it won't write your
logic)
Program- 1
ming
Business
Language
Object
3 2
Algorithm
4 Algorithm
BO Type
Algorithm

Other Types Of BO Rules
Pre-processing rules are triggered from the BO layer only
Other rules are triggered from the MO layer
Whether called via a business object or directly
Therefore, the MO needs to determine the processed
instances BO before executing its rules
BO ke
vo
In
Individual Taxpayer
1. Pre-processing rules Enter Exit
M oke
5. Audit rules
v
O
Person MO
In
(Service) 4. Post-processing rules
3. Validation rules
2. MO Processing

BO Hierarchies

Reuse Scenario Post Processing Rule
Let's assume that whenever a new customer is added, we want to

send a "welcome letter", regardless of the type of customer
You've learned you can do this by setting up a post processing
algorithm and then plug it in on all relevant BO's
However, some object-oriented adherents might argue this is
redundant
BO: HumanCustomer BO: BusinessCustomer

lastName businessName
firstName employerIdentityNbr
driversLicense

Post Processing: Send Post Processing: Send
welcome letter on add welcome letter on add

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
A post processing rule
defined on a parent BO
Parent BO: GenericCustomer applies to all of its
children
Post Processing: Send
welcome letter on add

driversLicense


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

BO, the parent's rules
automatically apply (no Post Processing: Send
compilation it's immediate) welcome letter on add

driversLicense


Grandchildren and Great Grandchildren and
A child BO can have children (and so on)
Parent BO: GenericCustomer

Post Processing: Send
welcome letter on add
BO: HumanCustomer
lastName BO: BusinessCustomer
firstName Post Processing: Check
driversLicense credit history

BO: CorporateCustomer BO: PartnershipCustomer

When this type of customer is

When these types of customers are added, a welcome
added, only a welcome letter is
letter is sent and their credit history is checked
sent

Inheritance and Ownership

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: Customer You can only modify this BO's

schema if the owner flag on the
Owner: C1 (Base) installation record is C1 (and
typically only the base-package team
<name ... /> will have such an installation record)
<customerId ... />
...

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
BO: Customer included BO must be the
parent; this is not true. You
Owner: C1 (Base)
can include a BO in any
<name ... /> other BO (but avoid
<customerId ... /> recursion!)
...
This shows how a "CM" BO: MyCustomer

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

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
Post Processing: Send add another post-processing
welcome letter on add algorithm to this BO that's
owned by the base-
package
BO: HumanCustomer
lastName BO: BusinessCustomer
firstName Post Processing: Check
driversLicense credit history

BO: CorporateCustomer BO: PartnershipCustomer


You Can Add Algorithms To BO's You Don't Own
You can add algorithms to BO: GenericCustomer

BO's you don't own
Owner: C1 (Base)
Owner: C1 (Base)
Post Processing: Send welcome letter on add
BO: BusinessCustomer
Notice the 2nd algorithm's owner
flag (CM) differs from the owner of
the BO (C1) Owner: C1 (Base)
Owner: C1 (Base)
We did this so you could add Post Processing: Check credit history
additional validation / processing
without having to create a child BO
Owner: CM (Customer)
Post Processing: Create To Do entry

Foreshadowing: Disabling Base-Package Algorithms
While you cannot remove a base-package algorithm from a BO;

there is a way to tell the framework to not execute it
You do this by using a BO option
We only talk about options in chapter 8 so you'll have to wait until then
until you learn the technique
For now, just accept that you can inactivate a base-package algorithm
BO: BusinessCustomer
Owner: C1 (Base)
Owner: C1 (Base)
Post Processing: Check credit history
Sequence: 10
Owner: CM (Customer) There is a way that you can tell the

Post Processing: Create To Do entry base-package to not execute this
Sequence: 15 algorithm

Business Object Lifecycle

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
Lodged
Sent
Preliminary
Follow Up
Investigation
Not Interested
Rejected
Refer To Investigation
Salesperson Canceled In Progress
Decision

Checkpoint
Cancel / Rebill
Approved

State-Specific Rules
In an earlier chapter, 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

State Transition Rules
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
Enter
Exit
Error Canceled
Exit algorithms execute when an object Enter algorithms execute before the
attempts to leave a state (and errors roll BO enters a state (and errors roll
back to the prior state) back to the prior state)

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 You have the same programming palette
as before (Scripting, Java, Cobol)
Valid
Status Algorithm
Algorithm
Type
Valid Values:
BO / State / System Enter
Algorithm Event Exit
and one more
This allows you to define plug-

ins for individual states under a
BO

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 Valid Values:
BO / System Pre processing
Algorithm Event Validation
Post processing
Valid
Status
Valid Values:
Algorithm Event Exit
and one more

Inheriting Lifecycle

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 BO: RemoveMeter BO: ReadMeter

Pending
Pending
Canceled Pending
Canceled
Canceled
Dispatched
Dispatched
Dispatched
Complete
Complete
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 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
Complete topmost BO in the hierarchy
BO: InstallMeter BO: ReadMeter
BO: InstallComplexMeter 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 BO: InvestiSvcTheft BO: ReadMeter

Status: Complete
System Event: Enter Only states defined on the
Algorithm: Create topmost parent BO can be
Installation Charge referenced

Check Point

Algorithm System Event Summary ERD
MO
Valid Values:
Info
MO / System
Transition
Algorithm Event Transition Error
Determine BO
BO Valid Values:
Validation
Algorithm Pre Processing
Post Processing
BO / System Audit
Algorithm Event Info
some designs
introduce these
Valid
Status
Valid Values:
Exit
Algorithm Event Monitor

Algorithm Execution Summary
BO k e
vo
Individual Taxpayer
In
Enter Exit
1. Pre-processing rules
M oke
8. Audit rules (BO)
v
O
In Person MO 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)
2. Determine status field.
otherwise, return the error
If changed proceed with
old value (Keep new > Monitor (new status)
value for later) > If monitoring, repeat #6
3. MO Processing 5. Validation rules (BO)
4. Determine BO (MO)

Business Object Access Rights

Business Objects Are Secured
When you link a business object to an application service, you are granting all
users in the group access to its instances
You can prevent users from transitioning a BO into specific states by correlating
each BO status with each application service action (and then don't give the user
group rights to the related action)
Application
BO User Group User
Service
User Group / User Group /

Valid Status Valid Action
App Svc User (Edate)
The users user group must have Permissible

access rights to the action in order Action
to transition the BO into this state

When Are Access Rights Checked?
The framework checks if a user has access rights each time the app server is
invoked to add, change, delete, read, or transition a BO
However, if a BO invokes another BO, we assume that access was controlled by the
initial BO invocation and we do NOT check access for other BO's that it invokes
In other words, access rights are only checked for the initial BO invoked in a service
call
Web Application
Server Server DB
For example, if a service call adds a BO which has a post processing

algorithm that adds a different BO (e.g., a To Do entry), access rights
are only checked for the initial BO invoked by the client


Very Brief Overview of Chapters 4 Through 9

Uploaded by

Document Information

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

Very Brief Overview of Chapters 4 Through 9

Uploaded by

Copyright:

Available Formats

Overview

Historically, we developed products that required a lot of

1-1 Copyright 2009, Oracle. All rights reserved.

Copyright 2009, Oracle. All rights reserved.

There are no business rules

All business rules on the UI tier are

1-3 Copyright 2009, Oracle. All rights reserved.

We wont have time to describe how

We then describe the highly configurable

1-4 Copyright 2009, Oracle. All rights reserved.

Copyright 2009, Oracle. All rights reserved.

Most objects are made up of several tables

1-6 Copyright 2009, Oracle. All rights reserved.

We don't like logical processing to communicate directly with tables

Person To reiterate most of your

1-7 Copyright 2009, Oracle. All rights reserved.

Many tables have a CLOB column that holds an XML

This means that the person table has a

1-8 Copyright 2009, Oracle. All rights reserved.

We use the term characteristic rather than user-defined field

1-9 Copyright 2009, Oracle. All rights reserved.

When an MO is created, we design both its physical

1 - 10 Copyright 2009, Oracle. All rights reserved.

Copyright 2009, Oracle. All rights reserved.

The meta-data is an integral part of every product

1 - 12 Copyright 2009, Oracle. All rights reserved.

The owner flag is a column on a table that references the

Field Owner Flag Table

1 - 13 Copyright 2009, Oracle. All rights reserved.

Copyright 2009, Oracle. All rights reserved.

Person Maintenance Object (MO)

1 - 15 Copyright 2009, Oracle. All rights reserved.

BO's are much more than visual definitions of objects;

1 - 16 Copyright 2009, Oracle. All rights reserved.

Copyright 2009, Oracle. All rights reserved.

1 - 18 Copyright 2009, Oracle. All rights reserved.

<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

1 - 19 Copyright 2009, Oracle. All rights reserved.

1 - 20 Copyright 2009, Oracle. All rights reserved.

1. Write your logic (in Java or Scripting)

1 - 21 Copyright 2009, Oracle. All rights reserved.

(Service) 4. Post-processing rules

1 - 22 Copyright 2009, Oracle. All rights reserved.

Copyright 2009, Oracle. All rights reserved.

Let's assume that whenever a new customer is added, we want to

BO: HumanCustomer BO: BusinessCustomer

1 - 24 Copyright 2009, Oracle. All rights reserved.

You can define parent BO's in the meta-data

BO: HumanCustomer BO: BusinessCustomer

1 - 25 Copyright 2009, Oracle. All rights reserved.

If a BO references a parent Parent BO: GenericCustomer

BO: HumanCustomer BO: BusinessCustomer

1 - 26 Copyright 2009, Oracle. All rights reserved.

Parent BO: GenericCustomer

BO: CorporateCustomer BO: PartnershipCustomer

When this type of customer is

1 - 27 Copyright 2009, Oracle. All rights reserved.

Copyright 2009, Oracle. All rights reserved.

BO: Customer You can only modify this BO's

1 - 29 Copyright 2009, Oracle. All rights reserved.

While you can't change the schema of a BO that your

This shows how a "CM" BO: MyCustomer