You are on page 1of 90

2

Config Tools Refresher

3-1

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Agenda
This section reviews important concepts from the Config Tools
training class

2-2

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

4-Tier Architecture

3-3

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

The Location Of The Business Rules

Web
Server

Application
Server

There are no business rules


on the Web Server
All business rules on the UI tier are
redundant (e.g., a drop-down that
contains valid choices is not a
substitute for a backend business rule
that checks the user's choice is valid)

2-4

DB

There are no business rules


in the database (i.e., no
stored procedures or
PL/SQL)

This is where youll find all of the


business rules and all of the
database access

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Entity Relationship
Diagramming Standards

2-5

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Colors and Mnemonics Highlight A Table's Class


And Features
SP Type
Disconnect
Location
Contact

Contact /
SP

The dashed line means the


FK is not in a dedicated
column. Rather, the FK is in
a multi-use column that can
reference practically any FK
in the system

2-6

Service
Point

Time
Zone

Legend
Lookup
Child Table

Related
Object

Activity
ST, CH, X

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Tran. Data
Admin Data
Master Data
FW Data

The Application Viewer

2-7

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

The Table and Field Metadata


Every table has an entry in the table metadata
Every field has an entry on the field metadata
Table

A table has 1 or more


fields; a field can be on
one or more tables

Table /
Field

Constraint

A table has constraints to


define its prime key and its
foreign keys

Constraint
/ Field

Field

2-8

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

The Application Viewer Is The Primary


Documentation Of Tables And Fields
Many ERDs are used in this class
These ERDs are logical subsets used to reinforce important
concepts; there are typically many more tables involved in a
functional area than shown on the slides
The complete data model is viewable using the Application
Viewer

2-9

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

The Application Viewer Is Generated From


Metadata
The application viewers Data Dictionary is generated by a batch
process that converts the systems table / field metadata into
XML documents that drive this graphical representation
This same table / field metadata is also used to create the
services that add, change, delete and read data
This means that the data dictionary is reliable documentation
In other words, if the data dictionary is wrong, the system is
wrong

2 - 10

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Practice 3-1 (15 minutes)


During this exercise, you will use the following transactions
Admin Application Viewer
Admin Table
You will see that the table and field metadata is identical to that
illustrated in the application viewer

2 - 11

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Common Data Design Patterns

3 - 12

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

No Recurring Groups
Recurring groups of columns are rarely used on the tables
Rather, child tables normalize the relationship so each implementation can
have as many entries as it needs

Contact

Contact /
ID
The contact table doesn't
contain two columns one for
social security number and
another for drivers license.
Rather, a contact's various ID's
are kept on the Contact / Id
table (where each entry
references an identifier type).
2 - 13

ID Type

Contact /
Phone

Phone
Type

The same is true for a


contact's phones (and
names, and email). You'll
find this pattern throughout
the system.

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Prime Keys
The prime key of most
"admin" tables is a userassigned mnemonic

Contact
Type

"Child" tables frequently have


concatenated prime keys

The prime key of many "non


admin" tables is a systemassigned, random number

Contact

Contact /
ID

ID Type

2 - 14

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Prime and Foreign Keys In The Application Viewer

PK is gold

FKs are
blue

2 - 15

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Language Tables
The admin tables support multiple end-user languages
An earlier diagram implied
that theres a column on the
Contact Type table that
holds its description this is
NOT true

Contact
This design allows each
contact type to have a different
description depending on the
end-user's language

Contact
Type

Language
Contact
Type /
Language
The description that
matches the users
language appears on
the UI

2 - 16

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Maintenance Objects

3 - 17

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

MO Definition
Most logical transactions are made up of several tables
The term maintenance object (MO) is used to describe the
group of tables that hold an objects physical data
The contact
maintenance object's
data is held in several
tables

Contact
Contact
D1_CONTACT

Contact ID

Contact / ID

CI_LOOKUP_FIELD

D1_CONTACT_ID

