Trabajando con Service Broker en Microsoft SQL Server

Hola, chicos,
¿Todo muy bien?

Hoy conocí Microsoft SQL Server Service Broker y aprendí mucho leyendo el blog. Junior Galvao, de donde saqué esta publicación. No creo que valga la pena escribir mucho sobre este tema, si ya lo ha cubierto (de forma muy didáctica) extensamente. Entonces, conozcamos esta importante característica de MS SQL Server, que estuvo disponible a partir de la versión 2005 en adelante.

Introducción

Lanzado junto con Microsoft SQL Server 2005, Service Broker fue uno de los aspectos más destacados de esta versión de SQL Server, siendo tratado como una de las principales innovaciones del producto en 2005.

Desde entonces mucho se ha hablado de esta característica, que se ha mantenido y evolucionado en versiones y ediciones posteriores de Microsoft SQL Server. Service Broker, que existe como característica y funcionalidad del motor de base de datos, permite a los desarrolladores y profesionales de bases de datos crear aplicaciones confiables de colas y mensajería para intercambiar datos en SQL Server. Básicamente, a través de este servicio, es posible que una aplicación conectada a una única instancia de SQL Server distribuya trabajo y mensajes entre varias otras instancias de bases de datos.

A través de esta capacidad de intercambiar información, el Service Broker estableció una forma de comunicación asincrónica entre las aplicaciones de bases de datos que hacen uso de esta funcionalidad, así, el tiempo de respuesta para el intercambio de información es mucho más corto, interactivo y simplificado, lo que hace más confiable el uso de este recurso.

Además, Service Broker proporciona un intercambio de mensajes confiable entre instancias de bases de datos distribuidas en una empresa, ayudando a los desarrolladores a componer aplicaciones estructuradas o reconocidas como servicios independientes, haciendo uso de la misma instancia de comunicación.

De forma predeterminada, Service Broker utiliza el protocolo TCP/IP y su conjunto de protocolos existentes para intercambiar mensajes, que contienen características que pueden impedir el acceso no autorizado a una red en cualquier momento, estableciendo estándares para el cifrado de mensajes enviados por aplicaciones entre instancias de SQL Server.

Cómo funciona el corredor de servicios

Como su objetivo es crear una forma simplificada, segura y desacoplada de intercambiar mensajes, el Service Broker tiene un conjunto de tareas necesarias para llevar a cabo este proceso de mensajería, entre aplicaciones e instancias del Servidor de Base de Datos. La arquitectura de Service Broker se compone de los siguientes componentes, tareas y características:

• Conversaciones;
• Ordenación y coordinación de mensajes;
• Programación asincrónica transaccional;
• Soporte para aplicaciones débilmente acopladas; y
• Componentes del agente de servicios.

A continuación describo esta arquitectura, destacando brevemente cada tarea.

Conversación

Diseñado como un recurso básico para enviar y recibir mensajes, el Service Broker presenta una tarea llamada “Conversación” que se lleva a cabo durante el proceso de intercambio de mensajes. Cada tarea de conversación es reconocida y tratada como un canal de comunicación confiable y persistente, los mensajes presentan un tipo de conversación específico que es tratado por el Service Broker individualmente, lo que permite reforzar y garantizar la seguridad en el registro de los datos intercambiados por las aplicaciones.

Durante este intercambio de mensajes, la tarea “Conversación” permite a las aplicaciones involucradas en este proceso establecer este canal de comunicación dentro de una “cola” que representa la visualización de una tabla interna relacionada con la base de datos que está utilizando el Service Broker.

Para cada conversación manejada por el Service Broker se establece una secuencia y ordenamiento de Mensajes a través de la tarea “Ordenación y Coordinación de Mensajes”, esto garantiza que cada mensaje sea parte de una conversación única y exclusiva, es decir, un mismo mensaje intercambiado será manejado por la misma tarea y conversación.

Una forma más sencilla de representar e ilustrar cómo funciona un Service Broker es pensar en cómo funciona un servicio postal. Para mantener una conversación con un colega lejano, puede comunicarse enviando cartas por servicio postal.

El servicio postal clasifica y entrega cartas. Luego, usted y su colega recuperan las cartas de los buzones, las leen, escriben respuestas y envían nuevas cartas hasta que finaliza la conversación. La entrega de cartas se realiza de forma asincrónica mientras usted y su colega realizan otras tareas.

EL Figura 1 presenta el proceso de intercambio de mensajes, basado en un Servicio Postal.

Figura 1: Representación del proceso de intercambio de mensajes realizado por el Service Broker.

Al analizar el funcionamiento del Service Broker, podemos entender que los programas involucrados en este escenario deben entender que este servicio operará de manera similar al Servicio Postal o Correios, dando soporte total a los mensajes asíncronos intercambiados entre aplicaciones.

Los mensajes de Service Broker funcionan como cartas. El servicio Service Broker se considera la dirección donde la oficina de correos entrega las cartas. Las colas son los buzones que contienen las cartas una vez entregadas. Las aplicaciones reciben mensajes, actúan sobre mensajes y envían respuestas.

Observación: Mientras exista un proceso de intercambio de mensajes a través del Service Broker, el proceso de cola se mantendrá y alimentará hasta que la aplicación que recibe los datos sea capaz de manejar estos mensajes, mientras esto no suceda, la cola de mensajes aumentará su tamaño y se ampliará su proceso de cola.

