Configuring a mid tier to launch a browser in a different mid tier

You can configure a central  to launch a browser on another . Perform this procedure on the central server for each remote server that you are configuring.

Before you start this procedure, review Multiple browser sessions in a distributed mid tier environment.

If you use  applications, see Registering hub and spoke servers.

To configure a  to render content in a different 

1. On the central , add a new entry to the  to Key Map form for the remote .
   

   1. In the Server Name field, type the name of the server used for the remote  in the Mid Tier Configuration Tool of the remote . 

      If you enter the Fully Qualified Domain Name (FQDN) of the , make sure that the FQDN of the remote  can be resolved by using the domain name system (DNS) from the central  server and from the remote mid tier server.
      
      If the FQDN of a remote  is invalid, make sure the Server Name value for the remote server is valid in the  to Key Map form on the central server. Make sure the valid remote Server Name can be resolved from outside the specific DNS.

   2.  In the Public Key field, copy the Public Key for the remote . 
      Click the expand box of the Public Key field, and copy the Public Key into the expand box. The Public Key for the remote  is in the server's entry on the   to Key Map form hosted on the remote  (for example, http:///midtierservername:port///arsys**). In a server group, the group shares the same Public/Private key pair.

   3. In the Web Path field, enter the mid tier base URL for the remote .
       If there is a load balancer situated between the browser and the remote , type the URL of the load balancer instead of the mid tier base URL.

      Best practice
      For improved security, we recommend that you use HTTP over SSL (HTTPS) on all s. If a reverse proxy or load balancer is set up with HTTPS protocol, and the  server is set up with HTTP protocol, then the transfer of information between these two servers is less secure. The less secure transfer of information between the two servers is most likely limited to within the secured intranet zone.

      If you need higher security with encryption at all levels, you can set up the mid tier server with HTTPS protocol. However, this might impair performance to end users due to multiple levels of encryption and decryption.

      If you configure multiple remote servers on the same reverse proxy, configure those servers with name-based virtual hosting and not URI path-based naming. For example, one central server and two remote servers on a single reverse proxy would be named hub.eng.remedy.com, spoke1.eng.remedy.com, and spoke2.eng.remedy.com. For details, see Sample configuration of a single reverse proxy server.

2. Write a workflow that invokes an Open Window action on the remote .
   See the example below.
   You can process requests in only one session at a time. Therefore, click Open in New Window only once and then process that request. If you log on to the remote server in another browser window on the remote , and then close the new window without logging off, you can receive an error while attempting to process a request in the original session. This error is caused by concurrent sessions.

Example of creating an Open Window action workflow

1. Using SAMPLEDATA source, specify the following:
   • Sample Server Name as the central  (such as arscentral.bmc.com)
   • Sample Form as User
   • Runtime Server Name as $Srv$
   • Runtime Form Name as $Form$
2. Set up Window Type as Submit.
3. Set up Target location as New.
4. Set the Login Name field (field ID 101) to User.
5. Save the active link.