Chapter 90 Email in CCB

90
CC&B ONLY - Advanced Techniques
This chapter is only relevant for

CC&B implementations
Copyright © 2010, Oracle. All rights reserved.

Advanced Techniques
This section has two purposes:

• It describes several examples in the demo system;
understanding these examples will reinforce many of this
course's major concepts
• It describes several framework features that might prove
useful to an implementation
90 - 2 Copyright © 2010, Oracle. All rights reserved.

90 Portals and Zones

Advanced Zones
This section illustrates several portals and zones that exist in

the demo system
These portals and zones are all "CM-owned" so your
implementation can use the bundling functionality to import
them if so desired

Context Sensitive Sibling Zone
A context-sensitive dashboard zone appears when a user

displays a rate component
This zone shows all rate components under a rate version (i.e.,
it shows the sibling rate components):
• Users can easily see the big picture of a rate version's
components
• Users can easily navigate to other rate components
The user can click the Seq link to

display a different rate component

Click to print or download
Bill History Zone to Excel (all historical bills
Shows the most recent bills for the account in context (this is can be downloaded)
intended to be placed on Control Central or its equivalent)
Click to populate the Worklist with the bills
Click to expose other zones

Click to start a BPA
with more info about the
script to reprint a bill
broadcast bill …
Drag and drop other

fields into the list

Bill Segment Calc Lines Zone
This zone appears after a bill id has been
broadcast from the Billing History zone. It
shows the calc header(s) and lines for all
bill segments on the broadcast bill.
Click to navigate to the bill

segment page
Click to navigate to the rate

component used to
calculate the line
Drag and drop other

fields into the list

View Bill Zone
Shows a near bill image of the broadcast bill
The bill's bill segments are shown too

SA Billing History Portal
Select the Go To SA Billing History Portal on

