05 - BO Elements

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 Business objects are not abstract, notice
"daytime phone") how each has specific fields
Person Maintenance Object (MO)

Individual Taxpayer
Legal name
Person
ID (e.g. drivers license)
Person
Business Birth date Business Taxpayer
Char
Objects Spouse Name
Person
Name Person Id
Person Tax ID
Number of dependents
Daytime phone Primary SIC code
Phone

Evening phone Accounting phone nbr
Id Type Phone Type Char Type Mailing address Service phone nbr
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
5-2 Copyright 2009, Oracle. All rights reserved.

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

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"

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 Person
Person Business object are designed
vertical markets Char
to match the business. For
Person example, a tax management
Name Person
Person Id
Phone implementation could set up
BOs for individual taxpayers,
corporations, partnerships, etc.
rather than work with the
generic person MO
Individual Taxpayer BO Corporation BO

Individual Corporate
Taxpayer ID Taxpayer ID
Name Corporate Name
E-mail Employer ID
SSN Main Phone
Home Phone Date of Incorporation
Date of Birth Corporate Officers
Dependents

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 Corporation

Individual Taxpayer elements Corporate Taxpayer elements
Taxpayer ID Taxpayer ID
Name Corporate Name
E-mail Employer ID
SSN Main Phone
Home Phone Date of Incorporation
Date of Birth Corporate Officers
Dependents

A BOs Elements Must Physically Reside
Somewhere In Its MOs Tables
Person (CI_PER)
Person ID 123
E-Mail Brazil_Mark@yahoo.com
Individual Taxpayer
Names (CI_PER_NAME)
Type Name
Elements
Primary Brazil, Mark
Taxpayer ID
Name (Name)
E-mail Ids (CI_PER_ID)
E-mail
Name Type ID Number
SSN (ID) SSN 777
Home Phone (Phone)
Phones (CI_PER_PHONE)
Work Phone (Phone) Type Phone Number Ext
Work Extension
Phone Ext. (Phone) Home 973-777-7777
Date of Birth (Char) Work 973-451-7777 111

Characteristics (CI_PER_CHAR)
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 "person types" Partnership
Sole Proprietorship
Business
Object Corporation
Form MO
MO
Income Tax
Sales & Use

Tax agencies can have many tax
forms Corp Income Tax
Business
Object
5 - 11 Copyright 2009, Oracle. All rights reserved.

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 These have an owner

MO
flag of CM
Base-package data Implementation data Individual
Partnership
These have an
owner flag of C1 Sole Proprietorship
Business
Business
Object Corporation
Object

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
Table MO Service XML Doc

MO / Table
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

Table / Field Primary Child 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

Field (and children can have children)
The fields linked to the MOs Tables are

the physical fields on the database

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 Individual
name = Mark, Brazil Taxpayer BO 2
email = abc@yahoo.con Map Individual
ssn = 1234567 Taxpayer BO XML
homePhone = 973-451-7777
to Person MO XML
birthDate = 1970-01-01
5 Person MO
Map Person XML back to
Individual Taxpayer XML 4 Database
6 Add
Individual taxpayer added
taxpayerId = 9999129912 3
name = Mark, Brazil Validate
email = abc@yahoo.con
ssn = 1234567 All business rules applied
homePhone = 973-451-7777
birthDate = 1970-01-01

Business Objects
Mapping Elements To Physical Locations

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

IndividualTaxpayer BO elements (you can think of a schema as
Business the BOs "data definition area")
Object
IndividualTaxpayer Schema
<taxpayerId />
<name />
<email />
<socialSecurityNumber />
Notice how each element is <homePhone />
surrounded with < />; this is <birthDate />
because weve adopted an XML-
like schema definition language
In the demo system, we use

"TitleCase" to define BO names and
"camelCase" to define element
names (you can do what you want)

Each Element Must Define Where Its Physically Stored
You declare where BO elements reside in the MOs tables by declaring

mapping rules
MO Table Field
MO / Table Table / Field
Business
Object IndividualTaxpayer Schema
<taxpayerId />
<name />
<email />
<socialSecurityNumber />
<homePhone /> This schema is invalid
<birthDate />
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" Note, in XML parlance, mapField is referred
to as an "attribute of the element"
Individual Taxpayer Schema Person Maintenance Object (MO)