Ordenación y coordinación de mensajes

Todo el proceso de control y mantenimiento de las colas de mensajes lo realiza el Service Broker directamente en el Motor de Base de Datos, adoptando un tratamiento tradicional a través de dos aspectos:

• Las colas administradas por Service Broker se integran directamente con la base de datos en la que está involucrado el servicio.
• Las colas se encargan de coordinar y ordenar los mensajes en tránsito.

A través de un fuerte control sobre el envío y recepción de mensajes, la tarea de “Ordenación y Coordinación de Mensajes” brinda al Service Broker garantías en el flujo de intercambio de mensajes, estableciendo dos lados en el proceso de comunicación, denominados:

• El lado inicial se llama iniciador; y
• El lado de destino del mensaje llama al receptor.

Un proceso básico de intercambio de mensajes de Service Broker consta de:

A continuación se muestra una ilustración del intercambio de mensajes en un diálogo típico:

• En el lanzador:
  • Un programa inicia la conversación.
  • El programa crea un mensaje que contiene los datos necesarios para realizar una tarea.
  • El programa envía el mensaje al servicio de destino.
• En el receptor:
  • El mensaje se coloca en la cola asociada con el servicio de destino.
  • Un programa recibe el mensaje de la cola y realiza el trabajo.
  • El programa responde enviando un mensaje al servicio iniciador.
• En el lanzador:
  • El mensaje de respuesta se coloca en la cola asociada con el servicio iniciador.
  • Un programa recibe la respuesta y la procesa.

Hasta el final del envío y recepción de mensajes, este ciclo se repite de forma cíclica y continua.

Este ciclo se repite hasta que el iniciador finaliza la conversación porque no tiene más solicitudes para enviar al destino.

Programación asincrónica transaccional

El componente “Programación asíncrona transaccional” está completamente relacionado con la infraestructura operativa de Service Broker, sirviendo como un área de transferencia de mensajes, tratando cada proceso de forma transaccional, lo que permite revertirlo en cualquier momento.

En este componente, el Service Broker controla los datos que se intercambian, estableciendo un proceso de escalabilidad, que asegura que el servicio pueda ser automatizado y crezca según la situación, uno de los cuales es la capacidad de iniciar automáticamente los procesos que procesan una cola, por lo que es posible que la aplicación que está utilizando el proceso de envío/recepción identifique el momento en que el mensaje se está ejecutando o en la cola de procesamiento.

La programación asincrónica permite a los desarrolladores crear soluciones de software capaces de escribir datos en colas de mensajes, haciendo uso de la propia base de datos a través de una o más tablas como repositorios internos de colas de mensajes.

Soporte para aplicaciones débilmente acopladas

Considerado como una característica y no como un componente o tarea, el “Soporte para aplicaciones acopladas de manera flexible” garantiza y permite al Service Broker trabajar con un conjunto muy distinto de aplicaciones independientes que pueden identificarse como posibles componentes de intercambio de mensajes. Estas aplicaciones deben contener internamente la misma estructura y mecanismo de intercambio de mensajes que existe en el Service Broker, lo que en algunas situaciones permite acoplar este componente al servicio de mensajería.

Componentes del agente de servicios

El Service Broker está compuesto por tres componentes básicos, existentes según la tarea que se realice:

• Componentes conversacionales: Conocido como diálogo, es cualquier conversación que se realiza a través del Service Broker durante el proceso de mensajería, permitiendo que grupos de conversiones, conversaciones y mensajes sean manejados por tus aplicaciones estableciendo los participantes.
• Componentes de definición de servicio: Responsable de establecer el flujo de la conversación, almacenando datos en una base de datos, este componente define la estructura básica de la conversación que se realiza entre el Service Broker y la aplicación.
• Componentes de red y seguridad: A través de este componente, Service Broker permite a los administradores de bases de datos administrar sus entornos sin impactar el código fuente de la aplicación, enfocándose en cambios o cambios de escenario, estableciendo un canal de intercambio de mensajes seguro y confiable para las aplicaciones que están consumiendo el Service Broker.

Observación: Los componentes de definición de servicios, componentes de red y componentes de seguridad son parte de la base de datos y de los metadatos de la instancia de SQL Server. Los grupos de conversación, las conversaciones y los mensajes forman parte de los datos que contiene la base de datos.

Bueno, después de esta larga caminata, le voy a agregar un poco de pimienta a esta salsa, iniciando la creación de nuestro ambiente de estudio, a través del Código 1 que presentamos a continuación:

–- Código 1 – Criando o Banco de Dados MyDatabaseServiceBroker
Use Master
Go


/* 1 – Criação do banco de dados */
CREATE DATABASE MyDatabaseServiceBroker
Go


/* 2 – Ativação do recurso de Service Broker */
ALTER DATABASE MyDatabaseServiceBroker 
SET ENABLE_BROKER
Go

/* 3- Verificação do Status */
SELECT Name, is_broker_enabled 
FROM sys.databases
WHERE Name = 'MyDatabaseServiceBroker'
Go

Tenga en cuenta que después de crear la base de datos, usamos el comando Modificar base de datosa través de la directiva Establecer Enable_Broker para activar e indicar a SQL Server que esta base de datos debe permitir el uso del servicio de mensajería.

