In the latest release of the WebSphere Migration Toolkit for Application Binaries version 19.0.0.5 (http://ibm.biz/WAMT4AppBinaries), released December 6, 2019, the tool now also scans the configuration for applications running in traditional WebSphere Application Server (tWAS) and converts it to either a Liberty server.xml configuration file or wsadmin scripts for configuring the app in a newer version of tWAS that is specific to each application scanned.
If you are not familiar with the WebSphere Migration Toolkit for Application Binaries already, let me provide a little background before diving into the new functionality. This small but powerful command line tool scans your binary applications and produces reports for migrating them to a Liberty application server or to more recent versions of tWAS. From a command line prompt, you tell the tool where your application binaries (i.e., *.EAR and *.WAR files) are located, from which runtime environment they are currently running, the version of Java SE, and the target environment to which you want to migrate and it generates a set of migration reports.
The Application Technology Evaluation Report indicates which Java EE technologies were detected and on which IBM platforms they are supported. The Detailed Migration Analysis Report contains a list of all the rules that were flagged and rule specific help for resolving the issues, as well as the file names and line numbers where the issues were detected. The Application Inventory Report shows a high-level view of the content and structure of the application, classifying the detected components and highlighting duplicates, unused components and missing dependencies. And finally, a Liberty Feature List containing the required features to include in a Liberty server.xml configuration file.
Until this release, the tool scanned only the binary application, and therefore only produced a list of features the application needs to run in Liberty. With the update in version 19.0.0.5, the tool now scans the configuration of tWAS applications and migrates it as well. The new functionality still generates the same feature list as before, and also analyzes application specific configuration settings (e.g., JBDC and JMS configuration) and migrates them for the targeted runtime environment. If the target environment is Liberty, then a Liberty server.xml file is generated that contains both a feature list and the application specific configuration for running the app in Liberty. If the target environment is a more recent release of tWAS (i.e., version 8.5.x or 9.0.x) then the binary scanner outputs wsadmin configuration scripts.
The easiest way to run the scanner is to point it to a directory of binary applications deployed in an existing tWAS environment and generate all reports and migrated configuration files for each application. By default, the scanner assumes the source application server to be WebSphere Application Server version 8.5.5 with Java SE 6 and a Java EE 6 application and the target application server to be Liberty with Java SE 8. Therefore, running the following command …
> java -jar binaryAppScanner.jar C:\WebSphere\profiles\AppSrv01\config\cells\Node01Cell\applications\
… generates the same output as explicitly using each of the respective options in the following command:
> java -jar binaryAppScanner.jar C:\WebSphere\profiles\AppSrv01\config\cells\Node01Cell\applications\ --all --sourceAppServer=was855 --sourceJava=ibm6 –sourceJavaEE=ee6 --targetAppServer=liberty --targetJava=ibm8
Alternatively, if you only want to analyze a specific application or set of applications, provide the directory path to one or more applications. For example, to analyze one specific application, you could use:
> java -jar binaryAppScanner.jar /path/myApp.ear --all
Or, use the following command to analyze three applications:
> java -jar binaryAppScanner.jar /path1/myApp1.ear /path2/myApp2.ear /path3/myApp3.ear --all
Now that you know the fundamentals for using the binary application scanner, let’s take a closer look at the new functionality that migrates the configuration for tWAS applications. To better reflect the functionality provided, the --featureList option was replaced with --generateConfig. Use this option if you want the binary scanner to output just the migrated configuration without the other reports. For example, use of the following commands to scan directory of deployed apps and output migrated server.xml Liberty configuration files for each application in the directory:
> java -jar binaryAppScanner.jar C:\WebSphere\profiles\AppSrv01\config\cells\Node01Cell\applications\ --generateConfig
Remember that Liberty is the default setting for the target server environment. If you want wsadmin configuration scripts for migrating to traditional WebSphere Application Server, also be sure to specify a version of tWAS as the target, such as: --targetAppServer=was855 or --targetAppServer=was90
The scanner will attempt to discover the configuration from a deployed application and then migrate it for you. If the configuration is not discovered, then you should use the --configLocation option to specify where the configuration is located, such as the path to a tWAS profile where the app is deployed or a backup of the configuration.
If the scanner encounters any sensitive information in the configuration, such as passwords, that sensitive information gets replaced with variables in the generated configuration. When migrating the app to tWAS, the variables are defined at the top of the wsadmin script. When migrating to Liberty, a separate file, myApp_server_sensitiveData.xml, is produced that contains a list of the variables. The variable values are left blank by default. Otherwise, use the --includeSensitiveData option to migrate the passwords.
In addition to the new configuration migration feature, the WebSphere Migration Toolkit for Application Binaries also extended its support for analyzing the impacts of upgrading the Java runtime that are detailed in the Migration Analysis Report. Matching the Java support provided by Liberty, the binary scanner includes migration rules for both the long-term support (LTS) releases (i.e., Java 8 and 11) and non-LTS releases of Java. In version 19.0.0.5, new migration rules were added to scan for issues when upgrading to Java 13, the latest non-LTS Java release. Depending on the Java runtime you choose to use with Liberty, consider using --targetJava=java11 when upgrading to the latest LTS release or use --targetJava=java13 when upgrading to the latest non-LTS release.
Likewise, you might also consider using the --targetJavaEE option to affect the version of the Liberty features that get included in the feature list of the server.xml file. For instance, use --targetJavaEE=ee8 to use the Java EE 8 version of the Liberty features which are detected in your applications. Otherwise, if a target Java EE is not specified, the scanner defaults to the latest available feature versions that support each of the scanned applications.