You are on page 1of 61

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 metadata

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

Copyright 2009, Oracle. All rights reserved.

More Sophisticated BO Business Rules

Copyright 2009, Oracle. All rights reserved.

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 metadata (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
Object

BO /
Algorithm

5-5

You define which algorithms should be


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

Algorithm

Copyright 2009, Oracle. All rights reserved.

A Quick Refresher Before Diving Into More Details


Remember - heres how a call to add a BO is implemented
on the server
1
Add new individual taxpayer BO
taxpayerId = null
name = Mark, Brazil
email = abc@yahoo.con
ssn = 1234567
homePhone = 973-451-7777
birthDate = 1970-01-01

Individual
Taxpayer BO

Map Individual
Taxpayer BO XML to
Person MO XML

Person MO
Map Person XML back to
Individual Taxpayer XML

4
Add

6
Individual taxpayer added
taxpayerId = 9999129912
name = Mark, Brazil
email = abc@yahoo.con
ssn = 1234567
homePhone = 973-451-7777
birthDate = 1970-01-01

5-6

3
Validate
All business rules applied

Copyright 2009, Oracle. All rights reserved.

Database

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:

In
vo
BO k e

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

Individual Taxpayer

In
v
M oke
O

Enter

2. MO Processing

5-7

Exit

Person MO
(Service)
Copyright 2009, Oracle. All rights reserved.

3. Validation algorithms

No Updates During Validation

In
vo
BO k e

Your validation algorithms are used to perform validation


You cannot perform any updates during validation (the
framework will issue an error if you try)

Individual Taxpayer

In
v
M oke
O

Enter

2. MO Processing

5-8

Exit

Person MO
(Service)

Copyright 2009, Oracle. All rights reserved.

You cannot add, change


or delete anything in a
validation algorithm

3. Validation algorithms

Writing New Algorithms

Languages and Meta-data

Copyright 2009, Oracle. All rights reserved.

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)

Programming
Language

Business
Object
BO
Algorithm
5 - 11

3
4

Algorithm

1
2

Algorithm
Type

Copyright 2009, Oracle. All rights reserved.

Writing An Algorithm Using A Script

Fundamentals

Copyright 2009, Oracle. All rights reserved.

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

5 - 13

Copyright 2009, Oracle. All rights reserved.

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
Script

Step

5 - 14

Business
Object

Maint.
Object

Foreshadowing only BO oriented plug-ins


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

Copyright 2009, Oracle. All rights reserved.

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

Business
Object
BO
Algorithm

5 - 15

3
4

Algorithm

1
Plug-In
Script
2

Algorithm
Type

Copyright 2009, Oracle. All rights reserved.

Step

Writing An Algorithm Using A Script

Declaring A Script's Data Area

Copyright 2009, Oracle. All rights reserved.

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 ... />
<mobilePhone ... />
<driversLicense ... />
...
</customer>
<account>
<creditLimit mapField= ... />
<preferredDueDay ... />
<customerClass ... />
...
</account>

5 - 17

Copyright 2009, Oracle. All rights reserved.

This XML document


represent a script's
data area

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
Plug-in
script

Each entry references an


object that has a schema

Data Area

BO
Standalone
Service
Script

The story is almost complete

Business
Service

5 - 18

Copyright 2009, Oracle. All rights reserved.

You know about BO's and


their schemas
You learned how you can
define common data
structures in a stand-alone
data area

You'd don't know about these


yet, but these are other types
of objects that your script
can interact with

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>

Business
Object

Plug-in
script

This is a simplification, you'll


soon discover this is the
entire BO's schema plus
several other useful bits of
information

Data Area

5 - 19

<customerId/>
<customerName/>
<homePhone/>
<workPhone/>
</hard>
</parm>
<customer>
<lastName mapField= ... />
<homePhone ... />
<mobilePhone ... />
<driversLicense ... />
...
<account>
<creditLimit mapField= ... />
<preferredDueDay ... />
<customerClass ... />
...

Copyright 2009, Oracle. All rights reserved.

Writing An Algorithm Using A Script

Steps Contain The Logic

Copyright 2009, Oracle. All rights reserved.

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
Script

Step

Step Type

Jump to another step if a condition is true or false


Conditional branch
Go to a step
Invoke business object
Invoke business service
Invoke service script
Label
Move data
Terminate
Edit data