Contact /
Name

Contact /
Phone

D1_CONTACT_NAME

D1_CONTACT_PHONE

Name Type
CI_LOOKUP_FIELD

2 - 18

Phone Type
CI_LOOKUP_FIELD

Note, this is a simplification


as this MO has more than
4 tables

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

MO, Table, Field Metadata


The MO, table and field metadata is very important as it is used to
generate the Java classes (and services) that add, change, delete and
read a maintenance object
If its wrong, the system wont work
Table

MO Def /
Table

MO

Table / Field

Field

2 - 19

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

MOs Are Also In The App Viewer


If you click this icon, you'll be
transferred to this table's MO (if the
table is part of multiple MOs, there are
multiple icons)

You are now shown the MO's


tables

These are all of the MOs


2 - 20

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

MOs Encapsulate Core Business Rules


In addition to defining data structures, MOs encapsulate core
business rules (e.g., validation logic)
These business rules are written in Java
These core business rules can be extended by an
implementation team
Note well - implementations cannot change or remove core
business rules; however, additional rules may be added as
described in the next section

2 - 21

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Many MOs Have Characteristics

3 - 22

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Characteristics Extend
Birth Date =
12/10/64

Contacts

County Parcel ID =
A234993

Service Points

Elevation =
1000ft
Customer
Count = 4

Subscriptions
Devices
Other
Things
2 - 23

Number
Wires = 3

...

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Volts
= 240

Many MOs Support 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 MOs user-defined fields
In other words, most MOs can have an unlimited number of
characteristics
Service
Point

SP / Char

Char
Type

An implementation can set


up an unlimited number of
user-defined fields for their
service points

2 - 24

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

There Are 4 Types Of Char Types


Each characteristics char type defines its category
The upcoming slides provide examples of each
Char
Type

Predefined
Value

2 - 25

Ad hoc
Value

Foreign Key
Reference

File
Location

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Predefined Char Types


Predefined char types are used when the user-defined field has
a discreet set of valid values
Char
Type

Gender

Male
Female

2 - 26

Predefined
Value

Ad hoc
Value

Foreign Key
Reference

Valid Value

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

File
Location

Ad Hoc Characteristic Types


Ad hoc char types are used when the user-defined field holds a
date, a string, or a number
Birth
Date

Defined
Value

2 - 27

Ad hoc
Value

Char
Type

Foreign Key
Reference

File
Location

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Foreign Key Reference Characteristic Types


FK char types are used when the user-defined field holds a
foreign key
Char
Type

Defined
Value

Ad hoc
Value

Property
manager

Foreign Key
Reference

File
Location

An FK ref char type must reference an FK ref


In this example, the foreign key reference
char type would reference the Contact FK
ref. This means that the char value must
be a foreign key to the contact table.

2 - 28

FK
Reference

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

File Location Characteristic Types


File location char types are used when the user-defined field
holds a reference to a file location or URL
Char
Type

Defined
Value

2 - 29

Ad hoc
Value

Foreign Key
Reference

Customers
Contract

File
Location

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Characteristic Values Are Effective-Dated On


Some Entities
Note that the char collection of some MOs contains an effective
date, which allows the char value to change over time
SP

2 - 30

SP / Char

Char Type

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

A Char Type Can Be Used On Multiple Entities


When a char type is set up, in addition to defining its category
(ad hoc, predefine, FK ref, file location), you must define which
entities / MOs that it can be defined on
Char
Type

Entity
Char Type
/ Entity

2 - 31

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Values:
- Contact
- Service Point
- Device
- Usage Subscr.
- etc

Data Ownership

3 - 32

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Owning Metadata
The metadata is an integral part of the system
Much of this metadata is interpreted at execution time and is
therefore shipped with our software
The base-package metadata cannot be changed 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 MOs) 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 metadata tables have a
column called owner flag

2 - 33

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Owner Flag ERD


