Capitulo 8 - Lección 3: Extender la funcionalidad de Microsoft SQL Server con Service broker

Service Broker se introdujo en SQL Server 2005 para proporcionar un sistema de colas de mensajes confiable, escalable y asíncronos para aplicaciones locales o distribuidas. Las soluciones de Service Broker pueden ir desde una simple aplicación existente en una sola base de datos a una aplicación compleja que llega a través de varias instancias remotas de SQL Server.
En esta lección se ofrece una visión general de los componentes que trabajan para crear una solución de Service Broker. También aprenderá a configurar una aplicación de Service Broker simple dentro de una sola instancia de servidor SQL.

Descripción del Service Broker
Para poder trabajar con Service Broker, primero hay que entender los componentes que trabajan juntos para proporcionar una solución de Service Broker. Al igual que en SQL Server 2005, una solución de Service Broker maneja las colas, los servicios, mensajes, tipos de mensajes y contratos.

Nota Importante: Prerrequisitos: Antes de habilitar Service Broker en una base de datos, debe crear una clave maestra de base de datos para la base de datos. Si no, los procesos parecen funcionar, pero los mensajes no se entregan a la cola.

Nuevas características en SQL Server 2008 (Más información AQUI)
Además de los componentes enumerados previamente, SQL Server 2008 ofrece las siguientes nuevas características de Service Broker:

• Prioridades Broker: le permite dar a una conversación prioridad sobre otro. Las prioridades Broker se crean mediante la instrucción CREATE BROKER PRIORITY.
• Utilidad ssbdiagnose: Se utiliza para analizar las conversaciones y los servicios de Service Broker.
• Sistema Monitorizador de objetos y contadores: Proporciona capacidades de análisis con el agente para objeto de Estadística y cinco nuevos contadores se agregan al objeto Broker Statistics (Más información AQUI).

Los componentes de SQL Server 2008 Service Broker se puede dividir en las siguientes tres categorías principales:

• componentes de conversación (Conversation components): Estos componentes son creados en tiempo de ejecución y funcionan de acuerdo a las reglas definidas con la definición del servicio y de red y componentes de seguridad. Una conversación existe entre un iniciador y un objetivo. Las conversaciones son siempre asíncronas y fiables. Las conversaciones se hacen de los mensajes. Un mensaje puede pertenecer a una y sólo una conversación y está hecha de un tipo de mensaje específico. Una conversación entre dos servicios específicos de Service Broker es llamado un diálogo. Cada diálogo pertenece a un grupo de conversación y sigue las reglas especificadas en un contrato. Las prioridades de conversación establecer la prioridad relativa para las conversaciones.
• Servicio de definición de los componentes: Para definir los componentes así como el diseño de su solución Service Broker se utiliza lo siguiente:
  • Colas (Queues): Estas son las tablas donde se almacenan los mensajes hasta que sean procesadas. Cada fila de la tabla representa un mensaje. Cuando un mensaje nuevo se añade a la cola, una fila se añade a la parte inferior de la tabla. Cuando se reciben mensajes y la opción de retención no se especifica, los mensajes se eliminan de la parte superior de la tabla.
  • Servicios: Este es el nombre dado al grupo de tareas que requieren el envío de mensajes. Cuando un servicio se crea, la cola que almacena los mensajes entrantes se define como parte de la definición del servicio. Los contratos están asociados con los servicios para gestionar conversaciones entrantes. Más de un contrato puede estar asociado con un servicio de destino. Si crea un servicio que inicia las conversaciones, pero nunca es el objetivo de cualquier conversación nueva, no es necesario que incluya un contrato en la definición del servicio. Si un servicio se pueden recibir mensajes en el contrato DEFAULT, se debe especificar el contrato DEFAULT cuando se define el servicio.
  • Contratos: Se trata de un acuerdo entre los dos servicios que define los tipos de mensaje de los servicios de envío para realizar ciertas tareas. También define lo que los participantes pueden enviar los tipos de mensajes. Un contrato existe en la base de datos donde se crea. Si está desarrollando una solución que consiste en múltiples bases de datos, debe crear un contrato idéntico en cada base de datos que participa en la solución. El contrato contiene por defecto el tipo de mensaje predeterminado. Cuando se inicia un diálogo y no especifica un contrato, el contrato DEFAULT se utiliza.
  • Tipos de mensajes: Este es el objeto que define el nombre y el contenido de un mensaje. Cada base de datos contiene un tipo de mensaje denominado DEFAULT que utiliza una validación tipo NONE. Tenga cuidado de no confundir el tipo de mensaje predeterminado en el contrato DEFAULT del sistema. Además, debe tener en cuenta que "DEFAULT" es un nombre de objeto delimitado, no una palabra clave, cuando se utiliza para definir un contrato o un tipo de mensaje.
