C

BUSINESS OBJECT OPTIONS

Overview
Up to now, you've learned to:

Define a business object's data structure

Define basic business rules for a business object

Create a hierarchy of business objects to allow logic reuse via inheritance

Control the various stages of a BO's lifecycle

In this section, you'll learn how to use "options" to control a BO's behavior.

By the end of this chapter, you will be able to:

Understand how certain MO options must be set up in order for core functionality
to operate
Understand how the framework uses BO options to implement certain types of
business rules
Understand how implementation teams can use BO options to extend a basepackage BO's business rules

Add additional BO (and MO) options

Understand how to inactivate base-package plug-ins by setting up MO and BO

options

2016 Oracle Proprietary and Confidential

Business Object Options

Chapter 8

Objectives

10-Oct-16

Oracle Configuration Tools Training Workbook

Walk ThroughAdd an Option to a BO

During this walk through we'd like you to use the following:

Admin Business Object

Let's split up into teams. Each team should do the following:

Using your team's business object, find an element that is currently optional and
set up a BO option to make it required when you enter a state.
Note: you probably will not understand all of the available option types (most will be
unveiled later in the course).
Instructors Notes
For example, if they want to make End Date required when a new conservation
program is added, they should:
-Go to the BO Lifecycle tab
-Expand the accordion for the Pending state
-Add an option whose Option Type is Required Element
-The option value is generalInfo/EndDate
They just need to add a new conservation program and they should see the error
End Date is missing

8 - 2 Business Object Options

2016 Oracle Proprietary and Confidential

Oracle Configuration Tools Training Workbook

10-Oct-16

Walk Through Explore the Options Associated with MOs and BOs
During this walk through we'd like you to use the following:

Admin Business Object (Summary Options Tree)

Admin Maintenance Object (Options)

Let's split up into teams. Each team should do the following:

Open the approval profile blueprint and check out how options have been
designed for both MO's and BO's.
Prepare a presentation describing the differences between the options in the
blueprint and the options in the released system.
Also:
How many idiosyncratic options have been set up for BO's belonging to the
conservation program MO and the approval profile MO.
Display your conservation program BO and check out the Options zone on the
BO Summary to see how it shows option values from all levels in the BO's
hierarchy.
Note: Many of these option types are UI oriented and we'll explain these in the upcoming
UI chapters.
Instructors Notes
The Approval Profile MO Options

The blueprint called for another MO option for a Valid BO Algorithm System Event
whose option value is Determine Approval Requirements. You'll see that the
released MO has this option (and it is this option that allows BO's belonging to this
MO to have an additional system event on their BO Algorithm grid).
The released MO has two options that were not in the blueprint as these only came
up later in the design / doc process:
The BO Maintenance Y/N option is an option that has to be declared on all MO's and
it controls whether the framework will support updates to this MO's BO's via
InvokeBO steps. For all new MO's, this is set to Y. For pre 2.2 MO's, this may be Y
or N depending on the logic behind the MO (we try to set as many as possible to Y).
The Maintenance BPA Script is just there for documentation purposes. They don't
know about BPA scripts at this point, but this identifies the business process that will
be used to add, change and delete this MO's BO's. They'll learn about this in an
upcoming chapter.

2016 Oracle Proprietary and Confidential

Business Object Options

Chapter 8

In the blueprint, there are several MO options whose option type is Valid BO Option
and you'll notice that the released MO has no such options. The reason for this is
that we started seeing the these options (e.g., the BO's Preprocessing Script, The
BO's Add / Update UI Map, The BO's Post-processing Script, The BO's Maintenance
Portal, The BO's Display UI Map) were needed for most MO's so we added these as
"valid BO opions" for all BO's in the framework so we wouldn't have to declare them
on every MO.

10-Oct-16

Oracle Configuration Tools Training Workbook

The Approval Request MO Options

The released MO has several options that were not in the blueprint as these only
came up later in the design / doc process:
Just like the prior MO, this MO also has BO Maintenance set to Y (because it's a
new MO).
Notice the two Valid BO Option Types (C1AS and C1AR). These are lookup values
on the BUS_OBJ_OPT_FLG. When a BO of this MO is set up, these option types
are used to define the service scripts that are used to Approve the approval request
and Reject the approval request (these service scripts are invoked when the user
clicks the Approve / Reject buttons). This cleverness was only spotted during the
detail design process.
The Periodic Monitor Process is just there for documentation purposes (for now we
intend to use it for real in a future release). For now, it's just there so that
implementers know the batch process that periodically monitors this MO's BO's that
are in a state with a monitor algorithm.
The Status Field is there as the framework uses it to transition and monitor the state
of the MO's BO's. Any post 2.2 MO that has a lifecycle will have this option populate
(if not, none of the framework lifecycle processing will work).
You will see that all of the options that were in the blueprint are not defined on the
MO, one of these proved to be extraneous as the server scripting logic can figure out
the object being approved. The other ones (Status's Condition Flag Value, The BO's
Display UI Map and Service script) proved to be needed by all BO's for all MO's so
these were added to the framework to avoid having to set them up on every MO.
Have a look at the BO's that have been set up for each of these MO's, the options
are mostly UI oriented and the students will only learn (in chapter 19!) that we use
these BO option values so that implementers can configure new BO's and change
the base-package BO's and then not have to change the base-package UI (i.e., the
base-package UI is set up to interrogate these options and use them to control the
user experience when users add, change, delete, display, approve and reject stuff).

8 - 4 Business Object Options

2016 Oracle Proprietary and Confidential

Oracle Configuration Tools Training Workbook

10-Oct-16

Review Questions
1. If a base-package BO's MO has a status, you can use BO options to make elements
required when an object is created. True/False
You'd define these options on the Initial state.
2. If a base-package BO's MO doesn't have a status, you can use BO options to make
elements required when an object is created. True/False
You'd have to use a Validation plug-in on the BO to implement this. You could also
do this with a required=true schema attribute.
3. When you add a new MO, you'll almost always have to add options to it. True/False
For example, BO add, change, and delete processing will only be enabled if a given
MO option is set up to indicate such. This is because some older MO's do not
support BO interaction to do adds, changes and deletes. Rather, you have to use a
business service call to do this (which we'll discuss in a future chapter).
4. If your design adds a new plug-in spot to a BO, you must add an MO option to tell
the system about this new system event. True/False
If you don't add the MO option to declare the system event, the system event will not
appear in the BO / Algorithm drop down.
5. An implementation team can add option values to a base-package MO and they will
survive future upgrades. True/False
6. An implementation team can add new option types to a base-package MO and they
will survive future upgrades. True/False
And it's always wise for the implementation team to prefix the option type flag values
with "CM" to avoid naming collisions on future upgrades.

This is true for "single" options as the when the calling program asks the framework
for a "single" option value, it would return the option value "nearest" to the child BO
(and this would be the override value on the child BO). If the caller asked for a "multi
options", both the value on the parent and child BO's would be returned.

2016 Oracle Proprietary and Confidential

Business Object Options

Chapter 8

7. Assume an option value is defined on a parent BO, one of the child BO's can
effectively override the option value. True/False