AS2（Applicability Statement 2）是在互联网上安全可靠地传输数据的标准规范。它通过使用数字证书对传输的信息进行签名、加密保障传输数据的安全性。

AS2通常采用HTTP或HTTPS协议，一般使用“POST”方法向对方发送数据。

AS2规定了一组标准，来规范通讯双方通过HTTP协议安全的交换数据。

这组标准包含了如果对消息进行数字签名来确认发送放的身份，如何对数据加密来保证数据的安全性，在发送方发送了消息后接收方接收到是否要返回MDN（Message Delivery Notification），以及MDN是同步返回还是异步返回。

一、  BizTalk对AS2的支持

BizTalk对提供 AS2 支持的固有功能，它不是产品的外接程序，例如适配器或加速器，它内置于产品之中。

1、BizTalk Server提供的AS2功能

BizTalk Server 使用 AS2 定义方法来发送、接收和验证消息。 BizTalk Server 有助于确保通过加密、签名和压缩的数据传输的安全性。 BizTalk Server 使用加密密钥、数字签名和证书来实现这一目的。

通过 BizTalk Server，你可以将传入和传出的 AS2 消息保存在不可否认的存储位置。包括在保存编码或解码的 AS2 消息和保存 MDN 时，都需这么做。

BizTalk Server 提供了将附件文件名保留为 AS2 消息的一部分的能力。

BizTalk Server 使你能够检查重复的传入消息。

既可以通过与确认消息时使用连接相同的连接同步返回 MDN，也可以通过不同的连接异步返回 MDN。

如果在指定时间段内未接收到 MDN，你可以重新发送 AS2 消息。

BizTalk Server 可提供特定于 AS2 的状态报告。这些报告提供了 AS2 传输的全面状态，其中也包括与交换有关的确认状态。

AS2 要求在接收端和发送端均使用 HTTP 适配器。

BizTalk Server 使你能够通过定义每个协议的证书来覆盖 AS2 消息的默认签名证书。

2、AS2跟EDI的关系

EDI也是BizTalk的內建功能，而且两者经常一起使用，所以有必要理一下AS2和EDI两者之间的关系。

AS2是一个通讯标准，给交换数据的双方提供安全的通讯环境，它只保证通讯双方的数据在公网上安全的传输，并不关心数据本身是什么。打个比方，AS2就是在双方之间构建了一条全封闭的高速公路，保证双方在这条路上跑的各种各样的车能安全可靠的到达对方。

EDI是电子数据格式的标准，是用来定义数据本身的，遵循同样EDI标准的双方能够理解对方的数据，知道对方数据的业务含义。对应AS2好比是建好了安全的告诉公路，EDI就是定义了在可以在这条路上跑的一种标准规格的车辆。

安全高速路上可以跑各种车，既可以跑EDI这样的标准规格的车，也可以跑任何其他类型的车。反过来，EDI标准的车可以跑在AS2这个安全高速路上，也可以跑在其他安全或不安全的高速路或者国道甚至乡间小路。

可见AS2和EDI之间只是一种路和一种车之间的关系，他们可以结合在一起用，也可以毫不相关。

二、  配置证书

证书可以购买也可以自己签发，一般商业环境最好使用从权威证书颁发机构购买的证书。如果使用自签发证书可以参考附录一《申请证书》

1、为AS2配置证书

2、SSL证书配置

如果AS2双方协商使用SSL传输数据（实际上很大程度没必要使用SSL，因为AS2协议本身就能使用加密签名机制保证信息传输的安全性了），Biztalk作为发送消息和接收消息时会分两种情况。

2.1.                BizTalk作为服务端接收partner的消息

Biztalk作为服务端，是使用IIS作为http的接收服务器，所以服务端的SSL证书就是在IIS中设置SSL证书。

2.2.                BizTalk作为客户端向partner发送消息

使用Http发送端口使用SSL向partner发送AS2消息。

2.2.1.   服务端证书

如果服务端不需要验证客户端（即不需要客户端证书），http发送端口除了把URL设置为服务端要求的https的URL，不需要安装服务端ssl证书（SSL协议会自动将服务端SSL证书交换到客户端）。

待确认：

服务端证书的上级颁发机构的证书是否需要保存到Local Computer的Trhusted Root Certification Authorites和Intermediate Certification Authorites

2.2.2.   客户端证书

如果服务端需要验证客户端（即需要客户端证书），发送端口需要指定客户端证书（带私钥的证书），客户端证书安装位置：Current User/Personal

发送端口指定SSL客户端证书：

如果不正常，可以试试把证书再加入到： Local Computer/Personal store

三、  反向代理

有的公司对安全规定比较严格，BizTalk server不允许直接接触外网和配置外网IP，这就导致biztalk的HTTP接收端口不能直接放在公网上接收客户发送的消息，需要有个在DMZ区域的中转服务器的HTTP接收端口接收请求后，再转发到内网的biztalk HTTP接收端口。

