Migrating Oracle WebLogic Integration applications to IBM Business Process Manager Advanced, Part 1: Introduction

This is the first part in a four-part series on migrating applications from Oracle® WebLogic Integration (WLI) to IBM Business Process Manager (BPM). Part 1 describes the tools and techniques that have been successfully used to migrate WLI business processes and associated artifacts to BPM.


Donald Vines (dhvines@us.ibm.com), Executive IT Architect, IBM

Author photoDon Vines is an Executive IT Architect for IBM in the United States. He has been the technical lead of the Worldwide WebSphere Competitive Migration Team since its inception in 2011. In this role, he spends most of his time migrating enterprise applications to the WebSphere V8.x platform for IBM's customers located throughout the world. He is a past representative of the Object Management Group (OMG), where he co-invented the Internet Inter-ORB Protocol (IIOP) that is used throughout the internet. Don is also an IBM Senior Certified IT Specialist, Sun Certified Enterprise Architect, Sun Certified Java Programmer, and OMG Certified UML2 Professional.

developerWorks Contributing author

Mike Cai (mikecai@us.ibm.com), Senior IT Specialist, IBM

Mike Cai photoMike Cai joined IBM right out of college in 2001 as an IT Specialist in the Enterprise Application Development practice of Global Business Services (GBS), focusing on Java/J2EE application development for client engagements. Mike later moved to the Enterprise Application Integration practice as a senior IT consultant, mainly performing large enterprise system and application integration using J2EE platforms and technologies such as WebSphere Application Server, WebSphere MQ, WebSphere Lombardi Services, JMS, SOAP, BPEL, Service Bus, WebSphere Service Registry and Repository, and so on. Mike was also hands-on in a variety of roles including architect, designer, developer, technical leads, business analyst, defect manager, and more. For the past five years, Mike has focused mostly on BEA/Oracle WebLogic and Fusion products suites, WLS, WLI, OSB, ODI, and WLP. He's produced a full range of deliverables from front-end JSPs, to mid-layer JPDs and OSB mediation and transformation services, to back-end SOAP and JMS web services.

Dave Mulley (dmulley@us.ibm.com), IT Specialist, IBM

Photo: Dave MulleyDave Mulley joined IBM in 1999 after graduating from Loughborough University with a BSc in Computer Science, and worked at IBM Hursley for 5 years, initially in the MQ and CICS Demo Team and then in the Worldwide Competitive PoC Team. Dave moved to IBM RTP in 2004 and joined IBM Software Services for WebSphere in the WebSphere Enablement Team, where he focused on performing Proof of Concepts for the ESB, BPM and B2B offerings. In 2012, Dave joined the Worldwide Competitive Migration Team where he now specializes in migrating customers from competitive ESB's and Application Servers.

developerWorks Professional author

David VandePol (vandepol@ca.ibm.com), IT Specialist, IBM

David VandePol photoDavid VandePol has worked for IBM since 2008. Prior to joining the competitive migration team at its inception in January 2012, he worked in development on the WebSphere install team for WebSphere v7 and 8. David has become well versed in all operating systems supported by WebSphere. As a member of the migration team David has taken part in developing training workshops for migration education from competitive application servers and version to version migrations. He has led many workshops in Canada and throughout the United States. David has performed many successful migrations from JBoss, WebLogic, Oracle Application Server, and Tomcat at numerous customers worldwide.

28 May 2013

Also available in Russian


Oracle unveiled its roadmap for BEA acquisition's products back in July 2008. During the webcast, Oracle Senior VP Thomas Kurian explained that Oracle has divided BEA’s products into three groups (strategic1, continue and converge2, and maintenance3). He then assigned each of the BEA products to one of these groups. WebLogic Integration (WLI), was assigned to the "continue and converge" group; it was no longer listed as a strategic product. This means that incremental extensions will be made to WLI 10gR3 and it will be converged with the Oracle BPEL Process Manager. In fact, extended support has already ended for many of the earlier WLI releases. For more information, refer to Oracle Information Driven Support: Lifetime Support Policy.

