Page 1 of 23

Tutorials
Chapter 1: Introduction
Chapter 2: What is SOA Suite ?
Chapter 3: SOA Suite Architecture
Chapter 4: SOA Suite Components
Chapter 5: BPEL
Chapter 6 : Mediator
Chapter 7: Business Rules
Chapter 8: Human Task
Chapter 9: Adapters
Chapter 10: Error Handling

hapter 1: Introduction
Oracle SOA Suite Introduction
Oracle SOA suite is a middleware tool that is used for integration, this tool helps two
system to exchange information between each other. This tool is based upon Service
Oriented Architecture.

Audience
This tutorial is designed for all the professional who interested in Oracle SOA Suite
development.

Versions till date

We have three versions of this tool as mentioned below.
1. 10g
2. 11g
3. 12c

10g was the first version of Oracle SOA Suite tool when it was launched by Oracle and
then few years later Oracle launched 11g version, there are few sub versions under 11g
version also. Recently in 2014 Oracle has launched 12c version also. This tutorial is
based on Oracle SOA Suite 11g version.
 Page 2 of 23

Prerequisites
You should know about below concepts before we start with this tutorial.
1. XML
2. XSD (Schema)
3. WSDL
4. SOAP

Chapter 2: What is SOA Suite ?

Oracle SOA Suite is member of Oracle Fusion Middleware family of products which is
based upon SOA- Service Oriented Architecture so first we need to understand about
SOA- Service Oriented Architecture concept. SOA- Service Oriented Architecture as
name suggested this concept further based upon services. So let’s first understand
services & web service concept.

Service is a unit of work that perform some business function i.e. it is piece of code
written in any language that performs some business function. E.g. Card validation
function created in Java. Service is always local to you, not available to anyone. To
make it available to everyone we deploy it over web.

When we deploy any service over web, it become web service as anyone who so ever
has access can access that service over web. As shown below, external application
accesses the web service by passing required request parameter and in turn it receive
response message.

Web Service
Now we understood about service and web service, now let’s talk about SOA-Service
Oriented Architecture.
 Page 3 of 23

SOA – Service Oriented Architecture is essentially a collection of services. These

services communicate with each other. The communication can involve either simple
data passing or it could involve two or more services coordinating some activity. In
below diagram, boxes above & below SOA Architecture layers depicts services. As
shown this SOA layer helps these services to communicate with each other.

SOA Concept
As we understood about SOA concept, now let’s talk about Oracle SOA Suite tool.

Oracle SOA suite tool is based upon SOA concept where we create services, manage
services and orchestrate services into composite application and business processes.
There are other middleware tools also in the market that are based on this SOA concept
but out of all these Oracle SOA Suite is most popular tool.

Advantage and Features of Oracle SOA Suite tool:

1. Very minimal or no coding required as we build business process and flow from pre-
build components and activities.
2. SOA Suite can be used to deliver more loosely-coupled services.
3. We can build new client functionality on top of existing Business Services.
4. Well defined interfaces- make changes without affecting clients.
5. It is standard platform which is service enabled and easily consumable by modern
 Page 4 of 23

web applications.
6. It provides single design-time experience, single run-time infrastructure, end-to-end
monitoring and greatly simplifies the work of building, maintaining and monitoring
distributed SOA implementations.
7. It is hot pluggable means it can natively run on, other vendor’s middleware also.

Chapter 3: SOA Suite Architecture

Following diagram depicts the architecture of Oracle SOA Suite tool.

WebLogic Server: It is an application server that is based upon J2EE and this has all
JDBC drivers, API’s, adapters etc. deployed. In earlier version of SOA suite i.e. 10 g we
use to have OC4J but 11g onward we use WebLogic as application server. We can also
deploy our custom application on this application server.

Oracle SOA Suite comprises of major four components as mentioned below and
discussed in detail in next chapters.

1. BPEL : Business Process Execution Language

2. Mediator
3. Business Rules
4. Human Task

Web Service Manager: In short form, this is known as OWSM. This is used to
implement security in SOA suite tool. We need not to install this separately, this will get
install when we SOA suite tool, we need to select Web Service Manager Option while
creating domain. This brings pre built security policies that we can use to secure SOA
Suite functionality exposed to outside world, it also provide security policies to access
any secured service from SOA suite tool.

JDeveloper: It is IDE tool to develop SOA suite application and projects. By default this
tool does not SOA suite extensions so while doing the installation; we need to install
required SOA suite extensions to develop SOA applications and projects.
 Page 5 of 23

SOA Suite Architecture

Service Component Architecture
Service Component Architecture is a set of specifications that describe a model for
building applications and systems using a Service-Oriented Architecture. I.e. provides a
model for composing applications that follow Service-Oriented Architecture principles.

