06 BO Inheritance

6
BO Inheritance
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 that hold its more sophisticated business
rules
In this section, you'll learn additional techniques to avoid

redundant logic
Note - even more reuse techniques will be unveiled in later
chapters
6-2
Refresher: Stand Alone Data Areas
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
StandardTaxpayerElements Standalone Schema

<standardTaxpayerElements type="group"
mapXML="BO_DEFN_AREA">
<ssn required="true" />
<lastName required="true" />
<firstName />
<address1 />
<address2 />
...
</standardTaxpayerElements>
Both of the BO's include the stand

alone schema's data structure and
element rules
You can now maintain this data
structure in one place rather than in
each of the BO's
6-4
<formType mapField="CASE_TYPE_CD"
default="1040a.07" />
<includeDA name="StandardTaxpayerElements"/>
<1040page1 type="group" mapXML="BO_DEFN_AREA">
<line1 dataType="number"/>
<1040page1/>
Form1040ez BO Schema
<formType mapField="CASE_TYPE_CD"
default="1040ez.07" />
<includeDA name="StandardTaxpayerElements"/>
<1040ezpage1 type="group" mapXML="BO_DEFN_AREA">
<1040ezpage1/>
Refresher: Reuse Using Plug-ins
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
Object
BO /
Algorithm
Algorithm
System
Event
Algorithm
Type
Valid Values:
Validation
Pre-processing
Post-processing
Audit
Information
Any bug fix / enhancement will

automatically apply to all BO's
that reference the algorithm type's
algorithms
6-6
Remember - the
program type and
program name are
defined here
Reuse Using Inheritance
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
businessName
employerIdentityNbr

lastName
firstName
driversLicense
Post Processing: Send

welcome letter on add
6-8
BO: BusinessCustomer

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: GenericCustomer
BO: HumanCustomer
6-9
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
Business
Object
Algorithm
Note, the parent and its children

must reference the same MO
If a BO references a parent
BO, the parent's rules
automatically apply (no
compilation it's immediate)

BO: HumanCustomer
6 - 10
There's a FK on BO
that references a
parent BO (this is
optional)
lastName
firstName
driversLicense
businessName
employerIdentityNbr

Grandchildren and Great Grandchildren and

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

When this type of customer is
added, only a welcome letter is
sent
6 - 11
BO: PartnershipCustomer

When these types of customers are added, a welcome

letter is sent and their credit history is checked
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
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

1
2
welcome
letter on add
Post Processing:
Send
BO: HumanCustomer
lastName
firstName
driversLicense
3
credit history

6 - 13

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

Info: Include customer name
BO: HumanCustomer
We'd show the customer name
for this type of BO
We'd show the
employer ID,
customer name and
credit rating for this
type of BO
6 - 14
Info: Include employer ID,
name and credit rating
We'd show the partnership name
and credit rating and partnership
date for this type of BO
Info: Include partnership name
and credit rating and partnership
date
Preventing Instantiation Of Parent BO's
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)
Instantiable: No
BO: HumanCustomer
Instantiable: Yes
Instantiable: No
Instantiable: Yes
6 - 16
Notice that we've set

up this BO hierarchy
to indicate that only
non-abstract
business objects can
have instances
created
Instantiable: Yes
Inheriting Data Structures
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
<name ... />
<customerId ... />
...
BO: HumanCustomer
<includeBO name="GenericCustomer" />

<dateOfBirth ... />
<mothersMaidenName ... />
...
6 - 18

<employerIdentityNumber ... />
<marketingContact ... />
...
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
<name ... />
<customerId ... />
...
BO: HumanCustomer
<dateOfBirth ... />
<mothersMaidenName ... />
...

...
A warning will be issued for this BO
6 - 19
Inheritance and Ownership
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
Owner: C1 (Base)
<name ... />
<customerId ... />
...
6 - 21
You can only modify this BO's

schema if the owner flag on the
installation record is C1 (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: Customer
Owner: C1 (Base)
<name ... />
<customerId ... />
...
This shows how a "CM"

implementation can add
additional elements to a
base-package BO
BO: MyCustomer
Owner: CM (Customer)
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)
6 - 22
<includeBO name="Customer" />

