Migrating Oracle WebLogic Integration applications to IBM Business Process Manager Advanced, Part 2: Data transformations

Part 1 of this series described the tools and techniques that have been successfully used to migrate Oracle® WebLogic Integration (WLI) business processes and associated artifacts to IBM Business Process Manager (BPM). Part 2 describes how to convert the different types and APIs that are used to write business logic in WLI flows into the types and APIs that can be used by that same business logic running on the IBM BPM platform.

Share:

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
        level

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.



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
        level

14 August 2013

Also available in Russian

Introduction

Data is always a focal point in any business processes. After all, a process is nothing more than a timely coordinated transportation, extraction, manipulation, conversion, transformation, and aggregation of some data based on some other data. The Oracle WebLogic Integration (WLI) platform uses different data binding technology from IBM WebSphere Business Process Manager (IBM BPM), so migration of data and functionality around data becomes a key task in the migration of WLI flows to BPM processes. Following is a list of data bindings and formats commonly found in WLI flows:

  • XMLBeans is an open source XML and Java data binding library developed by Apache. It is also the standard data binding technology used by WLI flows, controls, and various artifacts. In a WLI project workspace, any data definitions based on XSD schemas will be compiled in to XMLBeans (special Java™ beans). XMLBeans are used extensively both within a WLI flow and at the interface boundary of flows, controls, services, and so on.
  • Java Objects are supported natively by the WLI platform. They are commonly used within WLI flows, controls, and various artifacts. The WLI platform also supports using serializable Java types in the interface parameter definitions for various WLI artifacts. This allows the direct passing of Java objects between the interfaces of flows, controls, and other WLI artifacts.
  • Other industry standard XML Java data bindings such as Java Architecture for XML Binding (JAXB) have also been leveraged in various implementations due to deficiencies in capabilities or performance of the XMLBeans library. Both global and local variables can be declared using third party binding objects. They can even be persisted in stateful transactions.

IBM BPM is built using the Service Data Object (SDO) framework as the main data binding technology. This means any WLI codes (such as perform nodes and Java controls) leveraging XMLBeans objects need to be migrated to a SDO syntax. IBM BPM does not support direct exchange of serializable Java type objects across interfaces between processes and SCA components. These types of interface definitions from WLI must also be migrated to WSDL interfaces with appropriate updates to the implementations. Other binding technologies such as JAXB can be handled by data handlers in IBM BPM.

This article describes how to migrate data represented in these formats to the native data binding used by the IBM BPM processes, SDO. It describes the issues and resolutions surrounding these migrations; provides recommendations on various approaches; and demonstrates some of the utilities that have been created to help make these migrations quicker and less risky.

To do that, we'll first define a WLI process, then use that process to describe the different data types and APIs that must be migrated in order to reuse the business logic that is encapsulated inside that WLI process.


WebLogic Integration example

This section describes sample WLI business data and a business process that we'll use for demonstration purposes in the rest of this article series. We designed the business data and process to demonstrate the different capabilities of the IBM WLI migration tooling.

We use UML to represent the business data and process. If you are more familiar with the WLI representation, you may want to open the project workspace for this sample, which has been provided for download with this article.

Business data

This flow is a simple purchase order process that is started when a Purchase Order (XML) is received. Figure 1 shows the Purchase Order XSD.

Figure 1. Purchase Order XSD
Purchase Order XSD

Click to see larger image

Figure 1. Purchase Order XSD

Purchase Order XSD

The WLI business process

The main process is found in Process.jpd and is shown in the UML diagram in Figure 2. It starts off by checking to see whether the customer has sufficient funds. If they do, then two parallel flows are invoked: one handles the billing; the other uses a subprocess to check whether the product is in stock and sends a JMS message with a list of products that are in stock, and a list of products that are not. Once the parallel flows have completed an invoice is created and an email is sent to the customer informing them that the order has been processed.

Figure 2. WLI Process: Process.jpd
WLI Process: Process.jpd

Click to see larger image

Figure 2. WLI Process: Process.jpd

WLI Process: Process.jpd

The WLI subprocess is found in isItemInStockSubProcess.jpd and is shown in the UML diagram in Figure 3. The subprocess queries a database to determine the current stock level for a given product and then, if there was enough in stock, deducts the ordered amount from the current stock. Finally, the subprocess returns a boolean result to the calling process.

Figure 3. WLI subprocess: IsItemInStockSubProcess.jpd
WLI SubProcess: IsItemInStockSubProcess.jpd

A detailed description of each step of these flows is in the sample application that you can download.


Migrating XMLBeans

