dohertj2/3yearplan
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Fix ScadaBridge accuracy per design repo review

Browse Source 
Corrections:
- Notifications: email only, not Teams. Design repo documents SMTP/OAuth2
  email only; Teams was incorrectly claimed. Corrected in current-state.md
  and legacy-integrations.md (LEG-003).
- EventHub/Kafka forwarding: committed but not yet implemented. Clarified
  as a Year 1 ScadaBridge Extensions deliverable, not an existing capability.

Additions from design repo (previously undocumented):
- Dual transport (Akka.NET ClusterClient + gRPC server-streaming)
- Split-brain resolver (keep-oldest, 15s stability, ~25s failover)
- Staggered batch startup (20 instances at a time)
- Central UI: Blazor Server with LDAP/AD, JWT sessions, SignalR debug
- Comprehensive synchronous audit logging (JSON after-state)
- Three-phase deployment process with rollback
- Site-level SQLite (flattened config, not full SQL Server)
- Supervision detail: OneForOneStrategy, Resume/Stop per actor type
This commit is contained in:
Joseph Doherty
2026-04-17 09:30:22 -04:00
parent fc3e19fde1
commit 8428b7c186
2 changed files with 13 additions and 7 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
current-state/legacy-integrations.md
View File

@@ -94,11 +94,11 @@ The authoritative list of **legacy point-to-point integrations** that currently
| **Business Purpose** | Operator / engineering / maintenance notifications (alarms, state changes, threshold breaches — _TBD_ which categories) emitted from System Platform and delivered by email. |
| **Current Owner** | _TBD — service is in-house but ownership of the custom service codebase and its operational runbook needs to be confirmed._ |
| **Dependencies** | Enterprise email system availability; recipient distribution lists baked into the custom service's configuration; any downstream workflows (ticketing, on-call escalation, acknowledgement) that trigger off these emails — _TBD_ whether any such downstream automation exists. |
| **Migration Target** | **ScadaBridge native notifications.** ScadaBridge already provides contact-list-driven, transport-agnostic notifications over **email and Microsoft Teams** (see `../current-state.md` → ScadaBridge Capabilities → Notifications). Migration path: port the existing notification triggers to ScadaBridge scripts, recreate recipient lists as ScadaBridge contact lists, dual-run both notification paths for a window long enough to catch low-frequency alarms, then cut over and decommission the custom service. |
| **Migration Target** | **ScadaBridge native notifications.** ScadaBridge already provides contact-list-driven notifications over **email** (see `../current-state.md` → ScadaBridge Capabilities → Notifications). Migration path: port the existing notification triggers to ScadaBridge scripts, recreate recipient lists as ScadaBridge contact lists, dual-run both notification paths for a window long enough to catch low-frequency alarms, then cut over and decommission the custom service. |
| **Retirement Criteria** | _TBD — at minimum: (1) **trigger parity** — every notification the custom service emits today is emitted by a ScadaBridge script; (2) **recipient parity** — every recipient on every distribution list exists on the equivalent ScadaBridge contact list; (3) **delivery SLO parity** — email delivery latency on the ScadaBridge path meets or beats today's; (4) **dual-run window** long enough to surface low-frequency notifications (monthly / quarterly events)._ |
| **Status** | Discovered |
| **Retirement Date** | — |
| **Notes** | **Easier retirement than LEG-001** — ScadaBridge's notification capability already exists in production, so this is a migration of **triggers and recipient lists**, not new build work. Closer in difficulty to LEG-002. **Open risk:** if the custom service also handles non-notification workflows (acknowledgement callbacks, escalation state, ticketing integration), those are out of scope for ScadaBridge's notification capability and would need a separate migration path — confirm during discovery whether the service is purely fire-and-forget email or has state. **Also — Teams as a by-product:** moving to ScadaBridge opens the door to routing the same notifications over Microsoft Teams without code changes (contact-list config only), which may be a quick win to surface with stakeholders during dual-run. |
| **Notes** | **Easier retirement than LEG-001** — ScadaBridge's notification capability already exists in production, so this is a migration of **triggers and recipient lists**, not new build work. Closer in difficulty to LEG-002. **Open risk:** if the custom service also handles non-notification workflows (acknowledgement callbacks, escalation state, ticketing integration), those are out of scope for ScadaBridge's notification capability and would need a separate migration path — confirm during discovery whether the service is purely fire-and-forget email or has state. **Note on Teams:** ScadaBridge does **not** currently support Microsoft Teams notifications — only email. Adding Teams as a transport would be a ScadaBridge extension, not an existing capability. If Teams notification routing is desired, it should be scoped as part of the ScadaBridge Extensions workstream. |
## Deliberately not tracked