Изменить

Поделиться через

Receive-Side Processing of an Incoming Non-EDI Message over AS2

  • Статья

The AS2 pipelines shipped with BizTalk Server can be used to process an EDI message or a non-EDI message over AS2 transport. Different pipelines are used for the two different types of payloads. You use the AS2EdiReceive pipeline to process an incoming EDI message over AS2, and the AS2Send pipeline to return the associated MDN (if enabled). You use the AS2Receive pipeline to process an incoming non-EDI message over AS2, and the AS2Send pipeline to return the associated MDN (if enabled). The non-EDI message can be any binary payload.

The AS2Receive receive pipeline decodes the AS2 message, and then performs disassembly on the AS2 message. An AS2Send send pipeline encodes the MDN. You can include the AS2Receive and AS2Send pipelines in an HTTP two-way solicit response send port (if the MDN is synchronous), or in a one-way HTTP send port and a one-way HTTP receive port (if the MDN is asynchronous). If you need to perform disassembly of a non-EDI payload, you will have to do that in another receive pipeline, because BizTalk Server only allows one disassembler in a receive pipeline. This will require a loopback send port and receive location (see the Processing the Received Non-EDI Payload section below).

To receive a non-EDI interchange over AS2, BizTalk Server will perform the following steps:

  • Processing the received AS2 message

  • Sending an MDN

  • Processing the received non-EDI payload

Processing the Received AS2 message

The AS2 Decoder in the AS2Receive receive pipeline processes an incoming AS2 message. It does so using the InboundHTTPHeaders context property, which the HTTP adapter creates from the HTTP headers in the AS2 message. These headers include the following AS2 headers:

  • AS2-To

  • AS2-From

  • AS2-Version

  • MessageID

  • OriginalMessageID (for MDNs only)

  • Disposition-Notification-To (if an MDN is requested)

  • Receipt-Delivery-Option (if an MDN is requested)

  • Signed-Receipt-MICalg (if an MDN is requested)

    The AS2 Decoder will promote these headers to the context of the message. It then does the following:

  • Performs agreement resolution to determine the properties to be used to process the incoming message. For more information, see Agreement Resolution for Incoming AS2 Messages.

  • Authenticates the sender using the AS2-From and AS2-To properties.

    Note

    For more information about the processing that the AS2 receive pipelines perform on incoming AS2 messages, see Processing an Incoming AS2 Message.

Sending an MDN

If an MDN was enabled, the AS2Receive pipeline generates an MDN and drops it into the MessageBox. How the MDN is returned to the sender of the original message depends upon whether the AS2 transport is synchronous or asynchronous.

Note

For more information about the processing that the AS2 receive pipelines perform on outgoing MDNs, see Generating an Outgoing MDN.

Synchronous Mode

If a non-EDI message is sent over AS2 in synchronous mode, BizTalk Server will return the MDN over that synchronous connection and then close the connection. The MDN will be generated by the AS2Receive pipeline, routed by that pipeline to the MessageBox, and then automatically picked up by the AS2Send pipeline that is part of the request response receive port.

Asynchronous Mode

If a non-EDI message is sent over HTTP/HTTPS transport in asynchronous mode, you must create a send port to return the MDN separately. If it is a dynamic send port, it will use the address in the Receipt-Delivery-Notification line in the header of the message to route the message to the trading partner. If it is a static send port, it will use the address defined in port properties. This send port subscribes to the asynchronous MDN by using an EdiIntAS.IsAS2AsynchronousMDN==True filter expression. In asynchronous processing, the AS2Receive pipeline will generate an HTTP response in addition to the MDN. The receive port returns the HTTP response to the original sender over the HTTP connection between the receive port and the sending party, which closes that connection. This is necessary because the synchronous connection is not closed by the MDN.

Processing the Received Non-EDI Payload

When a message that is not encoded in EDI is received over AS2, and you need to perform disassembly on the payload, you will have to do that in a different receive pipeline than the AS2Receive pipeline. This is required because BizTalk Server only allows one disassembler in a receive pipeline. This scenario will require a loopback mechanism using a send port and receive location. In the first pass, the EDIReceive pipeline processes the AS2 message and sends the message in its native format to the MessageBox. In the second pass, a receive pipeline generates XML from the message's native format.

BizTalk Server will perform the following receive-side processing on a non-EDI message over AS2 BizTalk Server:

  • The AS2Receive receive pipeline associated with the two-way request response receive location parses the AS2 headers from the non-EDI message, and then routes the non-EDI message to the BizTalk MessageBox.

  • A loopback send port (either FILE or MSMQ) picks the non-EDI message up from the MessageBox, because it filters on the BizTalk property IsAS2PayloadMessage == True. The PassThruTransmit send pipeline associated with this send port passes the message through in its non-EDI format, routing the message to either a folder or an MSMQ queue.

  • A loopback receive location picks up the message. The receive pipeline associated with the loopback receive location generates an XML message from the non-EDI message, and routes it to the MessageBox.

  • If the message is to be routed to a back-end application, a send port picks up the XML message and routes it to the application.

See Also

How BizTalk Server Receives AS2 Messages
Send-Side Processing of an Outgoing EDI Message over AS2