This document discusses integrating order management and billing systems using WSO2 ESB and BPS. It outlines challenges such as complex billing strategies, pre-production billing, importing data from legacy systems, and handling orders from multiple sources. The proposed solution is to use WSO2 ESB to connect an on-premise .NET billing engine and a SaaS order management system. BPS would be used to address challenges through mediation logic and reusable processes. This "best of breed" approach aims to make billing more flexible, scalable and performant at a lower cost than custom coding.

1. Delivering the Goods?
Integrated Order Management
& Billing with BPS and ESB
by
Brad Svee
Sr. IT Development Manager

2. Growth = More Products, More Customers
and More Billing Runs
• Too many Lines of Custom PL/ SQL in Oracle EBS
to support complex billing and account structures
• Not sustainable, not scalable, not favorable, not
healthy
• Oracle Upgrades are harder with custom code
• Why upgrade all that custom stuff?
• What can we do to make billing more flexible,
scalable and performant?

3. First at Bat
Do it all in Oracle EBS
Estimated cost: 57 Galactic Credits
Sad Face Factor: 10/10

4. Now What?
Hire a consultant who knows these things
Write a bunch of academic type papers and
documents outlining the problems and goals
Start to evaluate vendors
Find a new Billing Engine and make them do it all

5. The State of the Billing Engines
• In the beginning, only giant telecom companies
needed big billing, aka gazillions of transactions a
minute rated across tons of kooky contracts
• Most established transactional billing engines are
very telecom oriented
• Starting from telecom means that order
management and quoting capabilities are weak or
missing in these systems
• SaaS companies need to bill too, right?

6. Goals of Billing Project
• Move away from Oracle EBS and tons of custom code
• Speed billing process up from weeks to days
• Consolidate invoicing
• Online bill presentment and payment
• Account Hierarchies
• Support complex partner account relationships
• Multi-currency invoicing
• Empower more complex pricing & product structures
• Sprinkle in Some Order Management…

7. Second at Bat
Nice new Billing Engine chosen
Missing Order Management and Catalog Rules
functionality OOB, but they will customize
Estimated cost: 27 Galactic Credits
Sad Face Factor: 6* / 10
*That’s a lot of dough to for an untested “custom” Order Management
Module and Price Catalog..

8. Basics of Quote & Order Management
• Sales people configure a set of products & prices
of items within those products
• Rules control what can be sold with what
(e.g. you can’t by 2 X-wings and only 1 R2)
• Permission levels allow more senior sales people
to give larger discounts
• Workflow approvals prevent bad deals from
sneaking through.

9. Goals of Order Management Project
• Structured product catalog & configuration rules available
within SFDC
• Empower hundreds of sales people to easily create quotes
online
• Automate orders and approval workflow
• Finalize SOF & Assets within SFDC
• Highly configurable: different rules & configuration for
different sales channels
• Eliminate Excel Spreadsheets
• Faster quoting & accurate Sales Order Forms

10. Choose Your Weapons
Billing System selection:
• On Premise
• .NET + SQL Server
• Small set of granular web services
Quote & Order System selection:
• SaaS + connectivity to SFDC
• Limited need to use web services
• Order is delivered via flat XML over HTTPS POST

11. So it’s a “Best of Breed” Approach?
Order Management + Billing = “The Goods”
Then we’d better pick something good to connect
the dots. Vendors both recommend “Cast Iron”…
• Recently acquired by IBM
• 1 yr prototype on previous project ended in fail
• Estimated cost to start: 3 Galactic Credits
• Sad Face Factor: 8 /10

12. Enter WSO2
• Already in heavy use within IT
• Began working with ESB and App Server in 2008, BPS
in late 2009.
• Project could be enabled with ESB, BPS, BAM
• Professional Services available
• Unique Approach (both BMI and MT very interested)

13. Third at Bat
Two Systems: Order Management and Billing Engine,
connected by WSO2 ESB and BPS
Estimated cost: 15 Galactic Credits
Sad Face Factor: 0/10

