Practices for Lesson 7: BO

Lifecycles
Overview

Copyright 2017, Oracle and/or its affiliates. All rights reserved.

Practices for Lesson 7: BO Lifecycles 344617905.doc

Effective mm/dd/yy Page 1 of 16 Rev 1
Practices for Lesson 7

Distribution
Job Title*

Ownership
The Job Title [list@YourCompany.com?Subject=Practices for Lesson 7: BO Lifecycles:
344617905.doc] is responsible for ensuring this document is necessary, reflects actual practice,
and supports corporate policy.

Lesson 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
In this section, you'll learn how to control the various stages of a BO's lifecycle.

Lesson Objectives
By the end of this chapter, you will be able to:
Understand how each BO's lifecycle is configurable via the BO meta data
Understand the lifecycle-oriented plug-in spots in which lifecycle-oriented business
rules reside
Understand how to defer the processing of some states to batch processes (in order to
reduce real-time processing)
Understand how lifecycle can be inherited (and lifecycle rules)
Understand what a "save point" is and how to use one in your logic

Copyright 2017, Oracle and/or its affiliates. All rights reserved.

Practices for Lesson 7: BO Lifecycles 344617905.doc

Effective mm/dd/yy Page 2 of 16 Rev 1
Practice 7-2: Examine a BOs Lifecycle

Overview
During this exercise, we'd like you to use the following:
Admin Business Object (all tabs)

Tasks
Please break up into teams. Each team should do the following:
Examine the lifecycle of the D1-InitialLoadIMDInterval business object as well as the
configuration of the Initial Measurement Data maintenance object (D1-IMD).
Prepare a list of the top cool things about lifecycle rules (and BO's in general) you
noticed based upon this section's slides.
Instructors Notes
The Initial Measurement Data (IMD) lifecycle is among the most complex within the MDM
product. It utilizes a number of concepts covered within the slides for this section, including:
The lifecycle includes transitory states. The Additional Mapping state is empty, serving as a
placeholder for logic contained solely within child BOs. This is somewhat unusual, as future
chapters on the topic of extending BO functionality will show, but we felt it documented the
purpose of the state. No IMD should ever persist in the Additional Mapping state.
The Force Complete state is a second transitory state. We wanted to obtain a status reason
from any user who attempts to transition an IMD out of the Exception state without revalidating
it. One alternative design - to allow a user to transition an IMD directly from Exception into
Finalized - would not have allowed us to differentiate that action from transitioning an IMD from
VEE Complete into Finalized (which is what usually occurs); we would have needed to require a
status reason on the Finalized state, which we only really need in less than 1% of the cases. As
designed, we require a status reason for IMDs entering the Force Complete state. If a user
transitions an IMD from Exception into Force Complete (which is configured with a Monitor
algorithm that transitions the IMD into the Finalized state), and an error occurs during the
execution an Enter algorithm plugged in on the Finalized state, the IMD will be rolled back to the
Exception state.
The maintenance object does not feature a transition error plug-in. This means that no save
points will be taken during state transition.
With the 2.0.1 release, the IMD maintenance object will feature a transition plug-in that will do
nothing. This prevents the creation of maintenance object log entries, and was done to
minimize the number of database inserts taking place during the processing of an IMD.
The Pending state has a monitor process defined, which means that when an IMD is created, it
will remain in this state until the monitor process is run.
The Exception state has an exit algorithm that completes any To Do entries that had been open
for the IMD.

Copyright 2017, Oracle and/or its affiliates. All rights reserved.

Practices for Lesson 7: BO Lifecycles 344617905.doc

Effective mm/dd/yy Page 3 of 16 Rev 1
Practice 7-2: Examine BO Inheritance of a Lifecycle

Overview
During this exercise, you will use the following:
Admin Business Object (All Tabs)

Tasks
Please break up into teams.
In the demo database, weve created a child BO of the D1-ServicePoint business object called
DM_StandardServicePoint.
Prepare a presentation describing every difference you can see on the BO maintenance
transaction between when a top-level parent BO is displayed versus when a child BO is
displayed
Instructors Notes
On the Main tab, for Child BO's, the system allows for the definition of a Parent Business Object
and it shows the "top level" Lifecycle Business Object. These fields are not shown for the
Parent BO as it has a lifecycle and if a BO has a lifecycle, it can't have a parent (or a lifecycle
BO).
Notice how the parent has so many options (we haven't covered options yet, but you might want
to highlight that the parent's options are inherited by the child BO and therefore the child BO just
has to declare what's different).
On the Schema tab, again, while it's not a transactional difference, notice how the child BO's
includes the parent BO's schema.
On the Algorithm tab, again, while it's not a transactional difference, notice how the child BO
doesn't have may algorithms (because they are inherited from the parent BO).
On the Lifecycles tab on a child BO you dont see the + / - buttons in the accordion. If you open
the accordion, you'll see that child BO's can only specify Algorithms and Options. All of the
other fields (e.g., next states and the descriptive information about the state) can only be
defined on the parent BO.
The Summary tab doesn't have functional differences however the data that is shown in the
various zones is very different. Notice how the tree works for each. Also notice how the Rule
and Options tree display the superset of rules and options for the child BO (i.e., it will show the
algorithms and options from all higher levels in the BO hierarchy).

Copyright 2017, Oracle and/or its affiliates. All rights reserved.

Practices for Lesson 7: BO Lifecycles 344617905.doc

Effective mm/dd/yy Page 4 of 16 Rev 1
Practice 7-2: Add Simple Validation to the New Child BO

Overview
In this walk thru, you'll add validation to it (you'll see in an addendum that, in real life, you
wouldn't have to put the validation on a new child BO, rather, you'd put it on the base-package
BO, but doing it this way allows us to avoid concurrency issues with multiple team updating the
same BO).

