Oracle Blog

Monday May 04, 2015

With
the help of my A-Team colleagues (Sushil Shukla, Siming Mu, John
Featherly, Pete Farkas), and based on collective experiences visiting
numerous BPM customers worldwide, I have put together my “Top 10″ list
of things everyone should know when embarking on a BPM project.

You might agree, you might disagree, most of all, feel free to comment.

1. Auditing

BPM provides the business with extremely detailed visibility of runtime instances through its powerful auditing capabilities.

HOWEVER…

This
comes at a cost: detailed auditing requires frequent inserts into the
SOAINFRA database increasing the likelihood of contention and causing
significant database growth. As volume increases it is almost always the
case that the consequences of Auditing produce the first bottleneck.

BUT…

Auditing can be tuned down where appropriate and purge scripts can remediate database growth

It
can often be simpler at the time of BPM process design to have one
large payload schema that includes all elements for every possible
interaction within the lifetime of an instance, and pass this everywhere
within the instance, including to human tasks and their UIs.

HOWEVER…

The
cost of this, both at runtime and in terms of the number and size of
database rows, can be large. The whole payload must be written to
SOAINFRA database at dehydration points within the lifetime of a process
instance & in-between these dehydration points, data objects
associated with this payload are held in memory.

BUT…

Appropriate
design of the payload schema (flatter & simpler) can reduce the
size considerably. The optimal solution would be to pass only key-values
in the payload and retrieve detail values as-and-when needed inside the
process, however this can lead to over-complicating the process design
with technical services. A sensible balance is always the best approach.

Partitioning
& purging are critical to limiting database growth. Test purging
thoroughly as part of a normal stress/load test cycle. Determine whether
“loop purge” outside of the online window is sufficient, if not
consider also using “parallel purge” during quiet periods during the
online day. Partitioning is a good option in most cases, in 11g SOAINFRA
must be partitioned post-installation but in 12c it is an installation
option.

Wednesday Dec 03, 2014

A
lot of effort has been put in by Oracle to make this major upgrade as
smooth and easy as possible. The basic approach is to install SOA Suite
12c in a new oracle home and upgrade the domain and schemas in place.
Customers undertaking the upgrade are primarily interested in a smooth
upgrade, minimizing the number of manual steps in the upgrade, reduce
the down time to a minimum, and minimize or eliminate any changes to
client apps that use SOA APIs or web interfaces.

The key to a
successful and smooth upgrade experience are the preupgrade preparations
that you perform. The upgrade must be planned carefully. If the
preupgrade preparations are not performed, there is a possibility that
upgrade will fail in the middle or the system does not behave properly
post upgrade. The only recourse to a failed production system upgrade is
to roll it back from a full backup.

If your SOA domain includes BAM, then the upgrade is more complex because BAM does not support inplace upgrade. Please read the documentation carefully.
The basic idea is to migrate the whole BAM deployment to a seperate
domain using export/import, remove BAM from the soa domain during
upgrade, and upgrade your soa domain to interop with the bam 11g domain.
Later slowly and carefully migrate to BAM 12c from BAM 11g.

There are six top steps that should be performed before upgrade of your production system as a best practice.

Carefully
review the prerequisites for upgrade in the documentation. Some of the
prerequisites are checked upfront before we upgrade the schema in
Upgrade Assistant but not all. Read all relevant upgrade documentation before starting on upgrade. Some of the key prerequisites are:

· Can only upgrade a domain that is 11.1.1.6 or 11.1.1.7. Migrate to a supported starting point before upgrade.

· Can only upgrade a deployment using a 64 bit JVM. Migrate to 64 bit JVM before upgrade.

· Can only upgrade a production domain not using XE DB and is not an admin server only domain.

·
Can only upgrade a domain using LDAP or DB OPSS policy store. Migrate
file based policy store to DB or LDAP based policy store before upgrade.
Read the complete article here.

Wednesday Jun 04, 2014

At our SOA Community Workspace (SOA Community membership required)
you can find best practice documents for BPM Implementations. Please
make sure that your BPM experts and architects read this documents if
you start or work on a BPM project. The material was created based on
the experience with large BPM implementations:

Monday May 26, 2014