• Componente de seguridad y Red (Network and security components): Estos componentes se utilizan para definir la infraestructura que permite que los mensajes que se entregarán. Son los siguientes:
  • Rutas (Routes): Estos se utilizan para determinar a dónde puede enviar mensajes. Por defecto,
    cada base de datos contiene una ruta a la que todos los mensajes sin una definición de ruta específica debe ser entregado dentro de la instancia actual de SQL Server. Esta ruta se llama AutoCreatedLocal y coincide con un nombre de servicio y la instancia de broker. Cuando se define una ruta, se define el nombre del servicio asociado a la ruta, el identificador de instancia del agente, que identifica a una base de datos específica, donde los mensajes deben ser enviados, y la dirección de red, que contiene la dirección real de la máquina o una palabra clave que identifica el de la máquina que aloja el servicio.
  • Enlaces de servicio remoto: Se utilizan para proporcionar seguridad a los diálogos con bases de datos remotas. La seguridad de diálogo le permite a su solución Service Broker usar autorización, autenticación y cifrado. Algunos de estos parámetros se pueden controlar mediante las sentencias BEGIN DIALOG CONVERSATION. Especificaciones adicionales son controlados a través de enlaces de servicio remoto. (Para más información clic AQUI)
  • Extremos de servicios Broker: Estos se usan para configurar SQL Server para enviar y recibir mensajes a través de conexiones TCP / IP. Los extremos (endpoints) se puede utilizar para controlar las conexiones a las terminales y garantizar la seguridad del transporte. De manera predeterminada, Service Broker no puede comunicarse en la red porque no hay extremos de Service Broker a menos que se configuren.

Creación de aplicaciones de Service Broker (Más información AQUI)
Varias aplicaciones funcionan juntos para proporcionar una solución de Service Broker. Para iniciar una conversación y enviar mensajes, una solicitud  inicia la instrucción BEGIN DIALOG, que incluye toda la información necesaria sobre la marcha y servicios de destino, contratos, etc. Una vez que los mensajes han sido enviados a una cola, la aplicación de destino se debe iniciar a recibir y procesar mensajes. Puede configurar uno o más de las cuatro opciones de inicio para las aplicaciones de servidor Broker en su solución.
Aplicaciones donde hay un flujo continuo de mensajes y aplicaciones que requieren una gran cantidad de recursos para la puesta en marcha puede ser configuradas para iniciarse cuando se inicia SQL Server, como parte del grupo de inicio de Microsoft Windows o como un servicio. Debido a que estas aplicaciones están siempre en funcionamiento, continuamente necesitan y mantienen sus recursos, pero también están disponibles de inmediato para procesar los mensajes sin el intervalo de tiempo requerido para iniciar una nueva solicitud.
La segunda opción de inicio que se pueden configurar utiliza el Agente SQL Server para programar la aplicación se ejecute en momentos específicos. Utilizando las tareas programadas para iniciar las aplicaciones es común para las aplicaciones de destino que pudiera llevarse a cabo como un lote. Por ejemplo, los empleados pueden presentar los formularios de reembolso de viaje durante todo el día. Los mensajes de reembolso se pueden almacenar en la cola todo el día. Durante la noche, la aplicación de destino recibe todos los mensajes y, o bien los procesos decheque de reembolso o marca el mensaje para una revisión manual y usa otra aplicación para enviar el formulario a otra cola a la espera de ser transformadas por otra aplicación de destino. La figura siguiente muestra el flujo de información para el ejemplo de reembolso de gastos.
 
