Architecture & Host Sizing

The Gateway Platform is made up of one or more Gateway Servers and one or more Remote Integrators. Gateway servers are cloud-hosted (either in a company data center or by a cloud provider) and bridge the public internet and private intranet. Remote Integrators are the remotely hosted workflow engine which sit behind the customer firewall.

Open

In this topology, there are a number of network appliances:

• Each Remote Integrator sits within the customer network, behind the customer’s network appliance (firewall). Typically, the customer does not need to make any configuration changes to their network appliance as outbound traffic from the Remote Integrator is used to establish the network tunnel with the Gateway.

• The Gateway Cluster sits behind the company’s public-facing network appliance. Each Gateway has its own public endpoint (gw1.company.com, gw2.company.com), and inbound traffic to these endpoints is routed to each Gateway host. Typically, the TLS tunnels between each Remote Integrator and Gateway is terminated at the Gateway, but termination can also happen at the appliance (F5, AWS WAF, etc.).

• The Gateway cluster can be further isolated from the Company’s private network via a network appliance which restricts outbound traffic from the Gateway Cluster to the private network. If the Gateway database is hosted within the private network, a route will need to be created to allow this traffic.

Traffic between Remote Integrators and the Gateway Cluster is encrypted using standard TLS tunnels. A valid 3rd-party provided certificate is required for each Gateway endpoint, with a wildcard certificate being the recommended approach. Internal traffic also uses these certificates to create TLS tunnels.

Gateway Cluster

The customer-hosted Remote Integrators are fully-featured workflow engines, and in some cases there is no need to transfer data to the company network. In this case, the Gateway cluster is simply used for management of the Remote Integrators and any configured Enterprise features. This requires very little resources and a pair of small servers is sufficient (4-core, 16GB RAM).

A core component of the Gateway cluster is it’s ability to tunnel data between Remote Integrators and Connexion Instances. For example, you may acquire some customer data (via, HL7, files, HTTP, etc.) and then securely pipe that data to a specific Connexion channel. This channel can perform some operations, and then optionally return data back to a specific Remote Integrator channel (and onward to a customer system). Gateways which are brokering data should use medium size servers (8-core, 32GB RAM).

In either case, almost no information is stored local to the Gateway, so disk space requirements are minimal.

Gateway Database

Gateways store all configuration data within a database (either Sql Server or Postgres). There is typically very little load/traffic on the database, so a small host is fine (4-core, 16GB). Databases must be redundant for the overall Gateway cluster to be redundant.

Redundancy

A Gateway cluster is inherently redundant, as each Gateway instance can accept traffic from any Remote Integrator. If one Gateway host fails, Remote Integrators will switch to a remaining accessible host. This also allows for rolling upgrades with near zero downtime.

The Gateway database, however, does require redundancy. If using Sql Server, you can use any of the built-in redundancy mechanisms. Many of the cloud providers provide automatic redundancy for both Sql Server and Postgres (RDS/Aurora).

Also note that a single Connexion instance is not redundant - you need a Connexion cluster with associated redundant database for end-to-end redundancy.

Remote Integrators

Remote Integrator configuration data is all stored within the Gateway database. When the Remote Integrator starts, it pulls all required configuration data and caches it locally. This means that a failed Remote Integrator can be quickly re-created by simply re-installing it at the customer site.

Remote Integrators store message data locally only, in a non-redundant database. If a Remote Integrator host fails, message data may be lost. Typically, Remote Integrators are ingesting data from other systems, so this is not an issue.

The Remote Integrator itself is fairly resource efficient. We recommend a minimum of 4-core, 16GB RAM, and 10GB disk free space. You will need to increase the disk free space depending on the volume of data expected to pass through the Remote Integrator.