EDI 批次處理的已知問題
本主題描述 BizTalk Server 中批處理的已知問題。
即使子檔批注設定為 [是]，仍不會執行子檔分割
徵兆
即使該交換的 HIPAA 架構內的subdocument_creation_break註釋設定為 「是」，HIPAA 交換也不會分割成子檔。
可能的原因
傳送物件的 [輸入批處理] 選項已設定為 [保留交換]。如果是這種情況，即使 HIPAA 架構內的subdocument_creation_break註釋設定為 「是」，HIPAA 檔也不會分割成子檔。
subdocument_break註釋已設定為 「Yes」，但subdocument_creation_break批註未設定為 「Yes」。
解決方法
在傳送物件的 [EDI 屬性] 對話方塊的 [驗證和 ACK 產生設定] 頁面中，將 [輸入批處理] 選項屬性設定為 [分割交換為交易集 ] – 在 [錯誤時暫停交易集] 或 [分割交換為交易集 – 暫停發生錯誤的交換]。
除非 subdocument_creation_break 註解設為 [是]，否則 HIPAA 文件不會分割成子文件。
如果在批次協調流程啟動時變更批次組態設定，驗證批次可能會失敗
當批次處理協調流程正在處理批次時，如果變更批次組態設定，該批次將不會套用新的組態設定。 這可能會在傳送管線中產生驗證錯誤。
這些設定位於 [EDI 屬性] 對話方塊的 [Batches] 頁面中。
若要解決這個問題，請重新啟動與批次處理協調流程相關的主控件執行個體。 這會讓批次組態設定的變更立即生效。
BatchControlMessageRecvLoc 接收位置只能在 32 位元電腦或 64 位元電腦上的 WOW 執行
SQL 配接器只能在 32 位元電腦或 64 位元電腦的 WOW64 模擬器下運作。 因此，由安裝程式安裝並使用 SQL 配接器的 BatchControlMessageRecvLoc 接收位置也只能在 32 位元電腦或 64 位元電腦的 WOW 下運作。 批次處理需要使用此接收位置。
在 64 位元電腦上的 WOW 下執行 BatchControlMessageRecvLoc 接收位置時，請在不同的主機中執行批次處理協調流程。 如果與接收位置在同一個主機上執行，則批次處理協調流程也會在 WOW 下執行，那麼就失去了在 64 位元電腦上執行的優勢。
批次可能會由非指定的傳送埠取用
當批處理協調流程發佈交換時，它會升級兩個屬性：ToBeBatched = False 和 DestinationPartyName = <PartyName>。 訂閱其中一個屬性或兩個屬性都訂閱的傳送埠可以取用這些批次交換。 請確定已設定傳送埠的篩選條件，好讓傳送埠選取應該取用的批次交換。
雖然批次項目計數大於批次所需的交易集數，仍可能不會提示批次釋放
如果批次釋放準則是根據群組或交換的交易集數目為基礎，即使批次項目計數大於釋放批次所需的交易集數目，仍可能不會釋放批次。 如果您啟用通知，並設定批次篩選條件準則將這些通知加入批次，就可能會發生這種情況。 在這種情況下，群組 (或交換) 中的批次項目數目將大於群組 (或交換) 的交易集數目。 這時，如果群組 (或交換) 的交易集數目小於批次釋放所需的數目，但同時批次項目數目又可能大於批次釋放所需的交易集數目，那麼將不會釋放批次。
按一下啟動時沒有儲存任何批次項目
徵兆
在合作物件的 [Batches] 頁面中按兩下 [開始 ] 時，不會收集批次的訊息。
可能的原因
按兩下 [ 開始 ] 日期時間早於 [ 啟用 ] 區段中輸入的日期時間。 因此，協調流程實例已啟動，但未收集批次的訊息。 如需詳細資訊，請參閱 設定傳出批次。
解決方法
針對遇到此問題的批次組態，按兩下 [批次] 頁面中的 [ 停止 ]。 將 [啟用] 設定為 [立即啟動]，或輸入早於目前時間的日期時間，然後按兩下 [開始]。 當系統提示您將 [開始日期 時間] 重設為目前時間時，按兩下 [ 確定]。 BizTalk Server 這時便會開始收集批次的訊息。
EDIFACT 批次中的位元組數目可能會視使用的字元集而定
某些 EDIFACT 字元集中的字元可能是雙位元組字元，而其他 EDIFACT 字元集中的字元則可能是單一位元組字元。 因此，當您根據交換中的字元數來設定批次的釋放準則時，交換中的位元組數可能會根據使用的字元集而有所不同。
字元 “<” 和 “&” 必須以批次信封中的編碼格式來表示
BizTalk Server 在建立批次 EDI 交換的信封欄位時，不支援其常值格式的下列字元：“<” 和 “&”。
如果使用 EdiSend 管線序列化交換，則若在外寄批次交換的信封欄位中使用其中任一字元的常值，將會導致訊息遭擱置。
如果需要在批次的信封欄位中使用上述其中一個字元，當您在「BizTalk 系統管理員」中設定信封欄位時，可以使用下表中經過適當編碼的值：
| 字元 | 編碼 |
|---|---|
| < | < |
| & | & |
當您使用其中一種編碼形式時，當 BizTalk Server 驗證合作夥伴合約管理員中的欄位長度限制時，編碼窗體中的每個字元都會計算為個別字元， (BizTalk Server 管理控制台中的 PAM) 畫面。 例如，即使編碼 「<代表批次 EDI 交換中的單一字元 」<，BizTalk Server 根據特定欄位的長度限制進行驗證時，會將這視為四個字元。 只有 PAM 才會發生此問題，「EDI 組合器」則無此問題。
執行升級批次協調流程期間發生執行
徵兆
使用設定EDI的自定義管線元件時。傳入檔的 DestinationPartyId 屬性，您可能會在應用程式事件記錄檔中收到錯誤，指出在執行升級批次協調流程期間發生例外狀況。
可能的原因
如果 ErrorMessage =「找不到批次」，此錯誤表示升級批次協調流程無法成功識別內送文件的批次。
解決方法
升級批次協調流程會使用 EDI。DestinationPartyId 以查閱合作對象名稱。 接著使用這個合作對象名稱、EDI.EncodingType 與字串 “Default” 建構一個字串，然後尋找具有相符批次名稱的批次組態。 如果此名稱沒有批次組態存在，就會將此錯誤記錄到應用程式事件記錄檔，並暫停協調流程實例。
注意
例如，如果合作對象名稱為 Contoso，EDI.EncodingType 為 X12，則協調流程會尋找名為 ‘ContosoX12Default’ 的批次。
若要解決此問題，請確定批次存在且名稱符合升級批次協調流程所建構的字串。
標示為 EDI 的訊息。ToBeBatched = True 和 EDI。DestinationParties 已暫止
徵兆
使用自定義管線元件來透過設定 EDI 來標記訊息以進行批處理時。ToBeBatched = True 和 EDI。DestinationParties 到合作對象標識符清單，訊息將會暫停，並顯示路由失敗，指出沒有訂閱者。
可能的原因
在舊版 BizTalk Server 中，當訊息應該由多個批次組態處理時，您會設定 EDI。DestinationParties 屬性為以空格分隔的合作對象標識符清單。 路由協調流程會訂閱具有 EDI.ToBeBatched = True 與 EDI.DestinationParties 屬性的訊息，並使用 EDI.DestinationParties 屬性中包含的合作對象識別碼清單為每個識別碼建立訊息，然後將訊息傳遞給批次處理協調流程。 使用合作物件標識碼來判斷批次，因為每個合作物件組態只能有一個批次組態。
在 BizTalk Server 中，每一方都可以有多個批次設定，因此不再足以只使用剖析標識符來判斷要使用的批次組態。 若要指出訊息必須由多個批次組態處理，訊息必須具有EDI。BatchIDs 屬性會設定為應傳送訊息之批次標識碼的空間分隔清單。
注意
處理僅使用EDI以單一合作物件標識符標示的訊息時。DestinationPartyId 屬性，訊息將由升級批處理協調流程處理。 如需詳細資訊，請參閱 組合批次的EDI交換。
解決方法
升級自定義管線元件，使其設定EDI。BatchIDs 屬性，而不是 EDI。DestinationParties。 您可以在每一方 EDI 屬性的 Batches 設定頁面上找到特定批次的批次識別碼。
注意
如果使用 BatchMarker 管線元件來標記訊息以進行批處理，就不會發生此問題。
批次篩選重新整理逾時已硬式編碼為15分鐘
修改批次篩選準則時，變更生效前需要 15 分鐘的時間。 無法修改此重新整理間隔。 若要讓篩選立即生效，請重新啟動 BizTalk Server 主機進程。
在報告未攔截的例外狀況之後，RoutingOrchestration 會暫停
徵兆
處理以多個批次組態為目標的檔時，您可能會在應用程式事件記錄檔中收到錯誤，從 XLANG/s 開始，Microsoft.BizTalk.Edi.RoutingOrchestration.BatchRoutingService 因為發生未攔截的例外狀況而失敗。
可能的原因
當 RoutingOrchestration 嘗試將訊息傳送至 BatchingOrchestration 且 BatchingOrchestration 實例未啟動時，就會發生此錯誤。
解決方法
在提交要批處理的檔之前，請確定 BatchingOrchestration 實例正在執行。
許多作用中批次可能會導致 BizTalkMsgBoxDb Logfile 成長很大
徵兆
啟動數個批次之後，您可能會注意到 BizTalk 消息框資料庫的事務歷史記錄 (BizTalkMsgBoxDb) 已成長為大型大小。
可能的原因
如果您有大量批次從發行準則開始，導致批次發行 (之間的短暫間隔，例如，排定每分鐘發行一次的批次) ，就會發生此問題。
當您啟動批次時所建立的批處理協調流程實例是長時間執行的進程，會在釋放批次之後保存到資料庫。 每次協調流程持續發生時，事務歷史記錄都會因為涉及持續性的交易而成長。
注意
批處理協調流程會在持續性期間增加大約 30 kb 的事務歷史記錄。
解決方法
若要解決此問題，請修改發行準則以增加批次發行之間的時間。 如需詳細資訊，請參閱 設定批次處理 (X12) 。