SOA stands for Service Oriented Architecture and has only really come
together as a concrete approach in the last 15 years or so, although
the concepts involved have been around for longer. Oracle SOA Suite is
based around the Service Component Architecture (SCA) devised by the
Open SOA collaboration of companies including Oracle and IBM.

SCA,
as used in SOA suite, is designed as a way to crystallise the concepts
of SOA into a standard which ensures that SOA principles like the
separation of application and business logic are maintained.

Orchestration or Integration?
A common thing to see with many people who are beginning to either
build a new SOA based infrastructure, or move an old system to be
service oriented, is confusion in the purpose of SOA technologies like
BPEL and enterprise service buses. For a lot of problems, orchestration
tools like BPEL or integration tools like an ESB will both do the job
and achieve the right objectives; however it’s important to remember
that, although a hammer can be used to drive a screw into wood, that
doesn’t mean it’s the best way to do it.

Service Integration is
the act of connecting components together at a low level, which usually
results in a single external endpoint for you to expose to your
customers or other teams within your organisation – a simple product
ordering system, for example, might integrate a stock checking service
and a payment processing service.

Process Orchestration, however,
is generally a higher level approach whereby the (often externally
exposed) service endpoints are brought together to track an end-to-end
business process. This might include the earlier example of a product
ordering service and couple it with a business rules service and human
task to handle edge-cases.

A good (but not exhaustive)
rule-of-thumb is that integrations performed by an ESB will usually be
real-time, whereas process orchestration in a SOA composite might
comprise processes which take a certain amount of time to complete, or
have to wait pending manual intervention.

BPEL vs BPMN
For some, with pre-existing SOA or business process projects, this
decision is effectively already made. For those embarking on new
projects it’s certainly an important consideration for those using
Oracle SOA software since, due to the components included in SOA Suite
and BPM Suite, the choice of which to buy is determined by what they
offer.

Oracle SOA suite has no BPMN engine, whereas BPM suite has
both a BPMN and a BPEL engine. SOA suite has the ESB component
“Mediator”, whereas BPM suite has none. Decisions must be made,
therefore, on whether just one or both process modelling languages are
to be used. The wrong decision could be costly further down the line.

Sunday May 25, 2014

SOA stands for Service Oriented Architecture and has only really come
together as a concrete approach in the last 15 years or so, although
the concepts involved have been around for longer. Oracle SOA Suite is
based around the Service Component Architecture (SCA) devised by the
Open SOA collaboration of companies including Oracle and IBM.

SCA,
as used in SOA suite, is designed as a way to crystallise the concepts
of SOA into a standard which ensures that SOA principles like the
separation of application and business logic are maintained.

Orchestration or Integration?
A common thing to see with many people who are beginning to either
build a new SOA based infrastructure, or move an old system to be
service oriented, is confusion in the purpose of SOA technologies like
BPEL and enterprise service buses. For a lot of problems, orchestration
tools like BPEL or integration tools like an ESB will both do the job
and achieve the right objectives; however it’s important to remember
that, although a hammer can be used to drive a screw into wood, that
doesn’t mean it’s the best way to do it.

Service Integration is
the act of connecting components together at a low level, which usually
results in a single external endpoint for you to expose to your
customers or other teams within your organisation – a simple product
ordering system, for example, might integrate a stock checking service
and a payment processing service.

Process Orchestration, however,
is generally a higher level approach whereby the (often externally
exposed) service endpoints are brought together to track an end-to-end
business process. This might include the earlier example of a product
ordering service and couple it with a business rules service and human
task to handle edge-cases.

A good (but not exhaustive)
rule-of-thumb is that integrations performed by an ESB will usually be
real-time, whereas process orchestration in a SOA composite might
comprise processes which take a certain amount of time to complete, or
have to wait pending manual intervention.

BPEL vs BPMN
For some, with pre-existing SOA or business process projects, this
decision is effectively already made. For those embarking on new
projects it’s certainly an important consideration for those using
Oracle SOA software since, due to the components included in SOA Suite
and BPM Suite, the choice of which to buy is determined by what they
offer.

