标签：eps   roc   property   was   qml   tac   命名   字符   center   

一、    准备证书    4

1、    升级win2008 R2证书服务    4

2、    申请证书    6

二、    配置证书    13

1、    为AS2配置证书    13

2、    SSL证书配置    14

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

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

2.2.1.    服务端证书    14

2.2.2.    客户端证书    14

三、    反向代理    15

1、    安装ARR    15

2、    新建Application Pool    16

3、    新建IIS Application    18

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

1、    新建Application Pool    22

2、    新建IIS Application    23

五、    通用设置    24

1、    日志report和NRR数据记录    24

1.1.    日志report    24

1.2.    NRR数据记录    24

六、    接收方MDN生成过程    24

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

1.1.    依据HTTP Header的设置：    25

1.2.    依据Agreement的设置：    25

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

2.1.    生成的主要属性    25

2.1.1.    OriginalMessageId    25

2.1.2.    EdiIntAS.DispositionMode    25

2.1.3.    EdiIntAS.DispositionType    25

2.1.4.    MicHashAlgorithm    26

2.1.5.    ReceivedContentMic    26

2.1.6.    EdiIntAS.IsAS2AsynchronousMDN    26

2.1.7.    MDNAsyncURI    26

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

2.2.1.    MDN消息第一部分    26

2.2.2.    MDN消息第二部分    26

A )    原始AS2消息的MessageID    26

B )    消息接收处置结果    26

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

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

2.4.    接收管道路由MDN消息    27

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

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

1、    AS2消息    27

1.1.    AS2消息不签名不加密    27

1.2.    AS2消息签名不加密    28

1.3.    AS2消息不签名加密    29

1.4.    AS2消息签名加密    29

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

2、    MDN消息    32

2.1.    MDN不签名    32

2.2.    MDN签名    32

八、    AS2传输数据的设置    34

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

1.1.    Agreement协议设置    34

1.1.1.    Validation    34

1.1.2.    Acknowledgements(MDNs)    34

1.1.3.    Send Ports    34

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

1.2.1.    HTTP adapter设置    34

1.2.2.    管道设置    35

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

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

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

2.1.    Agreement协议设置    35

2.1.1.    Validation    35

2.1.2.    Acknowledgments(MDNs)    35

2.1.3.    Local Host settings—Receiver MDN Settings    35

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

2.2.1.    HTTP Adapter设置    36

2.2.2.    管道设置    36

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

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

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

3.1.    Agreement协议设置    37

3.1.1.    Validation    37

3.1.2.    Acknowledgements(MDNs)    37

3.1.3.    Send Ports    37

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

3.2.1.    HTTP adapter设置    38

3.2.2.    管道设置    38

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

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

3.3.1.    HTTP Adapter设置    38

3.3.2.    管道设置    38

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

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

4.1.    Agreement协议设置    38

4.1.1.    Validation    38

4.1.2.    Acknowledgments(MDNs)    39

4.1.3.    Local Host settings—Receiver MDN Settings    39

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

4.2.1.    HTTP Adapter设置    39

4.2.2.    管道设置    39

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

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

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

九、    注意事项    40

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

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

十、    测试手段    40

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

1.1.    过滤需要看的Host    40

1.2.    设置需要拦截的Host    40

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

1.4.    取消拦截    42

1.5.    BizTalk HTTP 发送端口设置    42

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

十一、    故障排除    42

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

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

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

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

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

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

十二、    附录    43

1、    AS2-HTTP标头    43

2、    AS2-上下文属性    45

1. 准备证书

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

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

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. 申请证书

1. 配置证书

1. 为AS2配置证书

1. SSL证书配置

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

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

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

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

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

1. 服务端证书

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

待确认：

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

1. 客户端证书

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

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

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

1. 反向代理

有的公司对安全规定比较严格，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请求转发。

1. 新建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。

1. 新建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

1. 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组的账号。

1. 新建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. 通用设置

   1. 日志report和NRR数据记录

   2. 日志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. NRR数据记录

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

1. 接收方MDN生成过程

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

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

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

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. 依据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。

1. 接收管道生成MDN消息过程

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

1. 生成的主要属性

2. OriginalMessageId

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

1. EdiIntAS.DispositionMode

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