...
CM Algorithms on CM Objects
Implementations can
obviously add algorithms
to their BO's
BO: Customer
Owner: C1 (Base)
<name ... />
<customerId ... />
...
BO: MyCustomer
<includeBO name="Customer" />
...
This shows a CM algorithm on a CM

business object
6 - 23
Validation: Check My Elements
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
credit history

6 - 24

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: C1 (Base)
Owner: C1 (Base)
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: C1 (Base)
Owner: C1 (Base)
Post Processing: Check credit history
Post Processing: Create To Do entry
6 - 25
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 (there is no clear upgrade path for duplicate sequences)
Owner: C1 (Base)
Owner: C1 (Base)
Sequence: 10
Sequence: 15
6 - 26
Business
Object
BO /
Algorithm
There is a sequence
number on this table
that controls the
order of execution
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
Owner: C1 (Base)
Owner: C1 (Base)
Sequence: 10
Sequence: 15
6 - 27
There is a way that you can tell the

base-package to not execute this
algorithm
Inheriting a Nightmare
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
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
Walk Through Addendum

In real life, an implementation would never have to create
a child BO to just add some 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
Review Questions
6 - 32
6 - 33

06 BO Inheritance

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

06 BO Inheritance

Încărcat de

Drepturi de autor:

Formate disponibile

6

Copyright 2009, Oracle. All rights reserved.

In this section, you'll learn additional techniques to avoid

Copyright 2009, Oracle. All rights reserved.

Refresher: Stand Alone Data Areas

Copyright 2009, Oracle. All rights reserved.

Including Stand Alone Data Areas

StandardTaxpayerElements Standalone Schema

Both of the BO's include the stand

Copyright 2009, Oracle. All rights reserved.

Refresher: Reuse Using Plug-ins

Copyright 2009, Oracle. All rights reserved.

Using Algorithms To Avoid Redundant Logic

Any bug fix / enhancement will

Copyright 2009, Oracle. All rights reserved.

Reuse Using Inheritance

Copyright 2009, Oracle. All rights reserved.

Reuse Scenario Post Processing Rule

Post Processing: Send

Post Processing: Send

Copyright 2009, Oracle. All rights reserved.

Put Common Rules On A Parent BO

You can then plug-in rules on the parent BO

A post processing rule

Copyright 2009, Oracle. All rights reserved.

Note, the parent and its children

Parent BO: GenericCustomer

Copyright 2009, Oracle. All rights reserved.

Grandchildren and Great Grandchildren and

When these types of customers are added, a welcome

Copyright 2009, Oracle. All rights reserved.

Refresher: Single versus Multi Spots

Recall that a BO can have only 1 algorithm plugged in for

The next slides describe what happens when a given

Copyright 2009, Oracle. All rights reserved.

Multi System Events Are "Top Down"

Parent BO: GenericCustomer

Copyright 2009, Oracle. All rights reserved.

Single System Events Are "Find The Nearest"

Parent BO: GenericCustomer

Copyright 2009, Oracle. All rights reserved.

Preventing Instantiation Of Parent BO's

Copyright 2009, Oracle. All rights reserved.

Notice that we've set

Copyright 2009, Oracle. All rights reserved.

Inheriting Data Structures

Copyright 2009, Oracle. All rights reserved.

Note - Data Structures Are NOT Implicitly Inherited

<includeBO name="GenericCustomer" />

<includeBO name="GenericCustomer" />

Copyright 2009, Oracle. All rights reserved.

Warnings Are Issued

<employerIdentityNumber ... />

A warning will be issued for this BO

Copyright 2009, Oracle. All rights reserved.

Inheritance and Ownership

Copyright 2009, Oracle. All rights reserved.

Only The Owning Implementation Can Change A BO's

You can only modify this BO's

Copyright 2009, Oracle. All rights reserved.

Including A BO You Don't Own

This shows how a "CM"

This means that when elements are added

<includeBO name="Customer" />