Das CRMS-Modul im Hub

Worum es geht

Ein Projekt im Hub kann ein CRMS-Modul haben. Darin steht, was das Projekt über Berichte einmal entscheidet, bevor es das System überhaupt gibt: ob endgültige Dokumente aufbewahrt werden, wie lange, ob sie versiegelt werden, welche Formate es gibt, wer Vorlagen schreibt und wer sie freigibt. Ein endgültiges Dokument ist ein Bericht, den CRMS als Nachweis ablegt. Mehr dazu unter Was ein endgültiges Dokument ist.

Du bearbeitest das Modul im CRMS-Portal, einer Oberfläche im Hub. Der Hub öffnet sie aus dem Projekt heraus. Das Portal verwaltet keine Vorlagen und keine Dokumente einer laufenden Installation. Es bearbeitet nur das Modell.

Ein Projekt hat höchstens ein CRMS-Modul. Hat es zwei, bricht der Export des Projekts ab. Jedes geschützte CDMS-Modul des Projekts nutzt dieses eine CRMS-Modul.

Vom Hub in den Build

Die Platzierung: wo das Modul läuft

Ein Feld für „eingebettet oder eigener Dienst“ gibt es nicht. Der Build leitet es daraus ab, in welcher Laufzeit das CRMS-Modul steht. Eine Laufzeit ist im Hub ein Prozess, in dem Module laufen.

CRMS braucht CIAS. CRMS fragt CIAS nach dem Mandanten und reicht das Token des Aufrufers weiter. Ein öffentliches CDMS-Modul (authentication: NONE) hat beides nicht und bekommt deshalb nie einen CRMS-Teil. Steht das CRMS-Modul in der Laufzeit eines öffentlichen CDMS-Moduls, lehnt der Build ab.

Die Felder

Jedes Feld ist optional. „Leer“ heißt: Das Feld wird nicht geschrieben, die Spalte „Vorgabe von CRMS“ gilt.

Ein Scope sagt, wem eine Vorlage gehört: der Plattform (SYSTEM), einem Mandanten (TENANT) oder einem Benutzer (USER). Siehe Aufbau einer Vorlage. Die Rollen sind Client-Rollen in CIAS, siehe Rollen in CRMS.

Zwei weitere Felder stehen im Modell: approvalReauthenticate und approvalTenantDefined. Der Build liest sie nicht. Sie ändern weder die Konfiguration noch die Umgebung.

Was die Datei enthält

Der Build schreibt jedes gesetzte Feld als ${VARIABLE:wert}. Das ist die Spring-Schreibweise für „nimm die Variable, sonst diesen Wert“. Die Berichte des Hubs zum Beispiel legen keine Dokumente ab, siegeln nicht und erlauben nur Systemvorlagen. Ihr Build schreibt:

# Generated on every build from the CRMS module of this project in the CodamAI hub
codamai:
  crms:
    document:
      revisions: "${CODAMAI_CRMS_DOCUMENT_REVISIONS:false}"
    seal:
      mode: "${CODAMAI_CRMS_SEAL_MODE:none}"
    template:
      scopes: "${CODAMAI_CRMS_TEMPLATE_SCOPES:SYSTEM}"

Leere Felder fehlen in der Datei. Die Datei wird nicht von Hand bearbeitet: Der nächste Build überschreibt sie.

Formate entscheiden die pom.xml

formats ist kein Vorgabewert einer Variable. Das Feld entscheidet, welche Formatmodule in die pom.xml kommen. CRMS bietet dann an, was installiert ist.

Ein CDMS-Modul, das CRMS nur als Client nutzt, bekommt kein Formatmodul. Es rendert nichts selbst.

Die Freigabestufen

Eine Freigabe ist die Zustimmung, bevor eine eingereichte Vorlage veröffentlicht wird. Je Scope kann das Projekt eine Kette von Stufen festlegen. Jede Stufe hat diese Felder:

Der Build schreibt die Stufen in der Reihenfolge von sortOrder nach codamai.crms.template.approval.<scope>:

codamai:
  crms:
    template:
      approval:
        tenant:
          - name: Fachliche Prüfung
            role: crms-template-reviewer
            meaning: REVIEWED
          - name: Freigabe
            role: crms-template-approver
            minimum-approvers: 2
            meaning: APPROVED

(Die Rollennamen sind ein Beispiel.) Die Stufen haben keine Umgebungsvariable. Eine Freigabekette, die eine Umgebung abschalten könnte, wäre keine. Ein Scope ohne Stufe veröffentlicht eine eingereichte Vorlage sofort. Wie die Kette abläuft, steht unter Freigabe.

Hinweise im Portal

Das Portal prüft das Modul beim Bearbeiten und zeigt Hinweise. Speichern sperrt es nur bei Freigabestufen, die das Modell selbst ablehnt.

Fallen

Weiter

• Umgebungsvariablen
• Die Datenbank
• Beispiel: die Berichte des Hubs
• Eingebettet oder eigener Dienst