Because WLI is no longer a strategic product at Oracle, all WLI customers will eventually be forced to migrate their business processes and applications from WLI to an alternative platform, such as Oracle BPEL Process Manager or IBM BPM Advanced.

If you are one of those Oracle customers that are lucky enough to be running on WLI 10gR3, you can defer that decision for a few years because the extended support for 10gR3 doesn't end until Jan 2017. But if you are like most Oracle customers and are running your business processes on earlier versions of WLI, you will need to make a decision soon. In making such a decision, there are two options to consider. Specifically, you can:

  • Migrate to WLI 10gR3 now and migrate to an alternative platform in a few years.
  • Migrate to an alternative platform now and avoid the cost of migrating to 10gR3.

If you decide to migrate to an alternative platform, one option is Oracle BPEL Process Manager, which provides common infrastructure services to create, deploy, and manage BPEL business processes. Oracle has tooling to assist in the migration of WLI business processes and applications.

However, another strategic replacement product for WLI is IBM BPM Advanced, which is also a fully functional BPEL solution with tools to assist in the migration from WLI, as illustrated in the comparison below.


1 Strategic — These products will become Oracle’s lead offerings in their categories. In some cases, this means that Oracle will merge its own products into corresponding BEA products over the next 12 to 18 months. Kurian stressed, however, that there will be no forced migrations from the merged products to BEA offerings.

2 Continue and converge — These products have features that Oracle wants to include in its middleware stack. As a result, Oracle will incrementally redesign these products so that they can integrate with Oracle Fusion Middleware. It will also support the current releases of these products for at least nine years.

3 Maintenance — These products were already declared by BEA prior to the acquisition to be at the ends of their lives. Oracle will honor BEA’s maintenance contracts on these products by supporting them for at least five years.

Table 1. Feature comparison of IBM BPM Advanced V8 and Oracle Weblogic Integration 10gR3
IBM BPM Advanced V8.0 Oracle WebLogic Integration 10gR3
WebSphere Process Server compatible execution (BPEL) Process integration
Process Designer (BPMN) N/A
Integration Designer (BPEL / SOA) Eclipse-based IDE
Collaborative editing / immediate playback N/A
Interactive "process coach" user interfaces N/A
ILOG-based process rules N/A
Process Portal Administration and management
Real-time monitoring and reporting Administration and management
Performance analytics & optimizer Administration and management
Performance Data Warehouse N/A
Process Center / shared asset repository N/A
Unlimited process authors and end-users N/A
High availability: clustering and unlimited cores WebLogic Server high availability and clustering
Built-in enterprise service bus (ESB) Integration with AquaLogic Service Bus
Transaction support Stateless and stateful processes
Integration adapters Trading partner integration
Integration with back-end systems Trading partner integration
Advanced platform support (Linux on System z®, IBM AIX®, Solaris) N/A
Lombardi Process Portal Human user integration
Business Space user interface Human user integration

Series overview

This series of articles describes the overall process and supporting tools for exporting BPEL and supporting artifacts from WLI to IBM BPM Advanced. This tool-assisted approach enables you to produce a complete replica of your WLI application running on the IBM BPM Advanced platform. You can perform manual editing for optimum use of the new features provided by the platform. To obtain the migration tools described in this series, please contact the authors directly.

The series does not present a feature by feature comparison of Oracle BPEL Process Manager and IBM BPM Advanced. Contact your IBM sales representative for such a comparison. For this series, it is sufficient to say that IBM BPM Advanced is a superset of the features and functions in WLI, as illustrated in Table 2, and is therefore a viable alternative to WLI.

