6

BO Inheritance

Copyright 2010, Oracle. All rights reserved.

 Check Point

You know how to:

Define a BO's data structure (i.e., its schema)
Create plug-ins that hold the BO's more sophisticated
business rules
In this section, you'll learn additional techniques to avoid
redundant logic
Note - additional reuse techniques will be explained in later
chapters

6-2 Copyright 2010, Oracle. All rights reserved.

 6
Refresher: Stand Alone Data Areas

Copyright 2010, Oracle. All rights reserved.

 Including Stand Alone Data Areas
You've already learned how you can include stand alone data area schemas in
multiple BO's
Form1040a BO Schema

<formType mapField="CASE_TYPE_CD"
StandardTaxpayerElements Standalone Schema default="1040a.07" />

<standardTaxpayerElements type="group" <includeDA name="StandardTaxpayerElements"/>

mapXML="BO_DEFN_AREA">
<ssn required="true" /> <1040page1 type="group" mapXML="BO_DEFN_AREA">
<lastName required="true" /> <line1 dataType="number"/>
<firstName /> <line2 dataType="number"/>
<address1 /> <1040page1/>
<address2 />
...
Form1040ez BO Schema
</standardTaxpayerElements>
<formType mapField="CASE_TYPE_CD"
Both of the BO's include the stand default="1040ez.07" />
alone schema's data structure and
<includeDA name="StandardTaxpayerElements"/>
element rules
<1040ezpage1 type="group" mapXML="BO_DEFN_AREA">
You can now maintain this data <line1 dataType="number"/>
structure in one place rather than in <line2 dataType="number"/>
<1040ezpage1/>
each of the BO's

6-4 Copyright 2010, Oracle. All rights reserved.

 6
Refresher: Reuse Using Plug-ins

Copyright 2010, Oracle. All rights reserved.

 Using Algorithms To Avoid Redundant Logic
You've already learned how you can plug-in an algorithm on many
different BO's
This is a fine technique to avoid redundant logic

Business Algorithm
Algorithm Remember - the
Object Type
program type and
program name are
defined here
Valid Values:
BO / System Validation
Pre-processing
Algorithm Event
Post-processing
Audit
Information
Any bug fix / enhancement will
automatically apply to all BO's
that reference the algorithm type's
algorithms

6-6 Copyright 2010, Oracle. All rights reserved.

 6
Reuse Using Inheritance

Copyright 2010, Oracle. All rights reserved.

 Reuse Scenario Post Processing Rule

Let's assume that whenever a new customer is added, a "welcome

letter" is sent, 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

6-8 Copyright 2010, Oracle. All rights reserved.

 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

BO: HumanCustomer BO: BusinessCustomer

lastName businessName
firstName employerIdentityNbr
driversLicense

6-9 Copyright 2010, Oracle. All rights reserved.

 Parent BO ERD
There's a FK on BO
that references a
A parent BO is simply a BO that is parent BO (this is
referenced by other BO's Business
optional)

Note, the parent and its children Object

must reference the same MO Algorithm

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

BO: HumanCustomer BO: BusinessCustomer

lastName businessName
firstName employerIdentityNbr
driversLicense

6 - 10 Copyright 2010, Oracle. All rights reserved.

 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

6 - 11 Copyright 2010, Oracle. All rights reserved.

 Refresher: Single versus Multi Spots

Recall that a BO can have > 1 algorithm plugged in for the

following system events:
Pre-processing
Post-processing
Validation
Audit
Recall that a BO can have only 1 algorithm plugged in for the
following system events:
Info
The next slides describe what happens when a given system
event has algorithms plugged in at different levels within a BO
hierarchy

6 - 12 Copyright 2010, Oracle. All rights reserved.

 Multi System Events Are "Top Down"

The framework executes all algorithms at all levels for multi system events
It executes algorithms on the highest level BO's first and then moves on to
lower levels

Parent BO: GenericCustomer

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

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

BO: CorporateCustomer BO: PartnershipCustomer

6 - 13 Copyright 2010, Oracle. All rights reserved.

 Single System Events Are "Find The Nearest"
The framework executes only one algorithm for single system events
If multiple such algorithms exist in the hierarchy, it executes the one at the level "nearest" to the BO in
question

Parent BO: GenericCustomer

Info: Include customer name

BO: HumanCustomer
BO: BusinessCustomer
We'd show the customer name Info: Include employer ID,
for this type of BO name and credit rating

We'd show the

employer ID, BO: CorporateCustomer BO: PartnershipCustomer
customer name and
credit rating for this Info: Include partnership name
type of BO We'd show the partnership name and credit rating and partnership
and credit rating and partnership date
date for this type of BO

6 - 14 Copyright 2010, Oracle. All rights reserved.

 6
Preventing Instantiation Of Parent BO's

Copyright 2010, Oracle. All rights reserved.

 Instantiable Flag

While it is good practice to not allow users to create instances of parent

BO's, the framework will not prevent it by default
Rather, you must tell the framework if instances of a BO aren't allowed (and
there's a flag on BO Main for this purpose)
Parent BO: GenericCustomer
Notice that we've set
Instantiable: No up this BO hierarchy
to indicate that only
non-abstract
business objects can
have instances
BO: HumanCustomer BO: BusinessCustomer created

Instantiable: Yes Instantiable: No

BO: CorporateCustomer BO: PartnershipCustomer

Instantiable: Yes Instantiable: Yes

