Create and organize projects

 

Overview

When you create a new HATS project, a set of folders is created to help you organize your HATS files. The highest level folder has the same name as the name you give to your project when you create it. In that folder are other high-level folders that contain objects defined in your HATS project:

Depending on how you set up your HATS project, some or all of these folders may appear in your HATS Project View. You can also specify which folders appear in your HATS Project View as well as hiding file extensions.

HATS EJB projects and HATS projects differ. The directory tree for a HATS EJB project will have no Screen Customizations, Screen Captures or Web Content folders.

You can create subfolders within these high-level folders to help organize your project. For instance, as you create screen captures for your project, you might want to create folders under the Screen Captures folder to organize and group the captured screens. To create a folder, right-click on one of the high-level folders in the tree and click...

New HATS | Folder

To move a file into a different folder, right-click on the file and select Move, or you can use the drag-and-drop method.

There is a limitation for subfolders. The transformation JSP and the template JSP must be in subfolders of the same level. To use a transformation JSP that resides at a certain level of subfolders, such as \transformations\Callup\SearchRequest.jsp, then the template JSP that will be coupled with this transformation must be at the same level of subfolders, like...

\templates\Callup\Simple1.jsp.

HATS projects, created in HATS Studio, are extensions of Web projects in the WebSphere Studio workbench. Expand the sections to find information on Web projects by clicking...

Web development | Concepts | Web resources

By default, all HATS applications are stored in one Enterprise Archive file, HATS.ear. When you assemble your applications and deploy them on WAS, the HATS.ear file contains a .war file with the resources to run each application, as well as one copy of the HATS runtime executable code. If you prefer, you can organize your applications differently, either each in its own .ear file, or in some other combination.

 

Organize a HATS project

Consider the effect of the following on your server machine when deciding how to arrange your projects:

Disk space

If you create each project in its own .ear file, it has its own copy of the HATS runtime code. The runtime code is approximately 16 MB; multiply that by the number of projects you have to see how much disk space is consumed on your WAS machine for each project.

Maintenance

If you update a project and redeploy the .ear file, you are redeploying all the projects in that .ear file.

Logging and tracing

Logging and tracing are controlled at the level of the .ear file, not at the individual HATS application level. If each HATS project is in its own .ear file, you can control its logging and tracing settings independently of any other projects. If you have several HATS projects in one .ear file, logging and tracing settings apply to all HATS projects in the .ear file. Messages for all HATS projects in the .ear file are inserted into the same log file, and trace information for all HATS projects is inserted to the same trace file.

License tracking

License tracking is also controlled at the level of the .ear file, not at the individual HATS application level. If each HATS application is in its own .ear file, license tracking is done independently of other applications. If you have several HATS applications in one .ear file, license tracking is performed for all HATS applications in the .ear file. Information about license usage is kept for all HATS applications in the .ear file, and is inserted into the same license usage file.

Enable HATS runtime

The HATS menu contains an item called Enable HATS runtime. This menu item is used to upgrade alicense restricted version of HATS to the

 

Move a project

To move a project from one .ear to another, follow these steps:

1. Click the Navigator tab of the HATS Studio to display the .ear files.
2. Expand the .ear file to which you want to move a project. Expand the META-INF folder and locate the application.xml file.
3. Start the WebSphere Studio application.xml editor by double-clicking the application.xml file.
4. In the application.xml editor, click the Module tab to display the .war files for your projects.
5. Click Add to display the Folder Selection dialog.
6. Select the project you want to add to the .ear file.

   Make sure you select the project, and not the .ear file with the same name.

7. Click OK.

If you want to move a project to another machine with WebSphere Studio installed, export the project as a .zip file before sending the project to another machine.

To export the project from HATS Studio to a .zip file:

1. Click the Navigator tab of the HATS Studio.
2. Click...

   File | Export | Zip file | Next

3. Do not select the .ear file and the .ear project. Expand the project and check all of its subdirectories, as well as all the files in the project (in the right-hand pane). Click Create only selected directories do not click Create directory structure for files.
4. In the Zip file field, type export destination of the file. You can also select an export destination by clicking Browse.
5. Click Finish.

 

Import a project

Which .ear file your project files go into is determined when you create the project. On the first panel of the Create a Project wizard, you can use the default setting of Use default Enterprise Application project, in which case project files are created within HATS.ear, or you can clear that check box and specify a different .ear file to contain your project's files. In HATS Studio, you cannot choose a different .ear file after the project is created. However, you can move projects from one .ear to another, using the WebSphere Studio application.xml editor.

To import the project in a .zip file into HATS Studio:

1. Create a new HATS project using the same name as the project you are importing. If you use a different project name, you will get an error message that indicates that the context root does not match.
2. Click...

   File | Import | Zip file | Next

3. In the Zip file field, type the location of the .zip file. You can also select the location by clicking Browse.
4. Click Browse next to the Folder field, and select the name of the new HATS project you created.
5. Click Finish.
6. When the .zip file is being imported, click Yes to all to overwrite existing files.

