05 BO Business Rules

5
Business Object Business Rules
Copyright © 2009, Oracle. All rights reserved.

Check Point
• Up to now, you've learned to define a BO's data structure

(i.e., you learned how to define the elements in a BO
schema)
• In this section, you'll learn how to set up business rules
for your business objects
5-2 Copyright © 2009, Oracle. All rights reserved.

You Already Know How To Implement Simple Rules
• Recall the various validation-oriented attributes that can

be defined in a BO's schema:
<birthDate mdField="BIRTH_DT" …> validates the element is formatted as per the field's meta-
data
<propertyManager fkRef="SA" …> validates the element is a foreign key to the reference
table
<birthDate required="true" …> validates the element is specified
<customerType default="R" …> applies a default value if an element is left blank
<status dataType="lookup" lookup="STATUS_FLG" …>
Validates the element is formatted as per the

dataType (and, in this case, checks the element's
value is a valid value for the specific lookup)

5
More Sophisticated BO Business Rules

More Sophisticated Rules Require A More
Sophisticated Technique
• You create algorithms to perform business rules that can't be performed
using attributes in the BO's schema
• Think of an algorithm as a subroutine whose existence is declared in the meta-
data (hence the Algorithm entity in the following ERD)
• The framework invokes a BO's algorithms whenever a BO is added, changed
or deleted
• Note well, algorithms are "owned" (as are business objects)
• You can't touch base-package algorithms but you can use them to create your own
Business You define which algorithms should be

Object invoked when you set up the BO's meta-data
(and a BO can have many algorithms)
BO /
Algorithm
Algorithm

A Quick Refresher Before Diving Into More Details
• Remember - 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

Validation Rules
• You'd plug-in a validation algorithm on a BO if you need more sophisticated
validation than can be defined using the schema attributes
• Notice how your validation algorithms are executed after the MO processing
(e.g., core validation rules)
• Fun facts:
• Element-level validation (defined on the BO's schema) is executed before any MO
processing
• BO validation algorithms are only executed after "core validation" held in the MO is
passed and the MO is added / updated / deleted (but not committed)
• If your algorithms issue an error, MO changes are rolled back
BO k e
vo
In
Individual Taxpayer
Enter Exit
M oke
v
O
Person MO
In
3. Validation algorithms
2. MO Processing (Service)

No Updates During Validation
• Your validation algorithms are used to perform validation

• You cannot perform any updates during validation (the
framework will issue an error if you try)
BO k e
vo
You cannot add, change

In
Individual Taxpayer
or delete anything in a
Enter Exit validation algorithm
M oke
v
O
Person MO
In
3. Validation algorithms
2. MO Processing (Service)

5
Writing New Algorithms
Languages and Meta-data

3 Language Choices
• An algorithm can be written in one of the following

languages:
• Java. Typically used for "intense" logic.
• Cobol. Typically used for "intense" logic.
• Scripting. This is a high-level "4GL". Typically used for simpler
logic or logic that you know will be changed by an implementation
(and you want to make changing it easy).
• The external design will state the preferred language for a
new algorithm
5 - 10 Copyright © 2009, Oracle. All rights reserved.

To Create A New Algorithm, Follow These Steps
1. Write your logic (in Java, Cobol, or Scripting)
• The next section describes how to create a script; this course does not deal with Java or Cobol
2. Create an algorithm type that references your program or script
• The system uses this meta-data to know which program to invoke when a BO is added, changed
or deleted
3. Create an algorithm that references your algorithm type
• Later, you'll learn when you might have more than 1 algorithm for an algorithm type
4. Plug the algorithm in on the BO
• There's a wizard that sets up the above with 1 click (but it won't write your logic)
Program- 1
ming
Business
Language
Object
3 2
Algorithm
4 Algorithm
BO Type
Algorithm

5
Writing An Algorithm Using A Script
Fundamentals

What Is A Plug-in Script?
• We use the term plug-in script to describe an algorithm type whose

