Migrating Oracle WebLogic Integration applications to IBM Business Process Manager Advanced, Part 3: Migrating WLI controls

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® BPM. Part 2 described how to migrate the common data formats and APIs that are used to write business logic in an Oracle WLI business process. Part 3 describes the options available to migrate WLI controls to run on IBM BPM.

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

15 November 2013

Also available in Russian

Introduction

Most business processes require connectivity to enterprise resources, such as databases and file systems. The Oracle WebLogic Integration (WLI) platform uses controls to handle the work of connecting to these enterprise systems, which separates the connectivity logic from the business logic. IBM Business Process Manager (IBM BPM) uses WebSphere adapters to achieve the same abstraction.

As part of the overall migration process described in Part 1, we showed you how to export the BPEL and WSDL files from WLI for a JPD flow and how to import those files into IBM Integration Designer using the BPEL 2.0 importer plug-in. We also discussed WLI customization that we made to the BPEL plug-in to take care of a majority of the transformations required to migrate WLI JPD flows to IBM BPM processes. In this article, we'll describe the tools that are used to migrate Oracle WLI controls to IBM BPM adapters. We'll illustrate how to use these tools by migrating the WLI controls from an example WLI business process. You can download the example WLI process and the migrated BPM process from the WLI demo provided with this article.

There are a number of different kinds of WLI controls in our example WLI business process. The migration approach used depends on the WLI control. Table 1 defines the approaches, the WLI controls, and the tools that are used to migrate them. The steps to apply these tools are described in the following sections.

Table 1. Migration approaches and tools
Migration approach WLI controls Migration tools
External service wizard Database control
JMS control
Email control
File control
BPEL importer plug-in, runtime migration toolkit, external service wizard, BPEL process editor
WLI migration utilities Transformation control
Java control
database control
BPEL importer plug-in, runtime migration toolkit, WLI migration utilities, BPEL process editor
BPEL process editor Process control BPEL importer plug-in, BPEL process editor

Key concepts

This section identifies the key BPM concepts that are used to describe the migration of WLI controls. Understanding these key concepts is essential to the understanding of this article. To learn more about these concepts, see Resources.

Service Component Definition Language
The Service Component Definition Language (SCDL) is used to implement BPM processes. That is, it uses SCDL artifacts (module definitions, service components, imports, exports, and references) to migrate the WLI process into the BPM process.
BPEL process editor
The BPEL process editor is used to create and configure the BPM artifacts that are required to migrate WLI controls. These additional BPM artifacts include assembly diagram, Invoke, Assign, receive, snippet, and business object.
External service wizard
The external service wizard is used to create the WebSphere adapters (and the associated imports, exports, and business objects) for their associated WLI controls.
BPEL importer plug-in
The BPEL importer plug-in is used to import BPEL process definitions (JPDs) into IBM Integration Designer so they can be run on IBM BPM. As part of that import, the plug-in handles WLI proprietary extensions to the BPEL standard.
WLI migration utilities
The WLI migration utilities are used to migrate:
  • JCX (Java Control Extension) to Java objects that can be run on IBM BPM
  • JCS (Java Control Source) to Java objects that can be run on IBM BPM
  • DTF (Data Transformation Files) to Java objects that can be run on IBM BPM
  • XQuery files so that they can be run on BPM
The runtime migration toolkit
The runtime migration toolkit is used to read Java EE resources (such as JMS, JDBC, and Mail) that are required by the WLI controls and to create configuration scripts that can be run on IBM BPM to create equivalent resources required by the BPM adapters.

Migrating WLI controls using the external service wizard

This section shows how to use the external service wizard to convert the WLI database control to a WebSphere adapter so it can be invoked by the BPM process. Some of the other WLI controls that can be migrated using this approach include JMS, Email, and File. See the WLI demo provided for download wih this article for examples of the other controls that can be migrated with this approach.

The WLI database control provides any WLI JPD process connectivity to a JDBC-compatible database. In the downloadable WLI demo application, we use the WLI database control in the main process to retrieve the customer's account balance and to remove funds from his or her account when the order is processed. We also use the WLI database control in the subprocess to retrieve and then update the inventory amount for each product in the order.

Export the BPEL from WLI and import it into BPM using the BPEL importer plug-in

