Integration Developer Version 7.0 Version 7 Release 0. Migration Guide

Transcription

1 Integration Developer Version 7.0 Version 7 Release 0 Migration Guide

2 Note Before using this information and the product it supports, read the information in Notices on page 117. This edition applies to version 7, release 0, of WebSphere Integration Developer. Copyright IBM Corporation 2005, US Government Users Restricted Rights Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

3 Contents Chapter 1. Migrating to WebSphere Integration Developer Chapter 2. Migrating from previous versions of WebSphere Integration Developer Migrating source artifacts Migrating a process instance Migrating XML maps Migrating generated JEE staging projects Migrating server runtime targets Considerations for the version to version migration process Chapter 3. Migrating to WebSphere Process Server from WebSphere InterChange Server Supported migration paths Preparing for migration from WebSphere InterChange Server Considerations for the WebSphere InterChange Server migration process Considerations: General development Considerations: Common code utilities Considerations: Database connection pools Considerations: Business objects Considerations: Collaboration templates Considerations: Maps Considerations: Relationships Considerations: Access framework clients Considerations: Preventing database collisions.. 17 Considerations: Post-migration WebSphere InterChange Server migration scenarios 18 Migrating WebSphere InterChange Server artifacts using the Migration wizard Verifying the WebSphere InterChange Server migration Working with migration failures from WebSphere InterChange Server WebSphere InterChange Server and WebSphere Business Integration Server Express artifacts handled by the migration tools Supported WebSphere InterChange Server APIs.. 28 Mapping the WebSphere Process Sever DataObject from WebSphere InterChange Server XML Chapter 4. Migrating to WebSphere Integration Developer from WebSphere MQ Workflow Preparing for migration from WebSphere MQ Workflow Migrating WebSphere MQ Workflow using the Migration wizard Optimizing the migrated business processes.. 55 Verifying the WebSphere MQ Workflow migration 57 Limitations of the migration process (from WebSphere MQ Workflow) Chapter 5. Migrating from WebSphere Studio Application Developer Integration Edition Supported migration paths for migrating source artifacts Preparing source artifacts for migration Pre-migration considerations Migrating workspaces using the WebSphere Integration Developer Migration wizard Migrating workspaces using WSADIEWorkspaceMigration Additional migration information Creating SCA Components and SCA Imports for the services in the application for rewiring Migrating a Java service Creating the custom Java component: option Creating a Java Web service: option Advantages and disadvantages for each of the Java service rewiring options Migrating an EJB service Creating the custom EJB component: option Creating an EJB Web service: option Advantages and disadvantages for each of the EJB service rewiring options Migrating a Business Process to Business Process Service Invocation Migrating a Web Service (SOAP/JMS) Migrating a Web Service (SOAP/HTTP) Migrating a JMS service Migrating a J2C-IMS service Creating an SCA Import to invoke the IMS service: option Creating a Web service around the J2C service: option Advantages and disadvantages for each of the J2C-IMS service rewiring options Migrating a J2C-CICS ECI service Migrating a J2C-CICS EPI service Migrating a J2C-HOD service Migrating a transformer service The consumption scenario for service migration Creating SCA Exports to access the migrated service Migrating the EJB and the EJB process bindings Migration option 1 for the EJB and EJB process binding Copyright IBM Corp. 2005, 2009 iii

4 Migration option 2 for the EJB and EJB process binding Migration option 3 for the EJB and EJB process binding Migration option 4 for the EJB and EJB process binding Migrating the JMS and the JMS process bindings Migration option 1 for the JMS and JMS process binding Migration option 2 for the JMS and JMS process binding Migration option 3 for the JMS and JMS process binding Migration option 4 for the JMS and JMS process binding Migration option 5 for the JMS and JMS process binding Migrating the IBM Web Service binding (SOAP/JMS) Migration option 1 for the IBM Web Service binding (SOAP/JMS) Migration option 2 for the IBM Web Service binding (SOAP/JMS) Migrating the IBM Web Service binding (SOAP/HTTP) Migration option 1 for the IBM Web Service (SOAP/HTTP) binding Migration option 2 for the IBM Web Service (SOAP/HTTP) binding Migrating the Apache Web Service binding (SOAP/HTTP) Migrating to the SCA programming model Migrating WSIFMessage API calls to SDO APIs Migrating WebSphere Business Integration Server Foundation client code Migrating the EJB client Migrating the EJB process binding client.. 99 Migrating the IBM Web Service (SOAP/JMS) client Migrating the IBM Web Service (SOAP/HTTP) client Migrating the Apache Web Service (SOAP/HTTP) client Migrating the JMS client Migrating the business process choreographer generic EJB API client Migrating the business process choreographer generic Messaging API client and the JMS process binding client. 102 Migrating the business process choreographer Web client Migrating WebSphere Business Integration Server Foundation BPEL Java snippets Migrating interactions with WebSphere Business Integration Adapters Migrating WSDL interfaces that have SOAP-encoded array types Migrating WebSphere Business Integration EJB projects Manually deleting 5.1 Web Services Invocation Framework (WSIF) definitions Verifying the source artifact migration Working with source artifact migration failures Limitations of source artifact migration Notices Terms of use iv WebSphere Integration Developer: Migration Guide

5 Chapter 1. Migrating to WebSphere Integration Developer Migrating allows you to move from one product to another or one version of a product to another while preserving configuration information and user applications. WebSphere Integration Developer provides the necessary tools to migrate an existing environment to the new version 7.0 environment. The following topics describe concepts, reference information, and step-by-step instructions for migrating to WebSphere Integration Developer: Copyright IBM Corp. 2005,

6 2 WebSphere Integration Developer: Migration Guide

7 Chapter 2. Migrating from previous versions of WebSphere Integration Developer You can migrate from a previous version of WebSphere Integration Developer to WebSphere Integration Developer 7.0. This is referred to as version-to-version migration. Migrating to WebSphere Integration Developer 7.0 preserves the basic structure of your existing application with minimal required reconfiguration. The following topics provide further guidance on the WebSphere Integration Developer version-to-version migration process: Migrating source artifacts WebSphere Integration Developer source artifact migration refers to the process of importing a project interchange (PI) created from an older version of WebSphere Integration Developer into a newer version of WebSphere Integration Developer. To migrate WebSphere Integration Developer source artifacts, follow these steps: 1. Export the artifacts as integration modules by selecting File > Export > Business Integration > Integration modules and libraries. 2. From the Export Integration Modules and Libraries window, select the option Project interchange for sharing between workspaces and select the projects to export: Click Next. 3. From this window, specify the file names for each archive and the target directory: Copyright IBM Corp. 2005,

8 Click Finish. 4. Next you will need to import the zip file generated in the above steps as a project interchange file. To import a project interchange file, select File > Import > Other > Project Interchange and click Next. 5. Click Browse to select the zip file and click Finish. By default, the projects are set to build automatically. Therefore, after the project interchange is imported, the build, including the validation, begins automatically. 6. The Workspace Migration wizard opens after the project interchange file is imported: 7. After the migration process ends, you should see a dialog indicating that the migration validation has completed successfully: To see more details about the validation, you can go to the Migration Results view: 4 WebSphere Integration Developer: Migration Guide

9 Migrating a process instance Migrating a WebSphere Business Modeler business process involves migrating a process instance. In WebSphere Business Modeler V , the WebSphere Integration Developer export wizard provides an option to enable BPEL process versioning. The Enable generated BPEL for process versioning check box is available on the WebSphere Integration Developer export details page in the WebSphere Integration Developer export wizard: This option allows the generated BPEL to leverage the process versioning support and enablement for process instance migration in WebSphere Integration Developer and WebSphere Process Server. Chapter 2. Migrating from previous versions of WebSphere Integration Developer 5

10 Important: When selecting this option, ensure the targets are WebSphere Integration Developer or later and WebSphere Process Server or later. Otherwise, the generated BPEL definition from WebSphere Business Modeler will produce a validation error upon import to WebSphere Integration Developer and therefore will not be deployable to WebSphere Process Server. For more information on instance migration, see the topic "Creating a new version of your process - migrate running instances" in the related links sections below. Migrating XML maps The underlying structure of xml maps has changed between releases of WebSphere Integration Developer. Use the migration wizard or the quick fix feature to migrate your maps to the current version. XML maps that were created in versions of WebSphere Integration Developer prior to version need to be migrated to the current version for the following reasons: v Maps that were created in versions 6.0.x and have a file extension of.xmx must be migrated to the current version to allow you to edit them or if you want to run them in the lazy business object parsing mode. v Maps that were created in versions prior to and have the file extension of.map must be migrated to the current version if you want to run them in the lazy business object parsing mode. When you import existing maps from previous versions into WebSphere Integration Developer version , the older maps are detected and a migration wizard is launched to help you migrate the maps to the current version. The migration wizard handles the migration for both situations described above, and once migration is completed no further action is required. For the maps that have the extension of.xmx, the.xmx files will be deleted and a.map file will be created for each.xmx file. For the maps that have the extension of.map, the existing.map files will be updated. If you choose to exit the wizard and migrate the maps at a later time, you can launch the wizard by invoking the Run workspace migration action from within the Migration Results view. Note: Note: If the Migration Results view is not visible, you can bring it into perspective by selecting Window from the main menu and choosing Show view > Other. Then, from the Show View page, select the Migration Results view. If you do not migrate the maps using the migration wizard, and you choose to use the Configure Business Object Parsing Mode option to set the business object parsing mode of a module or library to lazy, the associated older maps will be automatically migrated for you during this action. However, if you manually change the business object parsing mode to lazy by editing the properties of the module or library, older maps will not be migrated automatically and you will see errors in the problems view for the associated older maps. When you see such errors in the problems view for.xmx or.map files, use the quick fix function to migrate the maps as follows: 1. Right click the error message and select Quick Fix. 2. Optionally choose to migrate all the maps, and click Finish. Migrating generated JEE staging projects When you import a project interchange file that contains modules from a previous version of WebSphere Integration Developer, a migration wizard is automatically launched. If the project interchange file contains any generated J2EE staging projects (such as EJB, Web, or App projects), the migration wizard will contain a wizard page to help you migrate the projects. 6 WebSphere Integration Developer: Migration Guide

11 When you are preparing modules for migration to a later version of WebSphere Integration Developer, it is recommended that you do not include any custom artifacts in the generated JEE staging projects. If you adhere to the recommendation, you do not need to include any generated JEE staging projects in your project interchange file. If your imported project interchange file contains any generated JEE staging projects, they will be automatically deleted and regenerated again during the migration process. (If your project interchange file does not contain any generated JEE staging projects, any required JEE staging projects will be automatically generated during migration.) 1. Import the project interchange file that contains your modules and JEE staging projects. The Workspace Migration wizard opens to the Workspace Migration page. 2. Click Next. The Review the JEE Staging Projects page opens. 3. In the Review the JEE Staging Projects page, review the list of JEE staging projects in the tree area. 4. Complete one of the following steps: v If your JEE staging projects do not contain any custom artifacts or if they contain custom artifacts that can be safely deleted along with the JEE projects because they exist elsewhere (such as a repository), click Next to continue the migration process. v If your JEE staging projects contain any custom artifacts that do not exist elsewhere (such as a repository), click Cancel to exit the wizard and save the custom artifacts to another location, then switch to the Migration Results view and click the Run Migration icon to continue the migration process. Any required JEE projects are automatically generated again except for EJB staging projects, which are no longer required by modules in WebSphere Integration Developer. Migrating server runtime targets When you import a project interchange file that contains modules from a previous version of WebSphere Integration Developer, a migration wizard is automatically launched. If the project interchange file contains any projects that target a previous version of the server runtime, the migration wizard will contain a wizard page that enables you to automatically update the projects to target the current server runtime. It is generally recommended that you accept the default settings in the migration wizard to ensure that the correct server runtimes are targeted by your projects. Any projects that target the WebSphere Process Server runtime will be updated to target the latest version of WebSphere Process Server. Similarly, any projects that target the WebSphere ESB server runtime will be updated to target the latest version of WebSphere ESB server. 1. Import the project interchange file that contains your modules. The Workspace Migration wizard opens to the Workspace Migration page. 2. Click Next until the Undefined Server Runtime page of the wizard is displayed. 3. In the Undefined Server Runtime page, review the information that is displayed on the page. 4. Accept the default settings and click Next to continue the migration process. Considerations for the version to version migration process When migrating from a previous version of WebSphere Integration Developer to version 7.0, most of the migration is done automatically. However, there are a number of considerations to be aware of that may require additional manual configuration. The following considerations are intended to assist in the version-to-version migration process: Validations With each new release of WebSphere Integration Developer, validators for various components, Chapter 2. Migrating from previous versions of WebSphere Integration Developer 7

