共用方式為

主題篩選和動作

  • 發行項

訂閱者可定義希望接收的主題訊息。 這些訊息的指定形式為一或多個命名訂閱規則。 每個規則都由一個選取特定訊息的篩選條件組成，以及選擇性地包含一個動作，為選定訊息加上註解。

所有不含動作的規則都會使用 OR 條件進行合併，即使您有多個比對規則，也會在訂用帳戶上產生單一訊息。

每個含有動作的規則會產生訊息複本。 此訊息會有稱為 RuleName 的屬性，其中值是比對規則的名稱。 動作可以新增或更新屬性，或刪除原始訊息中的屬性，以在訂用帳戶上產生訊息。

請考慮下列案例，其中訂用帳戶有五個規則：兩個具有動作的規則，另外三個沒有動作。 在此範例中，如果傳送一則符合所有五個規則的訊息，您會在訂用帳戶上取得三則訊息。 亦即，兩則訊息針對兩個含動作的規則，一則訊息針對三個不含動作的規則。

每個新建立的主題訂用帳戶都有最初的預設訂用帳戶規則。 如果您未明確指定規則的篩選條件，套用的篩選是讓所有訊息都能選入訂用帳戶的 true 篩選。 預設規則沒有任何關聯的註解動作。

注意

本文適用於非 JMS 案例。 針對 JMS 案例，請使用 訊息選取器。

篩選

服務匯流排支援三種類型的篩選條件：

  • SQL 篩選條件
  • 布林篩選條件
  • 相互關聯篩選

下列幾節提供這些篩選條件的詳細資料。

SQL 篩選條件

SqlFilter 會針對抵達訊息的使用者定義屬性和系統屬性，在訊息代理程式中評估類似 SQL 的條件表達式。 條件運算式中的所有系統屬性都必須加上 sys. 前置詞。 篩選條件的 SQL 語言子集可測試屬性 (EXISTS)、Null 值 (IS NULL)、邏輯 NOT/AND/OR、關係運算子、簡單數值算數，以及符合 LIKE 的簡單文字模式是否存在。

以下是定義 SQL 篩選條件的 .NET 範例：

adminClient = new ServiceBusAdministrationClient(connectionString);    

// Create a SQL filter with color set to blue and quantity to 10
await adminClient.CreateSubscriptionAsync(
		new CreateSubscriptionOptions(topicName, "ColorBlueSize10Orders"), 
		new CreateRuleOptions("BlueSize10Orders", new SqlRuleFilter("color='blue' AND quantity=10")));