解决方案就是，在DMZ区的中转服务器上使用反向代理，将收到的HTTP请求转发到内部IP的biztalk server的http接收端口。微软的Request Routing Version就是一款合适的Reverse Proxy软件。

1、安装ARR

反向代理软件下载：

• Microsoft Application Request Routing Version 2 for IIS 7 (x86) here.
• Microsoft Application Request Routing Version 2 for IIS 7 (x64) here.

安装后，看IIS界面，三个红框框出来的就是安装ARR后多出来的，这个URL Rewrite就是我们需要的请求转发功能：

一般会给每个AS2的partner设置一个IIS的Application处理相应partner的http请求转发。

2、新建Application Pool

为partner新建一个Application Pool：

注意：

在服务器上只安装了framework2.0的时候，Pipeline mode必须选Classic，否则ARR将不工作。

在这个Application Pool的Advanced Settings…中修改：

修改Idle Time-out (minutes)，从默认的20分钟修改为0，即空闲再多时间也不回收此Application Pool。

修改Regular time intervals（in minutes），从默认的1740分钟修改为0，即不设置固定多长时间后回收此Application Pool。

3、新建IIS Application

为这个partner新建一个IIS Application，Application Pool选前面新建的那个Pool：

选择Partner Application，在Features View中选择“URL Rewrite”设置请求转发：

在右侧的“Actions”面板里，点击“Add Rules”：

在Inbound rules下选择“Blank rule”，新建入站规则：

相关设置说明：

Pattern – 匹配入站URL的pattern，一般用正则表达式进行匹配。这里设置(.*)表示所有入站http请求的URL都转发。对于本例的情况，外部partner发送AS2请求的URL应该是：http://external-ip/PartnerName/BTSHTTPReceive.dll?para1=xxx&para2=yyy，红色部分就是用来匹配的Request URL。

Action Type – 表示对匹配后的URL请求的处理方式，这里选“Rewrite”，把请求重写。

Rewrite URL – URL的重写地址。对于本例，转发到内网biztalk的URL是：http://internal_ bizsrv/PartnerName/{R:1}，最后大括号里的R:1表示前面Request URL匹配到的URL，转发的实际URL应该就是：http://internal_bizsrv/PartnerName/ BTSHTTPReceive.dll?para1=xxx&para2=yyy

四、  IIS配置BizTalk接收位置（BTS ISAPI 筛选器）

要使用BizTalk的HTTP接收端口，必须在IIS做相应配置，使BizTalk的HTTP的接收位置可以跟IIS接收的http消息关联起来。

在BizTalk服务器上的配置IIS，一般每个partner设置一个IIS Application，分别设置每个partner的ISAPI。

1、新建Application Pool

为partner新建一个Application Pool：

在这个Application Pool的Advanced Settings…中修改：

Enable 32-Bit Applications 需要设置为true。

Identity需要设置为在BizTalk Isolated Host Users组的账号。

2、新建IIS Application

为partner建立一个IIS Application，一般在Default Web Site下建：

Application Pool选择前一步骤新建的那个Pool。

Physical path设置为：C:\Program Files (x86)\Microsoft BizTalk Server 2010\HttpReceive

在这个Application的Features View中，双击“Handler Mapping”，在右边的Actions面板里选择“Add Scritp Map…”：

在“Request path”字段中输入 BtsHttpReceive.dll。

在“Excuteable”字段中，单击省略号 (…) 按钮，导航到C:\Program Files (x86)\Microsoft BizTalk Server 2010\HttpReceive，选择 BtsHttpReceive.dll。

在 Name 字段中输入“BizTalk HTTP Receive”。

然后单击“Request Restrictions…”，选择“Verbs”选项卡，然后选择“One of the following verbs”。输入“POST” 作为谓词:

五、  通用设置

1、日志report和NRR数据记录

1.1.                日志report

如果想要AS2的消息状态在BizTalk console的AS2 Message and Correlate MDN Status中查看到相关Aggreement的AS2消息状态的日志report，需要如下设置：

Agreement里的General--Common Host Setting--Turn ON reporting打钩，那么MDN消息记录将会被记入以下两个表：bam_AS2MessageActivity，bam_AS2MdnActivity

1.2.                NRR数据记录

如果Agreement的单向协议中没有Local Host Settings -- Sender（Receiver） Message Tracking（NRR）没设置，则AS2消息或MDN的消息内容不会记入此表。bam_AS2MessageActivity表的MessagePayloadContentKey、MessageWireContentKey字段和bam_AS2MdnActivity表的MdnPayloadContentKey、MdnWireContentKey字段也会为空。

六、  接收方MDN生成过程

MDN是在接收方的AS2EDIReceive 或 AS2Receive 接收管道的拆装器管道组件中生成的，生成过程如下：

1、确定是否返回MDN、MDN同步还是异步、MDN是否要求签名

如果接收方的Process inbound MDN into MessageBox for routing/deliver opetions勾选了，Agreement里的设置覆盖发送方HTTP Header里的设置。所以分两种情况来确定MDN是否同步：