To start the migration of the database control, export the BPEL from WLI and import the BPEL into BPM using the BPEL importer plug-in. This will automatically convert the WLI database control nodes in the JPD process to BPM Invoke activities in the BPM process. Table 2 shows the migration from WLI JPD flow to BPM BPEL process.

Table 2. From WLI JPD flow to BPM BPEL process
Original WLI process flow Migrated BPM process flow
Original WLI Process FlowMigrated BPM process Flow

Migrate the Java EE resources from the WebLogic Server to WebSphere using the runtime migration toolkit

WLI is a set of features built on top of the WebLogic Server. This means many of the Java EE resources like JMS destinations and JDBC data sources that WLI relies upon are maintained within the WebLogic Server domains. To migrate these Java EE resources from WebLogic Server to WebSphere for our WLI demo, we used the runtime migration toolkit.

The runtime migration toolkit is a Eclipse plug-in that you can install onto IBM Integration Designer. Once installed, complete the following steps to migrate the Java EE resources from the WebLogic Server to WebSphere.

  1. Select Migration Tools => WebSphere Application Server Migration => Runtime Migration => WebSphere Runtime Migration Toolkit for WebLogic. This option will be available in Integration Designer after the plug-in is installed.
  2. Select the config.xml from the WebLogic config directory when prompted.
  3. Select the name and location where you want the tool to create a Jython script.
  4. Follow the prompts and select the appropriate JDBC and related resources required for migration.
  5. Select the scope to create the resources. You can select a profile home to search for the cells, clusters, notes, or servers that you want to install the resources to.
  6. Click Finish. The Jython administration script will opne in Integration Designer.
  7. You should see a log in Integration Designer (sometimes in the bottom frame). Be sure to review the messages in the log for instructions on additional things that need to be set, such as passwords.
  8. Finally, execute the following command from <WAS_Profile_HOME>/bin to finish migrating the JDBC resources to the BPM server:
    wsadmin.bat/sh -lang jython -script <script location>

    .

Table 3 shows the resulting JEE resources in WebSphere.

Table 3. JDBC data source related configuration values
Data source
Name WLIDemoDataSource Driver type 4
Scope cell DB name WLIDEMO
Provider DB2 using IBM JCC driver (XA) Server name <db host name>
JNDI jdbc/wliDataSource Port number <db port name>
Auth. alias WLIDemoDBUser
JAAS alias
Name WLIDemoDBUser User ID <db user name>
Password <db user password>

The runtime migration toolkit (provided for download with this article) is capable of migrating a host of configurations to WebSphere besides the JDBC resources (such as JMS, JAAS, and so on).

Create a JDBC import using the external service wizard

For this database control, we'll create a new JDBC Import using the external service wizard. Table 4 shows the migration result.

Table 4. From WLI control to BPM import
Original WLI control artifact Migrated BPM component
WLI database control (.JCX)

WLI database control (.JCX)
BPM Outbound JDBC Import

WLI database control (.JCX)

When the external service wizard finishes, the following artifacts will have been created:

  • Import named JDBCImport.
  • Interface named JDBCImport with four operations:
    • updateBpmadminAccountBG
    • retrieveBpmadminAccountBG
    • updateBpmadminInventoryBG
    • retrieveBpmadminInventoryBG
  • Business objects named:
    • BpmadminAccountBG
    • BpmadminAccount
    • BpmadminInventoryBG
    • BpmadminInventory

Configure a JDBC import module using the BPEL process editor

Before you can use the adapter you must configure a JDBC import module. Detailed instructions for configuring this module are described in the IBM BPM Information Center. The specific values that we used to configure our JDBC import are shown in Table 5.