the SA context menu to open this portal; its
zones are sophisticated
Click the zone's help text to This zone shows monthly usage by year and indicates if
see everything it can highlight usage has been estimated, overridden by a user, or was
derived from multiple bill segments (note, you can broadcast
a UOM / TOU / SQI from the above zone to see a different
service quantity's monthly consumption)
This zone shows monthly bill segment monetary amounts by

year and indicates if the monetary amounts come from
multiple bill segments. It also highlights when current
amount differs from payoff amount.
Click to see the details of a given year…

SA Billing History Portal (cont.)
This zone shows all service quantities for every bill segment
in the year along with start readings, end readings and
average daily consumption

SP Consumption Summary Portal
Select the Go To SP Consumption Summary Portal
on the SP context menu to open this portal
This zone shows a SP's meter reads and

the resultant billed consumption

Tender Control Portal
Select the Tender Control Portal on the
Main - Financial menu to open this portal
This zone is used to find tender controls

(tender controls are used to audit and
balance new payments)
Broadcasting causes other zones to

appear to help the user balance the tender
control…

Tender Control Portal - Additional Zones
This zone shows a summary of the This zone shows the user the types of
tenders in the tender control cash and coins that we remitted so
they can balance their deposit

Tender Control Portal - Additional Zones (cont.)
This zone shows the individual

payments in the tender control
This zone shows the details of a

specific payment that has been
broadcast from the above zone

90
Multiple Levels Of Admin MO's

Parent / Child MO's
Some designs create parent and child MO's for what may have historically
been a single MO
A good example is from the Conservation Program design where there are
two MO's that both hold admin data about a conservation program
The next few slides describe when this is done…
A conservation program can have many rebate
The "parent" MO holds general information definition MO's (where the rebate definition defines the
about a conservation program (e.g., amount of money the consumer receives for
effective dates) purchasing energy efficient commodities (e.g., it might
have one to define the rebate for a washer and
another one for an air conditioner)
Conservation Program
Rebate Definition
Conser- Language
vation Rebate
Program Language
clob Definition
clob
Char

Why Multiple Levels Of MO's?
- Avoiding 3-Level Hierarchies -
Each rebate definition has a list of the
Conser-
manufacturers and models that qualify for a vation
rebate Program
This would result in a 3-level hierarchy if it was
in a single MO (Conservation Program -
Rebate Definition - Manufacturer/Model)
Rebate
• 3 level hierarchies are definitely possible
Definition
in BO schemas, however, they are harder clob
for users (and programmers) to maintain;
so the tables were split into 2 simple
Manuf /
MO's
Model

Why Multiple Levels Of MO's?
- Independent Lifecycles -
Another reason to have two MO's is when the children have
their own lifecycle independent from the parent
In our example, a rebate definition could be inactivated on an
active conservation program
Conservation Program Rebate Definition
Pending Active Active
Inactive Inactive

90
Uploading Data From CSV Files

Case Study
Every rebate definition on a conservation program has a list of the

manufacturers and models that qualify for the rebate
• Note, this means that the rebate definition BO has a list element
The UI map can include a button that can populate a list from the rows
in a spreadsheet

The Spreadsheet
The first row of the spreadsheet must contain values that match
the list node's element names
The successive rows contain the list's members
The user should save the spreadsheet as a CSV file on the
local machine and then upload the CSV file
Notice the first row (these are the element

names in the manufacturerModel list in the
map's XML document)
Uploading this spreadsheet will result in 3
entries in the manufacturer/model list

The UI Map
On the UI map that's used to maintain the manufacturer / model

list, add a button with the oraUploadData function associated
with it, notice the following values:
• path: is the name of the list in the BO / service script XML
document that will be populated with rows from the CSV file
<body>
<input class="oraButton"
oraMdLabel="C1_UPLOAD_XSL_LBL"
type="button"
oraUploadData="type:popup;path:rebateDefinition/rebateDefinitionInfo/manufacturerModel" />
</body>
If the user clicks on this button,

this pop-up appears where the
user finds the CSV file
When the user presses Submit, the list

elements are populated with the CSV rows

The User Must Save
At this point, we have a list node in an XML document

populated with a list of manufacturers and models
When the user saves the rebate definition BO, the list will be
saved along with the rest of the BO
Notice that the user can

subsequently add, change,
delete entries without
using the spreadsheet

Another Upload Overwrites The List
If the user clicks Upload spreadsheet a second time, the

contents of the list will be overwritten (rather than appended)
with the contents of the spreadsheet

90
Real Time Web Service Calls

Case Study
When a tender is made by credit card, a real-time call should

be made to a credit card authorization provider (in this case,
CyberSource)
• In addition, all details of the call must be saved in the
system
When a tender is cancelled that was previously authorized, a
real-time call should be made to reverse the previously
authorized charge

XAI Overview
This isn't an XAI course, but here's what you need to know to
understand the solution
XAI stands for XML Application Interface and is part of our
framework
It is used to:
• Interface data to other applications in an enterprise
• Interface data to and from third party partners (e.g.
deregulated market, credit card authorization partners, …)
In our case study, we're going to use its ability to send
messages real-time to an external system
• It can send and receive messages in many other ways
besides real time

Step 1: Set Up an XAI Sender
An XAI sender is meta-data that controls how an outbound message is sent; think of it
as the Java class that does the web service call
In our case study, we've set up an XAI sender for CyberSource as follows:
• It will have an Invocation Type of Real Time
• It will have an XAI Class of Real Time Sender Via HTTP
• It will have a Context entries similar to the sample below…
Invocation
XAI Sender XAI Class
Type
Context

Step 2: Set Up Outbound Message Types & BO's
An outbound message type is meta-data that defines the structure of a given type of
outbound message
Notice that it references a business object:
• For the authorization message type, this BO defines how the authorization XML
document looks
• For the reversal message type, this BO defines how the reversal XML document
looks
A Snippet Of An Outbound Message Schema To Do Credit Card Auth.
Business
...
Object <requestMessage>
<merchantID dataType="string"/>
<merchantReferenceCode dataType="string"/>
<card type="group">
<accountNumber dataType="string" mdField="CREDIT_CARD_NBR"/>
Outbound <expirationMonth dataType="string"/>
Message <expirationYear dataType="string"/>
<cardType dataType="string"/>
Type </card>
</requestMessage>
<responseMessage>
...

Step 3: Set Up An External System
Define CyberSource as an external system that can receive messages
On it you define:
• Each outbound message type (e.g., the authorization and reversal message
types)
• How each message type is sent (e.g., by defining the CyberSource XAI sender)
External
System
This also references two XSL's that

massage the request and response
Valid sections of the outbound message
Message (depending on the receiver, these might
be tricky)
Outbound
Message XAI Sender
Type

Step 4: Create The Outbound Message In An
Algorithm
Configure the system to create an authorization outbound message BO when
a "credit card" tender is created and a reversal outbound message when it's
canceled
Note, a new plug-in spot was added to the base-package to do this (so
different customers can do this differently if they want)
Business
Tender Type
Object
Tender
BO /
The base-package algorithm
Valid Values: Algorithm type handles the creation of
• Validation the outbound messages for
• Pre-processing both authorization and
• Post-processing reversal
• Audit
• Information
System Event
• Tender Authorization

Step 5: Set Up "Audit" Char Types
Tender
Tender / Char
The base-package
algorithm types keeps
a tender's outbound
message(s) as FK
chars on the tender; it
also keeps the
authorization code
returned form the credit
card company here

90
To Do Entries That Create Email

Case Study
Users who approve rebate claims want to receive email

messages in addition to To Do Entries
Clicking the hyperlink navigates to

the system with the claim displayed,
ready for approval

To Do Overview
Batch
Note, these are just the basics Process
as this is not a To Do course
A To Do entry is created
whenever a user needs to do
something to an object To Do Role To Do Type
Every entry has a:
• To Do Type – this controls To Do
how the entry looks Entry
Role /
• Role – this defines the User
user(s) who can work on
the entry
To Do Entries can be routed out
of the system by populating an User
external routing batch process on
the To Do type

Step 1: Set Up an XAI Sender
You recently saw an XAI sender that did a real-time web service call in this example,
we need an XAI sender to post an email message via an SMTP host
In our case study, we've set up an XAI sender called emailSender as follows:
• Invocation Type of MPL (rather than real time)
– This means that the email will not be created when the outbound message is created;
rather, the multi-purpose listener (MPL) will create the email when it next runs
• XAI Class of Post Messages To Email
• Context entry similar to the sample below…
Invocation
XAI Sender XAI Class
Type
Context

Step 2: Set Up An Outbound Message Type & BO
An outbound message type is meta-data that defines the structure of a given
type of outbound message
A Snippet Of An Outbound Message Schema Create For An Email Message
...
<emailDocument type="group" mapXML="XML_SOURCE">
Business <from type="group">
<internetAddress type="group">
Object <address mdField="EMAILID"/>
...
</internetAddress>
</from>
<to type="list">
Outbound <internetAddress type="group">
Message <address mdField="EMAILID" isPrimeKey="true"/>
...
Type </internetAddress>
</to>
<subject type="group">
<text mdField="DESCR500"/>
<charset mdField="CHAR_TYPE"/>
</subject>
<messageText type="group">
<text mdField="DESCRLONG"/>
<charset mdField="CHAR_TYPE"/>
<contentType mdField="CHAR_TYPE"/>
</messageText>
...

Step 3: Set Up An External System
Define Email as being an external system that can receive messages
On it you define:
• The outbound message type
• The XAI sender
External
System
No XSL transformation of the

Valid outbound message XML is
Message necessary 
Outbound
Message XAI Sender
Type

Step 4: Create The Outbound Message In An
Algorithm
Configure the system to create an email outbound message BO when
a To Do entry is ready for routing
This is done by plugging in an external routing algorithm on the
appropriate To Do Types
The base-package algorithm To Do Type

type creates an outbound
message using two
parameters (the outbound
message type and the To Do Entry
external system) To Do Type /
Algorithm
If the To Do entry is open, it
sends it to every user in the Valid Values:
role. If the To Do entry is • Info
being worked, it sends it to System Event •…
the assigned user. • External Routing

Step 5: Define The Routing Process On The To Do
Type
Define the base-package external routing batch job on the To Do type
This batch process simply invokes the To Do type's external routing algorithm
(and this algorithm creates the outbound message that MPL subsequently
sends to the SMTP gateway)
Batch
To Do Type
Process
To Do Entry
To Do Type /
Algorithm
Valid Values:
• Info
System Event •…
• External Routing

Re-extract
Note - like all base-package extracts, you can submit the batch
process with an historic run number and it will re-create the
outbound messages (i.e., resend the email)
Batch
To Do Type
Process
Batch / Run To Do Entry

90 Sample and Submit

Case Study
On an ad hoc basis, users want to be able to see a sampling of

accounts / premises / SA's / … that meet specific criteria (e.g.,
show a sampling of accounts with credit cards due to expire in
the next x days)
After seeing the sample is correct, they want to submit a batch
request that performs some type of action against the entire set
of objects that meet their criteria (e.g., send a letter / email to all
such accounts)
Note, the "e.g.'s" above are just that; the notion is that the
implementation team wants to be able to easily introduce new
sampling criteria and batch jobs without the need for a huge
programming effort (we've seen the same requirement in ETM
and CCB)

Use Case – Identify The Batch Job
First, the user identifies the type of activity they want to do

Use Case – Enter The Criteria
Next, the user is presented with a UI map on which they enter:

• Sampling criteria (these are the element in a where clause)
• Values needed by the activity type
Sampling criteria - Select all

accounts with credit cards due
to expire in 30 days
Values for the batch job - Create this

type of customer contact for all such
accounts
Submit the batch request without See a sampling of such accounts

sampling

Use Case – See The Sample
This is the count of ALL objects that
meet their criteria
Next, if the user clicks
Preview, they'll see a small
sample of the objects that
meet their sampling criteria
Clicking Save will create a request to perform the

activity for the entire population of customers; this
request will be executed by a batch process (doing
the request real-time could result in lengthy
response times and degraded performance for all)

Use Case – Monitor The Request
After the request is saved, users can monitor it (or cancel it)
When the batch job runs, this will

become Complete after the
customer contacts are created

Step 1: The Activity Type Admin Object
An activity type BO is created for each type of ad hoc request; this holds the
types of parameters that are entered by a user for this type of activity
An activity type instance is created for each type of request, it defines the
default parameter values
Business
Activity Type
Object
clob
The activity type's default parameter values

BO / Option are held in the CLOB
Valid Values:
• Pre-script The standard BO option that holds the Related
• Post-script Option Type transaction BO references the batch request BO
• Related transaction BO that will be created for this type of activity when a
•… user submits a request (see next slide)

Step 2: The Activity Request Transaction Object
An activity request BO is created for each type of ad hoc request; instances of
this BO are created when a user saves and activity request
• Each instance holds the parameter values associated with the request
This BO has options (see below) that drive the request dialog
Business Activity
Object Request
clob
Obviously, the parameters

Valid Values:
BO / Option and values are held in the
• Pre-script CLOB as we'd never create
• Post-script "real columns" for something
•… so idiosyncratic
• Service script that The submit request dialog
returns the preview list Option Type uses the options to drive the
• UI map that displays "preview" dialog
the preview list

Activity Request Lifecycle
Activity Request
The pending state has a monitor plug-in and the
standard monitor batch job that transitions it to the
default next state (Complete). This means that the Pending Canceled
request will only transition to complete when the
monitoring batch process is scheduled to execute (not
when the user submits the request)
The complete state has an enter plug-in job that

selects the objects that match the request's criteria
and then performs the actions against the result set Complete
(in this example, it creates the customer contacts of
the desired type)

3 Info Zones Are Created
The first info zone does the count (you saw this on the sampling
results map)
The second does the preview (this has a ROWNUM in the WHERE
clause to limit the results)
The third does the selection of all (this is invoked by the enter plug-in
when the request transitions to Complete)
Each info zone is wrapped by a business service so it can be invoked
by the various scripts
• The 'count' and 'preview' business services are invoked by the
service script the returns the preview list
• The 'all' business service is invoked by the enter plug-in on the
activity request's complete state to return all accounts matching
the criteria

90 Encryption

Encryption and Masking Requirements
Implementations need to be able to encrypt certain elements on the

database and mask all or part of these elements on the UI. For
example
• Social security numbers should be encrypted on the database and only
the last 4 digits should be shown on the UI if the user does not have
appropriate access rights
• Bank account and credit card numbers have similar requirements
Implementations can identify the following things to be encrypted /
masked:
• Columns that hold dedicated values (e.g., a customer's bank account
number on their auto-pay record)
• Characteristics (these could be on any object that has characteristics)
• Specific rows of abstract collections (e.g., the row on CI_PER_ID where
ID_TYPE_CD = "SSN")
• Elements in BO's (flattened, real and those residing in a CLOB)

Database Encryption
Database encryption is only supported for Oracle database

customers as we use the standard Oracle encryption facilities
• Please see the Oracle encryption manual for the details
Bottom line:
• The user ID that is associated with the user's database
access must have access rights to retrieve unencrypted
data
• If they can retrieve the data, then it's subject to UI masking
• If they can't retrieve the data, then it's encrypted and
masking isn't relevant

A Masking Sample
Notice how driver's license is not encrypted but social

security number is (and only the last 4 digits are
shown)

More Samples
Before explaining how this is accomplished, we must
explain the base-package field level security meta-data
as it's used to control who sees information unmasked
and how it's masked for users who can only see
masked information…
A field in a scroll
An element in a
BO displayed on
a UI map In an editable grid

Field Level Security Overview
Every masked field has an application service associated with it
Every such application service will have a security type with 2 authorization levels:
• Mask
• Don't mask
A user group should be linked to the don't mask authorization level if its users can see
the field value unmasked
Application
Security Type User Group User
Service
App Service / User Group / User Group /

Security Type App Svc User (Edate)
UG /
Authorization
AppSvc / Sec
Level
Type / Author
Level
How To Mask: Step 1 - Identify The Fields
Identify the fields you need to mask, in this list you include:
• Elements on BO / BS / service script schemas
– Note, these fields MUST reference an mdField= or a mapField=
attribute
• Characteristic values that appear in char grids
• Fields that appear on traditional pages
– For example, email address on CI_PER
• Fields that appear on traditional pages in grids, for
example:
– The value in ID_NBR in the CI_PER_ID table in rows where
ID_TYPE_CD = "SSN"
– The value in the ADHOC_CHAR_VALUE in rows where
CHAR_TYPE_CD = "BANKACCT"
• Fields that appear in historical search results

How To Mask: Step 2 – Identify The Masking
Algorithm
Set up an algorithm for each type of masking
The base-package algorithm type (F1-MASK)
allows you to define:
• The character used to mask (e.g., "*")
• How many characters should remain
unmasked at the end (e.g., 4)
• Special characters that shouldn't be masked
(e.g., "-")
• The application service to which user groups
will be granted access for masking purposes
for fields related to this application service
• The security type on the application service
that defines the authorization levels for
masking purposes
• The authorization level on the security type that
indicates a user can see unmasked data
You'd need to set up one of these algorithms for
every logical field with different masking
requirements or access rights

How To Mask: Step 3 – Populate A Feature
You can now create / update a feature configuration where

Feature Type = Data Masking
On this feature configuration, you create a separate entry for
every field in your masking list, the entry will identify:
• What is being masked
– You'd enter a field name for fields in a schema
– You'd enter a char type for fields in characteristics
– You'd enter a table and field for fields on traditional pages that
aren't in grids
– You'd enter a table, field and, optionally, a where condition for fields
in grids on traditional pages
– You'd enter a search service name, field and, optionally, a where
condition for fields in traditional search results
• The algorithm to perform the masking

An Example of A Feature For Masking

How To Mask: Step 4 – Link Your User Group(s)
To The Application Service On The Algorithm
Link the appropriate user group(s) to your application service
Clear the cache (flushAll.jsp)
Data will now be masked

Masking Addendum
On data input pages, a user might be able to change a user's social

security number but not be able to subsequently see it
Some XAI requests require masking and some don’t, for example:
• A request from a CRM system to synch Person Info needs the SSN
unmasked
– Its request User is configured with security to see SSN unmasked
• A request from WSS to display Person Info needs the SSN masked
– Its request User is configured with security to see SSN masked
Masked fields that reside in CLOBs will be masked if the user looks at
a CLOB using our UI (there are ways to display the raw CLOB)
Internal BO / BS / Service Script calls have access to unmasked data
as they need it to create transaction / web service information
• How could you perform a web service call to check a customer's credit
score if the internal service couldn't get at the customer's social security
number unmasked? Keep in mind, the same user that needs to see the
credit score cannot see the social security number!

90
Converting BO's From Legacy Applications

Converting Legacy BO's
Many implementations have data in a legacy application that

they must convert into our products to "go live"
This legacy data needs to be converted into BO instances
• The conversion of this into XML prior to conversion is the
implementation team's responsibility
Each BO instance could be in any of its valid states (from initial
to final)
The problems:
• How to add a BO in a state other than the initial state
(remember, when you add a BO, the framework puts it into
the BO's initial state)?
• If you solve the first problem, how do you prevent the
framework from executing the enter algorithms on
whatever state it resides in at conversion time?

Refresher: BO Rules Invoked From The MO Layer
Pre-processing rules are triggered from the BO layer only
Other rules are triggered from the MO layer
• Whether called via a business object or directly
Therefore, the MO needs to determine the processed instance’s BO
before executing its rules
We'd like to repeat – if the MO
BO ke
vo
associated with the BO does

In
Individual Taxpayer not have a Determine BO plug-

in, no BO-oriented plug-ins will
1. Pre-processing rules Enter Exit be executed (this is because
the MO invokes these plug-ins)
M oke
6. Audit rules
v
O
Person MO
In
(Service) 5. Post-processing rules
4. Validation rules
2. MO Processing
3. Determine BO

Step 1: Load Unvalidated BO's
The easiest way to turn off BO processing is to have the MO's
Determine BO plug-in return "no BO"
• This is not considered to be an error, it just means that no BO
processing will take place
So, how do we get this plug-in to do this during conversion?
• The easiest way is to put a "mode" flag somewhere in the admin
data
• In the case of market messaging, we have a perfect place to put
the mode (there's a master configuration admin object that's
meant to hold stuff like this)
• With this in place, the MO's Determine BO plug-in simply reads
the master configuration BO and, if the conversion mode is set to
true, it returns "no BO"
• This means that the add BO will add whatever has been passed
in the BO's schema (in whatever state)

Step 2: Mark The Object As Being Unvalidated
Some conversions allow unvalidated data to go into production, some
don't
If you want to have a batch job subsequently validate converted data,
you should mark the converted records as being unvalidated
To do this, set up the BO's Pre-processing plug-in to read the master
configuration BO and, if in conversion mode, populate an element on
the BO's schema to indicate it's unvalidated (this is what pre-
processing plug-ins are designed to do)

Refresher: The Save Point Dispatcher
The base-package is supplied with a business service called

F1-SavePointDispatcher
You tell this business service the name of a service script and
the value of the script's schema (this XML document is held in a
"raw" element)
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)