<taxpayerId mapField="PER_ID" />
<name />
<email mapField="EMAILID" /> Person
<socialSecurityNumber /> Person
Char
<homePhone />
<birthDate /> Person
Name Person
Person Id
Phone
Both of these elements are easy to Id Type Phone Type Char Type
map because they reside on the
MOs primary table (CI_PER)

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 Person Maintenance Object (MO)

<taxpayerId mapField="PER_ID" />
<name />
<email mapField="EMAILID" /> Person
<socialSecurityNumber /> Person
Char
<homePhone />
<birthDate /> Person
Name Person
Person Id
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
Click here to see the
attributes in the tips documentation of the
These tips provide a list of all valid schema schema mapping attributes
attributes along with many cut and paste
examples

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">
<PRIM_NAME_SW is="true"/> Person
Person
<NAME_TYPE_FLG default="PRIM"/> Char
</row>
Person
</name> Name Person
Person Id
<email mapField="EMAILID"/> Phone
<socialSecurityNumber mapField="PER_ID_NBR">
<row mapChild="CI_PER_ID">
<ID_TYPE_CD is="SSN"/> Id Type Phone Type Char Type
</row>
<socialSecurityNumber/>
<homePhone mapField="PHONE" >
mapField= identifies the column where the
<row mapChild="CI_PER_PHONE"> elements value resides
<PHONE_TYPE_CD is="HOME" />
</row> The row node defines the child tables name (mapChild=)
</homePhone>
... And finally, you must identify the row's identifying column(s) and value(s)

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 is= means that the element mapped to the row on the
of the identifying columns CI_PER_NAME where PRIM_NAME_SW = Y is returned

...
<name mapField="ENTITY_NAME"> Person
Person
<row mapChild="CI_PER_NAME"> Char
<PRIM_NAME_SW is="true" />
<NAME_TYPE_FLG default="PRIM"/> Person
Name Person
</row> Person Id
Phone
</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)

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
IndividualTaxpayer Schema Person Maintenance Object (MO)

...
<workPhone mapField="PHONE" >
<row mapChild="CI_PER_PHONE">
<PHONE_TYPE_CD is="WORK" /> Person
</row> Person
Char
</workPhone>
Person
<workExtension mapField="EXTENSION" Name Person
Person Id
Phone
rowRef="workPhone" />
...
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)

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)
IndividualTaxpayer Schema Person Maintenance Object (MO)
...
<riskCategory mapField="ADHOC_CHAR_VAL" >
<row mapChild="CI_PER_CHAR">
<CHAR_TYPE_CD is="RISKCAT" />
Person
<EFFDT default="%CurrentDate" /> Person
</row> Char
</riskCategory> Person
... Name Person Id
Person
Phone
This means the riskCategory element will have its
effective date defaulted to the date when its first Id Type Phone Type Char Type
created (and this date will not change if the
category is subsequently updated)

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, the value effective on the that
Notice that default= is not used, rather is= is date is retrieved (otherwise, the value
used (with a reference to the element that effective on the current date is retrieved)
holds the effective date)
...
<riskCategory mapField="ADHOC_CHAR_VAL" >
Person
<row mapChild="CI_PER_CHAR"> Person
<CHAR_TYPE_CD is="RISKCAT" /> Char
<EFFDT is="%effectiveDate(riskEdate)" /> Person
</row> Name Person Id
Person
</riskCategory> Phone
<riskEdate mapField="EFFDT" rowRef="riskCategory"/>
...
Notice that mapField= references the column that holds the effective
date; also notice the rowRef= references the effective-dated element

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
Phone Type Object (MO)

...
<phoneType mapField="PHONE_TYPE_CD"/> Phone
Type
<phoneFormat mapField="PHONE_FMT_ALG_CD"/>
<version mapField="VERSION"/>
<description mapField="DESCR"/>
Language
The DESCR column is not on the primary table, but it Language

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

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
This means the system will validate that