Notas:

• Para ejecutar ENABLE_BROKER, SQL Server solicita un bloqueo exclusivo de la base de datos. Si otras sesiones han bloqueado recursos en la base de datos, ENABLE_BROKER esperará hasta que las otras sesiones liberen los bloqueos.
• Para habilitar Service Broker en una base de datos de usuario, verifique que ninguna otra sesión esté usando la base de datos antes de ejecutar la instrucción ALTER DATABASE SET ENABLE_BROKER, por ejemplo, colocando la base de datos en modo de usuario único.

Tipos de mensajes

Para hacer posible la comunicación, las aplicaciones que utilizan Service Broker utilizan el concepto de mensajes a través de la función de envío y recepción, algo muy similar al correo electrónico. Quienes participan en el proceso de intercambio de mensajes son responsables de aceptar el intercambio de contenido, así como de reconocer el nombre de cada mensaje.

El objeto de tipo de mensaje define un nombre para el tipo de mensaje y el tipo de datos que debe contener el mensaje. Los tipos de mensajes persisten en las bases de datos en las que se crean. Puede crear un tipo de mensaje idéntico en cada base de datos que participe en una conversación.

Cada tipo de mensaje es responsable de especificar la validación que SQL Server debe realizar para los mensajes, según el tipo de datos. SQL Server puede comprobar si el mensaje contiene XML válido, si contiene XML que se ajusta a un esquema particular o si simplemente no contiene datos.

La validación se realiza cuando el servicio de destino recibe el mensaje; si el contenido del mensaje no coincide con la validación especificada, Service Broker devolverá un mensaje de error al servicio que envió el mensaje.

Pues bien, nuestro escenario constará básicamente de dos tipos de mensajes:

1. mtEnviarMensaje; y
2. mtReceiptMessage.

Para crear nuestros tipos de mensajes, usaremos el Bloque de código 1, que se muestra a continuación:

/* Código 1 – Criando os Tipos de Mensagens */
Use MyDatabaseServiceBroker
Go

CREATE MESSAGE TYPE [mtEnvioMensagem]
VALIDATION = WELL_FORMED_XML
Go

CREATE MESSAGE TYPE [mtRecebimentoMensagem]
VALIDATION = WELL_FORMED_XML
Go

Tenga en cuenta que estoy especificando en el argumento Validación, la opción =Bien_FORMED_XML, esto le indicará a SQL Server que nuestro cuerpo debe contener un archivo XML bien formateado como mecanismo de validación del mensaje.

EL Tabla 1 presentado a continuación, ilustra los tipos de mensajes que existen en Service Broker:

Tabla 1: Lista de argumentos en el comando Crear tipo de mensaje.

Podemos observar el Figura 1 el cual ilustra la estructura de nuestra base de datos, luego de crear los dos tipos de mensajes:

Si desea consultar la lista de mensajes creados en este momento, utilice la Tabla del Sistema: Sys.Service_Message_Types

Nuestro siguiente paso es crear Contratos, aprendamos un poco sobre Contratos y luego creemos este recurso.

Contratos

Un contrato define qué tipo de mensaje utiliza una aplicación para realizar una tarea particular. Un contrato es un acuerdo entre dos servicios sobre qué mensajes pretende cada servicio realizar una tarea particular.

El contrato especifica qué tipos de mensajes se pueden utilizar para realizar el trabajo deseado. El contrato también especifica qué participante de la conversación puede utilizar cada tipo de mensaje.

Service Broker también incluye un contrato interno llamado POR DEFECTO. Esto contiene sólo el tipo de mensaje. ENVIADO POR CUALQUIER. Si no se especifica ningún contrato en las instrucciones, el Agente de Servicios utilizará el contrato PREDETERMINADO.

Para crear un nuevo contrato, usaremos el Bloque de código 2presentado a continuación, tenga en cuenta que usaremos el comando Crear contrato, especificando el tipo de mensaje que será el destino y cuál será el iniciador.

/* Código 2 – Criando contrato e definido o Target e Initiator */
Use MyDatabaseServiceBroker
Go

CREATE CONTRACT [cProcessaMensagens] ( 
   [mtEnvioMensagem] SENT BY initiator,
   [mtRecebimentoMensagem] SENT BY target
);
Go;

Tenga en cuenta que lo definimos como iniciador(inicializador) mtEnviandoMensaje y comoObjetivo(objetivo) el mtReciboMensajePor lo tanto, desde el momento en que iniciamos el proceso de diálogo, el Service Broker podrá entender qué Tipo de Mensaje enviará y quién recibirá el mensaje.

EL Figura 2 presentado a continuación, ilustra la estructura de nuestra base de datos MyDatabaseServiceBroker, después de crear el contrato cMensajes de proceso:

Figura 2 – Estructura de la Base de Datos MyDatabaseServiceBroker, mostrando el contrato creado anteriormente.

Si desea consultar el listado de contratos creados en este momento utilice la Tabla del Sistema: Sys.Service_Contracts

En este momento, nuestra base de datos tiene los siguientes componentes en su estructura:

• Tipos de mensajes: mtSendMessage y mtReceiveMessage; y
• Contrato: cProcessaMensagens.

