07 BO Lifecycle

7
Business Object Lifecycle
Copyright 2009, Oracle. All rights reserved.
Check Point
You know how to:
Define a BO's data structure (i.e., its schema)
Create plug-ins for a BO
Create a child BO that inherits rules defined on a parent BO
In this section, you'll learn how to control the various

stages of a BO's lifecycle
7-2
Hard versus Soft Lifecycle
Hard vs. Soft MO's

Many MO's have a column that holds their current status
An object's status controls a great deal of behavior
Rules that govern an MO's status (e.g., what is its initial state, when can
it transition to another state, etc.) are defined in 2 different ways:
For older MO's, the rules have been hard coded in the MO (in Java or Cobol)
For new MO's, the rules exist in the BO meta-data; we refer to these as soft
Literature Request BO Lifecycle
ToDo Entry MO Lifecycle
Literature
Sent
Open
Being Worked
On
Follow Up
Complete
Not Interested
ToDo Entry is an older MO

and therefore the state
transition rules are coded
by a programmer
7-4
Refer To
Salesperson
This is an example of a
BO whose MO supports
"soft state transition rules"
These rules have been
entered in the BO metadata (i.e., they have not
been hard-coded by a
programmer)
This Section Is About Soft MO's

Some MO's don't have a status column; we refer to these as simple MO's
These tend to be simple administration objects (and some older MO's)
The remainder of this section describes techniques that can only be

used by MO's designed to support a soft lifecycle
In other words, this chapter is NOT relevant to hard and simple MO's

Literature
Sent
The upcoming slides will

describe the BO lifecycle
meta-data
Follow Up
Not Interested
Refer To
Salesperson
7-5
Valid Statuses Are In Meta-Data (not in program logic)
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
7-7
Rejected
BO Status ERD
BO's associated with soft lifecycle MO's have their valid
statuses defined in the BO meta-data
One status must be marked as
Initial and there must be at least
one state marked as Final
Values:
Initial
Interim
Final
Business
Object
Notice how each state

is defined in the Valid
Status meta-data
Valid
Status
Condition

Literature
Sent
Valid State
Description
Condition
LS
Literature Sent
Initial
FU
Follow Up
Interim
NI
Not Interested
Final
RTS
Refer To Salesperson
Interim
Follow Up
Not Interested
Refer To
Salesperson
7-8
BO Lifecycle Transition Rules ERD

In addition to defining the valid states, you must also
define the state transition rules
Business
Object
Valid
Status
From
Notice how each from / to

combination is defined in the
Transition Rule meta-data

Literature
Sent
To
Follow Up
Transition
Rule
7-9
From State
To State
Literature Sent
Follow Up
Follow Up
Not Interested
Follow Up
Not Interested
Refer To
Salesperson
State Specific Rules
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 plugins 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
7 - 11
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,
Exit
Error
Exit algorithms execute when an object

attempts to leave a state (and errors roll
back to the prior state)
7 - 12
Enter
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)
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
and one more
This allows you to define plugins for individual states under a

BO
7 - 13
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
7 - 14
System
Event
Valid Values:
Pre processing
Validation
Post processing
Valid Values:
Enter
Exit
and one more
Team Walk Through (30 minutes)

Examine a BOs lifecycle
7 - 15
Break up into teams and follow the instructions in the workbook
Monitor Rules
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
7 - 17
Another BO / Status Plug-In Spot

Monitor algorithm(s) are plugged in on the BO / Status that they monitor
The previous slide's example would result in a monitor algorithm being
plugged in on the Error state
Because you want to monitor the BO while it's in the Error state
Business
Object
Error
Monitor
Canceled
Valid
Status
Algorithm
BO / State /
Algorithm
7 - 18
System
Event
Algorithm
Type
Valid Values:
Enter
Exit
Monitor
When Are Monitor Algorithms Invoked?

