The EntityTransformer has the new option “Trigger in a transaction”, whereby all documents triggered from the mapping are created in a transaction.
This option should be selected with caution, e.g. only if the EntityTransformer is followed by an EntityMessageCreator and a maximum of an EntityStateSetter. This setting achieves the greatest advantage if many documents are triggered from a mapping from an incoming document, then the created messages, attachments, envelopes and documents are created with the status information in a transaction. And inserts on the DB can be combined into blocks (bulk inserts).
Furthermore, accesses were optimized in the EntityMessageCreator so that database queries became superfluous.
In this specific case, the optimization took over 30 minutes! This was a special case where 16,000 documents were created from one incoming document. With the two optimizations mentioned above, the creation of the message with over 16,000 documents could be optimized from over 30 minutes to less than one second.
However, this does not mean that eBiss has now become 30 times faster. This use case with the 16,000 documents is not the normal case: The optimizations are in the 1/10 second range per outgoing document from the mapping. In most cases, an output document is created from an input document and the 1/10 of a second in the entire process of two executed mappings and message creation is not so noticeable. However, with 16,000 outgoing documents and 1/10 second optimization per document, this results in 27 minutes less runtime.
The splitting of JSON messages based on the MapTrigger attribute introduced in Version 3.8.301 (17.5.24) has been extended to read over JSON content that exists after the last document in the JSON file. It is unusual for parts from the file do not appear in the documents, but it was necessary due to a request. In this case, there was information at the end of the JSON file, that should not be visible in any document.
The EntityRecipientChanger uses the participant number to determine the partner from the stored value (“<participant number> - <name>”). If the participant number contained spaces, the partner was not found. A rare case that has now been fixed.
If you call the EntityRecipientChanger after changing the message direction using a SetFrameVariable('eBiss.DocumentVars.MessageDirection', 'Inbound/Outbound'), then the frame variable “Sender” must be set, as the DocumentVars values Sender and Receiver are only 'rotated' when the message is created in the EntityMessageCreator.
The PlugIns are loaded in the background when eBiss is started and until now it could happen that the EventManager was started while the PlugIns were being loaded. This meant that, for example, web services or jobs that use PlugIns were executed before the plug-ins were loaded, resulting in an error.
The error has been fixed, the EventManager now waits until all PlugIns have been loaded.
The tests with the MS-SQL Server 2022 were successful and the MS-SQL Server was added to the list of tested databases see System requirements.
Changes to the System settings take effect immediately for the changing WinClient and after 30 minutes at the latest for other running WinClients.
The Audit Log module can be used to log access to message content. The audit log can only be activated if the Versioning module is licensed. See Modules.
For eBiss users who are defined in the sub-node and who have been assigned a group from the same sub-node, an error occurred when mappings were displayed for the first time. Error occurred during view mappings and mappings view was empty without the error being displayed. Only when the view was refreshed the mappings were displayed. It was also not possible to debug messages in the mapping.
This error has been fixed.
With GroupByEx, the result is saved in a new type, in the type: eBiss.ClassLib.Maps.MappingFunctions.Result. In this type, the result of GroupByEx is returned in this type. This means that the CustomObjects are stored under a different type path compared to the source object, which is why the mapping functions defined via MapCustomTypeAttribute is no longer suitable and the CustomObject is not visible in Mapping. As of this version, an error log is output with the information of the MapCustomTypeAttribute definition needed for the CustomObject so that the CustomObject can also be used after the GroupByEx.
The error message when landing an EDIFACT file “Field size violation at …” was changed in “Field size limit of x was exceeded by z characters at …”
So that, for example, instead of:
the following message is displayed;
When creating entire rule trees via drag & drop, no rules were created for simple fields if the source type and target type were different, e.g. from “Integer (long)” to a “Nullable Numeric”, from String to “Integer (long)” etc..
This has been changed, as long as the field names are the same, a rule is created.
If the error occurred on the file receiving channel that the retrieved file could not be moved, this was reflected in the error:
This has been fixed and now only the task with e.g. “Couldn't move or handle the Message…” is created.
The log outputs are generally limited to 8,000 characters per output. However, it may be useful to output more characters in the debug log output, for example to log the content of a file received via a web service. For this reason, the debug log output has been increased to up to 500,000.