Step 3: Validate Converted Data In Batch
Write a simple batch job that reads unvalidated BO's
For each, it invokes the F1-SavePointDispatcher to invoke a service
script that looks as follows:
• Schema:
– BO name
– BO's prime-key
• Steps
– Dynamically declare a data area for the BO name passed in
– Read the BO
– Reset the unvalidated indicator
– Update the BO (note, we're hoping to release an Invoke BO with an
action of Validate, but until then …)
—
Remember, if there are validation errors, the change will "roll back to the
save point" and the script will stop and the error will be returned by the
framework to the batch program
If the dispatcher returns an error, write it to the BO's log

90
Generating Performance Testing Data

Case Study
The QA team needs to periodically run performance tests to

ensure that the batch framework is behaving as intended
In CC&B, this performance test is performed using the BILLING
batch process
• The BILLING batch process requires multiple accounts
where each account must have a metered service
agreement that is ready to bill
• Creating such accounts and meters by hand would be very
time-consuming
• The Configuration Tools have been used to create utilities
that performance testers execute to create a suite of
accounts for a performance test …

Generating Accounts
– The Real-time Method
Execute the Data Replicator - Create

Records BPA script to define template
information about the persons, accounts,
premises and meters to be propagated
When you press OK, the BPA script invokes a

service script …