birthDate is in system format (YYYY-MM-
IndividualTaxpayer Schema DD) before a person is added or updated
...
<birthDate mapField="ADHOC_CHAR_VAL"
dataType="date"> Person Maintenance Object (MO)
<CHAR_TYPE_CD is="BIRTHDT" />
<EFFDT default="%CurrentDate" />
</row> Person
Person
</birthDate> Char
...
Person
Name Person
Person Id
Phone

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 dataType="date">
means that youve created a meta- <row mapChild="CI_PER_CHAR">
data field with a type of "date" and a <CHAR_TYPE_CD is="BIRTHDT" />
label of "Birth Date"; this is more work </row>
up front, but you discover later in this </birthDate>
course that this allows for a multi- ...
lingual and translatable application IndividualTaxpayer Schema
...
For base-package development, every element mdField="BIRTH_DT">
...
that doesn't map to a "true column" must have an </birthDate>
mdField= attribute, no exceptions (otherwise the ...
system won't be translatable or multi-lingual)

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" /> Person MO
</row>
</primaryContract>
... Person
Person
Person
Name Char
While the MO logic will validate this char value is a FK Person

Person Id
Phone
(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

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=

required="true"
If you want the system to validate that an element is present and non-
blank, use required="true"
This means the system will make sure that

...
birthDate is supplied (and a valid date)
dataType="date" required="true" >
<row mapChild="CI_PER_CHAR"> Person Maintenance Object (MO)
</row>
</birthDate> Person
Person
... Char
Person
Name Person
Person Id
Phone

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 AccountType on an
add and update (i.e., it can't be blanked out)
...
ResidentialAccount Schema
...
dataType="date" >
<customerType mapField="CUST_CLASS_CD"
required="true" default="R" />
<mngGroup mapField="ACCT_MGMT_GRP_CD"
default="ALL" />
</row>
...
</birthDate>
...
This mapping means that 2 fields on the

flattened row will be defaulted: This will default the value of mngGroup on
CHAR_TYPE_CD is set to BIRTHDT an add (to ALL), but not on an update (i.e.,
EFFDT is set to current date 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)

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
IndividualTaxpayer Schema Notice the type= attribute, also notice
...
<homeAddress type="group"> how this element is not mapped
<country mapField="COUNTRY" default="USA"/>
<address1 mapField="ADDRESS1"/> Besides elegance, the other reason
<address2 mapField="ADDRESS2"/> (that youll discover later) is that you
<city mapField="CITY"/>
<postal mapField="POSTAL"/> can move a group to a similar group in
<state mapField="STATE"/> a single statement (i.e., you can do a
<homeAddress /> "move by name" from one group to
...
another)

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" Notice the mapChild= attribute (it
mapChild="CI_PER_ADDR_SEAS">
<country mapField="COUNTRY" default="USA"/> defines the table that the array lives on)
<address1 mapField="ADDRESS1"/>
<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 />
...

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

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 meta-data 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

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 mapField="ENTITY_NAME"> Person Maintenance Object (MO)
<PRIM_NAME_SW is="true"/>
<NAME_TYPE_FLG default="Primary"/>
</row> Person
Person
</name> Char
<email mapField="EMAILID"/>
Person
<version mapField="VERSION" /> Name Person
Person Id
Phone

If you dont include this, no concurrency validation
will take place when the BO is updated (and you
might want this)

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
<name mapField="ENTITY_NAME">
<PRIM_NAME_SW is="true"/> Person
Person
<NAME_TYPE_FLG default="PRIM"/> Char
</row>
Person
</name> Person
Name Person Id
<email mapField="EMAILID"/> Phone
...
<perBusFlag mapfield="PER_OR_BUS_FLG"
default="P" private="true" /> Id Type Phone Type Char Type
...
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

Business Objects
Mapping Elements To
Character Large Object (CLOB) Columns

Refresher: XML Extensions
A subset of tables have a special column that can hold an XML

document (this column is referred to as a CLOB)
This XML document is meant to be used by implementations to hold
additional attributes
The next sections describe how to use these to hold additional
attributes
Person
Remember, when you see this on an ERD,
CLOB 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
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 cases 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

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" /> Inbound
<marketTimeStamp mapXML="BO_DEFN_AREA" /> Message
<senderID mapXML="BO_DEFN_AREA" />
CLOB
<recipientID mapXML="BO_DEFN_AREA" />
<txRefNbr mapXML="BO_DEFN_AREA" />
...
These elements are stored in a CLOB
column called BO_DEFN_AREA that
resides on the CI_CASE table

If You Were To Look At The Contents Of The CLOB
Youd see XML
A Snippet Of A Market Message Schema The BOs schema
...
<messageTypeCode mapXML="BO_DEFN_AREA" />
<versionNumber mapXML="BO_DEFN_AREA" />
<marketTimeStamp mapXML="BO_DEFN_AREA" />
<recipientID mapXML="BO_DEFN_AREA" /> Inbound
<txRefNbr mapXML="BO_DEFN_AREA" />
... Message
CLOB
<messageTypeCode>AA-101</messageTypeCode>
<versionNumber>123</versionNumber>
... 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" />
<versionNumber mapXML="BO_DEFN_AREA" />
<marketTimeStamp mapXML="BO_DEFN_AREA" />
Notice how we properly used mdField=
<recipientID mapXML="BO_DEFN_AREA" /> rather than dataType=
<taxReferenceNumber mapXML="BO_DEFN_AREA" />
<receiveDate mapXML="BO_DEFN_AREA" mdField="RCV_DT" />
...

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 Message Schema
...
<messageType mapXML="BO_DEFN_AREA" />
Inbound <versionNumber mapXML="BO_DEFN_AREA" />
Message <marketTimeStamp mapXML="BO_DEFN_AREA" />
CLOB
<senderId mapXML="BO_DEFN_AREA" />
<recipientId mapXML="BO_DEFN_AREA" />
<taxReferenceNumber mapXML="BO_DEFN_AREA" />
<receiveDate mapXML="BO_DEFN_AREA" dataType="date" />
Char Type Charact.

<obligationId mapField="FK_CHAR_VAL" >
<row mapChild="CI_CASE_CHAR">
<CHAR_TYPE_CD is="SA ID" />
</row>
Because we will likely have an SQL join </obligationId>
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))

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":
Groups allow you to nicely document

