Research: Signals Python SDK and Autolab Action Blocks

1. Ownership and Responsibility

Both the SDK and the AAB are maintained by the LabEx team. xRED Dev uses them as consumers.

2. Signals Python SDK

What it is

An auto-generated Python API client for the MuleSoft “Experiments API” (dia-rnd-experiments-exp, v2.6.3). It wraps the DataRiver Facade — not the Signals API directly. This is the officially supported path per LEM governance (ADR-005).

AutoLab / xRED App → signals-python-sdk → MuleSoft (DataRiver) → Signals ELN

Code generation pipeline

The SDK is fully auto-generated:

1. Source: Swagger 2.0 spec from MuleSoft (api.json)
2. Convert: Swagger 2.0 → OpenAPI 3.0 via api-spec-converter
3. Patch: OpenAPI Overlay applied via oas-patch to fix MuleSoft spec issues (zero-width characters, wrong data types, misnamed schemas)
4. Generate: openapi-generator-cli v7.15.0 with python-pydantic-v1 generator
5. Publish: to Roche Artifactory

Installation

# From Roche Artifactory (RCN required)
pip install signals-python-sdk --index-url https://repository-ng.intranet.roche.com/artifactory/api/pypi/pypi-local/simple
 
# Or from Git
pip install git+https://code.roche.com/labex/sdk/signals-python-sdk.git

Dependencies: Python 3.8+, urllib3, python-dateutil, pydantic >=1.10.5,<2 (Pydantic v1 only), aenum.

Authentication

MuleSoft client credentials (Basic Auth) + mTLS client certificate:

import signals_python_sdk
 
configuration = signals_python_sdk.Configuration(
    host="https://dev-de-c1.apis.roche.com:443/dia-rnd-experiments-exp-dev/v2",
    username=os.environ["MULESOFT_CLIENT_ID"],
    password=os.environ["MULESOFT_CLIENT_SECRET"],
)
configuration.cert_file = "/path/to/cert.pem"

2FA with client certificate is required per the API’s non-functional requirements.

AutoLab ↔ Signals environment mapping

See retina.roche.com/cb/issue/6763835  for the canonical reference.

Decommissioned: The QA → TEST connection (test-de-c1.apis.roche.com/.../dia-rnd-experiments-exp-test/v2/) has been removed. QA now connects to Template Lab via the STAGE MuleSoft endpoint.

Available operations (27 methods)

All methods live on a single DefaultApi class:

Experiments:

Files/Attachments:

Tables:

Metadata (External File Links):

Other:

Non-functional requirements

Known issues and limitations

• Pydantic v1 only — the generator uses python-pydantic-v1 template; Pydantic v2 is not supported yet
• Awkward method names — auto-generated names like get_detailed_data_for_given_experiment_ are hard to work with
• MuleSoft spec quality — the overlay patch fixes zero-width Unicode characters, wrong data types (file → string/byte), and misnamed schemas generated by MuleSoft
• No examples or integration tests — only auto-generated test stubs
• 300 calls/hour rate limit — this is the MuleSoft layer’s own limit, separate from the 1,000/min Signals tenant quota

3. Experiment Templates

Analysis performed via GET /experiments/templates/templateId against the DEV instance (AAB-1919 ).

Supported by current SDK (9 of 12)

Not supported by current SDK (3 of 12)

These require fields that the MuleSoft create_experiment endpoint does not expose. Supporting them would require extending the MuleSoft Experiments API spec and regenerating the SDK — this is a DataRiver gap to raise with the LEM team.

Template replication to xRED DIA tenant

These templates exist on the pRED/gRED Signals tenants. The xRED DIA tenant needs exact replicas of the same templates so that the SDK and AAB work without modification.

Action required: Request LEM to replicate all 9 supported templates into the DIA tenant, preserving exact field definitions (name, type, required/optional, allowed values).

Process:

1. Export full template definitions from pRED DEV using GET /experiments/templates/templateId (Excel sheet uploaded to AAB-1919)
2. Provide definitions to LEM team
3. LEM creates templates in DIA tenant via Signals Admin
4. Verify template IDs accessible via templates_search on DIA tenant
5. Confirm create_experiment works for each template

Note: Template IDs are environment-specific UUIDs — the DIA tenant will have different IDs. The SDK and AAB resolve templates by name, not hardcoded ID.

4. AAB Signals (Autolab Action Block)

What is AAB?

The AutoLab Action Blocks framework is a modular system for building workflow components on the Roche AutoLab platform. Each AAB is a Python package implementing service tasks composed into BPMN workflows orchestrated by Camunda. The autolab_action_blocks group contains 35+ AABs covering Signals, EWB, Chromeleon, Genedata, Arvados, IRCI, TaPIR, and more.

Current operations

Not yet implemented (SDK supports but AAB does not use): table operations, row management, search, external file links, attachment downloads, worksheet access.

Architecture

Authentication (two layers)

Operational note: The MuleSoft client certificates are stored in the AutoLab Vault, not in a Vault we control. When certs need rotation, we must ask the AutoLab platform team to update them. This is a dependency to track.

AutoLab ↔ Signals environment mapping

AutoLab instances map to specific Signals environments. The full mapping is maintained in the AutoLab configuration (AutoLab ↔ Signals Env Mappings and Configs).

Write-back patterns

1. MuleSoft-mediated only — all API calls go through MuleSoft with mTLS + client credentials. No direct Signals API access.
2. Base64 file upload — files read from MinIO, base64-encoded in memory, uploaded in a single POST. Max 10 files per call (payload size concern).
3. User token pass-through — user’s Signals token obtained from Token Manager and passed on every call. Operations happen in the user’s context.
4. Template-based creation — experiments created from predefined templates, not freeform. Currently hardcoded to "pRED In-Vitro" and "pRED In-Vivo" only.
5. Close without signing — digital signature workflows are not handled.
6. No structured data writing — AAB only does file attachments, not table row writes.

Known issues

• Only 2 templates hardcoded — signals_create_experiment only accepts "pRED In-Vitro" and "pRED In-Vivo" via TemplateNameLiteral. The 7 other supported templates need to be added.
• Cert rotation dependency — MuleSoft client certificates are in AutoLab Vault; we cannot self-service rotate them.
• Python 3.9 lock — AAB is locked to >=3.9.0,<3.10, while the SDK supports 3.8+.
• SDK version lag — AAB pins signals-python-sdk==0.2.0 while SDK is at v0.3.0.
• No table write operations — the SDK supports table CRUD but AAB doesn’t use it yet.

5. Operational Dependencies

6. Next Steps