Redirecting users to the consolidated system
The majority of end users typically access the BMC Helix ITSM application using a web browser or (prior to AR System version 7.6.04) the AR System User Tool. While AR System User Tool users are significantly impacted by the upgrade from ITSM 7.6.04, typically the vast majority of users will access ITSM using a web browser. The URL used by users to access the BMC Helix ITSM system connects them to a user-facing web load balancer that directs the traffic to a mid tier server.
In a parallel environment upgrade scenario, users are typically redirected by changing the routing of the user-facing web load-balancer. This change is illustrated in the following diagrams. This approach means that users can continue to use the same URL to access the production system by using their browsers.
To ensure that any context-sensitive links sent to users in email notifications continue to work, the name of the AR System server group is kept consistent between the new and old production systems.
In short, this method ensures that there is little to no impact to customers using the BMC Helix ITSM application following an upgrade. However, despite the low impact of this approach on the user community, this method is not recommended for a typical consolidation.
In some consolidation scenarios, users cannot continue by using the same URL to access the BMC Helix ITSM system. For example, the system they are being moved to has a pre-existing URL associated with it. So, even in the Merge scenario, only the initial set of companies being merged into the system can retain their original URL.
User can connect to a single BMC Helix ITSM system using different URLs, but the context-sensitive links sent to users in email notifications can only be sent by using a single URL. Furthermore, some BMC Helix ITSM applications (in particular, Service Request Management) expect a single URL to be used.
Our recommended method for managing user-facing URLs as part of cutover of a consolidated system is to logically retain the existing user-facing load balancer for the original production system but to direct it to a servlet that will rewrite the URL to direct traffic to the user-facing load balancer of the new production system into which the consolidation has been performed.
The new URL is communicated to the users of the original production system who might use this directly in their browsers. However, if they forget and use the original URL, they are automatically redirected to the new system.
After a period of time, you can phase this feature out. You can replace the servlet with a static page that informs the user to use the new URL and no longer automatically redirect.
Finally, you can remove these components so that users using the original URL are no longer redirected or advised to redirect. While it is possible to achieve the same result with network configuration, this approach has the significant benefit of allowing URLs that were sent to users in emails to be parsed and fully rewritten by the servlet so that they are valid for the consolidated system. A Java servlet is simple to create and runs on the same Apache Tomcat server that was used to host mid tier.
This is a low-cost and low-impact solution. The diagrams illustrate the logical architecture rather than a physical architecture. You do not need to maintain two load balancers or to locate the servlet on the original production architecture. The exact configuration is dependent on your local architectural configuration and restrictions.