Change-Log

Version 2.4

Die Dokumentation wurde ergänzt um die Konfiguration im CMI Server.
Die Komponenten wurden aktualisiert.
TypDefinitions-Keys dürfen beim Einsatz einer SQLServer-Datebank nicht mehr als 450 Zeichen lang sein.
Beim Scripting steht nun eine bessere CodeCompletion zur Verfügung. Hierfür kann beispielsweise die aktuelle Zeile mittels GetCurrentRow().GetTypedRow<T>() typisiert werden. Für T stehen dabei die Schlüssel der TypDefinitionen zur Verfügung. Wird das typisierte Objekt danach verwendet so werden die entsprechenden Properties automatisch vorgeschlagen. Pro Mandant dauert die erste Ausführung eines Reports oder des Designers etwa 20 Sekunden länger.
Um die CodeCompletion zu verwenden, muss das folgende using-Statement hinzugefügt werden: using CMI.Reporting.Service.Public;

Neu sind gleichnamige Reports erlaubt, solange diese für unterschiedliche TypDefinitionen erstellt werden.
Gibt es Migrationen der Datenbank so werden diese beim Servicestart automatisch angewendet. Dies ist das neue Standardverhalten. Siehe auch InstanceMode.
Im Designer können neu Barcodes hinzugefügt werden.
Im Desigenr können neu Charts hinzugefügt werden. Die Datenbefüllung wird zurzeit aber nur via Script unterstützt.
Verbessertes Logging für besseres Troubleshooting
Sinnvolle Fehlermeldungen für fehlerhafte ReportAnfragen.
Beim Export werden die Reports flachgedrückt direkt im zip abgelegt. Zusätzlich wird im zip-File ein metadata.json mit den Struktur-Informationen der Reports erstellt.
Der Import unterstützt sowohl bestehende wie auch neue Exports.
Neu sind auch gleichnamige Ordner wie Reports erlaubt.
Bei Konflikten beim Import von Reports wird nicht nur der Name des Reports angezeigt sondern auch noch die TypDefinition.

Problem behoben, bei dem in Dropdowns nach dem Filtern und Herunterscrollen keine Werte mehr ausgewählt werden konnten.
Problem im Loading-Spinner-Component behoben, der bei einigen API-Calls nicht angezeigt wurde.
Schreibfehler in einer URL korrigiert, der verhindert hat, dass geänderte Renderer-Einstellungen vom Reporting-Service bemerkt werden.
Kann ein Report wegen Fehlern nicht gerendert werden, wird auf API-Ebene ein Fehler zurückgegeben statt so zu tun, als hätte es funktioniert.
Das mit Version 2.1 erhöhte Limit ging verloren und wurde wieder eingeführt.

Der CMI Reporting Service bietet einen neuen Endpunkt unter '/[tenant]/api/VersionDiscovery' an, um die unterstützten API-Versionen abzufragen
Reports für mehrere Objekte werden in der Reihenfolge der Objekte ausgegeben wie diese übergeben werden.
Bei Feldern des Typs "Dokument" gibt es nun ein Feld pro Renderer. Das originale Feld " (Data)" gibt es nach wie vor. Dieses gibt die originale Rendition zurück. Funktioniert erst ab R25.2. Vorher steht die entsprechende Option nicht zur Verwendung.
Einführung API-Version 2
Bei Report-Parametern kann neu ein Standardwert hinterlegt werden. Bisher war das Feld versteckt, d.h. jeder Report hatte bereits einen Standardwert, nun ist er aber konfigurierbar. Bei String-Parametern können mehrere Werte hinterlegt und als Enum genutzt werden.
Bei Report-Parametern kann neu ein NULL-Wert zugelassen werden.

Der Endpunkt /[tenant]/api/v2/ReportParameters liefert im Vergleich zu v1 ein DefaultValuesAsString-Property. In der Regel hat dieses Array nur einen Eintrag. Wenn ein Parameter als Enum genutzt wird, sind mehrere Werte enthalten. Es liegt am Konsumenten, einen Wert beim Endpunkt /[tenant]/api/v2/RenderedReport mitzuschicken.
Der Endpunkt /[tenant]/api/v2/ReportParameters liefert im Vergleich zu v1 ein AllowNull-Property. Es liegt am Konsumenten zu entscheiden, wann beim Endpunkt /[tenant]/api/v2/RenderedReport statt einem echten Wert NULL als Wert gesendet wird, bspw. ob statt 0 fachlich eher NULL richtig ist. Ein fehlender übermittelter Wert und ein explizit mit NULL übermittelter Wert werden gleich behandelt.

Gewisse Scripts funktionierten mit >= 2.0 nicht mehr, da Datumsfelder als String behandelt wurden. Dies wurde korrigiert.

Die Dateien im Release-Paket wurden nicht mit der deklarierten Version markiert, was korrigiert wurde.
Der Standardpfad für den automatisch gestarteten Prozess für die externe Reporterstellung enthielt einen Windows-Pfad-Delimiter, was unter Linux zu Problemen geführt hat. Der Delimiter wurde entfernt, da er nicht notwendig war.
Nach dem Start des automatisch gestarteten Prozesses wird neu eine kurze Zeit gewartet, damit dieser genug Zeit hat, sich zu initialisieren.
Das Limit für die Tiefe an abgefragten Daten war zu niedrig eingestellt. Es wurde um ca. 50% erhöht.
Die konfigurierten Schriftarten wurden nicht mehr beachtet bei der Reporterstellung. Dies wurde korrigiert.

Die Objekte in der Datenstruktur, die in der Funktion "TryGetDataSource" zurückgegeben werden, sind nicht mehr stark typisiert vom Typ "IDictionary" sondern vom Typ "object". Dieser Breaking Change ist ein Artefakt von der Umstellung zur externen Reporterstellung. Wir gehen davon aus, dass dies niemanden betrifft. Die Verwendung von "TryGetDataSource" Kombination mit "dynamic" sollte von diesem Breaking Change nicht betroffen sein.

Die Generierung der Reports wird in einen eigenen Prozess oder ausgelagerten Dienst ausgelagert. Somit können Sicherheitslücken durch Scripts verhindert werden.
Der automatisch gestartete Prozess zur Reporterstellung wird bei der Beendung des Dienstes ebenfalls beendet.

Reports, welche auf abstrakten Typen gestaltet wurden, funktionieren nun korrekt.

Der Designer berücksichtigt die eingestellte Sprache. Es kann allerdings Stellen geben, die nicht übersetzt sind.
Angular auf die Version 19 aktualisiert
Die Abhängigkeiten wurden auf die neusten Versionen aktualisiert
CSV wird standardmässig als UTF8-BOM generiert

Service startet auch bei fehlerhafter Mandantenkonfiguration
Gleichzeitige Reportausführung wieder ermöglicht
Falsch-Interpretation bei null-Werten in GraphQL-Resultat korrigiert
Der Dateiname vom Endpunkt RenderedReport wird anhand des angegebenen Reports und Rendertyps bestimmt
Für die Sortierung verwendete Felder müssen nicht mehr im Report dargestellt werden