logic has been written using the scripting tool
• The scripting tool allows you to define logic in a high-level 4GL
• In general, we prefer straightforward logic to be created using scripting
(rather than Java or Cobol) as it's easier for mortals to maintain (and you
don't need a compiler as the steps are interpreted from the meta-data at
run time)
• Notice that the script's logic is held in the system's meta-data and not
in a directory
Plug-In
Script
The script's steps contain the
algorithm's logic; we'll discuss
steps in a few slides
Step

BO-Oriented Plug-in Scripts Must Reference Their BO
• When you create a plug-in script to validate a BO, you must reference the BO on
the script
• This is because when you write a plug-in script, you'll typically reference
elements in this BO and the script validation logic ensures that your references
are valid (if you didn't have this BO on the script, it couldn't validate references
to the elements)
Plug-In Business Maint.

Script Object Object
Foreshadowing – only BO oriented plug-ins

require a reference to a BO (and there are
Step many other types of plug-ins that are only
dealt with later in this course)

Algorithm Types and Plug-In Scripts
• If an algorithm type has been written using the scripting

tool, the algorithm type must reference the script (rather
than a Java or Cobol program name)
MO
Program- 1
ming Plug-In
Business
Language Script
Object
3 2
Algorithm
4 Algorithm
BO Type
Step
Algorithm

5
Declaring A Script's Data Area

A Script's Data Area Is An XML Document
• A plug-in script is similar to other programming languages in that it has a data area that holds the
data used in its logic
• This data area is actually an XML document
• This XML document is simply an aggregation of the various objects referenced in the script
• Let's assume you have a "validation" plug-in script that needs to retrieve information about the customer
and its account; this script's data area would be an XML document that contains the elements for the
customer and the account business objects
<customer>
<lastName mapField= ... />
<homePhone ... /> This XML document
<mobilePhone ... /> represent a script's
<driversLicense ... />
...
data area
</customer>
<account>
<creditLimit mapField= ... />
<preferredDueDay ... />
<customerClass ... />
...
</account>

The Script's Data Area Is Constructed From Meta-data
(what else)
• When you create a script, you declare its data areas in meta-data
• Each entry references an object that has a schema
• It's the superset of these schemas that forms the script's XML
document
Each entry references an
You know about BO's and
Plug-in object that has a schema BO their schemas
script
Stand- You learned how you can

Data Area define common data
alone structures in a stand-alone
data area
Service
Script You'd don't know about these
The story is almost complete… yet, but these are other types
of objects that your script
Business
can interact with
Service

A Plug-In Script's API Is Dynamically Inserted In Its
Schema
• You learned earlier that you must declare the BO on a validation plug-in script
• The framework inserts this BO's schema (and then some) into the script's
schema (into the parm\hard group node)
• You'll use these elements in virtually every validation plug-in script you develop
<parm>
<hard>
<customerId/>
<customerName/>
Business This is a simplification, you'll <homePhone/>
Object soon discover this is the
<workPhone/>
</hard>
entire BO's schema plus </parm>
several other useful bits of <customer>
information <lastName mapField= ... />
Plug-in <homePhone ... />
script <mobilePhone ... />
<driversLicense ... />
...
<account>
<creditLimit mapField= ... />
Data Area <preferredDueDay ... />
<customerClass ... />
...

5
Steps Contain The Logic

A Small, But Powerful List of Step Types
• As described earlier, a script's steps contain its logic

• Think of a step as a structured "line of code"
• Where the step's step type controls the type of logic
Plug-in
Jump to another step if a condition is true or false
Script
• Conditional branch Jump to another step
• Go to a step
Read, add, change, delete a business object
• Invoke business object
• Invoke business service Invoke a Java or Cobol program
Step • Invoke service script
• Label Invoke a subroutine written in the scripting language
• Move data Declare a "go to" location
• Terminate
• Edit data Move data in the script data area
Step Type Exit the script (with or without an error)
Everything else (this is the only one you need to know )