Vamos a evolucionar un poco más en la estructura de nuestro entorno, creando ahora otro recurso muy importante para que se pueda utilizar el Service Broker, y de gran importancia para que se puedan intercambiar mensajes, este referido a COLA (Colas), manteniendo la regla, presentaré los conceptos sobre Cola y luego el código que debemos usar para crear nuestras colas.

COLA (Colas)

Las colas, o colas, tienen la función de habilitar un canal de comunicación entre los involucrados en el proceso de intercambio de mensajes, creando la llamada Cola de Mensajes.

Cuando Service Broker recibe un mensaje de un servicio, lo inserta en la cola de ese servicio. De esta manera, para recibir mensajes enviados al servicio, una aplicación recibe mensajes de la cola, lo que permite al Service Broker administrar y controlar el flujo de mensajes que se procesan en cada cola.

Durante el procesamiento de mensajes, las colas se llenan creando una secuencia de líneas que representan los mensajes que se utilizan.

La línea tiene el contenido del mensaje e información sobre el tipo de mensaje, el servicio previsto por el mensaje, el contrato que sigue el mensaje, la validación realizada en el mensaje, la conversación de la que forma parte el mensaje y la información interna de la cola.

Las colas no devuelven mensajes en un orden estricto de primero en entrar, primero en salir; en cambio, las colas devuelven mensajes para cada conversación en el orden en que se enviaron los mensajes. Por tanto, una aplicación no necesita incluir código para recuperar el orden original de los mensajes.

Avanzando crearemos las colas que usaremos en nuestro entorno, para esto crearemos dos hijos, llamados: qOrigem y qDestino, usados ​​como canales de comunicación y puestos en cola en el procesamiento de mensajes, para esto haremos uso de Bloque de código 3, que se muestra a continuación:

/* Código 3 – Criando as Filas qOrigem e qDestino */
Use MyDatabaseServiceBroker
Go

CREATE QUEUE [qOrigem]
Go

CREATE QUEUE [qDestino]
Go

Si nos fijamos en el proceso de creación de una cola, es muy sencillo y sin ningún tipo de secretos. Todo lo contrario, una de las características más peculiares de Service Broker está relacionada con su proceso de configuración, que se realiza de una forma muy clara, tranquila y muy simplificada.

Actualmente tenemos otro componente creado en nuestra base de datos, como se muestra en la Figura 3, que muestra cómo Management Studio presenta las colas creadas para nuestro Service Broker:

Figura 3: Estructura de la base de datos, que muestra las colas qOrigem y qDestino creadas anteriormente.

Si desea ver la lista de colas creadas en este momento, utilice la Tabla del sistema:Sys.Service_Queues

Nuestro último componente que será creado para componer la estructura de nuestra Base de Datos. MiBroker de servicio de base de datos, conocido como Servicio, y tal como lo presenta su propia descripción, el Servicio será el elemento involucrado en el proceso de intercambio de mensajes realizado por Service Broker.

Servicios

Elemento que conforma la arquitectura de un Service Broker, los servicios se definen y tratan como tareas que tienen un propósito específico, permitiendo que se produzcan conversaciones (diálogos) en el Service Broker. A través de los servicios, Service Broker pudo entregar mensajes correctamente a las colas dentro de una base de datos, enrutar mensajes, hacer cumplir el contrato para una conversación y determinar la seguridad remota de una nueva conversación.

Cada servicio especifica una cola para contener mensajes entrantes, haciendo uso de contratos asociados con el servicio que definen las tareas específicas para las cuales el servicio acepta nuevas conversaciones.

Continuando con este largo camino crearemos nuestros servicios, de la misma manera que lo hicimos con las Colas, estaremos creando dos servicios llamados: sOrigin y sDestino, como se muestra en la imagen. Bloque de código 4 abajo:

/* Código 4 – Criação dos Serviços sOrigem e sDestino */
Use MyDatabaseServiceBroker
Go

CREATE SERVICE [sDestino] ON QUEUE [qDestino] ([cProcessaMensagens])
Go

CREATE SERVICE [sOrigem] ON QUEUE [qOrigem]
Go

Es importante resaltar que el servicio Destino está vinculado a la cola qDestino y para este mismo servicio especificamos que se utilizará el contratocMensajes de proceso, por lo tanto, al utilizar este servicio, SQL Server debe llamar al contrato cMensajes de proceso como elemento de validación y garantía del tipo de mensaje que se intercambia.

EL Figura 4, ilustra la estructura de la base de datos MyDatabaseServiceBroker, después de crear nuestros servicios:

Proceso de envío de mensajes

Como se presentó en la Parte I, el Proceso de Comunicación (Conversación) entre el Agente de Servicios y las aplicaciones que lo utilizan es muy similar a cómo funciona Correos, donde hay un Intercambio de Datos (mensajes) que involucra al remitente y al destinatario.

En Service Broker este proceso de comunicación se produce mediante el uso de comandosIniciar conversación de diálogo y Enviar, donde el proceso comienza mediante el uso de Iniciar diálogo y Enviar se realizará mediante Enviar.

Comando Iniciar conversación de diálogo

El comando Begin Dialog Conversation básicamente indica a SQL Server que inicie un bloque de conversación entre uno o más servicios, lo que normalmente ocurre al intercambiar mensajes con al menos dos servicios.