Generating Accounts
– The Real-Time Method
The invoked service script creates the
designated number of accounts (and
premises, persons, meters, …). Control is
returned to the browser after all of the
accounts are created.
DB
Service Person
Script
Account Premise Meter
Meter
SA SP
This technique is fine to generate a limited Config
number of accounts. However; it should not be
used to generate > 50 accounts as a single SP / Mtr
SA / SP Register
commit is issued for the entire transaction. Config
Instead, the batch method should be used …
…

An Aside: The Fact MO
The system is shipped with a generic MO that your implementation can use to
hold idiosyncratic business objects; we call this the fact MO (the name is
purposefully generic as it can be used to hold a variety of BO's)
The fact MO will never be used for base-package owned functionality; this MO
is intended as a "stop gap" data store for implementations
With this in mind, we'll describe how the fact MO plays a part in the
generation of accounts in batch
It's wise to NOT overuse the fact MO; it
should only be used to hold BO's with a
Business Fact MO limited number of instances. If your
implementation has a BO with many
Object potential instances, you should consider
creating a new specific MO rather than
Fact use the generic Fact MO.
Status
Log Fact / Char Char Type

Generating Accounts
– The Batch Method
Execute the Data Replicator - Create Facts BPA

script to define template information about the
persons, accounts, premises and meters to be
propagated (notice the additional fields that are
defined for the batch method)
When OK is clicked, the invoked service script does

NOT create the accounts real time. Rather, it simply
creates x DR_CreateRecords BO's (and these BO's
reside in the fact MO). Each BO will eventually
create multiple accounts when a batch process
runs…
Service DB
Script Fact