Edit Data versus Specific Function Step Types
• The edit data step type is a free format region where you
can specify multiple "lines of code"
• Some prefer to develop scripts using the specific step
types; others prefer to use edit data steps; while others
prefer a combination
10 steps or 1 “edit data” step; the choice is yours

Steps and The Script's Data Area
• You might find it useful to view a script as a program that is passed
an XML document (that contains its input and output parameters)
• The program can, in turn, retrieve other objects
• Whenever you retrieve an object, you're actually populating a portion of
the script's data area
• The script can also add, change or delete other objects. Each of
these functions causes an XML document to be sent to a service
Invokes a service that adds a new BO (called Person) passing the data in the XML
document in the node "parm/cust" (and this is a group node that contains many elements)
Copy an XML node to another node
Add another BO passing a different section

of the XML document (the "parm/spouse"
group node)
Add another BO passing a different section

of the XML document ("account")
And so on

Edit Data Bonus Features – Part 1
• If you use use the specific "invoke" step types (i.e., Invoke BO, Invoke
Service Script, Invoke Business Service), you'll see that the id of the
BO / SS / BS that you're invoking is explicitly defined on the step (as a
FK to the respective object)
• If instead, if you use Edit Data to invoke the BO / SS / BS, the name of
the object that your invoking can be referenced in an element name
rather than hard-coded
• You'll find that having your scripts be able to dynamically invoke an
object at run time (rather than hard coding the object) leads to a lot of
reusability
invokeBO "theNameOfTheBO" using "parm/hard/ newBusinessObject" for add;
Double quotes means that this is an Xpath reference to a variable

that contains the name of the BO being added; if this had been single
quotes, this is a literal with the hard-coded name of the BO to invoke

Edit Data Bonus Features – Part 2
• All logic supported by the other step types can be implemented in edit data
plus:
• You can use For and If statements
• You can cut and paste lines of code
• You have access to the XPath 2.0 language
– XPath 2.0 is an expression language that is used to manipulate an XML document
– Because XML documents hold the script's data, XPath provides a powerful
programming extension for scripts:
—
Arithmetic functions (date and numerical)
—
For, If, Every statements
—
Complex string manipulation
—
…
– To learn more about XPath, go to www.w3.org/TR/xpath20/
if ("xs:date(parm/hard/newBusinessObject/generalInfo/endDate) < xs:date(parm/hard/newBusinessObject/generalInfo/startDate)")

terminate with error (11108, 11507 element='endDate');
end-if;
A simple example of XPath 2 being used to do date arithmetic

(the upcoming slides will provide more examples…)

An XPath 2.0 Sample
• Here's a sample of a subset of an edit data step that
validates that a credit card number is valid
• everything in " " is XPath 2.0 and you couldn't do most of this
using XPath 1
Admittedly, this is tricky logic, but we wanted to
include it to show what you can do with a little
if("string-length($accountNumber) mod 2=0") Xpath 2 knowledge
move 'Y' to $wholeStringEven;
else
move 'N' to $wholeStringEven;
end-if;
move "sum(for $idx in 1 to string-length($accountNumber)
return (if(($wholeStringEven='Y' and ($idx mod 2!=0)) or ($wholeStringEven='N' and ($idx mod 2=0)))
then if(substring($accountNumber,$idx,1)>'4')
then 1+number(substring($accountNumber,$idx,1))*2
else number(substring($accountNumber,$idx,1))*2
else number(substring($accountNumber,$idx,1))))" to $checkSum;
From a knowledgeable website: "Once you've gone through

the trouble of learning XPath 2.0, you'll be pleased to discover
that you're almost done learning Xquery"

Use The "Tips"
• You've just been exposed to the Edit

Data step type and learned that it can
contain a combination of service calls
(to retrieve and update information) and
Xpath
• The combination is powerful and relatively
straightforward to learn (note: easy XPath is
easy, difficult XPath is difficult)
Click here to see the
• Tips are available on the script page documentation of the edit
just like they were on the business data syntax
object page
• These tips provide a list of all valid edit
data syntax along with many cut and
paste examples