The articles in this series are as follows:

  • Part 1: "Introduction" describes the tools and techniques that have been successfully used to migrate WLI business processes and associated artifacts to BPM. This article covers the following:
    • Artifacts describes WLI artifacts that make up the business processes.
    • Tooling describes the tools that can be used to migrate these artifacts.
    • The migration process describes the high-level process of exporting and migrating these artifacts.
  • Part 2: "Data Transformations" describes the different transformations that may be required to reuse business logic that is encapsulated inside the WLI artifacts.
  • Part 3: "Migrating WLI Controls to IBM BPM" shows you how to convert WLI Controls to Service Component Architecture (SCA) components that can be run on IBM BPM.
  • Part 4: "Migrating WLI processes (JPDs) to IBM BPM" pulls all of the pieces together by demonstrating the migration of a business process that runs on Oracle WLI to one that runs on IBM BPM.

The issues discussed in this series apply directly to the migration of applications from Oracle WebLogic Integration V8.x, V9.x, and V10.x to IBM BPM Advanced V7.0, V8.0, and V8.5. Most of the information here also applies to earlier versions of WLI.


This section describes the artifacts that make up a WLI application.

WLI represents workflows in files with a .jpd extension. A JPD is a Java file, with some extra Javadoc annotations that define the orchestration logic.
WLI uses WSDL to define the interface to the JPD and its partners.
WLI represents XQueries in files with an .xq extension.
Data Transformation File (DTF) is a WLI control that can be invoked by a JPD. DTF files have an extension of .dtf. DTF files contain definitions of a data transformation that can be invoked from a JPD. DTF controls generally retrieve some data from an XML document by invoking XQuery (which uses XPath to address specific parts of the XML document).
Java Control Source (JCS) files are Java components that developers write to provide business logic and access other controls. These Java controls have an extension of .jcs. They are invoked by JPDs, may have per-process state, and may also access collaborators on behalf of their JPD.
Java Control Extension (JCX) files act as wrappers for Java EE resource adapter modules and have an extension of .jcx. They are invoked by JPD callouts.
WLI uses XMLBeans to generate Java types from WSDL and XSDs. These Java types are used as parameters to many of the aforementioned WLI artifacts.


This section describes the installation and configuration of the migration tools.

BPEL 2.0 Importer


The BPEL 2.0 Importer is an Eclipse plug-in for importing WS-BPEL 2.0 process definitions into IBM Integration Designer V8.0 or V7.5 (or WebSphere® Integration Developer V7.0) so they can be run on IBM BPM. Although IBM BPM supports the majority of WS-BPEL 2.0, some of the language elements in BPM still use the syntax defined in the preliminary BPEL4WS 1.1 specification. The BPEL 2.0 Importer handles these language differences by running a series of XSLT transformations. It even allows you to add new XSLT transformations if required.


Follow the installation instructions for the BPEL 2.0 Importer described in the developerWorks article Importing WS-BPEL 2.0 process definitions.

BPEL 2.0 Importer – WLI customization


As mentioned, the BPEL 2.0 Importer was designed to import WS-BPEL 2.0 language elements and extended to handle differences. This extensibility feature is quite useful because there are parts of the WLI BPEL that are nonstandard. Thus, IBM has created a number of additional XSLT transformations to account for the required changes between the WLI BPEL and BPM BPEL. These conversions are syntactic in nature and preserve the runtime semantics.

Some of the additional transformations are:

  • Convert BPEL v2.0's "if-else/if-else" constructs to v1.1 "switch-case" constructs.
  • Convert <empty>, <scope>, and <sequence> nodes under the main "if" element.
  • Convert "condition" attributes, nodes, or both.
  • Convert XPath or Java snippet conditions.
  • Convert <empty> nodes with a <jpd:javacode> child to an <invoke> node.
  • Refactor <jpd:javacode> nodes to <wpc:javaCode> nodes.
  • WLI's <jpd:javacode> elements wraps Java snippet codes in a method block with method name and curly braces. Those are stripped for BPM Java Snippet constructs.
  • Add TODO comments in the Java code to remind developers to review and refactor the Java codes to be BPM or WebSphere Process Server compatible.
  • Remove incompatible XQuery related nodes.
  • Attempt to give a unique name to <scope>, <sequence>, <assign> nodes.
  • Convert variables with initialized values. (Integer and String only so far).
  • Refactor PartnerLinkType.