Oracle SOA suite tool is based on SCA- Service Component Architecture, here we get
all pre built components, where we assemble all these components to build business
processes. That means as developer you need not to build these components, you just
need to assemble it. That assembly is known as SOA composite.

Below diagram depicts one SOA composites that comprises of different parts. This SOA
composite is equivalent to one assembly that built after we connect all the different
parts.
 Page 6 of 23

SCA
C1, C2 are components in SOA composite e.g. BPEL, Mediator, Business Rules &
Human Tasks. These are also known as service components and these are the building
block for composite application. Every component is hosted on its own service engine.

S & R are known as binding components that are used to connect SOA composite with
external world. S is equivalent to Service binding that is used to connect to source and
R is equivalent to Reference binding that is used to connect to targets. As you see in
the diagram apart from composite level, every component also has its own service
binding and reference binding.

Dotted lines connecting C1 & C2 are known as wire. This enables you to graphically
connect the components in a SOA composite application.

Chapter 4: SOA Suite Components

Oracle SOA Suite 11g has prebuilt service components that comes as part of SOA
Suite tool. These service components are used to build composite applications.
 Page 7 of 23

As shown below , these service components use Service Bindings to connect to

source/client and use reference bindings to connect to target/reference.

Composite Overview
The following service components are available. There is a corresponding service
engine of the same name for each service component. All service engines can interact
in a single composite.

BPEL: BPEL stands for Business Process Execution Language. BPEL processes
provide process orchestration and storage of a synchronous or an asynchronous
process. You design a business process that integrates a series of business activities
and services into an end-to-end process flow. Details explanation is provided on BPEL
in next chapter.

Mediator: It is mediation component that route events (messages) between different

components. We use this component when components need to interact with each
other.

Business rules: It enable you to design a business decision based on rules. This
component is used when user needs user interface to change their business policies
with time without any coding change.

Human task: It provides workflow modelling that describes the tasks for users or groups
to perform as part of an end-to-end business process flow. i.e. we use this component
when we require human intervention in our business process.
 Page 8 of 23

Spring: It enables you to integrate Java interfaces into SOA composite applications.

Components Overview

Chapter 5: BPEL
BPEL stands for Business Process Execution Language. BPEL is an xml based
language for designing and running business processes. This product provides a
comprehensive, standards¬ based and easy to use solution for creating, deploying and
managing cross application business processes with both automated and human
workflow steps – all in service¬ oriented architecture.

BPEL is used for Service Orchestration. It is standard way for composing multiple
services into collaborative and transaction process flow. It is based on OASIS standard
called “Web Services Business Process Execution Language” (WS-BPEL).
 Page 9 of 23

Overview
There are different parts of BPEL as mentioned below.

Service Interface: A WSDL describing the functionality of the BPEL process. The
service interface provides the end user a way to interact with the BPEL process
component using Service Interface / Service Binding.

Activities: units of work. The actual elements that make up the BPEL process flow or
sequence of instructions to be executed.

Partner links: also called Reference bindings. A partner link describes the roles played
for the interaction between the BPEL process and the service it invokes.

Oracle BPEL Process manager is based natively on BPEL – there is no import or export
of BPEL code. Moreover, it’s built ¬in support for standards such as XML, WSDL and
Web Services, XSLT, XPATH, JMS, and JCA makes this an ideal solution for creating
integrated business processes that are truly portable across platforms.

There are different types of BPEL templates in Oracle SOA Suite.

1. Synchronous Template: In this BPEL process response will return immediately after
the request is received. E.g. when you need some information from your friend, you give
him/her a call and he/she immediately reply with the required information.
 Page 10 of 23

Synchronous Template
2. Asynchronous Template: In this BPEL process, response will come after some time
after request is received. E.g. when you call your friend for some information, you give
him/her a call but he/she doesn’t have that information immediately but he/she provide
you that information after some time.

Asynchronous Template
3. One Way Template: In this BPEL process, there is no response message; only
request message will be processed. E.g. when you call your friend to pass some
information but you don’t expect any response back.

Oneway Template
 Page 11 of 23

Chapter 6 : Mediator
Mediator is one of the components of the Oracle SOA Suite tool; it provides mediation
capabilities such as selective routing, transformation, and validation capabilities. We
use mediator when components needs to exchange information within a composite as it
is very light mediation framework.

We can use mediator component to connect to different sources and consume a

business event or receive a service invocation. You can use an Oracle Mediator service
component to handle returned responses, callbacks, faults, and timeouts. Mediator
component follow VETRO pattern, where we Validate, Enrich, Transform, Route and do
Operations.