1.1.                依据HTTP Header的设置：

如果HTTP请求中Disposition-Notification-To 和Receipt-Delivery-Option标头都没有，表示发送方不需要返回MDN。

如果HTTP请求中有Disposition-Notification-To标头（值无关紧要），Receipt-Delivery-Option标头没有，表示发送方需要同步返回MDN。

如果HTTP请求中有Disposition-Notification-To标头（值无关紧要），也有Receipt-Delivery-Option标头（表示异步返回MDN的URL），表示发送方需要异步返回MDN。

disposition-notification-options标头指示MDN的签名行为。比如：

Disposition-Notification-Options:

signed-receipt-protocol=required,pkcs7-signature;

signed-receipt-micalg=required,sha1

其中signed-receipt-protocol键指示MDN是否需要签名，signed-receipt-micalg键指示MDN签名算法。

1.2.                依据Agreement的设置：

在“发送方à接收方”单项协议中， Acknowledgements(MDNs)中设置：

如果没有勾选了“Request MDN”，表示发送方不需要返回MDN。

如果勾选了“Request MDN”，但是“Request asynchronous MDN”没有勾选，表示发送方需要同步返回MDN。这时，“Disposition-Notification-To”必须填有值（值是什么无关紧要）。

如果勾选了“Request MDN”，“Request asynchronous MDN”也勾选，表示发送方需要异步返回MDN。这时，“Disposition-Notification-To”必须填有值（值是什么无关紧要），Receipt-Delivery-Option(URL)填入异步返回MDN发的URL。

如果勾选了“Request signed MDN”，表示MDN需要签名。这时，Signing Algorithm需要选择签名算法SHA1或者MD5。

2、接收管道生成MDN消息过程

接收管道生成MDN消息，是消息体内容为空，但是带有很多指示如何生成MDN消息的属性的消息。

2.1.                生成的主要属性

2.1.1.   OriginalMessageId

原始AS2消息的MessageID，从入站消息的HTTP Header中获得。

2.1.2.   EdiIntAS.DispositionMode

表示AS2消息接收处置方式，一般此字段置为：automatic-action/MDN-sent-automatically，表示MDN是自动处理并发送的。

2.1.3.   EdiIntAS.DispositionType

这个属性最为重要，这个属性的值其实包含三个部分：

MdnDispositionType -- 表示AS2消息的接收处置结果，可能的值有：

    Processed = 1

    Failed = 2

DispositionModifierExtType -- 表示附加的接收处置结果，可能的值有：

    Not Valued = 1

    Error = 2

    Warning = 3

DispositionModifierExtDescription-- 表示附加的接收处置结果的进一步说明，可能的值有：

    Not Valued = 1

    Authentication Failed = 2

    Decryption Failed = 3

    Insufficient MessageSecurity = 4

    Integrity Check Failed = 5

    Unexpected Processing Error = 6

2.1.4.   MicHashAlgorithm

原始AS2消息MIC哈希算法（Biztalk做为发送方时，发送的AS2消息的MIC哈希算法没有选择，只有sha1），根据入站AS2消息的HTTP标头Content-Type中的micalg键确定，如果没有这个标头默认使用sha1

2.1.5.   ReceivedContentMic

根据MIC的算法，对接收到的原始AS2消息进行哈希计算，如果消息是加密的解密后做哈希。

2.1.6.   EdiIntAS.IsAS2AsynchronousMDN

如果是同步MDN，此属性设置为false

如果是异步MDN，此属性设置为true

2.1.7.   MDNAsyncURI

包含 Receipt-Delivery-Option 值，该值用于发送异步 MDN 响应消息。如果异步MDN发送端口是动态的，它将基于这个属性确定发送URL。

2.2.                根据消息属性组装MIME格式的MDN消息

根据前面步骤生成的消息属性（升级的或没有升级的）组装MIME格式的MDN消息体。

MDN消息的格式参看后面章节中《MDN不签名》消息样例。

不签名的MDN的MIME格式消息由两部分组成，由MIME的boundary符分割。

2.2.1.   MDN消息第一部分

这部分的主要内容就一个，接收方设置的MDN文本，设置位置在：

接收方Agreement中“发送方à接收方”单向协议的“Local Host Setting – Receiver MDN Setting—MDN Text”中设置的文本，一般是说明性的文字，表示是谁返回的MDN等。

2.2.2.   MDN消息第二部分

第二部分主要内容有三个：

A )  原始AS2消息的MessageID

在MDN消息中形式如下：

Original-Message-ID: <BIZSRV-2_1C32C2AA-4A0D-4944-A425-801D4E5CD793>

从MDN消息的OriginalMessageId属性获得值。

B )  消息接收处置结果

DispositionMode和DispositionType属性，在发送管道会被组装到MIME格式的MDN消息中的Disposition中，比如：

第一段蓝色底线部分是属性DispositionMode，第二段蓝色底线部分是属性DispositionType，DispositionType属性又分为三部分：

第一段绿色底线是MdnDispositionType，

