You can submit AS2 messages for sending, in several ways:
The Quick-start 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 category.
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 category.
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,
At this point, the message gets moved into the Failed category.
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 AS2
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 (downstreams), using the last-processed data; e.g. re-save the attachments to your SFTP inbox, or reinvoke 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
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-ID is already recorded on their end
These provide different perspectives of your messaging history on AS2 Gateway:
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 (
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)