Jump to another step


Read, add, change, delete a business object
Invoke a Java or Cobol program
Invoke a subroutine written in the scripting language
Declare a "go to" location
Move data in the script data area
Exit the script (with or without an error)

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

5 - 21

Copyright 2009, Oracle. All rights reserved.

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

5 - 22

Copyright 2009, Oracle. All rights reserved.

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

5 - 23

Copyright 2009, Oracle. All rights reserved.

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

5 - 24

Copyright 2009, Oracle. All rights reserved.

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)

5 - 25

Copyright 2009, Oracle. All rights reserved.

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
Xpath 2 knowledge

if("string-length($accountNumber) mod 2=0")


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"

5 - 26

Copyright 2009, Oracle. All rights reserved.

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)

Tips are available on the script page


just like they were on the business
object page
These tips provide a list of all valid edit
data syntax along with many cut and
paste examples
5 - 27

Copyright 2009, Oracle. All rights reserved.

Click here to see the


documentation of the edit
data syntax

Team Walk Through (30 minutes)


Examine a validation plug-in
Break up into teams and follow the instructions in your workbook

5 - 28

Copyright 2009, Oracle. All rights reserved.

Plug-in and Service Scripts

Debugging

Copyright 2009, Oracle. All rights reserved.

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

5 - 30

Copyright 2009, Oracle. All rights reserved.

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

5 - 31

Copyright 2009, Oracle. All rights reserved.

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

5 - 32

Copyright 2009, Oracle. All rights reserved.

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

5 - 33

Copyright 2009, Oracle. All rights reserved.

Team Walk Through (20 minutes)


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

Copyright 2009, Oracle. All rights reserved.

You Can Do More Than Just Validate

Copyright 2009, Oracle. All rights reserved.

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

Algorithm

BO /
Algorithm

System
Event

When you link an algorithm to a BO,


you must also declare the system event
(i.e., the type of algorithm)

5 - 36

There are several different types of


algorithms that can be set up (and you can
have more than one of each type on a BO)
Valid Values:
Validation
Pre-processing
Post-processing
Audit
Information

Copyright 2009, Oracle. All rights reserved.

Pre Processing Rules


You'd create a pre-processing algorithm if you need to
massage the BO's elements prior to MO processing

In
vo
BO ke

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

Enter

In
v
M oke
O

1. Pre-processing rules

2. MO Processing

5 - 37

Individual Taxpayer
Exit

Person MO
(Service)

Copyright 2009, Oracle. All rights reserved.

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

In
vo
BO k e

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

In
v
M oke
O

1. Pre-processing rules

2. MO Processing

5 - 38

Individual Taxpayer
Enter

Exit

Person MO
(Service)

Copyright 2009, Oracle. All rights reserved.

4. Post-processing rules
3. Validation rules

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
In
vo
BO k e

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!
1. Pre-processing rules

Individual Taxpayer
Enter

Exit

In
v
M oke
O

5. Audit processing

2. MO Processing

5 - 39

Person MO
(Service)

Copyright 2009, Oracle. All rights reserved.

4. Post-processing rules
3. Validation rules

When You Can Update

In
vo
BO k e

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

In
v
M oke
O

1. Pre-processing rules
(updates allowed)

2. MO Processing

5 - 40

Individual Taxpayer
Enter

Exit

Person MO
(Service)

Copyright 2009, Oracle. All rights reserved.

5. Audit processing
(updates allowed)
4. Post-processing rules
(updates allowed)
3. Validation rules
(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)

5 - 41

Copyright 2009, Oracle. All rights reserved.

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
Valid Values:
Validation
Pre-processing
Post-processing
Audit
Information

5 - 42

Algorithm
Entity
Plug-In
Script

The algorithm type's entity must be the


same as the scripts (this ensures that
you don't plug-in a script written for one
purpose into the wrong spot)

Algorithm
Type

Copyright 2009, Oracle. All rights reserved.

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
Object Validation algorithm entity
receive different elements in their
hard parms as compared to a
different plug-in spot

<parm>
<hard>
<businessObject>
<id/>
</businessObject>
<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 plugin receives the before and after image of the BO)
5 - 43

Copyright 2009, Oracle. All rights reserved.

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>

5 - 44

Copyright 2009, Oracle. All rights reserved.

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)

