Biztalk AS2開發經驗總結

時間 2019-11-06

原文原文鏈接

AS2（Applicability Statement 2）是在互聯網上安全可靠地傳輸數據的標準規範。它經過使用數字證書對傳輸的信息進行簽名、加密保障傳輸數據的安全性。vue

AS2一般採用HTTP或HTTPS協議，通常使用「POST」方法向對方發送數據。正則表達式

AS2規定了一組標準，來規範通信雙方經過HTTP協議安全的交換數據。算法

這組標準包含了若是對消息進行數字簽名來確認發送放的身份，如何對數據加密來保證數據的安全性，在發送方發送了消息後接收方接收到是否要返回MDN（Message Delivery Notification），以及MDN是同步返回仍是異步返回。數據庫

1、 BizTalk對AS2的支持

BizTalk對提供 AS2 支持的固有功能，它不是產品的外接程序，例如適配器或加速器，它內置於產品之中。瀏覽器

一、BizTalk Server提供的AS2功能

BizTalk Server 使用 AS2 定義方法來發送、接收和驗證消息。 BizTalk Server 有助於確保經過加密、簽名和壓縮的數據傳輸的安全性。 BizTalk Server 使用加密密鑰、數字簽名和證書來實現這一目的。安全

經過 BizTalk Server，你能夠將傳入和傳出的 AS2 消息保存在不能否認的存儲位置。包括在保存編碼或解碼的 AS2 消息和保存 MDN 時，都需這麼作。服務器

BizTalk Server 提供了將附件文件名保留爲 AS2 消息的一部分的能力。架構

BizTalk Server 使你可以檢查重複的傳入消息。併發

既能夠經過與確認消息時使用鏈接相同的鏈接同步返回 MDN，也能夠經過不一樣的鏈接異步返回 MDN。app

若是在指定時間段內未接收到 MDN，你能夠從新發送 AS2 消息。

BizTalk Server 可提供特定於 AS2 的狀態報告。這些報告提供了 AS2 傳輸的全面狀態，其中也包括與交換有關的確認狀態。

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

BizTalk Server 使你可以經過定義每一個協議的證書來覆蓋 AS2 消息的默認簽名證書。

二、AS2跟EDI的關係

EDI也是BizTalk的內建功能，並且二者常常一塊兒使用，因此有必要理一下AS2和EDI二者之間的關係。

AS2是一個通信標準，給交換數據的雙方提供安全的通信環境，它只保證通信雙方的數據在公網上安全的傳輸，並不關心數據自己是什麼。打個比方，AS2就是在雙方之間構建了一條全封閉的高速公路，保證雙方在這條路上跑的各類各樣的車能安全可靠的到達對方。

EDI是電子數據格式的標準，是用來定義數據自己的，遵循一樣EDI標準的雙方可以理解對方的數據，知道對方數據的業務含義。對應AS2比如是建好了安全的告訴公路，EDI就是定義了在能夠在這條路上跑的一種標準規格的車輛。

安全高速路上能夠跑各類車，既能夠跑EDI這樣的標準規格的車，也能夠跑任何其餘類型的車。反過來，EDI標準的車能夠跑在AS2這個安全高速路上，也能夠跑在其餘安全或不安全的高速路或者國道甚至鄉間小路。

可見AS2和EDI之間只是一種路和一種車之間的關係，他們能夠結合在一塊兒用，也能夠絕不相關。

2、配置證書

證書能夠購買也能夠本身簽發，通常商業環境最好使用從權威證書頒發機構購買的證書。若是使用自簽發證書能夠參考附錄一《申請證書》

一、爲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 解碼器，則不必定是這樣。

二、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

3、反向代理

有的公司對安全規定比較嚴格，BizTalk server不容許直接接觸外網和配置外網IP，這就致使biztalk的HTTP接收端口不能直接放在公網上接收客戶發送的消息，須要有個在DMZ區域的中轉服務器的HTTP接收端口接收請求後，再轉發到內網的biztalk HTTP接收端口。

