Trabalhando com o Service Broker no Microsoft SQL Server 2008, 2008 R2 e 2012 – Parte III.

Boa tarde, Comunidade!

Após um merecido período de Férias, estou começando a retomar minhas atividades Profissionais, Acadêmicas, bem como, para toda Comunidade Microsoft, em especial aos amantes do Microsoft SQL Server.

Nos últimos dias andei lendo um pouco sobre algumas novidades do Microsoft SQL Server 2014 e sinceramente fiquei surpreso com o trabalho que a Equipe de Desenvolvimento desta nova versão esta fazendo. Mas enquanto esta nova versão e suas novidades não estão presentes, vamos continuar utilizando e descobrindo o que as atuais versões oferecem.

Como você deve esta acompanhando, estamos na terceira parte deste artigo sobre o Service Broker dedicado as versões 2008, 2008 R2 e 2012. Acredito que esta parte seja a mais importante e desafiadora, onde pretendo apresentar como o Service Broker pode realizar o processo de Envio, Tratamento e Recebimento de Mensagens, algo que particularmente deverei muito tempo para entender, não por pensar ou imaginar que seja algo complexo, pelo contrário pela falta de cenário até determinado momento que eu não conseguia encontrar.

Para que você possa acompanhar e entender o funcionamento do Service Broker em relação ao nosso cenário, recomendo que acesse e leia as Partes I e II publicadas anteriormente nos seguintes links:

https://pedrogalvaojunior.wordpress.com/2013/10/22/trabalhando-com-o-service-broker-no-microsoft-sql-server-2008-2008-r2-e-2012-parte-i/

https://pedrogalvaojunior.wordpress.com/2013/11/21/trabalhando-com-o-service-broker-no-microsoft-sql-server-2008-2008-r2-e-2012-parte-ii/

Vou começar esta parte destacando o processo de Envio de Mensagens, que consiste basicamente no uso dos comandos Begin Dialog Conversation e Send.

Desejo uma boa leitura e espero que goste deste conteúdo.

Processo de Envio de Mensagens

Conforme apresentado na Parte I, o Processo de Comunicação (Conversação) entre o Service Broker e as aplicações que fazem uso do mesmo é algo muito similar ao funcionamento dos Correios, onde existe a Troca de Dados (mensagens) envolvendo o remetente e seu destinatário.

No Service Broker este processo de comunicação ocorre através do uso dos comandos Begin Dialog Conversation e Send, onde o processo se inicia através do uso do Begin Dialog e o Send vai ocorrer através do Send.

Comando Begin Dialog Conversation

O comando Begin Dialog Conversation basicamente orienta o SQL Server a iniciar um bloco de conversação entre um ou mais serviços, o que normalmente ocorre através da troca de mensagens com no mínimo dois serviços.

As informações especificadas na instrução BEGIN DIALOG CONVERSATION são semelhantes ao endereço em uma carta; o Service Broker usa as informações para entregar as mensagens ao serviço correto. Este comando apresenta um conjunto único de argumentos, para determinar da melhor forma possível o processo de conversação. A seguir apresento a relação de argumentos:

  • @dialog_handle: Variável utilizada para armazenar o identificador do diálogo gerado retornada pela instrução BEGIN DIALOG CONVERSATION. Obrigatoriamente esta variável deve ser do tipo Uniqueidentifier.

 

  • From Service initiator_service_name: Determina o serviço que inicia o diálogo. O nome especificado deve ser o nome de um serviço no banco de dados atual. A fila especificada para o serviço iniciador recebe mensagens retornadas pelo serviço de destino e mensagens criadas pelo Service Broker para essa conversa.

 

  • To Service ‘target_service_name’: Especifica o serviço de destino com o qual será iniciado o diálogo. O target_service_name  é  do tipo nvarchar(256). O Service Broker usa uma comparação byte a byte do conjunto de caracteres existentes na mensagem. Esta comparação diferencia maiúsculas de minúsculas e não leva em conta o agrupamento atual.

 

  • Service_broker_guid: Informa o banco de dados que hospeda o serviço de destino. O service_broker_guid é do tipo nvarchar(128). Através da System Table Sys.Databases é possível obter o service_broker_guid.

 

  • ‘CURRENT DATABASE’: Apresenta que a conversa usa o service_broker_guid no banco de dados atual.

 

  • ON CONTRACT contract name: Especifica o contrato que essa conversa deverá utilizar e envolver no processo de troca. Quando este argumento é omitido, a conversa utilizará o contrato chamado DEFAULT.

 

  • RELATED_CONVERSATION = related_conversation_handle: Especifica o grupo de conversa existente ao qual um diálogo é adicionado. Quando esta cláusula estiver presente, o diálogo pertencerá ao mesmo grupo de conversa envolvido no diálogo especificado nos argumentos related_conversation_handle.

 

  • RELATED_CONVERSATION_GROUP =related_conversation_group_id: Determina o grupo de conversa existente ao qual a um novo diálogo é adicionado. Quando esta cláusula estiver presente, a nova caixa de diálogo será adicionada ao grupo de conversa especificado por related_conversation_group_id.

 

  • LIFETIME = dialog_lifetime: Declara o limite máximo de tempo que o diálogo permanecerá aberto. Para o diálogo ser concluído com êxito, os pontos de extremidade devem finalizar explicitamente o diálogo antes que seu tempo de vida expire. O valor dialog_lifetime deve ser expresso em segundos. O tempo de vida é do tipo int. Quando nenhuma cláusula LIFETIME é especificada, o tempo de vida da caixa de diálogo é o valor máximo do tipo de dados int.

 

  • ENCRYPTION: Especifica se as mensagens enviadas e recebidas no diálogo devem ou não ser criptografadas, quando forem enviadas para uma instância do Microsoft SQL Server. Quando ENCRYPTION = ON e os certificados necessários para oferecer suporte à criptografia não estão configurados, o Service Broker retorna uma mensagem de erro na conversa. Se ENCRYPTION = OFF, a criptografia será usada se uma associação de serviço remoto estiver configurada para o target_service_name; caso contrário, as mensagens serão enviadas descriptografadas. Se esta cláusula não estiver presente, o valor padrão será ON.

 