第二段绿色底线是DispositionModifierExtType，

第三段绿色底线是DispositionModifierExtDescription，

这三部分的值对应到bam_AS2MdnActivity_Completed数据表的相应的三个字段。

C )   原始AS2消息的MIC哈希值

消息的ReceivedContentMic和MicHashAlgorithm属性组装Received-Content-MIC，比如：

Received-Content-MIC: IhpgpyGz330b6V/lb2gEvHHAbJ4=, sha1

2.3.                创建AS2/MDN状态记录和组装MDN消息保存到NRR数据库

如果解密、验证签名阶段没有出错，接收管道将创建AS2/MDN状态记录写入到bam_AS2MessageActivity_Completed数据表（如果Agreement里设置了需要AS2/MDN状态报告Turn ON Reporting），并组装MIME格式的MDN消息保存到NRR数据库（EdiMessageContent表，如果设置了接收到的MDN保存NRR数据库）。

如果解密或验证签名阶段出错，接收管道不生成AS2/MDN状态记录，也不组装MIME格式的MDN消息保存NRR数据库。

2.4.                接收管道路由MDN消息

无论接收到的AS2消息在接收管道中解密和验证签名是否成功，接收管道都要生成MDN消息（BizTalk MDN消息，只有属性没有body内容）发布到MessageBox（除非设置不需要返回MDN），同步情况下有接收端口的发送部分订阅，异步情况下由一个单独的单向HTTP发送端口订阅。

3、发送管道组装MDN消息过程

同步MDN时的接收端口的发送部分，异步MDN时的单独HTTP单向发送端口订阅了MDN消息后，在发送管道组装MIME格式的MDN消息返回给AS2消息发送方，如何组装MIME格式的MDN消息参看《根据消息属性组装MIME格式的MDN消息》。

注意：

接收管道中组装MIME格式的MDN消息保存到NRR和发送管道中组装MIME格式的MDN消息是两个独立过程，所有生成的MDN消息会有一些差异，表现为MIME的.boundary和MIME消息每一部分的Content-ID不同，参看《订阅同步返回的MDN消息的发送端口》后的第二个注意部分。

七、  AS2数据和MDN数据的样例

1、AS2消息

1.1.                AS2消息不签名不加密

不签名不加密的AS2消息，除了HTTP header，post的内容就是AS2消息明文。

1.2.                AS2消息签名不加密

1.3.                AS2消息不签名加密

1.4.                AS2消息签名加密

1.5.                AS2消息数据格式分析（签名、加密）

2、MDN消息

MDN消息不能加密，只能签名。

MDN消息无论是签名还是不签名，都是MIME格式的消息。

2.1.                MDN不签名

2.2.                MDN签名

八、  AS2传输非EDI数据的设置

1、发送AS2数据，同步接收MDN

1.1.                Agreement协议设置

自身àpartner 单项协议中，做如下设置（其他保持默认值）：

1.1.1.   Validation

Message Should be signed：指示消息将被签名，BizTalk对AS2消息进行前面的算法不能选择，默认就是SHA1。

Message should be encrypted：指示消息将被加密。

Encryption algorithm：加密算法，如果前面的设置选择了需要加密，这个设置指定使用哪种加密算法，有DES2和RC2两种算法可选。

1.1.2.   Acknowledgements(MDNs)

Process inbound MDN into MessageBox for routing/deliver opetions：勾选此选项，表示发送AS2消息，在收到对方返回的MDN后，将MDN路由到MessagBox供其他服务订阅MDN消息。一般用一个发送端口订阅发送AS2消息后返回的MDN消息，用于备份MDN文件，订阅的Filter见下面《订阅同步返回的MDN消息的发送端口》设置。

对于同步MDN情形，MDN是在双向HTTP发送端口发送后直接返回的，在发送端口的接收部分的接收管道就会处理收到的MDN，更新数据库中AS2消息的MDN状态，所以MDN消息不是必须发布到MessageBox再路由消息了。

Request singned MDN：是否要求MDN签名和签名算法。

Request MDN：此项打钩，表示需要对方返回MDN。

Disposition-Dotifcation-To：当“Request MDN”打钩后，此文本框里必须有内容，实际上这里的内容将作为HTTP中的Disposition-Notification-To标头发送给对方，值是什么无关紧要（可以任意填），只要有Disposition-Notification-To标头就表示要求MDN。

1.1.3.   Send Ports

将发送AS2消息到partner的HTTP发送端口加入到发送端口列表。

发送端口加入列表到的含义是：这个发送端口将使用这个Agreement的这个单向协议的设置对消息进行处理。

1.2.                用于向对方发送AS2的双向HTTP发送端口

1.2.1.   HTTP adapter设置

General—Destination URL：对方接收AS2消息的URL。

General—Request time（sec）：设置发送超时时间，默认设置为空，为空时采用HTTP handler里的Request time设置，handler里的Request time的默认设置为0。

0表示根据发送消息的大小计算超时时间，一般很小的消息，超时时间是180秒（3分钟）。