14. Guiding Principles of the Integrations Team
• Source the data (identify keys) as far up-stream as
possible to minimize round trips
• Eliminate complex rules within the billing engine by using
mediation logic on the output from Order system
• Use the BPS whenever possible to avoid writing custom
code or services in the billing engine
• Reusability of the BPEL
• Manual execution/recovery plans just in case
• Timing

15. Design

16. Integration
Layer
Close up

17. Challenges Addressed by WSO2
“Hidden Product Offerings”
Certain billing strategies required the creation of
special Product Offering entries in the billing
engine to create the back-end calculation.
However, these offering items are not something
that needs to be shown on the quote/order.
Solution: BPS sees Order XML with specific products
and automatically creates the hidden objects in
the billing engine

18. Challenges Addressed by WSO2
“Pre-Production Billing”
Certain products require extra time to implement,
and therefore are sold with a re-occurring pre-
production fee that is much lower than the actual
re-occurring fee that will be assessed when the
product is actually live in production.
Solution: BPS sees Order XML “Pre-Prod PO” and
sets all other charge types on the subscription to a
start day 3 years in the future.

19. Challenges Addressed by WSO2
“Pre-Production Billing Cont.”
When the Product is finally in “production mode”, a
date is set out in another system. A file is sent
containing the date, the customer entity and the
billing ID.
Solution: ESB grabs the file via VFS and looks up the
subscription, and sets the end date of the Pre-
Prod PO and recalculates the start dates of all the
other Products and Prices within the subscription,
thereby activating production billing.

20. Challenges Addressed by WSO2
“.NET Activity Service calls are costly”
The billing engine’s web services are doing a lot of
work and therefore are expected to be able to
handle only a small continuous flow of orders
unless we buy huge servers(already 12cpu 48GB).
Solution: ESB will use its message queue and
throttling capability to restrict the amount of
orders that are sent to the BPS to insert/update in
the billing engine.

21. Challenges Addressed by WSO2
“Importing Data from Legacy Systems”
The billing engine’s only avenue for loading data
(save paying for a custom loader) is through it’s
default web services.
Solution: The two tiered BPS model and our own
Order XML Schema allows us to extract legacy
data with simple PL-SQL creating our XML and we
place those messages into the second message
queue as if they were just new orders.

22. Challenges Addressed by WSO2
“Orders from Multiple Sources”
Orders are expected to come from Indirect resellers
as well as the OM system. Not to mention any
future acquisitions may have order entry systems
as well.
Solution: The two tiered BPS model and our own
Order XML Schema allows us to parse orders from
different sources, validate them, and queue a
standard XML message for the worker BPEL to be
loaded. Also allows common readability of orders
for manual error investigation.

23. Challenges Addressed by WSO2
“Oracle EBS 11i: No Customer Create Services”
Customer records need to exist in Oracle AR module
after they are loaded into Billing, however no
standard interface exists.
Solution: Develop a set of custom PL/SQL
procedures to create customer, bill-to, ship-to
and contact records in the DB. Wrapping these
procedures with WSO2 Data Services allows the
BPS to easily create the necessary records.

24. Challenges Addressed by WSO2
“Minimize the Number of Invoices Sent”
Billing engine uses Billing Account to determine that
an invoice should be created, but does not have a
service to search for existing billing accounts, only
a single expensive service that pulls the entire
dataset for a single customer.
Solution: The first leg of the order validation BPEL pulls
that full record once, searches through it for a matching
billing address on the order and validates other customer
attributes.

25. Challenges Addressed by WSO2
“SaaS OM System Posts Order over HTTPS”
The delivery mechanism for the final Order XML is a
single POST and forget with basic security and
reliability built in.
Solution: ESB Message Queue, and Security
Throttling to only accept post from that IP
address, and store the message in a queue
immediately and reliably.

26. Questions?