Case 05 API integration · Visual diagnostics
DPMS and Equinor: API integration with visual diagnostics
I took full technical responsibility for the backend integration between DPMS and Equinor’s ISO Work Details API, from understanding contracts and business rules to submission and read-back verification. I also built the entire jobs-viewer interface to follow execution reports and visually debug each record’s path between the systems.
Context
The previous workflow relied on an Excel workbook. Direct integration required understanding how DPMS requests, scopes and services relate to Equinor work orders, specifications and items.
The work took place within the DPMS context through Oxeanbits. Individual authorship here refers to the integration and jobs-viewer, rather than the platforms they connect.
Problem
Copying fields between endpoints was insufficient. Different contracts, catalogues, phases and business rules had to be reconciled while preserving references back to source records.
A successful HTTP response alone does not explain what was included, what was left out or why returned values differ. Investigation needed to reveal the data’s path and the reasons behind each status.
My responsibility
I was responsible for all technical aspects of the integration backend, from technical decisions to implementation and flow verification.
I studied the API contracts and the previous Excel workflow, defined mappings and implemented authentication, retrieval, transformation, submission and read-back verification.
I built the entire jobs-viewer interface, including execution summaries, a source-to-target graph, status legends and details for investigating records and failures.
The interface queries the APIs to inspect graph nodes and displays HTTP statuses, response bodies and value discrepancies. Job reports remain stored and authorized by DPMS.
Decision
Preserve deterministic references linking specifications and items to DPMS records rather than losing identity during data transformation.
Make read-back part of verification and turn execution reports into a readable graph with explicit statuses and reasons.
Alternatives and trade-offs
Present-day analysis written for this site. It is not a record of the alternatives evaluated at the time.
- Stable references support reconciliation, but do not make every operation idempotent: a POST that appends specifications still requires care when resubmitting.
- The graph was designed around this integration’s source-to-target contract. That constraint keeps it simple and useful for investigation without requiring a generic graph engine.
Implementation
Integration and diagnostics were developed together to make the flow traceable.
Contracts and mapping
Reconciliation of data models, catalogues and rules, preserving source references in submitted items.
System communication
API authentication, data transformation and specification submission, followed by read-back verification.
Reports and graph
Execution summaries and connections between requests, scopes, services and their Equinor counterparts. Statuses distinguish included, excluded, blocked and orphan records.
Visual investigation
API record inspection, HTTP responses and differences between DPMS and Equinor values. The interface uses HTML, CSS and SVG, without JavaScript in the viewer.
Visualization
Outcome
The discovery repository records a validated test-environment cycle: insulation estimate submission, read-back of the created specifications and verified cleanup of test references.
The jobs-viewer turns job reports into a navigable view of the flow, with context for investigating failures and discrepancies. This evidence does not validate every scenario or confirm a production rollout.