dohertj2/ScadaBridge
1
0
Fork 0
Code Issues 5 Pull Requests Actions Packages Projects Releases Wiki Activity

docs: relabel wonder-app-vd03 as DEV, not production, across plans, records, reviews and API specs

Browse Source 
vd03 is the DEV box (vd = DEV, vq03/vq04 = QA). Historical docs called it prod/production.
Only vd03-referential uses are changed; generic 'production' wording (production HOCON,
production code paths, ASPNETCORE_ENVIRONMENT=Production, real-world production guidance)
is unchanged. One verbatim git commit message quoted in PLAN-07 is left as recorded.
This commit is contained in:
Joseph Doherty
2026-11-10 15:11:45 -05:00
parent ee320cd544
commit 48517b49fb
35 changed files with 110 additions and 110 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/api-specs/Delmia-Recipe-Download-API.md
+14 -14
View File
@@ -1,9 +1,9 @@
# DelmiaRecipeDownload — ScadaBridge Inbound API spec (as deployed)
**Captured:** 2026-09-02 from the live **prod** management API on `wonder-app-vd03` (method id 4,
**Captured:** 2026-09-02 from the live **DEV** management API on `wonder-app-vd03` (method id 4,
API keys, the `CvdReactor` template's `ProcessRecipeDownload` script, the `DelmiaReceiver` template,
and the inbound audit log). **QA (`vq03`/`vq04`) was NOT read** — its management API requires real
LDAP credentials (prod runs with `DisableLogin`); re-capture QA with `scadabridge api-method get --id …`
LDAP credentials (DEV vd03 runs with `DisableLogin`); re-capture QA with `scadabridge api-method get --id …`
once credentials are to hand. The definition is config-as-data in the central ConfigDb (not in git), so
this file is the durable record; the legacy predecessor is documented in
[`../former-api-specs/dnc/Delmia-Integration-API.md`](../former-api-specs/dnc/Delmia-Integration-API.md)
@@ -18,7 +18,7 @@ this file is the durable record; the legacy predecessor is documented in
| Auth | `X-API-Key: sbk_<keyId>_<secret>` **or** `Authorization: Bearer sbk_<keyId>_<secret>` (Authorization wins if both) |
| Content type | `application/json`, flat PascalCase object |
| Server timeout | **45 s** (`TimeoutSeconds` on the method); the site-side handshake wait inside it is **25 s** |
| Prod base URL | `http://wonder-app-vd03.zmr.zimmer.com:8085` (single central node) |
| DEV (vd03) base URL | `http://wonder-app-vd03.zmr.zimmer.com:8085` (single central node) |
| QA base URLs | `http://10.220.158.2:8085` (vq03), `http://10.220.158.3:8085` (vq04) — list **both** in the notifier's `BaseUrls`; a standby central relays to the active peer |
Unauthenticated / bad-key calls return **401** `{"error":"Invalid or missing API key"}` (audit kind
@@ -44,14 +44,14 @@ script itself rejects a missing/blank `MachineCode`):
| Field | Notifier flag | Meaning | Where it lands on the site |
|---|---|---|---|
| `MachineCode` | `-m` | **Routing key** — must equal an instance `UniqueName` exactly (trimmed). Prod today: `Z28061`, `Z28062`, `Z28061Sim`. | `Route.To(MachineCode)` |
| `MachineCode` | `-m` | **Routing key** — must equal an instance `UniqueName` exactly (trimmed). DEV (vd03) today: `Z28061`, `Z28062`, `Z28061Sim`. | `Route.To(MachineCode)` |
| `DownloadPath` | `-d` | Path where the recipe/NC file was placed | `DelmiaReceiver.DownloadPath` |
| `WorkOrderNumber` | `-w` | Work order | `DelmiaReceiver.WorkOrderNumber` |
| `PartNumber` | `-p` | Part / item number | `DelmiaReceiver.PartNumber` |
| `JobStepNumber` | `-s` | Job step / sequence op | `DelmiaReceiver.JobStepNumber` |
| `Username` | `-u` | Operator (audit only) | `DelmiaReceiver.Username` |
Example (a real call taken from the prod audit log):
Example (a real call taken from the DEV (vd03) audit log):
```bash
curl -s -X POST http://wonder-app-vd03.zmr.zimmer.com:8085/api/DelmiaRecipeDownload \
@@ -93,7 +93,7 @@ Delmia ─► WWNotifier.exe ─► POST /api/DelmiaRecipeDownload (central, act
4. read RecipeProcessResult / RecipeProcessResultText → {Result, ResultText}
```
Both scripts as deployed on prod (verbatim):
Both scripts as deployed on DEV vd03 (verbatim):
<details><summary>Central inbound method script (id 4, timeout 45 s)</summary>
@@ -154,12 +154,12 @@ try {
> the PREVIOUS download's cached `true`. The runtime fix is the reset-aware overload —
> `WriteBatchAndWaitAsync(data, "RecipeDownloadFlag", true, "RecipeProcessedFlag", true, 25 s,
> "RecipeProcessedFlag", false, 10 s)` returning a `HandshakeResult` — which replaces steps 2–3.
> The deployed prod/QA script bodies are NOT yet ported (deferred-work register row 119).
> The deployed DEV/QA script bodies are NOT yet ported (deferred-work register row 119).
## 5. Galaxy-side contract — the `DelmiaReceiver` template (id 12; composed clone id 26)
All ten attributes are **data-sourced over the site `MxGateway` connection**, bound per instance to the
reactor-level Galaxy object (prod: `DelmiaReceiver_038` on Z28061, `_039` on Z28062, `_037` on
reactor-level Galaxy object (DEV vd03: `DelmiaReceiver_038` on Z28061, `_039` on Z28062, `_037` on
Z28061Sim; `Left_00x.DelmiaReceiver` / `Right_00x.DelmiaReceiver` back the unused side compositions).
| Attribute | Type | Direction | Role in the handshake |
@@ -171,17 +171,17 @@ Z28061Sim; `Left_00x.DelmiaReceiver` / `Right_00x.DelmiaReceiver` back the unuse
| `RecipeProcessResultText` | String | Galaxy → SB | Outcome text → `ResultText` |
| `DownloadPath`, `WorkOrderNumber`, `PartNumber`, `JobStepNumber`, `Username` | String | SB → Galaxy | Payload, written as one batch before the trigger |
## 6. API keys scoped to this method (prod, names only — secrets are shown once at creation)
## 6. API keys scoped to this method (DEV vd03, names only — secrets are shown once at creation)
`mes`, `mes api key`, `delmia-mes-receivers`, `TestKey`, `JOE_TEST_KEY` — all enabled, all also
scoped to the MES methods (`MesMoveIn`, `MesMoveOut`, `MesSampleData`, `SimpleAlarmStatusRequest`,
most also `IpsenMESMoveIn`). `delmia-mes-receivers` is the one whose name says it is the Delmia
caller's key; the audit `actor` column shows which key served each call.
## 7. Observed behaviour and open issues (from the prod audit log, 2026-06-17 → 2026-06-26)
## 7. Observed behaviour and open issues (from the DEV vd03 audit log, 2026-06-17 → 2026-06-26)
Nine calls total, all test traffic (actors `delmia-mes-receivers`, `delmia-sim-test`), none since
2026-06-26 — **no production Delmia traffic has hit this method yet.** Every 200 answered
2026-06-26 — **no real Delmia traffic has hit this method yet.** Every 200 answered
`Result=false`: mostly `Receiver ready flag not set to true`, one
`Script 'ProcessRecipeDownload' … The given key 'side' was not present` from an earlier script
revision, and one `MachineCode must end with A (Left) or B (Right)` from a retired left/right variant
@@ -277,7 +277,7 @@ README states throughout.
configuration database, so a key exists on both nodes the instant it's created and a revoke is
cluster-wide immediately. `docker/sync-inbound-api-keys.sh` is deleted; a re-run of this drill needs
no file copy before the failover step. Re-measured 2026-09-03 without the
workaround: A/B/E/F `YES`, C/G `NO`, active-central `docker kill` takeover **28 s** (the earlier run measured 27 s with the file copy), victim rejoined as standby 2 s after restart. Prod `wonder-app-vd03` is single-node and unaffected; the QA pair
(`vq03`/`vq04`) and prod still run `Provider=Sqlite` pending a deployment record.
workaround: A/B/E/F `YES`, C/G `NO`, active-central `docker kill` takeover **28 s** (the earlier run measured 27 s with the file copy), victim rejoined as standby 2 s after restart. DEV `wonder-app-vd03` is single-node and unaffected; the QA pair
(`vq03`/`vq04`) and DEV (vd03) still run `Provider=Sqlite` pending a deployment record.
Deferred-work register row 107 records §7 item 1 (`Children["DelmiaRecv"]`) as the prod follow-up.
Deferred-work register row 107 records §7 item 1 (`Children["DelmiaRecv"]`) as the DEV (vd03) follow-up.