The following are the components that need to be migrated:
- Input and Output: The input of the migration tool includes BTT 4.3.x definition
files from a specific URL or an EAR file, and the source code of the server
operations or the validation classes based on BTT 4.3.x framework. The output
of the migration tool is the migrated artifacts, such as the related definition
files of BTT 5.2, the source code of SAEs, Activities of B.P and the validation
classes. The output also includes the tooling artifact for BTT 5.2.
- Definition Transformation: This feature transforms the definition from
BTT 4.3 to BTT 5.2. All definition files are converted or migrated to the
corresponding BTT 5.2 definition files. For example, screen flow process definition
is migrated to Struts base definition, and the business process definition
is migrated to BPEL base definition.
- Code Generation: Since many components in BTT 5.2 are different from those
in BTT 4.3, the migration tool provides a function to make the prior code
migration from the existing BTT 4.3.x program to the BTT 5.2 base program
to reduce the workload in the application program migration.
- Tooling Artifact Generation: The migration tool of BTT 5.2 provides a
number of development tools to help the developer for the application construction.
All the tools have managed artifact which is responsible for the environment
or the component extension. So the migration tool can generate the corresponding
artifact for each tool. The tooling artifact of BTT 5.2 is based on Rational® Application
Developer or WebSphere® Integration
Developer. The migration tool not only includes RAD/WID compatibility, but
also the functions. For example, the wsifAction defined in BTT 5.1 tooling
artifact is removed when migrated.
- UI Features: The migration provides a simple non-fashion UI to trigger
the underlying migration modules to carry out the migration work. It focuses
on the management of the user interface and the interaction with the user.
- Customer Extension Support: This is a key feature in the migration tool.
It provides the flexibility for you to plug in your own extension. It spans
the coverage of the extended functions in the existing BTT application system.
You can make the customization to fit the extension and plug it into the migration
tool. Then, the tool carries out the customer extension right after the base
migration process, or it may totally replace the default process of the migration
tool. The extension point is implemented using external definition files and
eclipse plugin extension point.
- Modular Base: The migration tool is organized by extension point and external
definition file. You can organize the process scenario without worrying about
the content processing for the migration.
- Exclusions: The definition file of the communication service and pool
services are not covered in the migration tool. You need to migrate them manually
- Constraints: To reduce the complexity, the migration tool limits the availability.
You cannot change the migration information, for example, if you change the
context name, then the application will not be able to recognize it.