Please help decide if this section still applies to 5.2.
During
this phase, the project team does a complete analysis on the differences between
version 4.3 and version 5.2, especially on the application logic layer. The
project team can base on the documentation of the existing application system
to identify the part that can be migrated automatically and the part that
can not be migrated automatically and prepare what is necessary for the migration.
Do the following:
- Gather all the definition files of the existing application system version
4.3. In the migration tool, it can migration the definition files on the server
side from version 4.3 to version 5.2. The migration tool can process the tags
based on the specification of version 4.3. If there are any special tag definitions,
the migration tool might not be able to migrate it successfully or properly. For this situation, the project team needs to customize the migration
tool to extend the process to contain the special definition for the application
or do it manually later.
- The migration tool cannot migrate the business logic of the application
to version 5.2 directly. The tool just creates a skeleton with the name corresponding
to the server operation or the action in the flow. However, you can make extensions
on the migration tool to move the business logic to the generated code automatically.
The project team must do an investigation to check whether it is worth or
not to extend the migration tool to add more functions.
- For the integrity, do not customize the migration process on the part
of the screen flow generation, the business flow generation and the version
5.2 tooling artifact generation.
- The project team must package the application into a jar file and then
copies the jar file into the plug-in directory of the migration tool and modifies
the plug-in.xml to include the library because the migration tool refers to
the applications when it does the migration.
- Because the migration tool can migrate the non-step server operation to
a Single Action EJB or a Business Process, the project team must separate
the definition files and the application jar into different sets if the application
will be migrated to have both set. The migration tool allows you to create
multiple projects to migrate different sets of applications.
- The supported services in the server side leave JDBC Table Service and
Electronic Journal Service, and the SNA LU0/6.2 communication services are
changed to JCA connectors, the project team must find the substitutive solution
(or implement a new service based on the new service architecture) for these
unsupported services. For example, Lotus Notes® support, LDAP support,
MQ connector, the relevant JCA connector. The migration tool can migrate the
server side service definition by modifying the class information regarding
the services that supported in BTT 5.2. The migration tool also modifies the
DummyDB2Journal.
- The event mechanism is changed to fit version 5.2 framework to be distributable
and span different server. The project team must check and modify the application
accordingly if the event mechanism is adopted in the server side in the current
application system.
- For the client application, there is no change. The project team does
not need to migrate it to version 5.2. The only thing is to verify the migrating
invoker and the related property files to check whether they match the server
operation name or not.
- 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, using WebSphere Integration
Developer and you will have more features supported. The migration tool will
provide fewer features on Rational Application Developer than WebSphere Integration
Developer. The difference is Rational Application Developer will not support
generation of the Business Process. In Rational Application Developer, the
step operations or the flow processor will not be able to migrate. The project
team needs to change it to be non-step operations, or just skip it and create
the Single Action EJB manually. Also, the non-step operation can only be migrated
to a Single Action EJB.