Table 5. JDBC import configuration values
DialogFieldValue
Locate the Required Files and Libraries Required Libraries db2jcc.jar, db2jcc_license.jar
Specify the Discovery Properties Database Types DB2 UDB, V9.1 – V9.7
Specify the Discovery Properties Database Name WLIDemo
Find Objects in the Enterprise System Discovered Objects BPMADMIN => ACCOUNT, BPMADMIN => INVENTORY
Specify Composite Properties Operations for selected business objects Update, Retrieve
Specify the Service Generation and Deployment Properties Use an existing JAAS alias (recommended Yes => WLIDemoDBUser
Specify the Service Generation and Deployment Properties XA DataSource JNDI Name jdbc/wliDataSource

Now that the WebSphere JDBC import has been configured, you need to modify the BPEL Process component to use it by adding a new reference. To add a new reference to a component complete the following steps:

  1. Select the Process component on the Assembly Diagram, then click New Reference, as shown in Figure 1.
    Figure 1. The Add Reference button appears when the Process component is selected
    The Add Reference button appears when the Process component is selected
  2. This displays the Add Reference dialog. Select the JDBCImport interface is selected from Matching interfaces and change the name of the new reference to WLIDemoDatabase, as shown in Figure 2.
    Figure 2. The Add Reference dialog
    The Add Reference dialog
  3. Once the reference has been added to the Process component, wire it to the JDBCImport, as shown in Figure 3.
    Figure 3. The Process component is wired to the JDBC Import component
    The Process component is wired to the JDBC Import component
  4. A reference partner is required when a BPEL process uses another component. You must add a new reference partner to the BPEL process. To do that:
    1. Open the Process component in the BPEL editor and click the + button to add a new reference partner, as shown in Figure 4.
      Figure 4. Add a new reference partner
      Add a new reference partner
    2. In the Add a Reference Partner dialog, select JDBCImport from the Interfaces list and change the name to WLIDemoDatabase, then click OK.
    Most reference partner usages in BPEL follow the same pattern (see Figure 5), in which an Assign activity is used to populate the business objects that are to be sent to the reference partner. An Assign is a simple mapping of values from one business object to another. After the Assign, an Invoke activity is used to make the call to the reference partner. The Invoke is configured with an interface, operation and business object variables. Once the Invoke is complete, another Assign is used to populate the response values to business objects.
    Figure 5. BPM Assign and Invoke activities
    BPM Assign and Invoke activities
  5. For illustration, we'll show you how to modify the Check-accountBalance Invoke in the BPEL process (Figure 6). Note that the node prior to the Invoke and the node after the Invoke are the Assign activities. To start this process, select the Check-accountBalance Invoke, as shown in Figure 6.
    Figure 6. Select the Invoke to change
    Select the Invoke to change
  6. In the Properties view, select the Details tab, then Browse to change the Partner to WLIDemoDatabase. Then select the retreiveBpmadminAccountBG operation from the Operation drop-down list and click Browse to select the Request variable.
  7. In the Select Request Variable dialog, click New and enter selectAccountName as the variable name, then click OK.
  8. In the Select Request Variable dialog, click OK again.
  9. Repeat the previous steps to create a new variable with the name responseAccountVariable for the Response variable.

The Invoke properties should now look like Figure 7.

Figure 7. The modified Invoke properties
The modified Invoke properties

The next step is to change the Assign nodes to use the new variables. As mentioned before, there is typically one Assign node before an Invoke node and one Assign node after the Invoke node. In the example process, the obj_obj2input.accountNumber Assign node is before the Invoke and will be changed first. This assignment populates the request data that is sent to the Invoke.

  1. Select the obj_obj2input.accountNumber assignment as shown in Figure 8.
    Figure 8. The pre-Invoke assignment
    The pre-Invoke assignment
  2. In the Properties view, select the Details tab and modify the Assigned To part of the assignment to selectAccountTable => retrieveBpmadminAccountBGParameters => retrieveBpmadminAccountBGInput/BpmAdminAccount/accountnumber, as shown in Figure 9 This element of the business object created along with the JDBC Import corresponds to the ACCOUNTNUMBER column of the Account table in the WLIDemo database.
    Figure 9. The modified assignment
    The modified assignment

    Click to see larger image

    Figure 9. The modified assignment

    The modified assignment
  3. Now, select the output.parameters2fundsAvailable Assign, which is after the Invoke and deals with the response message, as shown in Figure 10.
    Figure 10. The post-Invoke assignment
    The post-Invoke assignment
  4. In the Properties view, select the Details tab and modify the Assigned From part of the assignment to responseAccountTable => retrieveBpmadminAccountBGResult => retrieveBpmadminAccountBGOutput/BpmadminAccount/balance. This element of the business object created along with the JDBC Import corresponds to the BALANCE column of the Account table in the WLIDemo database, as shown in Figure 11.
    Figure 11. The modified assignment
    The modified assignment

    Click to see larger image

    Figure 11. The modified assignment

    The modified assignment
  5. Save your changes.

The above steps illustrate the migration of a WLI database control to a BPM outbound JDBC import. There are also inbound JDBC exports in BPM that can process database events and trigger business processes accordingly. In our WLI demo, we also created custom business objects and maps for reading and writing relational tables. Finally, the Properties tab for the BPM JDBC import contains many options regarding bindings, transactions, security, and so on, that may be changed to match the original WLI implementation.

For our WLI demo application, we also used the external service wizard to migrate the JMS, email, and file controls. The process for migrating these controls closely follows the above steps for the database control. In some cases, instead of creating new WSDL interfaces as we did when creating the JDBC adapter, it may be possible to reuse the existing WSDL interfaces that were exported from WLI. Such cases will require updating existing references for a process rather than adding a new reference and partner link.

Also, for all WLI controls in our WLI demo migrated using the external service wizard, we elected to use default or predefined business objects for our migrated interfaces. In a scenario where complex data types are used, it is possible and perhaps even recommended to create custom business objects. Details of how to implement custom business objects for WebSphere adapters are documented in the respective adapter sections of the IBM BPM Information Center. See Resources for specific links. For a complete list of WLI controls that can be migrated using the external service wizard, refer to Table 11.


Migrating WLI controls using the migration utilities

This section shows how to use the WLI migration utility to convert the WLI database control to a Java SCA component so that it can be invoked from the BPM process. The resulting Java SCA component will use Java SE JDBC APIs to connect and query the databases. This conversion of the WLI database control to the BPM Java SCA component is automated by the WLI migration utility. The other steps involved in this approach are similar to migrating the WLI database control via the external service wizard. Some of the differences seen in this approach are because this approach modifies rather than creates new interfaces and components. This approach also creates a "mapper" component. This approach is generally quicker. Some other WLI controls that can be migrated using this approach include the transformation control and the Java control. See the WLI demo provided for download with this article for examples of these other controls that can be migrated using this approach.

Export the BPEL from WLI and import it into BPM using the BPEL importer plug-in

Use the BPEL importer plug-in import BPEL into BPM as described in Export the BPEL from WLI and import it into BPM using the BPEL importer plug-in.

Migrate the Java EE resources from the WebLogic Server to WebSphere using the runtime migration toolkit

Use the runtime migration toolkit to create JEE resources in BPM as described in Migrate the Java EE resources from the WebLogic Server to WebSphere using the runtime migration toolkit.

Convert the database control to a BPM component using the WLI migration utility

The WLI migration utility provides a simple operation to convert the WLI database control (.jcx) for use by BPM. The result of the WLI migration utility is a set of Java classes that can be used to create BPM Java SCA components, as shown in Table 6.

Table 6. From WLI control to BPM SCA component
Original WLI control artifactMigrated BPM components
WLI database control (.JCX)

WLI database control (.JCX)
Converted Database SCA (.Java)

Converted Database SCA (.Java)

To convert the database control (.jcx), execute the WLI migration utility and provide the path to the directory containing the .jcx file as follows:

java.exe -classpath <required_libs> -jar <WLIMigrationUtils>.jar JDBC2JAVA DB

When the WLI migration utility finishes, the following artifacts will have been created:

  • A Java implementation of the database control, DB_AccountSCAImpl.java
  • A Java interface named DB_AccountSCA.java with the operations:
    • checkAvailableFunds
    • removeFunds
    • isItemInStock
    • removeProductFromStock
  • The original WLI control file, DB_Account.jcx

Create the Java SCA component using the BPEL process editor

You can use the migrated Java classes generated by the WLI migration utility in the previous step to create Java SCA components, as shown in Table 7.

Table 7. From WLI control to BPM SCA component
Original WLI control artifactMigrated BPM components
WLI database control (.JCX)

WLI database control (.JCX)WLI database control (.JCX)
Database Java SCA Component in BPM

Database Java SCA Component in BPM

Database Java SCA Mapper Component in BPM

Database Java SCA Mapper Component in BPM

The next step is to create the Java SCA component by opening the BPEL process editor and dragging the converted DB_AccountSCAImpl Java object onto the assembly diagram, as shown in Figure 12.

Figure 12. Converted JDBC SCA (.Java)
Converted JDBC SCA (.Java)

When the WSDL to Java Mapper Facade dialog displays, click Yes to create the mapper. The mapper is used for mapping between the SCA business objects used by the BPEL process, and the Java types used by DBAccountsSCAImpl. As a result, the DB_AccountSCAImpl Java SCA component and the DB_AccountSCAmapper Java SCA component are placed onto the Assembly Diagram and connected, as shown in Figure 13.

Figure 13. Converted JDBC SCA (.Java) and Mapper component
Converted JDBC SCA (.Java) and Mapper component

The WSDL to Java Mapper Facade creation functionality of the BPEL process editor then generates a WSDL interface according to the signatures of DB_AccountSCAImpl's Java operations. This WSDL interface provides an interface between the BPEL process and the Java SCA implementation of this WLI control.

Because of the way WLI exports WSDLs for the WLI controls, the WLI DB_Account interface will be split between two different WSDLs, one for the operations used by each JPD process (Figure 14 and Figure 15). To prevent namespace and port type clashes, we'll merge the operations in these two WSDLs into the generated mapper WSDL (Figure 16).

Figure 14 and Figure 15 show the WLI exported JPD control WSDLs:

Figure 14. DB.DB_AccountPT interface operations in the pprocess JPD's control WSDL (Process_ctrl.wsdl)
DB.DB_AccountPT interface operations in the pprocess JPD's control WSDL (Process_ctrl.wsdl)
Figure 15. DB.DB_AccountPT interface operations in the isItemInStockSubProcess JPD's control WSDL (isItemInStockSubProcess_ctrl.wsdl)
DB.DB_AccountPT interface operations in the isItemInStockSubProcess JPD's control WSDL (isItemInStockSubProcess_ctrl.wsdl)

Figure 16 shows the updated generated mapper interface WSDL:

Figure 16. Updated generated mapper interface WSDL
Updated generated mapper interface WSDL

The DB_AccountSCAmapper (Figure 16) leverages simple types for all of its operation parameters, so there are no source code changes required to the mapper. If more complex types were used by the WSDL operations, you would have to modify the mapper's implementations to convert between the SDO DataObject received by the mapper and the actual complex Java types expected by the DB_AccountSCAImpl implementation.

The next step is to update the DB_Account reference for the main process. This reference was imported when the WLI JPD BPEL was initially imported by the BPEL importer plug-in. The problem is that the DB_AccountReference references the DB.DB_AccountPT interface, which is no longer valid for our demo. Instead, it should point to the DB.DB_AccountSCA interface that has the merged operations. To change the DB_AccountReference to point to the right interface, do the following:

  1. Select the main process on the Assembly Diagram and view the Details section in the Properties tab.
  2. Expand References => DB_Account and select the DB.DB_AccountPT interface.
  3. In the Details tab on the right, click Change to change the interface from DB.DB_AccountPT to DB_AccountSCA.

The result is shown in Figure 17. Since isItemInStockSubProcess is also utilized the WLI database control, you need to make the same changes to its reference.

Figure 17. Updated DB_Account reference interface
Updated DB_Account reference interface

Once the references for the BPEL processes are updated to match the interface for the DB_AccountSCAmapper, they can now be properly wired together. On the assembly diagram, right-click the DB_AccountSCAmapper and select Wire to existing to wire the process reference to the mapper interface. Since the process's DB_Account reference has been updated to leverage the new mapper interface on the assembly diagram, you also need to update the existing DB_Account reference partner in the implementation of the BPEL process to point to the correct interface. To do this, on the assembly diagram, right-click on the main process and select to implementation under Synchronize Interfaces and References. This moves the reference interface change into the process implementation. Repeat the same steps for the isItemInStockSubProcess. Figure 18 shows the results, which would be the same for both BPEL processes in our WLI demo.

Figure 18. Updated DB_Account reference partner with the new DB_AccountSCA mapper interface
Updated DB_Account reference partner with the new DB_AccountSCA mapper interface

Since the new DB_AccountSCAmapper is exposing a new interface, any of the the Invokes that call the methods of that WSDL also need to be updated. Figure 19 shows one such Invoke of the checkAvailableFunds method.

Figure 19. Java SCA reference partner Invoke properties details
Java SCA reference partner Invoke properties details

As mentioned earlier, there is generally an Assign prior to the Invoke and an Assign after the Invoke. These Assigns also need to be modified. The example Invoke and its related Assigns are shown in Figure 20.

Figure 20. Java SCA Invoke activity and request /response assignments
Java SCA Invoke activity and request /response assignments

To make these changes, start with the Invoke request and response by selecting the correct data type for the local input and output variables. Table 8 shows the resulting variable types.

Table 8. Input & Output Variable Types
Variable: Input Variable: Output
InterfaceDB_AccountSCAInterfaceDB_AccountSCA
Operation checkAvailableFunds Operation checkAvailableFunds
Direction Input Direction Input

Finally, correct the Assign for the newly entered input request and output response variables. Table 9 shows the resulting assignments:

Table 9. Request & Response Assignments
Assign: AssignCheckAcctBalanaceInput Assign: AssignCheckAcctBalanaceOutput
FromaccountNumFrom output.parameters.checkAvailableFundsReturn
To Input.parameters.accountNumber To fundsAvailable

The steps above illustrate the migration of a WLI database control to a BPM Java SCA component using the WLI migration utility. For our WLI demo, we also used the WLI migration utility to migrate the transformation and custom Java controls. The process for migrating these controls closely follows the previous steps for the Database control. However, there can be some differences.

In cases where complex Java types are used in the interface operations (such as XMLBeans, JAXB objects, exceptions, and so on), the WSDL to Java Mapper Facade of the BPEL process editor may generate WSDL and Java that requires some changes. For example, operation input parameters of complex types may end up being typed as java.lang.Object and declared as xsd:anyType in the mapper WSDL.

In such cases, it can be very effective to simply replace the WSDL interface of the SCA mapper component with the original WSDL interfaces of the WLI controls that were exported along with the JPD BPELs. These existing interfaces usually have the correct XSD types defined for each of the operations. The reuse of existing interfaces also minimizes the impact to the reference partners and Invoke activities in the BPM BPEL process implementation. This replacement may cause the operations' parameter types between the mapper WSDL and the mapper Java implementation to become misaligned and will, therefore, require them to be synchronized. Additional source code modification may be needed to ensure the data type conversion in the mapper's Java implementation functions correctly.


Migrating WLI controls using the BPEL process editor

This section shows how to use the BPEL process editor to convert the WLI process control to a BPM Invoke activity. This is the only control that uses this approach in our WLI demo. See Conclusion for other controls that can use this approach.

The WLI process control provides any WLI JPD process access to another JPD process or subprocess. In our WLI demo, the main JPD process executes the isItemInStockSubProcess JPD process to check item availability and update stock quantity. A process control is created for the isItemInStockSubProcess JPD and the main JPD process invokes it using a process control Send node.

In the BPM world, this association is significantly simplified by the reference partner concept. The isItemInStockSubProcess in BPM will have a WSDL interface defined. The main process will have a reference partner defined for the isItemInStockSubProcess WSDL interface, and it can be invoked using a standard BPEL Invoke activity.

Import the BPEL into IBM BPM using the BPEL importer plug-in

When each WLI JPD process is exported from WLI as JPD BPEL, it comes with a pair of WSDLs, one of which contains the WSDL interface definitions for that JPD process. When the JPD BPEL is imported into Integration Designer using the BPEL 2.0 importer plug-in, the WSDLs are also imported. Therefore, the interface for a subprocess such as the isItemInStockSubProcess is readily defined and available for use, as shown in Table 10.

Table 10. From WLI JPD Flow to BPM BPEL Process
Original WLI process flowMigrated BPM process
WLI database control (.JCX)

WLI database control (.JCX)
WLI database control (.JCX)

WLI database control (.JCX)

Correct WSDL Interfaces using the BPEL process editor

Due to some inherent differences between the WLI and IBM BPM platform, some corrections to the imported WSDLs and the main orocess BPEL may be needed before they will function properly. Specifically, the WSDL interface for the isItemInStockSubProcess JPD requires some correction. The exported WSDL contains incorrect schema locations, undefined types, and WLI proprietary attributes, so you'll need to fix those WSDLs to be consistent with the original WLI Java interface. Below are some before and after comparisons of the isItemInStockSubProcess interface.

Listing 1 shows the original WLI process interface in Java interface format.

Listing 1. Original WLI Java interface
public interface isItemInStockSubProcessPControl extends 
com.bea.control.ProcessControl, com.bea.control.ControlExtension
{
    public boolean clientRequestwithReturn(com.bea.xml.XmlObject product);
}

Figure 21 shows the migrated WLI process interface as BPM WSDL (SubProcess.isItemInStockSubProcessPT port type in isItemInStockSubProcess.wsdl) after initial import using the BPEL importer plug-in.

Figure 21. SubProcess.isItemInStockSubProcessPT partner interface in BPM before correction
SubProcess.isItemInStockSubProcessPT partner interface in BPM before correction

Figure 22 shows the migrated WLI process interface as BPM WSDL after corrections.

Figure 22. SubProcess.isItemInStockSubProcessPT partner interface in BPM after correction

After correcting the WSDL, the only modification needed is to Assign the correct request and response variable to the Invoke. For this Invoke, we've elected to Use data type variables mapping to ensure proper XML namespace transfer. After checking that option, simply select the appropriate "read from" and "store into" variables for the Invoke's input and output. These "read from" and "store into" variables should already exist. As described earlier, there is typically an Assign activity before and after the Invoke. However, with using the variable mapping option, these Assign activities can be ignored unless there are errors.

Figure 23. Updated IsItemInStockSubProcess Invoke
Updated IsItemInStockSubProcess Invoke

Conclusion

This article described the approaches available for migrating WLI controls to IBM BPM. It covered the use of the external service wizard to configure the WebSphere JDBC adapter as a replacement for the WLI database control. It also described how to use the WLI migration utility to convert the WLI database control to a Java SCA component and how to use the BPEL process editor to migrate the WLI process control to a BPEL Invoke activity.

Although there are many WLI controls, most of the commonly used ones can be migrated using the approaches described by this article. However, there are a few WLI controls that are not being covered by this article. For those controls, we provide some suggestions for how to migrate them to IBM BPM in Table 11.

Table 11. Migration approaches for WLI controls
WLI control Description Migration approach
AquaLogic Service Bus control Provides connectivity to AquaLogic Service Bus Not currently supported
Database control Integrates with databases using JDBC External service wizard or WLI migration utility
Dynamic transformation control Provides a business process with the ability to dynamically select which transformation is invoked at runtime WLI migration utility
ebXML control This control supports ebXML 1.0 and 2.0 B2B messaging services ebXML messaging services are provided by the IBM Sterling® B2B products
EJB control Integrates with existing EJBs
Email control Allows a business process to send emails External service wizard
File control The file control can read, write and append to a file on the file system External service wizard
Http control Enables a business process to send an HTTP or HTTPS request to a URL and receive the appropriate HTTP response header and body data BPEL process editor
Java control Custom reuseable components. Not currently supported
JMS control Enables a business process to send and receive JMS messages BPEL process editor
Message Broker controls Provide JMS publish and subscribe capabilities BPEL process editor
MQSeries control Enables a business process to send and receive messages using WebSphere MQ BPEL process editor
Process control Integrates with other business processes Not currently supported
RosettaNet control Sends and Receives RosettaNet B2B messages RosettaNet messaging services are provided by the Sterling B2B products.
Service roker control A dynamic version of the web service control BPEL process editor
Timer control Notifies the business process when a specified period of time has elapsed BPEL process editor
TPM control Provides an interface to the Trading Partner Manager database to extract Trading Partner data. Not currently supported
Web service control Used to connect to a web service using a WSDL file BPEL process editor
WLI JMS control Similar to the JMS control with some additional features BPEL process editor
WLI timer control An extension of the timer control BPEL process editor
Worklist controls Enables the automated manipulation, creation, and management of tasks Not currently supported
XML MetaData Cache control Integrates with the WLI XML MetaData Cache Not currently supported

Downloads

DescriptionNameSize
WLI workspace for demo applicationWLIDevWorksDemo.zip14MB
Migrated demo app with SCA JDBC clientWLIDemoApp_BPM_JDBC_SCA_MIGR_UTIL.zip21MB
Migrated demo app with BPM JDBC adapterWLIDemoApp_BPM_JDBC_BPM_Adapter.zip28MB

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=952575
ArticleTitle=Migrating Oracle WebLogic Integration applications to IBM Business Process Manager Advanced, Part 3: Migrating WLI controls
publish-date=11152013