Prüfungen und Zuständigkeiten

Teil des Prozesswissens. Zulässigkeit, Konformität, Vollständigkeit und fachliche Prüfung in fester Reihenfolge, und wer welche Ableitung anstoßen darf.

Die vier Prüfungen

Jede Operation durchläuft dieselben Prüfungen in derselben Reihenfolge. Die ersten beiden verändern nie etwas; die dritte entscheidet je nach Art, ob gespeichert wird; die vierte ist die fachliche Prüfung des Versicherers.

pruefungen-je-operation

  1. Zulässigkeit. Ist die Operation in diesem Zustand des Objekts erlaubt, und darf der Aufrufer sie ausführen? Ein Übergang „einreichen“ auf einem bereits eingereichten Antrag, eine Bearbeitung eines übergebenen Objekts, ein Zugriff ohne Berechtigung werden abgelehnt (HTTP 409 für den Zustand, 403 für die Rechte, 404 für ein unbekanntes Objekt), ohne dass sich etwas ändert. Zur Zulässigkeit gehört auch die Version: Bearbeitung, Ersetzung und Übergang nennen die Version des Objekts, die sie voraussetzen (HTTP If-Match); ist das Objekt inzwischen verändert – durch einen anderen Bearbeiter oder durch den Versicherer –, antwortet der Server mit 409 und der aktuellen Version, und der Client liest neu. Die Fehlerantwort der Zulässigkeitsprüfung (403, 404, 409) nennt den Grund als IRI aus dem Vokabular (bc:StateNotAllowed, bc:VersionMismatch, bc:BlockedBySubordinate, bc:IncompleteForTransition), Status, Titel, Erläuterung und die betroffenen Objekte – bei blockierenden Nebenprozessen deren IRIs und Zustände, beim Versionskonflikt die aktuelle Version – in der Form der Problem Details (RFC 9457), eingebettet in JSON-LD. Die Konformitätsprüfung antwortet dagegen mit dem Prüfbericht.

  2. Konformität. Ist die Anfrage syntaktisch richtig, erfüllt das Ergebnis die Shapes des Produktmodells, und passen die Parameter? Das gilt für alle Arten, auch für den Übergang und seine Parameter. Eine nicht konforme Anfrage wird mit HTTP 422 und einem Prüfbericht abgelehnt, ohne dass sich etwas ändert. Ein gespeichertes Objekt ist deshalb immer konform.

  3. Vollständigkeit. Sind alle Pflichteingaben vorhanden, die der Zustand verlangt? Bei Erzeugung, Ableitung, Ersetzung und Bearbeitung ist das keine Bedingung: Auch ein unvollständiges Objekt wird gespeichert, der Server erkennt den Zustand neu zu (Entwurf oder Bereit), und die Antwort trägt den Bericht mit jeder fehlenden Eingabe am betroffenen Knoten und die Folgeschritte. Beim Übergang ist Vollständigkeit Voraussetzung: Ein unvollständiges Objekt wird mit HTTP 409 und Bericht abgelehnt, ohne dass sich etwas ändert. Zur Vollständigkeit eines Hauptobjekts gehört auch der Zustand seiner blockierenden untergeordneten Objekte: Der Übergang „einreichen“ ist erst zulässig, wenn jeder blockierende Nebenprozess erfüllt ist; bis dahin fehlt der Übergang in den Folgeschritten, und der Bericht nennt die blockierenden Objekte. Bei der Auskunft gibt es nichts zu speichern; sie liefert Ergebnis und Bericht.

  4. Fachliche Prüfung des Versicherers. Prämie, Annahmerichtlinien, Deckung, Plausibilitäten – alles, was die Norm nicht über die Struktur entscheidet. Ihr Ergebnis ist ein Ergebnis, kein Ja oder Nein: eine Prämie, eine Annahmeentscheidung, eine Rückfrage, Meldungen am betroffenen Element. Sie läuft beim Übergang und, wo der Typ es vorsieht, in der Bearbeitung durch den Versicherer.

Die Begriffe dazu stehen im Glossar: konform (das Produktmodell ist erfüllt), vollständig (die Pflichteingaben des Zustands sind vorhanden), gültig (konform und vollständig). Der Server prüft bei jeder Anfrage selbst und vollständig; der Client darf mit denselben Shapes vorprüfen, muss aber nicht (Lösungsansatz).

Konformität und Vollständigkeit sind zwei verschiedene Arten von Regel: Konformität ist eine Invariante – sie gilt für jedes gespeicherte Objekt zu jeder Zeit, deshalb verändert eine nicht konforme Anfrage nichts. Vollständigkeit ist eine aufgeschobene Validierung – sie muss erst beim Übergang gelten, deshalb darf ein Entwurf unvollständig gespeichert werden und der Server sagt mit dem zuerkannten Zustand und dem Bericht, was noch fehlt (Einordnung).

Zuständigkeiten

Eine Ableitung darf anstoßen, wer für das neue Objekt verantwortlich ist:

  • Der Vermittler leitet ab, was er dem Kunden vorlegt oder für ihn einreicht: Berechnung → Offert, Offert → Antrag, bestehender Vertrag → Änderungsantrag, bestehender Vertrag → Konvertierungsantrag.

  • Der Versicherer leitet ab, was er verantwortet: Antrag → Vertrag, Änderungsantrag → geänderter Vertrag, Konvertierungsantrag → neuer Vertrag, Prüfung und Regulierung beim Schaden.

An jedem Geschäftsobjekt stehen die Zuständigkeiten als drei Rollen (Kernmerkmale):

  • Der Veranlasser (requester) hat das Objekt entstehen lassen: der Vermittler für Berechnung, Offert und Antrag, der Versicherer für den Vertrag und für die Nebenprozesse, die er anfordert.

  • Der Verantwortliche (owner) entscheidet über Zustand und Ergebnis: in der Regel der Versicherer, beim Entwurf der Vermittler.

  • Am Zug (actor) ist, wer als Nächstes handeln muss: der Vermittler am Entwurf und in der Rückfrage, der Versicherer am eingereichten Antrag, der Kunde bei der Identifikation, der Gutachter bei der Besichtigung.

Veranlasser und Verantwortlicher folgen aus der Deklaration der Ableitung und werden bei der Entstehung gesetzt; „am Zug“ ändert sich mit dem Zustand und zeigt einem Client oder Agenten an jedem Objekt einheitlich, ob er selbst handeln muss oder wartet.

Übergänge stößt der Client an, der das Objekt bis dahin in der Hand hatte; die gesetzten Zustände danach vergibt der Versicherer. Welche Übergänge und Ableitungen ein Geschäftsfalltyp hat, wer sie anstoßen darf und welche Parameter ein Übergang erwartet, deklariert das Prozesswissen je Typ; die erwartete Form eines Parameters nennt der Folgeschritt als Shape (bc:expects), so wie heute bei jeder Operation.