Research: DataRiver Signals Facade (MuleSoft)

1. What Is the DataRiver Signals Facade?

DataRiver is a Roche integration group that builds and operates API facades on MuleSoft’s Anypoint platform for the Signals ELN. The facade is the mandatory gateway through which all programmatic API communication to Signals should be routed (ADR-005).

The primary API is dia-rnd-experiments-exp (Experiments API, currently v2.6.3).

2. Available Operations (22 use cases)

Experiments

Files (Attachments)

Tables (v2)

Metadata (External File Links)

Templates

3. What Is NOT in the Facade

The facade covers a subset of the native Signals REST API. Notable gaps:

For operations not covered by the facade, the LEM API Proxy (Route 2 in ADR-005) provides direct Signals API access — but requires LEM approval.

4. Environments

See Signals Python SDK — AutoLab environment mapping for the full AutoLab-to-Signals mapping.

5. Authentication

Dual-layer authentication:

The MuleSoft client credentials and certificate are typically stored in AutoLab’s Vault (for AAB consumers) or in the consuming application’s secret store.

6. Rate Limits and SLA

The 300 calls/hour MuleSoft limit is per client application. The 1,000 calls/min is tenant-wide across all consumers (xRED, ORCA, LEM, etc.).

7. API Contract Requirements

There is no single formal API contract template. Instead, the LEM team requires a combination of artifacts before granting access to the DataRiver facade:

Integration Design Questionnaire

Must be completed before implementation begins. Covers three views:

User view: Personas, user journeys, expected daily/peak user counts, success metrics.

System view: All systems involved, integration ports (APIs, message streams), how ports are secured, protocols, network accessibility (RCN only?), user context handling, key limits, test scenarios.

Data view: Data objects involved, expected flows with provider/consumer/direction, flow type (sync/async/batch), frequency, connection method, source of truth per field, data governance, data classification (C1-C4).

See LEM Platform Requirements — Integration Design Questionnaire for the full questionnaire.

Delivery Checklist (mandatory for all integration types)

12 deliverables required before go-live — documented requirements, test report, verification procedure, ops plan, TOP, SRA, credential management, change management. See LEM Platform Requirements — Delivery Checklist.

OpenAPI Specification

The ORCA architecture repo (code.roche.com/orca/architecture, /api-contracts/) contains example API contracts in OpenAPI 3.x format:

• arvados-lookup-contract.json — source lookup table API
• histlims-api-contract.json — HITSLIMS project lookup
• signals-reference-presenter-service.yaml — Signals references API

These serve as templates for what an API contract looks like:

• Info block with title, description, contact
• Functional and non-functional requirements in the description
• Path definitions with typed parameters
• Response schemas with all fields
• Standard HTTP error responses (400, 403, 404, 500, 503)
• Security scheme (SSL client cert + client ID/secret or Ms-Client-Id header)

Interface Summary Table (part of the SAD)

For each integration, the SAD must include an Interface Summary Table:

8. Onboarding Process for Facade Access

1. Fill out the Integration Design Questionnaire (user/system/data views)
2. Joint assessment with LEM team on integration design and ownership
3. Engage DataRiver — mandatory for public APIs or multi-system orchestration
4. Client ID registration on the Signals tenant for your application
5. MuleSoft application creation — via Proxify tool or DataRiver team
6. Security setup — SSL client certificates, Basic Auth, or OAuth2 client credentials
7. Fulfill the Delivery Checklist before go-live
8. Deployment — requires approvals from Service Owner, Application Support Manager, and Validation Lead (up to 6 working days for non-dev environments)

Requesting new facade operations

From the LEM offerings document:

If there are identified gaps in the current DataRiver Signals API offering, the LEM team may, on a case-by-case basis, onboard developers for direct exploration of the native Signals API on a DEV environment. The purpose is to identify necessary endpoints and propose additions to the DataRiver offering.

DataRiver involvement is mandatory for integration use cases involving orchestration of more than two systems, or if the integration is intended to be a reusable public API within the SnR domain.

9. Future Vision

The lem-signals-platform documentation describes a planned expansion beyond the current experiments-only facade:

• Cache layer — reduce load on Signals for frequently accessed data
• Data lake — store Signals data for analytics and reporting
• Event streams — publish Signals events for downstream consumers
• SQL API — query Signals data via SQL interface
• Exporter — bulk data export capabilities

This would significantly expand the DataRiver offering from a simple API proxy to a full data platform around Signals.

10. Relevance to xRED ELN

What xRED can do today through the facade

• Create experiments from templates
• Attach files to experiments
• Read/write table rows
• Search experiments
• Close experiments (without signing)

What xRED cannot do through the facade

• Sign experiments programmatically
• Update experiment metadata properties directly
• Manage users or groups
• Subscribe to notifications/events
• Perform bulk operations beyond table batch reads

Key constraint: 300 calls/hour

The MuleSoft rate limit of 300 calls/hour is very restrictive for interactive applications. A scientist actively working in an External Action that reads and writes back to Signals could exhaust this budget quickly. This reinforces the need for caching (ADR-009).