Monitor algorithms are invoked when a BO first enters a state and periodically after
that
Note - we'll qualify the above statement in a few slides as it's not 100% true
In the example below, a monitoring algorithm is associated with the Pending state of
a Credit Line Increase BO
This algorithm is designed to move the object to the Accepted state if a credit rating
verification is returned with a good rating, and to the Denied state if the credit rating
is not adequate
If the credit rating verification is not received, the BO remains in the Pending state
BO: CreditLineIncrease
Pending
Denied
Monitor
This plug-in will be invoked when the object is
first created. If the monitoring condition doesn't
apply when the object if first created, a batch
process will periodically invoke the plug-in (i.e.,
this algorithm is invoked when the object first
enters the state and also periodically in batch)
7 - 19
Accepted
Monitor Algorithms Can Do Several Things

A monitor algorithm can retrieve / update anything it pleases
It can also tell the framework to do the following:
Keep checking other monitoring algorithms plugged in on the BO / Status before transitioning
We design algorithms to do this when we want an action performed while a BO is in a state, but we don't want to
transition it (e.g., updating statistics)
Transition the BO to another state note, if there are other monitoring algorithms plugged in on the state,
they will NOT be checked
So it's important to think carefully about the sequence number allocated to this type of algorithm when it's plugged in
Stop monitoring the BO (i.e., tell the framework not to transition the BO and to not call any other monitor
algorithms plugged in on the BO / Status)
We design algorithms to do this when we want to prevent transitions while some condition is true
Pending
Denied
Monitor
Accepted
7 - 20
Multiple Conditions
Assume that the Pending object should only be transitioned to Accepted if two conditions are true:
1) we've received a good credit rating back from the credit agency, and
2) at least 3 days have passed since the request was created
You could bundle both conditions into a single monitoring plug-in; alternatively, you could create 3
Monitor 1: Check if the credit rating agency has returned a response,
Monitor 2: Check if at least 3 days have past
If no, Stop Monitoring

If yes:
If good credit rating, Keep Checking
If bad, Transition to Denied

If no, Stop Monitoring
If yes, Keep checking
Monitor 3: Transition to Accepted
Atomizing algorithms allows for easier maintenance and reuse
Pending
Denied
Monitor
Accepted
7 - 21
Monitor Exits and Enters

If a monitor algorithm says to transition, any Exit
algorithms on the current state are executed, and then any
Enters on the new state are executed
We'll discuss what happens if an error takes place during these
algorithms later
7 - 22
Monitor
Exit
Pending
Enter
Denied
Enter
Accepted
Monitor Cascading Transitions

