Der EntityTransformer hat die neue Option „Auslösen in einer Transaktion“, womit alle aus dem Mapping getriggerten Dokumente in einer Transaktion erstellt werden.
Diese Option sollte mit Vorsicht gewählt werden, z.B. nur dann, wenn nach dem EntityTransformer nur ein EntityMessageCreator folgt maximal noch ein EntityStateSetter. Den größten Vorteil erzielt diese Einstellung, wenn aus einem eingehenden Dokument im Mapping viele Dokumente getriggert werden. Dann erfolgt die Anlage der erstellten Nachrichten, Anhänge, Umschläge und Dokumente mit den Statusinformationen in einer Transaktion. Und die Inserts auf der DB können zu Blöcken (Bulk Inserts) zusammengefasst werden.
Weiter wurden im EntityMessageCreator Zugriffe optimiert, so dass Datenbankabfragen überflüssig wurden.
Die Optimierung lag in dem konkreten Fall bei über 30 Minuten! Wobei es ein Spezialfall war, wo aus einem Eingangsdokument 16.000 Dokumente erstellt wurden. Mit den beiden oben genannten Optimierungen konnte das Anlegen der Nachricht mit den über 16.000 Dokumenten von über 30 Minuten auf unter eine Sekunde optimiert werden.
D.h. aber nicht, dass eBiss jetzt um den Faktor 30 schneller geworden ist. Dieser Anwendungsfall mit den 16.000 Dokumenten ist nicht der Normalfall: Die Optimierungen liegen im 1/10 Sekundenbereich je Ausgangsdokument aus dem Mapping. Meist wird aus einem Eingangsdokument ein Ausgangsdokument erstellt und da machen sich die 1/10 Sekunde im ganzen Prozess von zwei ausgeführten Mappings und der Nachrichtenerstellung nicht so bemerkbar. Jedoch bei 16.000 Ausgangsdokumenten und genau 1/10 Sekunde je Dokument kommt man dann auf 27 Minuten weniger Laufzeit.
Das in der Version 3.8.301 (17.5.24) eingeführte Aufteilen von JSON Nachrichten anhand vom MapTrigger Attribut wurde erweitert um das Überlesen von JSON Inhalten, die nach dem letzten Dokument in der JSON Datei vorhanden sind. Es ist unüblich, dass Teile aus der Datei nicht in den Dokumenten erscheinen, es war aber auf Grund einer Anforderung notwendig. In dem Fall standen am Ende der JSON Datei Informationen, die in keinem Dokument sichtbar sein sollten.
Der EntityRecipientChanger ermittelt über die Teilnehmernummer aus dem gespeicherten Wert („<Teilnehmernummer> - <Name>“) den Partner. Enthielt die Teilnehmernummer Leerzeichen, dann wurde der Partner nicht gefunden. Ein seltener Fall, der nun behoben ist.
Ruft man den EntityRecipientChanger nach dem 'Drehen' der Nachrichtenrichtung durch ein SetFrameVariable('eBiss.DocumentVars.MessageDirection', 'Inbound/Outbound') auf, dann muss die Framevariable „Sender“ gesetzt werden, da erst beim Erstellen der Nachricht im EntityMessageCreator die DocumentVars Werte Sender und Empfänger 'gedreht' werden.
Das Laden der PlugIns erfolgt beim Start vom eBiss im Hintergrund und bisher konnte es vorkommen, dass der EventManager während des Ladens der PlugIns gestartet wurde. Womit z.B. Web-Services oder auch Jobs welche PlugIns verwenden vor dessen Laden ausgeführt wurden damit auf einen Fehler liefen.
Der Fehler wurde behoben, der EventManager wartet nun bis alle PlugIns geladen wurden.
Die Tests mit dem MS-SQL Server 2022 waren erfolgreich und der MS-SQL Server wurde in die Liste der getesteten Datenbanken aufgenommen, siehe Systemvoraussetzungen.
Änderungen an den Systemeinstellungen werden für den ändernden WinClient sofort wirksam und für andere laufende WinClients nach spätestens 30 Minuten.
Mit dem Modul Audit Log können Zugriffe auf Nachrichteninhalte protokolliert werden. Das Audit Log ist nur dann aktivierbar, wenn das Modul Versioning lizensiert ist. Siehe Module.
Bei eBiss Benutzern, welche im Unterknoten definiert sind und denen eine Gruppe aus demselben Unterknoten zugewiesen wurde, trat bei der ersten Anzeige von z.B. Mappings ein Fehler auf und die Liste der Mappings war leer, ohne dass der Fehler angezeigt wurde. Erst bei einer Aktualisierung der Ansicht wurden die Mappings angezeigt. Weiter war ein Debugging von Nachrichten im Mapping nicht möglich. Dieser Fehler ist behoben.
Beim GroupByEx wird das Ergebnis in einem neuen Typen gespeichert, in dem Typen: eBiss.ClassLib.Maps.MappingFunctions.Result. In diesem Typen wird das Ergebnis von GroupByEx zurückgegeben. Damit sind die CustomObjects unter einem anderen Typ-Pfad gespeichert im Vergleich zum Quellobjekt, weswegen die über MapCustomTypeAttribute definierte Zuordnung nicht mehr passend und das CustomObject in Mapping nicht sichtbar ist. Ab dieser Version wird ein Error Log ausgegeben mit der Information, mit welchen beiden MapCustomTypeAttribute-Definitionen der Typ zu dem CustomObject versehen werden muss, damit das CustomObject auch nach dem GroupByEx verwendet werden kann.
Die Fehlermeldung beim Landen einer EDIFACT Datei „Field size violation at …“ wurde geändert in „Field size limit of x was exceeded by z characters at …“
Z.B. statt:
Wird jetzt ausgegeben:
Beim Erstellen von ganzen Regelbäumen über Drag & Drop wurden für einfache Felder keine Regeln erstellt, wenn Quelltyp und Zieltyp unterschiedlich waren, z.B. von „Ganzzahl (long)“ auf ein „Nullable Numeric“, von String auf „Ganzzahl (long)“ etc..
Das wurde geändert, solange die Feldnamen gleich sind wird eine Regel erstellt.
Trat beim Dateiempfangskanal der Fehler auf, dass die abgeholte Datei nicht verschoben werden konnte, dann außerte sich das in dem Fehler:
Das wurde behoben und es wird jetzt nur noch der Task mit z.B. „Couldn't move or handle the Message…“ erstellt.
Die Log-Ausgaben sind generell je Ausgabe auf 8.000 Zeichen beschränkt. Bei den Debug Log-Ausgaben kann es aber sinnvoll sein mehr Zeichen auszugeben, um zum Beispiel den Inhalt einer über einen Web-Service erhaltenen Datei zu protokollieren. Daher wurde die Debug Log-Ausgabe auf die Ausgabe von bis zu 500.000 hochgesetzt.