1. 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

1. MicHashAlgorithm

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

1. ReceivedContentMic

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

1. EdiIntAS.IsAS2AsynchronousMDN

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

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

1. MDNAsyncURI

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

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

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

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

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

1. MDN消息第一部分

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

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

1. MDN消息第二部分

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

1. 原始AS2消息的MessageID

在MDN消息中形式如下：

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

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

1. 消息接收处置结果

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

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

第一段绿色底线是MdnDispositionType，

第二段绿色底线是DispositionModifierExtType，

第三段绿色底线是DispositionModifierExtDescription，

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

1. 原始AS2消息的MIC哈希值

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

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

1. 创建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数据库。

1. 接收管道路由MDN消息

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

1. 发送管道组装MDN消息过程

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

注意：

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

1. AS2数据和MDN数据的样例

   1. AS2消息

1. AS2消息不签名不加密

POST /Contoso/BTSHTTPReceive.dll HTTP/1.1

Content-Type: text/plain

AS2-Version: 1.2

Content-Transfer-Encoding: binary

Mime-Version: 1.0

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

Content-Description: body

Content-ID: {58FC446E-7D8C-413F-A0D0-45956E48D80E}

AS2-To: Fabrikam

Disposition-Notification-To: Contoso

AS2-From: Contoso

EDIINT-Features: multiple-attachments

User-Agent: Microsoft (R) BizTalk (R) Server 2010

Host: bizsrv-1

Content-Length: 64

Expect: 100-continue

Connection: Close

Static text.8320591249.6521165843.NLRM.CN04.8320591249.PDF.INV

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

1. AS2消息签名不加密

POST /Contoso/BTSHTTPReceive.dll HTTP/1.1

Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="_99C8D355-8E1E-4E4C-8E3C-21DC6BB66D50_"

Disposition-Notification-Options: signed-receipt-protocol=required,pkcs7-signature; signed-receipt-micalg=required,sha1

AS2-Version: 1.2

Message-ID: <BIZSRV-2_5610D942-F883-4BE4-995A-60C949D1C430>

Mime-Version: 1.0

EDIINT-Features: multiple-attachments

AS2-To: Fabrikam

Content-ID: {9BE235D2-2B8E-4892-B3B9-AB2C41880D0F}

Disposition-Notification-To: Contoso

AS2-From: Contoso

User-Agent: Microsoft (R) BizTalk (R) Server 2010

Host: bizsrv-1

Content-Length: 2224

Expect: 100-continue

Connection: Close

--_99C8D355-8E1E-4E4C-8E3C-21DC6BB66D50_

Content-Type: text/plain

Content-Transfer-Encoding: binary

Content-Description: body

Static text.8320591249.6521165843.NLRM.CN04.8320591249.PDF.INV

--_99C8D355-8E1E-4E4C-8E3C-21DC6BB66D50_

Content-type: application/pkcs7-signature; name="smime.p7s"

Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDtzCCA7Mw

ggKboAMCAQICCmEsP7IAAAAAAA4wDQYJKoZIhvcNAQELBQAwFjEUMBIGA1UEAxMLQklaU1JWLTEt

Q0EwHhcNMTYxMDEwMDEzNTMyWhcNMTcxMDEwMDE0NTMyWjASMRAwDgYDVQQDEwdDb250b3NvMIIB

IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr0USk0aDih1YDKeCcFf2UGFAwxqgUjQL/Rir

2+dUDsIKG7ZYE5J2vkg6ZtvBiR36HlphxnYtUS7jF+fypt9vF+YdmfOZ3MVV/Tb7U2E1x8Wcqtez

m7nf0kCJNi3CI28cufklNZb+CL4SI0eZM0ioVa9yvmrUf5xgL6E6Kf7T98A6QMzVPF6k00X9XLba

f2416ehYuQmdfgBfMBkxpXW0QxSUrc1TtwJ7APFDtIGRjforXqh95pFEtyrItC0xemgrDgySQ8dt

Yzf5MIqIqMxABIhU1QfvbwdPkCw6KW3lhlpimBHGZV4Z/N5lJtoSNBCUatLpFao0pv+zGSVIQOQL