Tasks
1. Navigate to the Business Object Page
Open the Business Object page (it's on the Admin menu) and display your business
object XXX_StandardServicePoint business object (where XXX are your initials).

2. Remove Your Validation Plug-In

Navigate to the Algorithms tab and remove the Validation plug-in by clicking the - button.

Save your work. At this point, your start date validation has been removed from your BO.
We'll now add a new plug-in in that will execute when a user attempts to deactivate the BO.
This new plug-in will contain the same logic from your original plug-in (i.e., it'll validate the
customer area information).

Copyright 2017, Oracle and/or its affiliates. All rights reserved.

Practices for Lesson 7: BO Lifecycles 344617905.doc

Effective mm/dd/yy Page 5 of 16 Rev 1
3. Create a New Plug-In Script
Note: The next several steps are a bit cumbersome, but we wanted to expose you to what
the Create Algorithm button does "behind the scenes" in case you have to make changes to
what the wizard creates.
Open the Script page in add mode (it's on the Admin menu). Please supply the following
information:
Name: XXX_SP_ENT1 (where XXX are your initials)
Description: XXX Service Point Inactivation Validation (where XXX are your initials)
Script Type: Plug-in
Algorithm Entity: Business Object Status - Enter
Business Object: XXX_StandardServicePoint
Script Engine Version: 1

Save your work.

Copyright 2017, Oracle and/or its affiliates. All rights reserved.

Practices for Lesson 7: BO Lifecycles 344617905.doc

Effective mm/dd/yy Page 6 of 16 Rev 1
4. Check Out this Plug-in Spot's API
Navigate to the Step tab and click the View Script Schema link.

Notice that the hard parameters are very different from those supplied to the Validation
plug-in you wrote in the previous chapter. Specifically notice that you are not supplied the
BO's elements like you were for the Validation plug-in spot. This means that before you can
validate the address information, you'll have to read the BO.
Why aren't the elements supplied? The reason that Enter plug-ins do not supply the
BO's before and after image like Validation plug-ins do is because Enter (and Exit and
Monitor) plug-ins can change the BO and the framework did not want to have to re-read
the BO before every enter plug-in (as there are many Enters that may not need the BO).

Copyright 2017, Oracle and/or its affiliates. All rights reserved.

Practices for Lesson 7: BO Lifecycles 344617905.doc

Effective mm/dd/yy Page 7 of 16 Rev 1
5. Add the BO's Schema to your Script
In order to read your BO, you must extend your script's XML document to hold your BO's
schema. To do this, navigate to the Data Area tab and enter the following information:
Schema Type: Business Object
Object: XXX_StandardSericePoint
Data Area Name: this defaults to the same name as our Object; you can leave this.

Save your work.

6. Check Out The Script's Schema
Return to the Step tab. Click the View Script Schema link again. Notice how the Script's
schema now contains your BO:

Copyright 2017, Oracle and/or its affiliates. All rights reserved.

Practices for Lesson 7: BO Lifecycles 344617905.doc

Effective mm/dd/yy Page 8 of 16 Rev 1
7. Add Your Logic
Return to steps page and add the following steps:
Step 10 will move the prime key of the Service Point supplied by the framework in the
hard parms to your BO's schema. This is necessary because, before you can read a
BO, you must populate the elements that hold its PK with the value to be read. Note,
you'll find that clicking on the desired elements in the schema pop-up is a far faster way
to define the Source and Destination Field Names.
You should enter the following values:
Step Sequence: 10
Step Type: Move data
Text: Populate the PK of the service point in preparation for read
Source Field Type: Data Area
Source Field Name: parm/hard/businessObjectKey/spId
Destination Field Type: Data Area
Destination Field Name: XXX_StandardServicePoint/spId

Note, if you wanted to use an Edit data step instead of a Move data, your Edit Data
Text would be:
move "parm/hard/businessObjectKey/spId" to "XXX_StandardServicePoint/spId";
Step 20 will read the BO (i.e., populate the section of the script's schema with the BO's
elements). You should enter the following values:
Step Sequence: 20
Step Type: Invoke business object
Text: Read the Service Point
Group Name: XXX_StandardServicePoint (note, this is the group node in the
script's XML document that is passed to the BO service)
Business Object: XXX_StandardServicePoint
Action: Read

Copyright 2017, Oracle and/or its affiliates. All rights reserved.

Practices for Lesson 7: BO Lifecycles 344617905.doc

Effective mm/dd/yy Page 9 of 16 Rev 1
 Note, if you wanted to use an Enter data step instead of a Move data, you'd have just
entered Edit Data Text of:
invokeBO 'XXX_StandardServicePoint' using "XXX_StandardServicePoint" for read;
Step 30 will contain your validation. You should enter the following values:
Step Sequence: 30
Step Type: Edit data
Text: Validate that if the customer area is CANTON, the temperature zone is either
N (North Stark County) or S (South Stark County)
Edit Data Text :
if ("XXX_StandardServicePoint/customerArea = 'CANTON'")
if ("XXX_StandardServicePoint/temperatureZone != 'N' and
XXX_StandardServicePoint/temperatureZone != 'S'")
terminate with error (90000, 30000 element='temperatureZone');
end-if;
end-if;

Save your work.

Note: Xpath is not validated. 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.
Note, rather than enter 3 steps, you could have had a single Edit data step that looked
as follows:

Copyright 2017, Oracle and/or its affiliates. All rights reserved.

Practices for Lesson 7: BO Lifecycles 344617905.doc

Effective mm/dd/yy Page 10 of 16 Rev 1
 At this point, we're ready to do the tedious tasks that the "Create algorithm" wizard did for
us.

Copyright 2017, Oracle and/or its affiliates. All rights reserved.

Practices for Lesson 7: BO Lifecycles 344617905.doc

Effective mm/dd/yy Page 11 of 16 Rev 1
8. Create a New Algorithm Type
Open the Algorithm Type page in add mode (it's on the Admin menu). Please supply the
following information:
Algorithm Type: XXX_SP_ENT1 (where XXX are your initials)
Description: XXX Service Point Inactivation Validation (where XXX are your initials)
Detailed Description: This plug-in validates the temperature zone of the service
point to ensure that it corresponds to the customer area.
Algorithm Entity: Business Object Status - Enter
Program Type: Plug-In Script
Plug-In Script: XXX_SP_ENT1 (where XXX are your initials)

Save your work.

Copyright 2017, Oracle and/or its affiliates. All rights reserved.

Practices for Lesson 7: BO Lifecycles 344617905.doc

Effective mm/dd/yy Page 12 of 16 Rev 1
9. Create a New Algorithm
Open the Algorithm page in add mode. The easiest way to do this if you're on the algorithm
type page is to click the context menu adjacent to Algorithm Type and click the + button
adjacent to Algorithm:

This will transfer you to the algorithm page ready to add an algorithm for this algorithm type.
Please supply the following information:
Algorithm Code: XXX_SP_ENT1 (where XXX are your initials)
Description: XXX Service Point Inactivation Validation
Algorithm Type: XXX_SP_ENT1 (where XXX are your initials)

Save your work.

Copyright 2017, Oracle and/or its affiliates. All rights reserved.

Practices for Lesson 7: BO Lifecycles 344617905.doc

Effective mm/dd/yy Page 13 of 16 Rev 1
10. Plug In Your Algorithm
Return to your business object and navigate to the Lifecycle tab.

In the Algorithms grid, enter the following:

System Event: Enter
Sequence: 10
Algorithm: XXX_SP_ENT1 (where XXX are your initials)
Save your business object.
Navigate to the Algorithms tab. Remove your validation algorithm, as in this case its logic
will execute redundantly with the lifecycle algorithm.
Save your business object.
You're now ready to test your work (and you can see how much work the Add algorithm
wizard saves you). To test your work, display your service point with a customer area of
Canton, and try to deactivate it with a temperature zone that is neither North nor South
Stark County. You should see the following error:

Copyright 2017, Oracle and/or its affiliates. All rights reserved.

Practices for Lesson 7: BO Lifecycles 344617905.doc

Effective mm/dd/yy Page 14 of 16 Rev 1
Review Questions

1. All MO's can have lifecycle rules defined using the business object meta-data. True/False
False. Only MO's with a status column that have been introduced after version 2.1 can take
advantage of the BO lifecycle functionality.
2. Two BO's linked to the same MO may have different lifecycles. True/False
True. This is only true if the BO's are not child BO's (see next question).
3. Every business object may have a different lifecycle. True/False
False. Trick question - child BO's inherit their lifecycle from their topmost parent BO and
therefore cannot have their own.
4. While child BO's can't have their own lifecycle, they can have their own lifecycle rules (i.e.,
you can plug-in Enter, Exit and Monitor plug-ins on child BO's). True/False
True
5. When defining a BO's lifecycle, multiple statuses can be defined as initial. True/False
False
6. When defining the lifecycle of a BO, multiple status values may be defined as final.
True/False
True
7. When a BO transitions into a new state, all exit algorithms on the old state are executed and
then, if there are no errors, all enters on the new state are executed. True/False
True
8. If the state into which an object is being transitioned has a monitoring algorithm, this
algorithm will be executed when the object enters the state. True/False
True/False. Trick question - if the state into which a BO is transitioning has a "monitoring" batch
process linked to it, the monitoring algorithm(s) will NOT be invoked when the BO enters the
state. Rather, the invocation will be deferred to when the batch process executes.
9. An Enter plug-in can tell the framework to transition the object into a new state. True/False
True
10. If an Enter plug-in tells the framework to transition a BO into a new state, none of the
Monitoring plug-ins on the state will execute; however the Exit plug-ins will execute before
the BO leaves the state. True/False
True
11. It's possible, in a single logical transaction, for a BO to enter and exit several states.
True/False
True
12. Deferring the monitoring of a BO to a batch process might be a wise decision if it results in
"heavy processing". True/False
True

Copyright 2017, Oracle and/or its affiliates. All rights reserved.

Practices for Lesson 7: BO Lifecycles 344617905.doc

Effective mm/dd/yy Page 15 of 16 Rev 1
13. If the base-package ships a BO / State without a reference to a monitoring batch process,
the implementation team cannot defer monitoring of this state. True/False
False. Trick question - you don't know this, but the monitoring batch process on a base-package
owned BO can be changed by an implementation team. We refer to this type of column as
being "CM-able" and it can be Customer Modified while still being owned by the base-package.
This means that any changes made by the team to this column will survive the upgrade.
14. If a MO is missing its Determine BO plug-in, none of the lifecycle rules will execute.
True/False
True
15. It is impossible for a BO to reside in a state that is marked as Transitory. True/False
True
16. A "save point" is kind of like a logical transaction within a logical transaction. True/False
True
17. Save points will only be issued if the appropriate plug-in has been defined on the BO's MO.
True/False
True
18. Most post 2.1 MO's that have a status column also have a log table. True/False
True
19. The logic to create log entries when a BO is created and when its state changes is done in
algorithms that are plugged in on the BO. True/False
False. The base MO has the logic to create the "created" and "state transition" log entries so
you don't have to plug-in anything to get these.

Copyright 2017, Oracle and/or its affiliates. All rights reserved.

Practices for Lesson 7: BO Lifecycles 344617905.doc

Effective mm/dd/yy Page 16 of 16 Rev 1