Algorithm
Entity
Plug-In
Script

5 - 45

As you can probably guess, you can't


plug-in an algorithm into a BO unless
its algorithm entity is in sync with the
respective system event

Algorithm
Type

Algorithm

Copyright 2009, Oracle. All rights reserved.

BO

BO /
Algorithm

System
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
Validation
Audit

BO

BO /
Algorithm

5 - 46

Copyright 2009, Oracle. All rights reserved.

System
Event

Valid Values:
Validation
Pre-processing
Post-processing
Audit
Information

Technical Note How The System Determines


The BO

Copyright 2009, Oracle. All rights reserved.

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?

5 - 48

Copyright 2009, Oracle. All rights reserved.

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

MO /
Algorithm
5 - 49

Algorithm

System
Event

Valid Values:
Determine BO
Information

Copyright 2009, Oracle. All rights reserved.

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

In
vo
BO ke

Therefore, the MO needs to determine the processed


instances BO before executing its rules

In
v
M oke
O

1. Pre-processing rules

Individual Taxpayer
Enter

Exit

Person MO
(Service)

We'd like to repeat if the MO


associated with the BO does
not have a Determine BO plugin, no BO-oriented plug-ins will
be executed (this is because
the MO invokes these plug-ins)
6. Audit rules
5. Post-processing rules
4. Validation rules

2. MO Processing

3. Determine BO
5 - 50

Copyright 2009, Oracle. All rights reserved.

Determine BO For Non-Add Calls

Individual Taxpayer
1. Pre-processing rules
2. Determine BO

In
v
M oke
O

For non-add calls, after the pre-processing


rules have been executed for the invoked
BO, the FW determines the BO prior to
invoking the MO. It does this for two
reasons:
1) to take a snapshot of the BO prior to it
being changed (for audit purposes),
2) to check if the user has security access to
the BO (more about this in a future chapter).

In
vo
BO k e

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 nonadd calls (e.g., updates, deletes)

Person MO
(Service)

3. MO Processing

6. Audit rules
5. Post-processing rules
4. Validation rules

5 - 51

Copyright 2009, Oracle. All rights reserved.

Team Walk Through (15 minutes)


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:
- Return the value of the "person
flag" (e.g., Human or Business)

System Event: Determine BO


Algorithm: Use Person Flag

BO: Human

BO: Business

BO: GenericCustomer

System Event: Validate


Algorithm: Require 2 forms
of ID

System Event: Validate


Algorithm: Require
marketing contact

System Event: Validate


Algorithm: Require Primary
Phone

System Event: Preprocess


Algorithm: Default person
flag to Human

System Event: Preprocess


Algorithm: Default person
flag to Business

System Event: Preprocess


Algorithm: Default person
flag to Business

5 - 52

Copyright 2009, Oracle. All rights reserved.

Beware Of Entity Updates

Copyright 2009, Oracle. All rights reserved.

Entity Updates Don't Trigger BO Rules

All page maintenance and XAI services


perform their updates via the MO service
layer

However, older MO's may have background


processes and common routines that do
not go through their 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
person MO, any rules that you've plugged in
on the BO will execute

Rather, they update the entities without


telling the MO about it
And, because it's the MO service layer that
invokes the BO plug-ins, this type of
updating will never execute your BO rules

We don't like this, but it's true

5 - 54

This type of updating is not terribly


common, but you need to think about it
when you design

Account
Account
CI_ACCT

Bill
Message
CI_ACCT_MSG

For example, the bill completion


routine can delete "one-time"
bill messages when it
completes a bill and it does not
go through the service layer

Copyright 2009, Oracle. All rights reserved.

Performance Concerns

Copyright 2009, Oracle. All rights reserved.

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,


theres 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...
5 - 56

Copyright 2009, Oracle. All rights reserved.

Here's What We Know About Performance Differences

There appears to be little difference for Ifs, Fors, Moves


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 arent called
during major batch processing

5 - 57

Copyright 2009, Oracle. All rights reserved.

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

5 - 58

Copyright 2009, Oracle. All rights reserved.

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

5 - 59

Copyright 2009, Oracle. All rights reserved.

Review Questions

5 - 60

Copyright 2009, Oracle. All rights reserved.

5 - 61

Copyright 2009, Oracle. All rights reserved.