Dynamic Inbound Routing

Connexion dynamic inbound routing keeps external inbound endpoints aligned with whichever application server currently runs a channel.

This is important in a multi-active cluster because a channel is not permanently tied to one EC2 instance or Kubernetes pod. Connexion can move a tab or channel group as capacity changes, during maintenance, or when an application server is replaced. Dynamic routing updates the configured front end so inbound traffic follows that placement automatically.

Why Dynamic Routing Is Needed

Traditional single-server deployments can expose an inbound device directly from a fixed host and port. In a dynamic cluster, the host running that device can change.

Connexion separates the two concerns:

• Stable frontend: clients connect to a consistent load balancer, gateway, hostname, and port.

• Dynamic backend ownership: Connexion tells the frontend which application-server host or pod currently runs the inbound channel.

The client configuration remains stable while Connexion and the platform update the backend route.

End-to-End Flow

1. An inbound device starts its listener.

2. The device registers the protocol, port, and advertised endpoint it can accept.

3. Connexion includes the route only while the channel is Running and its owning application server is healthy.

4. The route publisher builds the desired active-route snapshot.

5. The configured platform provider applies that snapshot to the frontend router.

6. The frontend sends new inbound traffic to the application server currently running the channel.

Open

The routing view groups active listeners by the application server that currently owns each channel, including the protocol, port, channel path, and runtime state.

When Placement Changes

If Connexion moves the owning tab or channel group to a different application server:

1. the previous application server stops the assigned work;

2. the new application server starts the channel and its inbound listener;

3. Connexion updates the active-route owner;

4. the route publisher detects the changed snapshot; and

5. the frontend route is republished with the new backend target.

Clients continue using the same public address and port. Only the backend destination changes.

Supported Frontend Integrations

Connexion currently ships four route-publishing interfaces. These are integration mechanisms, not a limit of four frontend products.

Open

Operators select the frontend provider and configure provider-specific routing settings directly in the Router panel.

A deployment selects one route-publishing interface for its frontend path. The Gateway API row represents an ecosystem rather than a single router product: the platform team can choose a conformant controller, provided it supports the HTTPRoute and/or TCPRoute resources required by the deployed devices.

Optional Apply Command

After the selected route publisher successfully produces a changed routing configuration, Connexion can optionally run an operator-supplied executable or script. Typical uses include validating and reloading HAProxy, copying generated configuration to a router, or invoking a site-specific apply workflow.

Configure this in the Connexion Configuration Wizard under Services > Frontend Route Publisher > Apply Command. Exactly one route publisher must also be selected.

For example, a Windows installation can launch PowerShell as the executable and pass a reload script through the arguments:

Container deployments can set the same values with environment variables:

The command runs directly rather than through a shell. A non-zero exit code or timeout marks the route publication as failed; Connexion does not accept the new route fingerprint and retries during a later publication or reconciliation cycle. The setting is loaded when the Connexion service starts.

Traefik normally watches its generated configuration file directly, and Kubernetes deployments normally use the route-applier sidecar, so these deployments usually leave the Apply Command blank. The command supplements the selected publisher; it is not a separate routing integration.

AWS Network Load Balancer

For an AWS Auto Scaling Group deployment, the public Network Load Balancer remains stable while EC2 application servers are created and removed.

Connexion publishes active inbound ports to the NLB and updates the target to the EC2 host currently running the channel. When placement changes, the NLB target changes without requiring the sending system to discover a different server.

Terraform supplies the AWS router resources and identifiers; Connexion supplies the live channel-to-host routing state.

Kubernetes Gateway API

For Kubernetes deployments, Connexion can publish routes through the Kubernetes Gateway API:

• HTTP and HTTPS devices use HTTPRoute.

• TCP devices, including HL7 MLLP listeners, use TCPRoute.

• A selectorless Service and managed EndpointSlice point the route at the pod currently running the channel.

• Gateway listeners remain platform-managed infrastructure and define which inbound ports can be exposed.

TCPRoute currently requires the Gateway API experimental channel. Platform teams should ensure that every approved inbound device port has a matching Gateway listener.

When a channel moves between pods, Connexion updates the Service endpoint and route resources so the Gateway sends traffic to the new owner.

Active Routes Versus Registered Routes

A device registration describes a route that can be exposed. Connexion publishes it only when it is active.

The active-route view excludes routes whose channel is stopped, disabled, or deleted and routes whose owning application server is no longer healthy. This prevents stale device registrations from becoming live frontend routes.

Reconciliation and Visibility

Route publication uses both immediate change notifications and periodic reconciliation:

• device listener registration requests publication;

• placement changes request publication;

• graceful shutdown requests publication after work is released; and

• a periodic reconciliation loop provides a backstop.

Connexion exposes the desired and published route counts, the last successful publication, and whether unapplied routing changes remain. Operators can inspect active routes and route-publisher status through the Connexion management and health surfaces.

Operational Considerations

• Configure the stable frontend and its approved listeners before enabling route publishing.

• Ensure application servers advertise addresses reachable by the selected frontend.

• Apply network policy, firewall, TLS, and allow-list controls at the frontend.

• Monitor route-publisher health alongside application-server readiness.

• Avoid ambiguous same-port TCP routes or conflicting HTTP host/path combinations.

• Validate route movement during deployment testing, rolling upgrades, and scale-in.

Relationship to Dynamic Scaling

Dynamic routing completes the multi-active scaling model:

• Kubernetes or an Auto Scaling Group changes application-server capacity.

• Connexion moves tabs and channel groups across the active servers.

• Dynamic routing updates inbound routes to follow the new placement.

• External systems continue using stable frontend endpoints.

Related pages:

• Kubernetes: Dynamic Scaling

• Cloud Dynamic Scaling & Integration

• Multi-Active Application Servers