04 BO Elements

4
Business Objects
Copyright 2009, Oracle. All rights reserved.
Business Objects Are Logical Views of Maintenance Objects

MOs are abstract to handle disparate
requirements (for example, the Person object
doesnt have a column called "daytime phone")
Business objects are not abstract, notice

how each has specific fields
Person Maintenance Object (MO)
Person
Person
Name
Person
Char
Person Id
Person
Phone
Id Type
Phone Type
Char Type
Individual Taxpayer
Busines
s
Objects
Legal name
ID (e.g. drivers license)
Commercial Customer
Birth date
Name
Spouse
Tax ID
Number of dependents
Daytime phone Primary SIC code
Evening phone Accounting phone nbr
Service phone nbr
Mailing address
Mailing address
Credit issues address
They closely represent the business

They are easy to access using the configuration tools (i.e.,
you can easily add, change, delete and read BOs)
They are true subclasses of the MO and therefore take advantage of the
rich, safe, and sophisticated business rules embodied in the base-package
MOs
4-2
Foreshadowing One Reason To Create A BO Is To

Simplify The Users Experience
This page shows the person
MAINTENANCE OBJECT
This zone shows a customer BUSINESS

OBJECT (and it's fairly easy to create this
zone after you've set up a business object)
4-3
Foreshadowing Other Reasons To Use BO's

BO's are much more than visual definitions of objects;
you'll soon find out that you can:
Introduce BO-specific business rules without coding in Java
Populate and retrieve effective-dated attributes without
complicated joins to effective-dated table
Set up default values for BO attributes
Hide base-package attributes that must be populated but aren't of
interest to a customer
Extend objects without the need for new tables and columns
Enable the generation of HTML that reflects each element's data
type
Allow external systems to communicate with our system in a more
natural way (rather than in a 3rd normal form way)
And much more
4-4
An Apology
We've just described some of the many benefits of
business objects
Before we can describe how to take advantage of these
benefits, we have to describe how to configure business
objects
This discussion is long and deals with abstract concepts
We ask you to be patient as you'll soon learn how to "reap
the rewards"
4-5
Business Objects
Maintenance Objects vs. Business Objects

MO's are designed to be
abstract and generic so
that they can be used in
multiple geographies and
vertical markets
Person
Person
Name
Person Id
Individual Taxpayer BO
Individual
Taxpayer ID
Name
E-mail
SSN
Home Phone
Date of Birth
Dependents
4-7
Person
Char
Person
Phone
Business objects are designed

to match the business. For
example, a tax management
implementation could set up
BOs for individual taxpayers,
corporations, partnerships,
etc. rather than work with the
generic person MO
Corporation BO
Corporate
Taxpayer ID
Corporate Name
Employer ID
Main Phone
Date of Incorporation
Corporate Officers
A Maintenance Object Has Fields,

A Business Object Has Elements
We use the term element to describe an individual piece of
information that a BO holds
Foreshadowing - we use this term rather than "field" or "column"
because you communicate with BOs via XML documents (and XML
documents contain elements)
Individual Taxpayer
Individual Taxpayer elements
Taxpayer ID
Name
E-mail
SSN
Home Phone
Date of Birth
Dependents
4-8
Corporation
Corporate Taxpayer elements
Taxpayer ID
Corporate Name
Employer ID
Main Phone
Date of Incorporation
Corporate Officers
A BOs Elements Must Physically Reside

Somewhere In Its MOs Tables
Person (CI_PER)
Individual Taxpayer
Person ID
123
E-Mail
Brazil_Mark@yahoo.com
Names (CI_PER_NAME)
Elements
Taxpayer ID
E-mail
Name (Name)
Name
E-mail
SSN (ID)
Home Phone (Phone)
Work Phone (Phone)
Work Extension
Phone Ext. (Phone)
Date of Birth (Char)
Type
Name
Primary
Brazil, Mark
Ids (CI_PER_ID)
Type
ID Number
SSN
777
Phones (CI_PER_PHONE)
Type
Phone Number
Home
973-777-7777
Work
973-451-7777
Ext
111
Characteristics (CI_PER_CHAR)
4-9
Type
Value
DOB
1961-11-15
Business Objects

A More Technical View
A MO Can have Many BO's,

A BO Is Linked To A Specific MO
Person MO
MO
Individual
A tax management package may use

BO's to define different types of
persons
Partnership
Sole Proprietorship
Business
Object
MO
Corporation
Premise MO
Single family
A utility package may use BO's

to define different types of
premises
4 - 11
Apartment
Business
Object
Multi-unit home single meter
Multi-apartment building
The Base Package May or May Not Have Business

Objects
We'd like to stress that some base-package MO's have
base-package BO's and others don't
It all depends on when the MO was created (older MO's tend not to
have base-package BO's)
And, for newer MO's, it depends on whether we feel a BO could be
used by implementations
Person MO
MO
Base-package data
Implementation data
Individual
Partnership
These have an
owner flag of C1
Business
Object
4 - 12
These have an
owner flag of CM
Business
Object
Sole Proprietorship
Corporation
Refresher: MO Metadata Defines The Physical Tables

MO meta-data defines the physical table structure of an object and the
service used to talk to its instances
MO
Table
Service
MO / Table
Table / Field
Primary
Child
The fields in the MO's XML are

very generic and hierarchical (to
match the abstract / normalized
structure of the MOs tables)
Generic and hierarchical XML, by
definition, does not look like how users
use it (e.g., you wont find Home Phone
or DOB in it)
An MO can have many child tables
(and children can have children)
Field
The fields linked to the MOs Tables
are the physical fields on the
database
4 - 13
XML Doc
Technical Execution
At a high-level, heres how a call to add a BO is
implemented on the server
1
Add new individual taxpayer BO
taxpayerId = null
name = Mark, Brazil
email = abc@yahoo.con
ssn = 1234567
homePhone = 973-451-7777
birthDate = 1970-01-01
Individual
Taxpayer BO
Map Individual
Taxpayer BO XML to
Person MO XML
Person MO
Map Person XML back to
Individual Taxpayer XML
4
Add
6
Individual taxpayer added
taxpayerId = 9999129912
name = Mark, Brazil
email = abc@yahoo.con
ssn = 1234567
homePhone = 973-451-7777
birthDate = 1970-01-01
4 - 14
3
Validate
All business rules applied
Database
Business Objects
Mapping Elements To Physical Locations
A Business Objects Schema

A business objects schema holds the BOs elements
IndividualTaxpayer BO
Business
Object
Every BO has a schema that defines its

elements (you can think of a schema as
the BOs "data definition area")
IndividualTaxpayer Schema
Notice how each element is

surrounded with < />; this is
because weve adopted an XMLlike schema definition language
<taxpayerId />
<name />
<email />
<socialSecurityNumber />
<homePhone />
<birthDate />
In the demo system, we use

"TitleCase" to define BO names and
"camelCase" to define element
names (you can do what you want)
4 - 16
Each Element Must Define Where Its Physically Stored

You declare where BO elements reside in the MOs tables
by declaring mapping rules
MO
Table
MO / Table
Business
Object
Field
Table / Field
<taxpayerId />
<name />
<email />
<homePhone />
<birthDate />
4 - 17
This schema is invalid as

its elements dont have
mapping rules
Mapping Rule Syntax 1

Mapping To Primary Table Columns
Every maintenance object has 1 and only 1 primary table
The mapping rule for an element that physically resides in
a column on the MOs primary table is simple:
mapField="COLUMN_NAME"
Individual Taxpayer Schema
<taxpayerId mapField="PER_ID" />
<name />
<email mapField="EMAILID" />
<homePhone />
<birthDate />
Both of these elements are easy to

map because they reside on the
MOs primary table (CI_PER)
4 - 18
Note, in XML parlance, mapField is

referred to as an "attribute of the element"
Person
Person
Name
Person
Char
Person Id
Person
Phone
Id Type
Phone Type
Char Type
You Must Map Elements To The MO's Prime Key

Every BO must have elements that map to the
constituents of the MO's prime key
As you know, the MO primary table has a "primary key" (defined in
the Table / Constraint meta-data)
PER_ID is the prime key of the person
MO's primary table
Individual Taxpayer Schema
<taxpayerId mapField="PER_ID" />
<name />
<email mapField="EMAILID" />
<homePhone />
<birthDate />
4 - 19
Person
Person
Name
Person
Char
Person Id
Person
Phone
Id Type
Phone Type
Char Type
Use The "Tips"

You've just learned the first schema
mapping attribute: mapField=
There are numerous other schema
mapping attributes that you'll be
exposed to in the upcoming slides
You will not be able to memorize
these as some are sophisticated
You can find a list of all schema
mapping attributes in the tips
These tips provide a list of all valid
schema attributes along with many cut
and paste examples
4 - 20
Click here to see the

documentation of the schema
mapping attributes
The BO Schema Dashboard Zone

The BO Schema zone is used to
populate a BO's schema with
elements mapped to every field on
the MO's tables
After clicking the button, you can add
/ remove / update the schema as
desired
This can save a great deal of time if
the BO's schema is similar to the
MO's data structure
4 - 21
Click to overwrite the BO's

schemas with elements that
match the MO's data structure
Team Walk Through (10 minutes)

Compare a business object to its maintenance object
Break up into teams
Your workbooks provide detailed instructions on how to work
through this exercise
4 - 22
Business Objects
Flattening Elements
Mapping A Flat Element To A Child Table

The remaining elements in our example reside in child tables linked to
the person MO
The mapping syntax to flatten an element is more complicated
<taxpayerId mapField="PER_ID"/>
<name mapField="ENTITY_NAME">
<row mapChild="CI_PER_NAME">
Person
Person
<PRIM_NAME_SW is="true"/>
Char
<NAME_TYPE_FLG default="PRIM"/>
</row>
Person
Person
</name>
Name
Person Id
Phone
<email mapField="EMAILID"/>
<socialSecurityNumber mapField="PER_ID_NBR">
<row mapChild="CI_PER_ID">
Phone Type Char Type
Id Type
<ID_TYPE_CD is="SSN"/>
</row>
<socialSecurityNumber/>
mapField= identifies the column
<homePhone mapField="PHONE" >
where the elements value resides
<row mapChild="CI_PER_PHONE">
<PHONE_TYPE_CD is="HOME" />
The row node defines the child tables name (mapChild=)
</row>
</homePhone>
...
And finally, you must identify the row's identifying column(s) and value(s)
4 - 24
is= versus default=

is= uniquely identifies the row that holds the elements value
default= defines the default values of other columns on the row
is= also defines the default
values of the identifying columns
is= means that the element mapped to the row on the

CI_PER_NAME where PRIM_NAME_SW = Y is returned

...
<PRIM_NAME_SW is="true" />
</row>
</name>
...
Person
Person
Name
This mapping means that 3 fields will be populated on

CI_PER_NAME when this BO element is added:
ENTITY_NAME (holds the entered / supplied name)
PRIM_NAME_SW is set to Y
NAME_TYPE_FLG is set to PRIM (primary)
4 - 25
Person
Char
Person Id
Person
Phone
Id Type
Phone Type
Char Type
Business Objects
When More Than 1 Element

Resides On The Same Row
Mapping Multiple Elements To The Same Row

Our example has two elements that reside on the same
row: workPhone and workExtension
...
<workPhone mapField="PHONE" >
<row mapChild="CI_PER_PHONE">
<PHONE_TYPE_CD is="WORK" />
</row>
</workPhone>
<workExtension mapField="EXTENSION"
rowRef="workPhone" />
...
Person
Person
Name
Person Id
Person
Phone
Id Type
Phone Type
This means that workExt resides on the same row as workPhone

(i.e., on the CI_PER_PHONE row where PHONE_TYPE_CD
="WORK")
rowRef= saves you from defining the mapping again (and this
saves lots of time when many elements live on the same row)
4 - 27
Person
Char
Char Type
Business Objects
Mapping Elements To Effective Dated Tables
Elements Residing In An Effective-Dated Table

Some child tables have an effective date in their prime key
This structure allows the system to maintain the value over time in case of retro-active calculations
If an element resides in an "edated" table, you must decide if you care about changes over time
If you dont care (i.e., you dont want different rows created when the elements value changes)
...
<riskCategory mapField="ADHOC_CHAR_VAL" >
<row mapChild="CI_PER_CHAR">
<CHAR_TYPE_CD is="RISKCAT" />
<EFFDT default="%CurrentDate" />
</row>
</riskCategory>
...
Person
Person
Name
This means the riskCategory element will have its

effective date defaulted to the date when its first created
(and this date will not change if the category is
subsequently updated)
4 - 29
Person
Char
Person Id
Person
Phone
Id Type
Phone Type
Char Type
If Effective Date Matters

If you do care (i.e., you want all changes to be recorded as
separate rows in the table)
If this BO is read and riskEdate is populated,
Notice that default= is not used, rather
is= is used (with a reference to the
element that holds the effective date)
...
<riskCategory mapField="ADHOC_CHAR_VAL" >
<CHAR_TYPE_CD is="RISKCAT" />
<EFFDT is="%effectiveDate(riskEdate)" />
</row>
</riskCategory>
<riskEdate mapField="EFFDT" rowRef="riskCategory"/>
...
the value effective on the that date is

retrieved (otherwise, the value effective on
the current date is retrieved)
Person
Person
Name
Notice that mapField= references the column that holds the effective
date; also notice the rowRef= references the effective-dated element
4 - 30
Person
Char
Person Id
Person
Phone
Id Type
Phone Type
Char Type
Business Objects
Mapping Elements To Language Tables
You Don't Have To Flatten Attributes On Language

Tables
If an element resides on the primary table's "language
table", you don't have to flatten it
...
<phoneType mapField="PHONE_TYPE_CD"/>
<phoneFormat mapField="PHONE_FMT_ALG_CD"/>
<version mapField="VERSION"/>
<description mapField="DESCR"/>
Phone Type Object (MO)
The DESCR column is not on the primary table, but it

doesn't require a flattening syntax as the framework knows
to look on the primary table's language table if it can't find
the field on the MO's primary table
4 - 32
Phone
Type
Language
Language
Business Objects
Validation and Defaulting
dataType=
If you want the system to validate that an elements value
holds a specific type of data, use dataType=
Use the "tips" to see all of the valid dataTypes
Note: dataType="lookup" / lookup= can be used to define valid
values for an element in a lookup value
...
<birthDate mapField="ADHOC_CHAR_VAL"
dataType="date">
<CHAR_TYPE_CD is="BIRTHDT" />
</row>
</birthDate>
...
4 - 34
This means the system will validate that

birthDate is in system format (YYYY-MM-DD)
before a person is added or updated
Person
Person
Name
Person
Char
Person Id
Person
Phone
Id Type
Phone Type
Char Type
dataType= vs mdField=
Rather than use dataType=, you can use mdField= and reference the
meta-data field whose format controls how the fields value is
validated
Both do the same thing - the bottom

means that youve created a meta-data
field with a type of "date" and a label of
"Birth Date"; this is more work up front, but
you discover later in this course that this
allows for a multi-lingual and translatable
application
For base-package development, every
element that doesn't map to a "true
column" must have an mdField= attribute,
no exceptions (otherwise the system won't
be translatable or multi-lingual)
4 - 35
...
dataType="date">
</row>
</birthDate>
...
...
mdField="BIRTH_DT">
...
</birthDate>
...
fkRef=
If you want the system to validate that an elements value holds a
foreign key, use fkRef=
The attributes value must reference a "FK reference code" (a FK reference
is meta-data that describes a foreign key)
...
<primaryContract mapField="CHAR_VAL_FK1" fkRef="SA" >
<CHAR_TYPE_CD is="PRIMCON" />
</row>
</propertyManager>
...
Person MO
Person
Name
While the MO logic will validate this char value is a

FK (as per the char type), the error message will
be "nasty" (it'll reference the char type). The above
technique means you'll get a good message
4 - 36
Person
Person
Char
Person Id
Person
Phone
Id Type
Phone Type
Char Type
dataType= Cannot Contradict Physical Field Rules

You cannot contradict the physical field's actual data type
(except for physical fields that are defined as strings)
For example, if a physical field is defined as being a date,
you can't put a number into it; same goes for physical
fields that are foreign keys, lookups, etc.
Good rules of thumb are:
If you've used mdField= on an element, don't use dataType=
If you've mapped an element to a non-generic column (e.g.,
START_DT) using mapField=, don't use dataType=
4 - 37
required="true"
If you want the system to validate that an element is
present and non-blank, use required="true"
...
dataType="date" required="true" >
</row>
</birthDate>
...
This means the system will make sure that

birthDate is supplied (and a valid date)
Person
Person
Name
4 - 38
Person
Char
Person Id
Person
Phone
Id Type
Phone Type
Char Type
Defaulting
On the earlier flattening slides, you saw how you can
default the values of related columns on a flattened
element's row using is= and default=
This will default the value of customerType on
an add and update (i.e., it can't be blanked out)
...
dataType="date" >
</row>
</birthDate>
...
This mapping means that 2 fields on the

flattened row will be defaulted:
CHAR_TYPE_CD is set to BIRTHDT
EFFDT is set to current date
4 - 39
ResidentialAccount Schema
...
<customerType mapField="CUST_CLASS_CD"
required="true" default="R" />
<mngGroup mapField="ACCT_MGMT_GRP_CD"
default="ALL" />
...
This will default the value of mngGroup on

an add (to ALL), but not on an update (i.e.,
they could "blank it out" on an update)
Defaulting System Variables

You've seen one system variable being defaulted so far
(%CurrentDate)
There are other variables (check them out in the tips)
4 - 40
Business Objects
Other Types of Elements
Groups of Elements
The elements encountered up to now are classic "fields" and dont
require you to declare their type (type=field is the default)
You can declare other types of elements, well first describe
type=group
Groups allow you to document
groups of other elements
Notice the type= attribute, also notice
how this element is not mapped
...
<homeAddress type="group">
<country mapField="COUNTRY" default="USA"/>
<address1 mapField="ADDRESS1"/>
Besides elegance, the other reason (that
youll discover later) is that you can move
<city mapField="CITY"/>
a group to a similar group in a single
<postal mapField="POSTAL"/>
<state mapField="STATE"/>
statement (i.e., you can do a "move by
<homeAddress />
name" from one group to another)
...
4 - 42
Lists = Array
You can also declare arrays of elements (and arrays within
arrays) using type=list
An element where type=List declares
the structure of an array (this
example is for an array of seasonal
addresses)
...
<seasonalAddress type="list"
mapChild="CI_PER_ADDR_SEAS">
<country mapField="COUNTRY" default="USA"/>
<address2 mapField="ADDERSS2"/>
<city mapField="CITY"/>
<postal mapField="POSTAL"/>
<state mapField="STATE"/>
<seasonStart mapfield="SEASON_START_MMDD"/>
<seasonEnd mapfield="SEASON_END_MMDD"/>
<sequence mapfield="SEQ_NUM"/>
<seasonalAddress />
...
4 - 43
Notice the mapChild= attribute (it

defines the table that the array lives
on)
Business Objects
Naming Conventions
BO Naming Convention
All base-package BO's have a code in the format XX-Yyyy

where:
XX is the owner flag
Yyyy is the BO's description; if multiple words are used, use title
case
For example:
F1-Country
C1-CustomerContact
A2-Message121
4 - 45
Element Naming Convention

All base-package elements will use camelCase, for example:
customerName
postalCode
accountId
saId
Abbreviations are not used because developers always have different

abbreviation standards and avoiding them makes it easier to avoid
inconsistencies between schemas
One exception - abbreviations in the common TUGBU parlance are allowed, like bo,
Id, etc.
Words like 'code', 'switch', or 'flag', are generally not appropriate as suffixes
for an element name
The following is not a naming convention, but it bears repeating - every
element that can appear on a UI must have some type of mapping to a metadata field (either via mapField= or mdField=), no exceptions
Without this, we don't have a translatable label for this field and this is a requirement
for base-package deliverables
4 - 46

Break up into
teams and
prepare a list of
what's wrong
and what's
right about this
schema?
4 - 47
F1-emailMsg Schema
...
<OutboundMsgStatFlg mapField="OUTMSG_STATUS_FLG"/>
<CreationDttm dataType="dateTime" mapField="CRE_DTTM"/>
<EmailDocument type="group" mapXML="XML_SOURCE">
<From type="group">
<InternetAddress type="group">
<address mdField="EMAILID"/>
<personal dataType="string"/>
<charset dataType="string"/>
</InternetAddress>
</From>
<To type="list">
<InternetAddress type="group">
<address mdField="EMAILID" isPrimeKey="true"/>
<personal dataType="string"/>
</InternetAddress>
</To>
<Subject type="group">
<text dataType="string"/>
</Subject>
...
Business Objects
Concurrency Checks When BOs Are Updated
If An Element Is Mapped To Version, Concurrency

Checking Will Take Place
If a BO is changed and the system sees it has an element mapped to
VERSION, it will abort the change if the MOs VERSION is not identical
to the BOs version (the MOs version is changed when its updated)
<NAME_TYPE_FLG default="Primary"/>
</row>
</name>
<version mapField="VERSION" />
Person
Person
Name
If you dont include this, no concurrency

validation will take place when the BO is
updated (and you might want this)
4 - 49
Person
Char
Person Id
Person
Phone
Id Type
Phone Type
Char Type
Business Objects
Populating Base Package Fields That You Dont Want

Anyone To Know About
Populating and Hiding MO Fields

Mark an element as private="true" if you dont want the
element exposed to invokers of the BO
</row>
</name>
...
<perBusFlag mapfield="PER_OR_BUS_FLG"
default="P" private="true" />
...
Person
Person
Name
When an IndividualTaxpayer is added, its

PER_OR_BUS_FLG column will be populated with P
(person) and because private="true", this element will never
appear in the XML representation of the business object
4 - 51
Person
Char
Person Id
Person
Phone
Id Type
Phone Type
Char Type
Business Objects
Mapping Elements To
Character Large Object (CLOB) Columns
Refresher: XML Extensions

A subset of tables have a column that holds an XML
document (this column is referred to as a CLOB)
Business objects can be configured to store elements in
this XML document (rather than in individual columns)
The next sections describe how this is done
Person
CLOB
4 - 53
Remember, when you see this on an ERD,

it means that this table contains a CLOB
Access to Fields Stored in a

Character Large Object (CLOB)
A CLOB is very, very large column on a table that is part of a
maintenance object
A trend going forward is to allow business objects to have elements
that are stored in the MO's CLOB
For example,
Market message and tax form objects have a CLOB on their primary table
This CLOB contains an XML document which, in turn, contains the
message / forms data
Whenever a message / form is created, the vast majority of the field values
are stored in the CLOB (in an XML document)
You'll find that CLOBs support all of the element structures that you've
learned up to now
This means that if the physical tables don't have a place to store your
elements, you can put them in a CLOB
But you can only do this for MO's that have CLOBs
4 - 54
Mapping Fields Residing in a CLOB

The mapping syntax is very simple for elements held in a
CLOB:
Use the mapXML="x" to map an element into a CLOB (where x is the
name of the CLOB's column)
A Snippet Of A Market Message Schema
...
<messageTypeCode mapXML="BO_DEFN_AREA" />
<versionNumber mapXML="BO_DEFN_AREA" />
<marketTimeStamp mapXML="BO_DEFN_AREA" />
<senderID mapXML="BO_DEFN_AREA" />
<recipientID mapXML="BO_DEFN_AREA" />
<txRefNbr mapXML="BO_DEFN_AREA" />
...
Inbound
Message
CLOB
These elements are stored in a CLOB

column called BO_DEFN_AREA that
resides on the inbound message table
4 - 55
If You Were To Look At The Contents Of The CLOB

Youd see XML
The BOs schema
...
<messageTypeCode mapXML="BO_DEFN_AREA" />
<txRefNbr mapXML="BO_DEFN_AREA" />
...
Inbound
Message
CLOB
<messageTypeCode>AA-101</messageTypeCode>
<versionNumber>123</versionNumber>
...
4 - 56
How a given messages CLOB

looks (this is just simple xml)
XML Elements Can Be Validated Just Like Other

Elements
If an element held as XML is anything other than a string, you should declare either an mdField= attribute or a dataType= attribute
(remember, if the element can appear on a UI, you MUST use mdField= in order to have the system produce a translatable label)
If an element is mandatory, declare required="true"
This works the same way as described earlier
So, if you don't want this validation to take place, don't specify these attributes

...
<messageType mapXML="BO_DEFN_AREA" mdField="MSG_TYPE_CD" required="true" />
Notice how we properly used mdField=
rather than dataType=
<taxReferenceNumber mapXML="BO_DEFN_AREA" />
<receiveDate mapXML="BO_DEFN_AREA" mdField="RCV_DT" />
...
4 - 57
CLOB vs Characteristics
The rule - if you need to "join" to an element value, it needs
to reside in a real column
A Snippit Of A Market Message Schema
Inbound
Message
CLOB
Char Type
Charact.
Because we will likely have an SQL join

to a cases SA ID, you need to put it into
a characteristic rather than the CLOB
(can't have indexes for elements in
CLOB's (at least not today))
4 - 58
...
<messageType mapXML="BO_DEFN_AREA" />
<senderId mapXML="BO_DEFN_AREA" />
<recipientId mapXML="BO_DEFN_AREA" />
<taxReferenceNumber mapXML="BO_DEFN_AREA" />
<receiveDate mapXML="BO_DEFN_AREA" dataType="date" />
<serviceAgreementId mapField="FK_CHAR_VAL" >
<row mapChild="CI_CASE_CHAR">
<CHAR_TYPE_CD is="SA ID" />
</row>
</serviceAgreementId>
...
Business Objects
Other Element Types Can Be Held In A CLOB
Groups of Elements
Groups and lists can be held in a CLOB
We'll first show a type="group":
...
<messageHeader type="group" mapXML="BO_DEFN_AREA" >
<messageTypeCode required="true" />
<versionNumber required="true" />
<marketTimeStamp required="true" />
<senderID required="true" />
<recipientID required="true" />
<txRefNbr required="true" />
</messageHeader>
4 - 60
Groups allow you to nicely document

groups of other elements
Notice that you only have to define the
mapXML= once for the group (if you
recall the earlier discussion of groups,
you had to declare a mapField on each
member of the group)
Besides elegance, you'll learn later that
you can move a group to a similar group
in a single statement
If You Were To Look At The Contents Of The CLOB

Youd see XML
The BOs schema
...
<messageHeader type="group" mapXML="BO_DEFN_AREA">
<messageTypeCode mdField="MSG_TYPE_CD"/>
<versionNumber />
<marketTimeStamp dataType="dateTime"/>
<senderID />
<recipientID />
<txRefNbr />
</messageHeader>
...
<messageHeader>
<messageTypeCode>ASDF</messageTypeCode>
<versionNumber>123</versionNumber>
...
</messageHeader>
4 - 61
Inbound
Message
CLOB
Notice the group node
Multiple Groups In The Same CLOB

You can keep an unlimited number of groups in the CLOB
...
<messageHeader type="group" mapXML="BO_DEFN_AREA">
<messageTypeCode required="true" />
<versionNumber required="true" />
<marketTimeStamp required="true" />
<senderID required="true" />
<recipientID required="true" />
<txRefNbr required="true" />
</messageHeader>
<BGTReference type="group" mapXML="BO_DEFN_AREA">
<bgtSystemRefNumber required="true" />
<shipperRefNumber required="true" />
<gprn required="true" />
<shipperId required="true" />
<supplierId required="true" />
</BGTReference>
Inbound
Message
CLOB
Notice how both groups of elements

are mapped to the same CLOB
...
4 - 62
Lists = Array
You can also declare arrays of elements (and arrays within
arrays) using type="list"
An element where type="list"
...
<seasonalAddress type="list"
<country default="USA"/>
<address1 />
<address2 />
<city />
<postal />
<state />
<seasonStart />
<seasonEnd />
<sequence />
<seasonalAddress />
...
4 - 63
declares the structure of an array

(this example is for an array of
seasonal addresses)
mapXML="BO_DEFN_AREA">
Notice the mapXML= attribute (it is

only declared on the list)
Why is this example bad? Because
the likelihood that these fields will
appear on a UI is very high and there
are no mdField= attributes on each
element.
CLOB's Aren't Everywhere

Most post 2.2 MO's support CLOBs
There are some older MO's that support CLOBs; however,
the number is limited (due to time constraints)
In future releases, you will find them on more MO's
4 - 64

Examine a BO that uses a CLOB
Break up into teams
Your workbooks provide detailed instructions on how to work
through this exercise
4 - 65
Business Objects
Raw Data Types
Foreshadowing
You can create elements that reside in a CLOB using
type="raw"
These elements are created when you need to save XML
documents within an XML document
For example, in a market message world, we frequently
need to save the message that was sent into the system in
the exact format in which it was received
To do this, you can create a raw element called something
like originalMessage and define it as type="raw"
There are other more interesting examples of raw
elements that will be described much later in the class
4 - 67
Business Objects
Standalone Data Areas Allow Reuse
Data Area Schema

If you have multiple BOs that share a common structure, you can set up
a "stand alone data area" schema and then include it in each BO
Form1040a BO Schema
StandardTaxpayerElements Standalone Schema

<standardTaxpayerElements type="group"
<ssn />
<lastName />
<firstName />
<address1 />
<address2 />
...
</standardTaxpayerElements>
This standalone data area can be

included in other schemas
Note, this is a real-time include and therefore
when the standalone schema is changed, all
using schemas are "changed"
4 - 69
<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
default="1040ez.07" />
<1040ezpage1 type="group" mapXML="BO_DEFN_AREA">
<1040ezpage1/>
Schema Business Rules

Recall that simple business rules can be defined in a schema
Form1040a BO Schema
StandardTaxpayerElements Standalone Schema

<standardTaxpayerElements type="group"
<ssn required="true" />
<lastName required="true" />
<firstName />
<address1 />
<address2 />
...
</standardTaxpayerElements>
Any business rule defined in the

schema applies to any BO that
includes it
default="1040a.07" />
<1040page1 type="group" mapXML="BO_DEFN_AREA">
<1040page1/>
Form1040ez BO Schema
default="1040ez.07" />
<1040ezpage1 type="group" mapXML="BO_DEFN_AREA">
<1040ezpage1/>
4 - 70
Mapping To Fields That Aren't In CLOBs

Please be aware that a stand-alone data area can hold
elements that are mapped to true columns
For example, you might have 50 different types of field
activities and all might have a common structure to
identify where and when the activity should take place
It would be wise to declare the elements that are the same
on all fields activities in a stand-alone data area and then
include this in the 50 field activity BO's
4 - 71
Data Area Schema

Foreshadowing in future chapters, you'll learn about
business services and service scripts
Both of these objects have their data defined in a schema
It's strongly recommended that you take advantage of stand-alone
data areas to avoid redundant data definitions
Also note, a stand-alone data area schema can reference

other stand-alone schemas (if you're really keen on
avoiding redundancy)
4 - 72
Business Objects
Performance
If You Have Large BO's

Let's assume you have BO's with many elements from
many tables
If you find that you need a small subset of the fields in the
majority of your data access and update requests, you
should consider creating a "scaled down" version of the
BO that only has the subset of fields
This helps performance because the system only
performs the IO to retrieve the elements on the specified
BO (not on its underlying MO)
4 - 74
Business Objects
XAI
Exposing BO's To The World

It's very easy to create an XAI service so that the outside
world can read, add, change and delete BO's
Just use the context menu entry on the BO
4 - 76
Business Objects
Summary
MO's and BO's

At this point you know that MO's are physical
representations of the system's objects
You also know that you can declare an unlimited number
of BO's for each MO (where each BO defines a logical type
of the MO)
And this can be done using meta-data; there are no database
changes required or new Java classes to author
The benefits are beginning to be unveiled (e.g., easy way

to validate subclasses, easy way to retrieve and update
data in our highly normalized databases)
More benefits will be unveiled in future chapters
4 - 78

Compare a BO with the blueprint design
4 - 79
Break up into teams and follow the instructions in the workbook
Review Questions
4 - 80
4 - 81

04 BO Elements

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

04 BO Elements

Загружено:

Авторское право:

Доступные форматы

4

Copyright 2009, Oracle. All rights reserved.

Business Objects Are Logical Views of Maintenance Objects

Business objects are not abstract, notice

Person Maintenance Object (MO)

They closely represent the business

Copyright 2009, Oracle. All rights reserved.

Foreshadowing One Reason To Create A BO Is To

This zone shows a customer BUSINESS

Copyright 2009, Oracle. All rights reserved.

Foreshadowing Other Reasons To Use BO's

Copyright 2009, Oracle. All rights reserved.

Copyright 2009, Oracle. All rights reserved.

Maintenance Objects vs. Business Objects

Copyright 2009, Oracle. All rights reserved.

Maintenance Objects vs. Business Objects

Person Maintenance Object (MO)

Business objects are designed

Copyright 2009, Oracle. All rights reserved.

A Maintenance Object Has Fields,

Copyright 2009, Oracle. All rights reserved.

A BOs Elements Must Physically Reside

Copyright 2009, Oracle. All rights reserved.

Maintenance Objects vs. Business Objects

Copyright 2009, Oracle. All rights reserved.

A MO Can have Many BO's,

A tax management package may use

A utility package may use BO's

Multi-unit home single meter

Copyright 2009, Oracle. All rights reserved.

The Base Package May or May Not Have Business

Copyright 2009, Oracle. All rights reserved.

Refresher: MO Metadata Defines The Physical Tables

The fields in the MO's XML are

Copyright 2009, Oracle. All rights reserved.

Copyright 2009, Oracle. All rights reserved.

Mapping Elements To Physical Locations

Copyright 2009, Oracle. All rights reserved.

A Business Objects Schema

Every BO has a schema that defines its

Notice how each element is

In the demo system, we use

Copyright 2009, Oracle. All rights reserved.

Each Element Must Define Where Its Physically Stored

Copyright 2009, Oracle. All rights reserved.

This schema is invalid as

Mapping Rule Syntax 1

Both of these elements are easy to

Note, in XML parlance, mapField is

Person Maintenance Object (MO)

Copyright 2009, Oracle. All rights reserved.

You Must Map Elements To The MO's Prime Key

Person Maintenance Object (MO)

Copyright 2009, Oracle. All rights reserved.

Use The "Tips"

Copyright 2009, Oracle. All rights reserved.

Click here to see the

The BO Schema Dashboard Zone

Copyright 2009, Oracle. All rights reserved.

Click to overwrite the BO's

Team Walk Through (10 minutes)

Copyright 2009, Oracle. All rights reserved.

Copyright 2009, Oracle. All rights reserved.

Mapping A Flat Element To A Child Table