Share via

Microsoft BizTalk Accelerator for RosettaNet (BTARN) 的已知問題

  • 發行項

本節包含實用資訊，可協助您避免 Microsoft® BizTalk Accelerator for RosettaNet (BTARN) 錯誤。 已知的問題可分為以下各類：

  • 0A1 失敗通知

  • 商業活動監控 (BAM)

  • 安裝和設定

  • 其他

0A1 失敗通知

BTARN 不會對 CIDX 程序組態屬性與 0A1 協議屬性執行跨欄位驗證。

BTARN 不會防止您將進程組態設定檔的 「Standard」 屬性設定為 「CIDX」，在您使用該設定檔將協定的 「0A1 合約」 屬性設定為 「0A1」 之後，即使 CIDX 不支援 0A1 合約也一樣。

商務活動監控

商務活動監控報告中出現重複的欄位資料

在 BAM 活動 Web 報告中的 ActivityID 與 PIPInstanceID 資料欄位，包含相同的內容。 此資料正確地反映交易夥伴介面程序 (PIP) 執行個體識別碼。 ActivityID 用這個值進行內部相互關聯。 您可以忽略此訊息。

商務活動監控 Web 報告中出現空白資料欄位

商務活動監控 (BAM) Web 報告內沒有 0A1 訊息程序的任何資料。 Web 報告中的 0A1 訊息欄都是以「初始化的 0A1」進行硬式編碼。

安裝和設定

BizTalk 應用程式使用者群組以及 BizTalk Server Administrator 群組中的群組與使用者，必須位於同一個網域中

BTARN 支援將群組新增至 BizTalk 應用程式使用者群組或BizTalk Server Administrators 群組。 但隸屬於「BizTalk 應用程式使用者」群組或「BizTalk Server 系統管理員」群組的個別使用者帳戶與群組，都必須位於同一個網域中才行。

如果先移除BizTalk Server，BTARN 卸載就會失敗

如果您在移除 BTARN 之前移除BizTalk Server，BTARN 移除程式就會失敗，而不會發生錯誤。 若要解決此問題，請重新安裝並重新設定BizTalk Server，然後移除 BTARN。

分散式部署需要有網域控制站

例如，在多伺服器環境中部署 BTARN 需要網域控制站，例如，當您在一部伺服器上安裝 BTARN，以及用於在另一部伺服器上設定的SQL Server資料庫時。

不支援自訂 PIP 組態

目前的 BTARN 版本不支援使用自訂元素或其他非 RosettaNet 標準資訊來設定 PIP。

BTARN 自動啟動單一登入服務

BTARN 會在 BTARN 要求它且 SSO 服務未執行時，自動啟動單一 Sign-On (SSO) 。

未對預設網站設定 WebApps 時，組態程式不會從排除的路徑清單移除 BTARN 虛擬目錄

如果您取消設定將 Web 應用程式虛擬資料夾設定為 SharePoint Server 的 BTARN 安裝，而不是預設網站，在取消設定之後，您必須從 SharePoint 管理中心網站的 [排除路徑] 清單中手動移除 btarnapp 和 btarnHTTPreceive 虛擬目錄。 發生這種情況是因為在設定 Web 應用程式虛擬資料夾為 [SharePoint Server] 時，您必須將 btarnapp 和 btarnhttpreceive 以手動方式加入到排除的路徑清單。 組態程式不會從排除的路徑清單自動移除它們。

其他

BTARN 可接收用任何一種加密演算法加密的訊息

BTARN 接收管線會接收和解密訊息，即使用來加密訊息的通訊協定和此欄位中的編碼設定不相符也一樣。 因此，BTARN 會接收以 RC2-40 或 3DES 加密的訊息。

在單向動作同步實例中，BTARN 需要收到信號