6 - 16 Copyright 2010, Oracle. All rights reserved.

 6
Inheriting Data Structures

Copyright 2010, Oracle. All rights reserved.

 Note - Data Structures Are NOT Implicitly
Inherited
While you can declare schemas on parent BO's, they will NOT be inherited
by their children
The children must include their parent BO's schema if they want it
For OO adherents this means that the instance variables on the superclass
are not automatically inherited by the subclasses
Parent BO: GenericCustomer
<name ... />
<customerId ... />
...

BO: HumanCustomer BO: BusinessCustomer

<includeBO name="GenericCustomer" /> <includeBO name="GenericCustomer" />
<dateOfBirth ... /> <employerIdentityNumber ... />
<mothersMaidenName ... /> <marketingContact ... />
... ...

6 - 18 Copyright 2010, Oracle. All rights reserved.

 Warnings Are Issued

If you neglect to include an element that exists on a parent BO,

the framework will issue a warning when you edit a child BO

Parent BO: GenericCustomer

<name ... />
<customerId ... />
...

BO: HumanCustomer BO: BusinessCustomer

<includeBO name="GenericCustomer" />
<dateOfBirth ... /> <employerIdentityNumber ... />
<mothersMaidenName ... /> <marketingContact ... />
... ...

A warning will be issued for this BO

6 - 19 Copyright 2010, Oracle. All rights reserved.

 6
Inheritance and Ownership

Copyright 2010, Oracle. All rights reserved.

 Only The Owning Implementation Can Change A
BO's Schema
Refresher:
BO's are owned
The owning implementation is defined on the installation
record
You can't change a BO's schema whose owner flag differs
from the one on the installation record
BO: Customer You can only modify this BO's
schema if the owner flag on the
Owner: C1 (Base) installation record is C1 (and only
the product development team will
<name ... /> have such a setting)
<customerId ... />
...

6 - 21 Copyright 2010, Oracle. All rights reserved.

 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"
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 base-
package team, the implementation will get
them too (for better or for worse)
Foreshadowing - chapter 13
describes how an implementation
BO: MyCustomer can extend a base-package BO
using a stand-alone data area
Owner: CM (Customer)
<includeBO name="Customer" />
<employerIdentityNumber ... />
<marketingContact ... />
...

6 - 22 Copyright 2010, Oracle. All rights reserved.

 CM Algorithms on CM Objects

BO: Customer
Implementations can
Owner: C1 (Base)
obviously add algorithms to
their BO's <name ... />
<customerId ... />
...

BO: MyCustomer

Owner: CM (Customer)
<includeBO name="Customer" />
<employerIdentityNumber ... />
<marketingContact ... />
...

This shows a CM algorithm on a CM Owner: CM (Customer)

business object Validation: Check My Elements

6 - 23 Copyright 2010, Oracle. All rights reserved.

 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

6 - 24 Copyright 2010, Oracle. All rights reserved.

 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)
This is allowed so implementations Post Processing: Check credit history
can add validation / processing
without having to create a child BO
Owner: CM (Customer)
Post Processing: Create To Do entry

6 - 25 Copyright 2010, Oracle. All rights reserved.

 Algorithm Sequence
When you add an algorithm to a BO, you must define its sequence number
(this allows you to position your algorithms before or after other logic)
You must select a unique sequence
After an upgrade, it's possible for your algorithms to have the same
sequence number as a base-package algorithm
If this happens, an error will be issued at run time and you must
reassign the sequence number as there is no clear upgrade path for
duplicate sequences

BO: BusinessCustomer

Owner: C1 (Base) Business

Owner: C1 (Base)
Object
Post Processing: Check credit history
Sequence: 10 There is a sequence
number on this table
Owner: CM (Customer) BO / that controls the
order of execution
Post Processing: Create To Do entry Algorithm
Sequence: 15

6 - 26 Copyright 2010, Oracle. All rights reserved.

 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 Implementations can disable this
Sequence: 10 algorithm by adding a BO option (more
about options later)
Owner: CM (Customer)
Post Processing: Create To Do entry
Sequence: 15

6 - 27 Copyright 2010, Oracle. All rights reserved.

 6
Inheriting a Nightmare

Copyright 2010, Oracle. All rights reserved.

 Use Parent BO's Wisely
It's intellectually attractive to abstract behavior into parent BO's
(super classes) to avoid redundant logic and simplify maintenance
But before doing this, weigh the reuse benefits against the cost in
transparency
It's not easy to maintain a complex hierarchy of BO's
Most base-package architects avoid complex hierarchies as they are
typically only clear to the person who designed the hierarchy, i.e., the
perceived maintenance benefits are elusive
As a rule of thumb, we subject hierarchies with more than 2 layers to
intense peer review before implementing them

6 - 29 Copyright 2010, Oracle. All rights reserved.

 Team Walk Through (90 minutes)

Add simple validation to a new child BO

Break up into teams and follow the instructions in your
workbook

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

6 - 30 Copyright 2010, Oracle. All rights reserved.

 Walk Through Addendum

In real life, an implementation would never have to create a

child BO to add validation because an implementation team can
add their own Validation algorithm directly to the base-package
BO (and it will survive future upgrades)
This exercise was structured like this so as to avoid concurrency
issues

6 - 31 Copyright 2010, Oracle. All rights reserved.

 Review Questions

6 - 32 Copyright 2010, Oracle. All rights reserved.