As part of the overall migration process described in Part 1, the exporting of BPEL and WSDL files from WLI for a JPD flow and the importing of these files into IBM Integration Designer using the BPEL 2.0 Importer Plugin with WLI customization will take care of a majority of the transformations required to migrate WLI JPD flows to IBM BPM processes. We will describe that process further in Part 4 of this series.

However, wherever Java programming is used to manipulate XMLBeans objects, manual modifications are needed to that code to manipulate SDO objects. With XMLBeans you use get<FieldName> and set<FieldName> methods; while with SDO you use get and set methods and pass in the field name. In most cases, you can simply replace the assignment statements to use SDO syntax as shown in the following example.

Table 1 shows the same IsItemInStock conditional branch in the WLI example and in the migrated IBM BPM process flow. In the sample process, once a product is confirmed to be in stock, it is added to a shipment list.

Table 1. IsItemInStock conditional branch
WLI IBM BPM
IsItemInStock in WLI exampleIsItemInStock in BPM process

In WLI's AddItemToShippingList perform node, XMLBeans' get methods are used to obtain ordered product information for output and assignment, as shown in Figure 4.

Figure 4. Imported AddItemToShipment Java snippet
Imported AddItemToShipment Java snippet

The migrated AddItemToShipment Java snippet in BPM uses the SDO get syntax to obtain the same ordered product information, as shown in Figure 5.

Figure 5. Migrated AddItemToShipment Java snippet in SDO syntax
Migrated AddItemToShipment in SDO syntax

In some cases, there are extensive numbers of XMLBeans objects being manipulated. In other cases, there is a preference to reuse the existing utility libraries that were coded based on the XMLBeans objects. In these cases, it can become a very slow and tedious process to convert everything into SDO syntax. In such a scenario, it's possible to convert the key native SDO variables in the process into XMLBeans objects and reuse the existing utility libraries that worked with XMLBeans without modification.

In order to do this, existing schema definitions (XSDs) must be compiled into XMLBeans objects and put onto the Java classpath. This is normally done automatically by BEA Weblogic Workshop or JDeveloper when XSDs are added to a Schema project. IBM BPM and Integration Designer do not provide XMLBeans libraries and compilations out of the box, but you can download an open source copy of XMLBeans from Apache and compile the XSDs into XMLBeans.

Once the desired XSDs have been compiled into XMLBeans Java objects and placed onto the classpath, the process code snippet can be modified to leverage it just like any other Java objects. Of course, there will need to be conversions between the XMLBean objects and the SDO objects which the IBM migration utility provides. The results of such modifications, using the same examples as above, would look something like Figures 6 and 7.

Figure 6. XMLBeans and compiled XSD library JAR files on the classpath
XMLBeans and compiled XSD library JAR files on the classpath

Using migration utilities, SDO to and from XMLBeans conversions were added before and after the original code (the red boxes). Original codes for output and assignment of ordered product information have been kept (yellow boxes). Only the variable name had to be modified in the original code because to conflicts with a global variable.

Figure 7. Migrated AddItemToShipment Java snippet using SDO to and from XMLBeans conversion
Migrated AddItemToShipment Java snippet using SDO to/from XMLBeans conversion

As you can see, all we did here was convert the incoming SDO object to an XMLBean object. Then we could reuse all of the existing code. At the end of the method, all we did was convert the XMLBeans object back into an SDO object. There are three important lessons learned when reusing XMLBeans objects in a BPM process:

  1. Any SDO variables that are not scoped purely within a Java snippet (that is, global and local process variables) and were converted to XMLBeans objects for manipulation must be converted back into the original SDO variable.
  2. The compiled XMLBeans object JAR file contains a set of the original XSDs files. When the JAR is placed onto the classpath of a BPM process module project, it is in essence putting duplicate XSDs on to the classpath. This may confuse the BPM server's artifact loader and cause deployment issues. In such cases, you can manually expand the JAR files, remove the XSD files, and repackage the JAR file. These XSDs are for schema extraction and viewing purposes, and do not interfere with the manipulation of the XMLBeans objects themselves.
  3. Although there are some performance implications of converting between SDOs and XMLBeans, when considered in the context of the overall process flow, this overhead is very small, and the benefit is reusable code without any modifications. Of course, if your profiling of the application indicates an issue, you can always convert the data types and APIs using one of the other approaches described in this article.

Fortunately, on the interface side minimum changes are required when using the WSDL exported from WLI BEA Workshop or JDeveloper. Since the XMLBeans objects are compiled from XSDs, these WSDLs have been defined using the same XSDs, which are also valid to use with SDO objects in IBM BPM interfaces. In the example WSDL in Listing 1, only the schemaLocation had to be corrected because file organization in BPM is slightly different than WLI.

