首页 > 其他 > 详细

Biztalk AS2开发经验总结

时间:2017-03-02 16:45:20      阅读:203      评论:0      收藏:0      [点我收藏+]

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

AS2通常采用HTTPHTTPS协议,一般使用“POST”方法向对方发送数据。

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

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

一、  BizTalkAS2的支持

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、AS2EDI的关系

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

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

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

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

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

二、  配置证书

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

1、AS2配置证书

证书用途

证书类

证书存储

定义位

签名(出站)

自己的私钥 (.pfx)

每个 AS2 发送端口主机实例服务帐户的“Current User\Personal”存储区

“Group Properties”对话框的“Certificate”页。BizTalk所有Application默认使用这里指定的出站签名证书。
但是可以通过在每个Agreement中选择单向协议选项卡的“Signature Certificate”页中的“Override group signing certificate”
覆盖组属性里设置的签名证书。

签名验证(入站)

partner的公钥 (.cer)

Local Computer\Other People存储区

“Party Properties”对话框的“Certificate”

加密(出站)

partner的公钥(.cer)

“Local Computer\Other People”存储区

发送端口属性的“Certificate”

解密(入站)

自己的私钥 (.pfx)

每个 AS2 接收端口主机实例服务帐户的“Current User\Personal”存储区

AS2 解码器将根据消息中的证书信息确定证书。
对于 BizTalk MIME 解码器,证书必须在用于接收消息的主机的证书页上。对于 AS2
解码器,则不一定是这样。

 

2、SSL证书配置

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

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

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

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

使用Http发送端口使用SSLpartner发送AS2消息。

2.2.1.   服务端证书

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

待确认:

服务端证书的上级颁发机构的证书是否需要保存到Local ComputerTrhusted Root Certification AuthoritesIntermediate Certification Authorites

2.2.2.   客户端证书

如果服务端需要验证客户端(即需要客户端证书),发送端口需要指定客户端证书(带私钥的证书),客户端证书安装位置:Current User/Personal

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

技术分享

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

 

三、  反向代理

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

解决方案就是,在DMZ区的中转服务器上使用反向代理,将收到的HTTP请求转发到内部IPbiztalk serverhttp接收端口。微软的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就是我们需要的请求转发功能:

技术分享

一般会给每个AS2partner设置一个IISApplication处理相应partnerhttp请求转发。

2、新建Application Pool

partner新建一个Application Pool

技术分享

注意:

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

在这个Application PoolAdvanced Settings…中修改:

技术分享

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

修改Regular time intervalsin minutes),从默认的1740分钟修改为0,即不设置固定多长时间后回收此Application Pool

3、新建IIS Application

为这个partner新建一个IIS ApplicationApplication Pool选前面新建的那个Pool

技术分享

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

技术分享

 

在右侧的“Actions”面板里,点击“Add Rules”:

技术分享

Inbound rules下选择“Blank rule”,新建入站规则:

技术分享

相关设置说明:

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

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

Rewrite URL – URL的重写地址。对于本例,转发到内网biztalkURL是: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 筛选器)

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

BizTalk服务器上的配置IIS,一般每个partner设置一个IIS Application,分别设置每个partnerISAPI

1、新建Application Pool

partner新建一个Application Pool

技术分享

在这个Application PoolAdvanced 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

在这个ApplicationFeatures 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、日志reportNRR数据记录

1.1.                日志report

如果想要AS2的消息状态在BizTalk consoleAS2 Message and Correlate MDN Status中查看到相关AggreementAS2消息状态的日志report,需要如下设置:

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

1.2.                NRR数据记录

如果Agreement的单向协议中没有Local Host Settings -- SenderReceiver Message TrackingNRR)没设置,则AS2消息或MDN的消息内容不会记入此表。bam_AS2MessageActivity表的MessagePayloadContentKeyMessageWireContentKey字段和bam_AS2MdnActivity表的MdnPayloadContentKeyMdnWireContentKey字段也会为空。

 

六、  接收方MDN生成过程

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

1、确定是否返回MDNMDN同步还是异步、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标头(表示异步返回MDNURL),表示发送方需要异步返回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不签名》消息样例。

不签名的MDNMIME格式消息由两部分组成,由MIMEboundary符分割。

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 )  消息接收处置结果