Overview
Features of Mediator

1. Content based and Header Based routing.

2. Synchronous and Asynchronous Interactions.
3. Sequential and Parallel Routing.
4. Message Re-sequencing.
5. Data Transformation.
6. Payload validation
7. Event Handling

Routing Rules
It is the core features of Mediator component – the ability to route data between a
source and target. The routing is implemented by adding one or more Routing Rules to
 Page 12 of 23

a Mediator. Each Routing Rule defines how data flows from a source to a target service,
may have additional properties that defined if the data needs to be validated, filtered,
and transformed.

There are two types of routing rules in Mediator:

Dynamic routing rule: These rules are used for asynchronous interactions only.
Business rules are used in these rules and endpoint is determined at run time from
business rules.

Static routing rule: These rules are used for synchronous and asynchronous interactions
and these are defined at design time.

Further routing rules are of two types:

Sequential: As name suggested, Oracle Mediator evaluates routing and performs the
resulting actions sequentially .Sequential Routing Rules execute in a single thread and
transaction as the caller. Oracle Mediator always enlists itself into the global transaction
propagated through the thread that is processing the incoming message. In case of
exceptions it rolls back all transactions.

Sequential Routing Rule

Parallel: As names suggest, Oracle Mediator queues and evaluates routing in parallel in
different threads. Oracle Mediator initiates a new transaction for processing each
parallel rule. In case of exceptions it roll back transactions in their own thread.
 Page 13 of 23

Parallel Routing Rule

Chapter 7: Business Rules

Business Rule is one of the component of SOA Suite tool. Business rules are
statements that describe business policies. It allows a business analyst to change
policies with little or no assistance from a programmer. It also enables business to
change their key decisions and policies rapidly and flexibly. There is no need to change
the deployed application if there is a need to implement certain logic at runtime.

Business Rules can be used in following different ways.

• A decision component can be used within a SOA composite and used directly to run
business rules.
• A decision component can be used with the Advanced Routing Rules in Human
Workflow.
• A decision component can be used within a SOA composite and wired to a BPEL
component.
 Page 14 of 23

Business Rules Usage

Business Rules Architecture
As shown below, Composite application interact with Rules Engine on which Business
Rules component runs. All business rules stored in rule repository. Rule author is web
browser where user can go change the business rules without any code changes.

Business Rule Architecture

Let’s briefly introduce the key components which make up a Business Rule. These are:

Facts: Represent the data or business objects that rules are applied to.

Rules: A rule consists of two parts, an IF part which consists of one or more tests to be
applied to fact(s), and a THEN part, which lists the actions to be carried out should the
test to evaluate to true
Rule Set: As the name implies, it is just a set of one or more related rules that are
designed to work together.
Dictionary: A dictionary is the container of all components that make up a business rule;
it holds all the facts, rule sets, and rules for a business rule.
 Page 15 of 23

Chapter 8: Human Task

Human Task is one of the components of SOA Suite tool. In some end to end business
processes we require human intervention e.g. manager needs to approval; in that cases
we use this component i.e. Human Workflow component allows us to incorporate
human intervention in a business process.

The human task component provides the following features:

1. Human interactions with processes, including assignment and routing of tasks to the correct
users or groups.
2. Deadlines, escalations, notifications, and other features required for ensuring the timely
performance of a task (human activity).
3. Presentation of tasks to end users through a variety of mechanisms, including a worklist
application (Oracle BPM Worklist).
4. Organization, filtering, prioritization, and other features required for end users to productively
perform their tasks.
5. Reports, reassignments, load balancing, and other features required by supervisors and
business owners to manage the performance of tasks.

Architecture
 Page 16 of 23

Architecture (Reference Oracle Site)

BPEL process interact with human workflow with human task activity, we use that
activity in BPEL when we need human intervention.

In Human task service component, we have three parts. First part (Service Part) uses to
interact with BPEL process. Second Part (Client Interface) is used to interact with client
applications. In third part (Task Definition) we create require human task.

Below is how human workflow works.

1. BPEL process invokes human workflow with human task activity.This creates a task in the
human task service component. The process waits for the task to complete.
2. There is metadata associated with the task that is used by the human task service component
to manage the lifecycle of the task. This includes specification of the following:
 Who performs the task? If multiple people are required to perform the task, what is the order?
Who are the other stakeholders? When must the task be completed?
 Page 17 of 23

 How do users perform the task, what information is presented to them, what are they expected
to provide, and what actions can they take?
3. The human task service component uses an identity directory, such as LDAP, to determine
people’s roles and privileges.
4. The human task service component presents tasks to users through a variety of channels,
including the following:
 Oracle BPM Worklist, a role-based application that supports the concept of supervisors and