如果在超过了超时时间HTTP发送端口还未收到对方返回的HTTP回应，那么会导致发送失败，发送端口进入dehydrate状态，等待重新发送。

1.2.2.   管道设置

发送管道为：AS2Send

接收管道为：AS2Receive

1.2.3.   发送重试次数和时间间隔。

在HTTP发送端口的Transport Advanced Options中设置失败后重发次数和重发间隔时间。

发送失败后，开始计时，在设定的重发间隔时间后开始一次重发，直到重发次数用尽。

1.3.                订阅同步返回的MDN消息的发送端口

用来备份接收到的对方同步返回的MDN消息。

订阅的Filter设置：

EdiIntAS.IsAS2MdnResponseMessage == True

BTS.SPName == 发送AS2消息的HTTP双向发送端口名

2、接收AS2数据，同步返回MDN

2.1.                Agreement协议设置

Partnerà自身单项协议中，做如下设置（其他保持默认值）：

2.1.1.   Validation

Use agreement setting for validation and MDN Instead of message header: 此项打钩，表示使用协议中的设置，不使用接收到的HTTP的标头设置来处理入站的AS2消息。通常使用打钩的设置。

Message Should be signed：指示消息应该是被签名的，如果收到的AS2消息没有签名，将会返回失败的MDN消息，MDN的失败原因：decoder-party-signing-configuration-error。

Message should be encrypted：指示消息应该被加密，如果收到的AS2消息没有加密，将会返回失败的MDN消息，MDN的失败原因：decoder-party-encryption-configuration-error。

Encryption algorithm：加密算法，接收方的这个设置无意义，biztalk会根据加密的AS2消息信封内指示的加密算法进行解密。

2.1.2.   Acknowledgments(MDNs)

这部分是设置发送方的MDN设置，如果在Validation部分选择了Use agreement setting for validation and MDN Instead of message header，则在这里设置如何返回给发送方MDN的行为。

Process inbound MDN into MessageBox for routing/deliver opetions: 在这种情景下，这个设置是否打钩都没关系，无意义，因为接收partner的AS2消息后，是返回给partner MDN，是出站MDN。

Request MDN：此项打钩，表示对方需要返回MDN。

Disposition-Dotifcation-To：当“Request MDN”打钩后，此文本框里必须有内容，值是什么无关紧要（可以任意填）。

2.1.3.   Local Host settings—Receiver MDN Settings

MDN Text：作为接收方返回给发送方的MDN中的消息内容，一般是一段说明性的文字，表示是我这方收到了对方个发来的消息，参看《MDN消息第一部分》。

2.2.                接收AS2消息的HTTP双向接收端口设置

由于同步返回MDN，所以需要使用双向HTTP接收端口。

2.2.1.   HTTP Adapter设置

General—Virtual directory plus ISAPI extension：使用之前“IIS配置BizTalk接收位置（BTS ISAPI 筛选器）”设置的这个partner的接收位置URL：

/partnerName/BTSHTTPReceive.dll

Suspend failed requests：勾选，失败的消息接收将挂起。

2.2.2.   管道设置

接收管道为：AS2Receive

发送管道为：AS2Send

2.3.                订阅AS2负载消息供后续步骤处理的发送端口

HTTP双向接收端口收到的AS2消息后，在接收管道进行解密、验证签名，如果成功会将解码后的AS2负载消息发布到MessageBox。

一般需要使用一个File发送端口订阅AS2消息并保存到一个目录供后续步骤处理。

这个发送端口的Filter设置：

EdiIntAS.IsAS2PayloadMessage == True

BTS.ReceivePortName == AS2消息的HTTP双向接收端口名

管道设置：

发送管道为：PassThruTransmit

2.4.                订阅同步返回的MDN消息用于备份的发送端口

HTTP双向接收端口在AS2接收管道中就会生成需要返回给对方的MDN消息，并发布到MessageBox，并由HTTP双向接收端口的发送端口部分订阅返回给对方。

不过，这个MDN消息是个带有很多上下文属性，而body为空的消息，AS2发送管道会根据消息上下文属性组装生成MDN消息的MIME内容。

可以用一个发送端口订阅这个MDN消息进行备份，这个发送端口的Filter设置：

BTS.RouteDirectToTP == True

EdiIntAS.IsAS2AsynchronousMdn == False

BTS.ReceivePortName == AS2消息的HTTP双向接收端口名

管道设置：

发送管道一定要设置为：AS2Send，AS2发送管道会根据消息的上下文属性组装MDN消息。

注意：

MSDN文档上说，这时MDN消息的EdiIntAS.IsAS2MdnResponseMessage为true，可以通过此属性订阅HTTP接收端口同步返回的MDN消息。但是实际测试，此时MDN消息的EdiIntAS.IsAS2MdnResponseMessage为false。

注意：

因为新建发送端口订阅的MDN消息跟HTTP双向端口是各自使用AS2发送管道生成的，所以他们产生的MDN消息有稍许不同，基本内容相同。除了以下两点：