Oracle SOA suite has no BPMN engine, whereas BPM suite has
both a BPMN and a BPEL engine. SOA suite has the ESB component
“Mediator”, whereas BPM suite has none. Decisions must be made,
therefore, on whether just one or both process modelling languages are
to be used. The wrong decision could be costly further down the line.

The OTN ArchBeat Podcast
kicks off the new year with a conversation with three highly
experienced SOA experts about strategies for dealing with some of the
problems that can thwart SOA efforts within some organizations. One of
those strategies involves a new collaborative venture that promises to
remove many of the technical hurdles on the path to SOA implementation. Listen to the podcast here.

Wednesday Mar 12, 2014

An
MDN (Message Disposition Notification) is a transmission level
acknowledgment used in the AS2 standard, so that the sender knows that
the receiver successfully acquired the message in a B2B scenario. B2B
(Business to Business) is an integration term used to describe the
sending and receiving of business messages between business partners.
When the business messages are being sent over the internet via HTTP or
SMTP, it is critical to business operators to know that the messages
were transmitted successfully to the right party. In order to give
assurance to the business operators, specific B2B transmission standards
have been developed. We call these standards "Message Exchange
Standards". These include AS1, AS2, AS4, ebMS and RNIF, to name a few.
AS2 is a very common standard for EDI messaging. It is important for
everyone using the standard to do so in the same way, or else
inter-operation becomes very difficult or impossible. Here is a diagram
showing a typical EDI interaction over AS2 between two fictitious
partners named OracleServices and MarketInc.

AS2 provides features
such as Non-Repudiation of Origin, Non-Repudiation of Receipt, and
Message Protection. When sending a message, the sender includes a
digital signature, and the receiver replies with an acknowledgement
called an MDN (Message Disposition Notification) that includes the
receiver's digital signature. Because each message is signed digitally,
the receiver can be sure that original message has really been sent by
the sender, and that the message has not been tampered with, which we
call Non-Repudiation of Origin. When the receiver replies with the
signed MDN, the sender can be sure that the receiver obtained the
message successfully, and that it was the correct receiver, which we
call Non-Repudiation of Receipt. When message encryption is turned on,
then the message can be protected in flight because it can only be
decrypted by the receiver. Read the complete article here.

Wednesday Nov 13, 2013

This
paper describes the recommended Active - Active solutions that can be
used for protecting an Oracle Fusion Middleware 11 g SOA system against
downtime across multiple locations (referred to as SOA Active - Active
Disaster Recovery Solution or SOA Multi Data Center Active - Active
Deployment). It provides the required configuration steps for setting up
the recommended topologies and guidance about the performance and
failover implications of such a configuration.

Tuesday Aug 06, 2013

Oracle
SOA Suite is a complete suite which contains various services engines
and adapters that can be readily integrated with other SOA Components to
enable true SOA Ecosystem in an Enterprise. The below diagram shows
view of the various SOA/SCA components that can be integrated together
to enable a right SOA Ecosystem. This shown to provide a recap on the
Oracle SOA Suite Components and Architecture before we discuss in detail
about the best practices to be followed in implementing Oracle SOA
Suite.

This article will discuss in detail about the below listed items to enable Best practices.

Hidden Treasures in Oracle SOA Suite 11g – Do it this way!!

Pitfalls in Oracle SOA Suite 11g – Do not Fall!!

Hidden Treasures in Oracle SOA Suite 11g – Do it this way!!

Component Usage

Oracle has provided a Meta Data Store (MDS) with Oracle SOA Suite; make use of this to store Oracle SOA Artefacts.

Oracle provides DVM
to store static references to be used across different flows; don’t
build custom logic to achieve the same. XPath Functions are available to
access the DVMs

Dynamic Cross Reference can be
achieved through Cross Reference Framework available in Oracle SOA
Suite. XPath Functions are available to access the XRefs.

All BPEL Process need not be persisted; make use of oracle persistency policy definition to make the BPEL as in-flight process. It improves the process efficiency.

Make use of Schematron
for Data Validation and Business Rules for defining the business rule
and policies. Oracle Mediator/BPEL provides are features to integrate
with Schematron Data Validation Files.

Don’t invest an additional in acquiring a Queue based product; make use of Oracle Weblogic JMS to implement guaranteed delivery scenarios.

