Migration tool architecture

The figure below shows the architecture view of the migration tool.

Architecture view of the migration tool.

As shown in the figure above, the migration tool consists of the migration API modules and the UI features plus the custom batch migration application:

Import definition file from EAR

There are two ways to input the definition files from an EAR file:
  • Flatten the EAR file: This scenario first imports the EAR into RAD, and then all the input files inside the web application WAR file, including definition files and the source code of the application, are extracted and placed in a web application project. Then, the migration tool gets the related files from the specific URL.
    Note: This approach will not work if the target files are inside the reference jar files of the web application project. You have to flatten the jar file too in order to get the target files by importing them into the migration tool project or another project, for example, a Java™ application project. Besides, this approach only works on RAD.
  • Extract the files from the EAR directly: This scenario extracts the specific files from the EAR file into the related project of the migration directly. In this case, you need to know which package is the target staff from and you need to indicate it for the migration tool. The advantage is that this approach does not have the limitations of the previous one.

To reduce the operation complexity, the second approach is better if the migration tool provides the location list of dse.ini for you to pick up.

Batch migration mode definition file import

To perform the batch migration, the EAR or the dse.ini path needs to be defined in an external file. The migration file can use it as input to get the list.

Handle BTT definition files by BTT Externalizer

To avoid the improper handling of BTT definition, it is better that you use BTT Externalizer to carry out the definition handling and parsing