解決方案就是，在DMZ區的中轉服務器上使用反向代理，將收到的HTTP請求轉發到內部IP的biztalk server的http接收端口。微軟的Request Routing Version就是一款合適的Reverse Proxy軟件。

一、安裝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請求轉發。

二、新建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。

三、新建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

4、 IIS配置BizTalk接收位置（BTS ISAPI 篩選器）

要使用BizTalk的HTTP接收端口，必須在IIS作相應配置，使BizTalk的HTTP的接收位置能夠跟IIS接收的http消息關聯起來。

在BizTalk服務器上的配置IIS，通常每一個partner設置一個IIS Application，分別設置每一個partner的ISAPI。

一、新建Application Pool

爲partner新建一個Application Pool：

在這個Application Pool的Advanced Settings…中修改：

Enable 32-Bit Applications 須要設置爲true。

Identity須要設置爲在BizTalk Isolated Host Users組的帳號。

二、新建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」做爲謂詞:

5、通用設置

一、日誌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字段也會爲空。

6、接收方MDN生成過程

MDN是在接收方的AS2EDIReceive 或 AS2Receive 接收管道的拆裝器管道組件中生成的，生成過程以下：

一、肯定是否返回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。

二、接收管道生成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發送端口訂閱。

三、發送管道組裝MDN消息過程

同步MDN時的接收端口的發送部分，異步MDN時的單獨HTTP單向發送端口訂閱了MDN消息後，在發送管道組裝MIME格式的MDN消息返回給AS2消息發送方，如何組裝MIME格式的MDN消息參看《根據消息屬性組裝MIME格式的MDN消息》。

注意：

接收管道中組裝MIME格式的MDN消息保存到NRR和發送管道中組裝MIME格式的MDN消息是兩個獨立過程，全部生成的MDN消息會有一些差別，表現爲MIME的.boundary和MIME消息每一部分的Content-ID不一樣，參看《訂閱同步返回的MDN消息的發送端口》後的第二個注意部分。

7、 AS2數據和MDN數據的樣例

一、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 header，post的內容就是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

...*.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消息數據格式分析（簽名、加密）

二、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_--

8、 AS2傳輸非EDI數據的設置

一、發送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雙向發送端口名

二、接收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的對比，實質內容是同樣的：

三、發送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)

對於異步MDN情形，MDN是由單獨的單向HTTP接收端口接收，在接收管道會處理收到的MDN，更新數據庫中AS2消息的MDN狀態，因此MDN消息不是必須發佈到MessageBox再路由消息了。

Request MDN：此項打鉤，表示須要對方返回MDN。

Request singned MDN：是否要求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

四、接收AS2數據，異步發送MDN

4.1. Agreement協議設置

Partnerà自身單項協議中，作以下設置（其餘保持默認值）：

4.1.1. Validation

Encryption algorithm：加密算法，接收方的這個設置無心義，biztalk會根據加密的AS2消息信封內指示的加密算法進行解密。

4.1.2. Acknowledgments(MDNs)

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

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消息。

9、 AS2傳輸EDI數據

（內容暫缺）

10、注意事項

一、修改Agreement後可能須要重啓IIS Application Pool

修改了Agreement後，若是修改內容影響到HTTP接收位置的動做，好比原來Agreement設置本身這一方接收AS2消息，不返回MDN，改成要同步返回MDN，則須要從新啓動承載這個HTTP接收位置的IIS Application Pool，不然更改不會生效。

二、修改Agreement後可能須要重啓運行發送端口的Host instance

修改了Agreement後，若是修改內容影響到HTTP發送端口的動做，那麼運行這個發送端口的Host instance須要從新啓動，不然更改不會生效。

11、測試手段

一、經過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：

二、使用Wireshark抓數據包分析AS2的HTTP通信數據

12、故障排除

一、發送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數據表。

二、若是AS2負載消息的發送端口忘記放在agreement單向協議的Send Ports列表中

發送方用這個發送端口發送AS2消息時，發送端口會掛起，掛起緣由：

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

三、若是使用了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位的便可。

四、接收方返回的MDN中的Received-Content-MIC值不對

五、接收方收到加密的AS2消息後若是解密失敗，在AS2/MDN狀態報告中找不到此消息

