SAD-001: xRED ELN Application Integration Layer Architecture

1. Overview

The xRED ELN Integrations platform connects Roche’s Signals ELN (Electronic Lab Notebook), hosted by Revvity as a SaaS offering, with internal Roche data systems. Scientists working in Signals need access to reference data from internal registries, and in turn, data captured in Signals needs to flow back into Roche systems for downstream analysis and compliance.

Signals is a shared platform used across Roche Diagnostics and Pharma, serving diverse user groups across multiple IT landscapes. It is a configurable SaaS solution run by the vendor (Revvity) on their own infrastructure — it is not a runtime for hosting custom extensions or integrations.

2. Integration Mechanisms

Signals provides several built-in integration mechanisms — External List Source, External Data Sources, External Chemical Source, and External Actions — each with different characteristics, constraints, and authentication models. These mechanisms allow Signals to either pull data from external endpoints or enable users to trigger external applications from within the ELN (and potentially write back to Signals).

2.1 External Data Source (Signals calls out to get data)

These are endpoints that Signals calls on behalf of the platform to populate UI elements. The user does not leave Signals — the data appears inline.

Subtypes:

Key constraints:

• Signals sends a single Authorization header (Basic Auth) plus a client certificate. No OAuth, no bearer tokens, no custom headers. Machine-to-machine authentication between the application layer and internal expert systems is supplied only with limited request context for fine-grained PBAM.
• The External List Source is limited to a maximum of 20,000 elements.

2.2 External Actions (User leaves Signals to do something, optionally writes back)

The user clicks a button in Signals, which opens an external web application. That application can read from and write back to Signals via the API or to other systems.

Key differences from External Data Source:

2.3 Write-Back Routes

Some applications require writing data back to Signals. Two routes exist:

Route 1: MuleSoft Facade (preferred) — A facade defining common blocks of operations (e.g. “Opening experiments”). Ensures common operations run optimally, avoiding unnecessary API load. Still early; the list of operations is not exhaustive. Developed by the DataRiver group.

Route 2: Signals API Proxy — More flexible, full API access. Should be used only if no appropriate MuleSoft Facade exists. Controlled by the LEM platform team; additional access currently available to the xRED Dev team only.

3. System Architecture

3.1 Network Boundaries

The integration layer is organised across two network boundaries: the Roche Corporate Network (RCN) and the Minerva AWS environment hosted within it. Revvity Signals and MuleSoft sit outside the RCN, while all xRED integration components run inside it.

3.2 External Data Source Integration (Lookups)

This diagram shows the flow for External List Source, External Data Sources, and External Chemical Source — Signals calls out to xRED to get data. The user never leaves Signals.

Key characteristics:

• Server-to-server (no browser involved)
• Single Authorization header (Basic Auth) + client certificate — Signals platform constraint
• Adapter handles all data transformation and pagination
• Auth validated at Gravitee via Groovy policy (ADR-004)

3.3 External Actions Integration (Apps)

This diagram shows the flow for External Actions — the user leaves Signals and enters an xRED web application that can read from and write back to Signals.

Key characteristics:

• Browser-based (user redirected to xRED app)
• Dual OAuth: Roche identity (Janus) + Signals access token
• Both tokens stored in ElastiCache (ADR-003)
• Write-back via MuleSoft Facade or LEM API Proxy (ADR-005)
• Richer auth model than External Data Source — browser enables OAuth flows

3.4 Component Catalogue

Revvity Signals

The source ELN platform, operated by Revvity as SaaS outside the RCN. Signals initiates all External Data Source calls and opens External Actions in a browser. It communicates exclusively through MuleSoft as its entry point into the Roche network.

MuleSoft

The external-facing API gateway and single point of entry for all traffic between Signals and the Roche network. MuleSoft enforces the LEM team’s API governance rules, manages the tenant-wide quota of 1,000 calls per minute, and routes traffic inbound to Gravitee. It also provides the DataRiver Signals Facade operations for write-back scenarios.

Gravitee (inside RCN)

The internal API gateway between MuleSoft and the Minerva application components. Acts as the single entry point within the RCN, handling:

• Authentication validation (Basic Auth via Groovy policy scripts)
• Request routing to backend services
• Response caching
• Rate limiting at the application layer level

All traffic from MuleSoft passes through Gravitee before reaching any internal service.

Lookups (Minerva)