// Create a SQL filter with color set to red
// Action is defined to set the quantity to half if the color is red
await adminClient.CreateRuleAsync(topicName, "ColorRed", new CreateRuleOptions 
{ 
	Name = "RedOrdersWithAction",
	Filter = new SqlRuleFilter("user.color='red'"),
	Action = new SqlRuleAction("SET quantity = quantity / 2;")
}

布林篩選條件

TrueFilter 和 FalseFilter 會導致系統為訂用帳戶選取所有抵達的訊息 (true)，或不選取任何抵達的訊息 (false)。 這兩個篩選條件衍生自 SQL 篩選條件。

以下是定義布林篩選條件的 .NET 範例：

// Create a True Rule filter with an expression that always evaluates to true
// It's equivalent to using SQL rule filter with 1=1 as the expression
await adminClient.CreateSubscriptionAsync(
		new CreateSubscriptionOptions(topicName, subscriptionAllOrders), 
		new CreateRuleOptions("AllOrders", new TrueRuleFilter()));

相互關聯篩選

CorrelationFilter 會保留一組條件，比對抵達訊息的一或多個使用者或系統屬性。 常見的用途是比對 CorrelationId 屬性，但應用程式也可以選擇比對下列屬性：

  • ContentType
  • Label
  • MessageId
  • ReplyTo
  • ReplyToSessionId
  • SessionId
  • To
  • 任何使用者定義屬性。

當抵達訊息的某個屬性值等於在相互關聯篩選中指定的值時，代表一個相符項目。 字串運算式的比較會區分大小寫。 如果您指定多個比對屬性時，篩選條件會將這些屬性結合為邏輯 AND 條件，表示針對要比對的篩選條件，所有條件必須符合。

以下是定義相互關聯篩選條件的 .NET 範例：

// Create a correlation filter with color set to Red and priority set to High
await adminClient.CreateSubscriptionAsync(
		new CreateSubscriptionOptions(topicName, "HighPriorityRedOrders"), 
		new CreateRuleOptions("HighPriorityRedOrdersRule", new CorrelationRuleFilter() {Subject = "red", CorrelationId = "high"} ));

使用採用 String 引數的 CorrelationRuleFilter 建構函式，建立具有相互關聯識別碼的相互關聯篩選條件。

當您使用 CorrelationRuleFilter 預設建構函式時，您可以指派系統屬性 (ContentType、Label、MessageId、ReplyTo、ReplyToSessionId、SessionId、To)，以及使用者定義屬性來進行篩選。 若要指定使用者定義屬性進行相互關聯篩選，請使用類型為 IDictionary <string, object> 的屬性 Properties。 此字典的索引鍵是要在訊息上查閱的使用者定義屬性。 與索引鍵相關聯的值是要相互關聯的值。 以下是一個範例。

var filter = new CorrelationFilter();
filter.Label = "abc";
filter.ReplyTo = "xdeu@hotmail.com";
filter.Properties["prop1"] = "abc";
filter.Properties["prop2"] = "xyz";

注意

  • 所有篩選都會評估訊息屬性。 篩選條件無法評估訊息內文。
  • 複雜的篩選規則需要處理容量。 特別是使用 SQL 篩選規則會在訂用帳戶、主題及命名空間層級產生較低的整體訊息輸送量。 應用程式應盡可能選擇相互關聯篩選而避免類似 SQL 的篩選，因為其能大幅提高處理效率，減輕對輸送量的影響。

動作

使用 SQL 篩選條件時，您可以定義動作來透過新增、移除或取代屬性和屬性值為訊息加入註解。 動作使用類似 SQL 的運算式，其大致上仰賴 SQL UPDATE 陳述式語法。 系統會在訊息比對完成之後，以及在將訊息選取至訂用帳戶之前，針對訊息執行動作。 訊息屬性的變更僅涉及複製到訂用帳戶中的訊息。

以下是 .NET 範例，此範例會建立 SQL 規則，其有一個動作，會在顏色為紅色時更新數量。

adminClient = new ServiceBusAdministrationClient(connectionString);    

// Create a SQL filter with color set to red
// Action is defined to set the quantity to half if the color is red
await adminClient.CreateRuleAsync(topicName, "ColorRed", new CreateRuleOptions 
{ 
	Name = "RedOrdersWithAction",
	Filter = new SqlRuleFilter("user.color='red'"),
	Action = new SqlRuleAction("SET quantity = quantity / 2;")
}

重要

當您透過規則動作更新系統屬性時，請注意它可能會變更預期的行為。 只有在佇列或主題中收到訊息時，才會評估某些屬性。 因此，當您在規則動作中更新這些屬性，然後在訂用帳戶中傳遞它們時，會忽略它們。 雖然，當自動轉送至另一個佇列或主題時，會重新評估它們。

  • ScheduledEnqueueTime：當您設定或更新此屬性時，會在訂用帳戶上忽略它。
  • 具有重複資料刪除的 MessageID：更新 MessageID 並導致重複資料刪除時，不會在訂用帳戶中執行重複資料刪除。
  • 具有數據分割的 SessionID：在此案例中，會話標識碼是分割實體的分割區索引鍵，用來決定訊息傳送至的數據分割。 變更規則動作中的 sessionID 表示在訊息登陸分割區之後，分割區索引鍵就會變更。 因此，取用者可能不會在會話中收到其中一些訊息。 即使取用者收到訊息，由於變更的數據分割索引鍵，它們似乎來自錯誤的分割區。

使用模式

  • 廣播模式

    最簡單的主題使用案例是每個訂用帳戶都讓每則訊息傳送一份到主題，實現廣播模式。

  • 分割模式

    透過可預測和互斥的方式，分割會使用篩選條件，將訊息散發到數個現有的主題訂用帳戶。 對於功能相同且每個都容納整體資料中某個子集的區間，當使用者為了處理其中許多不同的內容而向外延展系統時，便會使用分割模式。 透過分割，發行者不需要了解分割模型就能將訊息提交到主題。 接著，系統會將訊息移動到正確的訂用帳戶，供分割的訊息處理常式擷取。

  • 路由模式

    路由能透過可預測但不一定排斥的方式，使用篩選條件將訊息散發到主體訂用帳戶。 搭配自動轉送功能，主題篩選能用來在服務匯流排命名空間內建立複雜的路由圖表，於 Azure 區域中散發訊息。 有了 Azure Functions 或 Azure Logic Apps 作為 Azure 服務匯流排命名空間之間的橋樑，您可以透過與企業營運應用程式的直接整合建立複雜的全域拓撲。

注意

因為 Azure 入口網站現在支援 Service Bus Explorer 功能，所以可以從入口網站建立或編輯訂用帳戶篩選條件。

下一步

如需更多範例，請參閱服務匯流排篩選條件範例。