六、接收方的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。

七、發送方的消息簽名用錯證書

若是發送方發送的消息用錯證書，在接收方將驗證簽名時不經過，也不會把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.

十3、附錄

一、申請證書

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. 申請證書

二、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		用於指定郵件閱讀程序處理數據內容的方式，有inline和attachment兩種標準方式，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

三、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 處置模式值。
DispositionMode	string	若要生成 MDN，必須同時升級此上下文屬性和 DispositionType 上下文屬性。
DispositionType	string	包含 MDN 處置類型值。
DispositionType	string	若要生成 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開發經驗總結

1、 BizTalk對AS2的支持

一、BizTalk Server提供的AS2功能

二、AS2跟EDI的關係

2、 配置證書

一、爲AS2配置證書

二、SSL證書配置

2.1. BizTalk做爲服務端接收partner的消息

2.2. BizTalk做爲客戶端向partner發送消息

2.2.1. 服務端證書

2.2.2. 客戶端證書

3、 反向代理

一、安裝ARR

二、新建Application Pool

三、新建IIS Application

4、 IIS配置BizTalk接收位置（BTS ISAPI 篩選器）

一、新建Application Pool

二、新建IIS Application

5、 通用設置

一、日誌report和NRR數據記錄

1.1. 日誌report

1.2. NRR數據記錄

6、 接收方MDN生成過程

一、肯定是否返回MDN、MDN同步仍是異步、MDN是否要求籤名

1.1. 依據HTTP Header的設置：

1.2. 依據Agreement的設置：

二、接收管道生成MDN消息過程

2.1. 生成的主要屬性

2.1.1. OriginalMessageId

2.1.2. EdiIntAS.DispositionMode

2.1.3. EdiIntAS.DispositionType

2.1.4. MicHashAlgorithm

2.1.5. ReceivedContentMic

2.1.6. EdiIntAS.IsAS2AsynchronousMDN

2.1.7. MDNAsyncURI

2.2. 根據消息屬性組裝MIME格式的MDN消息

2.2.1. MDN消息第一部分

2.2.2. MDN消息第二部分

A ) 原始AS2消息的MessageID

B ) 消息接收處置結果

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

2.3. 建立AS2/MDN狀態記錄和組裝MDN消息保存到NRR數據庫

2.4. 接收管道路由MDN消息

三、發送管道組裝MDN消息過程

7、 AS2數據和MDN數據的樣例

一、AS2消息

1.1. AS2消息不簽名不加密

1.2. AS2消息簽名不加密

1.3. AS2消息不簽名加密

1.4. AS2消息簽名加密

1.5. AS2消息數據格式分析（簽名、加密）

二、MDN消息

2.1. MDN不簽名

2.2. MDN簽名

8、 AS2傳輸非EDI數據的設置

一、發送AS2數據，同步接收MDN

1.1. Agreement協議設置

1.1.1. Validation

1.1.2. Acknowledgements(MDNs)

1.1.3. Send Ports

1.2. 用於向對方發送AS2的雙向HTTP發送端口

1.2.1. HTTP adapter設置

1.2.2. 管道設置

1.2.3. 發送重試次數和時間間隔。

1.3. 訂閱同步返回的MDN消息的發送端口

二、接收AS2數據，同步返回MDN

2.1. Agreement協議設置

2.1.1. Validation

2.1.2. Acknowledgments(MDNs)

2.1.3. Local Host settings—Receiver MDN Settings

2.2. 接收AS2消息的HTTP雙向接收端口設置

2.2.1. HTTP Adapter設置

2.2.2. 管道設置

2.3. 訂閱AS2負載消息供後續步驟處理的發送端口

2.4. 訂閱同步返回的MDN消息用於備份的發送端口

三、發送AS2數據，異步接收MDN

3.1. Agreement協議設置

3.1.1. Validation

3.1.2. Acknowledgements(MDNs)

3.1.3. Send Ports

2、配置證書

3、反向代理

5、通用設置

6、接收方MDN生成過程

10、注意事項

11、測試手段

12、故障排除

十3、附錄