High Level Overview of Public URIs and Server Rename

Authors: MikeDelargy
Build basis: 4.0.1 (and higher), 5.x

Page contents

Public URIs, Proxy Servers, and Server Rename
*Understanding the communication in a CLM Deployment*

Accessing CLM

When a user accesses a CLM deployment, the user enters the Public URI for the application into a browser window.
Depending on the deployment architecture, the Public URIs may have the same ‘stem’ in the public URI and a different “context root” or the Public URIs could be completely different.

CLM application	Typical Enterprise Deployment	Typical Departmental Deployment
Jazz Team Server /jts	https://jts_server:9443/jts	https://clmserver:9443/jts
Rational Quality Manager/qm	https://rqm_server:9443/qm	https://clmserver:9443/qm
Rational Doors Next Generation/rm	https://rdng_server:9443/rm	https://clmserver:9443/rm
Rational Team Concert/ccm	https://rtc_server:9443/ccm	https://clmserver:9443/ccm

Departmental Deployment:

Enterprise Deployment:

Here, my pubic URI’s are:

https://jtsserver:9443/jts Where jtsserver is the computer name (or virtual hostname configured in W.A.S.) The service is listening on port 9443 and the context root is jts

https://rtcserver:9443/ccm Where rtcserver is the computer name (or virtual hostname configured in W.A.S.)The service is listening on port 9443 and the context root is ccm

https://rqmserver:9443/rqm Where rqmserver is the computer name (or virtual hostname configured in W.A.S.)The service is listening on port 9443 and the context root is qm

https://rdngserver:9443/rm Where rdngsrver is the computer name (or virtual hostname configured in W.A.S.)The service is listening on port 9443 and the context root is rm

Applications "communicating" with each other

The servers reference each other through their Public URIs

When JTS application server wants to communicate with the RDNG server, it does so through the public URI https://rdngserver:9443/rm
When RTC application server wants to communicate with the RDNG server, it does so through the public URI https://rdngserver:9443/rm
When RQM application server wants to communicate with the RDNG server, it does so through the public URI https://rdngserver:9443/rm

When JTS application server wants to communicate with the RTC server, it does so through the public URI https://rtcserver:9443/rccm
When RQM application server wants to communicate with the RTC server, it does so through the public URI https://rtcserver:9443/rccm
When RDNGapplication server wants to communicate with the RTC server, it does so through the public URI https://rtcserver:9443/rccm

When JTS application server wants to communicate with the RQM server, it does so through the public URI https://rqmgserver:9443/qm
When RTC application server wants to communicate with the RQM server, it does so through the public URI https://rqmgserver:9443/qm
When RDNG application server wants to communicate with the RQM server, it does so through the public URI https://rqmgserver:9443/qm

When RQM application server wants to communicate with the JTS server, it does so through the public URI https://jtsserver:9443/jts
When RTC application server wants to communicate with the JTS server, it does so through the public URI https://jtsserver:9443/jts
When RDNG application server wants to communicate with the JTS server, it does so through the public URI https://jtsserver:9443/jts

This is true for each of the applications and each of the “artifacts” within the applications.

The Public URI’s are in each of the application configuration files and are embedded in the artifacts for each application stored in the database(s)

User communicating with the Applications

Here, the user talks directly to each application server but the application servers still “communicate” directly with each other.

When JTS application server wants to communicate with the RDNG server, it does so through the public URI https://rdngserver:9443/rm
When RTC application server wants to communicate with the RDNG server, it does so through the public URI https://rdngserver:9443/rm
When RQM application server wants to communicate with the RDNG server, it does so through the public URI https://rdngserver:9443/rm

When JTS application server wants to communicate with the RTC server, it does so through the public URI https://rtcserver:9443/rccm
When RQM application server wants to communicate with the RTC server, it does so through the public URI https://rtcserver:9443/rccm
When RDNGapplication server wants to communicate with the RTC server, it does so through the public URI https://rtcserver:9443/rccm

When JTS application server wants to communicate with the RTC server, it does so through the public URI https://rtcserver:9443/rccm
When RQM application server wants to communicate with the RTC server, it does so through the public URI https://rtcserver:9443/rccm
When RDNGapplication server wants to communicate with the RTC server, it does so through the public URI https://rtcserver:9443/rccm