mwIDAQABo4IBBTCCAQEwDgYDVR0PAQH/BAQDAgTwMBMGA1UdJQQMMAoGCCsGAQUFBwMBMB0GA1Ud

DgQWBBTBhpGKWiTrB+Qh7lRjXYg8FEse/jAfBgNVHSMEGDAWgBQ+oYdE3QQHga4AfvkYjrJ2PvtY

tTA7BgNVHR8ENDAyMDCgLqAshipmaWxlOi8vQml6U3J2LTEvQ2VydEVucm9sbC9CSVpTUlYtMS1D

QS5jcmwwTwYIKwYBBQUHAQEEQzBBMD8GCCsGAQUFBzAChjNmaWxlOi8vQml6U3J2LTEvQ2VydEVu

cm9sbC9CaXpTcnYtMV9CSVpTUlYtMS1DQS5jcnQwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQsF

AAOCAQEA4N1Q9DWw998pGO8Z0WOIHOCbrkEwCxLicpgMn/2BWGRMsgrxlfmmXBu4kNLerhgazcG9

lqfiTK/ZWHPjDXpikxm3o3+Qy0KA3lV2U9rOGwIbqVxtQp4o2ak/xGw1vwN9SGj7ONZVZixUwwk7

Y/+tBmV2V7xtVskNKIRyGGu0HryxA945J844jwkpaDMUk5zh3YBnshVyqV0WS1IyuWfjoiKssFBd

iC3E4l4wrAj+AWvH0IiZujsR1tJ6RWyScX2ULMxrM2InWYwhVyEtKA2oFdBmHws+Oopvd9d8s6/u

zy2WCzrdPLxEAAwL6LLeys5FRj1wqlJ5BRxF3R9v2bCJZjGCAUswggFHAgEBMCQwFjEUMBIGA1UE

AxMLQklaU1JWLTEtQ0ECCmEsP7IAAAAAAA4wCQYFKw4DAhoFADANBgkqhkiG9w0BAQEFAASCAQBf

nM0som9k/Q6hpUPd48rVY0420CuIu49v+L1Kh5fKjksDcueCAjaBnuTBjoNkLoL+Hvt/DnIpFNvU

tDQtO6eSikICC6BS91LW7GSTFl6Sot1fMNZpFg2SH+PYR89V1pZfJ4r5wXFCVXe1w+yPTFeeCdIo

0/JMiZ+eQodvDdFGoEFBrhvdT2OYKfZ5DhEPs8Dxb4wWSck3oZC6SI8UwMTFMEW/RokQ+xZptTTL

CNmM1mXUfQ5I9BsbCxX0FzGDzITH6BQpMlF7i5MJM2y/3LfBly5MIWoRoddJtjqAY/BASeIVBtOQ

0ulrnortWhDUbtz9YMYAJg6C0sfCduAF42QRAAAAAAAA

--_99C8D355-8E1E-4E4C-8E3C-21DC6BB66D50_--

1. AS2消息不签名加密

POST /Contoso/BTSHTTPReceive.dll HTTP/1.1

Content-Type: application/pkcs7-mime; smime-type=enveloped-data; name="smime.p7m"

Disposition-Notification-Options: signed-receipt-protocol=required,pkcs7-signature; signed-receipt-micalg=required,sha1

AS2-Version: 1.2

Content-Transfer-Encoding: binary

Mime-Version: 1.0

Message-ID: <BIZSRV-2_F0F79DDB-3231-495E-AFE1-3153325B6744>

AS2-To: Fabrikam

Disposition-Notification-To: Contoso

AS2-From: Contoso

EDIINT-Features: multiple-attachments

User-Agent: Microsoft (R) BizTalk (R) Server 2010

Host: bizsrv-1

Content-Length: 517

Expect: 100-continue

Connection: Close

0.....*.H.. .......0......1..@0..<...0$0.1.0...U....BIZSRV-1-CA.

.2qW......0 ..*.H.. .........x 6........~....xk...>..tz<.I.!..:R.uu...l....S.<#oBm..^)..y...U.?s."......T;...p..u..X,......a.h.`...rG.......O4..:....=:......{..A.C.....q>q.....qd....v.d<r.P..f}/..[K.s..f...$b.Qw..