Team Walk Through (30 minutes)
• Examine a validation plug-in

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

5
Plug-in and Service Scripts
Debugging

The Server Log
• A special mode can be turned on to facilitate script

debugging
• To enable this mode, enter ?debug=true at the end of the URL that
you use to access the system
• For example,
– if the standard URL was http://sf-pdnt-009:7031/cis.jsp,
– you'd enter http://sf-pdnt-009:7031/cis.jsp?debug=true to enable
configuration mode
This area appears when you enter the system in debug=true mode. You must
turn on the Global debug checkbox if you want to turn on server logging

The Server Log
• If you turn on the Global debug switch, log entries are created when
the script executes
• Every step will appear in the log
• And these log entries will contain the subset of the script's XML document
that is referenced in the respective step
• You can see the log entries by clicking the Show User Log button
• All log records for YOUR USER ID appear in a pop-up window
• This is why you should not use anyone's user ID but your own
• You can use these log entries to debug your scripts

Be Careful What You Ask For
When you click the Global debug

checkbox, the adjacent pop-up
appears. You must turn it on to tell
the system that you want to turn
on server logging.
This is the only option you need to select

to have the framework create the log. If
you ask for other things, be prepared for
what you might see in the log

Commenting Steps
• As stated on the previous slide, every step causes a log

entry to be created when you're in debug mode
• If the first two characters of a step's text contains '//', the
step will be skipped at execution time
• This might prove useful to keep debugging logic in your
scripts and leave them commented

• Examining the server log

• Break up into teams and follow the instructions in the workbook
• Warning – if you're typing, make sure your user id is not used by any other
student as your logs will collide

5
You Can Do More Than Just Validate

Different Types Of Algorithms
• Up to now, you've learned how you can develop validation

algorithms and plug them in on a BO to perform additional
validation
• You can develop other types of algorithms
There are several different types of
Business algorithms that can be set up (and you can
Algorithm have more than one of each type on a BO)
Object
Valid Values:
• Validation
BO / System • Pre-processing
Algorithm Event • Post-processing
• Audit
• Information
When you link an algorithm to a BO,
you must also declare the system event
(i.e., the type of algorithm)

Pre Processing Rules
• You'd create a pre-processing algorithm if you need to
“massage” the BO's elements prior to MO processing
• For example, if you need to apply more complex defaulting rules
than can be defined with a "default=" attribute (e.g., if date of birth
> 65 years old, set special discount to "true")
BO ke
vo
In
Individual Taxpayer
1. Pre-processing rules Enter Exit
M oke
v
O
Person MO
In
2. MO Processing (Service) 3. Validation rules

Post Processing Rules
• You'd create a post processing algorithm if you need to perform
additional steps as part of the BO's logical transaction
• For example, create a To Do, add a log entry, etc
• One can argue that post processing could just be your last
"validation" algorithm
• However, there are core processes (e.g., conversion, ConfigLab) that can
invoke objects in "validate only mode" and you'd really not want to have
post processing to be executed in these scenarios
BO k e
vo
In
Individual Taxpayer
M oke
4. Post-processing rules
v
O
Person MO
In

Audit Rules
• You'd create an audit algorithm if you want to store audit
trail (or other audit type objects) when a BO is added,
changed or deleted
• One can argue that audit algorithms could just be your
last "post processing" algorithm
• However, audit is special as the framework supplies it with the
before and after image of the BO as well a list of everything that
changed!
BO k e
vo
In
Individual Taxpayer
5. Audit processing
M oke
v
O
Person MO
In

When You Can Update
• As stated earlier, the framework will not allow you to
perform updates during a Validation plug-in
• You can do updates in Pre-processing, Post-processing
and Audit plug-ins BO k e
In
vo
Individual Taxpayer
5. Audit processing
1. Pre-processing rules Enter Exit (updates allowed)
(updates allowed)
M oke
(updates allowed)
v
O
Person MO
In

