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: Collaboration templates

When developing WebSphere InterChange Server or WebSphere Business Integration Server Express collaboration templates, follow these guidelines to ensure the best chance of a smooth migration to IBM BPM.

To ensure that processes are described appropriately with metadata, always use IBM Process Designer 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. 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. Failure to make these corrections before using the migration tool will produce errors and the collaboration template will not be migrated properly. It is highly recommended that you do this before migration unless you want to rewrite the BPEL from scratch.

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 cleanup and implicit transaction bracketing. 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 that, when rendered as a BPEL business process component may be selectively deployed as an interruptible flow. In this case, the process may consist of several separate transactions, with only state and global variable information passed between the activities. The context for any system connection or related transaction that spanned these process transactions would be lost.

Name collaboration template property names in accordance with W3C XML NCName naming conventions. IBM BPM accepts names conforming to those conventions. Any disallowed characters are not valid in the BPEL property names 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 inputBusObj.

Use class-level scoping on variables instead of scenario-scoped variables. Scenario scoping is not carried forward during migration.

Initialize all variables declared in Java snippets with a default value, for example, Object myObject = null;. Be sure 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 or WebSphere Business Integration Server Express, the triggeringBusObj variable is read-only and its values cannot be overwritten, so any incoming business object values will not be saved. If the triggeringBusObj variable is used as the receiving variable for an incoming business object on an inbound service call, the behavior of the inbound service call after migration will be different: within the BPEL process, the incoming value from the inbound service call will overwrite the value stored in the triggeringBusObj variable.

: Premigration considerations