Professional Documents
Culture Documents
Lifecycles
Overview
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
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.
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).
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).
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).
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).
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
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)
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