(no updates)

Info Routine
• The "info plug-in spot" is responsible for returning the

standard string of information that appears throughout the
system
• It's not a "business rule" as it's used purely for display purposes
• This plug-in spot allows you to have different information
displayed for different types of BO's
• For example, you might want a different info string for a cut field
activity as compared to a service investigation field activity
• If the BO's for a given MO all have the same "info string"
logic, you can rather use a plug-in spot on the MO (the BO
plug-in overrides the MO)

Algorithm Entity
• Every plug-in script references an algorithm entity

• The algorithm entity serves two important functions:
• It defines the script's API (i.e., its input and output)
• It prevents the script from being plugged in on the wrong object (e.g., you
can't plug a validation script into a pre-processing algorithm type)
• Technical note - whenever a new plug-in spot is created, a developer
defines the spot's API (in Java)
• In addition, the developer creates a corresponding algorithm entity AND
system event in the system's meta-data
The algorithm type's entity must be the
Valid Values: same as the scripts (this ensures that
• Validation Algorithm you don't plug-in a script written for one
• Pre-processing Entity purpose into the wrong spot)
• Post-processing
• Audit
• Information
Plug-In Algorithm
Script Type

The Script's Hard Parms Differ Depending On The
Algorithm Entity
• Each algorithm entity has a well-defined set of hard parms
Scripts created for the Business <parm>
Object – Validation algorithm entity <hard>
receive different elements in their <businessObject>
<id/>
hard parms as compared to a </businessObject>
different plug-in spot <newBusinessObject>
<lastName/>
<homePhone/>
...
</newBusinessObject>
<originalBusinessObject>
<lastName/>
<homePhone/>
...
</originalBusinessObject>
</hard>
</parm>
Note, this slide's hard parms aren't 100% accurate as this is

purely for example purposes (but notice how the validation plug-
in receives the before and after image of the BO)

For Example, The Info Plug-In Spot Has Different Hard
Parms
• Notice, how the hard parms are different for the
Information algorithm entity as compared to the Validation
algorithm entity
<parm>
<hard>
<businessObject>
<lastName/>
<homePhone/>
...
</businessObject
<info/>
</hard>
</parm>

System Event vs. Algorithm Entity
• Recall that you must define the algorithm's system event when you plug it in
on a BO so the framework knows what the algorithm is used for
• There are a limited number of system events (e.g., validation, audit, …)
• You also learned that when you create a plug-in script / algorithm type, you
must define their algorithm entity so the system can construct's the program's
API
• There are 100's of algorithm entities – you've only learned those that are used on
BO's (the others are used on other objects that you don't know about yet)
As you can probably guess, you can't

plug-in an algorithm into a BO unless
Algorithm its algorithm entity is in sync with the
respective system event BO
Entity
Plug-In Algorithm BO / System

Algorithm
Script Type Algorithm Event

Single versus Multi System Events
• Each BO system event is categorized as either

• Multi. Multiple algorithms can be executed
– For example, you might have multiple "validation" algorithms on a BO
• Single. Only one algorithm will be executed
• The single system events are:
• Info
• The multi system events are:
• Pre-processing
• Post-processing BO
• Validation
• Audit Valid Values:
• Validation
BO / System • Pre-processing
Algorithm Event • Post-processing
• Audit
• Information

5
Technical Note – How The System Determines
The BO

Service Calls To MO's Exist
• Many processes can invoke maintenance objects directly,

never going through the BO interaction
• For example,
• XAI can make service calls directly to MO's (but it's far better to
configure it to call BO's)
• Older objects have page maintenance transactions that allow users
to work on MO's directly (rather than having a pleasant BO-specific
user interface)
• In these situations, the initial service call is to the MO, not
the BO
• So how does the system figure out which BO, if any, is associated
with a given instance of a MO?

