[Status]: Cloud service api testing

[jorgenherje]

Status of Work: Cloud Service and API for ResInsight

---

This issue tracks the status and progress of prototyping and designing a cloud service which provides an API for ResInsight.

Target Services

• Sumo
• OSDU (not tested yet)

Target Data Types

• Surfaces (SUMO and OSDU)
• Well picks (OSDU)
• Polygons (SUMO)
• Fault lines (SUMO)
• Roff grid model (SUMO)

Current testing has only covered metadata and ensemble/realization detection, and so far only with SUMO (not yet with OSDU).

---

Sumo

Experience

• Developed a prototype service using Python, Uvicorn, and FastAPI to expose a REST API.
• The prototype leverages the fmu-sumo-explorer package to retrieve data/metadata from Sumo.
• This approach decouples the previously hardcoded ElasticSearch integration in ResInsight (C++) by moving it into a separate service (FastAPI).
• The current prototype has only run locally (due to environment limitations in Equinor), but the intention is to eventually deploy a non-local service for ResInsight to use.
• The main goal is to set up an interface which can remain consistent as the service transitions to a possible cloud environment.

Open Questions / Topics for Investigation

• How will authentication work in ResInsight? How to pass tokens to the backend?
• How should integration tests be established—should we use Sumo test user and/or a Drogon test case?
• Handling slow or time-consuming data retrieval (e.g., Sumo aggregation service)?

---

OSDU

OSDU data access is not yet integrated in backend.

Experience

Open Questions / Topics for Investigation

• OSDU data access in back-end service

---

Key Considerations Going Forward

• Separation of Concerns:
  • Should the router layer in the service be organized by data type or by underlying service? (Suggestion: By data type)
  • Establish access layers such as SumoAccess and OsduAccess, callable from the router layer.
  • Stabilize the router/API interface for ResInsight, especially argument and return type stability (API versioning—so ResInsight can lock to specific versions and return types as necessary).
• Service API for cloud communication
  • As of now ResInsight has both RiaSumoConnector and RiaOsduConnector. Should these remain separate, or should the back-end have a single api, and the cloud service (SUMO vs OSDU) be extracted away from ResInsight?
  • If our new service handles/controls SUMO/OSDU: Can both use same authentication?
• API Generation / Shared Types:
  • Have local service as a sub-module to auto-gen api and its data types? E.g. arguments and return types for RestAPI
• Repository Management:
  • One option is for the service to live in its own maintained repository, independent from ResInsight. Other approaches could also be considered.

---

This issue remains open as work progresses on cloud API strategies and architectural validation for ResInsight.