最佳化協調流程效能
本主題描述在BizTalk Server解決方案中使用協調流程的最佳做法。 這包括下列專案的建議:
減少使用協調流程之BizTalk Server解決方案的延遲
排除僅傳訊模式的協調流程
利用來自協調流程的內嵌傳送
將協調流程持續性點降至最低
巢狀協調流程
協調流程設計模式
協調流程例外狀況處理區塊
針對低延遲案例優化協調流程的建議
下列技術可用來減少使用協調流程之BizTalk Server解決方案的延遲。
排除僅傳訊模式的協調流程
盡可能將協調流程的使用降到最低,以增加整體輸送量,並減少商務程式的延遲。 如果不需要執行長時間執行的交易,而且不需要為每個要求叫用數個系統,請考慮排除協調流程,並將商務邏輯移至接收和傳送埠,以減少 BizTalkMsgBoxDb 的往返總數,並降低資料庫存取所造成的延遲。 在此情況下,請實作自訂管線,並重複使用先前從協調流程叫用的協助程式類別。 只有在嚴格需要實作設計模式時,才能使用協調流程作為散佈圖和收集或 Convoys。 For more information about Orchestration Design Patterns, see the topic Implementing Design Patterns in Orchestrations (https://go.microsoft.com/fwlink/?LinkId=140042) in the BizTalk Server documentation.
使用來自協調流程的內嵌傳送來容納低延遲案例
盡可能減少協調流程的使用,並偏好僅傳訊模式來增加整體輸送量,並減少商務程式的延遲。 如果不需要長時間執行的交易,而且不需要商務邏輯叫用數個系統,請考慮移動商務邏輯來接收和傳送埠,並消除協調流程的使用。 此方法可以使用自訂管線來實作,並重複使用先前從協調流程叫用的協助程式類別。 為了在低延遲案例中達到更好的效能,請採用下列其中一種方法:
消除不必要的協調流程,並採用僅限傳訊模式,以減少 BizTalk MessageBox 資料庫的往返總數。 此方法可容納低延遲,因為內嵌傳送會略過 BizTalk 傳訊引擎和相關聯的額外負荷。 協調流程內嵌傳送功能隨附于 BizTalk Server 2006 和更新版本。
在協調流程內,排除系結至實體埠的邏輯埠,並在其位置使用內嵌傳送。 例如,內嵌傳送可用來建立 WCF Proxy 類別的實例,以叫用下游 Web 服務或 ADO.NET 元件來存取SQL Server資料庫。 在下圖中,協調流程具現化商務元件時,會執行內嵌傳送,此元件會在內部利用 WCF Proxy 物件直接叫用下游 Web 服務:
描述
注意
雖然使用來自協調流程的內嵌傳送可大幅降低延遲,但這種方法有一個限制。 因為內嵌傳送會略過 BizTalk 傳訊引擎,所以無法使用傳訊引擎所提供的下列功能:
- 交易管線
- 可復原管線
- 呼叫 BAM 攔截器 API 的管線
- BizTalk Server配接器支援
- 批次處理
- 重試
- 相互關聯集初始化
- 宣告式設定
- 次要傳輸
- 追蹤
- BAM 的宣告式使用
如需無法從協調流程內執行之管線類型的詳細資訊,請參閱 BizTalk Server 2010 檔中如何使用運算式執行管線https://go.microsoft.com/fwlink/?LinkId=158008 () 主題的一節。
盡可能減少持續性點數目,以優化協調流程延遲
如果您想要使用補償或範圍逾時,協調流程範圍只需要標示為「長時間執行的交易式」。 長時間執行的交易範圍會造成範圍結尾的額外持續性點,因此當您不需要使用補償或範圍逾時時,應該避免它們。 不可部分完成的範圍會導致範圍結尾的持續性點,但也保證不會在不可部分完成的範圍內發生任何持續性點。 此範圍內沒有持續性的副作用有時可用來在進行多個傳送時,將持續性點批次 (,例如) 。 不過,一般而言,我們建議盡可能避免不可部分完成的範圍。 協調流程引擎會將持續儲存體儲存到執行中的協調流程實例在不同時間點的整個狀態,以便稍後可以在記憶體中還原實例並執行到完成。 協調流程中的持續性點數目是影響流經協調流程之訊息延遲的重要因素之一。 每次引擎達到持續性點時,執行協調流程的內部狀態都會序列化並儲存至 MessageBox,而此作業會產生延遲成本。 內部狀態的序列化包含所有已具現化且尚未在協調流程中釋放的訊息和變數。 訊息和變數和這些變數數目愈大,協調流程的內部狀態所花費的時間就越長。 過多的持續性點可能會導致效能大幅降低。 基於這個理由,建議您減少交易範圍和傳送圖形的數目,以消除協調流程中不必要的持續性點。 此方法允許減少 MessageBox 上的爭用,因為協調流程解除凍結和解除凍結、增加整體延展性,以及減少協調流程延遲。 另一個建議是一律盡可能讓協調流程的內部狀態保持小。 這項技術可以大幅減少 XLANG 引擎序列化、保存及還原協調流程在持續性點時的內部狀態所花費的時間。 達成此目的的其中一種方式是盡可能建立變數和訊息,並儘快釋放它們;例如,在您的協調流程中引進非交易範圍,並在這些內部範圍內宣告變數和訊息,而不是在最上層宣告它們。 如需將協調流程持續性點降至最低的詳細資訊,請參閱 BizTalk Server 2010 檔中的下列主題:
持續性和協調流程引擎 (https://go.microsoft.com/fwlink/?LinkID=155292) 。
協調流程解除凍結和解除 凍結 (https://go.microsoft.com/fwlink/?LinkID=155292) 。
使用升級屬性從協調流程存取訊息標記或屬性的指導方針
如果您需要升級屬性,請只升級用於訊息路由、篩選和訊息相互關聯的屬性。 每個屬性的升級都需要反組譯程式元件 (XML、一般、自訂) 辨識檔案類型,以及使用 XSD 中所包含之相對注釋的 XPath 運算式,從訊息擷取資料。 此外,當 Message Agent 將訊息發佈至 MessageBox 資料庫時,每個屬性升級都會個別呼叫bts_InsertProperty預存程式。 如果協調流程需要存取 XML 檔所包含的特定專案或屬性,請使用下列其中一種技術:
減少已寫入和升級的屬性數目,並消除不完全必要的屬性。
消除不必要的辨別欄位。 辨別欄位是寫入的內容屬性,而且可以輕鬆地佔用大量空間,因為其名稱等於用來擷取資料的 XPath 運算式。 辨別屬性定義為 XSD 中定義檔案類型的注釋。 反組譯程式元件會使用針對升級屬性採用的相同方法,並使用定義辨別欄位的 XPath 運算式,在傳入檔中尋找它。 然後,反組譯程式元件會在內容中寫入屬性,其中:
名稱:批註中定義的 XPath 運算式。
值:傳入檔中 XPath 運算式所識別的專案值。
XPath 運算式可能很長,特別是當有問題的元素非常深入檔架構時。 因此,辨別欄位愈大,內容大小就越大。 這又會對整體效能造成負面影響。
使用協調流程執行時間提供的 XPath 內建函式。
如果訊息很小 (幾 KB) 和 XML 格式,您可以將訊息取消序列化為 .NET 類別實例,並使用公用欄位和屬性。 如果訊息需要複雜的 (自訂程式碼、商務規則引擎原則等 ) 使用 .NET 類別實例所公開的屬性來存取資料,則使用 XPath 運算式更快。 當協調流程叫用的商務邏輯完成時,實體物件可以序列化回 BizTalk 訊息。 您可以使用下列其中一個工具來從 XML 架構建立 .NET 類別:XSD 工具 (.NET Framework 2.0) 或 SVCUTIL (.NET Framework 3.0) 。
從協調流程啟用協助程式元件。 這項技術具有優於使用辨別欄位的優點。 事實上,協調流程可能會從組態存放區讀取 XPath 運算式, (組態檔、SSO 組態存放區、自訂 Db 等) ,因此,當您必須變更 XPath 運算式時,您不需要變更並重新部署架構,因為您應該針對升級的屬性和辨別欄位執行動作。 下列程式碼範例提供協助程式元件的範例。 元件會使用 BizTalk 執行時間提供的 XPathReader 類別。 這可讓程式碼讀取檔資料流程,直到找到 XPath 運算式為止。
#region Copyright
//===
//Microsoft Windows Server AppFabric Customer Advisory Team (CAT)
//
// This sample is supplemental to the technical guidance published on the community
// blog.
//
// Author: Paolo Salvatori.
//===
// Copyright © 2010 Microsoft Corporation. All rights reserved.
//
// THIS CODE AND INFORMATION IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER
// EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED WARRANTIES OF
// MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. YOU BEAR THE RISK OF USING IT.
//===
#endregion
#region Using Directives
using System;
using System.Collections.Generic;
using System.IO;
using System.Xml;
using System.Linq;
using System.Text;
using System.Globalization;
using Microsoft.XLANGs.BaseTypes;
using Microsoft.BizTalk.Streaming;
using Microsoft.BizTalk.XPath;
#endregion
namespace Microsoft.AppFabric.CAT.Samples.DuplexMEP.Helpers
{
public class XPathHelper
{
#region Private Constants
private const string MessageCannotBeNull = "[XPathReader] The message cannot be null.";
#endregion
#region Public Static Methods
public static string GetValue(XLANGMessage message, int partIndex, string xpath)
{
try
{
if (message == null)
{
throw new ApplicationException(MessageCannotBeNull);
}
using (Stream stream = message[partIndex].RetrieveAs(typeof(Stream)) as Stream)
{
XmlTextReader xmlTextReader = new XmlTextReader(stream);
XPathCollection xPathCollection = new XPathCollection();
XPathReader xPathReader = new XPathReader(xmlTextReader, xPathCollection);
xPathCollection.Add(xpath);
while (xPathReader.Read())
{
if (xPathReader.HasAttributes)
{
for (int i = 0; i < xPathReader.AttributeCount; i++)
{
xPathReader.MoveToAttribute(i);
if (xPathReader.Match(xPathCollection[0]))
{
return xPathReader.GetAttribute(i);
}
}
}
if (xPathReader.Match(xPathCollection[0]))
{
return xPathReader.ReadString();
}
}
}
}
finally
{
message.Dispose();
}
return string.Empty;
}
#endregion
}
}
將協調流程複雜性降到最低,以改善效能
協調流程的複雜性對效能有顯著的影響。 隨著協調流程複雜度增加,整體效能會降低。 協調流程可用於幾乎無限的各種案例,而且每個案例可能牽涉到不同複雜性的協調流程。 盡可能避免複雜的協調流程,以採用模組化方法。 換句話說,將您的商務邏輯分割成多個可重複使用的協調流程。
如果您需要實作複雜的協調流程,請盡可能將訊息和變數定義為內部範圍,而不是在根層級定義。 這項技術會針對每個協調流程維護較小的記憶體使用量,因為當流程離開定義變數和訊息的範圍時,會處置變數和訊息。 當協調流程在持續性點儲存到 MessageBox 時,此方法特別有用。
使用呼叫協調流程圖形與開始協調流程圖形來改善效能
請避免 啟動協調流程 圖形,並使用 呼叫協調流程 圖形來執行巢狀協調流程。 事實上, 呼叫協調流程 圖形可用來同步呼叫另一個專案所參考的協調流程。 此方法允許在 BizTalk 專案中重複使用常見的協調流程工作流程模式。 當您使用 呼叫協調流程 圖形同步叫用另一個巢狀協調流程時,封入協調流程會等候巢狀協調流程完成,再繼續進行。 巢狀協調流程會在執行呼叫協調流程的相同執行緒上執行。
[開始協調流程] 圖形類似于呼叫協調流程圖形,但在此案例中,會以非同步方式呼叫巢狀協調流程:叫用協調流程中的控制流程會繼續超出叫用流程,而不需要等候叫用的協調流程完成其工作。 為了在呼叫端與呼叫的協調流程之間實作這種分離, 啟動協調流程 是透過將訊息發行至 BizTalk Messagebox 來實作。 此訊息接著會由執行巢狀協調流程的內送 BizTalk 主機實例取用。 可能的話,請使用 呼叫協調流程,特別是當呼叫協調流程需要等候巢狀協調流程的結果才能繼續處理時。 如需使用呼叫協調流程圖形的詳細資訊,請參閱 BizTalk Server 2010 檔中的下列主題:
搭配 XLANGMessage 使用 XmlReader 與搭配 XmlDocument 使用 XmlReader 以改善協調流程效能
若要改善從協調流程呼叫之 .NET 方法的協調流程效能,請使用 XmlReader 搭配 XLANGMessage,而非 XmlDocument。 下列程式碼範例說明這項功能。
// As a general rule, use XmlReader with XLANGMessage, not XmlDocument.
// This is illustrated in the parameter passed into the following code.
// The XLANG/s compiler doesn't allow a return value of XmlReader
// so documents must be initially constructed as XmlDocument()
public static XmlDocument FromMsg(XLANGMessage old)
{
//get at the data
XmlDocument ret = new XmlDocument();
try{
XmlReader reader = (XmlReader)old[0].RetrieveAs(typeof(XmlReader));
//construct new message from old
//read property
object msgid = old.GetPropertyValue(typeof(BTS.MessageID));
}
finally {
// Call Dispose on the XLANGMessage object
// because the message doesn't belong to the
// .NET runtime - it belongs to the Messagebox database
old.Dispose();
}
return ret;
}
另一種方法是根據架構建立 .NET 類別。 這會佔用比將檔載入 XmlDocument 物件還少的記憶體,以及為 .NET 開發人員提供輕鬆的架構元素存取權。 若要根據 BizTalk 架構產生類別,您可以使用 Visual Studio 提供的 xsd.exe 工具。 例如,針對包含 ItemA、ItemB、ItemC 之欄位的簡單 架構執行xsd.exe < schema.xsd > /class ,將會產生下列類別。
//------------------------------------------------------------------------------
// <auto-generated>
// This code was generated by a tool.
// Runtime Version:2.0.50727.1433
//
// Changes to this file may cause incorrect behavior and will be lost if
// the code is regenerated.
// </auto-generated>
//------------------------------------------------------------------------------
using System.Xml.Serialization;
//
// This source code was auto-generated by xsd, Version=2.0.50727.42.
//
/// <remarks/>
[System.CodeDom.Compiler.GeneratedCodeAttribute("xsd", "2.0.50727.42")]
[System.SerializableAttribute()]
[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.ComponentModel.DesignerCategoryAttribute("code")]
[System.Xml.Serialization.XmlTypeAttribute(AnonymousType=true, Namespace="http://Schemas.MySchema")]
[System.Xml.Serialization.XmlRootAttribute(Namespace="http://Schemas.MySchema", IsNullable=false)]
public partial class MySchemaRoot {
private string itemAField;
private string itemBField;
private string itemCField;
/// <remarks/>
[System.Xml.Serialization.XmlElementAttribute(Form=System.Xml.Schema.XmlSchemaForm.Unqualified)]
public string ItemA {
get {
return this.itemAField;
}
set {
this.itemAField = value;
}
}
/// <remarks/>
[System.Xml.Serialization.XmlElementAttribute(Form=System.Xml.Schema.XmlSchemaForm.Unqualified)]
public string ItemB {
get {
return this.itemBField;
}
set {
this.itemBField = value;
}
}
/// <remarks/>
[System.Xml.Serialization.XmlElementAttribute(Form=System.Xml.Schema.XmlSchemaForm.Unqualified)]
public string ItemC {
get {
return this.itemCField;
}
set {
this.itemCField = value;
}
}
}
然後,您可以在 .NET 元件中參考這個類別,以存取訊息元素,而傳回的物件可以直接指派給訊息。 以下是上述所產生類別的範例用法。
public static Root SetValues(Microsoft.XLANGs.BaseTypes.XLANGMessage msg)
{
try
{
MySchemaRoot rootObj=(MySchemaRoot)msg[0].RetrieveAs(typeof(MySchemaRoot);
rootObj.ItemA="value a";
rootObj.ItemB="value b";
rootObj.ItemC="value c";
}
finally {
msg.Dispose();
}
return rootObj;
}
這項技術可讓您在處理訊息時使用物件導向的方法。 這項技術應該主要搭配相對小型的訊息使用。 這是因為即使這項技術使用的記憶體比將訊息載入 XmlDocument 物件時還少,整個訊息仍會載入記憶體中。 處理較大的訊息時,請使用 XmlReader 類別來讀取訊息,並使用 XmlWriter 類別來寫入訊息。 使用XmlReader 和 XmlWriter時,訊息會包含在VirtualStream物件中。 如果訊息大小超過針對 大型訊息閾值指定的值, (位元組 ) 在 BizTalk 群組屬性設定頁面上公開,訊息就會寫入檔案系統。 這會降低整體效能,但可避免記憶體不足例外狀況。
藉由將系結至實體埠的邏輯埠使用降至最低來改善效能
您可以藉由將系結至使用下列介面卡之實體埠的邏輯埠使用降至最低,以提升效能:
SQL Server、Oracle
WSE、HTTP、WCF
MSMQ、MQSeries
在 BizTalk Server 2010 中,可以使用包含在 Microsoft.XLANGs.Pipeline.dll 中的 XLANGPipelineManager 類別,直接從協調流程叫用傳送和接收管線。 因此,管線的處理可以從埠移至協調流程;協調流程中的邏輯埠可以使用 Expression 圖形取代,例如使用 ADO.NET) 叫用指定 .NET 類別的實例 (。 在採用這項技術之前,您應該注意,如果您不使用介面卡和實體埠,您會失去利用其功能的能力,例如批次處理、重試、宣告式設定和次要傳輸。
協調流程設計模式
協調流程Designer可讓開發人員實作各種不同的企業整合模式。 一些常見的模式包括匯總工具、例外狀況處理和補償、訊息代理程式、散佈圖和收集,以及循序和平行 Convoy。 這些模式可用來開發複雜的企業應用程式整合 (EAI) 、Service-Oriented 架構 (SOA) ,以及商務程式管理 (BPM) 解決方案與BizTalk Server。 For more information about Orchestration Design Patterns, see the topic Implementing Design Patterns in Orchestrations (https://go.microsoft.com/fwlink/?LinkId=140042) in the BizTalk Server documentation and Patterns and Best Practices for Enterprise Integration (https://go.microsoft.com/fwlink/?LinkId=140043).
在協調流程中適當地使用 .NET 類別,以最大化效能
一般而言,協調流程內所使用的 .NET 類別可以分成兩個不同的類別:
協助程式和服務 - 這些類別提供協調流程的常見服務,例如追蹤、錯誤處理、快取和序列化/還原序列化。 大部分的類別都可以實作為沒有內部狀態和多個公用靜態方法的靜態類別。 此方法可避免在同時執行的不同協調流程中建立相同類別的多個物件,這有助於減少主機進程的工作空間並節省記憶體。 無狀態的類別有助於減少在協調流程解除凍結時,必須序列化並保存到 BizTalk MessageBox 的內部狀態整體大小。
實體和商務物件 - 您可以使用這些類別來管理實體,例如訂單、訂單專案和客戶。 單一協調流程可以在內部建立和管理相同類型的多個實例。 這些類別通常是具狀態的,並公開公用欄位和/或屬性,以及修改物件內部狀態的方法。 您可以使用 XmlSerializer 或 DataContractSerializer 類別,或使用 XLANGPart.RetrieveAs 方法,將 XLANGMessage 元件還原序列化成 .NET 物件,以動態方式建立這些類別的實例。 您應該使用非交易式範圍來建構協調流程,讓具狀態類別的實例儘快建立,並在不再需要時立即釋放。 此方法可減少主機進程的工作空間,並在協調流程解除凍結時,將序列化並保存到 MessageBox 資料庫的內部狀態整體大小降到最低。 如需在 BizTalk Server 中使用協調流程的詳細資訊,請參閱BizTalk Server協調流程https://go.microsoft.com/fwlink/?LinkID=116886 () 一文。
注意
雖然本文針對 BizTalk Server 2004 和 BizTalk Server 2006 撰寫,但呈現的概念也適用于BizTalk Server 2010 協調流程。
協調流程例外狀況處理常式區塊
使用協調流程例外狀況處理常式區塊時,請盡可能在一或多個範圍中包含所有協調流程圖形 (非交易式範圍) ,並建立至少下列例外狀況處理常式區塊:
用於處理一般 System.Exception 錯誤的例外狀況處理常式區塊。
用於處理一般例外狀況的例外狀況處理常式區塊,以便攔截和處理可能的非受控錯誤,例如 COM 例外狀況。
如需使用協調流程例外狀況處理區塊的詳細資訊,請參閱下列文章:
使用BizTalk Server例外狀況處理 (https://msdn.microsoft.com/library/aa561229.aspx) 。
BizTalk Server 2006 年BizTalk Server:補償模型 (https://go.microsoft.com/fwlink/?LinkId=158017) 。
注意
雖然此部落格是以 2006 BizTalk Server撰寫,但部落格中所述的原則也適用于BizTalk Server。
在協調流程中使用地圖時的考慮
在協調流程中使用地圖時,適用下列考慮:
如果您使用對應來擷取或設定協調流程中商務邏輯所使用的屬性,請使用辨別欄位或升級的屬性。 應該遵循此做法,因為使用對應擷取或設定具有對應的值時,檔會載入記憶體中,不過在使用辨別欄位或升級屬性時,協調流程引擎會存取訊息內容,而不會將檔載入記憶體中。
若您使用對應將數個欄位彙總成一個欄位,請使用辨別欄位或升級屬性搭配協調流程變數,以累計結果集。