Introduction

Welcome to the Revvity Signals Developer Guide. Signals is an electronic data capture and management application built with a microservice cloud architecture, designed to be resilient, scalable, and frequently updated as a SaaS application with minimal risk and interruption to end-users.

This documentation will guide you through the principles, concepts, and key components of extending the power of Signals. 
 

General Principles

Simple should be simple: Simple and common use cases involving well-defined APIs should be straightforward to implement

Supportability: Integrations, regardless of their complexity, should not impede the supportability of the application

Don’t mess with what isn’t broken: Existing systems should not require major updates to address specific integration use cases

Future vision: Integration capabilities are critical to a transformative future: automatic data capture, data pipelining, and more

Adherence to standards: Experienced developers should find familiarity with the technology, thus lowering the barrier to implementation.

 

Core Components

This document describes the key components for Signals integration:

REST APIs: Client applications can call into Signals with RESTful APIs designed with the JSON:API specification

External Actions: Signals, as a client, calls into external applications triggered through configurable UI actions added to Signals.

External Notifications: Applications can subscribe to Signals events, triggering subsequent workflows

External Lists and Data Sources: Signals allows for externally hosted data to act as list items for UI elements within Signals and to act as data sources for tables within Signals.

 

Core Concepts

Entities

In Signals Notebook, nearly everything you interact with is an Entity, ranging from top-level Notebooks and Experiments down to individual text elements. Entities are identified by unique identifiers referred to as "Entity ID", "eid", or simply "id". These IDs are crucial for identifying specific entities when interacting with Signals through integrations.

Example of an Entity ID for an experiment: experiment:03ae2d17-e94d-466a-ba83-94d89a3cea2f
 

Examples of Common Entities and their internal types:

 

Determining an Entities ID:

The primary method for identifying an entity id is via The REST APIs which will return entities and their Entity IDs in their responses as appropriate for the API call.

This is typically found in the data object returned in the API JSON response as the key:value pair id:{entity_id}. More details on the API response breakdown can be found here.

System Configuration

Signals provides administrators of tenants access to large set of configurations for their usage of Signals. Features described throughout this document rely on access to this configuration for setup and management of integrations.

Administrators can access these configuration settings via their tenants URL.

System Configuration Guide

Signals provides administrators documentation for configuring their Signals tenant in the System Configuration Guide. The system configuration guide is accessed via the drop down menu in System Configuration.

This documentation contains the details for the basic setup of External Actions, External Notifications, and External Data Sources. Setting up of these integration points requires administrator access to your tenant.

External Servers

What is an External Server?

An external server serves as a hosted application server that facilitates seamless communication between your disparate systems or services. In the context of Signals, it acts as a bridge between our APIs and integration components to your existing software applications or tools. This layer abstracts away the complexities of direct API interactions between each distinct piece of software you want to interact with Signals and provides a standardized interface for data exchange and functionality extension.
 

Significance of External Servers

By utilizing External Servers hosted by your company, developers can harness the full potential of our APIs and other integration components to enhance the functionality of their applications or tools. Here's how you can leverage external server layers effectively:

API Integration: Utilize Signals' flexible API endpoints to seamlessly exchange data with your external server(s) and further downstream into your digital lab. For example, integrate with a CRM system to synchronize your data across systems or integrate with an external weather API to capture weather conditions during an experiment.

Notifications: Configure External Notifications in Signals to send real-time notifications to external servers and trigger automated actions. For instance, receive alerts for Experiment creation and create a record of it in an external data lake.

Middleware Integrations: Implement middleware solutions to orchestrate complex integration scenarios involving Signals and multiple external servers. For example, use a message broker to route data between Signals and various backend systems while ensuring reliability and scalability.

Data Transformation and Mapping: External Servers can act as integrations layers that handle data transformation and mapping tasks, ensuring compatibility between your application's data format and Signals data formats. Data coming from Signals that needs to be transformed into a format for an external service or data being sent to Signals that needs to be transformed into a format Signals is expecting/requires.

Authentication and Authorization: Implement authentication and authorization mechanisms within the integration layer to secure access to our APIs as well as your company's data and applications. This ensures that only authorized users or applications can interact with sensitive data or perform privileged operations.

External Servers play a crucial role in enabling seamless integration with Signals, empowering developers to create innovative yet simple solutions for their unique needs. By leveraging external servers effectively, you can extend the power of Signals to enhance the functionality, maintain data integrity, and add additional value to your company's digital landscape.

 

Architectural Pattern Overview

For users wanting to make the most out of their integrations with Signals they will make use of all of Signals points of integration as described in this document often in conjunction with one another.

Below is a high level architectural diagram of a system making full use of Signals core integration points.

There are many ways to achieve success with integrations and the above is a simplified representation of the core components.

In the diagram some basic examples of each of your distinct tooling may be as follows:

External List Source: A regularly updated external list of project codes used as meta data inside of signals. 

External Data Source: A regularly updated external data source of lab instruments, their last calibration date, the model, and a location used as table data inside of signals. 

External Hosted Websites: An external site you host for registering samples in their LIMS system which acts as the intermediary between Signals and the LIMS.

External Notification Handler: An external server setup to receive Signals events that subsequently kicks off an automated archival process whenever an experiment is closed.