Generated page. Written from IdaMilk/Jumo_Service at commit 365fe44 on 2026-07-28. The database server name is redacted per the wiki's redaction policy.
Jumo Service (PLMS Proxy)
What is it?
A read-only HTTP/JSON API over the Tetra Pak PLMS Centre database, so plant-network processes can pull packaging-line data without touching SQL Server directly.
The repository is named Jumo_Service; the package and README call it plms-proxy. The latter describes it better.
Purpose
PLMS Centre is Tetra Pak's line-monitoring system, holding production counts, machine events and process values for the packaging lines. Its data is valuable to anything reporting on line performance — but handing out SQL credentials to a vendor database is a poor way to share it.
This service is the controlled alternative: one read-only door, with the schema's quirks handled once rather than in every consumer.
How it Works
Fastify with mssql, and those are the only two dependencies — a deliberate choice, both being pure JavaScript so the artefact deploys unchanged to an air-gapped Windows server with no native module compilation.
Read-only is enforced in three independent layers rather than trusted to convention:
- A read-only SQL login
ApplicationIntent=ReadOnlyon the connection- A database layer that refuses any non-
SELECTstatement
Every query is parameterised. There is no authentication — the service is reachable only from the plant network, which the README states as the explicit trade-off.
Responses use a consistent envelope (src/lib/envelope.js), parameters are validated centrally (src/lib/params.js), and freshness data is cached for 60 seconds (src/lib/cache.js) to avoid hammering the vendor database.
API
| Endpoint | Purpose |
|---|---|
GET /health | Liveness, no database call |
GET /health/db | Database connectivity |
GET /api/v1/freshness | Data currency per table, with realtimeHealthy / historicalCurrent flags (cached 60 s) |
GET /api/v1/import-status | Historical import status per line, with anyStalled / allStalled |
GET /api/v1/production/daily | Daily package counts per line |
GET /api/v1/events | Historical events, resolved to human-readable text |
GET /api/v1/process | Historical process values |
GET /api/v1/rt/events | Live events, rolling buffer, newest first |
GET /api/v1/rt/process | Live process values |
GET /api/v1/event-codes | Event-code dictionary |
GET /api/v1/lines | Line identifiers |
from and to are YYYY-MM-DD and required on historical endpoints — an unbounded query against this dataset would be expensive, so the API refuses to allow one.
The freshness and import-status endpoints deserve attention: PLMS data can silently stop importing, and a report built on stale data looks fine while being wrong. Exposing realtimeHealthy, historicalCurrent and anyStalled lets consumers detect that rather than trusting what they read.
Tech Stack
| Technology | Version | Purpose |
|---|---|---|
| Fastify | ^5.3.2 | HTTP framework |
| mssql | ^11.0.1 | SQL Server driver |
Two dependencies total. Development uses Docker Compose with a seeded schema (dev/sql/) so the vendor database is not needed locally.
Interfaces
| System | Direction | Purpose |
|---|---|---|
| PLMS Centre database | inbound (read-only) | Production counts, events, process values |
| Plant-network consumers | outbound | JSON over HTTP |
Operations
Installed as a Windows service via deploy/install-service.cmd, configured from deploy/config.env.template. deploy/RUNBOOK.md covers operational procedures and scripts/smoke.sh provides a post-deploy check — this is one of the few repositories in the organisation with a written runbook.
Releases are packaged by scripts/package-release.sh for transfer to the air-gapped host.
PLMS-Centre-Data-Access-Guide.md documents the underlying data system, including the event-text lookup quirk the API works around.
Repository
| Repository | IdaMilk/Jumo_Service |
| Version | 0.0.1 |
| Primary language | JavaScript (Node) |
| Files | 37 |
| Last activity | 2026-07-14 |
| Status | Active |
Unusually disciplined for its size: minimal dependencies chosen for a specific deployment constraint, defence in depth on read-only access, a runbook, a smoke test, and a documented explanation of the vendor schema.