.. ...,i-..........L....<..\...=....L.V-..Cw.......G..>.<..9..e6A8D....0....*.H.. ...0...*.H.. .......K..4......+W.=e

...fo......J9..)._t8.......\@...v.1..i.4Q..l.. .q.....fEN...@....-...W...i...6..L.^._=......|)..)......-+..pJ....Z..qNVs

1. AS2消息签名加密

POST /Contoso/BTSHTTPReceive.dll HTTP/1.1

Content-Type: application/pkcs7-mime; smime-type=enveloped-data; name="smime.p7m"

Disposition-Notification-Options: signed-receipt-protocol=required,pkcs7-signature; signed-receipt-micalg=required,sha1

AS2-Version: 1.2

Content-Transfer-Encoding: binary

Mime-Version: 1.0

Message-ID: <BIZSRV-2_FA1CFD9E-9744-45A9-9E3D-0009BDA1C0EB>

AS2-To: Fabrikam

Disposition-Notification-To: Contoso

AS2-From: Contoso

EDIINT-Features: multiple-attachments

User-Agent: Microsoft (R) BizTalk (R) Server 2010

Host: bizsrv-1

Content-Length: 2759

Expect: 100-continue

Connection: Close

0.

...*.H.. .....

.0.

....1..@0..<...0$0.1.0...U....BIZSRV-1-CA.

.2qW......0 ..*.H.. .........%‘..g..1.,u..Yg..i.H0c./0fl....^....5.....g.+R..].@.k

^tr9..1F.zr.T....A........1.z.......WP.?~.*0J.[........[.......iy.....+. Ou._C.(.K..cB....r....>..S. i...$.)!<l..).H.n.n. .D,....C[..k..‘.8o......<"...2.......}&.x.].,F.O*.w.,.....d...`TP[,.;....32.J.iP0..e..*.H.. ...0...*.H.. .....j.k&......@G..5..%.P...U...1....d..}w&. 5U...#.........U.b.^..z e..!.A..3..i..*w7=B....?(.. $...%..h..<@....\iB:...g^...ZP.3#. .wOd2m..-..i...aHA..&....b.1(..i..=p.h^!\...o.....#...g.D.&.Y..c>...\...q\-A..V.}`Z.D...f..CF......T.{p.:..:.)...uc...."}..kdK..E..{.. %.n..=..V.h..*p1..DR2...-u...*....... :1.....H6......JK.........C.2..H.imt .V}.|....~WI+.....?";.eI"SS9Y. ‘V.t.$...u....;.N.......S..T...=p.VW7.[...../.]etssa..kd.<R.^.6..xl... F...h.qz...VZ&...(/.......O..j......8.4G ..0..c.....n........ ...<.r>...8....j}9xZG...xTP?...;.....d...f....m..m.g.c.J....g.D..P.\... ....Y=.f.v......,qEJ5_B.z..O.Ol......c..Q.‘5T..Ov..4.*.D....r...zp...B.x|w*.V..&"K...2...P....I. ...kGN.......\i...........g5..K.......lS...".....r.0..z..8.vb...l..7.~.F.>.@.H.|.....9B!.b.V.Qi..J.,...ap..I..8....tmU.e.O....~......fH....~9..h.,*U.%..8O.R.=8/...".w .....K>...F.J..>......_.u.‘Rn:<....\t......E...;Q.*.VA,l]V........

.m....i ).Qu:n..............l....G...T......E.f..^..1q.x..nY..s0..C.r:....T.q.4>..‘.]1.........0.T7._.S..*.?9.....,}..6\e..b....@...LJ.a...|8...s..3.aX.N......6..m......G..._jL.+.....V.U.IB..6w|.x<.H..F....Mu..h..V.t..<.8..

.

......k.G.^0.../...42m.)..

FJ..\..].=Fi...#K.Y.Wg..h...........\(...z.........j.nk.....w.y.)..g&..}....s".f..E.S...a.$0.d..BY..9..b..../.(..-.}..[..3.<..D..^..r.....1.....uv.-

|...pN.Q.d/...r...*2r.