Figure 8 shows the WSDL interface for the main process in the WLI example after it has been imported into IBM BPM. It leverages the original XSD definition for the input parameter type.

Figure 8. WSDL interface in IBM BPM using the original XSD
WSDL Interface in IBM BPM using the original XSD

Listing 1 shows the imported WSDL XML unchanged except for the relative path of the schemaLocation.

Listing 1. WSDL XML in IBM BPM importing the original XSD
<types>
	<xsd:schema>
		<xsd:import namespace=”http://temp.openuri.org/DemoApp/PurchaseOrder.xsd”
				schemaLocation=”../data/PurchaseOrder.xsd” />
	</xsd:schema>
</types>

<message name=”Process_clientRequestMsg”>
	<part name=”purchaseOrder” element”pur:PurchaseOrders” />
</message>

Migrating Java types

The WLI platform allows extensive use of "regular" Java objects that are not XMLBeans based in its process flows and controls. This creates two additional data types and APIs that need to be handled during the migration process:

  • Native Java objects as global variables
  • Native Java objects as input and output parameters to interfaces

IBM BPM, on the other hand, supports only XSD-based global variables and some simple Java types such as String, Integer, Double, and so on. This is the same during invocation of SCA and WSDL interfaces. In the case where more complex Java types (such as Collections and Throwables) are being used as global variables or being passed to SCA components, they need to be converted to something else in order for BPM to persist and process them.

IBM BPM supports the xsd:base64Binary XML schema type and binds it to a Java byte array object. So it is possible to convert complex or custom Java objects to a byte array when they need to be persisted or passed around. The IBM WLI migration utilities provide methods to achieve that.

The IsItemInStockSubProcess in the WLI example accepts a JAXB object with product information as input. This means that in the main process, product information stored in XMLBeans object must be converted to JAXB before sending to the subprocess. The IsItemInStockSubProcess process control node includes a snippet to transform the input parameter from XMLBeans to JAXB before invocation. This node in WLI becomes a Java snippet and an invoke activity after migration to IBM BPM.

Table 2. IsItemInStockSubProcess invoke and related activities
WLI IBM BPM
IsItemInStockSubProcess node in WLI exampleIsItemInStockSubProcess node in IBM BPM example

In the main WLI process transformToJAXB method, product information is converted and stored in a global variable of JAXB object type (this.product), as shown in Figure 9.

Figure 9. Imported transformToJAXB Java snippet
Imported transformToJAXB Java snippet

The global variable product is changed to base64Binary data type, as shown in Figure 10.

Figure 10. Migrated global variable product.
Migrated global variable product

In the migrated transformToJAXB Java snippet, an SDO object (productDocument) is converted to a JAXB object and stored in a global variable (product) of byte array type, as shown in Figure 11.

Figure 11. Migrated transformToJAXB Java snippet
Migrated transformToJAXB Java snippet

In the case where the complex Java object is being passed across an interface, the associated interface WSDL will need to be modified accordingly (the element type will need to be changed to base64Binary).

The IsItemInStockSubProcess process in the WLI example is imported into IBM BPM as a business process. Its control interface is imported as a WSDL interface.

Table 3. IsItemInStockSubProcess interface
WLI IBM BPM
IsItemInStockSubProcess in WLI exampleIsItemInStockSubProcess in IBM BPM example

The WSDL exported from WLI BEA Workshop or JDeveloper defines the input parameter type for IsItemInStockSubProcess using the full JAXB object type with package name, which is not a valid XSD type in IBM BPM.

The IsItemInStockSubProcess accepts a JAXB object with product information as input.

Figure 12. Imported WSDL interface of the IsItemInStockSubProcess process
Imported WSDL interface of the IsItemInStockSubProcess process

The WSDL XML, shown in Listing 2, shows a non-existent element in the input parameter definition.

Listing 2. Imported WSDL XML of the IsItemInStockSubProcess process
<types>
	<xsd:schema xmlns=”http://www.bea.com/wli/jpd” targetNamespace=”http://www.bea.com/wli/jpd”>
		<xsd:element name=”com.ibm.issw.demo.jaxb.impl.ProductImpl”/>
	</xsd:schema>
</types>

<message name=”SubProcess.isItemInStockSubProcess_clientRequestwithReturnMsg”>
	<part name=”product” element=”jpd:com.ibm.issw.demo.jaxb.imple.ProductImpl”/>
</message>
<message name=”SubProcess.isItemInStockSubProcess_clientReturnMsg”>
	<part name=”parameters” type=”xsd:boolean” />
