Research: ORCA Platform (LEM Team)

1. What is ORCA?

ORCA (team name “Lemmings”, group xPET = cross-Pharma ELN Team) is the LEM (Lab Experiment Management) platform team’s integration platform. It builds custom services bridging Revvity Signals ELN with internal Roche data systems — the same problem space as xRED ELN, but from the platform team’s side.

ORCA and xRED ELN share the same Signals platform, the same MuleSoft/DataRiver gateway, and the same integration mechanisms (External Lists, External Tables, External Actions). The key difference is organisational scope and infrastructure:

2. Architecture Overview

ORCA follows a hub-and-spoke adapter pattern:

3. Service Catalogue

3.1 External List Adapters (Dropdowns)

These serve Signals “External Lists” — dropdown data that Signals polls periodically.

Key pattern — SQLite as transform engine: Adapters load external API data into in-memory SQLite, then use SQL queries (supplied via K8s ConfigMaps) to transform into Signals-compatible JSON. Lightweight ETL without a dedicated data pipeline.

A shared Docker image (signals-external-list-adapter) provides the runtime; each adapter is configured per-instance via environment variables and ConfigMaps. The external-list-template repo provides scaffolding for new adapters.

An NGINX API gateway (api-gateway repo) routes requests based on the ?list= query parameter to the correct K8s service.

3.2 External Data Source Services (Table Lookups)

These validate IDs typed into Signals table cells and return metadata.

Generation 2 (simple lookups)

Pattern: Single GET /v1/{source}/{id} endpoint returning a flat JSON object. No pagination. Uses Spring Cloud OpenFeign for upstream calls. Returns markdownLink fields for clickable links in Signals.

Generation 3 (advanced lookups)

Pattern: More sophisticated — rcdb-lookup and irci-lookup depend on signals-user-lookup to resolve email addresses to unix IDs. Two-phase search+retrieve pattern for RCDB. Admin test IDs for Signals Admin panel validation without real data access.

Unified Python Service (newest approach)

Pattern: Python/FastAPI with dynamic router discovery (discover_and_include_routers). Modular client architecture with base_client.py. RBAC evaluation — calls User Lookup to determine user’s group/role, returns FULL/LIMITED/DENIED responses. Rate limited at 1000 req/min per IP. This is now the standard for all new external data integrations.

3.3 External Actions (Interactive Web Apps)

Signals-FISH Integration is a modular monolith — rather than building separate apps per integration, ORCA chose to extend a single web app (ADR 0021, 0024). It handles:

• FISH study metadata import via GraphQL against FISH MDS
• IRCI registration and read operations
• MAX/SMR and SMART analytical requests
• LEAP bulk updates

Dual authentication: Roche SSO (PingFederate) for user identity + Signals OAuth2 for API access. Tokens stored in encrypted cookies (not ElastiCache like xRED).

Signals Gateway (signals-gateway repo) provides a JWE token broker — encrypts OAuth2 access tokens with RSA (RSA-OAEP-256 + A256GCM) so they can be safely passed in browser URLs. The client holds the RSA private key for decryption. Stateless, self-contained pattern.

3.4 Background Services

3.5 Integration Shell (Template)

The signals-integrations-shell repo is a clean fork of signals-fish-integration with business logic as an example. It is the official template for bootstrapping new External Action integrations — same multi-module Maven structure (backend, frontend, bundle, blackbox-tests), same dual-auth pattern, same WireMock test setup.

4. Infrastructure

Docker Image Hierarchy

alpine:3.21
  └── orca-base (Roche CA certs, libc6-compat, non-root user)
        ├── java-21 (custom JRE via jlink, minimal modules)
        │     ├── java-21-jdk (full JDK)
        │     │     └── maven-java-21 (Maven 3.9.8)
        │     └── java-25 (newer JRE)
        │           └── maven-java-25
        ├── python3_pandas (Python + pandas + FastAPI)
        └── glab-release (glab + vault CLI)

Environment Map

CI/CD (GitLab CI)

Centralised pipeline templates in base-pipelines repo:

• java-k8s-base.yml — full Java service pipeline (build → package → verify → deploy)
• release-base.yml — release management (Docker retag, git tag, GitLab release)
• K8s cluster: rancher.emea.roche.com (Rancher-managed CaaS, EMEA)
• Vault auth: GitLab JWT tokens with aud: https://code.roche.com
• Deploy image: benchling/devops/k8s-deploy-image
• Container registry: registry.code.roche.com

Vault Bootstrap

The vault-bootstrap repo automates Vault role creation for new GitLab projects — creates JWT auth roles bound by project_id with gitlab-jwt policy. Run manually via CI pipelines.

5. Architecture Decisions (from ORCA’s ADRs)

ORCA maintains formal ADRs in Y-statement format in their architecture repo. Key decisions relevant to xRED ELN:

6. Patterns Worth Adopting

Already in use by xRED (validated by ORCA’s parallel adoption)

• FastAPI for data source adapters — ORCA’s signals-external-sources confirms this is the right direction
• Vault for secrets — same approach, different namespaces
• MuleSoft as external gateway — mandatory per LEM governance

Worth considering for xRED

Differences to be aware of

7. Key Repositories Reference

Core Services

Lookup Services

Infrastructure and Templates

Background / ETL

8. Collaboration Notes

The offerings repo contains a branch feature/initial-updates-for-collaboration-with-xRED-vertical, indicating active collaboration planning between ORCA and xRED teams. The offerings repo also documents the Integration Design Questionnaire (user view, system view, data view) which could be useful for standardising how xRED documents new integration requirements.

Contact for the ORCA/LEM platform team integration requests can be routed through the DataRiver group or the LEM team directly.