Aliases

Mapping a URL-Path to a Defined Session

The main purpose of an alias is to re-route a browser's request from one location to another. The new location can be just a different session on the current server or it could be a complete URL to a different server.

The command WRKWBLALS will show a list of aliases and the values that they are mapped. The server checks every URL-path to see if an alias substitution should occur. If the URL-path begins with an alias, the value the alias is mapped to will replace the aliased portion of the URL-path and appends the end portion of the URL-path to the new URL-path. The replaced portion can be the whole URL-path, or any beginning portion of a URL-path. Note that Webulator/400 supports begins with alias matching. This means that the only time an alias substitution occurs is when the beginning of a URL-path matches a configured alias. This comparison is case-insensitive.

Webulator/400 assumes that all requests are Webulator/400 session requests. This means that you are not required to create any aliases in order to access a Webulator/400 session. You may choose to create aliases with a source type of *WEBULATOR if you wish to mask your implementation details from the user.

Alias Matching

These are some important points regarding aliases that you should know prior to setting up aliases.

Begins-with match: A check is only made to see if a URL-path matches an alias from the very beginning of the URL-path. An alias that appears in the middle or at the end of a URL-path is ignored.
Leading slash: All aliases should begin with a slash since all URL-paths begin with a slash. If the alias did not have a leading slash, it would never be found in a URL-path because only begins-with matching is done with aliases.
Maximal matching: If two aliases that begin the same are defined, the server has to decide which alias substitution to use on a URL-path that begins the same as both aliases. The server always uses the longest alias that still matches. For example, if an alias /abc maps to /uvw and alias /abcdef maps to /xyz and the URL-path /abcdef/screen1 is requested, the server has to decide if this should be converted to /uvwdef/screen1 or /xyz/screen1. Webulator/400 does a maximal match which means that the longest matching alias will always be picked. In this example, /xyz/screen1 would be used since it comes from the longest matching alias (/abcdef).

Webulator/400 Alias Examples

For example, assume that you have set up Webulator/400 sessions with the following names:

/region1/sales/orderentry: Automatically signs on the user with userid SALESENTRY whose user profile automatically runs the application SALES/ENTRY.
/region1/sales/orderstatus: Automatically signs on the user with userid ORDSTATUS whose user profile automatically runs the application SALES/STATUS.

The above Webulator/400 sessions are accessible by the complete Webulator/400 URL (www.xyz.com:5061/region1/sales/orderentry and www.xyz.com:5061/region1/sales/orderstatus) or you can create Webulator/400 aliases that will allow for more flexible access.

Assume that you define the following aliases:

/entry/: maps to /region1/sales/orderentry/ with a source type of *WEBULATOR
/status/: maps to /region1/sales/orderstatus/ with a source type of *WEBULATOR

Now, the same Webulator/400 sessions are accessible by using the newly defined aliases instead of the complete Webulator/400 URL (www.xyz.com:5061/entry and www.xyz.com:5061/status). The use or aliases allows for a shorter URL and hides the implementation details which means that you can restructure your Webulator/400 session names without breaking existing links to your site.

Increasing Alias Flexibility by Including Query String Options

It is possible to specify options on the query string of the URL that initializes a Webulator/400 session to change the behavior of that interactive Webulator/400 session. These query string options can be simplified by their incorporation as part of an alias, eliminating the need for the user at the browser to enter the complex string options.

When including the query string options in the alias value, the full URL-path must be specified. This includes the entire session path and query string.

Examples of Query Strings in the Alias

Assume that you have set up the following Webulator/400 session:

/region1/sales: Performs user authentication which requires a valid AS/400 user id and password to be provided.

This session will challange the user for a valid user id and password and run the initial program or menu defined for the user id. If query strings are configured for this session, you can change the behavior of this session by defining aliases with query strings.

Assume the following aliases have been configured:

/entry/: maps to /region1/sales?PGM=ENTRY&LIB=SALES with a source type of *WEBULATOR
/status/: maps to /region1/sales?PGM=STATUS&LIB=SALES with a source type of *WEBULATOR

With this setup, each of the following requests would be handled as described.

A URL-path of /entry: The server would accept this request, use the configuration values setup for the session /region1/sales and automatically start the program called ENTRY in the SALES library.
A URL-path of /status: The server would accept this request, use the configuration values setup for the session /region1/sales and automatically start the program called STATUS in the SALES library.

Using Aliases to Redirect URLs to Different Servers

A Web server has the ability to tell a Web browser to look for a URL at a certain location on an entirely different Web server. This is referred to as Redirection. This might be useful if a Webulator/400 application is removed from one server, and relocated to another. HTML documents with links to the old application location will still work since the server will redirect them automatically to the new location. Also, people that have a bookmarked URLs will still be able to find applications that have moved.

URL redirections can be permanent or temporary:

Permanent: The new URL will be in effect indefinitely and it is not planned to have the old URL be valid anymore.
Temporary: The redirection is only temporary. The old URL will be effective again or the redirection could change to something else at any time.

When redirecting a URL-path the entire new URL must be specified. This includes the protocol, server, port, and URL-path.

Examples of Alias Redirection

Assume that you are migrating from Webulator/400 version 1.x to version 2.0 and you want all of your version 1.x Webulator/400 URLs to be redirected to your new version 2.0 URLs.

If you have the following sessions defined in your version 1.x configuration:

/*meta/webulator/region1/sales/orderentry
/*meta/webulator/region1/sales/orderstatus

You should define the following session in your version 2.0 configuration:

/region1/sales/orderentry
/region1/sales/orderstatus

In order for existing links to find the new sessions, you must change any *WEBULATOR aliases in your existing Web Server/400 or Commerce Server/400 configuration files to be a redirect.

Assume that your existing configuration files had the following *WEBULATOR alias entry:

/WWW5250/

This entry should be changed to the following:

/WWW5250/: maps to http://www.yourcompany.com:5061/ (permanently).

With this setup, your existing Web Server/400 or Commerce Server/400 server would redirect all of your Webulator/400 requests to your Webulator/400 version 2.0 server running on port 5061.