Using TDP to Communicate Bi-Directionally



Bi-Directionality is disabled by default. You'll need to enable it for it to work.

Starting with version 3.0 of the software, TDP supports bi-directional command requests for agents and the generic connector. This topic provides an overview of this functionality.


Prior to version 3.0 of the software, TDP only supported “On-Prem Pull,” using Tetra Agents and Connectors. Tetra Agents, which are installed and configured on the customer’s premises, pulled a copy of data from a system, via the connectors, then sent the data to the Tetra Data Lake where our Tetra Pipelines could harmonize them to produce an IDS formatted file. This file could then be sent to a LIMS, ELN, a pub-sub system like Solace, or analyzed/further processed using another means.

Bi-Directionality adds functionality that is much like “On-Prem Push”, but that is accomplished when the client initiates the pull request using a command from a specified subset of commands that they download from the platform. Bi-Directionality is accomplished primarily using the GDC connector. This can streamline operations and improve efficiency.


To make this feature more secure, we've implemented several things.

  • The feature must be enabled to work. Enablement must occur in both the Agent and the TDP. You must have other pieces of information as well, such as the Agent ID. Enablement occurs on an agent-by-agent basis.
  • You cannot use this feature to send an arbitrary command or request; requests are limited to those that have been specified and differ by agent type.
  • You cannot use this feature to download a file that is not already in the data lake.
  • The enablement of this feature, as well as other actions that occur - such as commands run - are recorded in the audit trail.
  • When running in the context of a workflow execution, the SDK creates commands via an internal API that is not accessible externally. The call is scoped to the workflow organizational slug.
  • The AWS credential and configuration are fetched dynamically before polling AWS SQS. The information is not logged as plain text in the log file, nor is it stored in the database.

Additional Details

See the following topics for more details on this feature, as it relates to this scenario.

Other Documentation: