Synthetische Beispiele zum Nachbauen
Die Beispiele illustrieren Datenstrukturen und Prüfungen. Sie sind keine Erfolgsgeschichten oder Nachweise realer Transaktionen.
Ein Formular muss keinen Nachnamen erfinden. Das Modul Name und Geburt erlaubt:
{"name":{"preferredName":"Sukarno"},"birthDatePartial":"1984"}
Der Designer kann [name][preferredName] als Textfeld verwenden. Die unvollständige Geburt wird nicht automatisch als 1984-01-01 interpretiert.
Bei einer Bankverbindung außerhalb eines IBAN-Verfahrens genügt die strukturelle Alternative aus lokaler Kontonummer und den übrigen Pflichtfeldern. Der konkrete Zahlungsweg bestimmt zusätzliche Routing-Angaben:
{"accountHolders":[{"entityType":"person","id":"urn:example:person:42"}],"accountNumber":"000123456789","bank":{"name":"Example Bank","country":"US"},"currency":"USD"}
Die führenden Nullen bleiben erhalten. Das Beispiel führt keine Zahlung aus und bestätigt kein existierendes Konto.
Das Modul Geldbetrag trennt Wert und Währung:
{"amount":"12.345","currency":"KWD"}
Die Dezimalstellen werden beim JSON-Transport erhalten. Die Berechnung erfolgt mit einer Dezimalarithmetik; Rundung ist eine zusätzliche Geschäftsregel.
Eine Aufgabe enthält einen Verweis auf Dokumentmetadaten:
{"id":"urn:example:task:42","title":"Unterlagen prüfen","status":"pending","documentRefs":["urn:example:document:42"]}
Das Dokument wird separat gespeichert. Ein Adapter muss die Kennung auflösen, Berechtigungen prüfen und anschließend das vorhandene Workspace-Format bedienen.
Workflowübergaben verwenden eine einheitliche Hülle für Zielart, Ziel und freigegebene Nutzdaten. Beim Beispiel auf der Modulseite beschreibt payload.schemaId das Schema des enthaltenen Geldbetrags. Hülle und Nutzdaten werden getrennt validiert. Die Datei selbst ruft weder eine URL noch ein Skript auf.