Practices for Lesson 7: BO

Lifecycles
Overview

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

Practices for Lesson 7: BO Lifecycles 344617885.doc

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

Distribution
Job Title*

Ownership
The Job Title [list@YourCompany.com?Subject=Practices for Lesson 7: BO Lifecycles:
344617885.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 344617885.doc

Effective mm/dd/yy Page 2 of 15 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:
Read the portion of the Conservation Program blueprint that describes the design's
rebate claim BO. This is a little lengthy so try to be as efficient as possible.
Prepare a presentation describing the differences between the BO in the blueprint
(especially the lifecycle) and what was released.
Prepare a list of the top cool things you learned about lifecycle rules (and BO's in
general) that were not covered in this section's slides.
Instructors Notes
The BO Schema in the blueprint has some elements that were not put into the base product.
For example, Payee is a Business, Tax Status, Tax ID Number Type and Tax ID Number. These
turned out to be customer-specific and/or USA-centric and we opted to not include them in the
base (the customer can add them with a child BO).
The BO Schema in the blueprint also had an element for Email authentication as we were
hoping to support allowing an approving user to send an "approve email" rather than approving
the claim in the system. This was scoped out due to time constraints.
The BO Schema that was released has extra elements for error message parameters that are
kept on the claim (these errors are accumulated during the Verification phase).
The BO Algorithms were implemented as designed. Note, there are some simple techniques to
format dates and currency amounts using the user's display profile in the Info plug-in script.
The Lifecycles were implemented exactly as designed. This is to be expected as the designers
spend a lot of time worrying about lifecycles and changes are fairly rare by the time
development starts.
The Verification Enter plug-in in the blueprint had the vestige of some elements that had been
scoped out of the schema in the blueprint, but had been forgotten in the Verification step (e.g.,
Vintage, Number of Stories, ). Note, this plug-in is an example of a fairly complex bit of
validation and should be checked out for interesting examples.
Notice how the transition to the Issue Detected or Approval in Progress states is performed by a
Monitor plug-in on the Verification State rather than by the Enter plug-in. This was done as,
otherwise, an implementation couldn't add additional validation logic by adding additional Enter
plug-ins (if the base plug-in said to transition, the framework would never call any other plug-
ins).
The Issues Detected state has a nice bit of defensive logic to make sure that there's an issue
before they are allowed to enter this state. This was not in the blueprint and it was a good
catch.

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

Practices for Lesson 7: BO Lifecycles 344617885.doc

Effective mm/dd/yy Page 3 of 15 Rev 1
The Issues Detected state has a UI map that's dynamically invoked to capture the manual
issue. This was not in the blueprint as this technique was invented by the development team.
The Canceled state has a required element and a state transition UI map. These were not in
the blueprint as these techniques were not invented when the blueprint was written.
The Approval In Progress state's Monitor (used to be called Auto Transition) algorithm
transitions to the Receipt Verification state when all approvers (if any) have approved the claim.
The Approval In Progress state's Monitor (used to be called Auto Transition) algorithm that's in
the blueprint that was looking for stuff that was "Waiting Too Long" has to be configured as we
didn't ship it on the base BO as we felt an implementation team should set this up. So, there's
an algorithm type in the base for this, we just didn't set up a base algorithm and plug it in on the
base rebate claim BO.
The Approval In Progress state's Exit algorithm was not in the blueprint and it was a good catch
(to complete any hanging To Do entry when it leaves this state).
The Receipt Verification state was implemented as designed.
The Complete state was implemented as designed. This is a good sample of financial logic if
you need this in future plug-ins.
The Rejected state has a required element and a state transition UI map. These were not in the
blueprint as these techniques were not invented when the blueprint was written.

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

Practices for Lesson 7: BO Lifecycles 344617885.doc

Effective mm/dd/yy Page 4 of 15 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, we've created a child BO of the C1-ConservationProgram business
object called CI_ConservationProgram.
Note: We have a standard of labeling demo object as CI_ rather than C1- or CM so they can be
distinguished as being demo data as opposed to implementation or base-package data.
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).
While it's not a difference in the transaction, notice how the child BO has been set up to allow
instances, but the parent does not (check out the Instance Control field). Also 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 344617885.doc

Effective mm/dd/yy Page 5 of 15 Rev 1
Practice 7-2: Add Simple Validation To A New Child BO

Overview
In this walk thru, you'll create a new child BO and 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_ConservationProgram 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.

