Files
apix-mvp/docs/arc42/03-context-scope.md
T
Carsten Rehfeld b2a16a8be7 Implement apix-registry with IoT sunset/decommission lifecycle and full BDD suite
- REST API: register, patch, O-level, replacements, history, search endpoints
- IoT lifecycle validations: future sunset, lock-before-release, sunset-passed-before-decommission
- DB schema: Liquibase changesets 001–008 (services, versions, replacements, sunset-at column)
- @ColumnTransformer(write="?::jsonb") on bsm_payload fields to avoid JDBC varchar→jsonb rejection
- Jandex plugin on apix-common + quarkus.index-dependency so @NotBlank validators resolve at runtime
- quarkus-logging-json extension added; quarkus.log.console.json=false is now a recognised key
- Fix requireSunsetBeforeLockRelease: Boolean.TRUE.equals instead of !Boolean.FALSE.equals (null guard)
- BDD suite: 27 scenarios / 213 steps across 5 feature files (sunset-lock, decommission, replacement, discovery, anonymity)
- Test infrastructure: JDBC TRUNCATE in @Before for DB isolation, Arc.container() for clock control — no test endpoints in production code
- sunsetAt truncated to microseconds in BDD steps to match Postgres timestamptz precision
- Cucumber step fixes: singular/plural candidate(s), lastResponse propagation in replacementsReturnsNCandidates

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-05-08 09:13:26 +02:00

2.5 KiB

arc42, status
arc42 status
3 — Context and Scope stub

3.1 Business Context

TODO: PlantUML system context diagram.

External actors:

  • Autonomous Agent — queries the index by capability; reads BSM; consumes registered services
  • Service Registrant — submits BSM via portal or API; receives registration confirmation
  • Spider — automated crawler (internal); checks liveness of registered services against external endpoints
  • Admin (BSF) — assigns O-levels; approves pending registrations; monitors registry health
  • External Service Endpoints — the actual services being registered; queried by Spider for liveness
@startuml context
!include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Context.puml

Person(agent, "Autonomous Agent", "Queries registry by capability; consumes registered services")
Person(registrant, "Service Registrant", "Submits BSM; monitors registration status")
Person(admin, "BSF Admin", "Assigns O-levels; approves registrations")

System(apix, "APIX Registry", "Global, queryable index of machine-consumable services")

System_Ext(ext_service, "External Service Endpoint", "The registered service; queried by Spider for liveness")

Rel(agent, apix, "Capability query / BSM fetch", "HTTPS/JSON")
Rel(registrant, apix, "BSM registration / status check", "HTTPS/JSON or Portal")
Rel(admin, apix, "O-level assignment / moderation", "Portal (API-key)")
Rel(apix, ext_service, "Liveness check / spec fetch", "HTTPS", "Spider")

@enduml

3.2 Technical Context

TODO: PlantUML technical context diagram showing network boundaries.

Components inside the system boundary:

  • Caddy (reverse proxy, TLS termination)
  • API service (FastAPI)
  • Portal service (FastAPI + HTMX)
  • Spider service (async Python scheduler)
  • PostgreSQL (registry database)

3.3 External Interface Table

Interface Direction Protocol Data
Capability query Agent → API HTTPS GET Query params: capability, country, olevel; Response: BSM list
BSM registration Registrant → API HTTPS POST BSM JSON payload + API key header
Service detail Agent → API HTTPS GET BSM + liveness status
HATEOAS root Agent → API HTTPS GET Navigation links JSON
Liveness check Spider → Ext. service HTTPS GET HTTP status + response time
OpenAPI fetch Spider → Ext. service HTTPS GET OpenAPI JSON spec
Admin portal Admin → Portal HTTPS Browser; HTML form