Once the BPEL 2.0 Importer has been installed, you can import BPEL as described in the BPEL plug-in documentation. When BPEL process definitions are imported using the BPEL 2.0 Importer, these process definitions may contain XPath expressions that call XPath functions provided by WLI. If so, the BPEL 2.0 Importer leaves these XPath expressions unchanged. When the processes are in IBM Integration Designer, the calls to these WLI proprietary XPath functions are marked as errors as these functions are unknown in the IBM BPM environment

To handle these WLI proprietary XPath expressions, we have implemented about 15 XPath functions that we have found in WLI BPEL processes. These XPath expressions have become a base for a growing repository of XPath function implementations that can be reused for WLI migrations. These XPath function implementations are made known to the IBM BPEL 2.0 Importer by replacing the XSLT file that came with the BPEL 2.0 Importer. The location of that file is:

The migration of WLI proprietary XPath expressions will be described in more detail in Part 3 of this series.

OpenESB BPEL 1.1 to 2.0 transform tool


The BPEL 1.1 to 2.0 transform tool is a third-party tool that can be downloaded to migrate your BPEL process from 1.1 to 2.0. You may need this tool if you are running earlier versions of WLI that only support BPEL 1.1 exports. This tool can be at the Open ESB web site.


The BPEL transformation tool is an executable JAR. Example usage is:
java –jar transform.jar <input folder> <output folder>

Note: <input folder> should contain any referenced BPEL, XSD, or WSDL files.

WLI migration utilities

This section describes the migration utilities available to help you migrate your WLI applications to IBM BPM.

JCS migration utility

The JCS Migration Utility helps migrate JCS (Java Control Source) to Java Objects that can be run on IBM BPM. In WLI, JSCs are essentially Java implementations with a .jcs extension. This utility automatically modifies JSC files and their corresponding interfaces, and modifies them into standard Java Objects that can be used by BPM. This utility automatically migrates JSCs by:

  • Changing the extension from .jsc to .java
  • Modifying the interface and implementation to remove any proprietary APIs
  • Creating an SCA implementation that can be used by BPM

Note: The SCA implementation references some conversion libraries that we developed to handle the data transformations between XMLBeans and Service Data Objects. These libraries are also included in the project classpath.

The utility is an executable JAR that can be run at the command line. Example usage is:
java –jar transformationUtil.jar JCStoJAVA <location of jcs>.jcs

For example, suppose that <location of jcs> had the files:

  • Example.java – Interface file
  • ExampleImpl.jcs – Implementation of Example, and business logic

After running the utility you would have:

  • Example.java – New interface with proprietary APIs removed
  • Example.java.old – Original Java interface for reference (this can be discarded)
  • ExampleImpl.java – Implementation of Example.java with proprietary APIs removed and some other changes
  • ExampleSCAImpl.java – An SCA implementation that does some data transformation and calls the corresponding methods in ExampleImpl.java. This can be used in BPM
  • ExampleImpl.jcs – The unchanged jcs file (this can be discarded)

DTF Migration Utility

The DTF Migration Utility assists in the migration of WLI DTF (Data Transformation Files) to Java Objects that can be run on IBM BPM Advanced. In WLI DTF files are used to help execute XQuery files for performing data transformations. References to the XQuery files are defined as Java doc comments above each method in the DTF.

The DTF migration utility automatically modifies DTF files by converting them to standard Java Objects that can be used by BPM. This utility automatically migrates the DTFs by:

  • Changing the extension from .dtf to .java
  • Removing the abstract definition from the class name
  • Changing the abstract methods to standard methods, and modifying the methods to execute the corresponding XQuery file that was defined within the comments
  • Modifying the class by removing any WLI proprietary APIs
  • Modifying the return type of the methods to return a standard DataObject