The middleware service responsible for serving External Data Source integrations — External List Source, External Data Sources, and External Chemical Source. When Signals needs to populate a dropdown, resolve a chemical structure, or fill a table row, it calls this service via MuleSoft → Gravitee. Lookups fetches the required data from internal systems and returns it in the JSON format Signals expects, handling all data transformation and pagination internally.

Apps (Minerva)

The application layer responsible for External Actions integrations. When a user clicks an action button in Signals and is redirected to an external web application, that application runs within this layer. Apps handle the dual OAuth flow — authenticating the user via Janus (PingFederate) and obtaining a Signals OAuth token to enable write-back to the ELN. Apps can interact with internal systems and write results back into Signals via the MuleSoft Facade or the LEM API Gateway.

ElastiCache (Minerva)

An AWS ElastiCache instance used as a distributed session store by the Apps layer. It holds two short-lived OAuth tokens per user session:

• Signals access token — for write-back calls to the ELN
• Roche identity token — for calls to internal systems via Janus

The primary architectural motivation is horizontal scalability and resilience. By externalising session state to a shared store, the Apps layer can run multiple replicas without sticky sessions — any pod can serve any request. This is a deliberate trade-off against the alternative approach of in-memory session storage, which would limit the application to a single replica and introduce a single point of failure.

See ADR-003 for the trade-off analysis.

Janus / PingFederate (RCN)

The Roche identity and authentication service. Janus handles OAuth flows for External Actions — when a user enters an xRED application, Janus authenticates their Roche identity and issues the tokens required to access internal systems.

Internal Systems

Representative internal Roche systems within the RCN (e.g. compound registries, sample management systems, analytical data stores).

• Internal System 1 — accessed by Lookups and External Actions for reference data retrieval
• Internal System 2 — accessed by Apps via OAuth through Janus, typically for write or transactional operations triggered by External Actions

4. Data Flows

4.1 External Data Source Flow (Lookups)

There are two data source patterns:

External List Source (scheduled pull): Signals pulls dropdown data from the Lookups service on a configured schedule (hourly or daily). The data is snapshot-based — Signals refreshes its local copy periodically, not on every user interaction.

External Data Source and External Chemical Source (real-time): When a scientist interacts with a table cell or chemical structure field, Signals calls out to the Lookups service in real-time. The user never leaves Signals — the data appears inline.

Both patterns follow the same network path via MuleSoft and Gravitee. Authentication is limited to a single Basic Auth header and a client certificate — all credential translation is handled internally by the integration layer.

4.2 External Actions Flow (Apps)

When a scientist triggers an External Action in Signals — for example, launching a calculation or submitting a request — the browser redirects them to an external application hosted in the Apps layer. The application performs a dual OAuth handshake: first authenticating the user’s Roche identity via Janus (PingFederate), then obtaining a Signals OAuth token to enable write-back into the ELN. Both tokens are stored in ElastiCache for the duration of the session. When the application needs to call an internal Roche system, it retrieves the Roche token from ElastiCache and uses it as a Bearer token. When it needs to write results back into Signals, it retrieves the Signals token from ElastiCache and routes the write-back through MuleSoft.

5. Infrastructure

6. Constraints and Boundaries

API Quota

The tenant-wide Signals API quota is 1,000 calls per minute, shared across all consumers. The MuleSoft layer enforces rate limiting to protect this quota.

Authentication Limitations

External Data Source integrations (External List Source, External Data Sources, External Chemical Source) support only a single Authorization header (Basic Auth) plus a client certificate. No OAuth, no bearer tokens, no custom headers. This is a hard constraint imposed by the Signals platform.

External List Source Limits

• Maximum 20,000 elements per list
• Maximum 200 lists per tenant
• 30-second response timeout

External Data Source and Chemical Source Limits

• 20-second response timeout
• External Data Source: max 20 columns, 2,000 rows per table

DataRiver Facade Rate Limit

The MuleSoft facade enforces 300 calls per hour per client application. This is separate from and more restrictive than the tenant-wide Signals quota.

Network Boundary

Internal Roche systems sit within the RCN and are not directly accessible from Revvity’s infrastructure. All traffic must traverse MuleSoft → Gravitee.

API Governance

The LEM team’s strong expectation is that all programmatic access to and from the Signals platform within the RDT DIA R&D domain should be routed through the DataRiver Signals Facade on MuleSoft. See ADR-005 for details on the two access routes.

7. Repositories

8. Glossary