process owners, and provides functionality for finding, organizing, managing, and performing
tasks.
 Worklist functionality is also available as portlets that can be exposed in an enterprise portal.
 Notifications can be sent to email, phone, SMS, and other channels. Email notifications can be
actionable, enabling users to perform actions on the task from within the email client without
connecting to Oracle BPM Worklist or Oracle WebLogic Server.

Chapter 9: Adapters
It is a JCA Binding component, which is a lightweight implementation that uses JCA
standards for inbound and outbound communications. It provides an interaction layer
between the integration server and another application. This enable interoperability with
heterogeneous applications, provided by different vendors, based on different
technologies and platforms. The JCA Binding component allows composite application
to integrate with a service exposed through the adapter as if it were a Web service. i.e.
These adapters help us to connect to external system for both inbound and outbound
interactions.

Overview
 Page 18 of 23

Types of Adapters:

1. Oracle Technology adapters

2. Legacy Adapters
3. Packaged Application
4. Oracle Application

Types Of Adapter
Further technology adapter are of following types:
 Page 19 of 23

Types Of Technology Adapters

Files/FTP:
These adapters are used to connect to file and FTP system. File adapter is used to read
both flat & XML files from local file system. FTP adapter is used to read both flat & XML
files from remote machine. We can perform below operations in these adapters.

a. Read file
b. Write file
c. Sync Read
d. File Listing
 Page 20 of 23

JMS/AQ/MQ:
These adapters are used to read the messages from JMS, AQ & MQ. JMS is open/Java
standard, AQ (Advanced Queue) is oracle standard and MQ (Message Queue) is IBM
standard. We can perform below operations in these adapters.

a. Read
b. write
c. Sync Read & Write

Database:
This adapter is used to interact with database. we can connect to different databases
(like Oracle, DB2, SQL etc) using this adapter. In case we need to connect to non-
oracle databases then we need to import require drivers as these drivers are there by
default. We can perform below operations in this adapter.

a. Call stored procedure

b. CRUD operations
i. Select
ii. Delete
iii. Update
iv. Insert
v. merge
c. Poll for new or changes records
d. Execute pure SQL

Chapter 10: Error Handling

Error or Fault occurs when web services return data other than what is normally
expected. E.g. web service return error message instead of credit card status. In Oracle
SOA Suite, mainly we have two types of faults.
 Page 21 of 23

Types Of Error
Business Faults:
When we have error or fault based on Business functions, it is known as business
faults. e.g. Invalid credit card number, Invalid age etc. These faults are user defined and
application specific.

Technical (Runtime) Faults:

Runtime faults are the result of problems within the running of the BPEL process service
component or web service. These faults are not user-defined, and are thrown by the
system. Below are the most commonly faced runtime faults in SOA Suite tool.

bindingfault: A bindingFault is thrown inside an activity if the preparation of the

invocation fails. For example, the WSDL of the process fails to load. A bindingFault is
not retryable. This type of fault usually must be fixed by human intervention.

remoteFault: A remoteFault is also thrown inside an activity. It is thrown because the

invocation fails. For example, a SOAP fault is returned by the remote service.

In BPEL, we have some standard faults defined. these defined by WS-BPEL

specifications and these are not associated with a message type or WSDL message,
and can be caught without a fault variable. These faults are thrown by the systems.
 Page 22 of 23

In Oracle SOA Suite, we can handle the faults by following ways.

Types Of Error Handler

Catch Blocks
We use Catch & CatchAll blocks to handle the faults at BPEL component level. we use
Catch block to handle specific fault like to handle remote fault and we use CatchAll
block when we don’t know about fault as this block handle all the faults.

We can have only one CatchAll block in one BPEL process but we can have more than
one Catch block in BPEL process. If we have both Catch & CatchAll block in one BPEL
then Catch block executed first.

Fault Handling Framework

This is another way to handle the faults in Oracle SOA suite. Main difference between
these two methods is that, in Catch Block we can only handle error at BPEL level as we
can’t apply these block in other components. e.g. to handle errors in Mediator
component we use Fault Handling framework not Catch blocks.

Fault handling framework only handle faults that occurs during runtime in an invoke
activity in a process, the framework catches the fault and performs a user-specified
action defined in a fault policy file associated with the activity.

We need following two files that for policy driven fault handling:
 Page 23 of 23

fault-policy.xml: This file defines one or more fault Policies with conditions and actions.
In this file we define what type of error we want to handle and what action we need to
perform when that fault occur. In one file, we can define more than one policy as each
policy will have one unique id.

fault-bindings.xml: This file associates a policy with a composite application, a

component, or a reference.