13-Anticipating Site Specific Enhancements

13
Anticipating Site-Specific Enhancements
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
Define a BO's lifecycle
Define rules for the different stages of a BO's lifecycle
Control who can access and update a BO
Understand the reason for admin BO's
Create service scripts to encapsulate commonly used logic
Invoke core services using business services
In this section, you'll learn several design patterns that

allow implementations to make more profound changes to
the systems we deliver
And still be 100% upgradeable!
13 - 2
The Goals
The primary directive: create applications that can be extended by
implementations while still being easily upgradeable
By upgradeable we mean that an implementation should be able to upgrade over
a weekend
Anything we do in a subsequent release that could result in an implementation
having to change their configuration / program logic in order to get their system
working after an upgrade is prohibited
The secondary directive: the only time an implementation should have to

subclass a BO is if they need to add elements to our BO
Or phrased differently an implementation should be able to add, change and
delete rules without having to subclass
The tertiary directive: the only time an implementation should have to

duplicate a BO is if they need to radically change the structure or our BO's
lifecycle
Or phrased differently an implementation should be able to make minor
extensions to BO lifecycles
And, when possible, the application should work "out-of-the-box" with a

minimal amount of configuration
13 - 3
13
Refresher: Inactivating Algorithms
Refresher: BO's Have Algorithms

Recall that we can release a BO with a variety of algorithms
Also recall that an implementation can add their own "CM" algorithms
to our BO's
This means that a given BO can have algorithms with disparate owners
BO
Owner
BO /
Algorithm
System
Event
Valid
Status
BO / State /
Algorithm
13 - 5
System
Event
Valid Values:
Validation
Pre Processing
Post Processing
Audit
Info
some designs
introduce these
Valid Values:
Enter
Exit
Monitor
Refresher: BO's Have Options

Recall that we can release a BO with a variety of options
Also recall that an implementation can add their own "CM"
options to our BO's
This means that a given BO can have options with disparate
owners
BO
Owner
BO /
Option
Option
Type
Valid
Status
BO / State /
Option
13 - 6
Option
Type
Valid Values:
inactivate
algorithm
there are several
base package
values that are UIoriented so we'll
save these for later
Valid Values:
Required element
Inactivate algorithm
Case Study
Let's assume:
We've released a BO with several Validation algorithms plugged in
The onsite team determines that one of our validation algorithms is
too strict
One method of achieving the results would be for them to

duplicate the entire BO (i.e., create a "CM version" of the
base-package BO) and then remove the strict algorithm
from the CM version
This is because an on site team cannot remove algorithms that are
owned by the base-package, they can just add additional
algorithms
However, you know a better way
13 - 7
Refresher: The Inactivate Algorithm Option Type

If an onsite team wants to disable a base-package algorithm, they
simply add an option to the BO or BO / Status where:
Option Type = Inactivate Algorithm
Option Value = Algorithm Code
The framework will not execute disabled algorithms

BO
BO /
Option
Option
Type
Valid Values:
there are several base package
values that are UI-oriented so we'll
save these for later
Valid
Status
BO / State /
Option
13 - 8
Option
Type
Valid Values:
Required element
Support Issues
The decision to support the Inactivate algorithm option
type was difficult for the base-package team to accept as it
means that an on site team can completely change a basepackage BO's behavior
However, the alternative was viewed as worse
Duplicating a BO means that an implementation will not easily
receive upgrades and bug fixes to the original BO
In order to satisfy all parties, the following rule exists:

If an implementation reports a bug with a base-package BO, they
must recreate this bug on an unmodified BO; by unmodified we
mean:
No CM options (including the option used to disable an algorithm)
No CM algorithms
Until that time, we won't deal with the bug

