If you are a Host Publisher V4, HATS V5, V6, V7.0, V7.1, V7.5, V8.0, V8.5, or V9.0 user, you can migrate your projects to HATS V9.5.
HATS V4 LE, HATS V5 LE, and HATS V4 projects cannot be migrated directly to HATS V8.0, V8.5, V9.0, or V9.5. To migrate these projects you must first migrate them to an interim release of HATS, for example, V5, V6, V7, V7.1, or V7.5, and then migrate them from the interim release to HATS V8.0, V8.5, V9.0, or V9.5. See the documentation for your previous release of HATS for information about migrating HATS projects.
If you are using a Host Publisher version before V4.0, you must first follow the instructions for migrating your Host Publisher applications to Host Publisher V4.0. Go to http://www.ibm.com/support/entry/portal/overview/software/rational/rational_host_access_transformation_services and enter the search string "How to migrate Host Publisher". For more information, see HATS for Host Publisher users.
Migrating a HATS project from a previous release of HATS is a two step process.
If you have a HATS V5, or later, release of HATS installed, you can export your project to either a zip file or a project interchange file and then import and migrate it to HATS V9.5. See the documentation for your previous release of HATS for information about exporting HATS projects. For more information about importing HATS Web and rich client projects into HATS V9.5, see Exporting and importing HATS Web projects and Exporting and importing HATS rich client projects.
If you have stored your HATS projects in Rational ClearCase, you should create a snapshot view containing these projects and then import them into your HATS V9.5 workspace using File > Import > General > Existing Projects into Workspace. During the import, do not select the Copy projects into workspace option. After the projects are imported into your HATS V9.5 workspace, you have the option to migrate them to HATS V9.5. During migration, files that need updating are automatically checked out of Rational ClearCase.
The Rational SDP Workspace Migration wizard displays when a project is imported into the workspace and needs some level of Rational SDP migration. This wizard performs some basic Rational SDP project migration and if the project targets an unsupported runtime, forces you to choose a supported target runtime. In preparation for running the HATS Migration wizard, you should first run the Rational SDP Workspace Migration wizard.
When you switch to the HATS perspective, if you have a project created from a previous HATS release in your HATS V9.5 workspace, you will get a message stating that the workspace contains a HATS project that needs to be migrated.
You should use the HATS Migration wizard to migrate this project to HATS V9.5 before investigating any errors shown in the Problems view because migration may eliminate some or all of these errors.
To use the HATS Migration wizard follow these steps:
When you migrate HATS projects from a previous release of HATS to HATS V9.5, transformations in the projects are migrated as well. Changes made to the transformations depend on the release of HATS you are migrating from. All transformations are saved in the MigrationBackup folder before being migrated.
If in previous versions of HATS you enabled the auto advance function by adding the line turnAutoTabOn(); to the lxgwfunctions.js file, you must now use the Enable automatic field advance setting in the Client Settings section of the Other tab in the Project Settings editor. For more information, see Client settings.
HATS migration creates a backup folder in the project directory called MigrationBackup. This folder contains copies of the files from the old project before they were overwritten by the migration process. These files are saved allowing you to compare and merge them with your new HATS V9.5 files. Do not worry if problems occur; these files are no longer used by the application. When you are satisfied that all the saved files have been compared and merged, you can delete the MigrationBackup folder.
If you migrate a project created prior to HATS V7.0.0.2, and you choose to implement the Enable foreground colors option, if you use a template that uses the blacktheme.css style sheet, you must manually update the blacktheme.css style sheet in one of the following ways:
color: lime;.HBLUE {
color: #3c9dff;
}
input.HBLUE {
white-space: normal;
letter-spacing: normal;
}.HBLUE, input.HBLUE {
color: #3c9dff;
white-space: normal;
letter-spacing: normal;
}An alternative to manually editing the blacktheme.css style sheet is to create a new dummy project and copy the theme CSS files from this project into your project. Be aware that any changes you have made to your CSS files are overwritten.
If you have existing HATS V5 projects that have EJB Access Beans, you may have compile or runtime errors that begin with "HPubReqCompleteEvent cannot be resolved." To correct this, regenerate the EJB Access Beans.
If you want to use the Render using monospace font setting for the Field widget, and your project was originally created in a release earlier than HATS V7.0, you must update your CSS files as follows:
.HF {
font-family: courier new, monospace;
}A new setting, enforceImmediacy, is added to any global rule imported into HATS V9.5 from HATS V5. When this setting is true, the global rule behaves as it did in HATS V5 when Nearest input field only is selected for the Transform option of the Find input fields by surrounding text pattern. When this setting is false, the default, the global rule behaves as it does in HATS V9.5.
To make newly defined global rules behave as the HATS V5 global rules did, you must add and set the enforceImmediacy setting to true. To do this, on the Source tab of the Project Settings editor, add the following setting to the globalRules componentSettings tag:
<setting name="enforceImmediacy" value="true"/>Before HATS V7, the value of a global variable, entered into a prompt inserted onto a transformation using the Prompt for global variable with input box option, might have been truncated because some characters were not escaped properly.
In this HATS version, global variable values prompted for by a transformation are properly escaped to prevent truncation. Global variables inserted onto a transformation using the Display global variable value as static text option are not affected by this change. Global variable prompts inserted onto a transformation in a version of HATS before HATS V7 are not automatically updated during migration, so they are not affected by this change.
If you want to use HATS support for HTTP compression in projects migrated from HATS V5.0.x, V6.0, and V6.0.1, you must manually add the compression filter to the Web Deployment Descriptor file (web.xml). To add the compression filter to the web.xml file:
<filter>
<description>Provides compression for output from HATS entry
servlet</description>
<display-name>CompressionFilter</display-name>
<filter-name>CompressionFilter</filter-name>
<filter-class>com.ibm.hats.runtime.filters.CompressionFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>CompressionFilter</filter-name>
<servlet-name>EntryServlet</servlet-name>
<dispatcher>ERROR</dispatcher>
<dispatcher>FORWARD</dispatcher>
<dispatcher>INCLUDE</dispatcher>
<dispatcher>REQUEST</dispatcher>
</filter-mapping>
<filter-mapping>
<filter-name>CompressionFilter</filter-name>
<url-pattern>/</url-pattern>
</filter-mapping>
<filter-mapping>
<filter-name>CompressionFilter</filter-name>
<url-pattern>/index.jsp</url-pattern>
</filter-mapping>
HATS, WebFacing, and HATS/WebFacing linked applications that are migrated to HATS V9.5 must be redeployed to the production environment to pick up support for the new HATS V9.5 signature file by the IBM license management tools, for example, IBM License Metric Tool and IBM Tivoli® Asset Discovery for Distributed.
IBM license management tools detect Web applications deployed as Enterprise Archives (EARs) to supported WebSphere Application Servers. Since WebFacing Web projects are created independently of associated EARs, the HATS V9.5 signature file must be included manually. Follow the steps below to enable the proper detection of WebFacing Web applications.
<shared_install_directory>\plugins\com.ibm.hats_nnn\If you enabled detection for an old WebFacing project and migrate that project to V9.5, you must remove the existing signature file (for example, WDHT0700.sys2 if the old WebFacing project is from V7.0) from the project's associated EAR and add the V9.5 signature file (Host_Access_Transformation_Services-9.0.0.swidtag) before redeployment.
During migration to HATS V9.5, the WebSphere Application Server Java™ 2 security was.policy file is overwritten. If you have customized the was.policy file in a pre-HATS V9.5 project, then you must re-customize the file after migration.
In earlier versions of the HATS host terminal, the Pause key was mapped to the host's [clear] action. In HATS V7, and later, host terminal, the Esc key is mapped to the host's [clear] action.
In versions of HATS earlier than HATS V6, Ctrl+R was used in bidirectional sessions to reverse the screen. In HATS V6 and later, Ctrl+R is mapped to a host RESET for both bidirectional and non-bidirectional sessions, and Alt+Enter is mapped to reverse for bidirectional sessions.
If you migrate to HATS V9.5 a pre-HATS V7.5.1 rich client project that is targeted for Lotus® Expeditor, the keyboard mappings for Lotus Notes® are added to the project.
After migrating a rich client project, if you are unable to launch it in the test environment, create a new launch configuration to use in the test environment. To do this, in the HATS Projects view, right-click the project and select either Run or Debug. The Run (or Debug) Configurations window is displayed. If the project is targeted for Eclipse RCP, right-click on Eclipse Application and select New. If the project is targeted for Lotus Notes or Lotus Expeditor , right-click on Client Services and select New. Modify the launch configuration name and location if desired. You can delete old launch configurations from this window as well. Click Run (or Debug) to launch the project in the test environment.
HATS V7.0 rich client applications that use the Classic terminal emulator theme will have the Arrow key navigation setting enabled after migration.
Non-US English strings included in templates and transformations of a HATS rich client project built with HATS V7.0 or V7.0.0.1 are not compiled correctly when the project is exported as a feature. To work around this problem, after migrating the project to HATS V9.5, edit the build.properties file located in the root folder of the project. Add the following line at the bottom of the build.properties file:
javacCustomEncodings.library.jar = src/rcpproject/templates/[UTF-8],
src/rcpproject/transformations/[UTF-8]Where rcpproject is the name of the rich client project.
To fully enable the HATS V9.5 runtime for production, you must specify your license settings using the License Settings wizard. You must do this even for projects whose runtimes were fully enabled in previous versions of HATS. For information about specifying license settings, see Enabling HATS runtime and license settings in HATS Getting Started
During migration, HATS V9.5 converts SSL certificate class files, CustomizedCAs.class files, to PKCS12 keystore files with the names appname-CustomizedCAs.p12 and passwords of hats, where appname is the project name. After migration, you should use the Certificate Management tool (also known as IBM Key Management or iKeyMan) to change the passwords for the new keystore files and verify them using the connection editor. For more information, see Security.
Starting with HATS V7, the Run on Server (for Web projects) and Run (for rich client projects) testing modes can be used to modify and test the runtime settings that are deployed to the production environment. Be aware that any changes made to the runtime settings while testing in this mode are retained and become effective when you deploy the HATS application to a production environment.
The Debug on Server (for Web projects) and Debug (for rich client projects) testing modes can be used to modify and test the runtime settings without modifying the settings that are deployed to the production environment.
For more information about changing runtime settings for Web projects, see Starting the administrative console while in HATS Toolkit. For more information about changing runtime settings for rich client projects, see Administering HATS rich client applications.
Before HATS V7, the URL host component searched within both input and protected fields. Starting with HATS V7, the URL host component searches only within protected, non-hidden fields.
When a HATS Web project is migrated to HATS V9.5 with no associated EAR, Web Express Logon (WEL) does not function properly. The WEL configuration information for a Web project is kept in its associated EAR project. If the associated EAR project is not imported and migrated then this information is lost.
If you import the Web and EAR projects as archive files into the workspace and migrate the Web project, the associated EAR project is also migrated and the WEL configuration information is not lost.
Starting with HATS V7, Java Secure Socket Extension (JSSE) is used by both the HATS DCAS/RACF/JDBC and certificate-based DCAS/RACF credential mapper plug-ins for secure connections to the DCAS server. As a result, consider the following changes to the plug-in initialization parameters.
This parameter specifies a keyring database. A keyring must be specified to provide access to the DCAS client certificate as well as the DCAS server's certificate. The certificates establish a client authenticated secure connection with the DCAS server. This parameter is a file reference to the keyring to be used. The DCAS plug-in is the DCAS client. The keyring file must be stored in the .ear file.
This parameter specifies the password for the keyring database.
If you are an experienced user of IBM WebSphere Host Publisher, you will need to adjust your approach in order to develop projects with HATS. Here are some key differences between the HATS and Host Publisher approaches to developing projects:
If you are importing a Host Publisher V4.0 application (versus a Host Publisher V4.0.1 application):
If you are currently a Host Publisher V4 user, you can migrate whole projects or just the Integration Objects from your existing projects. When you import Host Publisher .ear files, the Integration Objects remain packaged in the .jar file.
If the Integration Object was in a Web Module, the .jar file is in the WEB-INF/LIB directory. If the Integration Object is in an EJB module, the .jar file is in the imported_classes\IntegrationObject directory. The EJB Access Beans also remain packaged in the .jar file in the WEB-INF/LIB directory of the Web Module.
If you import an .ear and modify the macro for which an Integration Object has been created, you will have the original Integration Object .jar that was imported, as well as the Java source. After you have regenerated the Integration Object for HATS, you can delete the imported .jar file.
Below is a list of considerations when migrating from Host Publisher V4:
You can import Host Publisher V4 projects into HATS as new HATS projects, or as part of an existing HATS project.
You can also import individual Host Publisher Integration Objects into an existing HATS project.
If you want to migrate the level of J2EE support in your HATS projects, perform the following steps: