04 BO Elements PDF

4
Business Objects
Copyright © 2009, Oracle. All rights reserved.

Business Objects Are Logical Views of Maintenance Objects
MO’s are abstract to handle disparate
requirements (for example, the Person object Business object’s are not abstract, notice
doesn’t have a column called "daytime phone") how each has specific fields
Person Maintenance Object (MO)

Individual Taxpayer
• Legal name
Person
• ID (e.g. driver’s license)
Person Busines • Birth date Commercial Customer
Char
s • Spouse • Name
Person Objects • Tax ID
Name Person Id
Person • 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 BO’s)
They are true subclasses of the MO and therefore take advantage of the
rich, safe, and sophisticated business rules embodied in the base-package
MO’s
4-2 Copyright © 2009, Oracle. All rights reserved.

Foreshadowing – One Reason To Create A BO Is To
Simplify The User’s 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-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…

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
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
vertical markets
Person Person Business objects are designed
Name Char
to match the business. For
Person
example, a tax management
Person Id
Phone implementation could set up
BO’s 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 BO’s 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 BO’s Elements Must Physically Reside
Somewhere In Its MO’s 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)
Name
E-mail Type ID Number
SSN (ID) SSN 777
Home Phone (Phone)
Work Phone (Phone) Phones (CI_PER_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

4
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 Partnership
persons
Sole Proprietorship
Business
Object Corporation
Premise MO
MO
Single family
Apartment
A utility package may use BO's
to define different types of Multi-unit home – single meter
premises Business
Object Multi-apartment building
4 - 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

MO owner 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 MO’s tables)
Generic and hierarchical XML, by

Table / Field Primary Child definition, does not look like how users
use it (e.g., you won’t 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 MO’s Tables

are the physical fields on the
database

Technical Execution
• At a high-level, here’s 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 to
• homePhone = 973-451-7777
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

4
Business Objects
Mapping Elements To Physical Locations

A Business Object’s Schema
• A business object’s schema holds the BO’s elements
Every BO has a schema that defines its

IndividualTaxpayer BO elements (you can think of a schema as
Business the BO’s "data definition area")
Object
IndividualTaxpayer Schema
<taxpayerId />
<name />
<email />
<socialSecurityNumber />
Notice how each element is <homePhone />
surrounded with < … />; this is <birthDate />
because we’ve 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 It’s Physically Stored
• You declare where BO elements reside in the MO’s tables

by declaring mapping rules
MO Table Field
MO / Table Table / Field
Business
Object IndividualTaxpayer Schema
<taxpayerId />
<name />
<email />
<homePhone /> This schema is invalid as
<birthDate />
its elements don’t 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 MO’s 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
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
MO’s 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
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 Click here to see the
documentation of the schema
• You can find a list of all schema mapping attributes
mapping attributes in the tips
• These tips provide a list of all valid
schema attributes along with many cut
and paste examples

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 Click to overwrite the BO's
schemas with elements that
/ remove / update the schema as match the MO's data structure
desired
• This can save a great deal of time if
the BO's schema is similar to 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
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
<PRIM_NAME_SW is="true"/> Person
<NAME_TYPE_FLG default="PRIM"/> Char
</row> Person
</name> Name Person Id
Person
<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/> mapField= identifies the column
<homePhone mapField="PHONE" >
<row mapChild="CI_PER_PHONE"> where the element’s value resides
<PHONE_TYPE_CD is="HOME" />
</row> The row node defines the child table’s 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 element’s value
• default= defines the default values of other columns on the row
is= also defines the default is= means that the element mapped to the row on the
values 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)

4
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
Person
</row>
Char
</workPhone>
Person
Name Person
<workExtension mapField="EXTENSION" 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)