在單一動作同步案例中，BTARN 一律會預期並產生訊號。 此行為與 RosettaNet 規格的定義不同。根據 RosettaNet 規格，在單向動作同步實例中，信號可以為必要或非必要。 如果 BTARN 是回應者，它一律會產生訊號以回應來自啟動器的訊息。 如果 BTARN 是啟動器，則一律會預期回應者傳回訊號。 如果 BTARN 未收到訊號，它會在進程組態設定中 屬性中指定的 Time To Perform 間隔之後逾時，並產生 0A1 訊息。

BTARN 可以接收 UTF-16 的訊息

BTARN 會接收和處理具有 UTF-16 字元集的訊息。 BTARN 會傳送具有 UTF-8 字元集的訊息。

從要求訊息對應的回應訊息中，其命名空間必須加以刪除

若您在雙向動作實例的私用程序中使用 BizTalk 對應工具，BizTalk 對應工具將會在對應要求訊息的回應訊息執行個體中，新增命名空間至部分項目標記。 這些命名空間會導致傳送管線的失敗。 您必須移除這些命名空間。 請用 HeaderHelper 範例進行這項作業。 如需詳細資訊，請參閱雙重動作 PIPAutomation 協調流程 [RN3]和步驟 4：建立 HeaderHelper 專案 [RN3]。

變更 URI 設定需要使用 IISRESET

執行安裝程式時，您會設定接收與傳送 .aspx 頁面要使用的 URI 設定，以及接收配接器與傳送配接器的 URI 設定。 如果您變更了 .aspx 頁面或配接器所在電腦的電腦名稱，就必須變更這些設定。 您可以重新執行組態程序以變更這些設定，但是這麼做將需要重設所有的組態設定。 您可以藉由變更相關聯的登錄機碼 (AsyncReceivePortURI 、 RNIFSenderURI 和 SyncReceivePortURI) ，單獨變更 URI 設定。 變更上述任何一項登錄機碼設定之後，您必須執行 IISRESET，變更才會生效。 這是因為 BTARN 會快取其使用的設定。 執行 IISRESET 後，還必須重新啟動 BizTalk 服務。

BTARN 不會對 RNIF v1.1 列舉強制執行限制條件

RosettaNet 實作架構 (RNIF) Specification v1.1 指定某些 RNIF 架構列舉的限制。 BTARN 不會強制執行這些限制，也不會針對這些限制進行驗證。 這些限制不適用於 RNIF v2.01。

上述原則適用於下列服務標頭項目：

  • GlobalBusinessActionCode

  • GlobalPartnerClassificationCode

  • GlobalBusinessServiceCode

  • GlobalProcessCode

  • GlobalProcessIndicatorCode

  • VersionIdentifier

PerformanceControlRequest 參數不會覆寫預設的程序組態設定

傳入訊息可以包含 PerformanceControlRequest 服務標頭中的參數。 這些參數包括 [認可 (回條) ] 和 [執行時間] 時間延遲參數的值，如 BTARN 管理主控台中所做的程式組態設定中所設定。 BTARN 不會根據 PerformanceControlRequest 傳入訊息中的參數動態設定時間延遲。 BTARN 一律需要進程組態設定中所設定的預設 PIP 值所花費的時間延遲。 這符合 RosettaNet 實作架構 (RNIF) 規格 v1.1。

雙向動作訊息的 PIP 名稱與 PIP 版本有區分大小寫

如果 PIP 名稱和 PIP 版本的回應訊息大小寫與原始雙動作要求訊息的對應值不同，啟動器 BTARN 會將回應訊息拒絕為無效，並將例外狀況傳回給回應者。

當有作用中的程序時，BTARN 不支援變更協議設定。

當您按一下 [ 套 用] 或 [ 確定 ] 接受合約屬性時，將會立即套用合約屬性的變更。 在您更改了協議之後，只要牽涉到該協議的執行中程序或新程序，其中的所有新活動都會使用變更過的協議屬性。 在您變更協議的同時，如果有正在執行的程序，此程序可能已經對訊息使用了先前的協議屬性。 然而，這個程序的新訊息會使用新的協議設定，這樣將導致無法預測的後果。 建議您最好在沒有執行任何程序時，才對協議設定進行變更。