When JTS application server wants to communicate with the RQM server, it does so through the public URI https://rqmgserver:9443/qm
When RTC application server wants to communicate with the RQM server, it does so through the public URI https://rqmgserver:9443/qm
When RDNG application server wants to communicate with the RQM server, it does so through the public URI https://rqmgserver:9443/qm

When RQM application server wants to communicate with the JTS server, it does so through the public URI https://jtsserver:9443/jts
When RTC application server wants to communicate with the JTS server, it does so through the public URI https://jtsserver:9443/jts
When RDNG application server wants to communicate with the JTS server, it does so through the public URI https://jtsserver:9443/jts

This is true for each of the applications and each of the “artifacts” within the applications.

The Public URI’s are in each application’s configuration files and are embedded in the artifacts for each application stored in the database(s)

Introducing a Proxy Server

When you introduce a proxy server, all traffic gets routed through the proxy server which then redirects the traffic based upon the context root.

When a proxy server is configured, the applications still communicate with each other using the public URI, but the “stem” of the public URI always points to the proxy server.

Typically, if you are implementing a proxy server, then the “stem” of the public URI would not change but each application would still have a distinct context root.

JTS server would have https://clmserver/jts
RTC server would have https://clmserver/ccm
RQM server would have https://clmserver/qm
RDNG server would have https://clmserver/rm

The Proxy server looks at the context root of the traffic ( jts, ccm, rm, qm) and directs traffic accordingly. The proxy sends

/qm traffic to the RQM Application server
/jts traffic to the JTS application server
/ccm traffic to the RTC server
and /rm traffic to the RDNG server

In this case, the I.H.S. (Web Server) “takes over” the public URI. (clmserver) Meaning, either the I.H.S. server name has to be the same as the public URI OR, you configure a virtual host name on the I.H.S. server (httpd.conf file) to “spoof it” into thinking that its name is the public URI.

Implementing a Proxy Server

Proxy Server

If you implemented / configured a proxy server into your environment on Day 1 (before you actually deployed) then your users and application server communicate to each of the applications through the proxy server.

If you want to move an application server with this proxy configuration, you do not need to do a server rename, you simply modify your proxy server to point to the new server.

If you did not implement a proxy server in your initial deployment, then all users and applications communicate with the application servers directly.

If you want to move an application to a new server with a different name, then you may* need to do a server rename.

Server Rename

Server Rename

If you want to change your Public URI for whatever reason, you MUST do a server rename.

The Public URI is embedded deeply within each artifact of each application. Therefore, implementing a server rename is the only way to change the Public URI of a deployment.

Why do a Server Rename?

Company got bought by another company and the domain changes
Want to remove a port number from a Public URI
You want to create a test environment from a production system
You are moving from Test to Production and the original Public URI was “localhost” or contained an I P address.

Server Rename Best Practices

If you are going to change your Public URI consider creating a more “portable” URI that would not have to be changed again.
Try to avoid using real server names as they are less portable
Consider implementing a proxy server for easier portability and HA/DR

Server Rename Mapping File

In a server rename, we create a mapping file that defines each “original” Public URI and maps this to the new ‘desired’ Public URI.

#/context root
source=https://old_server:9443/context_root
target=https://new_server:port/jts

In the Target Public URI, we have omitted the PORT because we are going to configure a proxy server into our deployment. The Proxy Server (Web Server / I.H.S. server) will be configured to listen on the default ports 80 and 443 so no port number is necessary.If I wanted to, I could configure my proxy server to listen on ports 9080 and 9443 but if I did that, then I would have to include the port number in the Target URI

In this example, we are using an enterprise deployment and we want to implement a proxy server.

Clmserver is the virtual hostname for our proxy server

We are also configuring our proxy server to listen on the default ports of 80 and 443 so the new public URIs (target URIs) will not have to include a port number.

#/jts
source=https://jtserver:9443/jts
target=https://clmserver/jts

#/qm
source=https://rqmserver:9443/qm
target=https://https://clmserver/qm

#/rm
source=https://rdngserver:9443/rm
target=https://clmserver/rm

#/rtc
source=https://rtcserver:9443/ccm
target=https://clmserver/ccm

Back to the Server rename landing page

External links:

Additional contributors: TWikiUser, TWikiUser

This topic: Deployment > WebHome > DeploymentInstallingUpgradingAndMigrating > ServerRename > Highleveloverviewofpublicuriandserverrename

History: r1 - 2015-02-12 - 20:00:41 - Main.msdelarg

Copyright © by IBM and non-IBM contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our Terms of Use. Please read the following disclaimer.
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.