Linked HATS/WebFacing applications have several technical and security considerations. In general, any limitations posed by a standalone HATS application or a standalone WebFacing application will also apply to linked HATS/WebFacing projects. In addition, you should consider the following information when designing and deploying your own projects.
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 re-running the project wizard. Changing the connection settings in the HATS or WebFacing project after linking will not affect the linked project.
The Field Exit key is handled differently between HATS and WebFacing. For HATS, data formatting and validation are done by the runtime. With WebFacing however, data formatting and validation are done at the client side in the browser. Ctrl+Enter is the default keyboard shortcut for Field-Exit for both HATS and WebFacing. See Providing documentation for users for other keyboard shortcuts available in HATS projects.
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 Adminstrative 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 Adminstrative 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.
The only supported client browser for any linked HATS/WebFacing application is Microsoft® Internet Explorer.
A linked HATS/WebFacing application must consist of one HATS/WebFacing enabled project and one HATS Web project. Other types of WebFacing projects (Web and Portlet) and 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. Non-persistent 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.
To use a profile with limited capabilities, you must start the linked application from the HATS interface.
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 V7. 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.
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.