ADR-005: Two Routes for Signals API Access — DataRiver Facade vs LEM API Proxy

Context

When an xRED integration needs to write data back into Signals (or read from it programmatically), the call must traverse the Roche network boundary. The LEM platform team — which governs all programmatic access to the Signals tenant — provides two distinct routes for this. Choosing the wrong route, or bypassing both, violates the LEM integration rules and risks losing API access.

The Signals tenant has a hard rate limit of 1,000 API calls per minute shared across all consumers. Both routes exist in part to manage this shared quota.

Decision

xRED ELN integrations use the two LEM-governed routes in the following priority order:

Route 1: DataRiver Signals Facade (preferred)

A curated set of high-level API operations exposed through MuleSoft by the DataRiver group. Each facade operation encapsulates one or more raw Signals API calls into a single, optimised transaction.

When to use:

• A facade operation exists for the workflow (e.g. opening experiments, updating worksheets)
• The operation is a common pattern shared across multiple consumers
• You want the DataRiver team to manage the API call optimisation

Characteristics:

• Operations are pre-defined and maintained by the DataRiver group
• Each facade operation is an abstraction over one or more Signals API calls
• DataRiver handles rate limiting, retries, and call optimisation internally
• New facade operations can be requested but require DataRiver development time
• The list of available operations is not yet exhaustive

Route 2: LEM Signals API Proxy (fallback)

Direct access to the full Signals REST API, proxied through a gateway controlled by the LEM platform team. This gives full flexibility but bypasses the facade’s optimisation layer.

When to use:

• No appropriate DataRiver Facade operation exists for the use case
• The integration requires fine-grained control over individual API calls
• During development/exploration on DEV environments (with LEM approval)

Characteristics:

• Full Signals API surface — any endpoint, any method
• Proxied 1:1 (no optimisation, no batching)
• Controlled by the LEM platform team — access must be explicitly granted
• Currently available to the xRED Dev team as an additional access route
• The caller is responsible for managing API call volume and rate limiting

Rationale

Why not direct Signals API access?

The LEM team’s strong expectation is that all programmatic access to Signals within the RDT DIA R&D domain should be routed through the DataRiver Signals Facade on MuleSoft. While not technically enforced at the infrastructure level, bypassing this would face significant governance friction and is unlikely to pass the LEM review process. The reasons:

• Visibility: DataRiver provides centralised analytics on API usage across all consumers
• Rate management: The 1,000 calls/min quota is tenant-wide; unmanaged direct access risks exhausting it for everyone
• Optimisation: The facade prevents the “reinvent the wheel” problem — common operations are implemented once and optimised centrally
• Evolution: LEM and DataRiver can evolve the platform internally behind the facade without breaking consumers

Why two routes instead of one?

The DataRiver Facade is still early — the list of operations is not exhaustive. Some xRED use cases require API calls that no facade operation covers yet. Rather than block development, the LEM team provides the API Proxy as a controlled escape hatch.

The expectation is that Proxy usage informs future Facade development. When xRED discovers a pattern worth abstracting (e.g. a sequence of 5 API calls that always go together), that pattern should be proposed to DataRiver as a new facade operation.

Gap handling process

Per the LEM team’s offerings document: if there are identified gaps in the DataRiver Signals Facade, 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.

Consequences

• xRED must check whether a DataRiver Facade operation exists before using the API Proxy
• New integrations requiring write-back must document which route they use and why
• API Proxy usage should be tracked and periodically reviewed for facade promotion
• The xRED team must comply with the LEM delivery checklist for either route (see LEM Platform Requirements)
• Facade operations may change or be deprecated by DataRiver — xRED must track DataRiver release communications
• Rate limiting responsibility shifts depending on route: DataRiver manages it for Facade calls; xRED manages it for Proxy calls