In this phase, you need to analyze the differences between BTT
version 5.2 and BTT version 6.1.2, especially the application logic layer.
Based on the documentation of the existing application system, you
can identify the parts that can be migrated automatically and the parts that
cannot be migrated automatically, and then make necessary preparation for
the migration. To get well prepared for the migration, you need to do the
following work:
- Gather all the definition files of the existing application system version
5.2. The migration tool can migrate the definition files on the server side
from version 5.2 to version 6.1.2. The migration tool can process the definition
contents based on the given rules. BTT version 6.1.2 provides default migration
rules, but if there are any special tag definitions that are not included
in the default rules, the migration tool might not be able to migrate them
successfully or properly. In this case, you need to customize the migration
tool rules to extend the process to cover those special tag definitions for
the application or migrate them manually later.
- The migration tool can migrate the business logic Java™ code
of the application to BTT version 6.1.2 directly. BTT version 6.1.2 uses the
processor, operation, and operation step on the server side of BTT. There
is much enhancement and refinement in the architecture of BTT version 6.1.2,
so it has different package names, class names, and changes of APIs. The migration
tool can migrate BTT version 5.2 classes and APIs to the corresponding BTT
version 6.1.2 classes and APIs.
- Migrate the BTT version 5.2 invoker. BTT version 5.2 leverages the invoker
framework to invoke the business logic. BTT version 5.2 leverages EJB as the
business logic implementation. The invoker of BTT version 5.2 is mainly used
for EJB calling from the BTT runtime server. In BTT version 6.1.2, the architecture
is improved. The request from the channel side will directly call the BTT
processor or operation in the BTT runtime container, where you can handle
some channel aware logic or business logic. If you want to call EJB, JMS,
and BPEL, BTT provides you an invoker to invoke them. BTT version 5.2 invoker
framework is not used in BTT version 6.1.2, because a more powerful and ease-of-use
invoker framework is implemented in BTT version 6.1.2. You should migrate
your applications to adopt the new BTT version 6.1.2 invoker.
- BTT version 6.1.2 provides more powerful Context and Formatter,
and the API usage is different with that in BTT version 5.2. The migration
tool of BTT version 6.1.2 can help you migrate the Context, Formatter, and
APIs or provide recommendations for the migration.
- Migrate BTT version 5.2 services. The supported services of BTT version
6.1.2 on the server side support all of the BTT version 5.2 services. The
migration tool helps to migrate the package names, class names, APIs, and
so on. If you have some customized services, you can customize the migration
rule to meet your migration requirements.
- The event mechanism is changed to fit version 6.1.2 framework so
that it can be distributable and spans different servers. You must do some
manual migration to run the BTT version 5.2 event in BTT version 6.1.2.
- There are two kinds of client applications in BTT version 5.2. There is
no change to the Swing based Java client, so you do not need to migrate
it to BTT version 6.1.2. For JSP/HTML based client, the migration tool does
not support its migration, so manual migration is needed.
- Migrate the BTT trace. BTT version 6.1.2 enhances the trace features
to support more powerful functions and comprehensive APIs. BTT version 6.1.2
trace is completely compatible with BTT version 5.2 trace. If you do not want
to use the new trace framework, the old trace can still work in BTT version
6.1.2 runtime container. If you want to use the new trace, use the migration
tool to achieve the trace by defining specific migration rules.
- If the future application only runs on WebSphere® Application Server, use Rational® Application
Developer to migrate the application. If the future application runs on WebSphere Process
Server, use WebSphere Integration
Developer to migrate the application.