groups of other elements
...
<messageHeader type="group" mapXML="BO_DEFN_AREA" >
<messageTypeCode required="true" />
Notice that you only have to define the
<versionNumber required="true" /> mapXML= once for the group (if you
<marketTimeStamp required="true" /> recall the earlier discussion of groups,
<senderID required="true" />
<recipientID required="true" />
you had to declare a mapField on
<txRefNbr required="true" /> each member of the group)
</messageHeader>
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 /> Inbound
<txRefNbr />
</messageHeader> Message
... CLOB
<messageHeader>
<messageTypeCode>ASDF</messageTypeCode>
<versionNumber>123</versionNumber> Notice the group node
...
</messageHeader>

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" /> Inbound
<versionNumber required="true" />
<marketTimeStamp required="true" /> Message
<senderID required="true" /> CLOB
<recipientID required="true" />
<txRefNbr required="true" />
</messageHeader>
<BGTReference type="group" mapXML="BO_DEFN_AREA">

<bgtSystemRefNumber required="true" />
<shipperRefNumber required="true" />
<gprn required="true" /> Notice how both groups of
<shipperId required="true" />
<supplierId required="true" />
elements are mapped to the
</BGTReference> same CLOB
...

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
IndividualTaxpayer Schema array of seasonal addresses)
...
<seasonalAddress type="list" mapXML="BO_DEFN_AREA">
<country default="USA"/>
<address1 />
<address2 />
<city />
<postal /> Notice the mapXML= attribute (it
<state /> is only declared on the list)
<seasonStart />
<seasonEnd /> Why is this example bad? Because the
<sequence />
<seasonalAddress /> 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

Business Objects
Raw Data Types

Storing Any XML
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

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
<formType mapField="CASE_TYPE_CD"
StandardTaxpayerElements Standalone Schema default="1040a.07" />
<standardTaxpayerElements type="group" <includeDA name="StandardTaxpayerElements"/>

mapXML="BO_DEFN_AREA">
<ssn /> <1040page1 type="group" mapXML="BO_DEFN_AREA">
<lastName /> <line1 dataType="number"/>
<firstName /> <line2 dataType="number"/>
<address1 /> <1040page1/>
<address2 />
...
Form1040ez BO Schema
</standardTaxpayerElements>
default="1040ez.07" />
This standalone data area can
be included in other schemas <includeDA name="StandardTaxpayerElements"/>
<1040ezpage1 type="group" mapXML="BO_DEFN_AREA">

Note, this is a real-time include and therefore <line1 dataType="number"/>
when the standalone schema is changed, all <line2 dataType="number"/>
using schemas are "changed" <1040ezpage1/>

Schema Business Rules
Recall that simple business rules can be defined in a schema
Form1040a BO Schema
StandardTaxpayerElements Standalone Schema default="1040a.07" />
<standardTaxpayerElements type="group" <includeDA name="StandardTaxpayerElements"/>

