eBiss 3

From this version onwards, messages containing sensitive data can be can be given special protection. To this end, two approaches have been implemented in eBiss:

• “audit-proof” can be excluded from global access and
• Messages can be encrypted.

If a node is defined as “audit-proof”, only users from that specific node have access to it. Even administrators from other nodes have no access, neither to the node itself nor, for example via the global search, to elements within the node. The “audit-proof” property is set in the node type. This is only possible

• for a user with admin rights from that specific node and
• if there are no sub-nodes.

!!! This setting cannot be undone.

From this version of eBiss onwards, messages can be encrypted. To do this,

• the eBiss system must have been enabled for encryption using the eBiss configurator, and
• a key file must be stored on the server.

The administrator can then set a message basket to “Encrypted”. This setting cannot be undone!

All messages created in this message basket will then be encrypted and remain so, even if they are moved to another message box.

The ‘Message store’ access right, and specifically ‘View encrypted’, can be used to control which users can read encrypted messages. A user without this permission cannot open or save an encrypted message. Nor can they open it in a mapping or start a job.

The Job-Steps RestGet, RestGetHandleDocument, RestPush, and RestPushHandleDocument have been expanded to include:

• the direction of the message being sent or received,
• the system partner of the message being sent,
• the trading partner of the message being sent, and
• the authentication method to be used.

see: Rest Job-Steps, OAuth2, Misc..

In the Bearer token request, the parsing of the received JSON has been extended to include the detection of tokens located within the “data” sub-structure, such as:

   { "data": { "token":"…."} } 

For more information on the identified bearer token structures, please visit Rest Job-Steps, OAuth2, Misc..

Instructions for Setting Up OAuth Client Authentication via Microsoft 365 with eBiss of the SMTP send channel and POP3 receive channel have been revised.

Till now, overflow handling in EDIFACT read component had been applied to segments within segment groups only, but not to top-level EDIFACT segments (e.g., not to DE_9308 under SG_37.SEL). This error has been fixed.

Furthermore, starting with this eBiss version, a warning is logged when EDIFACT values are truncated.

A new send channel for transferring messages to Azure Blob Storage has been added.
The channel enables storing messages in a configurable storage account and container.
Azure Blob Storage Send Channel

The eBiss website has been updated to include article subscriptions of article details, on the EAN level. This means that it is now possible to select individual EANs via the eBiss website and send them to a partner in a PRICAT message.

In the Harddisk receive channel, you can now use masks for the Move to path field, allowing e.g. files to be moved to a month-specific subdirectory, using:

• .\Messages\Moved\${fn:ActualDateTime(“yyyyMMdd”)}

In the AS2 send channel, you can now use masks for the “Accepted SSL Certificate” field.

The “Accepted SSL Certificate” refers to the https address in the URL, which is why the field

• has been placed below the URL,
• is hidden when a template is used and
• must be defined in the EDInt address.

If a variable is used for the Signing Certificate File, the Subject cannot be determined in the UI. However, the Subject is required when using the certificate, not always, but for example with certain PFX files. Which is why, in the case of a variable in the Signing Certificate File, the Subject is read from the certificate after variable substitution during runtime and output to the debug log.