Professional Documents
Culture Documents
3-1
Agenda
This section reviews important concepts from the Config Tools
training class
2-2
4-Tier Architecture
3-3
Web
Server
Application
Server
2-4
DB
Entity Relationship
Diagramming Standards
2-5
Contact /
SP
2-6
Service
Point
Time
Zone
Legend
Lookup
Child Table
Related
Object
Activity
ST, CH, X
Tran. Data
Admin Data
Master Data
FW Data
2-7
Table /
Field
Constraint
Constraint
/ Field
Field
2-8
2-9
2 - 10
2 - 11
3 - 12
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
Prime Keys
The prime key of most
"admin" tables is a userassigned mnemonic
Contact
Type
Contact
Contact /
ID
ID Type
2 - 14
PK is gold
FKs are
blue
2 - 15
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
Maintenance Objects
3 - 17
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
MO Def /
Table
MO
Table / Field
Field
2 - 19
2 - 21
3 - 22
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
...
Volts
= 240
SP / Char
Char
Type
2 - 24
Predefined
Value
2 - 25
Ad hoc
Value
Foreign Key
Reference
File
Location
Gender
Male
Female
2 - 26
Predefined
Value
Ad hoc
Value
Foreign Key
Reference
Valid Value
File
Location
Defined
Value
2 - 27
Ad hoc
Value
Char
Type
Foreign Key
Reference
File
Location
Defined
Value
Ad hoc
Value
Property
manager
Foreign Key
Reference
File
Location
2 - 28
FK
Reference
Defined
Value
2 - 29
Ad hoc
Value
Foreign Key
Reference
Customers
Contract
File
Location
2 - 30
SP / Char
Char Type
Entity
Char Type
/ Entity
2 - 31
Values:
- Contact
- Service Point
- Device
- Usage Subscr.
- etc
Data Ownership
3 - 32
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
2 - 34
Installation FW
Field
Owner Flag
Table
Char Type
metadata
2 - 35
Owner Flag
2 - 36
Installation FW
2 - 37
2
Security
3 - 38
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)
Application
Service
User Group
User Group /
App Svc
2 - 40
User Group /
User
User
A user's membership
in a user group has
an expiration date
Valid Action
User Group
User Group /
App Svc
Permissible
Action
2 - 41
User
User Group /
User
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
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
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
Business Objects
3 - 45
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
Commercial
Contact BO
Corporate
Contact ID
Corporate Name
Employer ID
Main Phone
Date of Incorporation
Corporate Officers
2 - 47
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
2 - 49
2 - 50
3 - 51
2 - 52
Service
Point
SP / Char
Char
Type
XML
2 - 53
2 - 54
Validation Rules
Ad
BO d
Individual Taxpayer
Ad
M d
O
Enter
2. MO Processing
2 - 55
Exit
Person MO
(Service)
3. Validation algorithms
Programming
Language
Business
Object
BO
Algorithm
2 - 56
3
4
Algorithm
1
2
Algorithm
Type
In
vo
BO ke
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
BO Hierarchies
3 - 58
lastName
firstName
driversLicense
2 - 59
BO: CommercialContact
businessName
employerIdentityNbr
Post Processing: Send
welcome letter on add
BO: ResidentialCustomer
2 - 60
lastName
firstName
driversLicense
BO: CommercialContact
businessName
employerIdentityNbr
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)
BO: ResidentialContact
2 - 61
lastName
firstName
driversLicense
BO: CommercialContact
businessName
employerIdentityNbr
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
3 - 63
BO: Contact
Owner: D1 (Meter Data Foundation)
<name ... />
<customerId ... />
...
2 - 64
BO: Contact
Owner: D1
<name ... />
<customerId ... />
...
BO: MyContact
Owner: CM
<includeBO name="Customer" />
<employerIdentityNumber ... />
<marketingContact ... />
...
BO: HumanCustomer
lastName
firstName
driversLicense
BO: BusinessCustomer
Post Processing: Check
credit history
BO: CorporateCustomer
2 - 66
BO: PartnershipCustomer
BO: GenericCustomer
Owner: D1
Owner: D1
Post Processing: Send welcome letter on add
BO: BusinessCustomer
Owner: D1
Owner: D1
Post Processing: Check credit history
Owner: CM
Post Processing: Create To Do entry
2 - 67
2 - 68
3 - 69
Literature
Sent
Lodged
Preliminary
Investigation
Follow Up
Not Interested
Refer To
Salesperson
Canceled
Investigation
In Progress
Decision
Checkpoint
Cancel / Rebill
Approved
2 - 70
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
Exit
Error
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)
Canceled
Monitor
2 - 73
BO / State /
Algorithm
Algorithm
System
Event
Algorithm
Type
Valid Values:
Enter
Exit
Monitor
2 - 74
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
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
Inheriting Lifecycle
3 - 77
You have many different types of field activities (install meter, investigate
service theft, read meter, remove meter, exchange meter, )
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
Complete
BO: InstallMeter
2 - 79
BO: RemoveMeter
BO: ReadMeter
Complete
BO: InstallMeter
BO: InstallComplexMeter
2 - 80
BO: ReadMeter
BO: InstallSimpleMeter
Complete
BO: InstallMeter
Status: Complete
System Event: Enter
Algorithm: Create
Installation Charge
2 - 81
BO: InvestiSvcTheft
BO: ReadMeter
2
Check Point
3 - 82
System
Event
BO
Algorithm
BO /
Algorithm
System
Event
Valid
Status
BO / State /
Algorithm
2 - 83
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
1. Pre-processing rules
Exit
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.
2 - 84
Entity Relationship
Diagramming Standards Revisted
2 - 85
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
Service
Point
ST, CH, X
XML
Disconnect
Warning
Ext
Legend
Lookup
Child Table
Tran. Data
Admin Data
Master Data
FW Data
ST - Status
CH - Characteristics
X - CLOB
2 - 87
3 - 88
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)
2 - 89
Review Questions
2 - 90