The owner flag is simply a column on a table that references
the product that owns it
The installation record references the product that owns the
installed system. For example,
In an MDM development environment, this record
references the D2 (meter data management) owner
In a customers environment, this record references the
CM (customer) owner
This flag cannot be changed after the system is installed
Owner Flag

2 - 34

Installation FW

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Owner Flag Is Ubiquitous


MO

Field

Owner Flag

Table

Char Type

You've only been exposed

to a small percentage of the

tables that have "owned"

metadata

2 - 35

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

The System Stamps Owner Flag On New


Metadata Rows
When you add a row to a metadata table, the system flags it with the
implementations active owner flag
Remember, the implementations owner flag is on the installation
record
The system will not allow changes to a row if the rows owner flag is
not the same as the implementations owner flag
For example, an implementation will not be able to change data
owned by the base-package
For example, if an implementation adds a new MO, the MO will be
marked with an owner flag of CM (given this is the value on the
implementation's installation record)
CM

Owner Flag

2 - 36

Installation FW

If you were to look at an


implementation's installation,
you'll find an owner flag of CM
(customer modification)

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Dont Even Think About It


If you dont like something someone else owns and you think
that youll just change the rows owner flag outside of the
application (e.g., via ad hoc SQL), DONT DO IT
If you do, when you next upgrade, the upgrade scripts will
override any such changes (as ownership is reapplied during an
upgrade)
Similarly, if you use SQL to change data on a row that your
implementation doesn't own, the next upgrade will revert your
changes

2 - 37

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

2
Security

3 - 38

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Database and Operating System Security


Browser:
provides logon prompt,
keeps a session cookie that holds
the authentication certificate
SSL encryption can be used here if
desired; managed by Web server

Web Server

App Server

Database
Server
2 - 39

Web server:
provides authentication,
allows you to use your operating
systems authentication: Windows,
Unix, authorization services are NOT
used
Application security is described in
the next section
The database sees one User
(controlled by the application server)

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Sessions expire when:


Web server times out,
browser is closed
Browser caches the
users application
security values

Application Services Are Secured


Every securable transaction (e.g., business object, portal, page
transaction, zone, etc.) has a corresponding application service
When you link a user group to an application service, you are
granting all users in the group access to the application
services transaction

Application
Service

User Group

User Group /
App Svc

2 - 40

User Group /
User

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

User

A user's membership
in a user group has
an expiration date

Application Services Have Valid Actions


Every application service has valid actions

For example, update-oriented transactions have actions of read,


add, change, and delete
When you grant a user group access to an application service, you define
which valid actions it has rights to (read, add, change, )
Application
Service

Valid Action

User Group

User Group /
App Svc

Permissible
Action

2 - 41

User

User Group /
User

This defines the actions the users in


the group have access to

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Field-Level Security
The system allows you to define the various fields which are
secured
Field-level security could be anything:
From:
Only certain users can change a field

To:
User group A can authorize bills less than $500
User group B can authorize bills less than $2,000
User group C can authorize any bill

While the system allows you to define the types of field-level


security you have and the authorization levels, your
implementation must add the code to user exits to enforce these
restrictions
2 - 42

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Field-Level Security Overview


Every secured field has a security type associated with it
Every security type will have authorization levels

For example, the bill authorization security type would have 3 levels
Each user group is linked to the appropriate level for the security type for
the application service
Application
Service

Security Type

App Service /
Security Type
Authorization
Level

2 - 43

User Group

User Group /
App Svc

User Group /
User (Edate)

UG /
AppSvc / Sec
Type / Author
Level
Copyright 2010, Oracle and/or its affiliates. All rights reserved.

User

Security Rights Are Cached


If you change anything thats security oriented, you must clear the
cache
To do this, replace cis.jsp with flushAll.jsp in the address field.
For example,
if the standard URL was http://sf-pdnt-009:7031/cis.jsp,
You would enter http://sf-pdnt-009:7031/flushAll.jsp to flush the
server cache

The framework will show this to indicate that the cache has been flushed. You
must restart the system with cis.jsp?debug=true (and it will take a little longer
than normal as it will rebuild the cache)
2 - 44

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Business Objects

3 - 45

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Maintenance Objects Versus Business Objects


MOs are designed to be
abstract and generic so
that they can be used in
multiple geographies and
vertical markets

Contact Maintenance Object (MO)


Contact

Contact
Name

Contact Id

Residential Contact BO
Individual
Contact ID
Name
E-mail
SSN
Home Phone
Date of Birth
Spouse

2 - 46

Contact
Char
Contact
Phone

Business objects are


specialized versions of MOs
that are designed to match the
business. For example, an
implementation could set up
BOs for different types of
businesses rather than work
with the generic contact MO

Commercial
Contact BO

Corporate
Contact ID
Corporate Name
Employer ID
Main Phone
Date of Incorporation
Corporate Officers

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

A Maintenance Object Has Fields,


A Business Object Has Elements
The term element is used to describe an individual piece of
information that a BO holds
This term is used rather than field or column because XML
documents are used to communicate with BOs (and XML
documents contain elements)

2 - 47

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

A BOs Elements Must Physically Reside


Somewhere In Its MOs Tables
Contact (D1_CONTACT)

Residential Contact

Elements
Contact ID
Contact
Type
Name (Name)

Name
E-mail
SSN
SSN (ID)
Home Phone

Phone (Phone)
Home
Work Phone
Work Phone
(Phone)
Extension
Date
Birth Ext. (Phone)
Work of
Phone

2 - 48

Contact ID

123

Contact Type

PER

Names (D1_CONTACT_NAME)
Type

Name

Primary

Brazil, Mark

Ids (D1_CONTACT_IDENTIFIER)
Type

ID Number

SSN

777

Phones (D1_CONTACT_PHONE)
Type

Phone Number

Home

973-777-7777

Work

973-451-7777

Ext

111

Characteristics (D1_CONTACT_CHAR)
Type

Value

DOB

1961-11-15

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

BOs Encapsulate Business Rules


In addition to defining the data structure of an object, a BO also
encapsulates business rules specific to the object
A BO's rules can never violate an MOs core business rules, as
the BO is a specialized version of the MO; the BO defines
additional business rules that are applicable to its instances

2 - 49

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

BOs and SOA


XML service calls are used to communicate with BOs (just like
MOs)
The main difference between MO and BO services is that the
XML for a BO service matches the BO's elements, thus making
it more intuitive to understand (and therefore simpler to invoke)

2 - 50

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

BO Elements and Rules

3 - 51

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

A BOs Elements Are Defined In Its Schema

Recall that each element must reside somewhere in its MO's


physical tables (notice the mapField and mapChild attributes)

2 - 52

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

"Real" Columns versus CLOBs

An element can reside in a real column or as XML stored in a CLOB


If the element will never be referenced in an SQL WHERE
statement, it can reside in a CLOB
Otherwise it must reside in a real column

Service
Point

SP / Char

Char
Type

XML

Elements that are not referenced


in WHERE statements can reside
as XML stored in a CLOB

2 - 53

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

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 metadata

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

2 - 54

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Validation Rules

Ad
BO d

A validation algorithm can be plugged in on a BO if more sophisticated


validation than can be defined using the schema attributes is required
Notice how validation algorithms are executed after the MO processing (e.g.,
core validation rules)

Individual Taxpayer

Ad
M d
O

Enter

2. MO Processing

2 - 55

Exit

Person MO
(Service)

3. Validation algorithms

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

To Create A New Algorithm, Follow These Steps


Write your logic (in Java or Scripting)
Create an algorithm type that references your program or script
Create an algorithm that references your algorithm type
Plug the algorithm in on the BO
Note - a Dashboard zone on the Business Object page contains a wizard that
will set up the above meta-data (you just have to write the script afterwards)

Programming
Language

Business
Object
BO
Algorithm

2 - 56

3
4

Algorithm

1
2

Algorithm
Type

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Other Types Of Rules

In
vo
BO ke

In addition to validation rules, a BO can have:


Pre-processing rules to default elements into the BO's schema
Post-processing rules to perform additional logic after add /
change / delete operations
Audit rules to store audit trails after add / change / delete
operations

Enter

In
v
M oke
O

1. Pre-processing rules

2. MO Processing

2 - 57

Individual Taxpayer
Exit

Person MO
(Service)

5. Audit rules
4. Post-processing rules
3. Validation rules

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

BO Hierarchies

3 - 58

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Reuse Scenario Post Processing Rule


Let's assume that whenever a new contact is added, a "welcome
letter" is sent, regardless of the type of contact
This could be implemented by plugging in a post processing algorithm
on all relevant BO's
However, some object-oriented adherents might argue this is
redundant
BO: ResidentialContact

lastName
firstName
driversLicense

Post Processing: Send


welcome letter on add

2 - 59

BO: CommercialContact
businessName
employerIdentityNbr

Post Processing: Send
welcome letter on add

Copyright 2010, Oracle and/or its affiliates. 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
Parent BO: GenericContact
Post Processing: Send
welcome letter on add

BO: ResidentialCustomer

2 - 60

lastName
firstName
driversLicense

A post processing rule


defined on a parent BO
applies to all of its
children

BO: CommercialContact
businessName
employerIdentityNbr

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Parent BO ERD
A parent BO is simply a BO that is
referenced by other BO's
Note, the parent and its children
must reference the same MO

Business
Object

There's a FK on BO
that references a
parent BO (this is
optional)

Algorithm
If a BO references a parent
BO, the parent's rules
automatically apply (no
compilation it's immediate)

Parent BO: GenericContact


Post Processing: Send
welcome letter on add

BO: ResidentialContact

2 - 61

lastName
firstName
driversLicense

BO: CommercialContact
businessName
employerIdentityNbr

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Grandchildren and Great Grandchildren and


A child BO can have children (and so on)
Parent BO: GenericContact
Post Processing: Send
welcome letter on add

BO: ResidentialContact

lastName
firstName
driversLicense

BO: CommercialContact
Post Processing: Check
credit history

BO: CorporateContact

When this type of customer is
added, only a welcome letter is
sent
2 - 62

BO: PartnershipContact

When these types of customers are added, a welcome


letter is sent and their credit history is checked

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Inheritance and Ownership

3 - 63

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

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: Contact
Owner: D1 (Meter Data Foundation)
<name ... />
<customerId ... />
...

2 - 64

You can only modify this BO's


schema if the owner flag on the
installation record is D1 (and
typically only the base-package team
will have such an installation record)

Copyright 2010, Oracle and/or its affiliates. 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
included BO must be the
parent; this is not true. You
can include a BO in any
other BO (but avoid
recursion!)

BO: Contact
Owner: D1
<name ... />
<customerId ... />
...

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 basepackage team, the implementation will get
them too (for better or for worse)
2 - 65

BO: MyContact
Owner: CM
<includeBO name="Customer" />
<employerIdentityNumber ... />
<marketingContact ... />
...

Copyright 2010, Oracle and/or its affiliates. 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


add another post-processing
algorithm to this BO that's
owned by the basepackage

Post Processing: Send


welcome letter on add

BO: HumanCustomer

lastName
firstName
driversLicense

BO: BusinessCustomer
Post Processing: Check
credit history

BO: CorporateCustomer

2 - 66

BO: PartnershipCustomer

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

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: D1
Owner: D1
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

BO: BusinessCustomer
Owner: D1
Owner: D1
Post Processing: Check credit history
Owner: CM
Post Processing: Create To Do entry

2 - 67

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Foreshadowing: Disabling Base-Package


Algorithms
While you cannot remove a base-package algorithm from a BO; you can tell
the OUAF not to execute an base-package algorithm by creating a BO
option (where the option type is Inactivate Algorithm)
BO: BusinessCustomer
Owner: D1
Owner: D1
Post Processing: Check credit history
Sequence: 10
Owner: D1
Post Processing: Create To Do entry
Sequence: 15

2 - 68

Any algorithm can be inactivated by


adding a BO option of Inactivate
Algorithm that references the algorithm's
code

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Business Object Lifecycle

3 - 69

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

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

2 - 70

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Rejected

State-Specific Rules
Earlier, 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

2 - 71

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

State Transition Rules

Exit

Error

Exit algorithms execute when an object


attempts to leave a state (and errors roll
back to the prior state)

2 - 72

Enter

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
Canceled
Enter algorithms execute before the
BO enters a state (and errors roll
back to the prior state)

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

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
2 - 73

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

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
Monitor

This allows you to define plugins for individual states under a


BO

2 - 74

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

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

2 - 75

System
Event

Valid Values:
Pre processing
Validation
Post processing

Valid Values:
Enter
Exit
Monitor

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

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
2 - 76

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

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Inheriting Lifecycle

3 - 77

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

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
Pending
Canceled
Dispatched

Complete

2 - 78

BO: RemoveMeter
Pending
Canceled
Dispatched

Complete

BO: ReadMeter
Pending
Canceled
Dispatched

Complete

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

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

2 - 79

BO: RemoveMeter

BO: ReadMeter

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

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
2 - 80

BO: ReadMeter
BO: InstallSimpleMeter

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

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
Status: Complete
System Event: Enter
Algorithm: Create
Installation Charge

2 - 81

BO: InvestiSvcTheft

BO: ReadMeter

Only states defined on the


topmost parent BO can be
referenced

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

2
Check Point

3 - 82

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Algorithm System Event Summary ERD


MO
MO /
Algorithm

System
Event

BO
Algorithm
BO /
Algorithm

System
Event

Valid
Status
BO / State /
Algorithm
2 - 83

System
Event

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

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
2. Determine status field.
If changed proceed with
old value (Keep new
value for later)
3. MO Processing
This incluedes MO-level
validation and inserts /
updates to the database.

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)
4. Determine BO (MO)

2 - 84

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Entity Relationship
Diagramming Standards Revisted

2 - 85

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Colors and Mnemonics Highlight A Table's Class


And Features
ST the object has a
configurable lifecycle
CH the object has a
collection a characteristics
X the table has a CLOB

Contact
ST, CH, X

Contact /
SP

SP Type
CH, X

Service
Point
ST, CH, X

Disconnect
Location
Time
Zone

Legend
Lookup
Child Table
Tran. Data

Related
Object

Activity

Admin Data

ST, CH, X

Master Data
FW Data

ST - Status
CH - Characteristics
X - CLOB

2 - 86

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Additional Diagramming Techniques

Service
Point
ST, CH, X

XML

Disconnect
Warning

FW4 introduced the extendable


lookup (used when the lookup value
is longer than 4 bytes or when the
lookup value has attributes in
addition to its description). This
symbol highlights when this type of
lookup is used.

Ext
Legend

When a relationship is held in a


CLOB, this diagramming
technique is used

Lookup
Child Table
Tran. Data
Admin Data
Master Data
FW Data

ST - Status
CH - Characteristics
X - CLOB

2 - 87

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Odds and Ends

3 - 88

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Localization Support
The following values can be defined on the users profile
Date / Time display formats
Position of Year, Month, Day
Time Format (e.g., 24-hour clock versus AM/PM)

Currency and quantity format


Decimal point symbol
Thousands separator
Position of negative sign

In addition, the address components may differ per country

2 - 89

Copyright 2010, Oracle and/or its affiliates. All rights reserved.

Review Questions

2 - 90

Copyright 2010, Oracle and/or its affiliates. All rights reserved.