Professional Documents
Culture Documents
Overview
Up to now, you've learned to:
In this section, you'll learn how to use "options" to control a BO's behavior.
Chapter 8
Objectives
10-Oct-16
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:
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.
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
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.
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