En el escenario de reembolso de gastos, pueden pasar semanas sin ningún tipo de mensajes que se envían a la cola de revisión manual. En tal situación, sería ineficiente para procesar esta cola en forma programada. También, porque es importante para la compañía para manejar los reembolsos de gastos de manera rápida y eficiente, se necesita un método de activación en apoyo de estos requisitos. Los procesos de activación interna y basados en eventos, deben cumplir con estos requisitos.

Activación de Service Broker
Puede configurar la activación de Service Broker para que sus soluciones se inicien automáticamente. Los dos métodos de activación automática son la activación interna y la activación basada en eventos. La activación interna se gestiona mediante el uso de procedimientos almacenados y requiere que la aplicación sea escrita como los procedimientos almacenados. La activación basada en eventos es administrada por una aplicación externa y es activado por un evento de SQL Server activación enviado a la cola de la aplicación externa.
Estas activaciones de Service Broker son ideales para aplicaciones que puede iniciar de forma rápida y para aplicaciones en las que la frecuencia o el número de mensajes que varía con el tiempo. Además de iniciar una aplicación en donde los mensajes se reciben con poca frecuencia, también puede utilizarse la activación de Service Broker para las aplicaciones que añaden los procesos de lectura a la cola de mensajes de forma automática cuando comienzan a acumularse en una cola.

Habilitando el servicio Service Broker
Entre las nuevas caracteristicas de SQL Server 2008, esta que Service Broker está habilitado por defecto en todas las bases de datos de usuario, así como la base de datos msdb. Al utilizar el Explorador de objetos en SSMS, se pueden ver y modificar las propiedades relacionadas a service Broker en la página Opciones de la ventana Propiedades de base de datos en particular, como se muestra en la figura siguiente:


Por otra parte, la siguiente consulta muestra las propiedades de Service Broker para la base de datos AdventureWorks2008R2:

SELECT name, service_broker_guid
, is_broker_enabled, is_honor_broker_priority_on
FROM sys.databases
WHERE name = 'AdventureWorks2008R2'
Lo que nos muestra esto:



También puede utilizar el comando ALTER DATABASE para modificar las opciones de bases de datos relacionadas con Service Broker.
Se utiliza la sintaxis siguiente con el comando ALTER DATABASE para modificar las opciones de Service Broker:




La opción DISABLE_BROKER desactiva el Service Broker en la base de datos actual y evita que los mensajes sean entregados, pero mantiene el identificador de Service Broker actual. Cuando se utiliza la opción para volver a activar ENABLE_BROKER Service Broker, el identificador de Service Broker actual también se mantiene. La opción NEW_BROKER crea un identificador nuevo de Service Broker y de inmediato elimina todas las conversaciones existentes sin necesidad de poner fin a las conversaciones o el enviar de mensajes de diálogo final. Todas las conversaciones que se iniciaron con el identificador de Service Broker anterior debe ser reiniciado para ser válidas. La opción ERROR_BROKER_CONVERSATIONS se puede utilizar si dos bases de datos implicadas en las conversaciones dejan de estar sincronizadas debido a un fallo o un error en una de las bases de datos. Cuando se utiliza esta opción, Service Broker mantiene activado y el identificador de Service Broker se mantiene, pero todas las conversaciones se concluyó con un mensaje de error. Esta opción también se puede utilizar para decir una aplicación para realizar una limpieza regular de las conversaciones existentes. La última opción, HONOR_BROKER_PRIORITY, se pone en ON o OFF para especificar si el sistema da preferencia a los mensajes que provienen de conversaciones con un valor de alta prioridad.

Retardo en HONOR_BROKER_PRIORITY
Cambios en la opción HONOR_BROKER_PRIORITY no surtirán efecto para los diálogos con los mensajes existentes hasta que los mensajes actuales se han enviado. Esto significa que podría haber una demora significativa entre el momento se establece la opción, y cuando todos los diálogos han empezado a utilizar la nueva configuración.