13 - 9
13
Algorithms That Invoke Algorithms
Case Study
The previous chapter described how algorithm type programs can be
designed to retrieve parameter values from a variety of sources
For example, an algorithm that creates an adjustment can retrieve the
respective adjustment type from the algorithm, or from a BO option, or
from an admin BO
This is a fine technique, but what happens if the algorithm type's logic
is impossible to parameterize?
For example, what if the requirement is to NOT create the adjustment if the
customer is considered to be "high-value" and the definition of a "highvalue" customer is unique to each implementation?
Implementation 1's definition: A high-value customer is one with a credit score >
620, with no payment plans in the last 2 years, and with annual billings > $1,000
Implementation 2's definition: A high-value customer is one that has been a
customer for at least 12 months and has had no collection processes in the last 2
years
In sum: each implementation's definition is idiosyncratic and it'd be almost

impossible to parameterize the definition
13 - 11
A New Plug-In Spot (i.e., System Event)

The pattern that we've adopted to handle these types of requirements
is as follows:
Create a new system event for the idiosyncratic logic
Remember, when you create a new system event, you must involve a Java
programmer and this programmer defines its API
In our example, the system event would have input of the customer id and output
of an indication if the adjustment should be levied
The placement of the system event depends on many factors:

Ease of set up by the on site team (we're always trying to come up with ways that
are "self documenting")
Frequency of use (if the system event is going to be called from many parts of
the system, we'll typically place it on the installation record)
Existence of an admin BO (if the system event is only called from another
algorithm and there's an admin BO, we'll typically put it on the admin BO)

In our example, we'll place the system event on the same place where we
keep the adjustment type (i.e., the instance of the admin BO)
13 - 12
Placing The New System Event On The Admin Object

This is an example of an admin MO
that's been designed with an algorithm
table. This allows us to have a
configuration experience where the on
site team defines both the adjustment
type AND the algorithm used to
determine if the adjustment should be
levied (i.e., "one stop" set up)
Valid Values:
Levy an adjustment
condition
Adjustment
Type
FA Type
System
Event
FA Type /
Algorithm
Algorithm
Note, this table is identical to

the algorithm table that you've
seen on BO and BO / status
13 - 13
Field
Activity
The Primary Algorithm Invokes An Algorithm

The original algorithm that had the idiosyncratic logic will
now simply invoke the new algorithm to determine if the
adjustment should be levied (and, if so, the original
algorithm will levy it)
Decisions to implement this type of design are not made
lightly as we understand that this is complex
However, if the requirement that we're given fits into this
pattern, all other alternatives involve the primary algorithm
needing to be totally overridden by an implementation
when they just need to change a small part of it
And neither us nor our customers like this alternative
13 - 14
13
Extending Lifecycles
Checkpoint
We've talked about how an onsite team can change BO's released with the base-package:
Insert new "CM" algorithms anywhere in the BO hierarchy for any status
Disable base-package algorithms anywhere in the BO hierarchy
Add option values anywhere in the hierarchy
Create child BO's with additional elements that inherit base-package behavior
Parent BO: GenericFieldActivity

Pending
Canceled
Dispatched
Complete
BO: InstallMeter
13 - 16
BO: InvestigateSvcTheft
BO: ReadMeter
The Lifecycle Is Owned

An integral part of the BO meta-data is the lifecycle data (i.e., the valid
state and the from/to state meta-data)
Lifecycle meta-data can only be modified by the owner of the BO
This means that if the base-package team releases a BO, the on site
team cannot modify its lifecycle
Pending
Remember, the lifecycle

can only be defined on the
top-most BO in a hierarchy
Canceled
Dispatched
Complete
BO: InstallMeter
13 - 17
BO: ReadMeter
Case Study
What if InvestigateSvcTheft field activities for commercial customers
require authorization before they can be dispatched?
Pending
Canceled
Dispatched
Complete
BO: InstallMeter
Pending
Canceled
Waiting For
Approval
Dispatched
13 - 18
Complete
BO: ReadMeter
Can Only Change Lifecycle On The Topmost BO

(and you must own the BO)
Remember, lifecycle can only be defined on the highest BO and it
can't be changed if you don't own it
Pending
Canceled
Dispatched
Complete
BO: InstallMeter
Pending
Canceled
The framework will not

allow you to do this
Waiting For
Approval
Dispatched
13 - 19
Complete
BO: ReadMeter
Create Another Object

Rather than extend the BO's lifecycle,
the "trick" is to do the following:
Add an Enter plug-in to the Pending state
to create another object with its own
lifecycle
Add a Monitor plug-in to the Pending
state that monitors the state of the new
object and only transitions to the
Dispatched state when the other object is
done
This algorithm creates an
"authorization" object that
has its own lifecycle
BO: AuthFA
Pending
Canceled
Authorized
13 - 20
This algorithm transitions

the field activity to the
dispatched state when the
authorization object
reaches a complete state

Pending
Canceled
Dispatched
Complete
Status: Pending
System Event: Enter
Algorithm: Create authorization if
commercial customer
Status: Pending
System Event: Monitor
Algorithm: Transition to dispatched
when authorization is complete
Base Package Enter Plug-Ins Will Rarely Transition

In an earlier section, we explained how Enter plug-ins have the
power to transition to any other state
What we didn't say is that most base-package Enter plug-ins will
NOT do this
Rather, such states will have a monitor plug in that will do the
transition
If we did, an on site team could never extend the object's lifecycle

Because our enter plug-in would skip to the Dispatched state and
there'd never be an opportunity to create the authorization object and
then monitor it while the FA is in the Pending state
BO: GenericFieldActivity
Owner: CM
Status: Pending
Sequence: 5
when authorization is complete
Owner: Base
Status: Pending
Sequence: 10
Notice how the CM

algorithm is placed before
the base algorithm (this is
so it can abort the monitor
while the authorization is
pending)
13 - 21
13
Flattening To Site-Specific Admin Data
Problem Statement
Some solutions need to have
flattened BO elements
For example:
A taxpayer BO may need an
element called <homePhone>
This element will physically
reside in the CI_PER_PHONE
table
The problem is that the schema
flattening syntax needs to
reference the PHONE_TYPE_CD
However, we aren't allowed to
ship phone type codes as this
table has no owner (and, even if it
did, it's hard to justify telling a
customer that they'd have a
phone type code equal to HOME
(especially if they don't speak
English))
13 - 23
Notice we have the

analogous problem with
socialSecurityNumber
IndividualTaxpayer Schema
<taxpayerId mapField="PER_ID"/>
<name mapField="ENTITY_NAME">
<row mapChild="CI_PER_NAME">
<PRIM_NAME_SW is="true"/>
<NAME_TYPE_FLG default="PRIM"/>
</row>
</name>
<email mapField="EMAILID"/>
<socialSecurityNumber mapField="PER_ID_NBR">
<row mapChild="CI_PER_ID">
<ID_TYPE_CD is= "SSN" />
</row>
<socialSecurityNumber/>
<homePhone mapField="PHONE" >
<row mapChild="CI_PER_PHONE">
<PHONE_TYPE_CD is= "HOME" />
</row>
</homePhone>
...
Solution: Reference Constants In Schemas

Rather than hard-code the codes in the flattening syntax, you can
reference a "constant" whose value is defined by the implementation
team on the Schema Constants feature configuration
<taxpayerId mapField="PER_ID"/>
<name mapField="ENTITY_NAME">
<row mapChild="CI_PER_NAME">
<PRIM_NAME_SW is="true"/>
<NAME_TYPE_FLG default="PRIM"/>
</row>
</name>
<ID_TYPE_CD is="%Constant(<ssnIdType>)"/>
</row>
<PHONE_TYPE_CD is="%Constant(<homePhoneType>)"/>
</row>
</homePhone>
...
13 - 24
%Constant is a FW function; the value

in parms is the Java name of one of
the feature configuration's option
types that holds the implementation
team's admin value (we'll show this on
the next slide)
At run time, the FW finds the