The tool is an executable JAR that can be run at the command line. Example usage is:
java –jar transformationUtil.jar DTFtoJAVA <location of dtf>.dtf

XQuery Migration Utility

The XQuery Migration Utility automatically migrates the XQuery files that run on WLI so that they can be executed in BPM. These XQuery files were written specifically for execution in DTF files, and a few modifications need to be made to make them standard. They were migrated by:

  • Adding namespace declarations
  • Adding ";" at the end of some lines

The tool is an executable JAR that can be run at the command line. Example usage is:
java –jar transformationUtil.jar XQueryTranformation <location of xquery>.xq

The migration process

This section gives a high-level overview of the major steps performed during the migration from WLI to IBM BPM, as illustrated in Figure 1. These steps will be described in more detail in future parts of this series.

Figure 1. The migration process
The migration process


During the preparation stage, the required software is installed (it is assumed that WLI is already installed), which includes:

  • IBM Integration Designer V8.0
  • IBM BPM Advanced V8.0
  • BPEL 2.0 Importer
  • OpenESB BPEL 1.1 to 2.0 Transform Tool (Optional)
  • JCS Migration Utility
  • DTF Migration Utility
  • XQuery Migration Utility

Extract artifacts

In this stage of the migration process, the following artifacts are extracted or exported from the WLI workspace:

  • WSDLs and web services (such as JWS)
  • Control implementations (such as JCS and JSX)
  • Data transformations (such as DTF and XQ)
  • XML Schemas (XSD)
  • EARs and Java Source Files

Export BPEL v2.0

If you are using WLI v10.x and have access to JDeveloper, you can export the JPD processes as BPEL v2.0 and avoid having to perform the transformation in the next section. If you are using WLI v7.x, v8.x or v9.x you must export the JPD processes as BPEL v1.1, as described in the next section.

Export BPEL v1.1 and transform to BPEL v2.0

If you are using WLI v7.x through v9.x, you don't have the capability to export the JPD processes as BPEL 2.0 and therefore must first export the JPD processes as BPEL v1.1 by doing the following:

  1. Use the Export BPEL option in WLI Workshop to export the JPD process as BPEL.
  2. Copy the BPEL, WSDL and XSD files in to a temporary directory.
  3. Use the OpenESB BPEL 1.1 to 2.0 Transform Tool to convert the BPEL to BPEL v2.0.

Import artifacts into Integration Designer

The next stage of the migration process is to import the WLI artifacts into IBM Integration Designer using the BPEL 2.0 Import wizard in the Import dialog.

Migrate XMLBean objects

XMLBeans (based on the Apache XMLBeans) is the default XML data construct and access technology leveraged by WLI processes. Many existing WLI artifacts, WLI controls, Java snippets and Java utilities contain XMLBean objects. Given that some of the aforementioned artifacts have XMLBeans deeply embedded and would be too costly to re-code, you can follow these steps to bridge between XMLBeans and SDO.

  1. Generate XMLBeans Java objects from existing XSD schemas using Apache XMLBeans libraries.
  2. Import generated XMLBeans into the Integration Designer workspace.
  3. Locate existing code where XMLBeans are used.
  4. Use WLI migration utilities to convert between XMLBeans and SDO. (This is a two step conversion process: XMLBeans ↔ XML String ↔ SDO.)

This process will be described in more detail in Part 2 of this series.

Migrate the WSDL

Two WSDL files are generated for each exported WLI JPD BPEL flow.

  • One provider WSDL defines the interface for the JPD process.
  • One control WSDL defines the interface for all the external services the JPD process invokes. This WSDL has the "_ctrl" suffix in the file name.

