Konfiguration vor der Veröffentlichung validieren

Der MobilityManager validiert die Konfiguration serverseitig, bevor sie gespeichert oder aktiviert wird, sodass ein ungültiger Wert niemals wirksam werden kann. Zu wissen, was geprüft wird, hilft Ihnen, Probleme schnell zu beheben und fehlgeschlagene Speichervorgänge zu vermeiden. Dieser Artikel fasst die Validierung zusammen, die über die wichtigsten Konfigurationsbereiche hinweg angewendet wird.

Warum serverseitige Validierung wichtig ist

Client-Formulare leiten Sie an, doch die Plattform prüft jede Änderung beim Absenden erneut. Eine abgewiesene Änderung gibt eine spezifische Fehlermeldung zurück, statt teilweise angewendet zu werden, wodurch die Konfiguration in einem konsistenten, sicheren Zustand bleibt.

Belege-Konfiguration (Veröffentlichung)

Das Veröffentlichen einer Belege-Konfiguration erfordert die Rolle SystemAdmin und durchläuft folgende Prüfungen:

Eine Versionsbezeichnung ist erforderlich.
Mindestens ein Beleg-Typ muss konfiguriert sein.
Jeder Schweregrad muss ein anerkannter Wert sein: Off, Info, Warning oder Blocking. Ein unbekannter Schweregrad wird mit einer Meldung abgewiesen, die die zulässigen Werte auflistet und den betreffenden Typ und das betreffende Feld benennt.
Die Konfigurations-Baseline muss verfügbar sein, andernfalls gibt die Veröffentlichung einen 503 zurück.

Hinweis: Die Schweregrad-Validierung läuft über jedes Feld je Typ — Kraftstofftyp-Abweichung, fehlende Kostenstelle, fehlender Mehrwertsteuersatz, Dublettenerkennung und Kilometerstands-Plausibilität — sodass ein veralteter Client oder ein Tippfehler keinen Wert speichern kann, den die Regel-Engine nicht verstehen würde.

Lokalisierungsbezeichnungen

Sie müssen mindestens eine Bezeichnung übermitteln.
Jeder Eintrag benötigt einen nicht leeren internen Schlüssel, einen Sprachcode und eine Bezeichnung.
Der interne Schlüssel muss einer der anerkannten Workflow-Status- oder Beleg-Typ-Schlüssel sein; ein nicht unterstützter Schlüssel wird abgewiesen.
Das Speichern erfordert zusätzlich zu settings:manage die Rolle SystemAdmin.

Dokumentenspeicher

Der Anbieter muss ein unterstützter Wert sein: Local, Azure Blob oder S3.
Anbieterspezifische Pflichtfelder werden erzwungen (zum Beispiel ein Basispfad für Local, ein Container und eine Verbindungsreferenz für Azure Blob sowie ein Bucket, eine Region und Schlüsselreferenzen für S3).
Ein angegebener lokaler Verschlüsselungsschlüssel muss ein base64-codierter 32-Byte-AES-Schlüssel sein.
Wenn die Verschlüsselung im Ruhezustand aktiviert ist, ist eine Verschlüsselungsschlüssel-Referenz erforderlich und muss sich aus der Konfiguration auflösen lassen.

Referenzdaten

Schlüssel für Kraftstofftypen und Motortypen sind erforderlich und werden in Kleinbuchstaben gespeichert.
Schlüssel müssen eindeutig sein; ein Duplikat gibt einen Konflikt zurück.

Eine Checkliste vor der Veröffentlichung

Vergewissern Sie sich, dass Sie die erforderliche Berechtigung besitzen — und die Rolle SystemAdmin, wo eine Veröffentlichung oder Lokalisierung beteiligt ist.
Prüfen Sie die aktuell aktive Version, damit Sie wissen, was Sie ersetzen.
Kontrollieren Sie, dass Schweregrade und Anbieterfelder zulässige Werte verwenden.
Bei E-Mail-Vorlagen: Vorschau vor der Aktivierung anzeigen.
Absenden und anschließend das gespeicherte Ergebnis durch erneutes Öffnen der Konfiguration überprüfen.

Tipp: Wenn ein Speichervorgang fehlschlägt, lesen Sie die zurückgegebene Meldung genau — sie benennt das genaue fehlerhafte Feld oder den fehlerhaften Wert, was schneller ist als Raten.

Warnung: Eine 503-Antwort "baseline not available" oder "store not available" ist ein Umgebungsproblem, kein Validierungsfehler. Ein erneuter Versuch hilft nicht; das zugrunde liegende Schema muss zunächst bereitgestellt werden.