option value entered for the
option type and uses it to flatten
the element
The Constants Feature Configuration

This is the lookup value behind the Schema Constants
feature configuration
This sample would mean that there would be 3 entries on
the Schema Constants feature configuration and the
implementation team would enter the appropriate value for
each
This is the name referenced in

the Constant (<>)
13 - 25
default= Uses Constants Too

You can also use Schema Constants to default values in a
schema
<taxpayerId mapField="PER_ID"/
<individualTaxpayerType mapField="ADHOC_CHAR_VAL" default="%Constant(<indTaxpayerType>)">
<row mapChild="CI_PER_CHAR">
<CHAR_TYPE_CD is="TPTYPE" />
<EFFDT default="%CurrentDate" />
</row>
This is the default value the
</individualTaxpayerType>
implementation team wants for
the ad hoc char value that will
contain the taxpayer type for
individual taxpayers
<ID_TYPE_CD is="%Constant(<ssnIdType>)"/>
</row>
<PHONE_TYPE_CD is="%Constant(<homePhoneType>)"/>
</row>
</homePhone>
...
13 - 26
Team Walk Through (15 Minutes)

Assume that we release a BO with several different
validation algorithms that are sequenced as follows:
10 Validate name
20 Validate phone number
30 Validate email address
40 Validate mailing address
This implementation would prefer that the mailing address

