Үйлчилгээний регистр ба Relay¶

Хоёр модуль нь байгууллагын мастер өгөгдөл дээр ажилладаг (хэрэглэгч тус бүрийн биш) тул RLS-гүй — хамгаалалт нь HTTP давхаргад эрхээр хийгддэг.

Ring System · R1 — Үйлчилгээний нэгдсэн регистр¶

Регистр нь «төрийн үйлчилгээний инвентар хэр бүрэн, хэр дижитал, once-only-д хэр ойрхон вэ» гэсэн асуултад хариулдаг удирдлагын хэрэгсэл. Паспорт (service passport) бүр CPSV-AP толь бичигт нийцнэ.

Паспортын статус¶

Статус	Утга
`draft`	Ноорог — нийтийн каталогт харагдахгүй
`published`	Нийтлэгдсэн — `/api/v1/catalog/*`-д гарна
`archived`	Архивлагдсан

Проактив байдлын шат¶

Эстонийн загвараар — зөвхөн мэдээллээс автомат үйлчилгээ хүртэл:

Шат	Утга
`information`	Зөвхөн мэдээлэл нийтэлсэн
`online`	Онлайн өргөдөл авдаг
`once_only`	Байгаа өгөгдлийг дахин шаарддаггүй
`proactive`	Иргэн хүсэлт гаргалгүйгээр өөрөө санал болгодог

Overview самбар нь шат бүрээр үйлчилгээний тоог харуулж, дундаж хуулийн шийдвэрлэх хугацааг тооцно.

Нотолгоо ба once-only¶

registry_evidences нь нотолгооны каталог. Бичлэг бүрийн in_khur талбар нь уг мэдээлэл ХУР-д аль хэдийн байгаа эсэхийг заана.

Паспорт ↔ нотолгооны холбоос дээр from_citizen флаг байдаг — уг баримтыг иргэнээс шаардаж байна уу, эсвэл байгууллага өөрөө системээс татдаг уу.

Once-only зөрчил

in_khur = true БА from_citizen = true хосолсон тохиолдол бүр нь once-only зөрчил — системд аль хэдийн байгаа мэдээллийг иргэнээс дахин шаардаж байна гэсэн үг. GET /api/v1/registry/once-only нь эдгээрийг жагсааж, жилийн давтамжаар нь иргэдэд учирч буй дарамтыг тооцоолно.

Хувилбар ба delta¶

Нийтлэх бүрд паспортын хувилбар (registry_service_versions) үүснэ. Delta* талбарууд нь дахин инженерчлэлийн өмнөх baseline-тай харьцуулсан ялгааг хадгална — сөрөг утга нь сайжралт (алхам цөөрсөн, хугацаа богиноссон).

Endpoint-ууд¶

registry.view — уншилт, registry.manage — бичилт. admin нь хоёуланд нь давна.

Метод	Зам	Эрх
`GET`	`/api/v1/registry/overview`	view
`GET`	`/api/v1/registry/catalog`	view
`GET`	`/api/v1/registry/once-only`	view
`GET`	`/api/v1/registry/services` · `/{id}`	view
`GET`	`/api/v1/registry/services/{id}/versions`	view
`GET`	`/api/v1/registry/services/{id}/once-only`	view
`GET`	`/api/v1/registry/evidences` · `/life-events`	view
`POST` `PUT` `DELETE`	`/api/v1/registry/services…`	manage
`POST`	`/api/v1/registry/services/{id}/publish` · `/archive`	manage
`PUT`	`/api/v1/registry/services/{id}/evidences`	manage
`POST` `PUT` `DELETE`	`/api/v1/registry/evidences…`	manage
`POST` `DELETE`	`/api/v1/registry/life-events…`	manage

UI: Admin → Registry (/admin/registry, /admin/registry/services, /admin/registry/evidences).

Relay — платформ хоорондын хүсэлт дамжуулалт¶

Relay нь дээд (upstream) платформоос хугацаатай хүсэлт хүлээн авч, доод (downstream) платформууд руу дамжуулж, SLA-г хянаж, хариуг цуглуулдаг.

flowchart LR
    U[Upstream platform] -->|POST /relay/requests| R[(Relay)]
    R -->|assignment| D1[Downstream A]
    R -->|assignment| D2[Downstream B]
    D1 -->|respond| R
    D2 -->|respond| R
    R -->|forward-up webhook| U

Статусууд¶

Хүсэлт: received → dispatched → in_progress → fulfilled (эсвэл overdue, rejected).

Даалгавар (assignment): pending → acknowledged → in_progress → done (эсвэл overdue, rejected).

SLA хяналт¶

Механизм	Утга
Сануулга	SLA цонхны 75% ба 90% дээр downstream руу шахалт илгээнэ
Escalate	Даалгавар overdue болсноос хойш нэмэлт хугацаа өнгөрөхөд дээд шат руу автоматаар дамжина
Timeline	`received` · `dispatched` · `reminded` · `escalated` · `responded` · `fulfilled` · `overdue` · `breach_notified` · `forwarded_up`

Escalate-ийн хүлээлт

Суурь модульд RelayEscalateGrace нь 2 минут — энэ нь загварын (template) утга. Production-д өөрийн SLA-даа тааруулж уртасгана.

Endpoint-ууд¶

Метод	Зам	Эрх
`POST`	`/api/v1/relay/webhook`	— (peer платформын дуудлага)
`POST`	`/api/v1/relay/requests`	manage
`POST`	`/api/v1/relay/assignments/{id}/respond`	manage
`POST`	`/api/v1/relay/requests/{id}/forward`	manage
`GET`	`/api/v1/relay/overview` · `/requests` · `/requests/{id}`	view
`GET` `POST` `DELETE`	`/api/v1/relay/platforms…`	view / manage
`GET` `POST` `DELETE`	`/api/v1/relay/routes…`	view / manage

RelayRoute нь service_code → platform чиглүүлэлтийн дүрэм бөгөөд target бүрдээ өөрийн SLA-тай.

UI: Admin → Relay (/admin/relay, /admin/relay/config, /admin/relay/{id}).

Ingest/Respond-ийн хамгаалалт

Энэ суурь хэрэгжилтэд requests ба assignments бичилт нь JWT + relay.manage-аар хамгаалагдсан. Production-д дээд/доод платформууд эдгээрийг gateway (m2m OAuth)-аар дуудах нь зөв загвар.