You can submit AS2 messages for sending, in several ways:
The User Guide contains step-by-step instructions on how to send a message.
Each submitted outgoing message is added to a queue, and appears under Outbox. AS2 Gateway usually sends the message out within 5-10 seconds, upon which it gets moved into the Sent mailbox.
If you do not specify a MIME type (Content-Type) during submission, such as during SFTP uploads and composing from the web console, AS2G will auto-detect the type by file extension - and by content (EDI sub-types for files with “.edi” extension) - and include it in the message.
If the message sending fails, the next step depends on the nature of the failure:
- If the failure is temporary:
- a temporary network issue (e.g. partner endpoint is not accepting incoming traffic), or
a temporary/transient error response returned by the partner system/endpoint (e.g. HTTP 500/503 indicating a server fault),
AS2 Gateway continues to retry your message automatically - with increasing wait times; starting at 5 seconds by default, and spanning to ~1h.
During this phase, the message appears under the Queued mailbox.
If the failure is:
- permanent (e.g. the partner endpoint returns a rejection response, such as a HTTP 400 bad-request error), or
temporary, but the automatic retries for the message (10 by default) are exhausted,
AS2 Gateway stops the automatic retry process - and informs you of the failure if failure notifications are configured; e.g. email or webhook.
At this point, the message gets moved into the Failed mailbox.
When you want to send several types of messages - with slight variations - to the same partner, you can use profiles.
Each profile contains a set of additional parameters (or overrides), that gets applied to the submitted message during sending. A common use case is routing using HTTP headers; for example, if your partner’s trading system has one AS2 ID but several sub-systems, your partner may require you to set an additional HTTP header to indicate which subsystem is the intended final recipient. A very popular real-world example is routing messages to different submission centers of FDA.
You can add and edit message send profiles under the Submission Profile option on the ‘Compose Message’ page:
Afterwards, you can pick the desired profile when sending a message, to apply the respective configurations (e.g. HTTP headers) to the outgoing message - on top of the recipient partner’s configuration settings. If you do not pick/specify a profile, the message gets sent using just the partner-level settings.
- Profiles currently allow you to configure HTTP request headers. If you would like AS2 Gateway to support other types of configurations, please write to us with details.
- If you have also defined partner-level custom HTTP headers, both sets of headers will be merged. In case of conflicts (headers with same name/key found in both sets), profile-level headers will take precedence. This allows you to define a generic header value at partner level (to cover several scenarios), and configure a profile to override the value - to use in just one or a few specific submissions.
AS2 Gateway offers 4 main message views:
- Received: your AS2 inbox
- Sent: AS2 messages sent out from your account
- Queued: AS2 messages that AS2 Gateway is currently processing (sending out), including those being retried due to previous failures
- Failed: AS2 messages that permanently failed to be sent out - due to network issues (maximum retry count reached) or being actively rejected from the partner’s end (received HTTP error status codes)
Except for Received, the other views can collectively be considered as your “outbox” (successful, in-progress and failed sends).
The other two list views, Failure Log and Timeline, are described under supplementary views.
Each view has some common functionalities:
- view details of the message (by clicking the subject line of the corresponding row)
- download all attachments associated with the message
- delete the message entry, or select and bulk-delete several of them
- additional actions, such as copying the
Additional view-specific actions are also available:
- re-process or replay the message, based on the originally received AS2 metadata (headers) and payload; this can be useful if your initial settings for the sending partner were incorrect, but now you have corrected them and would like AS2 Gateway to try to process the message again - without waiting for your partner to re-send it.
- redeliver the message to any of your enabled integration channels (downstream), using the last-processed data; e.g. re-save the attachments to your SFTP inbox, or re-invoke the matching webhook with details of the message
- in case an MDN could not be sent back to the sender (partner), try to resend the MDN - optionally changing the target async-MDN URL (e.g. if the original MDN was supposed to be synchronous, or if the async-delivery URL mentioned on the original message was incorrect)
- re-send the message as a new AS2 message (optionally with a new
Message-ID), using the same subject and attachments (files) as in the original message
- replay the message exactly as it was sent out before - using the same metadata (headers),
Message-ID, and previously composed payload (regardless of any changes made on your partner/station settings, after the original message was sent out); useful if you want to find out the last known good configuration, when the message flow is broken after you made some configuration changes
- retry the message if the automatic retry process has stopped; or stop retrying if it is already in progress
- refresh the AS2 identifier of the message, so that the receiving end (partner) can see it as a new transaction; useful in cases where a previous transaction was interrupted, and the partner’s system is rejecting further retry attempts because the current
Message-IDis already recorded on their end
- retry the message, which moves it back to Queued - optionally with a new
These provide different perspectives of your messaging history on AS2 Gateway:
This is a list of all your message send failures, including retry attempts.
This is a complete trail of messages that you have received and sent (or failed during sending).
You can filter this view based on various parameters, to get a unified list of incoming and outgoing messages that match the filter. For example, if your incoming and outgoing messages are tagged by the same transaction/submission ID (e.g. the CoreID in case of an FDA submission), you can view the full trail of a single transaction by either:
- entering the full transaction ID into the search box, or
- clicking the transaction ID tag on a single message that belongs to the transaction (which automatically performs the search/filtering on your behalf)
Note that, if a message got retried due to send failures, the Failure Log and Timeline views will show one entry for each retry attempt. The original submission may also be visible under Outbox or Failed, depending on whether the retry is still in progress, or was cancelled (automatically or manually).
For example, if you
- received a message,
- composed and submitted a response message,
- but the response failed to be sent - even after 3 retries,
- and you manually stopped the message after the third retry,
you would see:
- 1 message in Inbox
- no messages in Sent (because none of the send attempts were successful)
- no messages in Outbox (because there are no pending/active submissions at the moment)
- 1 message in Failed (the submission that you stopped retrying)
- 3 messages in Failure Log (the 3 unsuccessful send attempts)
- 4 messages in Timeline (1 incoming + the 3 unsuccessful send attempts)
This view offers more details of each message entry; including
- AS2 message identifier (
- sent/received/queued date
- included attachments (files)
- message subject (
for sent/received messages,
options to view/download:
- the original HTTP protocol (transport) headers
- the raw AS2/MIME payload that was sent/received
- headers and content of the MDN receipt that was received/sent
for sent messages:
- HTTP-level response status code received during the send operation
- error summary, if the partner responded with an error (negative) MDN
for received messages:
- error summary; if AS2 Gateway failed to process/validate the received content, and sent back an error (negative) MDN
for send-failed (queued/stopped) messages:
- error received during the last send attempt
- a link to view the list of previous failures of the message (queue entry) delivery; this would contain as many entries as the number of times the message was retried (maximum 10 by default)