</message>

The migrated WSDL interface declares the input parameter in the base64Binary schema type, as shown in Figure 13.

Figure 13. Migrated WSDL interface of the IsItemInStockSubProcess process
Migrated WSDL interface of the IsItemInStockSubProcess process

The migrated WSDL, shown in Listing 3, defines the input parameter as base64Binary, a valid XSD type for carrying byte array SDO objects in BPM. The base64Binary is a primitive XSD type, so no additional schema import is required in the IsItemInStockSubProcess WSDL XML.

Listing 3. Migrated WSDL XML of the IsItemInStockSubProcess process
<message name=”SubProcess.isItemInStockSubProcess_clientRequestwithReturnMsg”>
	<part name=”product” type=”xsd:base64Binary”/>
</message>
<message name=”SubProcess.isItemInStockSubProcess_clientReturnMsg”>
	<part name=”parameters” type=”xsd:boolean”/>
</message>

Migrating other XML to Java binding frameworks

Even though XMLBeans are the default data carrier for WLI applications, at times other XML-to-Java binding frameworks, such as JAXB, have been used as the primary data containers. There are many reasons why this replacement is preferred, and they range from compatibility issues to performance deficiencies with XMLBeans to standards compliance. Whatever the reason, typical implementation with a third-party binding framework involves a pattern of from and to conversion between XMLBeans and the third-party binding at key locations. This is similar to the XMLBeans-to-SDO transformations described earlier; therefore similar approaches can be leveraged for migrating these third-party XML-to-Java bindings from WLI to BPM.

We'll illustrate these issues using the popular JAXB binding framework. When dealing with straight Java programming in the WLI flow, or artifacts such as a perform node or a custom control method, any small piece of JAXB code can be converted directly to SDO syntax. This conversion is very similar to the one we did before, changing calls such as getFirstName to get("FirstName").

As before, if the JAXB integration is extensive or if there is a preference to keep and reuse libraries that are written based on manipulating JAXB objects, then our migration utility can convert between JAXB objects and SDO objects. Following is an example of how it is used.

The IsItemInStockSubProcess process in the WLI example initializes some global variables at the start of the process. The imported BPM process performs the same initialization in a Java snippet.

Table 4. IsItemInStockSubProcess process initialization
WLI IBM BPM
IsItemInStockSubProcess initialization in WLI exampleIsItemInStockSubProcess initialization in IBM BPM example

Upon receiving product information, the IsItemInStockSubProcess extracts the product ID and quantity information in preparation for checking stock availability, as shown in Figure 14.

Figure 14. Imported IsItemInStockSubProcess process initialization
Imported IsItemInStockSubProcess process initialization

The original initialization code in WLI uses the JAXB object's get methods to extract the required product and quantity information. If you migrated the snippet by modifying the code to manipulate SDO objects then you just need to change the getters and setters, and the snippet would look like Figure 15.

Figure 15. Migrated IsItemInStockSubProcess process initialization using SDO syntax
Migrated IsItemInStockSubProcess process initialization using SDO syntax

On the other hand, if you wanted to reuse that code, you would just convert the incoming SDO object into a JAXB object, reuse all of the existing code, and then convert the JAXB object to an SDO object. The resulting snippet would then look like Figure 16, where the IBM WLI migration utility is used to perform the SDO to JAXB conversion.

Figure 16. Migrated IsItemInStockSubProcess process initialization using JAXB to/from SDO conversion
Migrated IsItemInStockSubProcess process initialization using JAXB to/from SDO conversion

JAXB objects are just like any other Java objects. That means that on the WLI platform they can be declared as global variables and can be passed as parameters to WLI controls. Regarding global JAXB variables, they can be handled like any other global Java variables as explained in the previous section, Migrating Java types, so we won't discuss them any further in this section. However, with regards to passing JAXB objects through WLI control interfaces or subprocess interfaces, a couple of alternative solutions are available for consideration, as described below.

Web services and processes being invoked in BPM are typically presented as Imports or SCA interfaces. IBM BPM allows data handlers to be defined for Imports and SCA interfaces, and these data handlers are capable of converting incoming data from one format to another. In a migration scenario, it is possible to send a JAXB object as a base64Binary or String SDO as described earlier. The receiving Import or SCA interface can have a custom data handler attached that is able to convert that base64Binary or String to a regular XSD-based SDO object. This results in the web service or process actually receiving a regular SDO object as input. For more information on BPM data handlers,refer to Data format transformation in imports and exports in the IBM BPM Information Center.