After the WSDL files are imported in to Integration Designer, a number of changes may be required:

  • schemaLocation sometimes need correction.
  • Some types will have to be modified (for example, Exceptions, Objects, xsd:base64binary).
  • The provider WSDL may have a missing types definition. This can be imported from XSD or copied from the control WSDL.
  • Some interfaces in the control WSDL files may be replaced by the original WSDL files or other exported WSDL files (e.g. web service controls, process controls, and so on.)
  • PartnerLink information may need to be updated.

This process will be described in more detail in parts 3 and 4 of this series.

Migrate XQuery transforms

WLI uses XQuery language to transform XML messages. Such XQuery transformations are commonly used in WLI JPD processes. Each XQuery is saved in a .XQ file and is invoked using a WLI control (saved in a .DTF file). IBM BPM does not natively support XQuery transformations (it supports transformations using XSLT or Java) and although manually converting the XQuery to XSLT or Java is an option, in some cases it might be easier to use the existing XQuery transformations by invoking the WebSphere Thin Client for XML, which supports XQuery 1.0. To use the XQueries with the WebSphere Thin Client for XML, do the following:

  • Run WLI Migration Utilities to transform .DTF to .java code that leverages the Thin Client for XML.
  • Run WLI Migration Utilities to transform .XQ files to be compatible with the thin client.
  • Create Java SCA component using the converted .DTF Java implementation.

This process will be described in more detail in Part 2 of this series.

Migrate Custom Controls

WLI Custom Controls are externalized Java classes exposed as a WLI control, which are invoked by WLI JPD processes. These Custom Controls often implement complex functionality that is not provided natively by WLI or IBM BPM and may have a large code base that is impractical to re-implement during migration. Complete the following steps to migrate the Custom Control to IBM BPM while preserving as much of the custom code as possible:

  • Run WLI Migration Utilities to transform Custom Control .JCS files to POJOs.
  • Create a Java SCA component using the converted .JCS Java implementation.
  • Perform any manual modifications necessary to correctly convert data types in the converted .DTF Java codes.

This process will be described in more detail in Part 3 of this series.

Migrate Built-in Controls

WLI built-in controls are pre-built integration components that allow the WLI JPD process to interact with external enterprise systems. These built-in controls are exposed through a Java Control Extension (.JCX) file that contains the interface and configuration data for the built-in control.

Some built-in controls can be replaced by embedded IBM BPM business process features (such as Process Control with Invoke, Timer Control with Expiry or Wait, and so on), some can be replaced by WebSphere Adapter and some simply require re-implementation.

This process will be described in more detail in Part 3 of this series.

Migrate the business processes

This step of the migration process is focused on making the required changes to the BPEL process that was exported from WLI to ensure that it is ready to run on IBM BPM. Some of the required changes are:

  • Conversion of fault handlers
  • Conversion of parallel "or" constructs
  • Setting transaction properties
  • Conversion of Java snippets
  • Modification of partner references

This process will be described in more detail in Part 4 of this series.

Assemble and wire the components

Once the BPEL process and other implementation artifacts have been migrated to IBM BPM, you need to complete the assembly diagram by creating SCA components and wiring them to the BPEL process. Before the application can be deployed, you must create any required J2EE resources on the IBM BPM server and disable the inter-transaction cache.

This process will be described in more detail in Part 4 of this series.

Deploy and test

The final stage of the migration process is to deploy and test the new IBM BPM process using the integration test client in Integration Designer. If there are any unimplemented components or unwired references in the process, they are automatically emulated. This means your process does not need to be complete before you can start testing.

This process will be described in more detail in Part 4 of this series.


The tools and migration process described in this series of articles were developed over the past year to ease the process of migrating Oracle WLI applications to IBM BPM Advanced. These tools have successfully been used at customer sites. To obtain these tools, contact the authors or your IBM sales representative.



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Business process management on developerWorks

Zone=Business process management, WebSphere
ArticleTitle=Migrating Oracle WebLogic Integration applications to IBM Business Process Manager Advanced, Part 1: Introduction