There's A Plug-In Spot, Of Course
• Up to now, you've just seen BO-oriented plug-in spots (e.g., validation, audit,
info, etc.)
• However, there are many other plug-in spots, one of which is on the MO
• When an MO is initially created, the base-package team plugs-in an
algorithm whose logic knows where to look for a given MO's BO
• The following are common algorithms:
• Look for a column directly on the MO's primary table
• Look for a column on a "type" table linked to the MO (this is for older objects)
• If you create a new MO and you don't plug-in this type of algorithm, the
system will NOT invoke any BO rules
Maint.
Algorithm
Object
Valid Values:
MO / System • Determine BO
Algorithm Event • Information
•…

BO Rules Invoked From The MO Layer
• Pre-processing rules are triggered from the BO layer only
• Other rules are triggered from the MO layer
• Whether called via a business object or directly
• Therefore, the MO needs to determine the processed
instance’s BO before executing its rules
We'd like to repeat – if the MO
BO ke
vo
associated with the BO does

In
Individual Taxpayer not have a Determine BO plug-

in, no BO-oriented plug-ins will
1. Pre-processing rules Enter Exit be executed (this is because
the MO invokes these plug-ins)
M oke
6. Audit rules
v
O
Person MO
In
(Service) 5. Post-processing rules
4. Validation rules
2. MO Processing
3. Determine BO

Determine BO For Non-Add Calls
• The previous slide illustrated the sequence of events when a BO is
invoked for adds
• The following shows what happens when a BO is invoked for non-
add calls (e.g., updates, deletes)
BO k e
vo
In
For non-add calls, after the pre-processing
rules have been executed for the invoked Individual Taxpayer
BO, the FW determines the BO prior to 1. Pre-processing rules
invoking the MO. It does this for two
reasons: 2. Determine BO
1) to take a snapshot of the BO prior to it
being changed (for audit purposes), M oke
2) to check if the user has security access to
v
O
Person MO
In
the BO (more about this in a future chapter).

6. Audit rules
(Service)
3. MO Processing
4. Validation rules

• Please split up into teams
• Assume every instance of the person MO has a column called "person flag" and it
can contain only two values: Human or Business
• Describe if / when the validation plug-in on the GenericCustomer BO will execute?
MO: Person
Logic:
System Event: Determine BO - Return the value of the "person
Algorithm: Use Person Flag flag" (e.g., Human or Business)
BO: Human BO: Business BO: GenericCustomer

System Event: Validate System Event: Validate System Event: Validate
Algorithm: Require 2 forms Algorithm: Require Algorithm: Require Primary
of ID marketing contact Phone
System Event: Preprocess System Event: Preprocess System Event: Preprocess

Algorithm: Default person Algorithm: Default person Algorithm: Default person
flag to Human flag to Business flag to Business

5
Beware Of Entity Updates

Entity Updates Don't Trigger BO Rules
• All page maintenance and XAI services
perform their updates via the MO service
layer
• This means that if a user updates a person's
phone numbers on the person page, and
there's a determine BO plug-in on the
Account
person MO, any rules that you've plugged in
on the BO will execute Account
• However, older MO's may have background CI_ACCT
processes and common routines that do

not go through their service layer
• Rather, they update the entities without Bill
telling the MO about it Message …
• And, because it's the MO service layer that CI_ACCT_MSG
invokes the BO plug-ins, this type of

updating will never execute your BO rules
• We don't like this, but it's true For example, the bill completion
• This type of updating is not terribly routine can delete "one-time"
common, but you need to think about it bill messages when it
when you design completes a bill and it does not
go through the service layer

5
Performance Concerns

Performance Differences Between Plug-In Scripts
versus Java Plug-Ins
• Whether you use Java or scripting for your plug-in logic
will typically be defined in the internal design
• The designer takes a variety of factors into consideration
when making this call
• The biggest factors are:
• Ease of change by an implementation (this is subjective)
• Performance (this is not subjective)
• We know that for some update-intensive processing,
there’s a performance price to pay if you use scripting
• The exact cost is hard to quantify
• We've performed numerous tests where we've written the
same logic in both languages and found the following to
be true...

