Académique Documents
Professionnel Documents
Culture Documents
BUSINESS OBJECT
INHERITANCE
Overview
Up to now, you've learned to define a BO's data structure and basic business rules. In
this section, you'll learn techniques to avoid redundant logic.
Create common data structures that can be reused amongst business objects.
Chapter 6
Objectives
10-Oct-16
Note. You'll learn more about debug mode later in this class.
New Message
10-Oct-16
Chapter 6
10-Oct-16
10-Oct-16
When prompted, indicate you want to create a BO Algorithm (rather than a BO Status
Algorithm). You will then be asked to enter basic information about your new algorithm.
Please supply the following information:
Sequence: 10
Chapter 6
10-Oct-16
When you click Save, the system will add a plug-in script, an algorithm type, an
algorithm, and plug the new algorithm in on the BO in the specified System Event. It will
then transfer you to the new plug-in script's Steps tab where you should create the
following edit data step:
The framework is not able to validate information within double quotes (i.e., the Xpath),
therefore take care with what you enter. If you have entered invalid Xpath, you'll see a
"nasty" error at execution time.
Navigate to the Main tab and set the Script Engine Version to 2.0 as you are using
Xpath 2 in your script. If you don't do this, you can't use the date casting function
(xs:date).
Script - Main
When you save the script, you're ready to test your work. To do this, choose Admin Conservation Program + and see if your validation works as desired. Note, you should
see the description of your BO in the dropdown that appears when initiate the addition of
a new conservation program.
Instructors Notes
The xpath to check if startDate is before the current date (note $CURRENT-DATE is
a global and they can read about more globals in the script tips):
if ("xs:date(parm/hard/newBusinessObject/generalInfo/startDate) >
xs:date($CURRENT-DATE) ")
terminate with error (90000, xxxxx element='generalInfo/startDate');
end-if;
10-Oct-16
Chapter 6
10-Oct-16
Review Questions
1. A stand-alone data area can be included in an unlimited number of BO schemas.
True/False
2. If you add, change or remove an element from a stand-alone data area, you must
display and save all BO's that include it. True/False
When you save a stand-alone data area, the framework dynamically changes all
business objects that include it; no "recompilation" is necessary.
3. You can use the Schema tab on the Data Area maintenance page to see all of the
business objects that include the data area. True/False
4. If a BO includes a parent BO's schema, and the parent BO's schema includes a
stand-alone data area; you can easily see all elements in the child BO by clicking the
View Schema hyperlink on the BO - Main page. True/False
5. A BO's parent BO must be part of the same MO. True/False
6. A parent BO's schema is automatically included in all of its children. True/False
7. It's a good practice to include a parent BO's schema in a child BO. True/False
This way, if the parent changes, the children (and grandchildren, and great
grandchildren, etc.) change automatically.
8. If you add or remove a Validation plug-in from a parent business object, you must
"recompile" all child BO's for the change to take effect. True/False
When you add or remove a plug-in from a parent BO, the framework affects the
change immediately; no "recompilation" is necessary.
9. A plug-in that's been developed for one child BO can be used by any number of
other BO's. True/False
But, if you've developed a BO hierarchy, it's probably a better idea to plug the
algorithm in on the parent BO rather than on each individual child BO.
10. A BO that's owned by the base-package cannot be changed by an implementation
team. True/False
While the implementation team cannot change the schemas of base-package owned
BO's, they can add additional plug-ins and disable base-package plug-ins (and a few
other things) without having to create a child BO.
11. A BO that's owned by the base-package cannot be used as a parent BO by an
implementation team. True/False
Allowing implementations to add elements to our BO's is a big part of our value as
we develop fully functioning, robust BO's that can then be easily extended by our
customers without having to perform database changes, Java builds, etc.
12. If you plan to create a BO hierarchy that's more than 3 levels deep, it's probably wise
to get a second opinion. True/False
BO hierarchies are as tempting as class hierarchies and can be equally misused
and, ironically, result in a maintenance nightmare as it becomes difficult to find where
logic is executing.