La información especificada en la declaración BEGIN DIALOG CONVERSATION es similar a la dirección de una carta; el Agente de Servicios utiliza la información para entregar mensajes al servicio correcto. Este comando presenta un conjunto único de argumentos para determinar mejor el proceso de conversación. A continuación presento la lista de argumentos:

• @dialog_handle: Variable utilizada para almacenar el identificador del diálogo generado devuelto por la instrucción BEGIN DIALOG CONVERSATION. Esta variable debe ser de tipo Ud.identificadornique.
• Desde Iniciador de servicio_nombre_servicio: Determina el servicio que inicia el diálogo. El nombre especificado debe ser el nombre de un servicio en la base de datos actual. La cola especificada para el servicio de inicio recibe los mensajes devueltos por el servicio de destino y los mensajes creados por Service Broker para esta conversación.
• Al servicio 'target_service_name': Especifica el servicio de destino con el que iniciar el diálogo. El target_service_name es de tipo nvarchar(256). Service Broker utiliza una comparación byte por byte del conjunto de caracteres del mensaje. Esta comparación distingue entre mayúsculas y minúsculas y no tiene en cuenta la clasificación actual.
• Service_broker_guid: Informa a la base de datos que aloja el servicio de destino. service_broker_guid es de tipo nvarchar(128). A través de la Tabla del Sistema Sys.Databases es posible obtener el service_broker_guid.
• 'BASE DE DATOS ACTUAL': Muestra que la conversación utiliza service_broker_guid en la base de datos actual.
• EN EL CONTRATO nombre del contrato: Especifica el contrato que esta conversación debe utilizar e involucrar en el proceso de intercambio. Cuando se omite este argumento, la conversación utilizará el contrato llamado POR DEFECTO.
• CONVERSACIÓN_RELACIONADA = related_conversation_handle: Especifica el grupo de conversación existente al que se agrega un diálogo. Cuando esta cláusula está presente, el diálogo pertenecerá al mismo grupo de conversación involucrado en el diálogo especificado en los argumentos related_conversation_handle
• RELATION_CONVERSATION_GROUP =id_grupo_conversación_relacionada: determina el grupo de conversación existente al que se agrega un nuevo diálogo. Cuando esta cláusula esté presente, el nuevo cuadro de diálogo se agregará al grupo de conversación especificado por related_conversation_group_id.
• VIDA ÚTIL = diálogo_vida útil: Declara el límite de tiempo máximo que el diálogo permanecerá abierto. Para que el cuadro de diálogo se complete correctamente, los puntos finales deben finalizarlo explícitamente antes de que expire su vida útil. El valor de dialog_lifetime debe expresarse en artículos de segunda clase. La duración de la vida es como entero. cuando no hay cláusula VIDA Si se especifica, la vida útil del cuadro de diálogo es el valor máximo del tipo de datos entero.
• CIFRADO: Especifica si los mensajes enviados y recibidos en el cuadro de diálogo se cifran o no cuando se envían a una instancia de Microsoft SQL Server. Cuando ENCRYPTION = ON y los certificados necesarios para admitir el cifrado no están configurados, Service Broker devuelve un mensaje de error en la conversación. Si ENCRYPTION = OFF, se utiliza el cifrado si se configura un enlace de servicio remoto para target_service_name; de lo contrario, los mensajes se enviarán sin cifrar. Si esta cláusula no está presente, el valor predeterminado es ON.

Importante: Todos los mensajes son parte de una conversación. Por lo tanto, un servicio iniciador debe iniciar una conversación con el servicio de destino antes de enviarle un mensaje.

El servicio especificado en la cláusula TO SERVICE es la dirección a la que se envían los mensajes. El servicio especificado en la cláusula FROM SERVICE es la dirección de devolución utilizada para los mensajes de respuesta. Iniciar un diálogo crea un punto final de conversación en la base de datos para el servicio que lo inicia, pero no crea una conexión de red con la instancia que aloja el servicio de destino. El Service Broker no establece comunicación con el destino del diálogo hasta que se envía el primer mensaje.

Después de conocer un poco sobre este comando, trabajemos en nuestro primer bloque de código, llamado Código 1, donde estaremos iniciando nuestro proceso de diálogo para posterior intercambio de mensajes.

/* Código 1 – Iniciando o Diálogo entre os Serviços */
USE MyDatabaseServiceBroker
GO

Declare @MyConversationHandle Uniqueidentifier

Begin Transaction

-– Iniciando um novo diálogo entre os serviços da sOrigem e sDestino –
BEGIN DIALOG  @MyConversationHandle 
FROM SERVICE    [sOrigem]
TO SERVICE      'sDestino'
ON CONTRACT     [cOProcessaMensagens]
WITH ENCRYPTION = OFF,
LIFETIME = 600;

Dónde
– @MyConversationHandle: Variable utilizada para almacenar el Handle_id creado por SQL Server que se utilizará en este cuadro de diálogo;
– Del Servicio: informamos al Servicio sOrigem como nuestro servicio de origen para el intercambio de mensajes;
– Al servicio: Declaró el Servicio sDestino como el servicio de destino involucrado en nuestro intercambio de mensajes;
– Por contrato: Declaramos nuestro acuerdo que utilizaremos en este Diálogo para los servicios involucrados;
– Cifrado = Desactivado: Le informamos a SQL Server que no es necesario cifrar el mensaje que se intercambiará en este cuadro de diálogo; y
– Vida útil = 600: Informe al Service Broker que este cuadro de diálogo tendrá una duración máxima de 600 segundos; cuando se acabe este tiempo y el cuadro de diálogo aún exista, se debe finalizar.