DispositionModeDispositionType属性,在发送管道会被组装到MIME格式的MDN消息中的Disposition中,比如:

技术分享

第一段蓝色底线部分是属性DispositionMode,第二段蓝色底线部分是属性DispositionTypeDispositionType属性又分为三部分:

第一段绿色底线是MdnDispositionType

第二段绿色底线是DispositionModifierExtType

第三段绿色底线是DispositionModifierExtDescription

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

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

消息的ReceivedContentMicMicHashAlgorithm属性组装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.boundaryMIME消息每一部分的Content-ID不同,参看《订阅同步返回的MDN消息的发送端口》后的第二个注意部分。

 

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

1、AS2消息

 

1.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 headerpost的内容就是AS2消息明文。

1.2.                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.3.                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.4.                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.5.                AS2消息数据格式分析(签名、加密)

技术分享

 

 

2、MDN消息

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

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

2.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_--

 

2.2.                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_--

 

 

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

 

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

1.1.                Agreement协议设置

自身àpartner 单项协议中,做如下设置(其他保持默认值):

1.1.1.   Validation

Message Should be signed:指示消息将被签名,BizTalkAS2消息进行前面的算法不能选择,默认就是SHA1

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

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

 

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消息到partnerHTTP发送端口加入到发送端口列表。

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

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

1.2.1.   HTTP adapter设置

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

General—Request timesec):设置发送超时时间,默认设置为空,为空时采用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: 在这种情景下,这个设置是否打钩都没关系,无意义,因为接收partnerAS2消息后,是返回给partner MDN,是出站MDN

Request MDN:此项打钩,表示对方需要返回MDN

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

 

2.1.3.   Local Host settingsReceiver 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双向接收端口名

管道设置:

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

 

注意:

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

 

注意:

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

MDNMIMEboundary

MIME每个部分的Content-ID

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

技术分享

 

 

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

3.1.                Agreement协议设置

自身àpartner 单项协议中,做如下设置(其他保持默认值):

3.1.1.   Validation

Message Should be signed:指示消息将被签名,BizTalkAS2消息进行前面的算法不能选择,默认就是SHA1

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

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

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)”指示接收方异步返回MDNURL,这个URL将会作为HTTP请求的Receipt-Delivery-Option标头。

3.1.3.   Send Ports

将发送AS2消息到partnerHTTP发送端口加入到发送端口列表。

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

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

3.2.1.   HTTP adapter设置

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

General—Request timesec):设置发送超时时间,默认设置为空,为空时采用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.                异步接收MDNHTTP单向接收端口

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 == 异步接收MDNHTTP单向接收端口名

管道设置:

发送管道为: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: 在这种情景下,这个设置是否打钩都没关系,无意义,因为接收partnerAS2消息后,是返回给partner MDN,是出站MDN

Request MDN:此项打钩,表示对方需要返回MDN

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

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

4.1.3.   Local Host settingsReceiver 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

 

发送管道一定要设置为AS2SendAS2发送管道会根据消息的上下文属性组装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

过滤不相关HostHTTP请求,只需要查看跟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

BizTalkHTTP发送端口需要设置代理,指向http://127.0.0.1:8888

技术分享

 

2、使用Wireshark抓数据包分析AS2HTTP通讯数据

 

十二、               故障排除

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,在接收方的BizTalkAS2/MDN状态报告中,AS2 Message Date Time会显示为“9999/12/31 23:59:59”。

原因是BizTalkAS2消息在HTTP头不会放置Date标头:

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

 

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

这应该是biztalkbug

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标头

AS2标头:AS2消息负载和MDN消息都可以使用这些HTTP标头

AS2 标头

必需/

AS2-Version

“1.1”

AS2-From

发送 AS2 消息的公司的名称

值:字符串,可打印的 ASCII,长度为 1 128 个字符

AS2-To

向其发送 AS2 消息的公司的名称

值:字符串,可打印的 ASCII,长度为 1 128 个字符

AS2-Text