Furthermore, since JAXB is a binding between XML and Java, it is XSD-based. That means on the IBM BPM platform, instead of having to convert these objects to byte arrays and declare them as xsd:base64Binary in the WSDL interface as shown in the Migrating Java Types section, you can simply reuse the XSD types of the JAXB objects in your WSDL interfaces.

The IsItemInStockSubProcess process in the WLI example is imported into IBM BPM as a business process. Its control interface is imported as a WSDL interface.

Table 5. IsItemInStockSubProcess interface
WLI IBM BPM
IsItemInStockSubProcess in WLI exampleIsItemInStockSubProcess in IBM BPM example

The IsItemInStockSubProcess accepts a JAXB object with product information as input. The WSDL exported from WLI BEA Workshop or JDeveloper defines the input parameter type for IsItemInStockSubProcess using the full JAXB object type with the package name.

Figure 17. Imported WSDL interface of the IsItemInStockSubProcess process
Imported WSDL interface of the IsItemInStockSubProcess process

The WSDL XML, shown in Listing 4, shows the undefined element in the input parameter definition.

Listing 4. Imported WSDL XML of the IsItemInStockSubProcess process
<types>
	<xsd:schema xmlns=”http://www.bea.com/wli/jpd” targetNamespace=”http://www.bea.com/wli/jpd”>
		<xsd:element name=”com.ibm.issw.demo.jaxb.impl.ProductImpl”/>
	</xsd:schema>
</types>

<message name=”SubProcess.isItemInStockSubProcess_clientRequestwithReturnMsg”>
	<part name=”product” element=”jpd:com.ibm.issw.demo.jaxb.imple.ProductImpl”/>
</message>
<message name=”SubProcess.isItemInStockSubProcess_clientReturnMsg”>
	<part name=”parameters” type=”xsd:boolean” />
</message>

The migrated WSDL defines the input parameter as Product type. This is the same XSD type the JAXB is compiled from. The schema import had to be added to the WSDL for proper reference.

Figure 18. Migrated WSDL interface of the IsItemInStockSubProcess process
Migrated WSDL interface of the IsItemInStockSubProcess process

The migrated WSDL XML where the IsItemInStockSubProcess input parameter is defined uses a type from the same XSD schema used to generate the JAXB object,as shown in Listing 5.

Listing 5. Migrated WSDL XML of the IsItemInStockSubProcess process
<types>
	<xsd:schema>
		<xsd:import
			namespace=”http://DemoAppWLI.migration.issw.ibm.com/DemoApp/Products.xsd” 
			schemaLocation=”../../data/Products.xsd” />
	</xsd:schema>
</types>


<message name=”SubProcess.isItemInStockSubProcess_clientRequestwithReturnMsg”>
	<part element=”prod:Product” name=”product”/>
</message>
<message name=”SubProcess.isItemInStockSubProcess_clientReturnMsg”>
	<part name=”parameters” type=”xsd:boolean”/>
</message>

This is a preferred approach as it provides more visibility into the XML payload during testing; it reduces the need to convert between JAXB, byte array, and SDO objects; and is just a more natural way to handle an XML message.

Also, this removal of the dependency on converting between JAXB, byte array, and SDO objects works exceptionally well in migration scenarios where all or most JAXB codes are being replaced with SDO equivalents. After all, SDO and JAXB are both modern binding frameworks and should have comparable features and performance characteristics, which cannot be said for earlier versions of XMLBeans included with older WLI runtimes.


Conclusions

This article described how to migrate the common data formats and APIs that are used to write business logic in an Oracle WLI business process into the data formats and APIs that are used to write business logic in IBM BPM. It covered the use of XMLBeans, native Java objects, and other binding technologies, such as JAXB. It showed examples of WLI artifacts using those formats and described the changes required to reuse the business logic in an IBM BPM flow.

This article did not cover the migration of WLI data transformations that are used to convert between XML, non-XML, and Java data formats. An example of such a transformation might be created by the JPD Palette or XQuery Mapper in WLI. These kinds of data transformations would be embedded in a WLI transformation control. The migration of transformation controls and related artifacts (DTF, XQ, XSLT) will be covered in Part 3.

This article also did not cover the creation of metadata to describe non-XML data. This is typically done by the Format Builder in WLI, which handles the binding where there is input and output from the flow. This too will be covered in Part 3 as part of migrating the built-in controls (for example, the Database control).


Download

DescriptionNameSize
WLI sample applicationWLIDevWorksDemo.zip15MB

Resources

Comments

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


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Business process management
ArticleID=940678
ArticleTitle=Migrating Oracle WebLogic Integration applications to IBM Business Process Manager Advanced, Part 2: Data transformations
publish-date=08142013