Aviso: Al ejecutar este bloque de código observarás que Microsoft SQL Server prácticamente no estará realizando ningún trámite ni intercambiando mensajes. El objetivo del Código 1 es ilustrar y presentar cómo podemos crear un nuevo diálogo, y este mismo bloque se utilizará más adelante.

Bien, nuestro diálogo ha comenzado y ahora el Service Broker comienza a funcionar, esperando que los datos que se agregarán formen parte del mensaje que luego se enviará.

Entonces, aprendamos un poco sobre el comando Enviar, responsable directo del proceso de envío de mensajes por parte del Service Broker.

enviar comando

De la misma manera que el comando Iniciar conversación de diálogo, el comando Enviar también participa en el proceso de intercambio de mensajes entre servicios que están conectados al Service Broker.

La función principal de Enviar es permitir el envío de mensajes entre una o más conversaciones existentes. A través de Send, se instruye a SQL Server a realizar el llamado PULL (Push), empujando los datos que se almacenan en la estructura que conforma el mensaje para ser movidos entre los servicios de origen y destino, pasando internamente en la estructura de la base de datos con la que está relacionado.

Este comando también presenta un conjunto único de argumentos que se pueden usar para determinar una mejor manera de enviar datos, como se destaca a continuación:

• EN CONVERSACIÓN conversation_handle: Especifica las conversaciones a las que pertenece el mensaje. El handle_conversación debe contener un identificador de conversación válido. El mismo identificador de conversación no se puede utilizar más de una vez.

• TIPO DE MENSAJE: Informa el tipo de mensaje enviado. Este tipo de mensajes deben incluirse en los contratos de servicios utilizados para estas conversaciones. Estos contratos deben permitir el tipo de mensaje que se enviará en ese lado de la conversación. Si se omite esta cláusula, el mensaje será de tipo DEFAULT.

• expresión_cuerpo_mensaje: Proporciona una expresión que representa el cuerpo del mensaje. La expresión message_body_expression es opcional. Sin embargo, si message_body_expression está presente, la expresión debe ser de un tipo que pueda convertirse a varbinary(max). La expresión no puede ser NULL. Si se omite esta cláusula, el cuerpo del mensaje estará vacío.

Ahora podemos realizar el proceso de creación y envío de nuestro mensaje, para ello usaremos el Bloquear Código 2 presentado a continuación.

/* Código 2 – Criando e Enviando a Mensagem */
USE MyDatabaseServiceBroker
GO

Declare @MyConversationHandle Uniqueidentifier

Begin Transaction

/* Inicia um diálogo entre os serviços da origem e destino */

BEGIN DIALOG  @MyConversationHandle
FROM SERVICE    [sOrigem]
TO SERVICE      'sDestino'
ON CONTRACT     [cProcessaMensagens]
WITH ENCRYPTION = OFF,
LIFETIME = 600;

/* Declarando a Estrutura e Conteúdo da Mensagem */
Declare @MyMensagemServiceBroker XML

SET @MyMensagemServiceBroker = N'<!--?xml version=”1.0″?-->
Minha mensagem
Olá esta é uma mensagem de teste no Service Broker';

 
/* Enviando uma mensagem no Diálogo */
SEND ON CONVERSATION @MyConversationHandle
MESSAGE TYPE [mtEnvioMensagem] (@MyMensagemServiceBroker)
Commit Transaction

Notas:

– Tenga en cuenta que para llevar a cabo todo el proceso de Diálogo y Envío de Mensajes, debemos ejecutar el Bloque de Código 1 nuevamente dentro del Bloque de código 2.

– Otro punto importante es el uso del comando Confirmar transacción para obligar a SQL Server a procesar y confirmar las instrucciones que componen este bloque de código, de esta manera estaremos asegurando que el mensaje fue enviado y cerrando el bloque de transacción.

Show de Bola, nuestro mensaje ha sido enviado y ahora esa pregunta que no puede faltar. Dónde terminó nuestro mensaje, es precisamente esta respuesta la que presentaré en el Bloque Código 3, como si fuera un aperitivo que añadimos a nuestro almuerzo y que os desvelaremos en la siguiente parte de este artículo.

/* Código 3 – Localizando – Mensagem */
Select Cast(message_body as xml) from qDestino

Procesamiento de mensajes entrantes

El proceso de recepción de mensajes manejados por aplicaciones que utilizan Service Broker, o directamente en Management Studio, se realiza básicamente mediante el uso del comando Recibir, junto con la cláusula Top.

La función principal del comando Recibir es recuperar uno o más mensajes que puedan existir en la cola que el Servicio invocado por el Service Broker está utilizando actualmente. Normalmente, este comando debería eliminar el mensaje de su cola o actualizar su estado, dependiendo de cómo esté configurado para la cola en uso.

Recibir comando

El comando Recibir tiene una función simple para leer la cola que se está procesando con el fin de identificar el conjunto de mensajes que se encuentran dentro de este repositorio, pasando una orden para actualizar el estado o eliminar el mensaje de la cola. Para llevar a cabo este sencillo procedimiento, existe un conjunto de argumentos que se pueden utilizar junto con el comando, los cuales serán reconocidos por SQL Server como guías de la acción y tratamiento que se debe realizar con el mensaje o conjunto de mensajes capturados. A continuación presento la lista de argumentos:

• Esperar: Dirige la instrucción RECEIVE para que espere a que llegue un mensaje a la cola si no hay ningún mensaje actualmente.
• Arriba (n): Indica el número máximo de mensajes que se recuperarán y devolverán posteriormente.　Si no se especifica esta cláusula, se devuelven todos los mensajes que cumplan con los criterios de la declaración. Para este argumento, se permite utilizar algunas opciones: Nombre_Columna, Expresión o Alias_Columna, como posibles filtros de datos.
• De: Informa a la cola que debe usarse y contener el conjunto de mensajes capturados. Junto con este argumento, podemos usar las opciones: Database_Name, Schema_Name y Queue_Name, como posibles propietarios de la cola.
• En variable_tabla: Indica a SQL Server que los mensajes devueltos deben almacenarse posiblemente en una variable tipo tabla, donde la tabla debe tener el mismo número de columnas que los mensajes.　El tipo de datos de cada columna en la variable de la tabla debe poder convertirse implícitamente al tipo de datos de la columna correspondiente en los mensajes.　Si se omite esta opción, SQL Server devolverá mensajes en el formato estándar, identificando cada valor como un posible resultado.
• Dónde: Muestra la conversación o grupo de conversación de mensajes recibidos.　Si se omite, los mensajes se devolverán desde el siguiente grupo de chat disponible. Para este argumento, podemos usar las opciones: Conversation_Handle y Conversation_Group_Id, para ayudar al Service Broker a identificar el controlador de mensajes o el grupo de conversación que estamos capturando dentro de la cola. Cabe resaltar que los valores pasados ​​para estas dos opciones son tratados como Identificadores Únicos oIdentificador único.
• Se acabó el tiempo: Determina la cantidad de tiempo, en milisegundos, que la instrucción espera un mensaje. De forma predeterminada, esta cláusula sólo se puede utilizar con la cláusula WAITFOR.　Si esta cláusula no se especifica o si el tiempo de espera es -1, el tiempo de espera será ilimitado.　Al final del tiempo de espera, RECEIVE devolverá un conjunto de resultados vacío.

Importante: La declaración RECEIVE lee mensajes de una cola y devuelve un conjunto de resultados.　Este conjunto consta de cero o más líneas, cada una de las cuales contiene un mensaje.　Si la instrucción EN no se utiliza y　　especificador de columna　　Si no asigna los valores a las variables locales, la instrucción devolverá un conjunto de resultados al programa que llama.

La instrucción RECEIVE elimina los mensajes recibidos de la cola a menos que la cola especifique la retención de mensajes.　Cuando la configuración de RETENCIÓN de la cola está ENCENDIDO, la declaración RECEIVE actualizará la columna estado　　a　　0,　 　 y dejará los mensajes en la cola.　Cuando se revierte una transacción que contiene una instrucción RECEIVE, cualquier cambio realizado en la cola de la transacción también se revierte, devolviendo mensajes a la cola.

Muy bueno, ya sabemos un poco sobre el comando Recibir, sus argumentos, opciones y principalmente la forma en que funciona este comando, podemos evolucionar un poco más e iniciar el proceso de recepción de mensajes, comenzando por identificar qué mensajes están en nuestra Cola.

Pero como estamos al final de este viaje, ya se han presentado muchas cosas anteriormente y como la memoria es algo que normalmente falta en nuestras cabezas, refrescaré nuestros recuerdos presentando nuestro escenario nuevamente, con toda la estructura de recursos, a través de la Tabla 1 a continuación:

Tabla 1 – Estructura y Recursos – Corredor de Servicios.

Ahora no te puedes quejar, creo que ya has logrado recordar nuestro escenario, estructura y sobre todo los recursos que estamos utilizando.

Un detalle importante, puedes ver que en la Tabla 1 se presenta un recurso tipo Ruta, en ningún momento se abordó este recurso en este escenario, pero está presente y posiblemente sea de gran importancia.

Cuando se crea una aplicación de Service Broker de forma predeterminada, Microsoft SQL Server crea una ruta llamada AutoCreatedLocal, que se aborda como una Ruta Local y es responsable de permitir el tráfico de datos que Service Broker está procesando. Si desea saber más sobre este elemento y su funcionalidad, consulte los Manuales de Microsoft SQL Server (Libros en línea), buscando Crear ruta.

Luego trabajemos con nuestro primer bloque de código, llamado Código 1,buscando la lista de mensajes que pueden existir en nuestra cola, llamada  qDestino, como se muestra a continuación:

/* Código 1 – Procurando a relação de Mensagens na Fila – qDestino */
USE MyDatabaseServiceBroker
GO

SelectCast(Message_Body asXml)from qDestino
Go

Tenga en cuenta que después de ejecutar el Código 1, Management Studio debería mostrar nuestra lista de mensajes almacenados en la cola. qDestino, donde el resultado debería estar en formato XML, ya que nuestros mensajes fueron creados y enviados en este formato. La figura 1 que se presenta a continuación ilustra este resultado:

Figura 1: Lista de mensajes almacenados en la cola qDestino.