變更了程序組態設定檔之後，BTARN 並不會執行跨欄位驗證

當您建立進程組態設定檔，然後建立合約時，BTARN 會執行跨欄位驗證，以確保合約和設定檔的屬性相容。 例如，若設定檔的「標準」屬性設為「CIDX」，BTARN 就會檢查協議的「0A1」協議屬性是否設為「No 0A1」。 不過，如果您在建立合約之後變更進程組態設定檔，BTARN 不會執行跨欄位驗證。 如果您將 Standard 屬性從 「RosettaNet」 變更為 「CIDX」，BTARN 不會驗證合約的 0A1 合約屬性已設定為 「No 0A1」。

如果協調流程並未全部啟動，就會發生錯誤

BTARN 安裝程式會安裝九個協調流程。 若要讓 BTARN 順利處理訊息，您必須先系結、登記和啟動這九個協調流程，再起始處理。 For more information, see the "Orchestration Management in BizTalk Explorer" or "Managing Orchestrations" topics in BizTalk Server Help.

RNIFReceive.aspx 並未刪除訊息的 MIME 下界限

當 RNIFReceive.aspx 頁面從夥伴的 RNIFSend.aspx 頁面接收訊息時，該訊息中會含有 MIME 標頭與以及 MIME 上下界限 (base 64 數字)。 RNIFSend.aspx 會為 RNIF 傳輸，新增標頭與界限至訊息。 RNIFReceive.aspx 提交訊息至公開程序前，應移除訊息中的 MIME 標頭與界限。 RNIFReceive.aspx 會移除 MIME 標頭與上界限，但不會移除下界限。 遺留的下界限，並不會影響在公開程序中的訊息處理。

BTARN 不支援要區分大小寫的 SQL Server 資料庫組態

如果您讓 BTARNSQL Server 資料庫和資料庫物件區分大小寫，BTARN 管理主控台找不到資料庫資源並擲回例外狀況。 BTARNSQL Server 資料庫和資料庫物件必須不區分大小寫。

資料庫維護指令碼中的所有查詢都必須使用 UTC 時間

BTARN SQL Server資料庫使用 UTC (通用時間座標) 時間，因此您必須針對 UTC 時間撰寫任何建立維護這些資料庫的查詢。 例如，如果您的維護腳本是使用 GetDate() 命令，您應該將其變更為 GetUTCDate() 。

PublicResponder 協調流程會拒絕重複的要求動作訊息

PublicResponder當協調流程 (PublicResponderV11.odx) 收到重複的要求動作訊息時，它會在事件記錄檔中記錄警告，然後拒絕訊息。 在回應者協調流程完成後，若收到重複的訊息，由於已經沒有任何訂閱，因此 BizTalk Server 會停止該訊息。

公開程序停止後，傳輸錯誤不會顯示在 BAM 中

當公開程序協調流程處理其最終訊息時，若發生傳輸錯誤，事件日誌與 HAT 會顯示錯誤，但 BAM 不會顯示該項錯誤。 這是因為協調流程已停止，因此 BAM 無法顯示訊息。

pipeline.exe 工具不能用來對 BTARN 接收管線進行偵錯

要對接收管線進行偵錯，則必須建立裝載該管線的連接埠， 您無法使用BizTalk Server提供的 pipeline.exe 工具進行偵錯。

可能因為重試訊息在協調流程完成後才成功處理完畢而產生錯誤

BTARN 會使用協調流程來代表進程流程。 在某些情況下，會重試數個重試的訊息，協調流程可能會在重試的訊息抵達 BizTalk MessageBox 之前順利完成。 發生此行為時，BizTalk Server會產生對應的「已完成但已捨棄」錯誤訊息。 此時應該查看商務營運系統 (LOB) 應用程式，才能判斷該程序是否已經完成。 如果 LOB 應用程式表示程序已成功完成，您就可以忽略「完成但捨棄」訊息。

從 tracking.xls 匯出的 XML 檔案可能含有不正確的欄位