Business Object - Algorithm

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 inactivate
the BO. This new plug-in will contain the same logic from your original plug-in (i.e., it'll
check that the start date isn't in the future).
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_CP_ENT1 (where XXX are your initials)
Description: XXX Conservation Program Inactivation Validation (where XXX are
your initials)
Script Type: Plug-in
Algorithm Entity: Business Object Status - Enter
Business Object: XXX_ConservationProgram
Script Engine Version: 2

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

Practices for Lesson 7: BO Lifecycles 344617885.doc

Effective mm/dd/yy Page 6 of 15 Rev 1
 Script - Main

Save your work.

4. Check Out This Plug-in Spot's API
Navigate to the Step tab and click the View Script Schema link.

Script - Schema

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 that the start date is not in the future, 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).
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_ConservationProgram
Copyright 2017, Oracle and/or its affiliates. All rights reserved.

Practices for Lesson 7: BO Lifecycles 344617885.doc

Effective mm/dd/yy Page 7 of 15 Rev 1
 Data Area Name: this defaults to the same name as our Object; you can leave this.

Script - Data Area

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:

Script - Schema

7. Add Your Logic

Return to steps page and add the following steps:
Step 10 will move the prime key of the conservation 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,

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

Practices for Lesson 7: BO Lifecycles 344617885.doc

Effective mm/dd/yy Page 8 of 15 Rev 1
 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 conservation program in preparation for read
Source Field Type: Data Area
Source Field Name: parm/hard/businessObjectKey/conservationProgram
Destination Field Type: Data Area
Destination Field Name: XXX_ConservationProgram/conservationProgram

Script - Step - 10

Note, if you wanted to use an Enter data step instead of a Move data, your Edit Data
Text would be:
move "parm/hard/businessObjectKey/conservationProgram" to
"REW_ConservationProgram/conservationProgram";
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 conservation program
Group Name: XXX_ConservationProgram (note, this is the group node in the script's
XML document that is passed to the BO service)
Business Object: XXX_ConservationProgram
Action: Read

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

Practices for Lesson 7: BO Lifecycles 344617885.doc

Effective mm/dd/yy Page 9 of 15 Rev 1
 Script - Step - 20

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_ConservationProgram' using "XXX_ConservationProgram" for
read;
Step 30 will contain your validation. You should enter the following values:
Step Sequence: 30
Step Type: Edit data
Text: Validate that the start date is not in the future
Edit Data Text:
if ("xs:date(XXX_ConservationProgram/generalInfo/startDate) >
xs:date($CURRENT-DATE)")
terminate with error (90000, 1500 element='generalInfo/startDate');
end-if;

Script - Step - 30

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 344617885.doc

Effective mm/dd/yy Page 10 of 15 Rev 1
 At this point, we're ready to do the tedious tasks that the "Create algorithm" wizard did
for us.
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_CP_ENT1 (where XXX are your initials)
Description: XXX Conservation Program Inactivation Validation (where XXX are
your initials)
Detailed Description: This plug-in validates a conservation program's start date is
not in the future.
Algorithm Entity: Business Object Status - Enter
Program Type: Plug-In Script
Plug-In Script: XXX_CP_ENT1 (where XXX are your initials)

Algorithm Type - Main

Save your work.

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_CP_ENT1 (where XXX are your initials)

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

Practices for Lesson 7: BO Lifecycles 344617885.doc

Effective mm/dd/yy Page 11 of 15 Rev 1
 Description: XXX Conservation Program Inactivation Validation (where XXX are
your initials)
Algorithm Type: XXX_CP_ENT1 (where XXX are your initials)

Algorithm - Main

Save your work.

10. Plug In Your Algorithm
Return to your business object and navigate to the Lifecycle tab.

Business Object - Lifecycle

In the Algorithms grid, enter the following:

System Event: Enter
Sequence: 10
Algorithm: XXX_CP_ENT1 (where XXX are your initials)
Copyright 2017, Oracle and/or its affiliates. All rights reserved.

Practices for Lesson 7: BO Lifecycles 344617885.doc

Effective mm/dd/yy Page 12 of 15 Rev 1
 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 BO and try to deactivate it with a start
date that's in the future. You should see the following error:

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

Practices for Lesson 7: BO Lifecycles 344617885.doc

Effective mm/dd/yy Page 13 of 15 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 344617885.doc

Effective mm/dd/yy Page 14 of 15 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 344617885.doc

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