11 Business Services

11
Business Services
Copyright 2009, Oracle. All rights reserved.
Check Point
Up to now, we've discussed how you can develop:
Business objects to read, add, change, delete MO's
BO's are also useful to handle state-specific processing
Service scripts to perform functions that transcend MO's
In this section, we'll discuss how you can use a different

technique to achieve similar results
11 - 2
Business Services Invoke Core Services

There are a multitude of base-package Java and Cobol services that
do things other than read, add, change and delete MO's
For example,
Theres a service that can add, generate and freeze an adjustment in one
step
Theres a service that can easily add a log entry to a case
There's a service that can send an email message
There's a service that can verify a credit card number and debit the
customer's account

You can imagine that being able to invoke these services would enrich
your BO's and service scripts
To do this, you create a business service and then invoke the
business service in your BO rules and service scripts
11 - 3
Business Services Front-End Backend Services

A business service front-ends a service in the same way a
business object front-ends a maintenance object
A table linked to the
person MO
A BOs schema maps the BOs

elements to the MOs tables and
fields
MO
Business
Object
IndividualTaxpayer BO Schema
<taxpayerId mapField="PER_ID"/>
<email mapField=EMAILID"/>
...
11 - 4
Service
Program
Business
Service
A service program that performs

date arithmetic
A BSs schema maps the BSs

elements to the elements in the
service program's XML
document
DateMath BS Schema
<option mapField="OPTION_FLG"/>
<beginDate mapField="BEGIN_DTTM"/>
<endDate mapField="END_DTTM"/>
...
Business Services Are Invoked From Scripts

The main reason to set up a business service is so that your plug-in
and service scripts can invoke the underlying Java / Cobol program
Foreshadowing in the user-interface (UI) section of this class, you'll
learn how you can set up a business service to invoke a Java / Cobol
service from the UI
Script
(Plug-in &
Service)
Step
11 - 5
And yes, Edit data steps can also

invoke business services
Step Type
Conditional branch
Edit data
Go to a step
Invoke business object
Invoke business service
Invoke service script
Label
Move data
Terminate
Team Walk Through (30 minutes)

Exploring business services
Break up into teams and follow the instructions in the workbook
11 - 6
11
Business Services
Not All Backend Common Routines Have Services
Common Routines Without Service Programs

Due to time-constraints, some base-package common
routines do not have a service program
This means you cant create a business service for them
You have two choices:

You can find a CM developer to write a service program to wrap
the common routine (this is coded in Java)
If you do this, you may want to send it to PD for inclusion in the next
release so others can benefit from your hard work
You can log an SR and have PD do it

This may take longer than you can affored
11 - 8
11
Business Services
Anomalous Interactions With Anomalous MOs
Not All MOs Can Be Maintained Via BO Interaction

A limited number of maintenance objects cannot be added, changed,
or deleted via a BO; these typically are transaction-oriented MOs like:
Bill
Payment
Adjustment
Payment Plan
To add, change or delete these MOs, you must set up a business

service to communicate directly with the MOs service
The system lets you know on the BO

transaction if the related MO is a read only
11 - 10
Note Well: All MOs Can Be Read Via BO Interaction

You can use BO interaction to READ any MO
You can read BO's in service scripts, map zones, info zones and
query zones
For example,
You can retrieve a bills bill date by setting up a bill BO
You can retrieve the collection of bill lines from a bill segment by
setting up a bill segment BO

Efficiency Concerns it is MUCH more efficient to read an

MO using a BO interaction rather than using a business
service call
This is because the framework only physically retrieves the data
mapped in the BO's schema when you do a BO interaction
If you use a business service (that invokes the MO service), all
attributes on the MO are retrieved (even if you just need one)
11 - 11
State Transition Changes Cannot Be Done Via BO

Interaction For Older MO's
You must use a business service to perform state changes for MO's that predate 2.2
For example, if you want to change a SAs state from, say, Pending Start to Active,
you must set up a business service to communicate directly with the MOs service:
Service
Program
This is an example of a business service

related to the SA Page Maintenance service
Notice the pageAction= in the schema node
Business
Service
Notice the usage of
default= and private= (this
means the invokers of this
service don't even know
about the activate
element)
11 - 12
ActivateSA BS Schema
<schema pageAction="update" >
<saId mapField="SA_ID" />
<activate mapField="ACTIVATE_SW" default="true" private="true" />
These are two elements in the SA page service

There are MANY other elements in the SA page service, you only need to
map the ones that you care about (in this example, we only need the SAs ID)
11
Business Services
Validation
Validating The Input Variables

You can use the dataType= and required=true on the
elements if you want the system to perform basic
validation on the input parameters
This would be a "double-check" as the underlying service should
have this validation
Service
Program
Business
Service
DateMath BS Schema
<option mapField="OPTION_FLG" dataType="lookup" lookup="OPTION_FLG"/>
<beginDate mapField="BEGIN_DTTM" dataType="dateTime" required="true"/>
<endDate mapField="END_DTTM" datatype="dateTime"/>
...
11 - 14
Team Walk Through (60 minutes)