4
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 don’t care (i.e., you don’t want different rows created when the element’s 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
Person Id
Phone
This means the riskCategory element will have its

effective date defaulted to the date when it’s first created Id Type Phone Type Char Type
(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 date is
Notice that default= is not used, rather retrieved (otherwise, the value effective on
is= is used (with a reference to the the current date is retrieved)
element that holds the effective date)
...
<riskCategory mapField="ADHOC_CHAR_VAL" > Person
<row mapChild="CI_PER_CHAR"> Person
Char
<CHAR_TYPE_CD is="RISKCAT" />
<EFFDT is="%effectiveDate(riskEdate)" /> Person
</row> Name Person
Person Id
Phone
</riskCategory>
<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

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

...
Phone
<phoneType mapField="PHONE_TYPE_CD"/>
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

doesn't require a flattening syntax as the framework knows Language
to look on the primary table's language table if it can't find
the field on the MO's primary table

4
Business Objects
Validation and Defaulting

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

fkRef=
• If you want the system to validate that an element’s 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>
</propertyManager>
... Person
Person Person
Name Char
Person
While the MO logic will validate this char value is a Person Id
Phone
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 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=

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

4
Business Objects
Other Types of Elements

Groups of Elements
• The elements encountered up to now are classic "fields" and don’t

require you to declare their type (type=field is the default)
• You can declare other types of elements, we’ll first describe
type=group
Groups allow you to document
groups of other elements
IndividualTaxpayer Schema Notice the type= attribute, also notice

... how this element is not mapped
<homeAddress type="group">
<country mapField="COUNTRY" default="USA"/>
<address1 mapField="ADDRESS1"/>
<address2 mapField="ADDRESS2"/> Besides elegance, the other reason (that
<city mapField="CITY"/> you’ll discover later) is that you can move
<postal mapField="POSTAL"/> a group to a similar group in a single
<state mapField="STATE"/> statement (i.e., you can do a "move by
<homeAddress /> 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"> defines the table that the array lives
<country mapField="COUNTRY" default="USA"/> 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 />
...

4
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

• Break up into F1-emailMsg Schema

...
teams and <OutboundMsgStatFlg mapField="OUTMSG_STATUS_FLG"/>
<CreationDttm dataType="dateTime" mapField="CRE_DTTM"/>
prepare a list of <EmailDocument type="group" mapXML="XML_SOURCE">
<From type="group">
what's wrong <InternetAddress type="group">
<address mdField="EMAILID"/>
and what's <personal dataType="string"/>
<charset dataType="string"/>
right about this </InternetAddress>
</From>
schema? <To type="list">
<InternetAddress type="group">
<address mdField="EMAILID" isPrimeKey="true"/>
<personal dataType="string"/>
</InternetAddress>
</To>
<Subject type="group">
<text dataType="string"/>
</Subject>
...

4
Business Objects
Concurrency Checks When BO’s 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 MO’s VERSION is not identical
to the BO’s version (the MO’s version is changed when it’s updated)
<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 don’t include this, no concurrency
validation will take place when the BO is
updated (and you might want this)

4
Business Objects
Populating Base Package Fields That You Don’t Want

Anyone To Know About

Populating and Hiding MO Fields
• Mark an element as private="true" if you don’t want the

element exposed to invokers of the BO
<PRIM_NAME_SW is="true"/> Person
Person
<NAME_TYPE_FLG default="PRIM"/> Char
</row>
Person
</name> Name Person
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

4
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
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 on their primary table
• This CLOB contains an XML document which, in turn, contains the
message / form’s 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

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 inbound message table

If You Were To Look At The Contents Of The CLOB
• You’d see XML
A Snippet Of A Market Message Schema The BO’s 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 message’s 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 Market 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.
<serviceAgreementId mapField="FK_CHAR_VAL" >
<row mapChild="CI_CASE_CHAR">
<CHAR_TYPE_CD is="SA ID" />
</row>
Because we will likely have an SQL join </serviceAgreementId>
to a case’s 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
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

A Snippet Of A Market Message Schema groups of other elements
...
<messageHeader type="group" mapXML="BO_DEFN_AREA" > Notice that you only have to define the
<messageTypeCode required="true" /> mapXML= once for the group (if you
<versionNumber required="true" /> recall the earlier discussion of groups,
<marketTimeStamp required="true" />
you had to declare a mapField on each
<senderID required="true" />
<recipientID required="true" /> member of the group)
<txRefNbr required="true" />
</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
• You’d see XML

The BO’s 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" />
<shipperId required="true" /> Notice how both groups of elements
<supplierId required="true" /> are mapped to the same CLOB
</BGTReference>
...

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" mapXML="BO_DEFN_AREA">
<country default="USA"/>
<address1 />
<address2 />
<city />
<postal />
Notice the mapXML= attribute (it is
<state /> only declared on the list)
<seasonStart /> Why is this example bad? Because
<seasonEnd />
the likelihood that these fields will
<sequence />
<seasonalAddress /> 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

• Examine a BO that uses a CLOB

• Break up into teams
• Your workbooks provide detailed instructions on how to work
through this exercise

4
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
Business Objects
Standalone Data Areas Allow Reuse

Data Area Schema
• If you have multiple BO’s 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 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

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

• Compare a BO with the blueprint design

• Break up into teams and follow the instructions in the workbook

Review Questions


04 BO Elements PDF

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

04 BO Elements PDF

Diunggah oleh

Hak Cipta:

Format Tersedia

4

Copyright © 2009, Oracle. All rights reserved.

Person Maintenance Object (MO)

4-2 Copyright © 2009, Oracle. All rights reserved.

This zone shows a customer BUSINESS

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

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

• We've just described some of the many benefits of

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

Maintenance Objects vs. Business Objects

Copyright © 2009, Oracle. All rights reserved.

Individual Taxpayer BO Corporation BO

4-7 Copyright © 2009, Oracle. All rights reserved.

Individual Taxpayer Corporation

4-8 Copyright © 2009, Oracle. All rights reserved.

4-9 Copyright © 2009, Oracle. All rights reserved.

Maintenance Objects vs. Business Objects

Copyright © 2009, Oracle. All rights reserved.

4 - 11 Copyright © 2009, Oracle. All rights reserved.

Person MO These have an

Base-package data Implementation data Individual

4 - 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 MO’s Tables

4 - 13 Copyright © 2009, Oracle. All rights reserved.

4 - 14 Copyright © 2009, Oracle. All rights reserved.

Mapping Elements To Physical Locations

Copyright © 2009, Oracle. All rights reserved.

• A business object’s schema holds the BO’s elements

Every BO has a schema that defines its

In the demo system, we use

4 - 16 Copyright © 2009, Oracle. All rights reserved.

• You declare where BO elements reside in the MO’s tables

4 - 17 Copyright © 2009, Oracle. All rights reserved.

Individual Taxpayer Schema Person Maintenance Object (MO)

4 - 18 Copyright © 2009, Oracle. All rights reserved.

• Every BO must have elements that map to the

Individual Taxpayer Schema Person Maintenance Object (MO)

Id Type Phone Type Char Type

4 - 19 Copyright © 2009, Oracle. All rights reserved.

• You've just learned the first schema

4 - 20 Copyright © 2009, Oracle. All rights reserved.

• The BO Schema zone is used to

4 - 21 Copyright © 2009, Oracle. All rights reserved.

• Compare a business object to its maintenance object

4 - 22 Copyright © 2009, Oracle. All rights reserved.

Copyright © 2009, Oracle. All rights reserved.

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

4 - 24 Copyright © 2009, Oracle. All rights reserved.

Person Maintenance Object (MO)

4 - 25 Copyright © 2009, Oracle. All rights reserved.

When More Than 1 Element

Copyright © 2009, Oracle. All rights reserved.

• Our example has two elements that reside on the same

4 - 27 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

IndividualTaxpayer Schema Person Maintenance Object (MO)

This means the riskCategory element will have its

4 - 29 Copyright © 2009, Oracle. All rights reserved.