The new project will contain the original HATS project.

 

Manage projects

To share HATS project files with other developers in a team environment, use a repository such as Rational Clearcase. Using a repository is easier and more robust than importing and exporting individual projects in .zip files. WebSphere Studio supports several repositories.

 

Planning

HATS enables you to use an iterative approach to application development. You can start with simple configuration and add refinements as you are ready. You can test each change as you make it, and modify it if needed before you proceed to the next change. This section describes some strategies that you can use to design and develop your HATS application.

One approach to designing a HATS application is to first configure application-wide settings and see how much of your host application can be handled without configuring specific screens. You can change application-wide characteristics under the various tabs of the project settings. See Rendering for more information.

Another type of application-wide configuration you can perform is changing the characteristics of host components and widgets. You can change these settings at the project level by changing the default rendering to establish defaults to be used on most of your host screens, and also change the settings for individual instances of components and widgets when you add them to transformations. To change the settings for your transformations, see Rendering for more information.

Try making a few application-wide changes, such as:

• Make a change to the default rendering. For example, change a selection list so it renders as a drop-down list. This will change all selection list to drop-down lists.
• Create one or more global rules to configure the way HATS transforms the input fields on your host screens. For example, change date fields to calendar widgets or location fields to drop-down lists.
• Use text replacement to change one or more strings that appear on your host screens.

After each change, you can save your work and use the Run on Server function to see the results.

Look at the way your host screens are transformed. Are there elements that appear on several screens that you want to see transformed differently? Those might be candidates for modifying the settings of some components (to change how host components are recognized) or widgets (to change how the HTML controls are rendered on the Web page).

You might also want to consider using the Create a Screen Customization wizard to define a set of screen recognition criteria used to match host screens, and a list of actions to be taken when a host screen matches the screen recognition criteria.

Perhaps you want to combine one screen with another. It is a common task to present multiple host screens as a single Web page. HATS allows you to do this by using macros, transformation JSPs and global variables.

 

Configure HATS applications in a clustered environment

If you deploy HATS applications in a vertically clustered environment, each application server instance will create its own files for logging, tracing, and license tracking. This is accomplished by decorating the names of the output files with the fully-qualified name of the application server instance. For example, the default pattern for the logging file is messages.txt, but the actual filename will be something like...

messages_myCell_myNode_myAppServerInstance_1.txt

By default, all of the server instances will read the same runtime.properties file for their settings, so to properly control runtime settings configure each instance so that it will have its own runtime.properties file. This will allow you to control tracing for each instance independently, and will prevent runtime settings from changing spontaneously.

Follow these steps to configure your vertically clustered HATS application instances so that each has its own runtime.properties file:

1. Make a copy of the runtime.properties file for each application server instance in the vertical cluster.
2. Add a new JVM setting to identify the runtime.properties file used by each instance.

Each of these steps is explained in detail below:

1. Locate the runtime.properties file for your HATS application. This file should reside in the installedApps\app_name.ear directory under the directory where you installed WebSphere Application Server.

   For each instance, make a copy of runtime.properties, with a unique name, in the same directory. For example, you could name the files Clone1runtime.properties, Clone2runtime.properties, and so on. Use any valid file name, but the name should help the administrator identify the application server instance with which this file is associated.

2. At this point, for N server instances you will have N unique runtime.properties files. Now perform these configuration steps for each application server instance in the vertical cluster:

   1. Select the Application Servers link inside the Servers item in the left navigation pane of the WebSphere Application Server Administrative Console.
   2. Select the server instance from the list of application servers, and choose the Process Definition link from the Configuration tab for the server.
   3. Select the server's Java Virtual Machine link. On the Java Virtual Machine page, scroll down to the Custom Properties link, and select it.
   4. In the Custom Properties dialog, click New to add a new system environment property.
   5. In the Name field, enter hats.runtime.properties. In the Value field, enter the name of the properties file that you created for this server, for example, Clone2runtime.properties. Do not specify directory names or slashes in this value. The Description field does not require a value.
   6. Click Apply.
   7. Repeat this procedure for each server instance.

If you have more than one HATS application in your vertically clustered environment, repeat these steps for each HATS application.

After adding the System Environment Property and ensuring that each server instance has its own runtime.properties file copy, start or restart each so that it will pick up the new hats.runtime.properties setting and use its own settings file.

The HATS Administration can control the settings of the cluster members. Use the Getting Started folder in the Navigation Panel of the Administration Web page to select the Management Scope. Once you've chosen the desired cluster, choosing to view the Trace Settings will prompt you for the particular cluster member you wish to control.

 

Security considerations

For information regarding security and HATS, see Security and Web Express Logon. For WebSphere Application Server security information, visit the WebSphere Application Server online library at http://www.ibm.com/software/webservers/appserv/was/library/.

 

Home