MDN的MIME的boundary

MIME每个部分的Content-ID

例如，下图是这两个MDN的对比，实质内容是一样的：

3、发送AS2数据，异步接收MDN

3.1.                Agreement协议设置

自身àpartner 单项协议中，做如下设置（其他保持默认值）：

3.1.1.   Validation

Message Should be signed：指示消息将被签名，BizTalk对AS2消息进行前面的算法不能选择，默认就是SHA1。

Message should be encrypted：指示消息将被加密。

Encryption algorithm：加密算法，如果前面的设置选择了需要加密，这个设置指定使用哪种加密算法，有DES2和RC2两种算法可选。

3.1.2.   Acknowledgements(MDNs)

Process inbound MDN into MessageBox for routing/deliver opetions：勾选此选项，表示发送AS2消息，在收到对方返回的MDN后，将MDN路由到MessagBox供其他服务订阅MDN消息。一般用一个发送端口订阅发送AS2消息后返回的MDN消息，用于备份MDN文件，订阅的Filter见下面发送端口设置。

对于异步MDN情形，MDN是由单独的单向HTTP接收端口接收，在接收管道会处理收到的MDN，更新数据库中AS2消息的MDN状态，所以MDN消息不是必须发布到MessageBox再路由消息了。

Request MDN：此项打钩，表示需要对方返回MDN。

Request singned MDN：是否要求MDN签名和签名算法。

Disposition-Dotifcation-To：当“Request MDN”打钩后，此文本框里必须有内容，实际上这里的内容将作为HTTP中的Disposition-Notification-To标头发送给对方，值是什么无关紧要（可以任意填），只要有Disposition-Notification-To标头就表示要求MDN。

Request asynchronous MDN：勾选，表示要求异步返回MDN。同时填写“Receipt-Delivery-Option(URL)”指示接收方异步返回MDN的URL，这个URL将会作为HTTP请求的Receipt-Delivery-Option标头。

3.1.3.   Send Ports

将发送AS2消息到partner的HTTP发送端口加入到发送端口列表。

发送端口加入列表到的含义是：这个发送端口将使用这个Agreement的这个单向协议的设置对消息进行处理。

3.2.                用于向对方发送AS2的单向HTTP发送端口

3.2.1.   HTTP adapter设置

General—Destination URL：对方接收AS2消息的URL。

General—Request time（sec）：设置发送超时时间，默认设置为空，为空时采用HTTP handler里的Request time设置，handler里的Request time的默认设置为0。

0表示根据发送消息的大小计算超时时间，一般很小的消息，超时时间是180秒（3分钟）。

如果在超过了超时时间HTTP发送端口还未收到对方返回的HTTP回应，那么会导致发送失败，发送端口进入dehydrate状态，等待重新发送。

3.2.2.   管道设置

发送管道为：AS2Send

3.2.3.   发送重试次数和时间间隔。

在HTTP发送端口的Transport Advanced Options中设置失败后重发次数和重发间隔时间。

发送失败后，开始计时，在设定的重发间隔时间后开始一次重发，直到重发次数用尽。

3.3.                异步接收MDN的HTTP单向接收端口

3.3.1.   HTTP Adapter设置

General—Virtual directory plus ISAPI extension：使用之前“IIS配置BizTalk接收位置（BTS ISAPI 筛选器）”设置的这个partner的接收位置URL：

/partnerName/BTSHTTPReceive.dll

Suspend failed requests：勾选，失败的消息接收将挂起。

3.3.2.   管道设置

接收管道为：AS2Receive

3.4.                订阅异步返回的MDN消息的发送端口

用来备份接收到的对方异步返回的MDN消息。

订阅的Filter设置：

EdiIntAS.IsAS2MdnResponseMessage == True

BTS.ReceivePortName == 异步接收MDN的HTTP单向接收端口名

管道设置：

发送管道为：PassThruTransmit

4、接收AS2数据，异步发送MDN

4.1.                Agreement协议设置

Partnerà自身单项协议中，做如下设置（其他保持默认值）：

4.1.1.   Validation

Use agreement setting for validation and MDN Instead of message header: 此项打钩，表示使用协议中的设置，不使用接收到的HTTP的标头设置来处理入站的AS2消息。通常使用打钩的设置。

Message Should be signed：指示消息应该是被签名的，如果收到的AS2消息没有签名，将会返回失败的MDN消息，MDN的失败原因：decoder-party-signing-configuration-error。

Message should be encrypted：指示消息应该被加密，如果收到的AS2消息没有加密，将会返回失败的MDN消息，MDN的失败原因：decoder-party-encryption-configuration-error。

Encryption algorithm：加密算法，接收方的这个设置无意义，biztalk会根据加密的AS2消息信封内指示的加密算法进行解密。

4.1.2.   Acknowledgments(MDNs)

这部分是设置发送方的MDN设置，如果在Validation部分选择了Use agreement setting for validation and MDN Instead of message header，则在这里设置如何返回给发送方MDN的行为。