Configuración de los componentes de Service Broker
Antes de que usted pueda construir su solución de aplicaciones de servicio Broker, tienes que ser capaz de crear y configurar los componentes individuales. Los componentes que se configuran son las colas, servicios, tipos de mensajes, los contratos y las prioridades de conversación.
Creación de tipos de mensaje
Cuando se crea un tipo de mensaje, se define el nombre del mensaje. También se define si Service Broker realiza la validación de los mensajes con ese nombre. Antes de comenzar las conversaciones, debe definir los tipos de mensajes iguales para ambos lados de la conversación.
Se puede ver la sintaxis completa del comando CREATE TYPE mensaje aquí:



El comando CREATE MESSAGE TYPE incluye los siguientes argumentos:

• message_type_name: Define el nombre del tipo de mensaje que se hace referencia cuando se crea el contrato (s) que utilizan este tipo de mensaje. Cuando se crea un tipo de mensaje, se crea en la base de datos actual y se debe especificar un nombre de una parte (no incluyendo el servidor, base de datos o esquema).
• AUTHORIZATION: Define el propietario para el tipo de mensaje. Si se inicia la sesión con una cuenta que no es sa, debe definir su propia cuenta de usuario, un rol que le pertenecen, o una cuenta de usuario al que se tiene el permiso suplantar. Si no se especifica esta cláusula, el valor por defecto a su cuenta de usuario actual.
• VALIDACIÓN: seleccione NONE, EMPTY, WELL_FORMED_XML, o VALID_XML WITH SCHEMA COLLECTION schema_collection_name para definir el tipo de validación que Service Broker debe realizar en los mensajes de este tipo. La configuración por defecto de validación de NONE especifica que no se realiza la validación. La configuración de validación EMPTY especifica que el cuerpo del mensaje debe ser NULL. El ajuste WELL_FORMED_XML especifica que el cuerpo del mensaje debe contener XML bien formado. La última opción, VALID_XML especifica el nombre de una schema collection existente XML a la que el cuerpo del mensaje debe cumplir.

El siguiente código crea un tipo de mensaje con el nombre [/ / Adventure-Works.com/SampleType]:

Creación de colas (Más información AQUI)
Cuando se crea una solución de Service Broker, debe crear al menos una cola. Service Broker utiliza colas para contener los mensajes. Se asocian con las colas de los servicios cuando se crea el servicio.
Se puede ver la sintaxis completa del comando CREATE QUEUE aquí:


La única opción que se requiere es el nombre de cola. Este comando crea una cola llamada TestQueue:
CREATE QUEUE TestQueue

• object: Ajústelo en el nombre de la cola que se creará. El nombre del objeto se expresa como un completo nombre de tres partes (database_name.schema_name.queue_name) o un nombre parcial. Si no se especifica un nombre de base de datos, la base de datos actual se utiliza. Si un esquema no se especifica el esquema predeterminado para el usuario que está ejecutando la instrucción CREATE QUEUE se emplea.
• STATUS: Ajústelo en ON si la cola está disponible o cuando la cola no está disponible y los mensajes no se pueden agregar o quitar de la cola. El valor predeterminado es ON.
• RETENTION: Ajústelo en ON si desea que despues de enviar y recibir mensajes de las conversaciones que utilizan esta cola estos permanezcan en la cola. La configuración por defecto de OFF elimina los mensajes de la cola cuando el comando RECEIVE se emite.
• ACTIVATION: Especifica información sobre el procedimiento almacenado para empezar a procesar los mensajes en la cola, e incluye los siguientes argumentos:
  • STATUS: Ajústelo en ON si Service Broker debe iniciar el procedimiento almacenado.
  • PROCEDURE_NAME: Ajústelo en el nombre del procedimiento almacenado necesario. Al igual que el nombre de la cola, el nombre del procedimiento se puede expresar como un nombre total o parcial de tres partes en el formato database_name.schema_name.queue_name.
  • MAX_QUEUE_READERS: Ajústelo en el número máximo de instancias del procedimiento almacenado que se puede iniciar al mismo tiempo
  • EXECUTE AS: Especifica la cuenta de usuario que se utilizará para el contexto de ejecución del procedimiento almacenado. Este valor se puede establecer a SELF, el OWNER o un USER_NAME de la base de datos.
