Vous êtes sur la page 1sur 77

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)
5-3 Copyright 2009, Oracle. All rights reserved.
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

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


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"

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


Business Objects

Maintenance Objects vs. Business Objects

Copyright 2009, Oracle. All rights reserved.


Maintenance Objects vs. Business Objects
MO's are designed to be
Person Maintenance Object (MO)
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

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


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

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


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

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


Business Objects

Maintenance Objects vs. Business Objects


A More Technical View

Copyright 2009, Oracle. All rights reserved.


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

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


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

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


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

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


Business Objects

Mapping Elements To Physical Locations

Copyright 2009, Oracle. All rights reserved.


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)

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


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

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


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)

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


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

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


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

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


Business Objects

Flattening Elements

Copyright 2009, Oracle. All rights reserved.


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

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


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

Person Maintenance Object (MO)


IndividualTaxpayer Schema

...
<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>
...
Id Type Phone Type Char Type
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)

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


Business Objects

When More Than 1 Element


Resides On The Same Row

Copyright 2009, Oracle. All rights reserved.


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" />
...
Id Type Phone Type Char 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)

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


Business Objects

Mapping Elements To Effective Dated Tables

Copyright 2009, Oracle. All rights reserved.


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)

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


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)
Person Maintenance Object (MO)
IndividualTaxpayer Schema
...
<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"/>
...
Id Type Phone Type Char Type

Notice that mapField= references the column that holds the effective
date; also notice the rowRef= references the effective-dated element

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


Business Objects

Mapping Elements To Language Tables

Copyright 2009, Oracle. All rights reserved.


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)


IndividualTaxpayer Schema
...
<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

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


Business Objects

Validation and Defaulting

Copyright 2009, Oracle. All rights reserved.


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)
<row mapChild="CI_PER_CHAR">
<CHAR_TYPE_CD is="BIRTHDT" />
<EFFDT default="%CurrentDate" />
</row> Person
Person
</birthDate> Char
...
Person
Name Person
Person Id
Phone

Id Type Phone Type Char Type

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


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

IndividualTaxpayer Schema
...
<birthDate mapField="ADHOC_CHAR_VAL"
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" />
<EFFDT default="%CurrentDate" />
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
...
<birthDate mapField="ADHOC_CHAR_VAL"
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)

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


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)

IndividualTaxpayer Schema
...
<primaryContract mapField="CHAR_VAL_FK1" fkRef="SA" >
<row mapChild="CI_PER_CHAR">
<CHAR_TYPE_CD is="PRIMCON" /> Person MO
<EFFDT default="%CurrentDate" />
</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
Id Type Phone Type Char Type
technique means you'll get a good message

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


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=

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


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


IndividualTaxpayer Schema
...
birthDate is supplied (and a valid date)
<birthDate mapField="ADHOC_CHAR_VAL"
dataType="date" required="true" >
<row mapChild="CI_PER_CHAR"> Person Maintenance Object (MO)
<CHAR_TYPE_CD is="BIRTHDT" />
<EFFDT default="%CurrentDate" />
</row>
</birthDate> Person
Person
... Char

Person
Name Person
Person Id
Phone

Id Type Phone Type Char Type

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


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)

IndividualTaxpayer Schema
...
ResidentialAccount Schema
<birthDate mapField="ADHOC_CHAR_VAL"
...
dataType="date" >
<customerType mapField="CUST_CLASS_CD"
<row mapChild="CI_PER_CHAR">
required="true" default="R" />
<CHAR_TYPE_CD is="BIRTHDT" />
<mngGroup mapField="ACCT_MGMT_GRP_CD"
<EFFDT default="%CurrentDate" />
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)

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


Defaulting System Variables

You've seen one system variable being defaulted so far


(%CurrentDate)
There are other variables (check them out in the tips)

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


Business Objects

Other Types of Elements

Copyright 2009, Oracle. All rights reserved.


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)

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


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)
IndividualTaxpayer Schema
...
<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 />
...

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


Business Objects

Naming Conventions

Copyright 2009, Oracle. All rights reserved.


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

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


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

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


Business Objects

Concurrency Checks When BOs Are Updated

Copyright 2009, Oracle. All rights reserved.


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

<taxpayerId mapField="PER_ID"/>
<name mapField="ENTITY_NAME"> Person Maintenance Object (MO)
<row mapChild="CI_PER_NAME">
<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

Id Type Phone Type Char Type


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

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


Business Objects

Populating Base Package Fields That You Dont


Want Anyone To Know About

Copyright 2009, Oracle. All rights reserved.


Populating and Hiding MO Fields

Mark an element as private="true" if you dont want the element


exposed to invokers of the BO

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

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


Business Objects

Mapping Elements To
Character Large Object (CLOB) Columns

Copyright 2009, Oracle. All rights reserved.


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

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


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

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


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

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


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" />
<senderID 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)

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


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
A Snippet Of A Market Message Schema

...
<messageType mapXML="BO_DEFN_AREA" mdField="MSG_TYPE_CD" required="true" />
<versionNumber mapXML="BO_DEFN_AREA" />
<marketTimeStamp mapXML="BO_DEFN_AREA" />
<senderID 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" />
...

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


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

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


Business Objects

Other Element Types Can Be Held In A CLOB

Copyright 2009, Oracle. All rights reserved.


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


A Snippet Of A Market Message Schema
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

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


If You Were To Look At The Contents Of The CLOB

Youd see XML

A Snippet Of A Market Message Schema


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>

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


Multiple Groups In The Same CLOB
You can keep an unlimited number of groups in the CLOB
A Snippet Of A Market Message Schema

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

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


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.

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


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

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


Business Objects

Raw Data Types

Copyright 2009, Oracle. All rights reserved.


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

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


Business Objects

Standalone Data Areas Allow Reuse

Copyright 2009, Oracle. All rights reserved.


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>
<formType mapField="CASE_TYPE_CD"
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/>

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


Schema Business Rules
Recall that simple business rules can be defined in a schema

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 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>
<formType mapField="CASE_TYPE_CD"
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/>

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


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

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


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)

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


Business Objects

Performance

Copyright 2009, Oracle. All rights reserved.


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)

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


Business Objects

XAI

Copyright 2009, Oracle. All rights reserved.


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

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


Business Objects

Summary

Copyright 2009, Oracle. All rights reserved.


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

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


Self Service Case Study

Copyright 2009, Oracle. All rights reserved.


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.

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


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