AS2 Gateway 2.3.6 is now live, with several management and integration enhancements that you may find handy:
Support for sending out large files
As documented officially, our SaaS platform allows sending files up to 10MB in size, in a single message. Over the years we have been receiving several requests from users, asking to increase this limit.
(Of course, in our on-premise product, the maximum file size limits are free for you to decide and tune.)
Now we are happy to announce a new option that would allow you to submit outgoing files exceeding 10MB - as long as they can be compressed to 10MB or less. If you are sending textual files like TXT, CSV, XML, EDI etc., they would usually be highly compressible. Based on past data, some of our production files could be compressed even by 100x; so if you are dealing with files that could possibly exceed 10MB *at some point_, this option might definitely fit your needs.
This feature utilizes the built-in compression capability of AS2 protocol (section 6.1 of AS2 RFC). As long as the remote system supports AS2 version 1.1 or above, it should transparently handle this form of compression without any additional changes; so, apart from enabling the setting on the relevant trading partner on your side, no other changes need to be made - neither on your side, nor in the partner’s remote system. You will continue to submit original/uncompressed files (potentially over 10MB) as usual, and your partner’s AS2 system will output the same “large” files in uncompressed form; actual compression and de-compression will be handled transparently, by the two AS2 systems.
In this mode, when picking a file from file-based integrations like SFTP or AWS S3, AS2 Gateway will first try to compress the file (if it exceeds a predefined size threshold); if the compressed copy is below 10MB, it will enqueue and send the file as usual. (If 10MB is exceeded even after compression, it will reject the file as usual, using the standard mechanisms.)
You can enable the new pre-compression mode for desired partners, using the “Pre-compress input files” option under “AS2 Security” section of the partner settings. Make sure to first enable “Compress messages” option and pick “Before signing and/or encryption” as the “Compression Stage”, in order to make the new option accessible.
In future we hope to further expand support for large files, including the incoming path; stay tuned.
Webhooks enhanced
More event types
You can now configure webhooks to receive notifications for more mesaaging events:
- message sent successfully (MSG_SENT)
- MDN sent successfully for an incoming message (MDN_SENT)
- MDN sending failed for an incoming message (MDN_SEND_FAILED)
These, along with the already supported events, provide full visibility to the lifecycles of all your messages:
- message received (MSG_RECEIVED)
- MDN received for a sent message (MDN_RECEIVED)
- message sending failed (MSG_SEND_FAILED)
Improved error reporting
Earlier we used a single X-Processing-Error header to report both transmission/network errors and AS2-level processing errors.
But now we report transmission errors in a separate X-Transmit-Error header; this allows us to report more details,
for example in case of a send failure of a negative MDN (which involves both types of errors).
We still report transmit errors (for MSG_SEND_FAILED events) on a copied X-Processing-Error header as well - along with a deprecation notice.
We will be discontinuing this and switching completely to X-Transmit-Error in near future,
so we encourage you to remove the dependency on X-Processing-Error for MSG_SEND_FAILED events, as soon as possible.
Enable/disable switches
Earlier if you wanted to disable/pause a webhook temporarily, the only option was to change its mode to “Disabled”; this meant that the originally set payload delivery mode (e.g. “headers-only”) would get lost, and you had to manually track/remember it - and restore that exact mode when re-enabling the webhook.
Now you have a separate enable/disable switch (toggle) for each event type. After configuring a webhook, if you ever want to disable it for some reason, you can simply turn the switch off, and save the configuration - and turn it on again later, when ready - without losing any of the pre-configured parameters.
Account management
We have added some features to ease the management of your AS2 configurations and transactions:
Certificate expiration alerts
If any of your AS2 certificates are expiring recently, we will automatically inform you via email - 1-2 weeks in advance - so that you can make arrangements with your trading partners to perform necessary certificate updates or rotations.
Incomplete message alerts
If any of your messages have not received a MDN receipt - i.e. have been waiting in “MDN pending” status - for over 24 hours, we will automatically notify you via email. An AS2 transaction is not considered as complete, until the partner acknowledges it with a MDN - so a missing MDN almost always indicates a problem and requires manual intervention, and with these new notifications, you can look into such issues without delay.
Similarly, we will alert you if a message stays “stuck” in “sending” or “in-flight” status for too long. This is very rare (has never happened in SaaS) and mainly targets on-premise/dedicated installations, but just be aware that you are covered against any such inconsistencies as well.
With this, you have full visibility to the lifecycle of every message/file, even without having to log in to your dashboard:
- If the file is rejected (not picked up) by an integration, you will receive an email alert.
- If a message gets “stuck” during sending (although highly unlikely), you will receive an email alert.
- If AS2G fails to send a file out, you will receive email and/or webhook alerts.
- Once AS2G sends a file out successfully, you can choose to receive a webhook alert.
Alerts for problematic MDNs
As mentioned above, a successful/positive MDN is essential to close off an outgoing AS2 transaction. To ensure that you are aware of any transaction failures or anomalies, we now issue automatic email alerts for following MDN-related issues as well (in addition to the “pending MDN” scenario mentioned above):
- Negative/error MDN received
- MDN received, but the integrity check (MIC) failed (commonly known as “MIC mismatch”)
- Failed to send a MDN for a received message (preventing the partner from completing the transaction on their side)
Since these alerts are important for identifying unsuccessful/incomplete transactions, they are enabled by default; but if preferred, you can turn them off under advanced settings of your trading station.
Message tagging
We introduced message tags quite some time ago, mainly to facilitate messaging profiles, and to handle regulatory submissions; however there was no way for you to add, modify or remove those tags - and you were missing out on a lot of potential.
From 2.3.6 onwards, we give you full control on message tags; you can add, edit and remove multiple tags on any message as you desire. For example, if you are receiving POs periodically and need to review all of them later-on at once, you can simply tag the corresponding messages with a desired tag (e.g. “PO-review”), and later search your inbox using the same tag text to instantly view all those PO messages/files. You can untag each PO as you make progress, so that you can reuse the same tag name later for another review cycle - without having to manually keep track of the already reviewed ones.
There’s more…
Certificate management
We have several minor enhancements to our certificate store as well:
- Earlier we aborted operations such as partner creation/update, if the user was trying to upload duplicate certificates - or certificates that were previously uploaded and already existing in their store. From now onwards, we will instead ignore such duplicates automatically, and import the rest - without aborting the overall operation. (You will, of course, receive a summary of the certificates that we ignored.)
- You can now view serial numbers of imported/generated certificates, on the UI itself.
- During station and HTTPS identity certificate renewals, you can now replace the entire key pair (public key and public certificate chain. This may not benefit SaaS users much, but it is good news for our on-premise community - especially when they want to replace the self-signed HTTPS certificate (auto-generated by our system) with a proper CA-signed one.
Incoming traffic suspension is now available
In 2.1.4 we announced support for suspending outgoing traffic for any desired partner - without affecting the rest of your account, and with the ability to automatically resume all pending messages when resuming traffic for such a suspended/paused partner.
From 2.3.6 we have unlocked the long-awaited complementary option, to suspend incoming traffic. If your downstream system or integration is encountering issues, or a discontinued partner simply would not stop sending messages to you, this option will reject messages from that partner with a HTTP 423 (Locked) response - without landing them in your inbox.
We believe our new enhancements would satisfy some of your long-awaited needs. Always feel free to drop us a line if you face any issue in using any of the new features, or if you have something cool on your mind!