• ON: Especifica el grupo de archivos en los que debería ser la cola creada.

Buenas Practicas: Tanto para el rendimiento y los beneficios de recuperación, se recomienda que cree las colas de un grupo de archivos dedicado para permitir restauraciones parciales y minimizar de entrada / salida (I / O) en conflicto con otra base de datos lee y escribe.

Creación de contratos (Más información AQUI)
Los contratos especifican los tipos de mensajes que se pueden utilizar durante una conversación particular. El contrato también especifica por quién (iniciador, destino o ambos) cada tipo de mensaje en particular pueden ser enviado.
Se puede ver la sintaxis completa del comando CONTRATO crear aquí:



El comando CREATE CONTRACT incluye los siguientes argumentos:

• contract_name: Define el nombre del contrato que se hace referencia cuando se inicia una conversación. Cuando se crea un contrato, se crea en la base de datos actual. No se puede especificar nombres de servidor, base de datos, o el esquema de la definición.
  • AUTHORIZATION: Define el dueño del contrato. Si usted está registrado como una cuenta que no sea sa, debe definir una cuenta de usuario, o un rol con esos permisos. Si no se especifica esta cláusula, el valor por defecto a su cuenta de usuario actual.
  • message_type_name: Define los nombres de los tipos de mensajes que se incluyen en las conversaciones que especifica este contrato. Usted puede agregar varios tipos de mensaje a un contrato.
  • SENT BY: Establecer INITIATOR, TARGET, o ANY para especificar qué servicios pueden enviar el tipo de mensaje especificado en el message_type_name correspondiente. ANY especifica que los servicios tanto de iniciador y el destino puede utilizar el tipo de mensaje correspondiente.

Cada base de datos incluye un contrato con nombre DEFAULT que especifica el tipo de mensaje por defecto (DEFAULT), que utiliza una validación de NONE:
En el siguiente ejemplo se crea un contrato de reembolso de gastos basándose en tres tipos de mensaje.

