The Tetra HTTP Relay Agent facilitates communication between TetraScience components, such as Tetra Data Pipelines, and customers' on-premises systems—even when firewall or networking configurations block incoming network traffic from the Tetra Data Platform (TDP).

The Agent is a containerized, instrument-agnostic application designed to send HTTP and HTTPS requests on behalf of a requestor. It uses outbound network communication to receive specialized commands from the TDP, which include details about the HTTP and HTTPS requests. The Agent then relays these requests to target on-premises systems and sends the target system's response back to the TDP.

Design Overview

Systems that use the Tetra HTTP Relay Agent include four components:

• A requestor: The requestor seeks to make an HTTP or HTTPS request to a target on-premises system, but is restricted by network configuration and firewall rules inbound communication to the target system from the requestor's network. The requestor is commonly a Tetra Data Pipeline. The HTTP Relay supports large numbers of requestors.
• The customer's target system(s): The target system(s) could be an application, electronic lab notebook (ELN), laboratory information management system (LIMS), or other service whose API can handle HTTP or HTTPS requests, but has a networking configuration which makes direct access from the requestor impossible. The HTTP Relay supports large numbers of requestors.
• The Tetra HTTP Relay Agent: A containerized application deployed to a server with outbound networking access to all other components. The HTTP Relay is designed with security in mind and each agent deployment can support requests from one TDP Organization.
• The TDP Command Service: The TDP Command Service mediates communication between the Tetra HTTP Relay Agent and the requestor by using a combination of TetraScience API endpoints and Amazon Simple Queue Service (Amazon SQS) queues.

When Do You Need a Tetra HTTP Relay Agent?

The Tetra HTTP Relay Agent uses outbound network connectivity to poll the TDP Command Service for commands. After the Agent receives a command, the relay parses it. The Agent then executes the specified HTTP or HTTPS request and returns the response to the Command Service, which stores the response for the requestor.

TDP deployments that use the Tetra HTTP Relay Agent will generally include the following:

• A target system which has network connectivity and communicates through HTTP or HTTPS: For example, the target system may be a LIMS deployed to a GXP-hardened network on-premises.
• One or more requestors seek to make HTTP and/or HTTPS requests with the target system: For example, these could be TDP Pipelines that seek to fetch business-valuable metadata from the target system.
• The target system is deployed in a computer network that blocks HTTP or HTTPS requests from the requestor(s): For example, the requestor(s) may be in a different network or the public internet.
• Operational networking, IT, and security considerations prevent the requestor from sending HTTP or HTTPS requests directly to the target system: For example, the IT security team may not support inbound requests to a GxP-hardened network from dynamically assigned IP addresses outside the network.
• The HTTP Relay Agent can be deployed to a host machine that has outbound access to the TDP, AWS, and the target system(s).

The following diagram shows an example workflow where a customer is using the TDP to enrich instrument raw files by using metadata from an on-premises application, but the pipeline fails because of local networking and/or firewall rules.

The diagram shows the following workflow:

1. A raw file is uploaded to TDP.
2. The uploaded file triggers a chain of Tetra Data Pipelines to convert the raw file to IDS and enrich it with metadata from an on-premises application. For simplicity, this is represented as a single pipeline entity in the diagram. This pipeline needs to send an HTTP or HTTPS request to an on-premises application for the data.
3. A pipeline sends a HTTP or HTTPS request to the target system, which is refused due to networking and/or firewall rules.
4. The pipeline fails. Depending on the pipeline design, the expected IDS file is not generated or the file is not decorated with the expected metadata.

Architecture

The following diagram shows an example Tetra HTTP Relay Agent workflow. The Agent is deployed to a host machine inside the customer's on-premises network and has outbound network access to the TDP and the target system.

The diagram shows the following workflow:

1. A raw file is uploaded to the TDP.
2. The uploaded file triggers a chain of Tetra Data Pipelines to convert the raw file to IDS and enrich it with metadata from an on-premises application. For simplicity, this is represented as a single pipeline entity in the diagram. This pipeline needs to send an HTTP or HTTPS request to an on-premises application for the data.
3. The pipeline uses the context.run_command() method to send the HTTP or HTTPS request details as a command. The pipeline waits for the Agent to process the command.
4. The Agent polls the Command Service and receives the command. The Agent then parses the command payload and forms an HTTP or HTTPS request.
5. The Agent relays the HTTP or HTTPS request to the target system on behalf of the pipeline, and then parses the response into a format suitable to relay by command.
6. The Agent relays the HTTP or HTTPS response to the TDP Command Service.
7. After waiting for a period, the pipeline starts to poll the Command Service for a response to the command action and parses the HTTP or HTTPS response from the Command Service.
8. The pipeline enriches the Intermediate Data Schema (IDS) with additional attributes like labels, enabling further downstream analytics, processing, and integration.

Operational Guides

For installation and agent container deployment instructions, see the Tetra HTTP Relay Agent Installation Guide (v1.0.x).

For user and operational instructions, see the Tetra HTTP Relay Agent User Guide (v1.0.x).