Considerations for linked HATS/WebFacing applications

Technical considerations

• Some changes made to the individual HATS and WebFacing applications will not affect the linked HATS/WebFacing project. Specifically, any configuration options that are specified in the Linked HATS/WebFacing project wizard (such as host name or port, code page, and screen size) can only be modified after project creation by editing wfhats.xml, or by rerunning the project wizard. Changing the connection settings in the HATS or WebFacing project after linking will not affect the linked project.
• HATS connect macros will run when the HATS application is first accessed (from initial entry into the linked application, or from accessing a host screen that has not been converted by WebFacing). Therefore, you should not create a connect macro intended for the sign-on screen if your linked application will be started from WebFacing. Disconnect macros will only run if the linked application is terminated from the HATS runtime.
• Start and Connect events defined in a HATS project will run when the HATS application is first accessed. If the linked application is started from WebFacing, actions defined in these events will not be performed until a host screen that has not been converted by WebFacing is accessed. Therefore you should not, for example, play a macro intended for the sign-on screen in the Connect event if your linked application will be starting from WebFacing.
• If you use the HATS Administrative Console to change license settings while running in Run on Server mode, you must restart your linked application in order for the changes to take effect. If you use the HATS Administrative Console to change license settings while running in Debug on Server mode, the changes will not affect the linked application. This is because the HATS Administrative Console modifies the runtime-debug.properties file while running in Debug mode, and the linked application uses runtime.properties to determine license settings. Also note that if you are running in Debug on Server mode, you should verify that the license settings in runtime.properties match the license settings in runtime-debug.properties.
• For linked HATS/WebFacing projects, the only supported application server for deployment is IBM® WebSphere® Application Server.
• For the list of supported Web browsers for linked HATS/WebFacing applications, refer to the HATS prerequisites section of the HATS Knowledge Center .
• A linked HATS/WebFacing application must consist of one HATS/WebFacing enabled project and one HATS Web project. Other types of HATS projects (Rich Client, Portal, and Enterprise JavaBeans) cannot be linked.
• The HATS applet is not supported for linked HATS/WebFacing applications. Do not configure your project to use the applet.
• Any screen customization made using HATS will have no effect if the screen is also converted using WebFacing. This is because the WebFacing conversion will be used at runtime.
• When running a linked HATS/WebFacing application, HATS connection pooling is not used, even if it is configured in the HATS project.
• When running a linked application, the connection is persistent. Nonpersistent features, such as fail-over, will not function correctly.
• Workstation ID support is not available for the linked HATS/WebFacing application. You can link a HATS application that is configured for a special workstation ID; however, this setting will be ignored at runtime.
• HATS projects can have both a main transformation connection and one or more background connections to the same or different hosts. Linked project features and connection settings only apply to the main transformation connection.
• WebFacing supports limited-capability users on IBM i V6R1 and later. To use a profile with limited capabilities on V6R1, you must start the linked application from the HATS interface.
• In some cases, you may want to deploy your HATS application more than once to the same server. For example, the same HATS application can be deployed as a standalone application and part of a linked application. In order to deploy your HATS application more than once to the same server, you must provide a unique context root for each instance. To provide a unique context root:
  1. Right-click the project and select Properties.
  2. In the left pane, select Web Project Settings.
  3. Enter a new, unique context root in the Context Root field, and click OK.
  4. The Modifying Context Root dialog appears. Select Yes to fix links that reference the context root.
  5. Change the <display_name> value in the project's web.xml file.

  If you update the context root of either project after you have linked them together, you will need to update the wfhats.xml file to reflect the change. The wfhats.xml file is located in the root folder of the linked HATS/WebFacing project.

• You cannot access multiple linked applications at the same time in the same browser instance. For example, opening the browser and launching application A, creating a child browser window, and then accessing application B in the child window is not supported. A child browser is opened in Internet Explorer by doing Ctrl-N or File->New->Window. The same rule applies for tabs in Internet Explorer V10 and V11. In addition, if you wish to access application A and then application B in the same browser, you must first properly disconnect and exit application A before accessing application B. This only applies if applications A and B have the same context roots.
• You may see unexpected results when accessing a linked HATS/WebFacing application if you use the browser refresh and back buttons. See the HATS FAQs for details.
• Though the HATS toolkit allows you to create macros that navigate through DDS-based screens that have been WebFaced, the macros may fail when the application attempts to display the WebFaced screens. Macros cannot handle WebFaced screens if their display files were opened prior to the start of the macro execution, and the application will end in error.

Security considerations

When securing your linked HATS/WebFacing application using Tivoli® Access Manager, you must set two configuration options to allow your application to function properly.

• In the WebSEAL daemon configuration file (webseald.conf), enable the preserve-base-href setting:

  preserve-base-href = yes

• Create all junctions with the -j parameter, to allow WebSEAL to provide a junction identifier cookie to the browser.

For more information on these options, see the Tivoli Access Manager documentation for details.

Parent topic: WebFacing interoperability with HATS applications