Consider what happens when the Pending monitoring algorithm says it's time to
move to the Denied state
Remember, we indicated on the previous slide that monitoring algorithms are invoked
when a BO first enters a state
In the following example, the Denied state also has monitoring algorithms and
these will be invoked when the Denied state is entered
The Denied monitoring algorithms could, in turn, transition the BO to another
state (and then this state's monitoring algorithms will fire)
Ad infinitum
7 - 23
Monitor
Exit
Pending
Enter
4
5
Denied
Monitor
Monitor
Retry Later
Difficult Concept Save Points

Warning this following is a difficult concept
By default, any error produced by subsequent Enter, Exit or Monitor
algorithms rolls back ALL changes and transitions back to the BO's original
state
When applicable, the MO can be configured to always keep an entity in its
last successful state rather than rolling all the way back to the original state
In case of an error, the entity is rolled back to the last save point and the error is
logged on the MOs Log
Notice that the call is considered successful, no error is returned (it's just logged)!
If this plug-in throws an error, the
object will persist in the Denied
state rather than rolling back to
Pending
7 - 24
4
5
Denied
Monitor
Monitor
Enter
Monitor
Exit
Pending
Enter
Retry Later
Difficult Concept Save Points (continued)

A Transition Error plug-in on the MO tells the system that the save
point handling is needed
The plug-in is responsible for logging the exception on the MO log (more
about the log a little later)
If this plug-in is not specified and an error is thrown, the object will be
rolled back to its state before the start of the logical transaction
Your MO designs will specifically call for such a plug-in if it's needed
MO
MO /
Algorithm
7 - 25
System
Event
Valid Values:
Info
Transition Error
Determine BO
plus a few more
2 Ways To Execute Monitor Plug-ins
Periodic Monitoring Happens In Batch

We indicated on an earlier slide that monitoring algorithms
are invoked when a BO first enters a state AND
periodically thereafter
This periodic monitoring is performed by a batch process
Whenever a MO that supports soft transition is created, a
corresponding "monitoring" batch control is also created (this is
not a new program, it's just meta-data that allows the customer to
schedule the monitoring at their discretion)
The frequency of "polling" is up to the customer's batch

scheduler and the frequency of execution
7 - 27
Batch Controls Are Not New Programs

If you look at an MO that has a status, you'll see an option (we'll talk
about options in the next chapter) that defines its periodic monitoring
This is defined using an MO option
batch process
Batch
Control
When the batch job runs, it executes the
monitoring algorithms on BO's linked to the MO
that are in a state that has monitoring
algorithms
MO
BO
Valid
Status
BO /
Status /
Algorithm
7 - 28
System
Event
Valid Values:
Enter
Exit
Monitor
Another Option - Deferred Monitoring

The last slides didn't tell the entire story
Some designs do NOT want the monitoring to be executed when a BO
enters a state; rather, these types of designs want to defer the
monitoring until a batch job runs
Some classic requirements that necessitate this type of design:
In a market messaging world, once a day, you send messages to all players
in the market describing changes to basic customer information that have
occurred during the last 24 hours
For example, if a customer's name is changed at 9 am, and then their phone
number is changed at 10 am, and then their name is changed back to how it looked
before to the 9 am change, the summary message will just contain information
describing that their phone number changed
Another example from market messaging is that you don't want an inbound
message processed when it's received; rather, you want to wait until a later
point in time (maybe at the end of the day)
You'll learn another example later in this course when we describe how
statistics can be periodically updated while an object is in a given state

7 - 29
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
7 - 30
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
The End Of Day Example

An instance of this object is created when a
customer's information is changed and there
does not already exist a Pending object for the
customer
BO: OnceADayAudit
Status: Pending
Monitoring Batch Process: C1-MON-AUD
System Event: Enter
Algorithm: Snapshot Customer Information
System Event: Monitor
Algorithm: Transition to Sent
When an instance of this BO is created, this

plug-in takes a snapshot of the customer's
information before the change
Because a Monitoring Process is specified on
the state, the monitor algorithm will only be
invoked when this batch process executes (the
algorithm itself is trivial it just transitions the
object to the Sent state)
Status: Sent
System Event: Enter
Algorithm: Send Customer Change To Market
Participants
7 - 31
This status has a monitoring process so its

monitoring algorithms will only be checked in
batch
This algorithm compares the customer's

snapshot with the customer's current
information. If there are differences, it composes
a message describing all differences and then
sends it to the market participants
Batch Controls For Post 2.2 MO's With Status

Whenever we create a new MO that has
a status column, we set up batch
controls in the meta-data
One is called the Periodic monitor
This is the one that invokes monitor
algorithm on BO states that do not
reference a monitor process
The other is called the Deferred monitor

This is the one that should be referenced
on BO / States whose monitoring should
only be done in batch
We don't always ship this one
Remember, if a batch job is referenced

on a state, this state is classified as a
"deferred monitoring" state and
monitoring algorithms will only be
invoked by this batch job
Business
Object
Valid
Status
BO /
Status /
Algorithm
Batch
Control
System
Event
Valid Values:
Enter
Exit
Monitor
7 - 32
Case Study
Assume high-bill complaints are added
in a web self service app in the Lodged
state and an implementation only
wants to move them into the
Preliminary Investigation state (where
an investigator is assigned) in the
evening so that the entire new
workload can be considered when
making the assignment
To do this:
High Bill Complaint Lifecycle

Lodged
Preliminary
Investigation
Canceled
Set up the Lodged state with a monitor

plug-in that transitions the BO to the
Preliminary Investigation state
Reference the BO's deferred monitoring
batch control on the Lodged state
Schedule the deferred monitoring batch
control to run in the evenings
7 - 33
Investigation
In Progress
Decision
Checkpoint
Cancel / Rebill
Approved
Rejected
Transitory States
Enter Initiated Auto-Transition

Some designs call for transitory states
This is a state that exists purely to hold rules; objects will never persist in this state
The classic example is:

The BO can be saved in an unvalidated, Pending state
At some point, the user is ready to submit the BO for validation and transitions it into a transitory state whose Enter rules
contain the validation logic
The transitory state's Enter algorithm(s) decide if the object is OK or in Error and then transition it into the appropriate
final state
In this case, the Enter plug-in performs the transition

This means that both Monitor AND Enter plug-ins can transition to other states
Error
Pending
Enter
Validate
This is a transitory state

7 - 35
Complete
Transitory State ERD

Transitory states are defined in the BO meta data
The framework will not allow a BO to persist in a transitory state
Business
Object
Values:
No
Yes
Notice the values of

the transitory flag
Valid
Status
Transitory
Valid State
Description
Transitory
Pending
No
Validate
Yes
Error
No
OK
OK
No
7 - 36

Pending
Validate
Error
OK
7
MO Logs
Introducing Logs
Most new MO's that have a status column have a log
Note, there are some simple admin MO's that have a status and
don't have a log (this is done to save development time)
The log holds significant events in the BO's lifecycle

For example, log entries are created to record:
When the MO / BO is created (and who created it)
When the status changes (and who changed it)
If a transition error occurred (and the error message) (we discussed
transition errors that occur after a save point earlier in this section)
References to other objects created during the MO / BO's lifecycle.
For example, if a BO creates a To Do entry, the To Do's FK is kept in
the log
Manual entries added by a user (think of these as "diary" entries)
7 - 38
MO Log ERD
Values:
Created
Status Transition
System
User Details
Status Transition Error
Exception
product-specific values
This pair of log entries is
created by the MO's
Transition Error plug-in (as
explained during the earlier
"save point" discussion). The
first records the state in which
the error occurred, the second
records the actual error.
Remember, this plug-in is
optional, if it's not there, these
log entries won't be created
and there won't be save
points.
7 - 39
"MO"
Log Type
Optional. Typically used

when a log entry
records the ID of an
ancillary object that was
created.
Char Type
Log
Message
User ID
Message
Parm
Optional. Used to describe the

log entry (all system-generated
entries will have a message,
only manual entries don't have
a message number)
Logs Are An Extract Source

You probably don't know about the various Business
Intelligence products and their star schemas
However, if the MO has a corollary star "state change
history" star schema in BI, the state-change log entries
are used to populate this star schema
This star schema is used to analyze how long BO's exist in the
various states (a very important measure for most managers)
7 - 40
7
Just In Case
If You Want Control Of The Logs

The log entries that are created when a BO is added and when its
status changes are automatically created by the framework
If you don't want these entries (or want alternative versions), you can
plug an algorithm in on the MO
If the FW sees that a BO's MO has such an algorithm, it will NOT
create these log entries
Rather, it assumes that your plug-in is going to take this responsibility
This plug-in can also be used to introduce MO-wide logic that needs
to happen whenever an MO is added or its status changes
BO
7 - 42
MO
Algorithm
MO /
Algorithm
System
Event
Valid Values:
Transition
(and a few 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
Pending
Canceled
Dispatched
Complete
7 - 44
Pending
Canceled
BO: ReadMeter
Pending
Dispatched
Complete
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
7 - 45
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
7 - 46
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
Pending
Canceled
Dispatched
Complete
BO: InstallMeter
Status: Complete
System Event: Enter
Algorithm: Create
Installation Charge
7 - 47
BO: InvestiSvcTheft
BO: ReadMeter
Only states defined on the

topmost parent BO can be
referenced
Multi's Are Top Down

Recall that plug-in spots that support multiple algorithms are executed from
top down (i.e., algorithms on parent BO's are done first)
Enter, exit and monitor are all multi spots
BO
BO /
Algorithm
System
Event
Valid Values:
Validation
Pre Processing
Post Processing
Audit
Info
Valid
Status
BO / State /
Algorithm
7 - 48
System
Event
Valid Values:
Enter
Exit
Monitor
Info plug-ins are the only

base-package "single" spot
(remember, the FW will
execute one algorithm in a
BO hierarchy if the system
event is a "single" and it will
execute the algorithm
"closest" to the BO being
processed)
Only The Topmost BO Can Have A Monitoring Process

You can only define a monitoring batch process at the topmost level in a BO
hierarchy
But remember, when you schedule the job, you can restrict it to a specific child BO

Pending
Monitoring Batch Process: C1-MON-AUD
Dispatched
Canceled
Complete
BO: InstallMeter
7 - 49
BO: InvestiSvcTheft
BO: ReadMeter

Examine BO inheritance of a lifecycle
7 - 50

Add simple validation to a new child BO
Before you start adding any meta-data, please check the
answer in your workbook and ask your instructor to clarify
anything you don't understand
7 - 51
7
Check Point
Algorithm System Event Summary ERD

MO
MO /
Algorithm
System
Event
BO
Algorithm
BO /
Algorithm
System
Event
Valid
Status
BO / State /
Algorithm
7 - 53
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
We'd like to repeat if the MO

associated with the BO does not
have a Determine BO plug-in, no
BO-oriented plug-ins will be
executed (this is because the MO
invokes these plug-ins)
2. Determine status field.

If changed proceed with
old value (Keep new
value for later)
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)
3. MO Processing
4. Determine BO (MO)
7 - 54
Review Questions
7 - 55
7 - 56

07 BO Lifecycle

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

07 BO Lifecycle

Hochgeladen von

Copyright:

Verfügbare Formate

7

Business Object Lifecycle

Copyright 2009, Oracle. All rights reserved.

In this section, you'll learn how to control the various

Copyright 2009, Oracle. All rights reserved.

Hard versus Soft Lifecycle

Copyright 2009, Oracle. All rights reserved.

Hard vs. Soft MO's

ToDo Entry MO Lifecycle

ToDo Entry is an older MO

Copyright 2009, Oracle. All rights reserved.

This Section Is About Soft MO's

The remainder of this section describes techniques that can only be

Literature Request BO Lifecycle

The upcoming slides will

Copyright 2009, Oracle. All rights reserved.

Valid Statuses Are In Meta-Data (not in program logic)

Copyright 2009, Oracle. All rights reserved.

Each BO Can Have A Different Lifecycle

High Bill Complaint Lifecycle

Copyright 2009, Oracle. All rights reserved.

Notice how each state

Literature Request BO Lifecycle

Copyright 2009, Oracle. All rights reserved.

BO Lifecycle Transition Rules ERD

Notice how each from / to

Literature Request BO Lifecycle

Copyright 2009, Oracle. All rights reserved.

State Specific Rules

Copyright 2009, Oracle. All rights reserved.

But what if you need to perform validation that only

Copyright 2009, Oracle. All rights reserved.

State Transition Rules

Exit algorithms execute when an object

You could develop an algorithm that requires a cancellation reason

Copyright 2009, Oracle. All rights reserved.

State-Specific BO Rules ERD

You have the same programming palette

This allows you to define plugins for individual states under a

Copyright 2009, Oracle. All rights reserved.

BO Rules vs. BO State Rules

Copyright 2009, Oracle. All rights reserved.

Team Walk Through (30 minutes)

Break up into teams and follow the instructions in the workbook

Copyright 2009, Oracle. All rights reserved.

Copyright 2009, Oracle. All rights reserved.

Monitor (State Monitoring) Rules

Copyright 2009, Oracle. All rights reserved.

Another BO / Status Plug-In Spot

Copyright 2009, Oracle. All rights reserved.

When Are Monitor Algorithms Invoked?

Copyright 2009, Oracle. All rights reserved.

Monitor Algorithms Can Do Several Things

Copyright 2009, Oracle. All rights reserved.

Monitor 1: Check if the credit rating agency has returned a response,

Monitor 2: Check if at least 3 days have past

If no, Stop Monitoring

If good credit rating, Keep Checking

If bad, Transition to Denied

Monitor 3: Transition to Accepted

Atomizing algorithms allows for easier maintenance and reuse

Copyright 2009, Oracle. All rights reserved.

Monitor Exits and Enters

Copyright 2009, Oracle. All rights reserved.