Managing Integration with eBusiness Suite using Oracle
Company: Hewlett Packard
Integrating third party systems to Oracle’s eBusiness suite has traditionally been
done using cumbersome methods such as PL/SQL and UNIX scripts. These
methods are very inflexible and the resulting interfaces become inflexible point-
to-point solutions that generally require technical expertise to customise in the
event of an upgrade.
By using Oracle BPEL not only can you integrate any 2 applications regardless of
their underlying technology, you can implement complex business rules to help
validate the integration process. Oracle BPEL is designed based on Service
Oriented Architecture (SOA) principles, allowing organisations to move away
from tightly coupled inflexible interfaces to loosely coupled, flexible interfaces.
The benefit of using SOA architecture comes when changes occur in the IT
infrastructure. By adopting SOA methods and principles organisations can
reduce the impact on existing interfaces when upgrading or replacing systems
therefore reducing integration costs.
This study describes how flexible Oracle BPEL can be when integrating third
party products to eBusiness Suite. It will introduce some concepts that will help
you design a flexible architecture to minimise integration costs during new
implementations, upgrades, or acquisitions.
Service Oriented Architecture:
The new buzz around Oracle software at the moment is Oracle Fusion. To many
people it means different things. Some people think it’s just Middleware, some
think it’s the merging of the ERP products eBusiness Suite, PeopleSoft, and JD
Edwards, and some people are just confused. This paper is not going to define
Oracle Fusion but it is important that some key definitions are explained to
understand the rest of the paper.
Middleware is a general term for any programmatic layer that serves to "glue
together" or mediate between two separate and often already existing programs.
A common application of middleware is to allow programs written to access a
particular database to also access other databases. Oracle BPEL is a product
within the Oracle Fusion Middleware product suite that helps organisations to
achieve this goal.
Oracle BPEL has a number of underlying components that make up the
application, but the key to implementing BPEL is SOA. Although it is not
necessary to use SOA principles, the more SOA compliant your application is the
more flexible, and reusable it well be. To understand what SOA is you need to
understand what a service is. Think of a service as a mini application. This
service is self contained and is not dependent on another service. Services are
published by an application to expose some of its functionality. Other applications
can then subscribe to this service without having to understand the applications
SOA is the underlying structure supporting communications between different
services. A simple way to think about SOA is as a collection of services
communicating with one another to make one large application. A good example
is Amazon.com. You look at their catalogue and choose a number of items. You
specify your order through one service, which communicates with an inventory
service to find out if the items you've requested are available in the sizes and
colours that you want. Your order and shipping details are submitted to another
service which calculates your total, tells you when your order should arrive and
furnishes a tracking number that, through another service, will allow you to keep
track of your order's status and location en route to your door. The entire process,
from the initial order to its delivery, is managed by communications between the
The reality in IT enterprises is that infrastructure is heterogeneous across
operating systems, applications, system software, and application infrastructure.
Organisations rely on existing applications to run current business processes, so
starting from scratch to build new infrastructure isn't an option. IT enterprises
need to quickly respond to business changes with agility by leveraging existing
investments in applications and application infrastructure in order to address new
business requirements; support new channels of interactions with customers,
partners, and suppliers; and feature an architecture that supports organic
business. SOA with its loosely coupled nature allows enterprises to plug in new
services or upgrade existing services in a granular fashion to address these
issues. By providing an option to make the services consumable across different
channels, and the ability to expose existing enterprise and legacy applications as
services, SOA is able to safeguard existing IT infrastructure investments.
BPEL is an acronym for Business Process Execution Language. It is a
convergence of language features from IBM’s Web Service Flow Language
(WSFL) and Microsoft’s XLANG. It was jointly developed by IBM, BEA, SAP,
Siebel, and Microsoft in August 2002. In 2003 it was submitted to OASIS
(Organisation for the Advancement of Structured Information Standards) to
obtain even broader industry acceptance and open standardization. Although
Oracle BPEL is an Oracle product the underlying technology is standards based
therefore integration to third party applications becomes simpler and more robust.
Oracle BPEL is a tool that enforces SOA principles. A BPEL process is made up
of a number of loosely coupled services to make up a larger application. It is
quite common to see a BPEL process made up of a number of smaller BPEL
Oracle BPEL is part of the wider Oracle SOA Suite which consists of the
Integrated Services Environment:
Oracle JDeveloper is an integrated development environment for building
service oriented applications using the latest industry standards for Java,
XML, Web Services, and SQL. Oracle JDeveloper supports the complete
development life cycle with integrated features for modeling, coding,
debugging, testing, profiling, tuning, and deploying applications.
BPEL Process Manager:
Oracle BPEL Process Manager includes a user-friendly Web-based
Console for management, administration, and debugging of deployed
processes. Instance-level Audit trails, process history, and process
analysis/reports are available through the Console.
Oracle Enterprise Service Bus:
Oracle ESB provides connectivity leveraging Oracle Adapters, which
provide standards based access to virtually any data source. Oracle ESB
fully supports data transformation and document enrichment using XSLT
or XQuery transformation, Business Rules, Systems Cross References,
and Domain Value Mapping. Oracle ESB supports content based routing
and content filtering. Oracle ESB features a multi-protocol messaging bus
including support for JMS, SOAP, JCA, WSIF, JDBC, HTTP, and FTP.
The message bus provides configurable JMS qualities of service with
different types of persistence stores including Database, File, and In-
Oracle Business Rules:
Oracle Business Rules enables business analysts to easily define, update,
and manage key decisions and policies governing business processes
and applications, e.g. business policies within business processes that are
likely to change can be captured using business rules. This reduces the
need for developer intervention.
Business Activity Monitoring:
Oracle Business Activity Monitoring (BAM) is a complete solution for
building real-time operational dashboards to monitor business processes
and services, services levels, and track key performance indicators (KPIs)
from processes and services, with capabilities to take automatic or
manually invoked corrective actions.
Oracle Web Services:
Oracle Web Services Manager (OWSM) is a comprehensive solution for
securing and managing Service Oriented Architectures It enables security
and identity management policies to be defined centrally but enforced
When talking about enterprise application integration (EAI) with IT organizations,
we often heard a significant amount of dissatisfaction with traditional, proprietary,
integration-broker technologies as well as point-to-point integrations. Many
companies had trouble maintaining their integrations and grossly underestimated
the time, money, and consulting help that would be required. They need a better
way of integrating applications, a way that will allow their internal, non-expert, IT
resources to maintain and evolve existing integrations rapidly and cost-effectively.
Using standards-based integration, you now have the tools to create easy-to-
Using Oracle BPEL Process Manager Console, key business users are able to
administer and maintain BPEL processes with little to no knowledge of J2EE
principles. The console provides an intuitive interface that makes it easy for
business users to interrogate, diagnose, and debug BPEL processes. Due to the
simplicity of this tool the training requirements are minimal. Business users could
gain a basic understanding of the BPEL principles after a 2 day training course
and be competent enough to mange the BPEL environment unassisted.
Point to Point Integration Traditional EAI SOA Based Integration
Process hard coded Proprietary (Metadata, Standards (XML,
Risky development data, process, security, WSDL, BPEL)
project UI) Sync and Async
Not out of the box Intrusive application Interaction
management and model Flow coordination
monitoring Separate Infrastructure Advanced exception
supporting BPEL with
To help organisations apply SOA principles to the eBusiness Suite environment,
Oracle has provided an integration repository that lists all the services that are
exposed as part of eBusiness Suite 11.5.10 and above. This can be found at
http://irep.oracle.com. By utilising these services with your integration to
eBusiness Suite Oracle provides you with increased flexibility during future
upgrades. Although the underlying functionality of the service may change, the
method used to define the service will not. Therefore if you interface uses these
services little to no development will be required to that interface during an
People that are new to BPEL think of it as an integration tool that has a number
of adapters allowing communication to a number of applications and
technologies. Although BPEL has comprehensive integration capabilities, it can
also enable organisations to implement complex business rules using workflow
type processes. BPEL can populate worklists, and send emails to notify users of
any impending action, such as a PO approval. A good example of the complex
business rules BPEL can perform is the hiring of an employee. When a new hire
is entered into Oracle eBusiness Suite, a business event occurs that shows that
an employee has been added to your system. Oracle BPEL Process Manager
listens for that event, taking it in and starting a process. Then Oracle BPEL
Process Manager sends an e-mail to the new employee, asking him to access
the Oracle Portal, where they can select their benefits and order their computer,
after which Oracle BPEL Process Manager can use a third-party service to
provide them with their corporate credit card. Finally, a Web service could be
invoked to pass the employee information to security, so that the employee can
get a badge on their first day.
Presenting BPEL Processes:
Creating and modifying business processes alone won’t give your company a
competitive edge; you must also be able to monitor and improve them. You have
to keep an eye on key performance indicators to ensure that your business is
performing according to plan. A component of the Oracle SOA Suite is Oracle
Business Activity Monitoring (Oracle BAM) which enables you to define
monitoring points to provide insight into business flows for reporting, analytic, and
performance improvements and offers a dashboard so you can understand your
business processes and key performance indicators.
Oracle BPEL Process Manager Console provides a user-friendly Web-based
interface for management, administration, and debugging of processes deployed
to the BPEL server. Audit trails and process history/reporting information are
automatically maintained and available through the BPEL Process Manager
Console and via a Java API. The workflow task lists and historical process
analysis reports are also integrated into the same console.
Migrating existing interfaces to BPEL:
Traditionally interfaces used within eBusiness Suite are tightly coupled and
developed with only the source and target system in mind. The diagram below
shows a typical GL interface where the source system FTPs a file to the target
system and a few concurrent programs are run to get the data imported into the
Traditional GL Interface
Source Target Server
Concurrent Program Uploads Source File
Loads data into Load data into
Custom Staging Open Interface
Oracle Alerts Load GL Import
X Potential Manual Intervention
Typically the interface will be broken into 3 parts:
File mappings and business rules, and
Execution of the open interface.
Some sites may also develop some notification capabilities using Oracle Alerts
to notify users of any exceptions that occurred during the import process. Some
sites may also invest money to automate the whole process, but in most
circumstances the business rule will be to run the concurrent programs manually.
Traditionally this interface would have been developed using PL/SQL with a
small amount of shell scripting, although any language or toolset could be used.
The issue is that the intellectual understanding for the program generally says
with the developer, therefore if the interface fails and the developer is not
available it can take some time to diagnose the issue.
As the interface has been developed with only the source and the target system
in mind the program has tightly coupled the 2 systems together therefore if one
of the systems were to change through replacement or upgrade, the interface
could require a complete rewrite.
Using Oracle BPEL and SOA principles you can remove the inflexibilities to make
your interface more robust to change. It can also make the interface easier to
administer and maintain. The diagram below shows how a traditional interface
can be converted into a BPEL process.
BPEL GL Interface
Inbound BPEL Service
Source FTP Custom
File Adapter Stage
Outbound BPEL Service
Main BPEL Service
The fundamental difference between the 2 interfaces is that the BPEL interface is
loosely coupled. The interface comprises 3 BPEL services that work
independently of each other to create the interface. Due to this loose coupling the
impact on this interface will be minimal in the event of the source system being
changed due to upgrade or replacement. Only the inbound service will be
affected. If an organisation has multiple GL interfaces much of this interface can
be reused. All that is required is another inbound service that calls the main
Using the integration repository can also reduce the impact on the interface in the
event of an eBusiness Suite upgrade. The method used to call these services will
remain constant between application releases; therefore the interface should
require no change.
Organisations have many applications within their infrastructure to help them
manage their business. Organisations are also purchasing new systems to help
them overcome current business issues. In this ever changing environment it is
important to implement a method that will reduce the IT spend, yet leverage the
strengths of existing systems, allowing the organisation to move towards the
future. By implementing SOA principles using Oracle BPEL you are able to
achieve these goals. BPEL not only has the capabilities to communicate through
the latest standards such as WSDL, it is also shipped with a number of adapters
to help communicate with older legacy systems. Therefore any 2 applications can
be integrated using Oracle BPEL.
Oracle BPEL also provides some comprehensive administration tools to help
organisations manage the messages being passed through the BPEL engine. No
longer are organisations exposed when key technical staff leave. The BPEL tools
are intuitive which in most circumstances allow business uses to diagnose any
issue that may arise within the application.