Skip to content

Version 3.3

Features

Bug-Fixes

  • Die Dokumente wurden nicht über die in der appsettings.json konfigurierte Api-Base-URL heruntergeladen, sondern direkt über das CMI-Backend. Dieser Fehler wurde behoben.

Version 3.2

Features

  • Einführung vom Prozess Layer 'Klapp'

Version 3.1

Features

  • Einführung von "Gruppen". Pro Mandant lassen sich mittels Config-UI mehrere Definitionen (Gruppen) erstellen die eine eigene Konfiguration haben. Diese Gruppen sind unter einer eigenen URL ereichbar. Bestehende Konfigurationen funktionieren wie bisher.

Version 3.0

Features

Breaking Changes

  • STS 2.0 wird nicht mehr unterstützt
  • Der STS Client für die CMI API muss den Grant-Type authorization_code unterstützten. Implicit wird nicht mehr benötigt.
  • Config-UI ist neu eine statische Webseite und ist neu unter der URL <Protokoll>://<CmiApiServer>:<Port>/<Mandant> erreichbar
  • Swagger ist neu unter <Protokoll>://<CmiApiServer>:<Port>/<Mandant>/swagger/index.html erreichbar und enthält mehrere Definitionen
  • In appsettings.json sind die Einträge für DataProtection und SignalR ausgebaut und werden nicht mehr benötigt

Version 2.2

Wichtig: Für einen vollständig funktionsfähigen skaliertem Betrieb Version 3.x verwenden.

Wichtig: Unabhängig davon, ob die CMI API skaliert betrieben wird, wenn das Hosting via IIS erfolgt, muss ab dieser Version das Windows Feature Web Server / Application Development / WebSocket Protocol installiert sein. Für weitere Informationen, siehe Installation.

Ergänzungen für einen eingeschränkten skalierten Betrieb.

  • Optionales Redis-Backend für SignalR
  • Zentraler Datenspeicher für den Data Protector
  • Reconnect-Anweisungen für die WebSocket-Verbindung
  • Http Web Hook bei Konfigurationsänderungen
  • STS-Discovery-Daten werden nicht mehr für jeden Mandaten beim Prozessstart abgerufen, sondern bei der ersten Verwendung

Fehlerkorrektur bei Konfiguration mit mehreren Mandaten / API's

  • Enum Werte funktionieren bei allen API's

Version 2.0

Neue Einstellung AutoRebootOnConfigChangeEnabled, welche standardmässig aktiviert ist. Durch diese Einstellung wird die komplette API automatisch neu gestartet, wenn bei einem Tenant die Definition angepasst wird.