Add post-processing to a new child BO
Break up into teams and follow the instructions in the workbook
Before you start adding any meta-data, please check your
solution against the answer in your workbook
11 - 15
Warning! - Advanced Concepts Ahead

The remainder of this section describes advanced
concepts
If these concepts prove challenging, take a step back and
ask yourself if you understand the concept being taught;
you can always return to the slides (and the related tips
and user documentation) when you need to take
advantage of these concepts in the future
11 - 16
11
Implementing Save Points
Errors
By default, any error produced by a service script causes a roll
back of ALL changes that occurred before the error occurred
(including any changes done by the BO / service script that
invoked the script)
For example, if a Post Processing algorithm invokes a script and it
throws an error, the algorithm will also error and the entire
transaction will roll back
There is a way for the caller to tell the framework the following:
Take a save point before the service script starts
If there's an error in the script, roll back changes to the save point and
return the error to the caller (the caller can then determine what to do
with the error)
A classic example is when you want to call scripts to perform

basic validation and if a validation error occurs, just save it and
keep calling the other validation scripts. Then, return all errors
rather than just the first one detected.
11 - 18
How To Issue A Save Point Before Executing A Service

Script
The base-package is supplied with a business service called F1SavePointDispatcher
You pass this business service the name of the service script and the
service script's data area (this is held in a "raw" element in the save point
dispatcher's data area)
When invoked, this business service:
Issues a save point before it starts the script,
It then executes the script
If there are errors, it rolls back to the save point and returns the error message
number to the caller (and the caller can do what it wants with it)
// populate the service script's parameters
move "personId" to "C1-RequestLetterDataArea/input/personId";
move 'CC' to "C1-RequestLetterDataArea/input/customerContactClass";
move 'REMINDER' to "C1-RequestLetterDataArea/input/customerContactType";
// populate the script name and its data area in the save point dispatcher's parameters
move "C1-RequestLetterDataArea" to "F1-SavePointDispatcher/scriptData";
move 'C1-ReqLetter' to "F1-SavePointDispatcher/scriptName";
// invoke the save point dispatcher
invokeBS 'F1-SavePointDispatcher' using "F1-SavePointDispatcher";
11 - 19
The name of the service script and the

script's data area are passed to the
F1-SavePointDispatcher business
service in its data area
11
Summary of default= Behavior
default=
You've seen how elements in BO, BS and SS schemas can have an
attribute of default=
This attribute is used to default an element's value if its node is not
specified in the service call or if it's specified with an empty value
The upcoming slides will describe when the system defaults the
specified value based on a combination of the following factors:
Is the service call is related to a persistent object (i.e., BO calls and BS
calls linked to an MO service) or to a non-persistent object (i.e., SS calls
and BS calls linked to a non-MO service)
If the element has required="true" or private="true" attributes
If the related database action is add or update (for persistent object calls)
If the element's node is present, but empty
If the element's node is not present
In other words, just because an element has a default= attribute

doesn't mean the value will be defaulted
11 - 21
Empty Nodes versus Not Present Nodes

Before describing the default= logic, it's important to
understand that when a BO, BS or SS data area is
included in a script, its nodes are not present by default
The nodes are added as a result of move statements (or by
the service being invoked)
Let's assume this BO is
included in a script's data area
IndividualTaxpayer Schema
<taxpayerId mapField="PER_ID"/>
...
<homeAddress type="group">
<country mapField="COUNTRY" />
<address1 mapField="ADDRESS1"/>
<address2 mapField="ADDRESS2"/>
<city mapField="CITY"/>
<postal mapField="POSTAL"/>
<state mapField="STATE"/>
<homeAddress />
...
11 - 22
If you were to look at the script's XML document

prior to the execution of the move statement, no
nodes would be present. If you were to look after
the move statement, you'd see one node present
move '1232121211' to "IndividualTaxpayer/taxpayerId"

invokeBO 'IndividualTaxpayer' using "IndividualTaxpayer" for read;
After the invokeBO statement, the remaining

nodes will be added to the XML document. If the
person doesn't have a home address, the
homeAddress nodes will be present, but empty
default= For Persistent Object Calls