當您在追蹤 XLS 檔案內定義新的追蹤檢視，並從這個追蹤 XLS 檔案匯出 XML 檔案時，某些欄位的名稱可能會被稍微修改。 若要修正此問題，請根據 BTARN 安裝程式所安裝的標準 tracking.xml 欄位，確認自訂追蹤 XML 檔案中的欄位。

信號和回應的 RNIF 1.1 服務標頭結構描述可能需要修改

BTARN 隨附現用的所有 RosettaNet 標頭架構。 某些實作使用 [信號控制] 和 [動作控制] 節點的方式較為不同，如下所述。

BTARN 現成隨附訊號控制元素，如下所示。 請注意，以下也可能適用於「動作控制」項目。

<!ELEMENT SignalControl (  
          InstanceIdentifier,  
          PartnerRoute,  
          SignalIdentity,  
          inResponseTo)>

如果您的解決方案需要的是上述序列，您就不需要作任何動作。

但是某些實作是使用下列程式碼：

<!ELEMENT SignalControl (  
          inResponseTo,  
          InstanceIdentifier,  
          PartnerRoute,  
          SignalIdentity)>

如果您的解決方案需要這個序列，請參閱 KB 889523。 此軟體更新將會變更對應的 XML 結構描述。 請注意，這個更新只會影響 RNIF 1.1 程序。

PipAutomationGetAction SQL 預存程序需要更新

您必須更新 PipAutomationGetAction SQL 預存程序，才能鎖定單一記錄。 刪除下列幾行：

IF @@ERROR <> 0  
    UPDATE MessagesToLOB SET Delivered = -1 WHERE MessageID = @tempGUID

以下才是正確的 PipAutomationGetAction 預存程序：

CREATE PROCEDURE PipAutomationGetAction  
AS  
 SET TRANSACTION ISOLATION LEVEL READ COMMITTED  
BEGIN TRANSACTION  
DECLARE @tempGUID nvarchar(36)  
SELECT TOP 1 @tempGUID = MessageID FROM MessagesToLOB WITH (READPAST,UPDLOCK,ROWLOCK)  
   WHERE Delivered = 0 AND MessageCategory = 10  
  ORDER BY TimeCreated  
  SELECT PIPInstanceID,DestinationPartyName,SourcePartyName,PIPCode,PIPVersion, ServiceContent FROM MessagesToLOB  
   WHERE MessageID = @tempGUID  
For xml auto  
UPDATE MessagesToLOB SET Delivered = 1 WHERE MessageID = @tempGUID  
 COMMIT TRANSACTION  
GO

您可以自訂 aspx 程式碼以傳回錯誤描述

如果您需要記錄或傳送錯誤描述，可以自訂 aspx 程式碼，將實際的文字放在回應中傳回， 若要這樣做，請使用 HttpResponse.Status (，這是內部 asp 要求的回應物件) 或 HttpWebResponse.StatusDescription (，這是 .NET 呼叫 HttpWebRequest 物件的 GetResponse 方法) 。 若要從其中一個適用的回應物件傳回傳回值，請設定 Response.Status 值，類似于在 BTARN 隨附的 aspx 程式碼中設定 Response.StatusCode 的方式。

如果編碼方式設定為 Base64，就無法從不可否認性資料表中讀出純文字的 RNIF 1.1 訊息

這種狀況只有在編碼方式設定為 Base64 時才會發生。 當編碼方式設定為 quoted-printable 或 8-bit 時，可以從不可否認性資料表中讀出純文字的訊息。 您必須將訊息檔案存成 *.eml 副檔名，然後使用 Outlook Express 開啟檔案讀取訊息，這樣 Outlook Express 就會幫您把這個訊息解碼。 您也可以利用以下的程式碼，從不可否認性資料表中讀取以 Base64 方式編碼的訊息。

byte[] textBytes = Convert.FromBase64String(txtEncodedText.Text);  
string plainText = Encoding.UTF8.GetString(textBytes);  
txtOutput.Text = plainText;

另請參閱

疑難排解與已知問題