Ya sabemos qué mensajes están presentes en esta cola y ahora el siguiente paso es leer y recibir los datos contenidos en nuestro mensaje. Para hacer esto, usaremos el bloque de código 2, presentado en la secuencia:

/* Código 2 – Realizando a Leitura e Recebimento de Dados */
USE MyDatabaseServiceBroker
GO

Declare @MyConversationHandle UniqueIdentifier,
@MyMessage_Body XML,
@MyMessage_Type_Name sysname;

/* Iniciando o Bloco de Transação */
BeginTransaction;

/* Realizando o Recebimento da Mensagem */
RECEIVETOP(1)
@MyMessage_Type_Name = message_type_name,
@MyConversationHandle = conversation_handle,
@MyMessage_Body = message_body
FROM [qDestino]

/* Apresentando o Retorno da Mensagem */
SELECT @MyMessage_Body As MyMessage

/* Confirmando o Bloco de Transação */
Commit

Pues ya viste que sencillo y fácil fue obtener los datos de nuestro Mensaje que estaban almacenados en la Cola qDestino, en ningún momento tuvimos que realizar ningún tipo de configuración compleja ni requerir recursos externos.

El Service Broker es totalmente capaz de devolver datos, el secreto es utilizar el comando Recibir en conjunto con la cláusula Top, donde informamos la cantidad de mensajes que se deben devolver, luego a través del comando Seleccionar presentamos el contenido de la variable @MiMensaje_Cuerpo. Para ilustrarlo mejor, la Figura 2 muestra el contenido del mensaje que acabamos de recuperar:

Figura 2: Contenido del mensaje recuperado mediante el comando Recibir.

En este momento, si deseas consultar el contenido existente en la cola de qDestino, notarás que este mensaje ya no está presente.

Una vez que todo haya transcurrido con normalidad y como era de esperar, el último paso que realizaremos básicamente consistirá en analizar un mensaje que consultaremos dentro de nuestra cola. qDestino, según sus comentarios, interactúe con nuestro cuadro de diálogo y devuelva un mensaje a la cola qOrigen, completando el proceso de envío y recepción de mensajes. Para ello utilizaremos los Bloques de Código 3 y 4, que se presentan a continuación:

/* Código 3 – Enviando Mensagem */
USE MyDatabaseServiceBroker
GO

Declare @MyConversationHandle Uniqueidentifier

BeginTransaction

/* Inicia um diálogo entre os serviços da origem e destino */
BEGIN DIALOG @MyConversationHandle
FROMSERVICE [sOrigem]
TOSERVICE 'sDestino'
ONCONTRACT [cProcessaMensagens]
WITHENCRYPTION=OFF,
LIFETIME= 600;

/* Declarando a Estrutura e Conteúdo da Mensagem */
Declare @MyMensagemServiceBroker XML
SET @MyMensagemServiceBroker = N'<!--?xml version=”1.0″?-->
Minha segunda mensagem
Olá esta é a segunda mensagem de teste no Service Broker
';

/* Enviando uma mensagem no Diálogo */
SENDONCONVERSATION @MyConversationHandle
MESSAGETYPE [mtEnvioMensagem](@MyMensagemServiceBroker)

Commit Transaction

/* Código 4 – Respondendo a Mensagem – Interagindo com o Diálogo */
USE MyDatabaseServiceBroker
GO

Declare @MyConversationHandle UniqueIdentifier,
@MyMessage_Body XML,
@MyMessage_Type_Name sysname;

/* Iniciando o Bloco de Transação */
BeginTransaction;

/* Realizando o Recebimento da Mensagem */
RECEIVETOP(1)
@MyMessage_Type_Name = message_type_name,
@MyConversationHandle = conversation_handle,
@MyMessage_Body = message_body
FROM [qDestino]

/* Verifica se a mensagem foi enviada através da Message Type – mtEnviomensagem */

if @MyMessage_Type_Name = N’mtEnvioMensagem’
Begin
    DECLARE @MySourceMessage XML
    SET @MySourceMessage = 'Retorno da Mensagem de Destino foi respondida para Origem.';
    SENDONCONVERSATION @MyConversationHandle –- Interage no mesmo diálogo
    MESSAGETYPE [mtEnvioMensagem](@MySourceMessage)

    /* Finaliza o diálogo encerrando a conversação */
    ENDCONVERSATION @MyConversationHandle

End

/* Finaliza o Bloco de Transação */
COMMITTransaction

Al ejecutar estos dos bloques de código realizamos el proceso completo de envío y recepción de mensajes a través de los recursos que configuramos para el Service Broker, nuestro último paso es verificar los mensajes en la Cola qOrigen, como forma de garantizar y asegurarnos de que el mensaje de respuesta fue recibido, entonces haremos uso de la Bloque de código 5, presentado a continuación.

/* Código 5 – Consultando as Mensagens de Retorno na Fila qOrigem */
USE MyDatabaseServiceBroker
GO

SELECT cast(message_body asXML) FROM [qOrigem];
Go

RECEIVE Cast(message_body asxml) FROM [qOrigem];
Go

Al ejecutar este bloque de código podrás ver que no estamos haciendo nada diferente, simplemente usando el comando Seleccionar para consultar la información en la cola qOrigem, luego recibiendo los datos usando el comando  Recibir.

¡¡¡Feliz año nuevo!!!