Hybrid Integration 10.2 | Integrating On-Premises Applications | Clustering | An Overview of Clustering | Remote Integration Servers in a Cluster
 
Remote Integration Servers in a Cluster
An Integration Server can be configured to connect to a remote server for a number of reasons, including:
*Allow clients to run services on other Integration Servers using the pub.remote:invoke service and the pub.remote.gd:* services.
*Connect publisher and subscriber Integration Servers to each other for the purpose of package replication.
*Facilitate the process of presenting different certificates to different Integration Servers.
In general, if a remote server is not available when a request is made, and the remote server is not part of a cluster, Integration Server will use the retry server specified in the alias definition for the remote server.
If the requested remote server is part of a cluster, Integration Server will attempt to use the next Integration Server in the cluster until one is found. If no available Integration Server is found in the cluster, Integration Server will use the retry server specified in the alias definition for the remote server.
In cases where a client calls the pub.remote:invoke to run a service on a remote server that is part of a cluster, it is possible to modify the default behavior by using the $clusterRetry.
This parameter controls whether the service will try other Integration Servers in the cluster. When this parameter is set to true, the service will try other Integration Servers in the cluster. If none are found, the service will try the retry server specified in the remote server alias definition. When this parameter is set to false, the service does not try other Integration Servers in the cluster. Instead, it will try the retry server specified in the alias definition.
For more information about remote servers, see webMethods Integration Server Administrator’s Guide.
For more information about the pub.remote:invoke service, see the webMethods Integration Server Built-In Services Reference.
You can also use the Java API to control the retry behavior. Specifically, if you are using the Context or TContext class, you can control whether Integration Server looks for a retry server by calling the BaseContext.setAllowRedir method. In addition, you can specify which retry server to use by calling the BaseContext.setRetryServer method. For more information about the Context and TContext classes, see the webMethods Integration Server Java API Reference.

Copyright © 2015- 2018 | Software AG, Darmstadt, Germany and/or Software AG USA, Inc., Reston, VA, USA, and/or its subsidiaries and/or its affiliates and/or their licensors.
Innovation Release