^..p9.....z....?.y..xe......4. .p.[K..)= f]..+./......|A..... ...`.u..4.Y..9.>.$....[..?..8....o.aB......... ..-U...{.e

|..w.........%c/X..S....><i.&..mp2!..yun.......Rr.3...".+.C......*..rR....).^........./...3i.T.<mv.i.7_....wB...B..r...4k

..T.|.WU... zp..~X8F..7..h.%}.Sz..b....D..Z

.....r..5.S..‘..a...-...L....T.U.RQ.....U<......!_...3..

.EG@ ..9..T..h..../..P......U<+([...;...<b._/|.j..t..c%..........vT.YM.z......c9.A.o...l.M.....=X...f..r.N...Q./..vH.#<<...4......S.....W.8h.(........f.U<8..2...n..(...s..L...9V....^..N..M...........*L..r..8.\.f.8....$u...).K..mR...y".....G._.iB.25...aK.. .......>..WMf....O/.....L...%.....q>.tO.....‘.`9..........6..a...>.ci.....W)!c.....|..........r.+.&X....S.SGS.R.~.H...qw.D.\x...r.%.U{=..*. .3i......v....5....F......L..i6t.K_m..".]...D.\........5.........yx.%.v..?W$.=.."o....`......;n......).T._........3EY?..DuMB....9vie.\o.../..L.....#..a(..U.]....SLOzz.N..O..:? .._...Qz2.(of.8.V.-_.. ......R|d^..0..,W9..$....%Q.J......2.>.,.......fx.........

(...&3.Y.@.exG.ey...!=...f`8...

0....\...........E.

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

1. MDN消息

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

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

1. MDN不签名

HTTP/1.1 200 OK

Content-Length: 681

Content-Type: multipart/report; report-type=disposition-notification;

.boundary="_E4BB7B25-A5C0-4BA7-BA06-176B374C8A30_"

Server: Microsoft-IIS/7.5

AS2-Version: 1.2

Message-ID: <BIZSRV-1_9676DD36-B582-410C-A431-7FC467005D45>

Mime-Version: 1.0

EDIINT-Features: multiple-attachments

AS2-To: Contoso

AS2-From: Fabrikam

X-Powered-By: ASP.NET

Date: Wed, 09 Nov 2016 03:30:52 GMT

Connection: close

--_E4BB7B25-A5C0-4BA7-BA06-176B374C8A30_

Content-Type: text/plain

Content-Transfer-Encoding: binary

Content-ID: {243F1896-6016-48A8-B2F9-13C718B2D015}

Content-Description: plain

This is Toll MDN

--_E4BB7B25-A5C0-4BA7-BA06-176B374C8A30_

Content-Type: message/disposition-notification

Content-Transfer-Encoding: 7bit

Content-ID: {5A37A23A-A50F-4FD4-89C8-5FB23EAF2478}

Content-Description: body

Final-Recipient: rfc822; Fabrikam

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

Disposition: automatic-action/MDN-sent-automatically; processed

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

--_E4BB7B25-A5C0-4BA7-BA06-176B374C8A30_--

1. MDN签名

HTTP/1.1 200 OK

Content-Length: 2880

Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1";

boundary="_60276327-5600-4CA2-86E1-06CEDAED1A46_"

Server: Microsoft-IIS/7.5

AS2-Version: 1.2

Message-ID: <BIZSRV-1_EC23F83B-501A-4CC0-9C06-F7CBB4CF6767>

Mime-Version: 1.0

EDIINT-Features: multiple-attachments

AS2-To: Contoso

AS2-From: Fabrikam

X-Powered-By: ASP.NET

Date: Wed, 09 Nov 2016 02:23:42 GMT

Connection: close

--_60276327-5600-4CA2-86E1-06CEDAED1A46_

Content-Type: multipart/report; report-type=disposition-notification;

.boundary="_554A0419-2C77-4521-9668-42E8C1EB4548_"

--_554A0419-2C77-4521-9668-42E8C1EB4548_

Content-Type: text/plain

Content-Transfer-Encoding: binary

Content-ID: {529F03AA-AF3F-453A-B890-D6A88176C500}

Content-Description: plain

This is Toll MDN

--_554A0419-2C77-4521-9668-42E8C1EB4548_

Content-Type: message/disposition-notification

Content-Transfer-Encoding: 7bit

Content-ID: {0D047958-8B3C-40D1-9CCC-1F48098FBDA4}

Content-Description: body

Final-Recipient: rfc822; Fabrikam

Original-Message-ID: <BIZSRV-2_2CF73B67-1A9A-4931-91E0-A57FFCBAF260>

Disposition: automatic-action/MDN-sent-automatically; processed

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

--_554A0419-2C77-4521-9668-42E8C1EB4548_--

--_60276327-5600-4CA2-86E1-06CEDAED1A46_

Content-type: application/pkcs7-signature; name="smime.p7s"

Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIDuDCCA7Qw

ggKcoAMCAQICChEycVcAAAAAAA8wDQYJKoZIhvcNAQELBQAwFjEUMBIGA1UEAxMLQklaU1JWLTEt

Q0EwHhcNMTYxMDEwMDYyMTU1WhcNMTcxMDEwMDYzMTU1WjATMREwDwYDVQQDEwhGYWJyaWthbTCC

ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALpAocLd+3ELED8FmI/Qc2rPniiq4gYSTmug

RNKa7bN/pxq9h3Edt02a2PF8ih4WxaIc27HkhWBTqTdO1oNaPYAWp7/vnN6x5AaqSdlWXVYNikRU

MJBBnwIY56skxYgt67Kzh1nc3fYvK3vxLNURsfRdOVCuy4R5yiGAVVp9ZCWOI7dZLLgGNjqCxRKb

Aemt0foveyXqEiJaag6ZsV0E/hRsCCMMwIAiEsLZih+6Gzaqicpusrn0LuXXBKDdcLAqmDWMebuI

97lw7JhZwbvv6aMY7xjrPFov4/dH8Mvuen2U5B9N/+HT8lLWcU4CBzyQOhz9aeHFh8k+8KIi6+/w

CAkCAwEAAaOCAQUwggEBMA4GA1UdDwEB/wQEAwIE8DATBgNVHSUEDDAKBggrBgEFBQcDATAdBgNV

HQ4EFgQUMDg7QU5/1+9SlwVf3xf9qrnAtR8wHwYDVR0jBBgwFoAUPqGHRN0EB4GuAH75GI6ydj77

WLUwOwYDVR0fBDQwMjAwoC6gLIYqZmlsZTovL0JpelNydi0xL0NlcnRFbnJvbGwvQklaU1JWLTEt

Q0EuY3JsME8GCCsGAQUFBwEBBEMwQTA/BggrBgEFBQcwAoYzZmlsZTovL0JpelNydi0xL0NlcnRF

bnJvbGwvQml6U3J2LTFfQklaU1JWLTEtQ0EuY3J0MAwGA1UdEwEB/wQCMAAwDQYJKoZIhvcNAQEL

BQADggEBAD9MIwaBtez3ryV5YBBI8Kz2LPjUgSuUroZFqZyQsMqE5W8IKwIgmUy+5qLc5Idxd/GG

qokaPPv5Xw2LNAHj8tAytbJWISG4kpcchNEs1DSwHL1guPLJoLEBKfDGFrLCS6lHxWf2E74Oj18M

ULMQHlpaaakfpO7CTBZkfeVdlfMClwAnzuWywEBrzZuwfUjBCoiXEzHNs6OZ6WSMK8SgSmg4B8n7

304JwpA85mY6xpdl5N3xov1T4aRqOJE1vKNPUh16knmRPfaLB3mf8+p2S/6Fgs5ghzkBl40lKvwz

ka+AErNCGwGRsi83aH5V7jHFdJA543qofeweg+hybVkeo9cxggFLMIIBRwIBATAkMBYxFDASBgNV

BAMTC0JJWlNSVi0xLUNBAgoRMnFXAAAAAAAPMAkGBSsOAwIaBQAwDQYJKoZIhvcNAQEBBQAEggEA

S2spsZ+H+loRg6miHnA9UOCYQ9ztpOragv/Bsrqd2BBT+JNrPBBymrHZYVJWtDzYzG5g47mbOMDe

rM+G0FTIp3zdF0b96x1nJGS7ZTXiZI+lEOV0BNZHrs08ymz1Ja6+cPXXImwJfEnKZRG6ItdURkju

eAtC4ZFeKFTQM11V7xhX+mWsvrDJ4h0bWX0G9G7roXcxbHJegMC8CKRGzPf19UmDen8U4iewYor4

ieVC9diWDeNOL51uDObXAzUoSHlm+lPxE5an0U5DJZC2G910tEFid1qi9aS6XKyKHC0Iplp1Gr78

5Lj4Zh6lmEVwYVt72xe1fjMr6+6vg4Ed1GJRcQAAAAAAAA==

--_60276327-5600-4CA2-86E1-06CEDAED1A46_--

1. AS2传输数据的设置

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

2. Agreement协议设置

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

1. Validation

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

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

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

1. 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. Send Ports

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

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

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

2. 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. 管道设置

   发送管道为：AS2Send

   接收管道为：AS2Receive

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

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

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

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

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

订阅的Filter设置：

EdiIntAS.IsAS2MdnResponseMessage == True

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

1. 接收AS2数据，同步返回MDN

2. Agreement协议设置

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

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消息信封内指示的加密算法进行解密。

1. 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"打钩后，此文本框里必须有内容，值是什么无关紧要（可以任意填）。

1. Local Host settings—Receiver MDN Settings

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

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

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

1. HTTP Adapter设置

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

/partnerName/BTSHTTPReceive.dll

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

1. 管道设置

接收管道为：AS2Receive

发送管道为：AS2Send

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

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

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

这个发送端口的Filter设置：

EdiIntAS. IsAS2PayloadMessage == True

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

管道设置：

发送管道为：PassThruTransmit

1. 订阅同步返回的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的对比，实质内容是一样的：

1. 发送AS2数据，异步接收MDN

2. Agreement协议设置

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

1. Validation

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

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

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

1. 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标头。

1. Send Ports

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

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

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

2. 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. 管道设置

   发送管道为：AS2Send

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

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

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

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

6. HTTP Adapter设置

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

/partnerName/BTSHTTPReceive.dll

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

1. 管道设置

接收管道为：AS2Receive

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

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

订阅的Filter设置：

EdiIntAS.IsAS2MdnResponseMessage == True

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

管道设置：

发送管道为：PassThruTransmit

1. 接收AS2数据，异步发送MDN

2. Agreement协议设置

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

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消息信封内指示的加密算法进行解密。

1. 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则此属性用不到。

1. Local Host settings—Receiver MDN Settings

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

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

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

1. HTTP Adapter设置

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

/partnerName/BTSHTTPReceive.dll

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

1. 管道设置

接收管道为：AS2Receive

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

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

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

这个发送端口的Filter设置：

EdiIntAS. IsAS2PayloadMessage == True

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

管道设置：

发送管道为：PassThruTransmit

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

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

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

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

EdiIntAS. IsAS2AsynchronousMdn== True

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

发送管道为：AS2Send

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

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

EdiIntAS.IsAS2AsynchronousMdn == True

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

发送管道为：AS2Send

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

1. 注意事项

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

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

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

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

1. 测试手段

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

   2. 过滤需要看的Host

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

1. 设置需要拦截的Host

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

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

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

看这时的请求数据：

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

1. 取消拦截

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

1. 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：

1. 使用Wireshark抓数据包分析AS2的HTTP通讯数据

1. 故障排除

   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数据表。

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

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

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

1. 如果使用了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位的即可。

1. 接收方返回的MDN中的Received-Content-MIC值不对

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

1. 接收方的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。

1. 附录

   1. AS2-HTTP标头

1. AS2-上下文属性

EDI/INT 全局属性架构中的消息上下文属性是公开的，因此可以在消息路由等操作中使用这些属性。在 Microsoft.BizTalk.Edi.BaseArtifacts 程序集中的 EdiIntProperties.xsd 中定义了这些上下文属性。这些属性的命名空间是 http://schemas.microsoft.com/BizTalk/2006/as2-properties。如果对其进行升级，则这些消息上下文属性可以用作"发送端口属性"对话框的"筛选器"页中的 EdiIntAS.<Property Name>。

Biztalk AS2开发经验总结

标签：eps   roc   property   was   qml   tac   命名   字符   center   

原文地址：http://www.cnblogs.com/chnking/p/6373598.html