be validated before the email address
Describe how you would achieve this if you were this
implementation team
13 - 27
Review Questions
13 - 28
13 - 29

13-Anticipating Site Specific Enhancements

Î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

13-Anticipating Site Specific Enhancements

Încărcat de

Drepturi de autor:

Formate disponibile

13

Anticipating Site-Specific Enhancements

Copyright 2009, Oracle. All rights reserved.

Define a BO's data structure (i.e., its schema)

In this section, you'll learn several design patterns that

Copyright 2009, Oracle. All rights reserved.

The secondary directive: the only time an implementation should have to

The tertiary directive: the only time an implementation should have to

And, when possible, the application should work "out-of-the-box" with a

Copyright 2009, Oracle. All rights reserved.

Refresher: Inactivating Algorithms

Copyright 2009, Oracle. All rights reserved.

Refresher: BO's Have Algorithms

Copyright 2009, Oracle. All rights reserved.

Refresher: BO's Have Options

Copyright 2009, Oracle. All rights reserved.

One method of achieving the results would be for them to

Copyright 2009, Oracle. All rights reserved.

Refresher: The Inactivate Algorithm Option Type

The framework will not execute disabled algorithms

Copyright 2009, Oracle. All rights reserved.

In order to satisfy all parties, the following rule exists:

Until that time, we won't deal with the bug

Copyright 2009, Oracle. All rights reserved.

Algorithms That Invoke Algorithms

Copyright 2009, Oracle. All rights reserved.

In sum: each implementation's definition is idiosyncratic and it'd be almost

Copyright 2009, Oracle. All rights reserved.

A New Plug-In Spot (i.e., System Event)

The placement of the system event depends on many factors:

Copyright 2009, Oracle. All rights reserved.

Placing The New System Event On The Admin Object

Note, this table is identical to

Copyright 2009, Oracle. All rights reserved.

The Primary Algorithm Invokes An Algorithm

Copyright 2009, Oracle. All rights reserved.

Copyright 2009, Oracle. All rights reserved.

Parent BO: GenericFieldActivity

Copyright 2009, Oracle. All rights reserved.

The Lifecycle Is Owned

Remember, the lifecycle

Copyright 2009, Oracle. All rights reserved.

Can Only Change Lifecycle On The Topmost BO

The framework will not

Copyright 2009, Oracle. All rights reserved.

Create Another Object

This algorithm transitions

Parent BO: GenericFieldActivity

Copyright 2009, Oracle. All rights reserved.

Base Package Enter Plug-Ins Will Rarely Transition

If we did, an on site team could never extend the object's lifecycle

Notice how the CM

Copyright 2009, Oracle. All rights reserved.

Flattening To Site-Specific Admin Data

Copyright 2009, Oracle. All rights reserved.

Notice we have the

Copyright 2009, Oracle. All rights reserved.

Solution: Reference Constants In Schemas

%Constant is a FW function; the value

Copyright 2009, Oracle. All rights reserved.

At run time, the FW finds the

The Constants Feature Configuration

This is the name referenced in

Copyright 2009, Oracle. All rights reserved.