文本(位于消息中的此标头内

值:字符串,可打印的 ASCII,长度为 1 128 个字符

Disposition-Notification-To

如果出现,则用作对要返回的 MDN 的请求。如果附带 receipt-delivery-option 标头,则它是对异步 MDN 的请求。如果不是,则它是对同步 MDN 的请求

如果不出现,则不需要 MDN

值:必须存在的邮件地址。但是,不得将此地址用于标识 MDN 的返回目的地。接收应用程序必须忽略此邮件地址并且不得就地址语法违规进行抗议

EDIINT-Features

指示发起方系统所支持的功能。BizTalk 将使用此标头来指示支持多个附件

值:MA”

Receipt-Delivery-Option

指示应向其发送 MDN URL。如果 Receipt-Delivery-Option 出现,则 Disposition-notification-to 用作对异步 MDN 的请求。Receipt-Delivery-Option 必须始终附带 Disposition-Notification-To

如果 Receipt-Delivery-Option 没有出现同时 Disposition-notification-to 出现,则 Disposition-notification-to 用作对同步 MDN 的请求

值:URL 字符串。

signed-receipt-protocol
(位于 Disposition-Notification-Options

如果设置为pcks7-signature,则用于从接收方请求签名回执,并指示应返回给请求方的签名回执的格式

值:optional,pcks7-signature

signed-receipt-micalg
(位于 Disposition-Notification-Options

请求方用于对返回的回执进行签名的首选 MIC message integrity check)算法列表。接收方应从左至右遵守此 MIC 算法列表

值:optional,MD5 ,SHA1

message-id

 

每个AS2消息的唯一id

Original-Message-Id

 

仅限 MDN,指示这个MDN是对应到哪个原始AS2

Content-Disposition

 

用于指定邮件阅读程序处理数据内容的方式,有inlineattachment两种标准方式,inline表示直接处理,而attachment表示当做附件处理。

content-type

 

Content-type: multipart/signed
Content-Type: multipart/report
Content-type: message/disposition-notification
Content-Type: application/PKCS7-signature
Content-Type: application/PKCS7-mime
Content-Type: application/EDI-X12
Content-Type: application/EDIFACT
Content-Type: application/edi-consent
Content-Type: application/XML

 

3、AS2-上下文属性

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

名称

AS2From

string

包含表示发送方名称的 AS2-From AS2 标头值

AS2PayloadContentType

string

包含负载消息的内容类型

AS2To

string

包含表示接收方名称的 AS2-To AS2 标头值

DispositionMode

string

包含 MDN 处置模式值

若要生成 MDN,必须同时升级此上下文属性和 DispositionType 上下文属性。

DispositionType

string

包含 MDN 处置类型值

若要生成 MDN,必须同时升级此上下文属性和 DispositionMode 上下文属性。

IsAS2AsynchronousMdn

boolean

指示消息是异步 MDN

IsAS2FailedMessage

boolean

指示传入 AS2 消息在 AS2 中处理失败,导致负载消息挂起

IsAS2Http200OKResponse

boolean

对将作为 HTTP 200 OK 响应消息生成的消息设置此属性。它用于不会为 AS2 消息生成 MDN 或已异步发送 MDN

IsAS2MdnResponseMessage

boolean

指示消息是一个 MDN 响应消息

IsAS2MessageDuplicate

boolean

指示以前已收到传入 AS2 消息

IsAS2MessageCompressed

boolean

指示传入 AS2 消息是经过压缩的消息

IsAS2MessageEncrypted

boolean

指示传入 AS2 消息是经过加密的消息

IsAS2MessageSigned

boolean

指示传入 AS2 消息是经过签名的消息

IsAS2PayloadMessage

boolean

指示该消息包含解码的 AS2 消息内容,且应作为负载处理

MDNAsyncURI

string

包含Receipt-Delivery-Option值,该值用于发送异步 MDN 响应消息

MessageID

string

包含 AS2 AS2 消息的头部中所包括的消息 ID

OriginalMessageId

string

包含原始 AS2 消息的消息 ID。该上下文属性是 MDN 消息的一部分,用于将 AS2 消息与其 MDN 响应相关

PreservedFileName

string

包含消息的原始文件名。只有传入消息包含文件名信息作为 Content-Disposition MIME 标头的一部分,才会填充此上下文属性

SendMDN

boolean

如果应当生成 MDN 消息,则设置为 True

 

Biztalk AS2开发经验总结

原文:http://www.cnblogs.com/chnking/p/6490735.html

(0)
(0)
   
举报
评论 一句话评论(0
关于我们 - 联系我们 - 留言反馈 - 联系我们:wmxa8@hotmail.com
© 2014 bubuko.com 版权所有
打开技术之扣,分享程序人生!