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

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:

• For WebSphere Integration Developer V7.0.0.1 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. If that this restriction does not apply for WebSphere Integration Developer 7.0.0.2 or later or for IBM Integration Designer.

• 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.
• 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 an SCA module to invoke a transformer service. Additionally, there is no special tools support in IBM Integration Designer 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.

• Specify one part per WSDL message if the WSDL is a document style according to the web Services Interoperability (WS-I) specification and the preferred style in 6.x and later releases. This does not apply to RPC style WSDLs.

• Use the WSDL wrapped doc-literal style; this is the preferred style in 6.x and later releases.
• 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="http://util.claimshandling.bpe.samples.websphere.ibm.com" 
      xmlns="http://www.w3.org/2001/XMLSchema"
      xmlns:tns="http://util.claimshandling.bpe.samples.websphere.ibm.com">
  
  <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 because it can cause problems when an SDO is serialized to XML (element containing an anonymous complex type definition):

   <schema attributeFormDefault="qualified"
      elementFormDefault="unqualified"
      targetNamespace="http://util.claimshandling.bpe.samples.websphere.ibm.com" 
      xmlns="http://www.w3.org/2001/XMLSchema"
      xmlns:tns="http://util.claimshandling.bpe.samples.websphere.ibm.com">
  <element name="DurationElement">
   <complexType>
  	  <all>
  	       <element name="hours" type="int"/>
  		     <element name="minutes" type="int"/>
  	       <element name="days" type="int"/>
  
     </all>
    </complexType>
   </element>
  </schema>

• 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 later releases and Apache web services are not.

• 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 and later releases, 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 IBM Integration Designer 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.

• Avoid using the Business Process Choreographer Generic Messaging API (Generic MDBs) because it will not be provided in 6.x and later releases. An MDB interface offering late binding will not be available in 6.x and later releases.

• 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 and later releases.

• 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 only one set of client settings is supported per operation reply.

• 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.

• 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).

• 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

• 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.
• Define your WSDL interfaces precisely and avoid XSD complexTypes that have references to the xsd:anyType type where possible.

• For any WSDL and XSDs that you generate from an EJB or JavaBeans, 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 IBM BPM. In IBM BPM 6.x and later releases, 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 JavaBeans, but not for the class itself, so problems will occur when a web service is generated for two or more EJB or JavaBeans in the same package). The solution is to specify a custom package to namespace mapping in the web service wizard or use the -namespace Java2WSDL command line option to ensure that the namespace of the generated files is unique for the given class.
• Where possible, use unique namespaces for each WSDL file. There are limitations around importing two different WSDL files with the same namespace according the WSDL 1.1 specification, and in IBM Integration Designer these limitations are strictly enforced.

: Migrating your workspace