IBM BPM, V8.0.1, All platforms > Migrating and upgrading your IBM BPM environment > Migrating from other products > Migrating from WebSphere Studio Application Developer Integration Edition > Migrating your workspace
Limitations of source artifact migration
There are limitations involved with the WebSphere Studio Application Developer Integration Edition source artifact migration process.
The following lists detail some of the limitations of the migration process for source artifact migration.
General limitations
- 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 IBM Integration Designer workspace, but will not have any processing for migration.
- Studio Application Developer Integration Edition did not strictly enforce consistency between the WSDLs and other artifacts in projects. IBM Integration Designer is much stricter and will report inconsistencies that WebSphere Studio Application Developer Integration Edition did not (and also which ran on the WebSphere Business Integration Server Foundation runtime without any issue).
- Although Studio Application Developer Integration Edition allowed multiple identical web service binding and service definitions (name and namespace), IBM Integration Designer does not. You must resolve these duplicates manually before migration (in Studio Application Developer Integration Edition) or after migration (in IBM Integration Designer). An example is that in WebSphere Studio Application Developer Integration Edition, all of the generated service definitions in the WSDL files with different names (ending in _EJB, _JMS, and so on) looked like:
<service name="OrderProcessIntfcService">To fix the duplicate, simply append the binding type to the name attribute. For the *_EJB.wsdl file, it would be changed to<service name="OrderProcessIntfcServiceEJB">For the *_JMS.wsdl file, it would be changed to<service name="OrderProcessIntfcServiceJMS">However, once this name is changed, the Export generated in IBM Integration Designer to use this service will also need to be changed to use the right name.- The Migration wizard does not migrate application binary files; it only migrates source artifacts found in a WebSphere Studio Application Developer Integration Edition service project.
- The standard provided JMS data binding does not provide access to custom JMS header properties. A custom data binding must be written for the SCA services to get access to any custom JMS header properties.
- IBM Integration Designer does not support XML-SOAP types as defined in the http://xml.apache.org/xml-soap namespace.
You should remove references to these types in WebSphere Studio Application Developer Integration Edition before migrating to avoid a migration process failure.
- When a workspace is migrated, some modules may have dependencies on other modules. This is not checked by IBM Integration Designer, however; there will be errors similar to the following after application deployment:
======== TravelOperationsApp ======== The application cannot start: TravelOperationsApp com.ibm.ws.exception.RuntimeWarning: javax.resource.ResourceException: Failed to lookup ActivationSpec.sca/TravelOperations/ActivationSpecAfter migration, you should review the modules and manually remove project and build path dependencies between modules. This might require moving some WSDL and Java files into a common library project.- Java EE type projects are not migrated to the most current Java EE level.
For example, if projects in the WebSphere Studio Application Developer Integration Edition workspace are at the 1.3 level and when migrated are kept at the 1.3 level and not 1.4 (the most current in V6.2), this does not cause any problems. If you want to upgrade to the most current level, use the Java EE tools menu by right-clicking any Java EE type project (Web, EJB, EAR, Application Client) and selecting Java EE Tools > Specifications Upgrade Wizard.
EJB project migration limitations
You might encounter a migration problem if the source WebSphere Studio Application Developer Integration Edition workspace has an EJB project without an EJB client project. If the EJB project is a dependency of one or more service projects, the migrated workspace will build correctly but will not deploy correctly. This happens because IBM Integration Designer tries to deploy the EJB project as a Java EE module and not a utility jar. To solve this problem, follow these steps:
- Migrate the workspace.
- In IBM Integration Designer, right-click EJB Project > Java EE > Create EJB Client Jar. An EJB client project is created.
- Replace all references to the EJB project in Modules with the EJB client.
SCA Programming Model limitations
- The SDO version 1 specification does not provide access to the COBOL or C byte array. This will impact those working with IMS multi-segments.
- The SDO version 1 specification for serialization does not support COBOL redefines or C unions.
- When redesigning your source artifacts according to the SCA programming model, note that the document/literal wrapped WSDL style (which is the default style for new artifacts created using the IBM Integration Designer tools) does not support method overloading. The other WSDL styles are still supported, so it is recommended that another WSDL style/encoding other than document/literal wrapped be used for these cases.
- Native support for arrays is limited. In order to invoke an external service that exposes a WSDL interface with soapenc:Array types, you will need to create a WSDL interface that defines an element whose "maxOccurs" attribute is greater than one (this is the recommended approach for designing an array type).
BPEL migration process technical limitations
- Multiple replies per BPEL operation - In WebSphere Business Integration Server Foundation, a business process could have one receive activity and multiple reply activities for the same operation. If you have a business process with multiple replies for the same operation, ensure that if any of them has client settings, all replies for that operation have the same client settings. In 6.x and later releases only one set of client settings is supported per operation reply.
- Limitations of BPEL Java snippet migration - The programming model has changed significantly from WebSphere Studio Application Developer Integration Edition to IBM Integration Designer, and not all supported WebSphere Studio Application Developer Integration Edition APIs can be directly migrated to corresponding IBM Integration Designer APIs. Any Java™ logic can be found in the BPEL Java snippets, so that the automatic migration tool may not be able to convert every Java snippet to the new programming model. Most of the standard snippet API calls will be automatically migrated from the 5.1 Java snippet programming model to the 6.x or later Java snippet programming model. WSIF API calls are migrated to DataObject API calls where possible. Any custom Java classes that accept WSIFMessage objects will need manual migration so that they accept and return commonj.sdo.DataObject objects instead:
- WSIFMessage metadata APIs - Manual migration may be needed for some WSIFMessage metadata and other WSIF APIs.
- EndpointReference/EndpointReferenceType APIs - These classes are not automatically migrated. Manual migration is needed because the partner link getter/setter methods deal with commonj.sdo.DataObject objects instead of the com.ibm.websphere.srm.bpel.wsaddressing.EndpointReferenceType objects from 5.1.
- Complex types with duplicate names - If an application declares complex types (in WSDLs or XSDs) with identical namespaces and local names, or different namespaces but identical local names, Java snippets that use these types might not be migrated correctly. Verify the snippets for correctness after the migration wizard has completed.
- Complex types with local names identical to Java classes in the java.lang package - If an application declares complex types (in WSDLs or XSDs) with local names that are identical to classes in the java.lang package of J2SE 1.4.2, Java snippets that use the corresponding java.lang class might not be migrated correctly. Verify the snippets for correctness after the migration wizard has completed.
- Read-only and read-write BPEL variables - In any 5.1 Java snippet code, it was possible to set a BPEL variable to "read-only", meaning that any changes made to this object will not affect the BPEL variable's value. It was also possible to set a BPEL variable to "read-write", meaning that any changes made to the object would be reflected for the BPEL variable itself. The following example shows four ways that a Java snippet could be accessed as "read-only" in any 5.1 BPEL Java snippet:
getMyInputVariable() getMyInputVariable(false) getVariableAsWSIFMessage(“MyInputVariable”) getVariableAsWSIFMessage(“MyInputVariable”, false)Here are the two ways that a BPEL variable could be accessed as "read-write" in any 5.1 BPEL Java snippet:getMyInputVariable(true) getVariableAsWSIFMessage(“MyInputVariable”, true)In 6.x or later releases, read-only and read-write access to BPEL variables is handled on a "per-snippet basis," meaning that you can add a special comment to the BPEL Java snippet to specify whether updates to the BPEL variable should be discarded or maintained after the snippet has finished executing. Here are the default access settings for the 6.x or later BPEL Java snippet types:BPEL Java Snippet Activity Default Access: read-write Override Default Access with comment containing: @bpe.readOnlyVariables names="variableA,variableB" BPEL Java Snippet Expression (Used in a Timeout, Condition, etc) Default Access: read-only Override Default Access with comment containing: @bpe.readWriteVariables names="variableA,variableB"During migration, these comments will automatically be created when a variable was accessed in a way that is not the default in 6.x or later releases. In cases in which there is a conflict (meaning that the BPEL variable was accessed as "read-only" and as "read-write" in the same snippet), a warning is issued and the access is set to "read-write". If you receive any such warnings, ensure that setting the BPEL variable access to "read-write" is correct for your situation. If this is not correct, correct it manually using the IBM Integration Designer BPEL editor.- Many-valued primitive properties in complex types - In 5.1, multi-valued properties are represented by arrays of the property type. As such, calls to get and set the property use arrays. In 6.x or later releases, java.util.List is used for this representation. Automatic migration will handle all cases where the many-valued property is some type of Java object, but in cases in which the property type is a Java primitive (int, long, short, byte, char, float, double, and boolean), calls to get and set the entire array are not converted. Manual migration in such cases might require adding a loop to wrap/unwrap the primitives in/from their corresponding Java wrapper class (Integer, Long, Short, Byte, Character, Float, Double, and Boolean) for use in the rest of the snippet.
- Instantiation of generated classes representing complex types - In 5.1, generated classes of complex types defined in an application could be easily instantiated in a Java snippet using the default no-argument constructor. An example of this is:
MyProperty myProp = new MyProperty(); InputMessageMessage myMsg = new InputMessageMessage(); myMsg.setMyProperty(myProp);In 6.x or later releases, a special factory class must be used to instantiate these types, or an instance of the containing type may be used to create the sub-type. If a BPEL process variable InputVariable was defined as having type InputMessage, the 6.x or later version of the preceding snippet would be:com.ibm.websphere.bo.BOFactory boFactory= (com.ibm.websphere.bo.BOFactory) com.ibm.websphere.sca.ServiceManager.INSTANCE.locateService( “com/ibm/websphere/bo/BOFactory”); commonj.sdo.DataObject myMsg = boFactory.createByType(getVariableType(“InputVariable”)); commonj.sdo.DataObject myProp = myMsg.createDataObject(“MyProperty”);The snippet converter attempts to make this change, but if the order in which the original instantiations occur does not follow the parent-then-child pattern, manual migration will be needed. The converter does not attempt to intelligently reorder the instantiation statements in the snippet.
- In WebSphere Business Integration Server Foundation 5.1, dynamic references were represented as WSDL message parts of type EndpointReferenceType or element EndpointReference from the namespace:
http://wsaddressing.bpel.srm.websphere.ibm.comSuch references will be migrated to the standard service-ref element type from the standard business process namespace:http://schemas.xmlsoap.org/ws/2004/03/business-process/http://schemas.xmlsoap.org/ws/2004/08/addressingSee the BPEL Editor documentation for instructions on manually importing these schema definitions into your project so that all references resolve properly.- BPEL variable message type - A WSDL message type must be specified for all BPEL variables used in Java snippets. Java snippets that access BPEL variables without the "messageType" attribute specified cannot be migrated.