本節說明解決方案如何將模式圖表轉譯成 BizTalk Server 成品。
連接和完整性條件
我們幾乎可以從任何位置開始，將模式轉譯成 BizTalk Server 元件。 不過，元件之間的連線實際上就是元件的基礎結構，因此似乎是一個很好的起點。 此外，在聚合模式的情況下，我們需要思考如何確定它已經擁有所需的所有資訊。 這會影響其與其他元件的連線，以及其設計。
解決方案需要提供方便且一致的使用方式。 服務介面會指定其他應用程式如何使用它。 因為解決方案需要使用 IBM WebSphere MQ 與舊版應用程式通訊，因此 IBM WebSphere MQ 必須是服務介面的一部分。 不過，對於較新的應用程式，Web 服務介面似乎是一個明顯的選擇。 Web 服務介面可為使用服務的其他應用程式提供最大的彈性。 在這裡，我們可以使用 BizTalk Server 的彈性來擁有雙重服務介面。 如需將協調流程公開為 Web 服務的資訊，請參閱 如何將協調流程對應至 Web 服務。
其他連接是服務介面與收件者清單、收件者清單與後端應用程式之間，以及後端應用程式、匯總器和服務介面之間的連線。
如果與收件者清單的連接是同步的，解決方案就不需要使用相互關聯來確保傳送和接收收件者清單的所有郵件。 後端應用程式與匯總工具之間的連線可能會因為相同原因而同步。 匯總工具需要來自所有三個後端應用程式的回應，才能完成查詢回應。 回應時間應該很短，以便讓同步連線適當，並簡化解決方案。
在匯總工具模式中，通常會有完整性條件。 如果有多個後端伺服器和回應時間很慢，則完整性條件可能是，例如，在指定的時段內至少收到一個回應。 此服務導向解決方案需要這三個回應，才能建構最終訊息。 因此，在這裡，完整性條件會接收這三個回應。
備註
透過 IBM WebSphere MQ 接收要求時，解決方案會將 MQMD_MsgId 值複製到回應訊息 MQMD_CorrelId ，以新增相互關聯標識碼。 這是使用 MQSeries 配接器進行要求-回覆時避免可能出現競爭條件的標準方式之一。 如需詳細資訊，請參閱 使用請求-回覆關聯訊息。
判斷編排邊界
解決方案必須允許透過IBM WebSphere MQ佇列以及Web服務介面來進行請求。 將服務介面放入一個協調流程，IBM WebSphere MQ 輸入放入另一個協調流程，而將大部分的處理放入第三個協調流程中，以保持外部通訊與處理的分離。
將元件轉譯成協調流程圖形
要轉譯成圖形的模式將會在最終解決方案中位於單一協調流程中。 在 BizTalk Server 中建立內容型路由器的方式有很多種，包括建立 MessageBox 訂用帳戶。 在解決方案中，路由會使用 MessageBox 訂用帳戶。 表達式圖形會評估訊息是否包含必要欄位的值。 決策圖形會評估表達式圖形中設定的變數，並透過協調流程選取路徑。
CustomerService 協調流程會使用平行圖形，將訊息傳送至後端應用程式，並同時接收回應。 在提出下一個要求之前，不需要等候一個應用程式完成。 如果應用程式數目經常變更，或應用程式連線不可靠，則協調流程需要以不同的方式轉譯模式。
在解決方案中，匯總工具必須結合來自三個回應消息的元素。 使用平行圖形可確保與後端系統的通訊是平行的。 而且，由於圖形在收到所有回應或逾時之前不會終止，匯總工具一律會知道何時可以繼續。 協調流程會使用轉換形狀，將來自三個後端回應訊息的元素和原始要求訊息對應至回應訊息中的元素。
備註
與後端系統的通訊也可能逾時。您可以將 接收 圖形括在 範圍 圖形中，並設定範圍的 Timeout 屬性，以設定逾時期間。
如需協調流程圖形的完整清單，請參閱 協調流程圖形。