Compartir vía

Filtros y acciones de temas

  • Artículo

Los suscriptores pueden definir los mensajes que quieren recibir de un tema. Estos mensajes se especifican en forma de una o varias reglas de suscripción con nombre. Cada regla está formada por una condición filter que selecciona mensajes concretos y, opcionalmente, una acción que anota el mensaje seleccionado.

Todas las reglas sin acciones se combinan mediante una condición OR y generan un mensaje único en la suscripción, incluso si tiene varias reglas de coincidencia.

Cada regla con una acción genera una copia del mensaje. Este mensaje tendrá una propiedad denominada RuleName en la que el valor es el nombre de la regla de coincidencia. La acción puede agregar o actualizar propiedades, o bien eliminar propiedades del mensaje original para generar un mensaje en la suscripción.

Tenga en cuenta el siguiente escenario en el que una suscripción tiene cinco reglas: dos reglas con acciones y las otras tres sin acciones. En este ejemplo, si se envía un mensaje que coincide con las cinco reglas, se generan tres mensajes en la suscripción. Es decir, dos mensajes para las dos reglas con acciones y un mensaje para las tres reglas sin acciones.

Cada suscripción de tema recién creada tiene una regla de suscripción predeterminada inicial. Si no especifica explícitamente una condición de filtro para la regla, el filtro aplicado es el filtro true que permite que se seleccionen todos los mensajes de la suscripción. La regla predeterminada no tiene ninguna acción de anotación asociada.

Nota:

Este artículo se aplica a escenarios que no son de JMS. Para escenarios de JMS, use selectores de mensajes.

Filters

Service Bus admite tres tipos de filtro:

  • Filtros SQL
  • Filtros booleanos
  • Filtros de correlación

En las siguientes secciones se proporcionan más detalles sobre estos filtros.

Filtros SQL

Un SqlFilter contiene una expresión condicional similar a SQL que se evalúa en el agente con respecto a las propiedades definidas por el usuario y las propiedades del sistema de los mensajes que llegan. Todas las propiedades del sistema deben ir precedidas de sys. en la expresión condicional. El subconjunto de lenguaje SQL para las condiciones del filtro comprueba la existencia de propiedades (EXISTS), valores null (IS NULL), operadores lógicos NOT/AND/OR, operadores relacionales, aritmética numérica simple y coincidencia de patrones de texto simple con LIKE.

Ejemplo de .NET para definir un filtro SQL:

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;")
}

Filtros booleanos

TrueFilter y FalseFilter hacen que se seleccionen todos los mensajes entrantes (true) o ninguno de los mensajes entrantes (false) de la suscripción. Estos dos filtros provienen del filtro SQL.

Ejemplo de .NET para definir un filtro booleano:

// 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()));

Filtros de correlación

CorrelationFilter contiene un conjunto de condiciones para las que se busca la coincidencia con una o varias de las propiedades del usuario y del sistema de un mensaje entrante. Un uso común es comparar con la propiedad CorrelationId, pero la aplicación también puede elegir comparar con las siguientes propiedades:

  • ContentType
  • Label
  • MessageId
  • ReplyTo
  • ReplyToSessionId
  • SessionId
  • To
  • cualquier propiedad definida por el usuario.

Existe una coincidencia cuando el valor de un mensaje entrante de una propiedad es igual al valor especificado en el filtro de correlación. En las expresiones de cadena, la comparación distingue mayúsculas de minúsculas. Al especificar varias propiedades de coincidencia, el filtro las combina como una condición AND lógica, lo que significa que para que el filtro encuentre la coincidencia, todas las condiciones deben coincidir.

Ejemplo de .NET para definir un filtro de correlación:

// 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"} ));

Use el constructor CorrelationRuleFilter que toma un Stringargumento para crear un filtro de correlación con un Id. de correlación.

Al usar el CorrelationRuleFilter constructor predeterminado, puede asignar las propiedades del sistema (ContentType, Label, MessageId, ReplyTo, ReplyToSessionId, SessionId, To) y las propiedades definidas por el usuario para el filtrado. Para especificar las propiedades definidas por el usuario para el filtro de correlación, use la propiedad Properties de tipo IDictionary <string, object>. Las claves de este diccionario son las propiedades definidas por el usuario para buscar en mensajes. Los valores asociados a las claves son los valores en los que se va a correlacionar. A continuación se muestra un ejemplo.

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

