IBM BPM, V8.0.1, All platforms > Migrating and upgrading your IBM BPM environment > Migrating from other products > Migrating from WebSphere InterChange Server or WebSphere Business Integration Server Express > Premigration considerations

Premigration considerations: General development

Follow these recommended practices when developing WebSphere InterChange Server or WebSphere Business Integration Server Express modules to ease future migration to IBM BPM.

Several considerations apply broadly to developing most of the integration artifacts. In general, artifacts that use the facilities provided by WebSphere InterChange Server or WebSphere Business Integration Server Express 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.

In general, IBM recommends that you do the following:

It is important for integration solutions to adhere to the programming model and architecture provided by WebSphere InterChange Server or WebSphere Business Integration Server Express. Each of the integration components within WebSphere InterChange Server or WebSphere Business Integration Server Express 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 IBM BPM.

Another general practice that 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 corrupt the artifact for migration.

IBM suggests the following when you are developing Java code within collaboration templates, maps, common code utilities, and other components:

Use only the APIs published in the WebSphere InterChange Server or WebSphere Business Integration Server Express product documentation for the artifacts. These are outlined in detail in the WebSphere InterChange Server or WebSphere Business Integration Server Express development guides. Compatibility APIs will be provided in IBM BPM for published WebSphere InterChange Server or WebSphere Business Integration Server Express APIs. Although WebSphere InterChange Server and WebSphere Business Integration Server Express have many internal interfaces which you might want to use, IBM discourages this practice 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 class path of WebSphere InterChange Server or WebSphere Business Integration Server Express, 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, IBM recommends that 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 or WebSphere Business Integration Server Express. 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 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 Java EE application server environment, even though it is currently running within a Java SE environment. Adhere to Java EE development practices, such as avoiding static variables, creating threads, and disk I/O. While these are generally good practices to adhere to, they can improve portability.

: Premigration considerations