Generating Accounts
– The Batch Method (continued)
This BO's Pending state has a monitor algorithm

DR_CreateRecords Lifecycle that transitions it into the Complete state. It also
has a deferred monitor batch process so that the
Pending BO will remain in the Pending state until the
batch process runs.
Created When the batch process runs, the BO transition

to the Created state. The complete state has an
enter algorithm that creates X accounts (where X
was defined during the BPA script).
Remember the following about deferred monitor batch processes:

- They can commit after each BO
- They can be run multi-threaded
This means that if you needed to create 50,000 accounts, you could use
the BPA script to create 500 DR_CreateRecords where each creates 100
accounts in batch

90
Implementing Intermittent Commits

Commits
By default, a single commit is issued for all updates issued during

a service call
This is exactly what is needed in most situations
However, you've just seen a situation when it might be better to
issue intermittent commits during a service call (e.g., it would
probably be better for the DR_CreateRecords BO to issue a
commit after every account is created so as not to fill up the
database's rollback queues)
There is a way to do this…

How To Issue Commits
The base-package is supplied with a business service called F1-ExecuteScriptInNewSession

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:
• Starts a new database session before it starts the script
• It then executes the script
• If there are errors, it rolls back to the start of session and returns the error message
number to the caller and it can do with it what it needs to (note, this BS has another
parameter that you can use to have it roll back both the new session's changes AND
the calling session's changes if there are errors)
// populate the service script's parameters

move "personId" to "C1-RequestLetterDataArea/input/personId";
move 'CC' to "C1-RequestLetterDataArea/input/customerContactClass"; The name of the service script and the
move 'REMINDER' to "C1-RequestLetterDataArea/input/customerContactType"; script's data area are passed to the
// populate the script name and its data area in the new DB session's parameters F1-ExecuteScriptInNewSession
move "C1-RequestLetterDataArea" to " F1-ExecuteScriptInNewSession /scriptData";
business service in its data area
move 'C1-ReqLetter' to " F1-ExecuteScriptInNewSession/scriptName";
// add the contact and execute a commit
invokeBS 'F1-ExecuteScriptInNewSession' using "F1-ExecuteScriptInNewSession";

Must Consider Restart Logic
Whenever you issue intermittent commits, you must design the

appropriate restart logic
To illustrate, we'll continue with the account generator example:
DR_CreateRecords Lifecycle The complete state's enter plug-in should check if

the account to be generated already exists. For
Pending example, check if there's already an account with the
respective person name. If no account exists, invoke
the F1-ExecuteScriptInNewSession and let it create
the account (and premise, person, SP, meter, …)
Created

Chapter 90 Email in CCB

Uploaded by

Document Information

Original Title

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

Chapter 90 Email in CCB

Uploaded by

Copyright:

Available Formats

90

CC&B ONLY - Advanced Techniques

This chapter is only relevant for

Copyright © 2010, Oracle. All rights reserved.

This section has two purposes:

90 - 2 Copyright © 2010, Oracle. All rights reserved.

Copyright © 2010, Oracle. All rights reserved.

This section illustrates several portals and zones that exist in

90 - 4 Copyright © 2010, Oracle. All rights reserved.

A context-sensitive dashboard zone appears when a user

The user can click the Seq link to

90 - 5 Copyright © 2010, Oracle. All rights reserved.

Click to populate the Worklist with the bills

Click to expose other zones

Drag and drop other

90 - 6 Copyright © 2010, Oracle. All rights reserved.

Click to navigate to the bill

Click to navigate to the rate

Drag and drop other

90 - 7 Copyright © 2010, Oracle. All rights reserved.

The bill's bill segments are shown too

90 - 8 Copyright © 2010, Oracle. All rights reserved.

Select the Go To SA Billing History Portal on

This zone shows monthly bill segment monetary amounts by

Click to see the details of a given year…

90 - 9 Copyright © 2010, Oracle. All rights reserved.

90 - 10 Copyright © 2010, Oracle. All rights reserved.

This zone shows a SP's meter reads and

90 - 11 Copyright © 2010, Oracle. All rights reserved.

This zone is used to find tender controls

Broadcasting causes other zones to

90 - 12 Copyright © 2010, Oracle. All rights reserved.

90 - 13 Copyright © 2010, Oracle. All rights reserved.

This zone shows the individual

This zone shows the details of a

90 - 14 Copyright © 2010, Oracle. All rights reserved.

Copyright © 2010, Oracle. All rights reserved.

90 - 16 Copyright © 2010, Oracle. All rights reserved.

90 - 17 Copyright © 2010, Oracle. All rights reserved.

Conservation Program Rebate Definition

Pending Active Active

90 - 18 Copyright © 2010, Oracle. All rights reserved.

Copyright © 2010, Oracle. All rights reserved.

Every rebate definition on a conservation program has a list of the

90 - 20 Copyright © 2010, Oracle. All rights reserved.

Notice the first row (these are the element

90 - 21 Copyright © 2010, Oracle. All rights reserved.

On the UI map that's used to maintain the manufacturer / model

If the user clicks on this button,

When the user presses Submit, the list

90 - 22 Copyright © 2010, Oracle. All rights reserved.

At this point, we have a list node in an XML document

Notice that the user can

90 - 23 Copyright © 2010, Oracle. All rights reserved.

If the user clicks Upload spreadsheet a second time, the

90 - 24 Copyright © 2010, Oracle. All rights reserved.

Copyright © 2010, Oracle. All rights reserved.

When a tender is made by credit card, a real-time call should

90 - 26 Copyright © 2010, Oracle. All rights reserved.

90 - 27 Copyright © 2010, Oracle. All rights reserved.

90 - 28 Copyright © 2010, Oracle. All rights reserved.

90 - 29 Copyright © 2010, Oracle. All rights reserved.

This also references two XSL's that