If the underlying service is related to a persistent object (i.e., all BO services or a
BS service invocation that's linked to an MO service) and the element is either
not specified or empty:
If the element also has an attribute of required="true" OR private="true":
On add, defaulting always occurs (we assume that the value on the database should be
populated with the default value if it's not present in the schema or has an empty value in the
schema)
On update:
If the element is present but empty, defaulting occurs (we assume the value in the database
should reflect the default= value)
If the element is not present, defaulting will NOT occur (we assume the value in the
database should remain)
Otherwise (the element has neither required="true" nor private="true")

On add:
If the element is present but empty, defaulting will NOT occur (we assume because its not
required on the database, the "blank" value in the service call is the value that should be
put into the database)
If the element is not present, defaulting will occur (we assume because the service doesn't
contain the element that the default value in the schema should be put into the database)
On update, defaulting will NOT occur regardless of whether the element is empty or not present
11 - 23
default= For Non-Persistent Object Calls

If the underlying service is related to a non-persistent object (i.e., all
SS invocations or a BS service invocation that's NOT linked to an MO
service) and the element is either not specified or empty:
If the element also has an attribute of required="true" OR private="true":
Defaulting always occurs
Otherwise (the element has neither required="true" nor private="true"):

If the element is present but empty, defaulting will NOT occur (we assume the
blank value is what the caller intended to pass)
If the element is not present, defaulting will occur (we assume the element
should contain the default value if it wasn't present)
11 - 24
An Example
The activate element will default whenever this BS call is invoked because:
The BS is related to an MO service (i.e., it's a persistent object call)
The pageAction is "update"
The element has an attribute of private="true" (the framework will always add private elements to the XML
document and therefore the element will always be present and empty by the time the default logic kicks in)
Service
Program
This is an example of a business service

related to the SA Page Maintenance service
Notice the pageAction= in the schema node
Business
Service
ActivateSA BS Schema
<schema pageAction="update" >
<saId mapField="SA_ID" />
<activate mapField="ACTIVATE_SW" default="true" private="true" />
Using the combination of default= and private= is a

good way to "hard code" a value in an element
11 - 25
Another Example
The option element will default if it's not specified or empty whenever this BS call is invoked because:
The BS is not related to an MO service (i.e., it's a non-persistent object call)
The element has an attribute of required="true"
The endDate element will only default if it's not present in the schema because:
The BS is not related to an MO service (i.e., it's a non-persistent object call)
Because it's not required it must be possible for the caller to set it to blank
Service
Program
Business
Service
DateMath BS Schema
<option mapField="OPTION_FLG" required="true" default="DIFF" />
<beginDate mapField="BEGIN_DTTM" required="true"/ >
<endDate mapField="END_DTTM" default="%CurrentDate" />
...
11 - 26
Review Questions
11 - 27
11 - 28

11 Business Services

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

11 Business Services

Uploaded by

Copyright:

Available Formats

11

Copyright 2009, Oracle. All rights reserved.

Service scripts to perform functions that transcend MO's

In this section, we'll discuss how you can use a different

Copyright 2009, Oracle. All rights reserved.

Business Services Invoke Core Services

Copyright 2009, Oracle. All rights reserved.

Business Services Front-End Backend Services

A BOs schema maps the BOs

A service program that performs

A BSs schema maps the BSs

Copyright 2009, Oracle. All rights reserved.

Business Services Are Invoked From Scripts

And yes, Edit data steps can also

Copyright 2009, Oracle. All rights reserved.

Team Walk Through (30 minutes)

Copyright 2009, Oracle. All rights reserved.

Not All Backend Common Routines Have Services

Copyright 2009, Oracle. All rights reserved.

Common Routines Without Service Programs

You have two choices:

You can log an SR and have PD do it

Copyright 2009, Oracle. All rights reserved.

Anomalous Interactions With Anomalous MOs

Copyright 2009, Oracle. All rights reserved.

Not All MOs Can Be Maintained Via BO Interaction

To add, change or delete these MOs, you must set up a business

The system lets you know on the BO

Copyright 2009, Oracle. All rights reserved.

Note Well: All MOs Can Be Read Via BO Interaction

Efficiency Concerns it is MUCH more efficient to read an

Copyright 2009, Oracle. All rights reserved.

State Transition Changes Cannot Be Done Via BO

This is an example of a business service

These are two elements in the SA page service

Copyright 2009, Oracle. All rights reserved.

Copyright 2009, Oracle. All rights reserved.

Validating The Input Variables

Copyright 2009, Oracle. All rights reserved.

Team Walk Through (60 minutes)

Copyright 2009, Oracle. All rights reserved.

Warning! - Advanced Concepts Ahead

Copyright 2009, Oracle. All rights reserved.

Implementing Save Points

Copyright 2009, Oracle. All rights reserved.

A classic example is when you want to call scripts to perform

Copyright 2009, Oracle. All rights reserved.

How To Issue A Save Point Before Executing A Service

The name of the service script and the

Copyright 2009, Oracle. All rights reserved.

Summary of default= Behavior

Copyright 2009, Oracle. All rights reserved.

In other words, just because an element has a default= attribute

Copyright 2009, Oracle. All rights reserved.

Empty Nodes versus Not Present Nodes

If you were to look at the script's XML document

move '1232121211' to "IndividualTaxpayer/taxpayerId"

After the invokeBO statement, the remaining

Copyright 2009, Oracle. All rights reserved.

default= For Persistent Object Calls

Otherwise (the element has neither required="true" nor private="true")

Copyright 2009, Oracle. All rights reserved.

default= For Non-Persistent Object Calls

Otherwise (the element has neither required="true" nor private="true"):