Here's What We Know About Performance Differences
• There appears to be little difference for If’s, For’s, Move’s
• There is a slight overhead for Invoke business service
• There is a slight overhead for Invoke BO – read
• There is a slight overhead for Invoke BO – delete
• There is a slight overhead for Invoke BO – fast add
• If there are many tables involved in the underlying MO, there is a
moderate overhead for Invoke BO – fast update
• Before we update, we read (in Java, this is not the case)
• Invoke BO – add and Invoke BO – update are slower than their "fast"
counterparts as we read the entire BO after the update (so don't use
these actions if your script doesn't need a refreshed object)
• Note well, the system will return the PK of a new BO after a fast add so you
don't need to use the slow version if your subsequent logic just need the
newly added PK
• The overhead may not be relevant if the plug-in scripts aren’t called
during major batch processing

Other Things To Be Aware Of
• The framework "compiles" a script's steps the first time

it's invoked and saves the resultant "executable"
• If you're doing performance tests, make sure you don't time the
first execution
• The framework automatically removes the "executable" if you make
changes to the script (and it then "recompiles" when it's next used)
• Revision control facilities exist and will be described in a
later chapter. For now, understand that:
• A developer can check out a script before making changes
• Inadvertent changes can be discarded
• Historical versions can be viewed and reinstated
• Queries through the revision history can be used to find what a
developer did or when a script was last updated or …

Team Walk Through (30 Minutes)
• Examine the parameters of plug-ins

• Watch your instructor examine the input and output elements for a
Business Object – Information script
– Notice what is marked as input and what is marked as output (see the
usage= attribute on each element)
• Break up into teams and follow the instructions in the workbook

Review Questions


05 BO Business Rules

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

05 BO Business Rules

Încărcat de

Drepturi de autor:

Formate disponibile

5

Business Object Business Rules

Copyright © 2009, Oracle. All rights reserved.

• Up to now, you've learned to define a BO's data structure

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

• Recall the various validation-oriented attributes that can

<customerType default="R" …> applies a default value if an element is left blank

<status dataType="lookup" lookup="STATUS_FLG" …>

Validates the element is formatted as per the

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

Copyright © 2009, Oracle. All rights reserved.

Business You define which algorithms should be

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

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

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

• Your validation algorithms are used to perform validation

You cannot add, change

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

Languages and Meta-data

Copyright © 2009, Oracle. All rights reserved.

• An algorithm can be written in one of the following

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

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

Copyright © 2009, Oracle. All rights reserved.

• We use the term plug-in script to describe an algorithm type whose

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

Plug-In Business Maint.

Foreshadowing – only BO oriented plug-ins

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

• If an algorithm type has been written using the scripting

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

Declaring A Script's Data Area

Copyright © 2009, Oracle. All rights reserved.

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

Stand- You learned how you can

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

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

Steps Contain The Logic

Copyright © 2009, Oracle. All rights reserved.

• As described earlier, a script's steps contain its logic

Everything else (this is the only one you need to know )

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

10 steps or 1 “edit data” step; the choice is yours

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

Copy an XML node to another node

Add another BO passing a different section

Add another BO passing a different section

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

invokeBO "theNameOfTheBO" using "parm/hard/ newBusinessObject" for add;

Double quotes means that this is an Xpath reference to a variable

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

if ("xs:date(parm/hard/newBusinessObject/generalInfo/endDate) < xs:date(parm/hard/newBusinessObject/generalInfo/startDate)")

A simple example of XPath 2 being used to do date arithmetic

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

From a knowledgeable website: "Once you've gone through

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

• You've just been exposed to the Edit

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

• Examine a validation plug-in

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

Copyright © 2009, Oracle. All rights reserved.

• A special mode can be turned on to facilitate script

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