12 such as business objects, human tasks, and XSLT maps are improved. Note that after importing the artifacts to a newer version of WebSphere Integration Developer, there may be validation errors that the previous validator did not catch. Java validation When using SDO API to create a data object, there is added Java validation in WebSphere Integration Developer: v v v It validates if a business object of the given namespace and name exists. If it is invalid, you will receive the following error message in the Problems view: A BO with namespace <namespace> and name <BO name> cannot be found. It validates if the correct getter and setter methods are used based on the attribute type. If not, you will receive the following error message in the Problems view: Incompatible method argument type. The <BO attribute name> field is of type <actual attribute type>. It validates if the attribute referenced in the getter and setter methods exists. If not, you will receive the following error message in the Problems view: The field <BO attribute name> does not exist in the Business Object <BO name with namespace>. Java validation occurs in: v Java components v Custom mediation primitive in mediation flows v Java snippet activities in business processes v Custom mappings in business object maps Quick Fix In some cases, you can use the Quick Fix to fix the problem. Go to the Problems view, right-click on the error or warning and check if Quick Fix is enabled. It usually helps to change the artifacts compliant to the validators more quickly: SDO programming tips From WebSphere Integration Developer 6.0.x to WebSphere Integration Developer 6.1, there are package name changes for a few classes, such as BOXMLSerializer, which may cause compilation errors. It is a good practice not to reference those classes directly, but to use Service Manager to locate the service. From: com.ibm.websphere.bo.boxmlserializer serializer = new com.ibm.websphere.bo.impl.boxmlserializerimpl(); To: com.ibm.websphere.sca.servicemanager srvmgr = com.ibm.websphere.sca.servicemanager.instance; com.ibm.websphere.bo.boxmlserializer serializer = (BOXMLSerializer) srvmgr.locateservice("com/ibm/websphere/bo/boxmlserializer"); For more examples, see the WebSphere Process Server Information Center and the BPC samples and tutorials ( 8 WebSphere Integration Developer: Migration Guide

13 Circular dependencies A newer version of WebSphere Integration Developer might detect circular dependencies of the modules or projects as errors, while an older WebSphere Integration Developer does not. To quickly resolve this issue, you can change the compiler option from the Preferences. Go to Windows > Preference > Java > Compiler > Building. Under the build path problems section, select the Warning option for Circular dependencies: Depending on the version of WebSphere Integration Developer that you are using, the Java preference might not be available. To enable that, go to the Java perspective and open the preference dialog again. Although the applications might be running fine, it is necessary to check the project dependencies again. Use refactoring If you need to change the name of a component or it's target namespace because they are invalid, use the refactoring capabilities instead of simply changing it in one place. If you do not use refactoring, you may encounter problems as the name or target namespace of a component might be referenced by other artifacts. Refactoring those values would preserve the relationships. For example, a namespace must be an absolute Uniform Resource Identifier, for example, starting with You should refactor the target namespace by pressing Alt+Shift+R on the target namespace field of the Properties page. XPath XPath can be used in mediation flows (for example, MessageFilter primitive) and business processes (for example, Assign activity). Prior to version 6.1, WebSphere Integration Developer did not have distinction between business object attributes defined as xsd:element and those defined as xsd:attribute. If XPATH is used, you may see the following message after migrating: The <attribute_name> schema element was not found in the <xpath_expression> XPATH. To fix this error, put symbol in front of the attribute name, or reselect the XPATH in the XPATH Expression Builder. For example, there is a business object called MyBO which has an attribute myattribute defined as xsd:attribute. The XPATH expression created in 6.0x is: /MyBO/myAttribute Then change it to: /MyBO/@myAttribute Component-specific considerations Business object map For WebSphere Integration Developer or after, if you have mappings that include an inherited type, you may receive the following warning message: CWLAT0064W: The 4 transform includes an inherited type, which might produce unwanted side effects when the map runs. Business object maps can work on generalizations of types, this warning is raised to indicate that the transform will still execute even if the inherited type comes in as part of the instance document. This becomes more of a concern when mapping elements are involved in a substitution group. Typically, if the element is not involved in a substitution group, you do not need to be concerned about the warning. XSLT mapper There was a major change in XSLT mapper for WebSphere Integration Developer 6.1. It can easily be identified from the file extension whether the maps are created prior to version 6.1. The file extension of the old 6.0.x XSLT map files is.xmx, and that of the new ones is.map. Chapter 2. Migrating from previous versions of WebSphere Integration Developer 9

14 If XSLT map files are created using 6.0.x, it continues to work in 6.1 or after. Therefore, WebSphere Integration Developer does not migrate those files automatically, and migration is not mandatory, however, the maps need to be migrated for further enhancement. In addition, it is highly recommended to migrate the old.xmx files to benefit from the performance improvement in the new XSLT map architecture. To migrate the XSLT maps, double click the file which will open the mapping migrator editor. Follow the steps in the Steps section as shown here: To optimize the process, note the following: v This mapping migrator discovers all the old map files (.xmx files) in the workspace. You can select to migrate them all at once. v Before launching the migrator, disable the automatic build. During the migration there are lots of file changes which kick off auto-build frequently. Disabling it will make shorten the migration time. After the mapping migration, enable the auto-build again. MQ bindings The MQ binding now uses an ActivationSpec class in its configuration rather than listener ports. If you are migrating an application that uses an MQ binding for an import or export, you will need to update your binding configuration. For more information on the required migration steps for the MQ binding, see the topic Migrating WebSphere MQ Bindings from version 6 to version 7 in the WebSphere Process Server information center. 10 WebSphere Integration Developer: Migration Guide

15 Chapter 3. Migrating to WebSphere Process Server from WebSphere InterChange Server WebSphere Integration Developer provides the tools necessary to migrate from WebSphere InterChange Server to WebSphere Process Server. Migration from WebSphere InterChange Server to WebSphere Process Server is supported through the following functions in WebSphere Integration Developer: Note: Refer to the release notes for information concerning limitations related to migration in this release of WebSphere Process Server. v Automatic migration of source artifacts through migration tools that can be invoked as follows: Through the File > Import > Business Integration menu of WebSphere Integration Developer. From the Welcome page of WebSphere Integration Developer. v Native support in the runtime of many WebSphere InterChange Server APIs. v Support for the current WebSphere Business Integration Adapter technology so that existing adapters will be compatible with the WebSphere Process Server. v Options for migrating WebSphere Business Integration Adapter connector configurations to native bindings or WebSphere Process Server equivalent adapters. v Connector migration to mediation modules. Even though migration of source artifacts is supported, it is recommended that extensive analysis and testing be done to determine if the resulting applications will function as expected in WebSphere Process Server, or if they will need post-migration redesign. This recommendation is based on the following limitations in functional parity between WebSphere InterChange Server and this version of WebSphere Process Server. There is no support in this version of WebSphere Process Server that is equivalent to these WebSphere InterChange Server functions: v Group Support v Hot Deployment/Dynamic Update v Scheduler - Pause Operation v Security - Auditing v Security - Fine Grain RBAC v Security Descriptors are not migrated Note: WebSphere Business Integration Server Express (WBISX) includes the same types of artifacts as WebSphere InterChange Server. Only two features, Business Rules and Business Probe, are not supported by the migration. Supported migration paths WebSphere Process Server migration tools support migration from WebSphere InterChange Server version 4.3 or later or WebSphere Business Integration Server Express version 4.4 or later. Before migrating, note the following requirements: Note: v Any WebSphere InterChange Server release prior to version 4.3 will first need to migrate to version 4.3 before migrating to WebSphere Process Server. Copyright IBM Corp. 2005,

16 v Any WebSphere Business Integration Server Express release prior to version 4.4 will first need to migrate to version 4.4 before migrating to WebSphere Process Server. Preparing for migration from WebSphere InterChange Server Before migrating to WebSphere Process Server from WebSphere InterChange Server using WebSphere Integration Developer, you must first ensure that you have properly prepared your environment. These migration tools can be invoked from: v The File > Import > Business Integration menu of WebSphere Integration Developer. v The Welcome page of WebSphere Integration Developer. Input to the migration tools is a repository jar file exported from WebSphere InterChange Server. Therefore, before accessing the migration tools through any of these options, you must first: 1. Ensure that you are running a version of WebSphere InterChange Server that can be migrated to WebSphere Process Server. See the topic "Supported migration paths for WebSphere InterChange Server". 2. Export your source artifacts from WebSphere InterChange Server into a repository jar file using the WebSphere InterChange Server repos_copy command as described in the documentation for WebSphere InterChange Server. The wizard requires as input a WebSphere InterChange Server repository JAR file. This JAR file should be self-contained with respect to the applications being migrated. That is, all artifacts referenced by any of the artifacts in the JAR file must also be contained in the JAR file. To ensure that the repository JAR file that will be generated is self-contained, run the repos_copy command with the -vr option before exporting the server repository (this validates the repository). If the repository is valid then repos_copy writes the following output to the console: Validation Succeeded. All Dependencies Resolved. If the repository is not valid then repos_copy prints a list of the dependencies that must be resolved. Resolve the dependencies prior to exporting the repository. Export the repository artifacts and create the repository JAR file, using the WebSphere InterChange Server repos_copy command with the -o option (See the WebSphere InterChange Server 4.3 documentation for more details, including how to export individual components). Considerations for the WebSphere InterChange Server migration process The following considerations are intended to assist in the development of integration artifacts for WebSphere InterChange Server. By adhering to these guidelines, you can ease the migration of WebSphere InterChange Server artifacts to WebSphere Process Server. These recommendations are meant to be used only as a guide. There may be cases where it is necessary to deviate from these guidelines. In these cases care should be taken to limit the scope of the deviation to minimize the amount of rework required to migrate the artifacts. Note that the guidelines outlined here are not all general recommendations for the development of WebSphere InterChange Server artifacts. They are instead limited in scope to those considerations which may affect the ease in which artifacts can be migrated at a future time. Considerations: General development There are several considerations which apply broadly to most of the integration artifacts. In general, the artifacts which leverage the facilities provided by the tools and conform to the metadata models enforced by the tools will migrate most smoothly. Also, artifacts with significant extensions and external dependencies are likely to require more manual intervention when migrating. The following list summarizes the considerations for general development of WebSphere InterChange Server based solutions to help ease future migration: v Document the system and component design 12 WebSphere Integration Developer: Migration Guide

17 v Use the development tools to edit integration artifacts v Leverage suggestions for defining rules with the tools and Java snippets It is important for integration solutions to adhere to the programming model and architecture provided by WebSphere InterChange Server. Each of the integration components within WebSphere InterChange Server plays a well-defined role within the architecture. Significant deviations from this model will make it more challenging to migrate content to the appropriate artifacts on WebSphere Process Server. Another general practice which will improve the success of future migration projects is to document the system design. Be sure to capture the integration architecture and design, including functional design and quality of service requirements, the interdependencies of artifacts shared across projects, and also the design decisions that were made during the deployment. This will assist in system analysis during migration, and will minimize any rework efforts. For creating, configuring, and modifying artifact definitions, use only the development tools provided. Avoid manual manipulation of artifact metadata (for example, editing XML files directly), which may break the artifact for migration. Follow these guidelines when developing Java code within collaboration templates, maps, common code utilities, and other components: v Use only the published APIs. v Use the activity editor. v Use adapters to access EISs. v Avoid external dependencies in Java snippet code. v Adhere to J2EE develop practices for portability. v Do not spawn threads or use thread synchronization primitives. If you must, these will need to be converted to use Asynchronous Beans when you migrate. v Do not do any disk I/O using java.io.* Use JDBC to store any data. v Do not perform any functions that may be reserved for an EJB container such as socket I/O, classloading, loading native libraries, and so forth. If you must, these snippets would need manual conversion to use EJB container functions when you migrate. Use only the APIs published in the WebSphere InterChange Server product documentation for the artifacts. These are outlined in detail in the WebSphere InterChange Server development guides. Compatibility APIs will be provided in WebSphere Process Server for published WebSphere InterChange Server APIs. Although WebSphere InterChange Server has many internal interfaces which you may use, this practice is discouraged because these interfaces are not guaranteed to be supported in the future. When designing business logic and transformation rules in maps and collaboration templates, try to avoid field developed common code utility libraries, included as a Java archive (*.jar) file in the classpath of WebSphere InterChange Server, as these will need to be migrated manually. Use the activity editor tool to the greatest extent possible. This will ensure that the logic is described through metadata which can more readily be converted to the new artifacts. In any Java code snippets that may need to be developed, the code be as simple and atomic as possible. The level of sophistication in the Java code should be on the order of scripting, involving basic evaluations, operations, and computations, data formatting, type conversions, and so forth. If more extensive or sophisticated application logic is required, consider using EJBs running in WebSphere Application Server to encapsulate the logic, and use web service calls to invoke it from WebSphere InterChange Server. Use standard JDK libraries rather than third party or external libraries which would need to be migrated separately. Also, collect all related logic within a single code snippet, and avoid using logic where connection and transaction contexts span multiple code snippets. With database Chapter 3. Migrating from WebSphere InterChange Server 13

18 operations, for example, code related to obtaining a connection, beginning and ending a transaction, and releasing the connection should be in one code snippet. In general, ensure that code which is designed to interface with an Enterprise Information System (EIS) is placed within adapters, and not within maps or collaboration templates. This is generally a recommended practice for architecture design. Also, this will help avoid prerequisites for third party libraries and related considerations within the code, such as connection management and possible Java Native Interface (JNI) implementations. Make the code as safe as possible by using appropriate exception handling. Also make the code compatible to run within a J2EE application server environment, even though it is currently running within a J2SE environment. Adhere to J2EE development practices, such as avoiding static variables, spawning threads, and disk I/O. While these are generally good practices to adhere to, they can improve portability. Considerations: Common code utilities If possible, you should avoid the development of common code utility libraries for use across integration artifacts within the WebSphere InterChange Server environment. Also, consider using EJBs running in WebSphere Application Server to encapsulate the logic, and use Web service calls to invoke them from WebSphere InterChange Server. While it is possible that some common code utility libraries may run appropriately on WebSphere Process Server, you will be responsible for the migration of the custom utilities. Considerations: Database connection pools A WebSphere InterChange Server database connection pool within a map or collaboration template will be rendered as a standard JDBC resource in WebSphere Process Server. However, the manner in which connections and transactions are managed might differ between WebSphere InterChange Server and WebSphere Process Server. Therefore, you should avoid keeping database transactions active across Java snippets. User-defined database connection pools are useful within maps and collaboration templates for simple data lookups and for more sophisticated state management across process instances. A database connection pool in WebSphere InterChange Server will be rendered as a standard JDBC resource in WebSphere Process Server, and the basic function will be the same. However, the way connections and transactions are managed may differ. To maximize future portability, avoid keeping database transactions active across Java snippet nodes within a collaboration template or map. For example, code related to obtaining a connection, beginning and ending a transaction, and releasing the connection should be in one code snippet. Considerations: Business objects For the development of business objects you should use only the tools provided to configure artifacts, and use explicit data types and lengths for data attributes, and only use the documented APIs. Business objects within WebSphere Process Server are based on Service Data Objects (SDOs) which have data attributes that are strongly typed. For business objects in WebSphere InterChange Server and adapters, data attributes are not strongly typed, and string data types are sometimes specified for non-string data attributes. To avoid issues in WebSphere Process Server, explicitly specify data types. As business objects within WebSphere Process Server might be serialized at runtime as they are passed between components, it is important to be explicit with the required lengths for data attributes to minimize utilization of system resources. For this reason, do not use the maximum 255 character length 14 WebSphere Integration Developer: Migration Guide

19 for a string attribute. Also, do not specify zero length attributes which currently default to 255 characters. Instead, specify the exact length required for attributes. XSD NCName rules apply to business object attribute names in WebSphere Process Server. Therefore, do not use any spaces or ":" in names for business object attributes. Business object attribute names with spaces or ":" are invalid in WebSphere Process Server. Rename business object attributes before migration. If using an array in a business object, you cannot rely on the order of the array when indexing into the array in maps or relationships. The construct that this migrates into in WebSphere Process Server does not guarantee index order, particularly when entries are deleted. It is important to use only the Business Object Designer tool to edit business object definitions, and to use only the published APIs for business objects within integration artifacts. Considerations: Collaboration templates Many of the guidelines that have already been described apply to the development of collaboration templates. To ensure processes are described appropriately with metadata, always use the Process Designer tool for the creation and modification of collaboration templates, and avoid editing the metadata files directly. Use the Activity Editor tool wherever possible to maximize the use of metadata to describe the required logic. To minimize the amount of manual rework that may be required in migration, use only the documented APIs within collaboration templates. Avoid the use of static variables and instead use non-static variables and collaboration properties to address the requirements of the business logic. Avoid the use of Java qualifiers final, transient and native in Java snippets. These cannot be enforced in the BPEL Java snippets that are the result of migrating the Collaboration Templates. To maximize future portability, avoid using explicit connection release calls and explicit transaction bracketing (that is, explicit commits and explicit rollbacks) for User Defined Database Connection Pools. Instead, make use of the container-managed implicit connection clean-up and implicit transaction bracketing. Also, avoid keeping system connections and transactions active across Java snippet nodes within a collaboration template. This applies to any connection to an external system, as well as user-defined database connection pools. Operations with an external EIS should be managed within an adapter, and code related to database operation should be contained within one code snippet. This may be necessary within a collaboration which, when rendered as a BPEL business process component may be selectively deployed as an interruptible flow. In this case, the process may be comprised of several separate transactions, with only state and global variable information passed between the activities. The context for any system connection or related transaction which spanned these process transactions would be lost. Name collaboration template property names in accordance with W3C XML NCName naming conventions. WebSphere Process Server accepts names conforming to those conventions. Any disallowed characters are not valid in BPEL property names that they will be migrated into. Rename properties to remove any disallowed characters before migrating to avoid syntactical errors in the BPEL generated by migration. Do not reference variables using "this." For example, Instead of "this.inputbusobj" use just "inputbusobj". Use class-level scoping on variables instead of scenario-scoped variables. Scenario-scoping is not carried forward during migration. Chapter 3. Migrating from WebSphere InterChange Server 15

20 Initialize all variables declared in Java snippets with a default value, for example, "Object myobject = null;". Ensure that all variables are initialized during declaration before migrating. Ensure that there are no Java import statements in the user modifiable sections of your collaboration templates. In the definition of the collaboration template, use the import fields to specify Java packages to import. Do not set incoming business object values to be stored in the triggeringbusobj variable. Within WebSphere InterChange Server, the triggeringbusobj is read-only and its values cannot be overwritten, so any incoming business object values will not be saved. If the triggeringbusobj is used as the receiving variable for an incoming business object on an inbound service call, then after migration the behavior of the inbound service call will be different: within the BPEL process, the incoming value from the inbound service call will overwrite the value stored in triggeringbusobj. Considerations: Maps Many of the guidelines that have already been described for collaboration templates also apply to maps. To ensure that maps are described appropriately with metadata, always use the Map Designer tool for the creation and modification of maps, and avoid editing the metadata files directly. Use the activity editor tool wherever possible to maximize the use of metadata to describe the required logic. When referencing child business objects in a map, use a submap for the child business objects. Avoid using Java code as the "value" in a SET since that is not valid in WebSphere Process Server. Use constants instead. For example, if the set value is "xml version=" + "1.0" + " encoding=" + "UTF-8" this will not validate in WebSphere Process Server. Instead, change it to "xml version=1.0 encoding=utf-8" before migrating. To minimize the amount of manual rework that may be required in migration, use only the documented APIs within maps. Avoid the use of static variables and instead use non-static variables. Avoid the use of Java qualifiers final, transient and native in map custom code. If using an array in a business object, do not rely on the order of the array when indexing into the array in maps. The construct that this migrates into in WebSphere Process Server does not guarantee index order, particularly when entries are deleted. To maximize future portability, avoid using explicit connection release calls and explicit transaction bracketing (that is, explicit commits and explicit rollbacks) for User Defined Database Connection Pools. Instead, make use of the container-managed implicit connection clean-up and implicit transaction bracketing. Also, avoid keeping system connections and transactions active in custom map steps across transformation node boundaries. This applies to any connection to an external system, as well as user-defined database connection pools. Operations with an external EIS should be managed within an adapter, and code related to database operation should be contained within one custom step. Do not use inner classes in your maps. The migration command (reposmigrate) does not migrate inner classes and you will receive errors if your maps contain them. In a WebSphere InterChange Server repository, an inner class could be defined in a node and referenced by other nodes within the same collaboration template. In WebSphere Process Server, an inner class defined in a BPEL component cannot be used by other components. Due to this limitation, inner classes are not translated and must be dealt with manually. Recommended changes include packaging the inner class code in a library as an external class, or removing the inner class declaration, resolving any errors, and placing the code as needed throughout the BPEL. 16 WebSphere Integration Developer: Migration Guide

21 Considerations: Relationships For relationships, while relationship definitions will be able to be migrated for use in WebSphere Process Server, the relationship table schema and instance data may be reused by WebSphere Process Server and also shared concurrently between WebSphere InterChange Server and WebSphere Process Server. Use only the tools provided to configure the related components, and use only the published APIs for relationships within integration artifacts. Use only the relationship editor to edit relationship definitions. In addition, allow only WebSphere InterChange Server to configure the relationship schema, which is generated automatically upon deployment of relationship definitions. Do not alter the relationship table schema directly with database tools or SQL scripts. If you must manually modify relationship instance data within the relationship table schema, be sure to use the facilities provided by the Relationship Manager. Considerations: Access framework clients Do not develop any new clients adopting the CORBA IDL interface APIs. This will not be supported in WebSphere Process Server. Considerations: Preventing database collisions If a migrated application causes multiple events to occur at the same time to WebSphere Business Integration components, database collisions, or deadlocks could occur. These occur when the WebSphere Process Server Application Scheduler (AppScheduler) schedules multiple events to occur at exactly the same time. You can prevent database collisions from occurring by scheduling events to occur at different times. When a deadlock occurs, the event that caused it is rolled back and attempted again as soon as possible. This cycle continues until each of the threads attempting to access the database successfully updates it. For example: AppScheduler E com.ibm.wbiserver.scheduler.appschedulermb process CWLWS0021E: The AppSchedulerMB.process method has generated an exception. WSRdbXaResour E DSRA0304E: XAException occurred. XAException contents and details are: The DB2 Error message is : Error executing a XAResource.end(), Server returned XA_RBDEADLOCK The DB2 Error code is : The DB2 SQLState is : null To prevent this from occurring, schedule the events to occur far enough apart so that deadlocks do not occur. Schedule events to occur at least two seconds apart, however, the amount of time you need will vary depending on other factors in your environment that affect performance such as database size, hardware, connection speed and other factors. Considerations: Post-migration When applications have been migrated from WebSphere InterChange Server to WebSphere Integration Developer or WebSphere Process Server, special attention is required in some areas to enable migrated applications to function in WebSphere Integration Developer and WebSphere Process Server consistently with their intended function due to differences with the architecture WebSphere InterChange Server. For more information regarding post-migration considerations, see the topic "Post-migration considerations" in the WebSphere Process Server information center. For information on how to download server documentation, see Viewing or downloading WebSphere Process Server documentation. Chapter 3. Migrating from WebSphere InterChange Server 17

22 WebSphere InterChange Server migration scenarios There are a number of WebSphere InterChange Server migration scenarios that are supported by WebSphere Integration Developer. The following scenarios outline the migration process from WebSphere InterChange Server: Migrating a WebSphere Business Integration EJB adapter to a WebSphere Process Server Stateless Session Bean The Migration wizard gives the option to migrate to either a JMS binding connecting to the existing WebSphere Business Integration adapter or to a new Stateless Session Bean. The migration will generate skeleton artifacts. Migrating a WebSphere Business Integration HTTP adapter to a WebSphere Process Server native binding If the HTTP connector was configured with a protocol listener, then you will need to modify your client application before connecting to the migrated connector. For example, if the connector is called HTTPConnector, is listening on port 8080 and using the URL /wbia/samples/webservices then when migrated to WebSphere Process Server, the port will be 9080 (the WC_defaulthost port) and the URL will change to /HTTPConnectorWeb/wbia/samples/http. In WebSphere InterChange Server you can access this using while in WebSphere Process Server it will be The Migration wizard gives the option to migrate to either a JMS binding connecting to the existing WebSphere Business Integration adapter or to a new HTTP binding. The wizard will allow you to select an ICS default data handler, create a WPS data handler skeleton, or use a custom data handler. The default data handler in the Migration wizard is the XML data handler. This migration scenario also supports dynamic endpoint routing. Migrating a WebSphere Business Integration JMS adapter to a WebSphere Process Server JMS or Generic JMS native binding The Migration wizard gives the option to migrate to either a JMS binding connecting to the existing WebSphere Business Integration adapter or to a new JMS or Generic JMS binding. The wizard will allow you to select an ICS default data handler, create a WPS data handler skeleton, or use a custom data handler. Choosing the default data handler option provides the CwDataHandler. If you select the JMS binding, you will need to create the Generic JMS, Queue Connection Factory, JMS Queues, and JMS Listener Ports, and you will also need to generate a new bindings file that includes entries for the queues. See the WebSphere Process Server information center for more information on working with JMS bindings. For information on how to download server documentation, see Viewing or downloading WebSphere Process Server documentation. If you select the Generic JMS binding, you will need to create the Generic JMS, Queue Connection Factory, and JMS Queues, and you will also need to generate a new bindings file that includes entries for the queues. The listener ports are created during deployment. See the WebSphere Process Server information center for more information on working with Generic JMS bindings. For information on how to download server documentation, see Viewing or downloading WebSphere Process Server documentation. The JMS or Generic JMS supports dynamic endpoint routing. Because of this, the Send queue in the import is not used and the migration has left this value blank. You will need to provide a value before the module can be deployed and started. 18 WebSphere Integration Developer: Migration Guide

23 Migrating a WebSphere Business Integration MQ adapter to a WebSphere Process Server MQ or MQ JMS native binding The Migration wizard gives the option to migrate to either a JMS binding connecting to the existing WebSphere Business Integration adapter or to a new MQ or MQ JMS binding. The MQ or MQ JMS supports dynamic endpoint routing. Because of this, the Request queue is not used and the migration has left this value blank. You will need to provide a valid queue (but recommended unused in case of problems) before the module can be deployed and started. Also, provide a valid Reply queue for the export. The wizard will allow you to select an ICS default data handler, create a WPS data handler skeleton, or use a custom data handler. Choosing the default data handler option provides the CwDataHandler. If you select MQ JMS, you will need to additionally configure the Destination Queue and Connection Factory. Open the outbound map for the MFC, and edit the URL in Custom Step #3 to include the Connection Factory name. A sample URL looks like this: jms:/queue?destination=mqoutput&connectionfactory=&targetservice=output Enter the value between connectionfactory= and the &. The final string would look like: jms:/queue?destination=mqoutput&connectionfactory=myconnectionfactory&targetservice=output Migrating a WebSphere Business Integration Web Services adapter to a WebSphere Process Server HTTP native binding If the WS connector was configured with a protocol listener, then you will need to modify your client application before connecting to the migrated connector. For example, if the connector is called WSConnector, listening on port 8080 and using the URL /wbia/samples/webservices then when migrated to WebSphere Process Server, the port will be 9080 (the WC_defaulthost port) and the URL will change to /WSConnectorWeb/wbia/samples/webservices There are two possible scenarios for this type of migration: 1. If the Web Services adapter uses the HTTP transport protocol, then the Migration wizard will give the option to migrate to either a JMS binding connecting to the existing WebSphere Business Integration adapter or to a new HTTP binding. 2. If the Web Services adapter uses the JMS transport protocol, then the only option for migration is the JMS binding connecting to the existing WebSphere Business Integration adapter. Note that in this type of migration, the wizard will not allow you to select a custom data handler. This migration scenario also supports dynamic endpoint routing. Migrating WebSphere InterChange Server artifacts using the Migration wizard You can use the WebSphere Integration Developer Migration wizard to migrate your existing WebSphere InterChange Server artifacts. The wizard will perform the migration based on the following: 1. Adapters are migrated to native bindings if they can be supported as native bindings; and 2. If an adapter is detected as one that has an equivalent JCA connector, then the option is given to import that. By importing the connector, you set up the environment to be migrated to the JCA adapter using the Migration wizard. Chapter 3. Migrating from WebSphere InterChange Server 19

24 To use the Migration wizard to migrate your WebSphere InterChange Server artifacts, follow these steps: 1. Invoke the wizard by selecting File > Import > Business Integration > WebSphere InterChange Server Repository and click Next. 2. The Migration wizard opens. Enter the WebSphere InterChange Server repository path or click Browse JARs to select the JAR file to be used in the migration process. 3. Enter the name of a new or existing WebSphere Integration Developer library. 4. You can also add a WebSphere InterChange Server assembly editor template to be loaded and used for XML to Java conversion. If custom APIs (My Library) are created for use in the activity editor, the migration tool must refer to the custom activity editor template to determine how to migrate the custom API to Java. These templates can be found in the root directory.wbiacteditorsettings located in WebSphere InterChange Server workspace directory. Generally, the template files have a.bbt file extension. Ensure that you load these templates in the template box. If you do not add a template, the Standard Assembly Editor Template V4.3.3 will be used for XML to Java conversion. 5. Select Enable selective migration if you want to choose specific collaboration objects and connectors to migrate and click Next. Note: Enabling selective migration is not recommended if you plan to split the shared library. For information about splitting the shared library, see step From this page, select the artifacts for migration by highlighting the available collaboration objects and connectors from the lists on the left and click Add to add the artifact to the list box on the right. Note that the supporting artifacts (such as business objects, maps, and relationships) will be added automatically. 7. After selecting the collaboration objects and connectors, you can choose to perform a complete or partial recursive selection. By using the complete recursive option, all direct and indirect dependent artifacts will be selected. The partial recursive option depends on the type of artifact selected. For example, for the collaboration object, all direct dependent connectors will be selected automatically, then the supporting artifacts are selected. If the artifact type is the connector, all direct dependent collaboration objects will be selected automatically first. Then all direct dependent connectors for these collaboration objects are selected before finally selecting the supporting artifacts. 8. Click Next to review the current selection results based on the root artifacts that have been chosen for migration. Use the filter to filter the results and sort a specific column by clicking on the column's header. 9. Click Next to add more supporting artifacts to the list for migration. From this page you can select supporting artifacts (such as business objects, maps, and relationships) that were not discovered automatically by the Migration wizard. Select the artifacts for migration by highlighting them from the lists on the left and click Add to add the artifact to the list box on the right. 10. Click Next to configure the migration settings for each connector. From this page, you can select the appropriate target binding and data handlers for each connector being migrated. Select the connector from the list and choose a target binding and then a custom data handler JAR file. Note that the Migration wizard will not allow the migration process to proceed until all connector values are set. 11. Click Next. The Conversion Options page displays. From here you can accept the recommended options or change them: 20 WebSphere Integration Developer: Migration Guide

25 The following table details the migration conversion options: Option Select how Java parsing errors in the migration process should be treated Description Errors (recommended) All Java conversion problems are treated as errors and you will need to review the error log for more details. Warnings All Java conversion problems are treated as warnings only and the artifact will be migrated by the Migration wizard as best as possible. Chapter 3. Migrating from WebSphere InterChange Server 21

26 Option Select the action for when content is missing or another error occurs Perform event sequencing for all asynchronous WSDL methods Merge the connector module and the collaboration module Description Missing content - complete the migration (recommended) The migration process will continue even if there are missing artifacts in the source JAR file. Missing content - stop the migration The migration process will stop if there are missing artifacts in the source JAR file. Other errors - complete the migration (recommended) The migration process will continue to process the remaining artifacts in a JAR file even if an error occurs during the processing of a given artifact. Other errors - stop the migration The migration process will stop as soon as an error is detected. The artifact with the error, and all subsequent artifacts, are not processed. Disable (recommended) The migration process will not enable event sequencing on any WSDL methods. Enable The migration process will enable event sequencing for all asynchronous WSDL methods. Disable (recommended) The connector module and collaboration module will not be merged together when the connector module only binds to one collaboration. Selecting this option means that the migrated modules may be easier to extend. Enable The connector module and collaboration module will be merged together when the connector module only binds to one collaboration. Selecting this option means that the migrated modules may not be easily extended thereby reducing the number of modules. Note the following limitations when selecting the Enable option: v The original scheduler configuration will not take effect on the merged connector module and collaboration module. v The connector being merged will not be able to migrate to a JCA adapter later. Note: This option will be disabled if the collaboration invokes the DynamicSend API. 22 WebSphere Integration Developer: Migration Guide

27 Option Split the shared library Note: The recommended option (Disable or Enable) depends on whether you selected the check box for Enable selective migration in step 5 on page 20. Description Disable The shared library is not split into smaller shared libraries. Select Disable to maintain a single shared library of the entire WebSphere InterChange Server repository. Note: If you selected Enable selective migration in step 5 on page 20, the recommended option is Disable (recommended). Enable The single shared library is split into smaller shared libraries. These smaller shared libraries contain only those artifacts that the dependent projects share, thus reducing the overall size of the EAR file to be installed into the migrated runtime environment. By selecting Enable, you can make the artifact migration process more efficient and less memory intensive at run time. By splitting the shared library into smaller shared libraries, you migrate only those artifacts used by a particular process (rather than migrating all of the artifacts from the WebSphere InterChange Server repository), which greatly reduces the size of the EAR file to be installed into the migrated runtime environment and reduces the number of artifacts that the artifact loader must process to load the correct business objects. Note: If you did not select Enable selective migration in step 5 on page 20, the recommended option is Enabled (recommended). Note: If you selected Enable selective migration in step 5 on page 20, the recommended option is Disable (recommended). Selecting both options, Enable selective migration and Split the shared library, introduces an unnecessary level of complexity to the migration task (because the artifacts added through selective migration must also be added separately if you select Enable for Split the shared library. For a migration that involves a simple repository (two or three self-contained groups), you might want to split shared library to migrate the repository in one batch. However, for a large and complex repository, for example more than 5 self-contained groups, you might want to use selective migration to migrate the content incrementally. 12. Click Next. If you set Split the shared library to Disable on the Conversion Options page, a Migration Summary page displays. Proceed to step 14 on page 25 Chapter 3. Migrating from WebSphere InterChange Server 23

28 If you set Split the shared library to Enable (recommended) on the Conversion Options page, a Name the Libraries page displays. Proceed to step Name the libraries. From the Name the Libraries page, you can perform the following actions: a. Set the library name. The default library name is based on the name that you entered in step 3 on page 20. You can change the default name by clicking the library name in the table. b. View the connectors. Information in the Connector column of the table specifies the connectors which can give you information about which subgroup this library is associated with. Tip: If the list of the artifacts is too long for the cell, use the hover help to display all the connectors. c. View the collaborations. Information in the Collaborations column of the table specifies the collaboration objects that can provide you with information about which sub group this library is associated with. Tip: If the list of the artifacts is too long for the cell, use the hover help to display all of the collaboration objects. d. Add more artifacts in the shared library by clicking Add More. An Add Supporting Artifacts page displays, which looks similar to the following screen capture: 24 WebSphere Integration Developer: Migration Guide

29 You cannot remove the preselected artifacts (shown on the right side) from the list. You can only add or remove the original artifacts (shown on the left side). The list is sorted in ascending order. The items on the right are categorized by preselected and user-selected and sorted separately. 14. After you have reviewed the summary details, click Finish to begin the migration process. Chapter 3. Migrating from WebSphere InterChange Server 25

30 A progress bar at the bottom of the migration dialog indicates the progress of the migration. Once the process has completed, the dialog disappears and the Migration Results window opens: 26 WebSphere Integration Developer: Migration Guide

31 Click Close to finish the process and to build the new workspace. You can deselect the Build workspace on close option if you do not want the workspace to build at this time. Verifying the WebSphere InterChange Server migration If no errors are reported during the migration of the WebSphere InterChange Server.jar file, then the migration of the artifacts was successful. If the migration has not completed successfully, a list of errors, warnings, and informational messages will be displayed in the Migration Results window. You can use these messages to verify the WebSphere InterChange Server migration. Note: Due to the complexity of migrating from WebSphere InterChange Server to WebSphere Process Server, you are strongly urged to perform extensive testing of the resulting applications running in WebSphere Process Server to ensure that they function as expected before putting them into production. If you decide to not stop on the first failure, you will see a green check mark icon in the Migration Results window, but there may also be red Xs in the list. Therefore, you will need to review these in the list. If you decide to stop on the first failure and you receive a failure or error, you will see a red X in the Migration Results window instead of a green check mark and you will need to review the failures in the list. Working with migration failures from WebSphere InterChange Server If the migration process from WebSphere InterChange Server fails, there are a two ways in which to deal with the failures. Note: You may prefer the first option as you will initially be more familiar with WebSphere InterChange Server. However, as you become more experienced with WebSphere Process Server and its new artifacts, you may choose to repair the migrated artifacts in WebSphere Integration Developer. 1. If the nature of the error permits, you can adjust the WebSphere InterChange Server artifacts using the WebSphere InterChange Server toolset, and export the jar file again and retry the migration. 2. You can fix any errors in the resulting WebSphere Process Server artifacts by editing the artifacts in WebSphere Integration Developer. Chapter 3. Migrating from WebSphere InterChange Server 27

32 WebSphere InterChange Server and WebSphere Business Integration Server Express artifacts handled by the migration tools The migration tools can automatically migrate some of the WebSphere InterChange Server and WebSphere Business Integration Server Express artifacts. The following artifacts can be migrated: v Business objects become WebSphere Process Server business objects. v Maps become WebSphere Process Server maps. v Relationships become WebSphere Process Server relationships and roles. v Collaboration templates become WebSphere Process Server BPEL and WSDL. v Collaboration objects become WebSphere Process Server modules containing SCA component that are bound to the Collaboration Template BPEL and all the necessary SCA wiring. v Connector definitions become WebSphere Process Server mediation modules containing SCA imports and exports and mediation flow components if the connector is migrated to a native binding. The connector definitions become WebSphere Process Server modules containing SCA imports and exports and mediation flow components that allow communication with Legacy Adapters, Legacy Adapter Administrative Artifact, and all the necessary SCA wiring. The migration tools create a Jython script that can be used with the wsadmin command line tool to configure resources in WebSphere Process Server for the following WebSphere InterChange Server artifacts or resources: v DBConnection pools v Relationships v Scheduler entries The migration tools do not handle the following WebSphere InterChange Server artifacts: v Benchmark artifacts Supported WebSphere InterChange Server APIs In addition to the WebSphere InterChange Server source artifact migration tools provided in WebSphere Process Server and WebSphere Integration Developer, there is also support for many of the APIs that were provided in WebSphere InterChange Server. The migration tools work in conjunction with these WebSphere InterChange Server APIs by preserving your custom snippet code as much as possible when migrating. Note: These APIs are provided only to support migrated WebSphere InterChange Server applications until they can be modified to use new Process Server APIs. The supported WebSphere InterChange Server APIs in Process Server are listed below. These APIs provide functions in WebSphere Process Server similar to the function that they provide in WebSphere InterChange Server. See the WebSphere InterChange Server documentation for a functional description of these APIs. CwBiDiEngine AppSide_Connector/ v BiDiBOTransformation(BusinessObject, String, String, boolean):businessobj v BiDiBusObjTransformation(BusObj, String, String, boolean):busobj v BiDiStringTransformation(String, String, String):String JavaConnectorUtil AppSide_Connector/ 28 WebSphere Integration Developer: Migration Guide

33 v INFRASTRUCTURE_MESSAGE_FILE v CONNECTOR_MESSAGE_FILE v XRD_WARNING v XRD_TRACE v XRD_INFO v XRD_ERROR v XRD_FATAL v LEVEL1 v LEVEL2 v LEVEL3 v LEVEL4 v LEVEL5 v createbusinessobject(string):businesobjectinterface v createbusinessobject(string, Locale):BusinesObjectInterface v createbusinessobject(string, String):BusinesObjectInterface v createcontainer(string):cxobjectcontainerinterface v generatemsg(int, int, int, int, int, Vector):String v generatemsg(int, int, int, int, Vector):String v getblankvalue():string v getencoding():string v getignorevalue():string v getlocale():string v getsdofromstring(string inputstring, String sdoname, String metaobjectname, String mimetype) v getstringfromsdo(dataobject sdo, String metaobjectname, String mimetype) v isblankvalue(object):boolean v isignorevalue(object):boolean v istraceenabled(int):boolean v logmsg(string) v logmsg(string, int) v tracewrite(int, String) JavaConnectorUtilDH datahandler/ wbi/ ibm/ com/ v getsdofromstring(string inputstring, String sdoname, String metaobjectname, String mimetype) v getstringfromsdo(dataobject sdo, String metaobjectname, String mimetype) BusObj Collaboration/ v BusObj(DataObject) v BusObj(String) v BusObj(String, Locale) v copy(busobj) v duplicate():busobj v equalkeys(busobj):boolean Chapter 3. Migrating from WebSphere InterChange Server 29

34 v equals(object):boolean v equalsshallow(busobj):boolean v exists(string):boolean v get(int):object v get(string):object v getboolean(string):boolean v getbusobj(string):busobj v getbusobjarray(string):busobjarray v getcount(string):int v getdouble(string):double v getfloat(string):float v getint(string):int v getkeys():string v getlocale():java.util.locale v getlong(string):long v getlongtext(string):string v getstring(string):string v gettype():string v getvalues():string v getverb():string v isblank(string):boolean v iskey(string):boolean v isnull(string):boolean v isrequired(string):boolean v keystostring():string v set(busobj) v set(int, Object) v set(string, boolean) v set(string, double) v set(string, float) v set(string, int) v set(string, long) v set(string, Object) v set(string, String) v setcontent(busobj) v setdefaultattrvalues() v setkeys(busobj) v setlocale(java.util.locale) v setverb(string) v setverbwithcreate(string, String) v setwithcreate(string, boolean) v setwithcreate(string, BusObj) v setwithcreate(string, BusObjArray) v setwithcreate(string, double) v setwithcreate(string, float) 30 WebSphere Integration Developer: Migration Guide

35 v setwithcreate(string, int) v setwithcreate(string, long): v setwithcreate(string, Object) v setwithcreate(string, String) v tostring():string v validdata(string, boolean):boolean v validdata(string, BusObj):boolean v validdata(string, BusObjArray):boolean v validdata(string, double):boolean v validdata(string, float):boolean v validdata(string, int):boolean v validdata(string, long):boolean v validdata(string, Object):boolean v validdata(string, String):boolean BusObjArray Collaboration/ v addelement(busobj) v duplicate():busobjarray v elementat(int):busobj v equals(busobjarray):boolean v getelements():busobj[] v getlastindex():int v max(string):string v maxbusobjarray(string):busobjarray v maxbusobjs(string):busobj[] v min(string):string v minbusobjarray(string):busobjarray v minbusobjs(string):busobj[] v removeallelements() v removeelement(busobj) v removeelementat(int) v setelementat(int, BusObj) v size():int v sum(string):double v swap(int, int) v tostring():string BaseDLM DLM/ v BaseDLM(BaseMap) v getdbconnection(string):cwdbconnection v getdbconnection(string, boolean):cwdbconnection v getname():string v getrelconnection(string):dtpconnection v implicitdbtransactionbracketing():boolean Chapter 3. Migrating from WebSphere InterChange Server 31

36 v istraceenabled(int):boolean v logerror(int) v logerror(int, Object[]) v logerror(int, String) v logerror(int, String, String) v logerror(int, String, String, String) v logerror(int, String, String, String, String) v logerror(int, String, String, String, String, String) v logerror(string) v loginfo(int) v loginfo(int, Object[]) v loginfo(int, String) v loginfo(int, String, String) v loginfo(int, String, String, String) v loginfo(int, String, String, String, String) v loginfo(int, String, String, String, String, String) v loginfo(string) v logwarning(int) v logwarning(int, Object[]) v logwarning(int, String) v logwarning(int, String, String) v logwarning(int, String, String, String) v logwarning(int, String, String, String, String) v logwarning(int, String, String, String, String, String) v logwarning(string) v raiseexception(runtimeentityexception) v raiseexception(string, int) v raiseexception(string, int, Object[]) v raiseexception(string, int, String) v raiseexception(string, int, String, String) v raiseexception(string, int, String, String, String) v raiseexception(string, int, String, String, String, String) v raiseexception(string, int, String, String, String, String, String) v raiseexception(string, String) v releaserelconnection(boolean) v trace(int, int) v trace(int, int, Object[]) v trace(int, int, String) v trace(int, int, String, String) v trace(int, int, String, String, String) v trace(int, int, String, String, String, String) v trace(int, int, String, String, String, String, String) v trace(int, String) v trace(string) 32 WebSphere Integration Developer: Migration Guide

37 CwDBConnection CwDBConnection/ CxCommon/ v begintransaction() v commit() v executepreparedsql(string) v executepreparedsql(string, Vector) v executesql(string) v executesql(string, Vector) v executestoredprocedure(string, Vector) v getupdatecount():int v hasmorerows():boolean v intransaction():boolean v isactive():boolean v nextrow():vector v release() v rollback() CwDBConstants CwDBConnection/ CxCommon/ v PARAM_IN - 0 v PARAM_INOUT - 1 v PARAM_OUT - 2 CwDBStoredProcedureParam CwDBConnection/ CxCommon/ v CwDBStoredProcedureParam(int, Array) v CwDBStoredProcedureParam(int, BigDecimal) v CwDBStoredProcedureParam(int, boolean) v CwDBStoredProcedureParam(int, Boolean) v CwDBStoredProcedureParam(int, byte[]) v CwDBStoredProcedureParam(int, double) v CwDBStoredProcedureParam(int, Double) v CwDBStoredProcedureParam(int, float) v CwDBStoredProcedureParam(int, Float) v CwDBStoredProcedureParam(int, int) v CwDBStoredProcedureParam(int, Integer) v CwDBStoredProcedureParam(int, java.sql.blob) v CwDBStoredProcedureParam(int, java.sql.clob) v CwDBStoredProcedureParam(int, java.sql.date) v CwDBStoredProcedureParam(int, java.sql.struct) v CwDBStoredProcedureParam(int, java.sql.time) v CwDBStoredProcedureParam(int, java.sql.timestamp) v CwDBStoredProcedureParam(int, Long) v CwDBStoredProcedureParam(int, String) Chapter 3. Migrating from WebSphere InterChange Server 33

38 v CwDBStoredProcedureParam(int, String, Object) v getparamtype():int getvalue():object DataHandler (Abstract Class) DataHandlers/ crossworlds/ com/ v createhandler(string, String, String):DataHandler v getbo(inputstream, Object):BusinessObjectInterface v getbo(object, BusinessObjectInterface, Object) v getbo(object, Object):BusinessObjectInterface v getbo(reader, BusinessObjectInterface, Object) (Abstract Method) v getbo(reader, Object):BusinessObjectInterface (Abstract Method) v getbo(string, Object):BusinessObjectInterface v getboname(inputstream):string v getboname(reader):string v getboname(string):string v getbooleanoption(string):boolean v getencoding():string v getlocale():locale v getoption(string):string v getstreamfrombo(businessobjectinterface, Object):InputStream (Abstract Method) v getstringfrombo(businessobjectinterface, Object):String (Abstract Method) v setconfigmoname(string) v setencoding(string) v setlocale(locale) v setoption(string, String) v tracewrite(string, int) NameHandler (Abstract Class) DataHandlers/ crossworlds/ com/ v getboname(reader, String):String) (Abstract Method) ConfigurationException (extends java.lang.exception) Exceptions/ DataHandlers/ crossworlds/ com/ MalformedDataException (extends java.lang.exception) Exceptions/ DataHandlers/ crossworlds/ com/ NotImplementedException (extends java.lang.exception) Exceptions/ 34 WebSphere Integration Developer: Migration Guide

39 DataHandlers/ crossworlds/ com/ BusinessObjectInterface CxCommon/ v clone():object v dump():string v getapptext():string v getattrcount():int v getattrdesc(int):cxobjectattr v getattrdesc(string):cxobjectattr v getattribute(string):object v getattributeindex(string):int v getattributetype(int):int v getattributetype(string):int v getattrname(int):string v getattrvalue(int):object v getattrvalue(string):object v getbusinessobjectversion():string v getdefaultattrvalue(int):string v getdefaultattrvalue(string):string v getlocale():string v getname():string v getparentbusinessobject():businessobjectinterface v getverb():string v getverbapptext(string):string v isblank(int):boolean v isblank(string):boolean v isignore(int):boolean v isignore(string):boolean v isverbsupported(string):boolean v makenewattrobject(int):object v makenewattrobject(string):object v setattributewithcreate(string, Object) v setattrvalue(int, Object) v setattrvalue(string, Object) v setdefaultattrvalues() v setlocale(locale) v setlocale(string) v setverb(string) CxObjectAttr CxCommon/ v BOOLEAN v BOOLSTRING Chapter 3. Migrating from WebSphere InterChange Server 35

40 v DATE v DATESTRING v DOUBLE v DOUBSTRING v FLOAT v FLTSTRING v INTEGER v INTSTRING v INVALID_TYPE_NUM v INVALID_TYPE_STRING v LONGTEXT v LONGTEXTSTRING v MULTIPLECARDSTRING v OBJECT v SINGLECARDSTRING v STRING v STRSTRING v equals(object):boolean v getapptext():string v getcardinality():string v getdefault():string v getmaxlength():int v getname():string v getrelationtype():string v gettypename():string v gettypenum():string v hascardinality(string):boolean v hasname(string):boolean v hastype(string):boolean v isforeignkeyattr():boolean v iskeyattr():boolean v ismultiplecard():boolean v isobjecttype():boolean v isrequiredattr():boolean v istype(object):boolean CxObjectContainerInterface CxCommon/ v getbusinessobject(int):businessobjectinterface v getobjectcount():int v insertbusinessobject(businessobjectinterface) v removeallobjects() v removebusinessobjectat(int) v setbusinessobject(int, BusinessObjectInterface) 36 WebSphere Integration Developer: Migration Guide

41 DtpConnection Dtp/ CxCommon/ v begintran() v commit() v executesql(string) v executesql(string, Vector) v executestoredprocedure(string, Vector) v getupdatecount():int v hasmorerows():boolean v intransaction():boolean v isactive():boolean v nextrow():vector v rollback() DtpDataConversion Dtp/ CxCommon/ v BOOL_TYPE - 4 v CANNOTCONVERT - 2 v DATE_TYPE - 5 v DOUBLE_TYPE - 3 v FLOAT_TYPE - 2 v INTEGER_TYPE - 0 v LONGTEXT_TYPE - 6 v OKTOCONVERT - 0 v POTENTIALDATALOSS - 1 v STRING_TYPE - 1 v UNKNOWN_TYPE v gettype(double):int v gettype(float):int v gettype(int):int v gettype(object):int v isoktoconvert(int, int):int v isoktoconvert(string, String):int v toboolean(boolean):boolean v toboolean(object):boolean v todouble(double):double v todouble(float):double v todouble(int):double v todouble(object):double v tofloat(double):float v tofloat(float):float v tofloat(int):float v tofloat(object):float v tointeger(double):integer Chapter 3. Migrating from WebSphere InterChange Server 37

42 v tointeger(float):integer v tointeger(int):integer v tointeger(object):integer v toprimitiveboolean(object):boolean v toprimitivedouble(float):double v toprimitivedouble(int):double v toprimitivedouble(object):double v toprimitivefloat(double):float v toprimitivefloat(int):float v toprimitivefloat(object):float v toprimitiveint(double):int v toprimitiveint(float):int v toprimitiveint(object):int v tostring(double):string v tostring(float):string v tostring(int):string v tostring(object):string DtpDate Dtp/ CxCommon/ v DtpDate() v DtpDate(long, boolean) v DtpDate(String, String) v DtpDate(String, String, String[], String[]) v adddays(int):dtpdate v addmonths(int):dtpdate v addweekdays(int):dtpdate v addyears(int):dtpdate v after(dtpdate):boolean v before(dtpdate):boolean v calcdays(dtpdate):int v calcweekdays(dtpdate):int v get12monthnames():string[] v get12shortmonthnames():string[] v get7daynames():string[] v getcwdate():string v getdayofmonth():string v getdayofweek():string v gethours():string v getintday():int v getintdayofweek():int v getinthours():int v getintmilliseconds():int v getintminutes():int v getintmonth():int 38 WebSphere Integration Developer: Migration Guide

43 v getintseconds():int v getintyear():int v getmaxdate(busobjarray, String, String):DtpDate v getmaxdatebo(busobj[], String, String):BusObj[] v getmaxdatebo(busobjarray, String, String):BusObj[] v getmindate(busobjarray, String, String):DtpDate v getmindatebo(busobj[], String, String):BusObj[] v getmindatebo(busobjarray, String, String):BusObj[] v getminutes():string v getmonth():string v getmssince1970():long v getnumericmonth():string v getseconds():string v getshortmonth():string v getyear():string v set12monthnames(string[], boolean) v set12monthnamestodefault() v set12shortmonthnames(string[]) v set12shortmonthnamestodefault() v set7daynames(string[]) v set7daynamestodefault() v tostring():string v tostring(string):string v tostring(string, boolean):string DtpMapService Dtp/ CxCommon/ v runmap(string, String, BusObj[], CxExecutionContext):BusObj[] DtpSplitString Dtp/ CxCommon/ v DtpSplitString(String, String) v elementat(int):string v firstelement():string v getelementcount():int v getenumeration():enumeration v lastelement():string v nextelement():string v prevelement():string v reset() DtpUtils Dtp/ CxCommon/ v padleft(string, char, int):string Chapter 3. Migrating from WebSphere InterChange Server 39

44 v padright(string, char, int):string v stringreplace(string, String, String):String v truncate(double):int v truncate(double, int):double v truncate(float):int v truncate(float, int):double v truncate(object):int v truncate(object, int):double BusObjInvalidVerbException (extends InterchangeExceptions) Exceptions/ CxCommon/ v getformattedmessage() IdentityRelationship relationship/ utilities/ crossworlds/ com/ v addmychildren(string, String, BusObj, String, Object, CxExecutionContext) v deletemychildren(string, String, BusObj, String, CxExecutionContext) v deletemychildren(string, String, BusObj, String, Object, CxExecutionContext) v foreignkeylookup(string, String, BusObj, String, BusObj, String, CxExecutionContext) v foreignkeyxref(string, String, String, BusObj, String, BusObj, String, CxExecutionContext) v maintainchildverb(string, String, String, BusObj, String, BusObj, String, CxExecutionContext, boolean, boolean) v maintaincompositerelationship(string, String, BusObj, Object, CxExecutionContext) v maintainsimpleidentityrelationship(string, String, BusObj, BusObj, CxExecutionContext) v updatemychildren(string, String, BusObj, String, String, String, String, CxExecutionContext) MapExeContext Dtp/ CxCommon/ v ACCESS_REQUEST - "SUBSCRIPTION_DELIVERY" v ACCESS_RESPONSE - "ACCESS_RETURN_REQUEST" v EVENT_DELIVERY - "SUBSCRIPTION_DELIVERY" v SERVICE_CALL_FAILURE - "CONSUME_FAILED" v SERVICE_CALL_REQUEST - "CONSUME" v SERVICE_CALL_RESPONSE - "DELIVERBUSOBJ" v getconnname():string v getgenericbo():busobj v getinitiator():string v getlocale():java.util.locale v getoriginalrequestbo():busobj v setconnname(string) v setinitiator(string) v setlocale(java.util.locale) 40 WebSphere Integration Developer: Migration Guide

45 Participant RelationshipServices/ Server/ v Participant(String, String, int, BusObj) v Participant(String, String, int, String) v Participant(String, String, int, long) v Participant(String, String, int, int) v Participant(String, String, int, double) v Participant(String, String, int, float) v Participant(String, String, int, boolean) v Participant(String, String, BusObj) v Participant(String, String, String) v Participant(String, String, long) v Participant(String, String, int) v Participant(String, String, double) v Participant(String, String, float) v Participant(String, String, boolean) v getboolean():boolean v getbusobj():busobj v getdouble():double v getfloat():float v getinstanceid():int v getint():int v getlong():long v getparticipantdefinition():string v getrelationshipdefinition():string v getstring():string INVALID_INSTANCE_ID v set(boolean) v set(busobj) v set(double) v set(float) v set(int) v set(long) v set(string) v setinstanceid(int) v setparticipantdefinition(string) v setrelationshipdefinition(string) v setparticipantdefinition(string) v setrelationshipdefinition(string) Relationship RelationshipServices/ Server/ v addmychildren(string, String, BusObj, String, Object, CxExecutionContext) v addparticipant(participant):int v addparticipant(string, String, boolean):int Chapter 3. Migrating from WebSphere InterChange Server 41

46 v addparticipant(string, String, BusObj):int v addparticipant(string, String, double):int v addparticipant(string, String, float):int v addparticipant(string, String, int):int v addparticipant(string, String, int, boolean):int v addparticipant(string, String, int, BusObj):int v addparticipant(string, String, int, double):int v addparticipant(string, String, int, float):int v addparticipant(string, String, int, int):int v addparticipant(string, String, int, long):int v addparticipant(string, String, int, String):int v addparticipant(string, String, long):int v addparticipant(string, String, String):int v create(participant):int v create(string, String, boolean):int v create(string, String, BusObj):int v create(string, String, double):int v create(string, String, float):int v create(string, String, int):int v create(string, String, long):int v create(string, String, String):int v deactivateparticipant(participant) v deactivateparticipant(string, String, boolean) v deactivateparticipant(string, String, BusObj) v deactivateparticipant(string, String, double) v deactivateparticipant(string, String, float) v deactivateparticipant(string, String, int) v deactivateparticipant(string, String, long) v deactivateparticipant(string, String, String) v deactivateparticipantbyinstance(string, String, int) v deactivateparticipantbyinstance(string, String, int, boolean) v deactivateparticipantbyinstance(string, String, int, BusObj) v deactivateparticipantbyinstance(string, String, int, double) v deactivateparticipantbyinstance(string, String, int, float) v deactivateparticipantbyinstance(string, String, int, int) v deactivateparticipantbyinstance(string, String, int, long) v deactivateparticipantbyinstance(string, String, int, String) v deletemychildren(string, String, BusObj, String, CxExecutionContext) v deletemychildren(string, String, BusObj, String, Object, CxExecutionContext) v deleteparticipant(participant) v deleteparticipant(string, String, boolean) v deleteparticipant(string, String, BusObj) v deleteparticipant(string, String, double) v deleteparticipant(string, String, float) v deleteparticipant(string, String, int) 42 WebSphere Integration Developer: Migration Guide

47 v deleteparticipant(string, String, long) v deleteparticipant(string, String, String) v deleteparticipantbyinstance(string, String, int) v deleteparticipantbyinstance(string, String, int, boolean) v deleteparticipantbyinstance(string, String, int, BusObj) v deleteparticipantbyinstance(string, String, int, double) v deleteparticipantbyinstance(string, String, int, float) v deleteparticipantbyinstance(string, String, int, int) v deleteparticipantbyinstance(string, String, int, long) v deleteparticipantbyinstance(string, String, int, String) v getnewid(string):int v maintaincompositerelationship(string, String, BusObj, Object, CxExecutionContext) v maintainsimpleidentityrelationship(string, String, BusObj, BusObj, CxExecutionContext) v retrieveinstances(string, boolean):int[] v retrieveinstances(string, BusObj):int[] v retrieveinstances(string, double):int[] v retrieveinstances(string, float):int[] v retrieveinstances(string, int):int[] v retrieveinstances(string, long):int[] v retrieveinstances(string, String):int[] v retrieveinstances(string, String, boolean):int[] v retrieveinstances(string, String, BusObj):int[] v retrieveinstances(string, String, double):int[] v retrieveinstances(string, String, float):int[] v retrieveinstances(string, String, int):int[] v retrieveinstances(string, String, long):int[] v retrieveinstances(string, String, String):int[] v retrieveinstances(string, String[], boolean):int[] v retrieveinstances(string, String[], BusObj):int[] v retrieveinstances(string, String[], double):int[] v retrieveinstances(string, String[], float):int[] v retrieveinstances(string, String[], int):int[] v retrieveinstances(string, String[], long):int[] v retrieveinstances(string, String[], String):int[] v retrieveparticipants(string):participant[] v retrieveparticipants(string, String):Participant[] v retrieveparticipants(string, String[]):Participant[] v retrieveparticipants(string, int):participant[] v retrieveparticipants(string, String, int):participant[] v retrieveparticipants(string, String[], int):participant[] v updatemychildren(string, String, BusObj, String, String, String, String, CxExecutionContext) v updateparticipant(string, String, BusObj) v updateparticipantbyinstance(participant) v updateparticipantbyinstance(string, String, int) v updateparticipantbyinstance(string, String, int, BusObj) Chapter 3. Migrating from WebSphere InterChange Server 43

48 UserStoredProcedureParam Dtp/ CxCommon/ v UserStoredProcedureParam(int, String, Object, String, String) v getparamdatatypejavaobj():string v getparamdatatypejdbc():int v getparamindex():int v getparamiotype():string v getparamname():string v getparamvalue():object v setparamdatatypejavaobj(string) v setparamdatatypejdbc(int) v setparamindex(int) v setparamiotype(string) v setparamname(string) v setparamvalue(object) v PARAM_TYPE_IN - "IN" v PARAM_TYPE_OUT - "OUT" v PARAM_TYPE_INOUT - "INOUT" v DATA_TYPE_STRING - "String" v DATA_TYPE_INTEGER - "Integer" v DATA_TYPE_DOUBLE - "Double" v DATA_TYPE_FLOAT - "Float" v DATA_TYPE_BOOLEAN - "Boolean" v DATA_TYPE_TIME - "java.sql.time" v DATA_TYPE_DATE - "java.sql.date" v DATA_TYPE_TIMESTAMP - "java.sql.timestamp" v DATA_TYPE_BIG_DECIMAL - "java.math.bigdecimal" v DATA_TYPE_LONG_INTEGER - "Long" v DATA_TYPE_BINARY - "byte[]" v DATA_TYPE_CLOB - "Clob" v DATA_TYPE_BLOB - "Blob" v DATA_TYPE_ARRAY - "Array" v DATA_TYPE_STRUCT - "Struct" v DATA_TYPE_REF - "Ref" BaseCollaboration Collaboration/ v BaseCollaboration(com.ibm.bpe.api.ProcessInstanceData) v AnyException - "AnyException" v AppBusObjDoesNotExist - "BusObjDoesNotExist" v AppLogOnFailure - "AppLogOnFailure" v AppMultipleHits - "AppMultipleHits" v AppRequestNotYetSent - "AppRequestNotYetSent" v AppRetrieveByContentFailed - "AppRetrieveByContent" v AppTimeOut - "AppTimeOut" 44 WebSphere Integration Developer: Migration Guide

49 v AppUnknown - "AppUnknown" v AttributeException - "AttributeException" v existsconfigproperty(string):boolean v getconfigproperty(string):string v getconfigpropertyarray(string):string[] v getcurrentloopindex():int v getdbconnection(string):cwdbconnection v getdbconnection(string, boolean):cwdbconnection getlocale():java.util.locale v getmessage(int):string v getmessage(int, Object[]):String v getname():string v implicitdbtransactionbracketing():boolean v iscallerinrole(string):boolean v istraceenabled(int):boolean v JavaException - "JavaException" v logerror(int) v logerror(int, Object[]) v logerror(int, String) v logerror(int, String, String) v logerror(int, String, String, String) v logerror(int, String, String, String, String) v logerror(int, String, String, String, String, String) v logerror(string) v loginfo(int) v loginfo(int, Object[]) v loginfo(int, String) v loginfo(int, String, String) v loginfo(int, String, String, String) v loginfo(int, String, String, String, String) v loginfo(int, String, String, String, String, String) v loginfo(string) v logwarning(int) v logwarning(int, Object[]) v logwarning(int, String) v logwarning(int, String, String) v logwarning(int, String, String, String) v logwarning(int, String, String, String, String) v logwarning(int, String, String, String, String, String) v logwarning(string) v not(boolean):boolean ObjectException - "ObjectException" v OperationException - "OperationException" v raiseexception(collaborationexception) v raiseexception(string, int) v raiseexception(string, int, Object[]) v raiseexception(string, int, String) Chapter 3. Migrating from WebSphere InterChange Server 45

50 v raiseexception(string, int, String, String) v raiseexception(string, int, String, String, String) v raiseexception(string, int, String, String, String, String) v raiseexception(string, int, String, String, String, String, String) v raiseexception(string, String) v ServiceCallException - "ConsumerException" v ServiceCallTransportException - "ServiceCallTransportException" v SystemException - "SystemException" v trace(int, int) v trace(int, int, Object[]) v trace(int, int, String) v trace(int, int, String, String) v trace(int, int, String, String, String) v trace(int, int, String, String, String, String) v trace(int, int, String, String, String, String, String) v trace(int, String) v trace(string) v TransactionException - "TransactionException" CxExecutionContext CxCommon/ v CxExecutionContext() v getcontext(string):object v MAPCONTEXT - "MAPCONTEXT" v setcontext(string, Object) CollaborationException Collaboration/ v getmessage():string v getmsgnumber():int v getsubtype():string v gettext():string v gettype():string v tostring():string Filter crossworlds/ com/ v Filter(BaseCollaboration) v filterexcludes(string, String):boolean v filterincludes(string, String):boolean v recursefilter(busobj, String, boolean, String, String):boolean v recurseprereqs(string, Vector):int Globals crossworlds/ com/ v Globals(BaseCollaboration) 46 WebSphere Integration Developer: Migration Guide

51 v callmap(string, BusObj):BusObj SmartCollabService crossworlds/ com/ v SmartCollabService() v SmartCollabService(BaseCollaboration) v doagg(busobj, String, String, String):BusObj v domergehash(vector, String, String):Vector v dorecursiveagg(busobj, String, String, String):BusObj v dorecursivesplit(busobj, String):Vector v dorecursivesplit(busobj, String, boolean):vector v getkeyvalues(busobj, String):String v merge(vector, String):BusObj v merge(vector, String, BusObj):BusObj v split(busobj, String):Vector StateManagement crossworlds/ com/ v StateManagement() v begintransaction() v commit() v deletebo(string, String, String) v deletestate(string, String, String, int) v persistbo(string, String, String, String, BusObj) v recoverbo(string, String, String):BusObj v releasedbconnection() v resetdata() v retrievestate(string, String, String, int):int v savestate(string, String, String, String, int, int, double) v setdbconnection(cwdbconnection) v updatebo(string, String, String, String, BusObj) v updatestate(string, String, String, String, int, int) EventKeyAttrDef EventManagement/ CxCommon/ v EventKeyAttrDef() v EventKeyAttrDef(String, String) v public String keyname v public String keyvalue EventQueryDef EventManagement/ CxCommon/ v EventQueryDef() v EventQueryDef(String, String, String, String, int) Chapter 3. Migrating from WebSphere InterChange Server 47

52 v public String nameconnector v public String namecollaboration v public String namebusobj v public String verb v public int ownertype FailedEventInfo EventManagement/ CxCommon/ v FailedEventInfo() v FailedEventInfo(String x6, int, EventKeyAttrDef[], int, int, String, String, int) v public String nameowner v public String nameconnector v public String namebusobj v public String nameverb v public String strtime v public String strmessage v public int wipindex v public EventKeyAttrDef[] strbusobjkeys v public int nkeys v public int eventstatus v public String expirationtime v public String scenarioname v public int scenariostate Mapping the WebSphere Process Sever DataObject from WebSphere InterChange Server XML If you use the Legacy Adapters to connect to WebSphere Process Server, the following algorithm will enable you to further understand how the WebSphere Process Sever DataObject was created from the WebSphere InterChange Server XML. This information shows where the data values have been placed, and also what data values have been chosen to replace the ones used in WebSphere InterChange Server. General v For setting the verb in the ChangeSummary, all settings will be done with the markcreate/update/ Delete APIs. v For setting the verb in the ChangeSummary/EventSummary, Create, Update, and Delete verbs will be set in the ChangeSummary, while all other verbs will be set in the EventSummary. v For getting the verb from the ChangeSummary: If isdelete is true, the verb will be Delete. Note: The value of iscreate will be ignored if isdelete is true. This could happen if the creation was marked before the DataObject entered the hub at which point it was deleted, or if the creation and deletion both occurred in the hub. If isdelete is false and iscreate is true, the verb will be Create. If isdelete is false and iscreate is false, the verb will be Update. v To avoid a DataObject being identified as Create instead of an intended Update, if logging is enabled, you must: Suspend logging during the creation of the DataObject. 48 WebSphere Integration Developer: Migration Guide

53 Resume logging for the update of the DataObject (or use the markupdated API). Loading Loading will load a WebSphere InterChange Server runtime XML into a WebSphere Business Integration BusinessGraph AfterImage instance. v An instance of the appropriate BusinessGraph will be created. v ChangeSummary Logging will be turned on, so that turning it on later will not clear the entries. v ChangeSummary Logging will be paused to prevent unwanted information from entering the ChangeSummary. v The attributes of the top level BusinessObject will be created in the DataObject (see the section "Attribute processing" below). v If the top level BusinessObject has children BusinessObjects, these will be processed recursively. v The attributes of these children BusinessObjects will be created in the DataObject (see the section "Attribute processing" below). v The verb of the top level BusinessObject will be set to the top level verb of the BusinessGraph and set in the summaries. v The verb of the children BusinessObjects will be set in the summaries. Saving Saving will save a WebSphere Business Integration BusinessGraph AfterImage instance to a WebSphere InterChange Server runtime XML. An exception will be thrown if the input BusinessGraph is not AfterImage. v An instance of the WebSphere InterChange Server XML document will be created. v All deleted DataObjects in the ChangeSummary will be treated as if they existed in their original positions. Note: This undelete process will not preserve list order. v The verb for the top level BusinessObject will be set to the top level verb of the BusinessGraph. v The attributes of the top level BusinessObject will be set from the DataObject (see the section "Attribute processing" below). v If the DataObject has children DataObjects, these will be processed recursively. v The verb of the children DataObjects will be handled in the following manner: If there is no verb for the child DataObject in the EventSummary or ChangeSummary, the verb will be set to "" (empty string). If there is a verb present in the EventSummary, but not in the ChangeSummary, this verb will be used. If there is a verb present in the ChangeSummary, but not in the EventSummary, this verb will be used. If there is a verb present in both the ChangeSummary and EventSummary, it will be resolved in that the value in the ChangeSummary will be chosen over that in the EventSummary. v The attributes of the children DataObjects will be set in the BusinessObject (see the section "Attribute processing" below). Attribute processing v All values not covered below will be loaded/saved ASIS. v ObjectEventId will be loaded into/saved from the EventSummary. v For CxBlank and CxIgnore: Chapter 3. Migrating from WebSphere InterChange Server 49

54 On the WebSphere Business Integration BusinessObject side of the conversion, CxBlank and CxIgnore will be set/identified as follows: - CxIgnore - unset or set with the Java value of null - CxBlank - type dependent value as shown in the table below On the WebSphere InterChange Server XML side of the conversion, CxBlank and CxIgnore will be set/identified as follows: Table 1. Setting CxBlank and CxIgnore Type CxIgnore CxBlank Int Integer.MIN_VALUE Integer.MAX_VALUE Float Float.MIN_VALUE Float.MAX_VALUE Double Double.MIN_VALUE Double.MAX_VALUE String/date/longtext CxIgnore Children BusinessObjects (empty element) N/A 50 WebSphere Integration Developer: Migration Guide

55 Chapter 4. Migrating to WebSphere Integration Developer from WebSphere MQ Workflow WebSphere Integration Developer provides the necessary tools to migrate from WebSphere MQ Workflow. The Migration wizard converts the FDL definitions of business processes that you exported from the build time component of WebSphere MQ Workflow into corresponding artifacts in WebSphere Integration Developer. The generated artifacts comprise XML schema definitions for business objects, WSDL definitions, BPEL, import and component definitions, and TEL definitions. The conversion tool requires a semantically complete FDL definition of a process model that you export from WebSphere MQ Workflow build time with the option export deep. This option ensures that all necessary data, program, and subprocess specifications are included. Also, ensure that any user defined process execution server definitions (UPES) referenced in your WebSphere MQ Workflow process model are also selected when you export FDL from the WebSphere MQ Workflow build time. Note: The Migration wizard does not cover the migration of: v WebSphere MQ Workflow runtime instances v Program applications that are invoked by a WebSphere MQ Workflow program execution agent (PEA) or WebSphere MQ Workflow process execution server (PES for z/os) For more information on migrating using the FDL2BPEL conversion tool, see WebSphere MQ Workflow support site. Preparing for migration from WebSphere MQ Workflow Before migrating to WebSphere Integration Developer from WebSphere MQ Workflow, you must first ensure that you have properly prepared your environment. The scope and completeness of mapping depends on how you adhere to the following guidelines for migration: v Ensure that FDL program activities are associated to a user defined process execution server (UPES) if they are not pure staff activities. v Ensure that staff assignments for WebSphere MQ Workflow program activities are compliant to TEL default staff verbs. v Use short and simple names to improve the readability of migrated process models. Note that FDL names may be illegal BPEL names. The Migration wizard automatically converts FDL names to valid BPEL names. The Migration wizard will produce syntactically correct business process editor constructs even for WebSphere MQ Workflow constructs that cannot be migrated (PEA or PES program activities, some dynamic staff assignments, and so on), which need to be manually adapted to runnable business process editor artifacts. The following table outlines the applied mapping rules: Table 2. Mapping rules WebSphere MQ Workflow Process WebSphere Integration Developer Process with execution mode: longrunning; Partner links for inbound and outbound interfaces of process Copyright IBM Corp. 2005,

56 Table 2. Mapping rules (continued) WebSphere MQ Workflow Source and Sink Program activity Process activity Empty activity Block Exit condition of activity Start condition of activity Staff assignment of activity Input container and output container of activity Control connector; Transition condition Data connector Global data container WebSphere Integration Developer Variables for process input and process output; Receive activity and reply activity Invoke activity Invoke activity FMCINTERNALNOOP activity Scope with embedded BPEL activities While activity (enclosing the actual activity) Join condition of activity Human task activity Variables used to specify the input/output of invoke activity Link; Transition condition Assign activity Variable Note: You should initially try the migration process with small projects, if possible. The Migration wizard will simplify the conversion of your WebSphere MQ Workflow process models into business process editor process models, but you should be aware that the processes cannot be mapped one-to-one as you are creating a new programming model. The semantic scopes of the underlying process specification languages (FDL and BPEL) share an area of intersection, but they do not overlap in total. Otherwise, you could not expect any new benefits from business process editor. Web services represent a promising new technology that claim replacing deprecated solutions by new ones. In general, you should always review and possibly modify the generated artifacts. Additional effort may be necessary to either make a successful migration possible or to complete the migration task. Migrating WebSphere MQ Workflow using the Migration wizard The Migration wizard enables you to convert FDL definitions of business processes that you exported from the build time component of WebSphere MQ Workflow into corresponding artifacts in WebSphere Integration Developer. The generated artifacts comprise XML schema definitions for business objects, WSDL definitions, BPEL, import and component definitions, and TEL definitions. Note: The Migration wizard does not cover the migration of: v WebSphere MQ Workflow runtime instances v Program applications that are invoked by a WebSphere MQ Workflow program execution agent (PEA) or WebSphere MQ Workflow process execution server (PES for z/os) To use the Migration wizard to migrate your WebSphere MQ Workflow artifacts, follow these steps: 1. Invoke the wizard by selecting File > Import > Business Integration > WebSphere MQ Workflow FDL File and click Next. 2. The Migration wizard opens. Enter the absolute path and name of the FDL file into the Source selection field or select one from the file system by clicking the Browse button and navigating to the file. You must also provide a module name before proceeding. Click Next: 52 WebSphere Integration Developer: Migration Guide

57 3. The WebSphere MQ Workflow Migration Options page for the artifact creation settings opens. From here you can accept the migration defaults or select a check box to change the option. By selecting the Treat name conflicts as errors check box, you can prevent the automatic addition of suffixes which could result in interoperability errors. The Create predefined data members check box adds extra nodes to the process to initialize the predefined data members: 4. Click Next. The WebSphere MQ Workflow Migration Options page for optimizing the migrated business processes opens: Chapter 4. Migrating from WebSphere MQ Workflow 53

58 From this page you can set the options to optimize the migrated business processes. For more information on these options, see the topic "Optimizing the migrated business processes" in the related links below or click F1 when selecting or deselecting each item. 5. Once you have selected and reviewed your optimization choices, click Finish. A progress bar at the bottom of the migration dialog indicates the progress of the migration. Once the migration process has completed, the migration dialog disappears and the Migration Results window opens: 54 WebSphere Integration Developer: Migration Guide

59 To keep all messages for future reference, click the Generate ToDo's button to create a list of "ToDo" tasks in the task view or click the Save as button to save the messages in a text file in the file system. Examine each message to see if any action needs to be taken to immediately fix an artifact that couldn't be fully migrated. To see the generated To Do's, click Window > Show View > Other > General > Tasks and click OK. The Tasks view opens with the list of generated To Do's from the migration process. Optimizing the migrated business processes During the migration of business processes, there are a number of optimization options that will aid in the overall efficiency, performance and usability of your migrated business process. For example, you can reduce the number of Java snippets, remove unnecessary structural elements, and reduce the number of BPEL variables through the optimization options in the Migration wizard. The following table details the WebSphere MQ Workflow migration optimization options and the associated results for each: Table 3. WebSphere MQ Workflow migration optimization options Option Result Merge adjacent Java snippets Selecting this check box will optimize the business process by combining Java snippets where possible (serial, parallel, or mixed). The process will run more efficiently as the variables are shared in one Java snippet and duplicate code pieces can be eliminated. Remove unnecessary structural elements Not selecting this check box means that the process is still valid, however, this will result in many single Java snippets in the BPEL process. Selecting this check box will optimize the business process by removing structural elements. Unnecessary nesting of structural BPEL activities is not efficient for the process flow. Chapter 4. Migrating from WebSphere MQ Workflow 55

60 Table 3. WebSphere MQ Workflow migration optimization options (continued) Option Result Reduce the number of variables Selecting this check box will optimize the business process by reducing the number of BPEL variables. Use the slide bar to select the reduction level. When migrating an FDL process to BPEL, many BPEL variables are created based on FDL variables. You can suppress all, some, or none of the FDL variables to be transferred to the BPEL process. v Variable reduction level 0: This option allows the minimum share of variables. This will merge the corresponding FDL variables of output and input containers into one BPEL variable. v Variable reduction level 1: This option allows the moderate share of variables. This will merge the corresponding FDL variables of output and input containers into one BPEL variable. It will also share variables while tolerating potential conflict with the predefined data member "Priority". v Variable reduction level 2: This option allows the medium share of variables. This will merge the corresponding FDL variables of output and input containers into one BPEL variable. It will also share variables while tolerating potential conflicts with the predefined data members "Priority" and "Notification". Note: In rare cases, a BPEL variable is shared incorrectly. In such cases, run the migration again with a decreased optimization level. v Variable reduction level 3: This option allows nearly all possible variables to be shared. This will merge the corresponding FDL variables of output and input containers into one BPEL variable. It will also share variables while tolerating potential conflicts with the predefined data members "Priority", "Notification", and "Staff". Note: In rare cases, a BPEL variable is shared incorrectly. In such cases, run the migration again with a decreased optimization level. v Variable reduction level 4: This option allows as many as possible variables to be shared. This will merge the corresponding FDL variables of output and input containers into one BPEL variable. It will also share variables while tolerating potential conflicts with the predefined data members "Priority", "Notification", "Staff", and default data settings. Note: In rare cases, a BPEL variable is shared incorrectly. In such cases, run the migration again with a decreased optimization level. For more information regarding optimization options as well as for information about the command line tool for MQ Workflow migration, see the WebSphere Process Server support site. 56 WebSphere Integration Developer: Migration Guide

61 Verifying the WebSphere MQ Workflow migration If the migration completes with a list of errors, warnings, or informational messages, they will be displayed in the Migration Results window. Otherwise, the wizard window will close if the migration was successfully completed. The following page appears if migration messages were generated during the migration process: The Migration Results window lists the migration messages that were generated during the migration process. By selecting a message from the upper Message list, you can find more information regarding that message in the lower Message Description window. To keep all messages for future reference, click the Generate ToDo's button to create a list of "ToDo" tasks in the task view or click the Save as button to save the messages in a text file in the file system. Examine each message to see if any action needs to be taken to immediately fix an artifact that couldn t be fully migrated. To see the generated To Do's, click Window > Show View > Other > General > Tasks and click OK. The Tasks view opens with the list of generated To Do's from the migration process. Limitations of the migration process (from WebSphere MQ Workflow) There are certain limitations involved with the WebSphere MQ Workflow migration process. v The migration of FDL will generate invoke activities for UPES activities and the corresponding WSDLs. However, the runtime environment significantly differs between IBM WebSphere MQ Workflow an IBM WebSphere Process Server in terms of the techniques that are used to correlate invocation messages and their responses. v The runtime engines of IBM WebSphere MQ Workflow and IBM WebSphere Process Server handle uninitialized data differently. While in IBM WebSphere MQ Workflow this did not cause errors, IBM WebSphere Process Server is handling this situation with an exception and stops executing the process. To run migrated applications correctly in IBM WebSphere Process Server, ensure that all variables and sub-structures are initialized before they are used with Assign, Invoke, Staff, and Reply activities. Chapter 4. Migrating from WebSphere MQ Workflow 57

62 58 WebSphere Integration Developer: Migration Guide

63 Chapter 5. Migrating from WebSphere Studio Application Developer Integration Edition Source artifacts for WebSphere Business Integration Server Foundation (WBISF) 5.1 projects can be migrated from WebSphere Studio Application Developer Integration Edition to WebSphere Integration Developer. Migrating the source artifacts in an application involves migrating them to the new WebSphere Integration Developer programming model so that new functionality and features can be used. The application can then be redeployed and installed to the WebSphere Process Server. Supported migration paths for migrating source artifacts Before migrating source artifacts from WebSphere Studio Application Developer Integration Edition, ensure that the workspaces with WebSphere Business Integration Server Foundation projects contain one or more service projects. The Migration wizard offers the ability to migrate one WebSphere Studio Application Developer Integration Edition Version 5.1 (or above) workspace at a time. The Migration wizard does not migrate application binaries it will only migrate source artifacts found in a WebSphere Studio Application Developer Integration Edition workspace. Preparing source artifacts for migration Before migrating source artifacts to WebSphere Integration Developer from WebSphere Studio Application Developer Integration Edition, you must first ensure that you have properly prepared your environment for the migration process. The following steps describe how to prepare your environment before migrating source artifacts to WebSphere Integration Developer from WebSphere Studio Application Developer Integration Edition: 1. Ensure that you have a backup copy of the entire 5.1 workspace before attempting to migrate. 2. Review the Web service section of the Rational Application Developer Information Center for background information on the Web service functionality provided by Rational Application Developer: Developing Web services 3. Ensure that you have all of the appropriate WebSphere Integration Developer features enabled. If you do not have these features enabled, the menu options that will be discussed below may not be visible. To enable the important features: v In WebSphere Integration Developer, select Window > Preferences. v Click General and select the Capabilities category. v Select all features under the following categories: Enterprise Java Developer Integration Developer Java Developer Web Developer (typical) Web Service Developer XML Developer v Click OK. 4. Use a new workspace as the migration target workspace. 5. By default, WebSphere Integration Developer generates the deploy code during build time for the supporting WEB, EJB and EAR projects for WebSphere Integration Developer modules. Copyright IBM Corp. 2005,

64 Note: The deploy code for other projects (for example, J2EE) are not generated. 6. In order to fully migrate the BPEL files within a workspace, you must ensure that all WSDL and XSD files referenced by the BPEL files can be resolved in a business integration project in the new workspace: v If the WSDL or XSD files are either in the current project, referenced project, or in a common library with the BPEL file, then no further action is required. v If the WSDL or XSD files are in a different project than the one you are migrating, the 5.1 artifacts must be reorganized using WebSphere Studio Application Developer Integration Edition prior to migration because Business Integration (BI) module projects cannot share artifacts. Here are the two options for reorganizing the 5.1 artifacts: In WebSphere Studio Application Developer Integration Edition, create a new Java project that will hold all the common artifacts. Place all WSDL and XSD files that are shared by more than one project into this new Java project. Add a dependency on this new Java project to all projects that use these common artifacts. Another option is to keep a local copy of these shared WSDL and XSD artifacts in each project such that there are no dependencies between projects. v If the WSDL or XSD files are in any other type of project (often other Java Projects), you should create a Business Integration library project with the same name as the 5.1 project. You should also set up the class path for the new library project, adding the entries from the 5.1 Java project if any. This type of project is useful for storing shared artifacts. Note that two WSDL files cannot define porttype, service, or port with the same name and target namespace. This should be manually fixed before migration to avoid errors. Note: WebSphere Integration Developer does not support XML-SOAP types as defined in the namespace. You should remove references to these types in WebSphere Studio Application Developer Integration Edition prior to migrating to avoid a migration process failure. You are now ready to begin the migration process. Pre-migration considerations There are a number of considerations for the WebSphere Studio Application Developer Integration Edition source artifact migration process. The following practices show how to design WebSphere Studio Application Developer Integration Edition services to ensure that they will migrate successfully to the new programming model: v For WebSphere Integration Developer V or earlier, all projects must be removed from the target WebSphere Integration Developer workspace and all folders and files must be removed from the workspace folder on the file system. Note that this restriction does not apply for WebSphere Integration Developer or later. v WebSphere Studio Application Developer Integration Edition project types supported by the Migration wizard are: Service Projects, Java Projects, EJB Projects, Connector Projects, Enterprise Application Projects, Application Client Projects, Dynamic Web Projects, and Static Web Projects. Any other project types that might exist in WebSphere Studio Application Developer Integration Edition will be copied to the WebSphere Integration Developer workspace, but will not have any processing for migration. v Try to use the Assign activity wherever possible (as opposed to the transformer service which is only needed when an advanced transformation is needed). You should use this practice because intermediate componentry must be constructed in order for the an SCA module to invoke a transformer service. Additionally, there is no special tools support in WebSphere Integration Developer for the transformer services created in 5.1 (you must use the WSDL or XML editor to modify the XSLT embedded in the WSDL file if you need to change the behavior of the transformer service). v Specify one part per WSDL message if the WSDL is a document style as per the Web Services Interoperability (WS-I) spec and the 6.x preferred style. This does not apply to RPC style WSDLs. 60 WebSphere Integration Developer: Migration Guide

65 v Use the WSDL doc-literal style as this is the preferred style in 6.x. v Ensure that all complex types are given a name and that each complex type can be uniquely identified by its target namespace and name. The following example shows the recommended way to define complex types and elements of that type (complex type definition followed by an element definition that uses it): <schema attributeformdefault="qualified" elementformdefault="unqualified" targetnamespace=" xmlns=" xmlns:tns=" <complextype name="duration"> <all> <element name="hours" type="int"/> <element name="minutes" type="int"/> <element name="days" type="int"/> </all> </complextype> <element name="durationelement" type="tns:duration"/> </schema> The following example is an anonymous complex type that should be avoided as it can cause problems when an SDO is serialized to XML (element containing an anonymous complex type definition): <schema attributeformdefault="qualified" elementformdefault="unqualified" targetnamespace=" xmlns=" xmlns:tns=" <element name="durationelement"> <complextype> <all> <element name="hours" type="int"/> <element name="minutes" type="int"/> <element name="days" type="int"/> </all> </complextype> </element> </schema> v If publishing a service for external consumers, generate service deploy code using IBM Web services (as opposed to Apache SOAP/HTTP) because IBM Web services are directly supported in 6.x and Apache Web services are not. v There are two ways to organize WSDL and XSD files in 5.1 to minimize the amount of reorganizing you must do during migration. In 6.x, shared artifacts such as WSDL and XSD files must be located in BI projects (Business Integration modules and libraries) in order to be referenced by a BI service: Keep all WSDL files shared by more than one project in a Java project that the workspace can reference. Keep a local copy of all WSDL/XSD files that a project references in the project itself. WebSphere Studio Application Developer Integration Edition projects will be migrated to a Business Integration module in WebSphere Integration Developer and a module cannot have dependencies on other modules (a project with dependencies on another project for the sake of sharing WSDL or XSD files will not migrate cleanly). v Avoid using the Business Process Choreographer Generic Messaging API (Generic MDBs) as it will not be provided in 6.x. An MDB interface offering late binding will not be available in 6.x. v Use the Business Process Choreographer Generic EJB API as opposed to invoking the generated session beans that are specific to a particular version of a process. These session beans will not be generated in 6.x. Chapter 5. Migrating from WebSphere Studio Application Developer Integration Edition 61

66 v If you have a business process with multiple replies for the same operation, ensure that if any of them has client settings that all replies for that operation have the same client settings as in 6.x only one set of client settings is supported per operation reply. v Design BPEL Java snippets according to the following guidelines: Avoid sending WSIFMessage parameters to any custom Java classes. Try not to depend on the WSIFMessage data format where possible. Avoid using the WSIF metadata APIs if possible. v Avoid creating top-down EJB or Java services where possible because the Java/EJB skeleton that gets generated from the WSDL PortTypes/Messages will be dependent on WSIF classes (for example, WSIFFormatPartImpl). Instead, create the Java/EJB interfaces first and generate a service around the Java class/ejb (bottom-up approach). v Avoid creating or using WSDL interfaces that reference the soapenc:array type because this type of interface is not natively supported in the SCA programming model v Avoid creating message types whose high-level element is an array type (maxoccurs attribute is greater than one) because this type of interface is not natively supported in the SCA programming model. v Define your WSDL interfaces precisely and avoid XSD complextypes that have references to the xsd:anytype type where possible. v For any WSDL and XSDs that you generate from an EJB or Java bean, ensure that the target namespace is unique (the Java class name and package name are represented by the target namespace) in order to avoid collisions when migrating to WebSphere Process Server 6.x. In WebSphere Process Server 6.x, two different WSDL/XSD definitions that have the same name and target namespace are not allowed. This situation often occurs when the Web Service wizard or Java2WSDL command is used without specifying the target namespace explicitly (the target namespace will be unique for the package name of the EJB or Java bean, but not for the class itself so problems will occur when a Web service is generated for two or more EJB or Java beans in the same package). The solution is to specify a custom package to namespace mapping in the Web Service wizard or to use the -namespace Java2WSDL command line option to ensure that the namespace of the generated files is unique for the given class. v Use unique namespaces for every WSDL file where possible. There are limitations around importing two different WSDL files with the same namespace according the WSDL 1.1 specification, and in WebSphere Integration Developer 6.x these limitations are strictly enforced. Migrating workspaces using the WebSphere Integration Developer Migration wizard The WebSphere Integration Developer Migration wizard enables the migration of workspaces, including all projects. Specifically for the migration of service projects, the Migration wizard does the following tasks: 1. Creates a new business integration module (the module name is defined by you) 2. Migrates the service project's classpath entries to the new module 3. Copies all WebSphere Business Integration Server Foundation source artifacts from the selected source project to this module 4. Migrates the BPEL extensions in WSDL files 5. Migrates the business processes (.bpel files) from BPEL4WS version 1.1 to the new level supported by WebSphere Process Server, which is built on BPEL4WS version 1.1 with major capabilities of the upcoming WS-BPEL version 2.0 specification 6. Creates an SCA component for each BPEL process 7. Generates a monitoring.mon file for each BPEL process to preserve the default monitoring behavior from WebSphere Studio Application Developer Integration Edition (if necessary) 62 WebSphere Integration Developer: Migration Guide

67 8. Creates imports and exports depending on the deploy options chosen in WebSphere Studio Application Developer Integration Edition 9. Wires the BPEL component to its partner links (imports, exports, and Java components) Note: Use a new WebSphere Integration Developer workspace as the migration target. To migrate workspaces using the WebSphere Integration Developer Migration wizard, follow these steps: 1. Invoke the wizard by selecting File > Import > Business Integration > WebSphere Studio Application Developer Integration Edition Workspace and click Next. 2. The Migration wizard opens. Enter the path for the workspace to migrate or click Browse to find it. Click Next. 3. From the migration options page, you can change the option to preserve the original BPEL Java snippets in the comments. 4. Click Finish to begin the migration process. You will see a migration status bar at the bottom of the Migration wizard's window. 5. Once the process has completed, you will see the following message: Click Next to begin the migration validation process. 6. Select the workspace projects to migrate: Click Next. 7. The project resources which may be impacted by the migration process are listed: Chapter 5. Migrating from WebSphere Studio Application Developer Integration Edition 63

68 Review this list and click Next. 8. Once you are ready, click Finish to begin migrating the projects that you have selected. 9. Once the migration validation process has completed, you should see the following message: 10. After the process has completed, the Migration Results window opens: A log file containing these migration messages will automatically get generated to the 6.x workspace's.metadata folder. The log file will have a.log extension. 64 WebSphere Integration Developer: Migration Guide