Manually replacing URLs for HAT configuration in IAG

Article
02/10/2010

Applies To: Intelligent Application Gateway (IAG)

In Whale Communications Intelligent Application Gateway (IAG) 2007 you can manually replace unrecognized URLs in requests with a valid path. You can configure URL replacement rules to redirect requests to a site on the portal application list.

Configuring URL replacement rules

Configure URL replacement rules as follows:

To configure manual URL replacement

In the IAG Configuration console, select the required portal.
Next to Advanced Trunk Configuration, click Configure.
In the Application Access Portal tab, under the Manual URL Replacement list, click Add.

The URL Change dialog box is displayed.
Configure the URL replacement rule, as described in the table below.
Once you finish configuring the rule, in the URL Change dialog box, click OK.

The URL Change dialog box closes. In the Application Access Portal tab, the replacement you configured is added in the Manual URL Replacement area.

Note

If you wish to redirect the URL to a URL with a different name, enter the replacement URL in To URL.
Repeat steps 4 through 5 to configure all the URLs you wish to replace.

Once the trunk is activated, the absolute paths you configured here will be replaced with absolute URLs, and the filter processes them.

Note

If the replacement type is Rerouting and you enter a value in To URL, the replacement mechanism adds the value of the source URL as a parameter to the destination URL.

For example:
If URL is /whale, To URL is /whale_internal, and Type is Rerouting, the destination URL is:
/whale_internal?WhlSourceURL=/whale

Manual URL replacement parameters

Parameter	Description
URL	URL path to be replaced. Must be a regular expression.
To URL	URL path that will replace the path defined in URL, above. In most cases, this field is left empty, and the value of this field is derived from the URL path requested by the browser, on the site defined in Server Name, below. Note If you do fill in this field, enter an absolute path, using plain text; do not use regular expressions in this filed.
Type	Select the type of replacement: Redirect—Returns the HTTP 302 status, which redirects the browser to the URL path defined in To URL, above. This option is selected by default and is recommended for use with most applications, because all relative links within the HTML page are also directed to their true location when requested. Rerouting—Replaces the original URL with the URL defined in To URL, above. Select this option only if your application uses a protocol that does not support the HTTP 302 status, such as WebDAV. In this case, you have to configure each of the relative path links that appear within the HTML page to be rerouted to their true location. Note Redirect can only be applied to GET requests. All other requests are rerouted.
Server Name	IP address or domain name of the server to which URL, above, will be redirected or rerouted (precedes the URL defined in To URL, above). Note If the rule you are creating is a dynamic forwarding rule, refer to Dynamic Forwarding Rules for instructions on how to define this field.
Dynamic	Determines whether requests will be dynamically rerouted or redirected between different servers. A description of this feature and instructions on how to define it are provided in Dynamic Forwarding Rules.
Port	Port number of the server defined in Server Name, above.
Use SSL	Check this option if the port is a Secure Sockets Layer (SSL) port.

Dynamic forwarding rules

When there is more than one server defined for an application, you can define a dynamic URL replacement rule that will automatically reroute or redirect requests to the appropriate application server for the current session. The dynamic forwarding rule must include the two following server-related definitions:

A dynamic parameter that is used to determine the destination server to which the request is forwarded. You define the dynamic parameter in an authentication hook and refer to it from the URL replacement rule.
A fallback server, to which requests are forwarded in case the dynamic parameter cannot be resolved. The fallback server must be a server that is defined in IAG; that is, it appears in the Web Servers tab of the Application Properties dialog box for one of the defined applications.

To create a dynamic forwarding rule

Create an authentication hook, or use an existing hook, as described in IAG_Adding functionality to the default pages.

Important

You must use a hook that is executed before the request is processed, otherwise the fallback server will be used for the duration of the session.
In the hook, add the required dynamic parameter value assignments.

Each assignment must be in this format:

SetSessionParam g_cookie,

"< DynamicParamName >","< DynamicParamValue >"

Where:
- DynamicParamName is the session variable name that is referred to from the dynamic forwarding rule. You must use the same DynamicParamName in all the dynamic parameter value assignments that relate to the dynamic forwarding rule.
- DynamicParamValue is a dynamically assigned server hostname to be used at runtime when a request to the URL defined in the dynamic forwarding rule is handled.
For Example:

<%

If ConditionA Then

SetSessionParam g_cookie, " DynamicServer ",

"app-serverONE.mycompany.com"

Else

SetSessionParam g_cookie, " DynamicServer ",

"app-serverTWO.mycompany.com"

End If

%>

Where:
- DynamicServer is the session variable used for all assignments related to this rule.
- The first assignment determines that the server app-serverONE.mycompany.com is used if the runtime check succeeds.
- The second assignment determines that the server app-serverTWO.mycompany.com is used if the runtime check fails.
In the Application Access Portal tab of the Advanced Trunk Configuration window, in the Manual URL Replacement area, click Add.

The URL Change dialog box is displayed.
Configure the URL replacement rule, as described in the table above, including the following:
- In Server Name, enter this string:
  
  *<DynamicParameterName>*<fallback_server>
  
  Where:
- < DynamicParameterName > is the session variable name you defined in step 2.
- < fallback_server > is a fallback server you choose from the servers defined for the relevant application and appears in the Web Servers tab of the Application Properties dialog box.
- Select the Dynamic option.
Once you finish configuring the rule, click OK to close the URL Change dialog box.

The rule you defined is added in the Manual URL Replacement area. Once the trunk is activated, requests are forwarded dynamically to one of the servers defined in the hook or to the fallback server.

Note

The server to which requests are forwarded when the first request is sent is used for the entire session. The dynamic forwarding rule is applied again when a new session is opened.

If you change the application servers in the Web Settings tab of the Application Properties dialog box, make sure that you adapt both the dynamic parameter in the authentication hook and the dynamic forwarding rule, accordingly.

For Example:

In the Application Access Portal tab of the Advanced Trunk Configuration window, the dynamic forwarding rule is defined:

In the WhalePortal1PostPostValidate.inc file, the following lines define the dynamic parameter:

<%

If SomeRuntimeCheck Then

SetSessionParam g_cookie, "DynamicApplicationServer",

"my-first-app-server.mycompany.com"

Else

SetSessionParam g_cookie, "DynamicApplicationServer",

"my-second-app-server.mycompany.com"

End If

%>

When a request to a URL that begins with /my-rerouted-url/ is handled, the dynamic forwarding rule refers the request to one of the dynamically assigned server host names, depending on whether the runtime check succeeds or fails:

my-first-app-server.mycompany.com or my-second-app-server.mycompany.com

If the DynamicApplicationServer session variable cannot be resolved, the request is sent to the following fallback server:

my-fallback-app-server.mycompany.com