Use of Message Disposition Notifications

A message disposition notification (MDN) is a receipt document that contains the original message ID of a message and status information about the original message. EDIINT is a family of protocols developed by the Internet Engineering Task Force (IETF) for securely packaging and transporting messages containing business data over the Internet, using S/MIME.

MDNs that conform to the EDIINT specifications can contain a cryptographic hash calculated over the content of the message after EDIINT processing. An MDN can be either:

  • Signed – Contains an encrypted digital signature of the receiver.
  • Unsigned – Contains only the original message ID and not a digital signature.

Signed MDNs that conform to the EDIINT specifications can provide acknowledgement of receipt in addition to message status information. A valid digital signature over an EDIINT MDN shows that the MDN was sent by the trading partner possessing the relevant key pair. It also shows that the signed area of the MDN (which includes the cryptographic hash calculated over the received content) was not altered after signing. A message sender compares the hash in the MDN with the hash calculated when the message was generated. If the hashes match, the sender knows that the receiver received the content and has the MDN to demonstrate the status.

Whether signed or not, MDNs do not show that the received message content conforms to EDI or other business document formatting requirements.

MDNs are sent asynchronously in which they are returned at a later time during a different communication session. For example, A initiates the connection to B and drops the data for delivery to B. A closes the connection and does not wait for an MDN from B during the same communication session. In a later session, B initiates a connection to A, and sends an MDN to A. When the MDN is delivered, B closes the connection.

The majority of the AS3 functionality in Sterling B2B Integrator requires the use of the Mailbox features. Therefore, you must purchase the Mailbox license to use AS3 in the Sterling B2B Integrator. For inbound AS3 messages, payloads are extracted and stored in a designated mailbox. The payload will only be stored in the mailbox upon successful delivery of the MDN (if required) to the trading partner. For outbound AS3 message exchanges, payloads are encapsulated within the MIME or S/MIME message and sent to the trading partner.

The Bulk Message Generation feature allows you to enable the schedule of the business process to collect payloads from a specified folder, create an AS3 message, and send it to the intended trading partner. Sterling B2B Integrator supports initiating AS3 message exchanges in a scheduled manner. The option of searching a specified folder for any files present within it or matching a file pattern is configured when you create an AS3 contract.

A system generated business process is created and added to the schedule. This schedule is enabled if the option to enable it was selected during the configuration of the Bulk Message Generation option. The scheduled business process is written to collect the documents from a specified folder and invoke a business process containing the AS3 Build service to create the AS3 message and initiate a message exchange with the trading partner as specified in the AS3 contract.

To prevent system performance degradation that may occur if there are too many files to process at once or if the system keeps trying to send AS3 messages to an unavailable FTP Server, Sterling B2B Integrator allows you to throttle the AS3 message exchange rate by limiting the number of message exchanges per cycle and to schedule optimal cycle periods that the system can handle. You can also throttle the AS3 message exchange rate by limiting the number of files to be picked up. Using throttling, if an FTP Server is down or too busy to accept any new connections, Sterling B2B Integrator sets a temporary lock on the AS3 contract and suspends message transmission for the period of time you specify. If the lock is enabled, Sterling B2B Integrator does not initiate any message exchange even when the schedule is executed, and only initiates a message exchange when the lock is disabled from the AS3 contract. This ensures that system resources are not wasted in attempts to connect to an unavailable FTP Server.

Sterling B2B Integrator also allows you to configure a maximum retry count for sending AS3 message and MDNs. This connection retry logic covers all possible transmission errors such as server unavailability, authentication failures, handshake failures, network surge during data transfer, generic file system errors, and so forth. If you enable the retry option, a retry attempt is executed if a failure is encountered at any stage of the transmission process for a message or MDN.

Sterling B2B Integrator ensures that MDNs have been sent to a trading partner before an AS3 payload is placed into the PAYLOAD mailbox to be processed by the business process. If the MDN was not sent, the payload is not placed into the PAYLOAD mailbox. Instead, it is placed into an Error mailbox for tracking only, and subsequent messages from that trading partner as a result of the failed MDN are not recorded as a Duplicate entry, but are considered to be a new message.

Note: This happens only if the Sender requests for an MDN for the message sent. A Sender can also send messages without requesting for an MDN.

AS3 messages having a message identifier that is already recorded in Sterling B2B Integrator are considered to be a duplicate if the payload of the original message was placed into the PAYLOAD mailbox. MDNs are either sent directly to a trading partner, or are placed in an outgoing mailbox for the trading partner to pick up within a specific time period.