Importante: Todas as mensagens fazem parte de uma conversa. Portanto, um serviço iniciador deve começar uma conversa com o serviço de destino antes de enviar-lhe uma mensagem.

O serviço especificado na cláusula TO SERVICE é o endereço para o qual as mensagens são enviadas. O serviço especificado na cláusula FROM SERVICE é o endereço de retorno usado para mensagens de resposta. O início de um diálogo cria um ponto de extremidade de conversa no banco de dados para o serviço iniciador, mas não cria uma conexão de rede à instância que hospeda o serviço de destino. O Service Broker não estabelece comunicação com o destino da caixa de diálogo até que a primeira mensagem seja enviada.

Após conhecermos um pouco sobre este comando, vamos então trabalhar no nosso primeiro bloco de código, denonimado Código 1, onde estaremos iniciando nosso processo de diálogo para posterior troca de mensagens.

— 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;

 

Onde

– @MyConversationHandle: Variável utilizada para armazenar o Handle_id criado pelo SQL Server para ser utilizado neste diálogo;

– From Service: informamos o Serviço sOrigem como o nosso serviço de origem para troca de mensagens;

– To Service: Declarado o Serviço sDestino como serviço de destino envolvido na nossa troca de mensagens;

– On Contract: Declaramos o nosso do Contrato que utilizaremos neste Dialogo para os serviços envolvidos;

– Encryption = Off: Estamos informando para o SQL Server que nossa a mensagem que será trocada neste diálogo não necessita ser criptografada; e

– Lifetime = 600: Informa o Service Broker que este diálogo terá um tempo máximo de vida útil de 600 segundos, quando este tempo se esgotar e o diálogo ainda existir o mesmo deverá ser finalizado de forma obrigatória.

Nota: Ao executar este bloco de código você vai observar que o Microsoft SQL Server praticamente não estará realizando nenhum procedimento ou troca de mensagens. O objetivo do Código 1 é ilustrar e apresentar como podemos criar um novo diálogo, sendo que, este mesmo bloco será utilizado em posteriormente.

Legal nosso diálogo foi iniciado e agora o Service Broker começa a trabalhar aguardando posteriormente os dados que serão adicionados para fazer parte da mensagem que em seguida enviada.

Vamos então conhecer um pouco sobre o Comando Send, responsável direto no processo de envio de mensagens por parte do Service Broker.

Comando Send

Da mesma forma que o Comando Begin Dialog Conversation, o comando Send também esta envolvido no processo de troca de mensagens entre os serviços que estão ligados ao Service Broker.

O Send tem como principal função possibilitar o envio de mensagens entre uma ou mais conversas existentes. Através do Send o SQL Server é orientado a realizar o chamado PULL (Empurrar) empurrando os dados que estão armazenadas na estrutura que compõem a mensagem para serem deslocados entre os serviços de origem e destino, passando internamente na estrutura do banco de dados ao qual o mesmo esta relacionado.

Este comando também apresenta um conjunto único de argumentos que podem ser utilizados para determinar uma melhor forma de envio dos dados, conforme destaco a seguir:

  • ON CONVERSATION conversation_handle: Especifica as conversas às quais a mensagem pertence. O conversation_handle deve conter um identificador de conversação válido. O mesma identificador de conversação não pode ser usado mais de uma vez.

 

  • MESSAGE TYPE: Informa o tipo da mensagem enviada. Esse tipo de mensagem deve ser incluído nos contratos de serviço usado por essas conversas. Esses contratos devem permitir que o tipo de mensagem seja enviado desse lado da conversa. Se essa cláusula for omitida, a mensagem será do tipo DEFAULT.

 

  • message_body_expression: Fornece uma expressão que representa o corpo de mensagem. A message_body_expression é opcional. Entretanto, se message_body_expression estiver presente, a expressão deverá se de um tipo que possa ser convertido em varbinary(max). A expressão não pode ser NULL. Se essa cláusula for omitida, o corpo de mensagem será vazio.