mapXML="BO_DEFN_AREA">
<ssn required="true" /> <1040page1 type="group" mapXML="BO_DEFN_AREA">
<lastName required="true" /> <line1 dataType="number"/>
<firstName /> <line2 dataType="number"/>
<address1 /> <1040page1/>
<address2 />
...
Form1040ez BO Schema
</standardTaxpayerElements>
Any business rule defined in the default="1040ez.07" />
schema applies to any BO that
<includeDA name="StandardTaxpayerElements"/>
includes it
<1040ezpage1 type="group" mapXML="BO_DEFN_AREA">
<line1 dataType="number"/>
<line2 dataType="number"/>
<1040ezpage1/>

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 tax
forms and all might have a common structure
It would be wise to declare the elements that are the same
on all tax forms in a stand-alone data area and then
include this in the 50 tax form BO's

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)

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)

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

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

Self Service Case Study

Case Study
Self Service Case Study starts here (exercise 1).

Case Study will continue throughout the course.
Case study map will be displayed after each chapter as a
checkpoint.


05 - BO Elements

Загружено:

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

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

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

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

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

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

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

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

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

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

05 - BO Elements

Загружено:

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

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

Business Objects

Copyright 2009, Oracle. All rights reserved.

Person Maintenance Object (MO)

5-2 Copyright 2009, Oracle. All rights reserved.

This zone shows a customer BUSINESS

BO's are much more than visual definitions of objects;

5-4 Copyright 2009, Oracle. All rights reserved.

We've just described some of the many benefits of

5-5 Copyright 2009, Oracle. All rights reserved.

Maintenance Objects vs. Business Objects

Copyright 2009, Oracle. All rights reserved.

Individual Taxpayer BO Corporation BO

5-7 Copyright 2009, Oracle. All rights reserved.

Individual Taxpayer Corporation

5-8 Copyright 2009, Oracle. All rights reserved.

5-9 Copyright 2009, Oracle. All rights reserved.

Maintenance Objects vs. Business Objects

Copyright 2009, Oracle. All rights reserved.

Sales & Use

5 - 11 Copyright 2009, Oracle. All rights reserved.

Person MO These have an owner

Base-package data Implementation data Individual

5 - 12 Copyright 2009, Oracle. All rights reserved.

Table MO Service XML Doc

Generic and hierarchical XML, by

An MO can have many child tables

The fields linked to the MOs Tables are

5 - 13 Copyright 2009, Oracle. All rights reserved.

5 - 14 Copyright 2009, Oracle. All rights reserved.

Mapping Elements To Physical Locations

Copyright 2009, Oracle. All rights reserved.

A business objects schema holds the BOs elements

Every BO has a schema that defines its

In the demo system, we use

5 - 16 Copyright 2009, Oracle. All rights reserved.

You declare where BO elements reside in the MOs tables by declaring

5 - 17 Copyright 2009, Oracle. All rights reserved.

Individual Taxpayer Schema Person Maintenance Object (MO)

5 - 18 Copyright 2009, Oracle. All rights reserved.

Every BO must have elements that map to the constituents of the

PER_ID is the prime key of the

Individual Taxpayer Schema Person Maintenance Object (MO)

Id Type Phone Type Char Type

5 - 19 Copyright 2009, Oracle. All rights reserved.

You've just learned the first schema mapping

5 - 20 Copyright 2009, Oracle. All rights reserved.

Copyright 2009, Oracle. All rights reserved.

The remaining elements in our example reside in child tables linked to

5 - 22 Copyright 2009, Oracle. All rights reserved.

Person Maintenance Object (MO)

5 - 23 Copyright 2009, Oracle. All rights reserved.

When More Than 1 Element

Copyright 2009, Oracle. All rights reserved.

IndividualTaxpayer Schema Person Maintenance Object (MO)

5 - 25 Copyright 2009, Oracle. All rights reserved.

Mapping Elements To Effective Dated Tables

Copyright 2009, Oracle. All rights reserved.

Some child tables have an effective date in their prime key

5 - 27 Copyright 2009, Oracle. All rights reserved.

If you do care (i.e., you want all changes to be recorded as separate

5 - 28 Copyright 2009, Oracle. All rights reserved.

Mapping Elements To Language Tables

Copyright 2009, Oracle. All rights reserved.

Phone Type Object (MO)