CREATE MESSAGE TYPE     [//Adventure-Works.com/Expenses/SubmitExpense]    

 VALIDATION = WELL_FORMED_XML ;         
CREATE MESSAGE TYPE     [//Adventure-Works.com/Expenses/ExpenseApprovedOrDenied]     

VALIDATION = WELL_FORMED_XML ;         
CREATE MESSAGE TYPE     [//Adventure-Works.com/Expenses/ExpenseReimbursed]     

VALIDATION= WELL_FORMED_XML ;         
CREATE CONTRACT     [//Adventure-Works.com/Expenses/ExpenseSubmission]     

( [//Adventure-Works.com/Expenses/SubmitExpense]           

SENT BY INITIATOR,       [//Adventure-Works.com/Expenses/ExpenseApprovedOrDenied]          

 SENT BY TARGET,       [//Adventure-Works.com/Expenses/ExpenseReimbursed]          

SENT BY TARGET     ) ;

Creación de servicios (Más información AQUI)

Una vez que haya creado una cola, el siguiente paso en el proceso es la creación de los servicios que definen la cola y el contrato al que está vinculado el servicio. El servicio representa la tarea empresarial o grupo de tareas que requiere la aplicación. Aunque muchos servicios puede señalar a una sola cola, cada servicio utiliza normalmente una cola dedicada a facilitar la recepción y procesamiento de mensajes.
Se puede ver la sintaxis completa del comando CREATE SERVICE aquí:



A diferencia de las colas, donde puede definir la base de datos y el esquema en el que se van a crear, los servicios se crean en la base de datos actual y no se puede especificar un esquema para el servicio.
La opción de autorización define el propietario del servicio. Debe definir el nombre de la cola, donde los mensajes de este servicio se almacena en la opción ON QUEUE.

Buenas Practicas: Aunque no es necesario especificar un nombre de esquema como parte del nombre de la cola si la cola se encuentra en el esquema predeterminado del usuario que ejecuta el comando, incluyendo el nombre del esquema en los scripts mejora la legibilidad y elimina los posibles problemas si el script se ejecuta en el futuro en un contexto de usuario diferente.

Si un contrato no está definido en el comando CREATE SERVICE, el servicio sólo podría iniciar conversaciones y no ser un objetivo. Si en el contrato se especifica DEFAULT, el servicio puede ser un objetivo de las conversaciones que utilizan el contrato DEFAULT. La palabra DEFAULT en este contexto de la consulta está siendo utilizado como un nombre delimitado de un contrato y no como una palabra clave como en algunos otros comandos, como CREATE TABLE.

Configuración de prioridades de la conversación (Más información AQUI)
Usted puede utilizar el CREATE BROKER PRIORITY COMMAND para establecer un nivel de prioridad para las conversaciones que están asociados con determinados contratos y servicios. Al definir la prioridad de broker se define el nombre de la prioridad de conversación, el nombre del contrato, los nombres de servicios locales y remotos, y el nivel de prioridad dado a la combinación de los contratos y servicios definidos. El nivel de prioridad se puede ajustar a cualquier valor entre 0 y 10.
El valor predeterminado de 5 se asigna si el PRIORITY_LEVEL no se especifica o se establece en DEFAULT.
La sintaxis completa del comando CREATE BROKER PRIORITY está aquí:



Enviar y recibir mensajes
Una vez que haya configurado los componentes de la definición del servicio y la red y los componentes de seguridad, necesita configurar sus aplicaciones para iniciar diálogos, enviar mensajes y manejar los mensajes que reciben.

Creación de una conversación de diálogo

Puede utilizar la instrucción BEGIN DIALOG para iniciar una conversación de diálogo de un servicio a otro. Un cuadro de diálogo que existe entre los dos servicios y proporciona la entrega de mensajes, lo que garantiza que cada mensaje que se recibe una sola vez y en orden.
La sintaxis completa del comando BEGIN DIALOG está aquí:



Antes de que el comando BEGIN DIALOG se ejecute, se necesita definir la variable @ dialog_handle como uniqueidentifier. Una vez definida la variable @dialog_handle, debe incluir los siguientes argumentos como parte del comando BEGIN DIALOG:

• FROM SERVICE: Define el nombre del servicio iniciador del cuadro de diálogo. Este servicio debe existir en la base de datos actual. La cola vinculados a este servicio se utiliza para almacenar los mensajes devueltos por el servicio de destino.
• TO SERVICE: Define el nombre del servicio de destino al que se envían los mensajes. Este nombre de servicio es distingue mayúsculas de minúsculas, incluso si la base de datos utiliza una intercalación que no distingue mayúsculas y minúsculas.

Los argumentos opcionales siguientes también se puede definir como parte del comando BEGIN DIALOG:

• service_broker_guid: Establece en el identificador único global (GUID) de Service Broker en una base de datos particular. Este argumento se puede utilizar si el servicio de destino está alojado en multiples bases de datos y quieres dirigir el diálogo con el Service Broker a una base de datos particular.


• ‘CURRENT DATABASE’: es el identificador de Service Broker de la base de datos actual que se utiliza.


• ON CONTRACT: Especifica el contrato que se exige para este diálogo. Si un contrato no se especifica, el contrato denominado DEFAULT se utiliza para este diálogo.


• RELATED_CONVERSATION o RELATED_CONVERSATION_GROUP: Define el related_conversation_handle para agregar una sola conversación o las relacionadas con related_conversation_groupid para el grupo al que se debe este nuevo cuadro de diálogo añadido.


• LIFETIME: Especifica la cantidad máxima de tiempo que la conversación puede permanecer abierta.


• ENCRYPTION: Establecer en OFF o ON para definir el estado de cifrado de los mensajes incluidos en este cuadro de diálogo. La configuración por defecto, ON, exige que los mensajes entre los servicios en diferentes instancias de SQL Server se cifren, pero los mensajes entre los servicios en la misma instancia del servidor SQL no están cifrados. Sin embargo, la clave maestra de base de datos y los certificados correspondientes se debe configurar si el iniciador y servicios de destino están en bases de datos separadas, aún cuando sea en la misma instancia. Esto facilita el traslado de una base de datos a una instancia independiente en el futuro.

En su forma más simple, el comando BEGIN DIALOG es similar al siguiente código:

DECLARE @dialog_handle uniqueidentifier
BEGIN DIALOG @dialog_handle
FROM SERVICE AW_Initiate
TO SERVICE AW_Target

Enviando mensajes (Más información AQUI)

Una vez que ha creado un cuadro de diálogo, utilice el comando SEND para enviar mensajes en la conversación creada en el comando BEGIN DIALOG.
El comando SEND es bastante sencillo y utiliza la siguiente sintaxis:

Una vez que el iniciador envía el mensaje, el mensaje se almacena en la cola relacionadas con el servicio de destino. El parámetro de tipo de mensaje es opcional y normalmente no se incluye como parte del comando SEND. Por el contrario, se define como parte de la especificación del contrato. Aunque la expresión del cuerpo del mensaje es opcional, si no se especifica, el cuerpo del mensaje está vacío.
Normalmente, el cuerpo del mensaje contiene información pertinente al servicio de destino.

Recibiendo mensajes (Más información AQUI)
Una vez que los mensajes se añaden a la cola, puede utilizar una instrucción SELECT simple para ver los mensajes incluidos en la cola. Para procesar los mensajes, utilice el comando RECEIVE para recuperar uno o más mensajes de la cola. Se leen los mensajes de la parte superior de la cola. Si la opción de retención de la cola está en OFF, los mensajes se eliminan de la cola cuando el comando RECEIVE las recupera. Esta es la sintaxis del comando RECEIVE:



El comando RECEIVE acepta los siguientes argumentos:

• WAITFOR: Especifica que la instrucción RECEIVE espera a que llegue un mensaje a la cola en caso de no haber ningún mensaje.  Este argumento sólo se utiliza si la cola está vacía.
• TOP( n ) : Especifica el número máximo de mensajes que se recupera de la cola. Si la primera opción no está incluido en el comando, todos los mensajes que cumplen los criterios definidos en la instrucción RECEIVE se devuelven.
• column Specifier: Enumera un nombre de columna, un alias para una expresión de columna.
• FROM: Especifica el nombre de la cola de la que desea recuperar los mensajes.
• INTO: Especifica la variable de tabla en la que RECEIVE coloca los mensajes. La variable de tabla debe tener el mismo número de columnas que los mensajes. El tipo de datos de cada columna en la variable de tabla debe ser implícitamente convertible al tipo de datos de la columna correspondiente en los mensajes. Si no se especifica INTO, los mensajes se devuelven como un conjunto de resultados.
• WHERE: Limita las filas recuperadas mediante la especificación de una conversación o un grupo de conversación .
• TIMEOUT: Limita la cantidad de tiempo que el comando RECEIVE espera de un nuevo mensaje cuando la opción WAITFOR también se especifica. El tiempo de espera predeterminado de –1, lo que especifica que el comando RECEIVE espera una cantidad ilimitada de tiempo para un nuevo mensaje.

Nota: Aunque siempre es buena práctica de programación para poner un punto y coma (;) al final de cada instrucción T-SQL, esto se requiere en la declaración que precede a una instrucción RECEIVE en un lote.

RESUMEN DE LA LECCION:

• Service Broker proporciona capacidades de mensajería asincrónica confiable para la instancia de SQL Server.
• Es necesario configurar los componentes de Service Broker para su solución. estos componentes pueden incluir los tipos de mensajes, los contratos, los servicios, las colas, los diálogos y las prioridades de conversación.
• Se utiliza los comandos BEGIN DIALOG, SEND y RECEIVE para controlar las conversaciones individuales entre los dos servicios.