Process inbound MDN into MessageBox for routing/deliver opetions: 在这种情景下，这个设置是否打钩都没关系，无意义，因为接收partner的AS2消息后，是返回给partner MDN，是出站MDN。

Request MDN：此项打钩，表示对方需要返回MDN。

Disposition-Dotifcation-To：当“Request MDN”打钩后，此文本框里必须有内容，值是什么无关紧要（可以任意填）。

Request asynchronous MDN：需要勾选，同时填写“Receipt-Delivery-Option(URL)”指示接收方异步返回MDN的URL。接收管道生成的MDN消息的MDNAsyncURI属性会保存这个URL，如果返回给发送方MDN的HTTP发送端口使用动态端口，就由这个属性确定返回的URL，如果采用非动态HTTP发送端口返回MDN则此属性用不到。

4.1.3.   Local Host settings—Receiver MDN Settings

MDN Text：作为接收方返回给发送方的MDN中的消息内容，一般是一段说明性的文字，表示是我这方收到了对方个发来的消息，参看《MDN消息第一部分》。

4.2.                接收AS2消息的HTTP单向接收端口设置

由于异步返回MDN，所以需要使用单向HTTP接收端口。

4.2.1.   HTTP Adapter设置

General—Virtual directory plus ISAPI extension：使用之前“IIS配置BizTalk接收位置（BTS ISAPI 筛选器）”设置的这个partner的接收位置URL：

/partnerName/BTSHTTPReceive.dll

Suspend failed requests：勾选，失败的消息接收将挂起。

4.2.2.   管道设置

接收管道为：AS2Receive

4.3.                订阅AS2负载消息供后续步骤处理的发送端口

HTTP单向接收端口收到的AS2消息后，在接收管道进行解密、验证签名，如果成功会将解码后的AS2负载消息发布到MessageBox。

一般需要使用一个File发送端口订阅AS2消息并保存到一个目录供后续步骤处理。

这个发送端口的Filter设置：

EdiIntAS.IsAS2PayloadMessage == True

BTS.ReceivePortName == AS2消息的HTTP单向接收端口名

管道设置：

发送管道为：PassThruTransmit

4.4.                订阅异步返回MDN消息的单向HTTP发送端口

接收AS2消息的HTTP单向接收端口在AS2接收管道中就会生成需要返回给对方的MDN消息，并发布到MessageBox，并由单独的HTTP单向发送端口订阅返回给对方。

不过，这个MDN消息是个带有很多上下文属性，而body为空的消息，AS2发送管道会根据消息上下文属性组装生成MDN消息的MIME内容。

这个HTTP单向发送端口的Filter设置：

EdiIntAS.IsAS2AsynchronousMdn== True

BTS.ReceivePortName == AS2消息的HTTP单向接收端口名

发送管道为：AS2Send

4.5.                订阅异步返回的MDN消息用于备份的发送端口

可以用一个发送端口订阅这个MDN消息进行备份，这个发送端口的Filter设置：

EdiIntAS.IsAS2AsynchronousMdn == True

BTS.ReceivePortName == AS2消息的HTTP单向接收端口名

发送管道为：AS2Send

发送管道一定要设置为AS2Send，AS2发送管道会根据消息的上下文属性组装MDN消息。

九、  AS2传输EDI数据

（内容暂缺）

十、  注意事项

1、修改Agreement后可能需要重启IIS Application Pool

修改了Agreement后，如果修改内容影响到HTTP接收位置的动作，比如原来Agreement设置自己这一方接收AS2消息，不返回MDN，改为要同步返回MDN，则需要重新启动承载这个HTTP接收位置的IIS Application Pool，否则更改不会生效。

2、修改Agreement后可能需要重启运行发送端口的Host instance

修改了Agreement后，如果修改内容影响到HTTP发送端口的动作，那么运行这个发送端口的Host instance需要重新启动，否则更改不会生效。

十一、               测试手段

1、通过Fiddler监控AS2 HTTP发送内容

1.1.                过滤需要看的Host

过滤不相关Host的HTTP请求，只需要查看跟AS2 partner之间的HTTP通讯，可以在Filters Tab里设置过滤条件，只查看跟列表中的Host通讯数据：

1.2.                设置需要拦截的Host

在Fiddler左下底部，输入bpu+你要拦截的网址域名（或内网的主机名），比如要拦截发送到内网bizsrv-1服务器的AS2数据包，输入：bpu bizsrv-1，这个时候就会拦截发送到bizsrv-1的数据包了，如下图：

1.3.                拦截HTTP请求并修改数据

向bizsrv-1发送AS2数据后，HTTP请求会被Fiddler拦截，拦截了以后，可以看到左侧图标是红色的，数据包实际上没有发送出去的，如图：

看这时的请求数据：

Header就是HTTP请求的标头部分的内容，TextView中就是HTTP post的数据，这两部分的数据，根据测试目的都可以修改，修改完后，点击“Run to Completion”按钮发送修改后的HTTP请求到对方。

