DDM_SOURCE_SYSTEM

Status: Entwurf · Spec-Kandidat: ja

Zweck

Registry der Quellsysteme, aus denen Stammdaten ins MDM einfließen oder mit denen Stammdaten synchronisiert werden. Vermeidet Free-Text-Wildwuchs in der Mapping-Tabelle DDM_ENTITY_EXTERNAL_ID (“SAP” vs. “sap” vs. “S/4-HANA-PROD”) und ist der Anker für künftige Survivorship-Regeln (OP-29) sowie inbound-Webhook-/Sync-Konfiguration.

Felder

Feld	Typ	Pflicht	Hinweise
`id`	uuid	ja	PK
`tenant_id`	uuid	ja	FK → `AA_TENANT`. Quellsysteme sind tenant-scoped — eine Konzern-Tochter pflegt eigene
`key`	text	ja	Format `^[a-z][a-z0-9_]*$`, eindeutig je Tenant. Beispiele: `sap_prod`, `salesforce`, `webshop`, `dynamics_crm`
`name`	text	ja	Anzeigename
`description`	text	nein
`trust_level`	smallint	ja	default `50`, Bereich `0..100`. V1 nur dokumentiert, nicht aktiv ausgewertet. Vorgesehen als Eingabe für Survivorship-Regeln in OP-29 (Match/Merge): höhere Vertrauensstufe gewinnt bei konkurrierenden Werten
`webhook_config`	jsonb	ja	default `'{}'`. Inbound-Webhook-Settings (Signatur-Schlüssel-Ref, erlaubte IPs, Endpoint-Slug). Format hängt vom Sync-Mechanismus ab
`is_active`	boolean	ja	default `true`. Inaktiv = neue `DDM_ENTITY_EXTERNAL_ID`-Zeilen werden vom Service abgelehnt; bestehende bleiben unangetastet
`metadata`	jsonb	ja	default `'{}'`
`created_at` / `updated_at` / `created_by` / `updated_by`	–	–	Standardfelder
`deleted_at` / `deleted_by`	–	–	Soft-Delete

Constraints

source_system_key_format_chk: key ~ '^[a-z][a-z0-9_]*$'
source_system_metadata_is_object_chk, source_system_webhook_config_is_object_chk
source_system_trust_chk: trust_level BETWEEN 0 AND 100
source_system_key_per_tenant_uk: UNIQUE (tenant_id, key)

Trigger

trg_source_system_set_updated_at

Verhalten

Anlage erfolgt durch Plattform-Admin oder metadata_admin (manuell oder durch ein Provisioning-Skript je Tenant).
Soft-Delete eines Quellsystems ist erlaubt; bestehende DDM_ENTITY_EXTERNAL_ID-Zeilen bleiben referentiell gültig (kein ON DELETE CASCADE), tauchen aber als „obsolet” in einer Steward-Sicht auf.
trust_level ist dokumentiert, in V1 jedoch ohne Wirkung. Erst OP-29 (Match/Merge / Survivorship) liest die Spalte aus. Dadurch lässt sich Vertrauen bereits bei der Erst-Anlage realistisch befüllen, ohne auf OP-29 zu warten.

Beispiele

`key`	Zweck
`sap_prod`	SAP S/4HANA Produktion, lädt Kunden- und Lieferantendaten
`salesforce`	Salesforce CRM, schickt Leads + Account-Updates
`webshop`	Eigener Webshop, Self-Service-Anlage durch Endkunden
`manual`	Reservierter Marker für hand-erfasste Datensätze ohne Quellsystem