Agora já podemos realizar o processo de criação e envio da nossa mensagem, para isso vamos utilizar o Bloco de Código 2 apresentado abaixo.

— 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″?>

<MSN Num=”1″>

<Titulo>Minha mensagem</Titulo>

<Texto>Olá esta é uma mensagem de teste no Service Broker</Texto>

</MSN>’;

 

— Enviando uma mensagem no Diálogo —

SEND ON CONVERSATION @MyConversationHandle

MESSAGE TYPE [mtEnvioMensagem] (@MyMensagemServiceBroker)

 

Commit Transaction

 

Observações:

– Note que para conseguirmos realizar todo processo de Diálogo e Envio da Mensagem somos obrigados a executar novamente o Bloco de Código 1 dentro do Bloco de Código 2.

– Outro ponto importante é o uso do comando Commit Transaction para forçar o SQL Server a realizar o processamento e confirmação das instruções que compõem este bloco de código, desta forma, estaremos garantindo que o envio da mensagem foi realizado e encerrando o bloco de transação.

Show de Bola, nossa mensagem foi enviada e agora aquela pergunta que não pode faltar. A onde foi parar nossa mensagem, é justamente esta resposta que eu vou apresentar no Bloco de Código 3, como se fosse um aperitivo que adicionamos ao nosso almoço e que será desvendado na próxima parte deste artigo.

— Código 3 – Localizando – Mensagem –

Select Cast(message_body as xml) from qDestino

 

Não existe segredo nesta parte, nossa mensagem foi enviada para nossa fila qDestino que internamente no nosso banco de dados representa uma tabela, que poderá ser utilizada como mecanismo para consulta e obtenção de dados. Observe que após o processamento desta pequena Query o Management Studio vai retornar nossa mensagem no formato XML.

 

Ótimo conseguimos chegar ao final de mais uma parte desta longa caminhada, hoje realizamos todo processo de criação de diálogos e envio de mensagens, podemos observar a maneira que o SQL Server faz uso destes componentes.

Como um pequeno aperitivo do que teremos na próxima parte, ilustrei de forma bem simples como a mensagem que estamos trabalhando neste momento é tratada pelo SQL Server, este aperitivo será melhor degustado na Parte IV, onde vamos trabalhar ainda mais com nossas Queues (Filas) em conseqüência realizar o recebimento das mensagens.

Mais uma vez obrigado, espero que esta tenha gostado, vou ficando por aqui, agradeço a sua atenção e visita ao meu blog. Estamos quase no final desta aventura e com certeza alguns pontos importantes ainda estão por serem revelados e trabalhos.

Um grande abraço.

Até mais.

Autor: Junior Galvão - MVP

Profissional com vasta experiência na área de Tecnologia da Informação e soluções Microsoft. Graduado no Curso Superior em Gestão da Tecnologia de Sistemas de Informação pela Uninove - Campus São Roque. Pós-Graduado no Curso de Gestão e Engenharia de Processos para Desenvolvimento de Software com RUP na Faculdade FIAP - Faculdade de Informática e Administração Paulista de São Paulo. Pós-Graduado em Gestão da Tecnologia da Informação Faculdade - ESAMC Sorocaba. Cursando Mestrado em Ciências da Computação - UFSCar - Campus - Sorocaba. Formação MCDBA Microsoft, autor de artigos acadêmicos e profissionais postados em Revistas, Instituições de Ensino e WebSistes. Meu primeiro contato com tecnologia ocorreu em 1995 após meus pais comprarem nosso primeiro computador, ano em que as portas para este fantástico mundo se abriram. Neste mesmo ano, comecei o de Processamento de Dados, naquele momento a palavra TI não existia, na verdade a Tecnologia da Informação era conhecida como Computação ou Informática, foi assim que tudo começou e desde então não parei mais, continuando nesta longa estrada até hoje. Desde 2001 tenho atuado como Database Administrator - Administrador de Banco de Dados - SQL Server em tarefas de Administração, Gerenciamento, Migração de Servidores e Bancos de Dados, Estratégias de Backup/Restauração, Replicação, LogShipping, Implantação de ERPs que utilizam bancos SQL Server, Desenvolvimento de Funções, Stored Procedure, Triggers. Experiência na Coordenação de Projetos de Alta Disponibilidade de Dados, utilizando Database Mirroring, Replicação Transacional e Merge, Log Shipping, para versões: 2000, 2005, 2008, 2008 R2, 2012 e 2014. Atualmente trabalho como Administrador de Banco de Dados no FIT - Instituto de Tecnologia da Flextronics, como também, Consultor em Projetos de Tunnig e Performance para clientes. Desde 2008 exerço a função de Professor Universitário, para as disciplinas de Banco de Dados, Administração, Modelagem de Banco de Dados, Programação em Banco de Dados, Sistemas Operacionais, Análise e Projetos de Sistemas, entre outras. Possuo titulação Oficial Microsoft MVP - SQL Server renovada desde 2007.

Um comentário em “Trabalhando com o Service Broker no Microsoft SQL Server 2008, 2008 R2 e 2012 – Parte III.”

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s