Nota

  • Todos los filtros evalúan propiedades del mensaje. Los filtros no pueden evaluar el cuerpo del mensaje.
  • Las reglas de filtro complejas requieren capacidad de procesamiento. En concreto, el uso de reglas de filtro SQL provoca un menor rendimiento general del mensaje en el nivel de suscripción, tema y espacio de nombres. Siempre que sea posible, las aplicaciones deben elegir filtros de correlación por encima de filtros de tipo SQL, ya que son mucho más eficaces en el procesamiento y tienen un impacto menor en el rendimiento.

Acciones

Con las condiciones de filtro SQL puede definir una acción que puede anotar el mensaje mediante la adición, eliminación o sustitución de propiedades y sus valores. La acción usa una expresión de tipo SQL que se basa ligeramente en la sintaxis de la instrucción SQL UPDATE. La acción se realiza en el mensaje después de que se haya correspondido y antes de que el mensaje se seleccione en la suscripción. Los cambios en las propiedades del mensaje son privados para el mensaje copiado en la suscripción.

Este es un ejemplo de .NET que crea una regla SQL con una acción para actualizar la cantidad cuando el color es Rojo.

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;")
}

Importante

Al actualizar las propiedades del sistema a través de acciones de regla, tenga en cuenta que podría cambiar el comportamiento esperado. Algunas propiedades solo se evalúan cuando se recibe un mensaje en una cola o un tema. Por lo tanto, al actualizar estas propiedades en una acción de regla y, a continuación, entregarlas en una suscripción, se omiten. Aunque, al reenviar automáticamente a otra cola o tema, se vuelven a evaluar.

  • ScheduledEnqueueTime: Al establecer o actualizar esta propiedad, se omite en la suscripción.
  • MessageID con desduplicación: No se realiza ninguna desduplicación en la suscripción cuando el MessageID se actualiza y da como resultado un duplicado.
  • SessionID con la creación de particiones: En este escenario, el identificador de sesión es la clave de partición para las entidades con particiones y se usa para decidir la partición a la que se envía el mensaje. Cambiar el sessionID en una acción de regla significa que la clave de partición cambia después de que un mensaje haya llegado a una partición. Como resultado, es posible que el consumidor no reciba algunos de estos mensajes en la sesión. Incluso si el consumidor recibe el mensaje, aparece como si provenían de la partición incorrecta debido a la clave de partición modificada.

Patrones de uso

  • Patrón de difusión

    El escenario de uso más sencillo de un tema es que cada suscripción obtenga una copia de cada mensaje enviado a un tema, lo que permite un patrón de difusión.

  • Patrón de creación de particiones

    En la creación de particiones se usan filtros para distribuir los mensajes entre varias suscripciones a temas existentes de una manera predecible y mutuamente excluyente. El patrón de creación de particiones se usa cuando un sistema se escala horizontalmente para controlar muchos contextos diferentes en compartimientos funcionalmente idénticos que contiene cada uno de ellos un subconjunto de los datos generales; por ejemplo, información del perfil del cliente. Con la creación de particiones, un editor envía el mensaje en un tema sin necesidad de ningún conocimiento del modelo de creación de particiones. A continuación, el mensaje se mueve a la suscripción correcta desde la que el controlador de mensajes de la partición puede recuperarlo.

  • Patrón de enrutamiento

    En el enrutamiento se usan filtros para distribuir los mensajes entre las suscripciones a temas de un modo predecible, pero no necesariamente exclusivo. Junto con la característica de reenvío automático, pueden usarse filtros de tema para crear gráficos complejos de enrutamiento dentro de un espacio de nombres de Service Bus para la distribución de mensajes dentro de una región de Azure. Si Azure Functions o Azure Logic Apps actúan como un puente entre los espacios de nombres de Azure Service Bus, puede crear topologías globales complejas con integración directa en las aplicaciones de línea de negocio.

Nota

Como Azure Portal ahora admite la funcionalidad de Service Bus Explorer, los filtros de suscripción se pueden crear o editar desde el portal.

Pasos siguientes

Para obtener ejemplos, consulte los Ejemplos de filtros de Service Bus.