Oracle BPM is bundled along with Oracle SOA Suite. BPMN Maps can be built and converted to BPEL Process.

Create an ESB Wrapper for Asynchronous Error Handler Service that can be utilized for error notification in transactional BPEL flows

When
a Common Error Handler Service implemented in BPEL process are called
by the other BPEL Processes/services that participates in the global
transaction; in case of rollback of the transaction , notification
process is also rolled back by Oracle BPEL Process Manager; to avoid
this ESB wrapper can be utilized.

Leverage Oracle Coherence for shared memory requirements and build capabilities within SOA to leverage coherence as a global space.

Oracle AIA recommends below MDS structure; Make use of this structure to govern your SOA artefacts better and easier.

MDS Partition/Folder

Artifacts Description

ApplicationConnectorServiceLibrary Abstract WSDLs of various Application Business Connector Services (ABCSs) are stored in this partition.

B2BObjectLibrary B2B related schemas are stored in this partition.

B2BServiceLibrary Abstract WSDLs of various B2B Connector Services (B2BCSs) are stored in this partition.

BusinessProcessServiceLibrary Abstract WSDLs of Composite Business Processes (CBPs) and Enterprise Business Flows (EBFs) are stored in this partition.

EnterpriseBusinessServiceLibrary Abstract WSDLs of Enterprise Business Services (EBSs) are stored in this partition.

EnterpriseObjectLibrary Oracle AIA Canonical Schemas are stored in this partition.

Transformations XSLs shared among various services are stored in this partition.

UtilityArtifacts Utility schemas and WSDLs are stored in this partition.

Config SOA Configuration Properties used by business process functions are stored in this partition.

Dvm Domain Value Maps are stored in this partition.

faultPolicies Common Fault Policies are stored in this partition.

Xref Cross References Definitions are stored in this partition.

Implementation

Plan to form a in-house foundation architecture team with few consultants to guide the implementation effort and provide best practices

Spend adequate time and resources in capacity planning of Fusion Middleware Hardware resources

Plan
for highly scalable and truly distributed SOA deployment architecture
with multiple clusters with each Cluster hosting related set of
services.

Scaling of a single SOA environment capable of hosting thousands of services is not feasible even in a HA environment

Don’t use BPEL as a programming language;
uses it as a glue language to call multiple services from different
BPEL. Avoid implementing any service/business logic in BPEL. Utility
Services are exception to this.

Don’t use multiple assign statement to construct a message; use XSL to construct messages and do multiple assign statement.

Don’t loop through the data for checking data constraints; use XPath Expression to check the data constraints.

Keep the number of activities in BPEL as minimal as possible; increasing the number of activities will decrease the performance of BPEL Engine

Avoid declaring many global variables in a BPEL process, instead use scope or local variables.

Don’t forget to turn off the Payload Validation at SOA Infra Properties – This increases the performance of the SOA Suite to greater extent. Major Improvements are guaranteed.

Be aware of setting idempotent property (Partner
Link Property in BPEL); turning off this property results in
dehydration of BPEL process after hitting the right checkpoint.

Don’t choose to have all the services in single Fusion Middleware Environment /System

Formulate an effective load balancer strategy that dispatches the service to appropriate system based on the request

Don’t use Pick based Initiate pattern for implementing interdependent operations

Implement different operations in independent BPEL processes.

Don’t use BPEL for intensive time scheduled activities.

Extensive
use of activities such as alarm and wait can lower system performance
if sufficient threads are not configured properly.

Kathiravan Udayakumar, Senior Architect - Technology, Cognizant Technology SolutionsKathiravan
has 9+ years of IT experience. He has extensive experience in
architecting and designing solutions using various Oracle Fusion
Middleware and PeopleSoft Products. Kathir works for a highly reputed IT
consulting Organisation and is a key member of the Fusion COE team. He
authored the world’s first book for Oracle SOA Certification, entitled
“Oracle SOA Infrastructure Implementation Certification Handbook” Other
books on Oracle SOA Published by the author are, “Oracle SOA Patterns” ,
“Oracle SOA Frameworks”, “Hello World to
Oracle SOA - A Complete Guide to Oracle SOA Suite 11g” and “Oracle SOA
Suite 11g Administration and Performance Tuning”.