Bi-Directional Functionality Overview

📘

Disabled by Default

Bi-Directionality is disabled by default. Before you can use it, you must first enable it.

As of Tetra Data Platform (TDP) version 3.0, TDP supports bi-directional command requests for Tetra Agents and the GDC connector.

  • Before TDP version 3.0: TDP only supported on-premise 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 through the connectors, and then sent the data to the Tetra Data Lake where the Tetra Pipelines could harmonize them to produce an IDS formatted file. Customers could then send this file to a LIMS, ELN, a pub-sub system like Solace, or to analyze and perform additional processing using another means.

  • As of TDP version 3.0: Bi-Directionality adds functionality that is similar to on-premise push. However, it is occurs when the client initiates the pull request using a command from a specified subset of commands which they download from the TDP. Bi-Directionality is accomplished using the GDC connector which streamlines operations and improves efficiency.

Security

To make the Bi-Directionality functionality secure, TetraScience has implemented the following:

  • You must enable the feature in both the Agent and the TDP for it to work. Additionally, you must have other information, 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 and 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 through 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.

For more details on this functionality and its related features, review:

Other Documentation:


Did this page help you?