1.4.                取消拦截

在在Fiddler左下底部，再次输入bpu（不带任何参数），则取消HTTP请求拦截。

1.5.                BizTalk HTTP 发送端口设置

Fiddler实际是个代理服务器，启动后默认地址是：http://127.0.0.1:8888。

Fiddler启动后，默认把IE浏览器的代理服务器设置为http://127.0.0.1:8888。

BizTalk的HTTP发送端口需要设置代理，指向http://127.0.0.1:8888：

2、使用Wireshark抓数据包分析AS2的HTTP通讯数据

十二、               故障排除

1、发送AS2消息，要求对方同步返回MDN时，如果对方没有同步返回MDN，而只是返回了HTTP 200 OK消息，发送端口会直接挂起（不重试）

对于发送方：

这时，发送方发送端口会挂起，挂起的原因是：An internal server error was encountered while attempting to transmit the message

并且此AS2消息不会在AS2/MDN Status中显示，消息状态也不会记入bam_AS2MessageActivity_Completed数据表。

对于接收方：

接收方一切正常，接收到AS2消息，不返回MDN，直接返回HTTP/1.1 200 OK，关闭HTTP连接，AS2/MDN状态数据写入bam_AS2MessageActivity_Completed数据表。

2、如果AS2负载消息的发送端口忘记放在agreement单向协议的Send Ports列表中

发送方用这个发送端口发送AS2消息时，发送端口会挂起，挂起原因：

Unable to access party using send port: 发送端口名

3、如果使用了AS2发送管道的发送端口使用了64位主机，发送端口将挂起

这时发送端口会挂起，挂起的原因：

Retrieving the COM class factory for component with CLSID {254B4003-2AA7-4C82-BB2E-18BA7F22DCD2} failed due to the following error: 80040154 Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)).

这是因为AS2发送管道中的MIME pipeline component不支持64位主机，将这个发送端口的handler主机改用32位的即可。

4、接收方返回的MDN中的Received-Content-MIC值不对

5、接收方收到加密的AS2消息后如果解密失败，在AS2/MDN状态报告中找不到此消息

6、接收方的AS2/MDN状态报告中，AS2 Message Date Time为“9999/12/31 23:59:59”

如果AS2消息的发送方也是BizTalk，在接收方的BizTalk的AS2/MDN状态报告中，AS2 Message Date Time会显示为“9999/12/31 23:59:59”。

原因是BizTalk的AS2消息在HTTP头不会放置Date标头：

Date: Fri, 06 May 2005 19:00:57 GMT

而BizTalk的AS2/MDN状态报告中，AS2 Message Date Time对应的是接收AS2消息的Date标头的时间，如果这个标头不存在，就会显示“9999/12/31 23:59:59”，这个时间也对应到bam_AS2MessageActivity_Completed数据表的MessageDateTime字段。

这应该是biztalk的bug。

7、发送方的消息签名用错证书

如果发送方发送的消息用错证书，在接收方将验证签名时不通过，也不会把AS2/MDN状态数据写入bam_AS2MessageActivity_Completed数据表，只能再事件日志里找到类似如下的出错信息：

An output message of the component "Microsoft.BizTalk.EdiInt.PipelineComponents" in receive pipeline "Microsoft.BizTalk.EdiInt.DefaultPipelines.AS2Receive, Microsoft.BizTalk.Edi.EdiIntPipelines, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" is suspended due to the following error:

     An error occurred when validating an AS2 message.  Make sure the certificates used have not timed out or been revoked..

The sequence number of the suspended message is 2.

十三、               附录

1、申请证书

AS2传输数据强调安全性，无论是对消息进行签名以确定发送者身份，还是对消息进行加密以保证消息在传输过程中的保密性，都需要使用到数字证书。

作为AS2数据通讯的双方都需要准备自己的证书，并相互交换各自的只含公钥的证书。

在实际生产环境下一般使用从权威证书颁发机构购买的商业证书，这样可信性高些。当然，公司自己签发的证书如果合作的对方能接受也是可以使用的。

购买证书就不多说了，下面是制作自签发证书的过程。

1.1.                升级win2008 R2证书服务

SHA1散列算法的安全性已经越来越低，sha1签名算法进入淘汰阶段，逐渐弃用中，sha1升级为sha2是大势所趋，所以我们需要win2008 R2的证书服务签发的证书也是sha2的。

不过默认安装的win2008 R2证书服务签发不了sha2的证书，查看证书服务器的属性：

可以看到，证书服务器的Hash algorithm设置是SHA1，我们需要把这里的设置修改为SHA256，但是win2008 R2证书服务没有提供修改的客户界面，只能使用命令行做这件事。

步骤如下：

·         以Administrator打开命令行窗口

·         执行命令：certutil -setreg ca\csp\CNGHashAlgorithm SHA256

·         执行命令：net stop certsvc && net start certsvc

然后，再看证书服务器的Hash algorithm设置：

1.2.                申请证书

2、AS2-HTTP标头