1. Sempre use tipos de mensagem com várias partes

O BizTalk trata de mensagens, mas não apenas mensagens de email. Documentos, formulários do InfoPath, arquivos binários grandes, registros do SQL, arquivos simples e qualquer XML podem ser processados como mensagens, tirando proveito da comunicação assíncrona. Depois de se habituar a ele, a programação orientada a mensagens se torna um paradigma tão legal e útil quanto a programação orientada a objetos.

As mensagens no BizTalk são dados, e cada mensagem deve ser de um tipo de mensagem selecionado. O tipo de mensagem mais comum no BizTalk é um esquema, o que quer dizer que a mensagem se baseia em um arquivo .XSD que especifica a estrutura de campos e registros na mensagem. Consulte msdn2.microsoft.com/en-us/library/ms942182.aspx para obter uma discussão completa sobre os esquemas e mapas no BizTalk.

Um dia, ao programar em BizTalk, você certamente decidirá que quer mudar o esquema no qual uma mensagem se baseia. O problema é que se você já tiver selecionado essa mensagem para uma forma Send ou Receive e a conectado a uma porta de orquestração, obterá este erro ao tentar alterar Message Type:


Property value is not valid: One or more Send or Receive actions are
connected to Ports and are using this Message. Please disconnect the
actions before changing the Message Type.


Antes de fazer o que é sugerido pela mensagem de erro, vamos pensar um pouco sobre o que está envolvido. Primeiro, você terá de inspecionar todas as formas Receive e Send para determinar se usam uma variável Message que está associada (que tem seu Message Type definido) ao esquema que deseja alterar. Atualmente, não há um recurso no BizTalk que forneça uma auditoria disso ou que gere um mapa de dependências; simplesmente não seria conveniente criar uma única orquestração com tantas formas Receive/Send e você precisaria desse recurso. Na terrível orquestração mencionada anteriormente, a maioria das formas Receive e Send usavam variáveis Message diferentes, mas todas apontavam para a mesma definição de esquema (o mesmo Message Type)!

Segundo, depois de localizar todas as formas Receive/Send, será necessário excluir suas conexões Port. Terceiro, você terá de alterar a variável Message de forma que a propriedade Message Type seja definida para o novo esquema e, em seguida, associar novamente a variável Message com cada forma Receive/Send.

Quarto (e você achou que tinha terminado), será necessário localizar todos os Port Types associados a Ports que desconectou das formas Receive/Send e redefinir também as propriedades Message Type de Operation. Veja, ao associar originalmente uma forma Receive or Send a Port, que o BizTalk define automaticamente a propriedade Message Type no tipo de Port para corresponder ao Message Type da variável Message daquela forma Receive/Send. Ao excluir a conexão entre Port e a forma Receive/Send, o BizTalk perde o Message Type de Port.

Felizmente, há uma maneira melhor de fazer isso. Um axioma da computação diz que vários problemas podem ser resolvidos adicionando-se um nível indireto. Neste caso, isso é verdadeiro; precisamos apenas usar um Multi-Part Message Type para encapsular o esquema subjacente. Inicialmente, isso é um pouco mais trabalhoso, mas muito mais flexível e, a longo prazo, você economizará tempo. Veja como isso é feito.

Ao clicar com o botão direito do mouse em Messages (Mensagens) na guia Orchestration View (Modo de exibição de orquestração) para criar uma nova mensagem, haverá quatro opções para a propriedade Message Type . É comum escolher um esquema para o tipo de mensagem, mas aqui vamos tentar algo radicalmente diferente. Clique no sinal de + para expandir Multi-Part Message Types (Tipos de mensagem com várias partes) e escolha Create New Multi-part Message Type (Criar novo tipo de mensagem com várias partes). Nomeie seu tipo de mensagem com várias partes e clique no sinal de + para expandi-lo de forma a poder ver seu membro MessagePart_1 (esse é o nome sugerido pelo BizTalk para a primeira parte de seu novo tipo de mensagem com várias partes). Agora, mude a propriedade Identifier (Identificador) de "MessagePart_1" para algo melhor, como "Body" (Corpo) (mas não use a palavra "body" com a inicial minúscula, pois trata-se de uma palavra reservada). Não esqueça de definir a propriedade Message Body Part como True (de forma que ela possa atuar como uma mensagem comum).

Acabou o trabalho extra. Finalmente, defina a propriedade Type da nova parte da mensagem (como Body) com o mesmo esquema que teria usado para um tipo de mensagem comum baseado em esquemas. Agora, a porta lógica e a forma Receive/Send usam seu tipo de mensagem com várias partes, e você poderá alterar facilmente o esquema subjacente no futuro, sem precisar desconectar a porta da forma de recebimento.



2. Sempre tente criar orquestrações com portas com ligação direta

Ao trabalhar no Port Configuration Wizard (Assistente para configuração de portas), você se move nesse diagrama de cima para baixo. Observe as três opções Direct (Direto) no diagrama. Apesar de a interface do usuário do BizTalk oferecer "Direct" como tipo de porta, usaremos o jargão específico e nos referiremos a ele como "Direct-Bound" (Com ligação direta).

A chave para entender a terminologia relativa a portas no BizTalk é compreender as noções de portas lógicas (também chamadas portas de orquestração) e portas físicas. Simplificando bastante, trata-se da diferença entre a criação de portas no Orchestration Designer (lógicas) e o uso do BizTalk Explorer ou do BizTalk Administration Console (físicas).

Quando um desenvolvedor cria uma porta Specify Later (Especificar depois) no Orchestration Designer, ele configura uma porta lógica, deixando as propriedades correspondentes da porta física para serem configuradas mais tarde pelo administrador do BizTalk. O fato de dar ao administrador a flexibilidade de configurar a porta física no ambiente de produção é um motivo importante para Specify Later ser a opção mais usada.

Com a opção Specify Now (Especificar agora), o desenvolvedor deve fazer tudo, a configuração lógica e física, e a solução é conectada. Isso não é recomendável, exceto para experimentos rápidos.

Com as portas Dynamic (Dinâmica), novamente a configuração final das propriedades da porta física é feita pelo administrador. Contudo, neste caso, o desenvolvedor também pode escrever código para definir determinadas propriedades da mensagem de saída em tempo de execução. Isso é útil para o SMTP ou o HTTP, em que a lógica de orquestração inclui uma forma Expression com uma instrução como esta:



Onde se ajustam as portas Static (Estática)? Esse termo aparece quando você cria uma porta física no BizTalk Explorer ou no BizTalk Administration Console. Se o desenvolvedor criar uma porta Specify Later ou Dynamic no Orchestration Designer (uma porta lógica), o administrador escolherá entre as quatro opções ao criar a porta física correspondente no BizTalk Explorer ou no BizTalk Administration Console

Lembre-se apenas de que as portas físicas Dynamic se referem às portas lógicas Dynamic (isso é fácil), mas que as portas físicas Static se referem às portas lógicas Specify Later. Além disso, observe a correspondência da terminologia entre Solicit-Response e Request-Response. Enfim.

Depois de descartar essas preliminares, podemos finalmente falar sobre as vantagens das portas Direct-Bound. As portas Direct-Bound são ótimas para enviar uma mensagem do BizTalk para o BizTalk. Aliás, é por isso que não faria sentido que o BizTalk tivesse uma opção Direct para portas da Web. As portas da Web vão do BizTalk para a Web, não do BizTalk para o BizTalk.

As portas Direct-Bound são autoconfiguradas, sem sacrificar a flexibilidade ou o desempenho. Uma vantagem útil das portas Direct-Bound é que nem o desenvolvedor, nem o administrador precisam criar portas físicas correspondentes no BizTalk Explorer ou no BizTalk Administration Console. Então, as portas Direct-Bound resultam em orquestrações mais autônomas e, portanto, mais fáceis de reutilizar e reimplantar de maneira independente.

Existem três tipos de porta Direct-Bound: Message Box Routing (Roteamento de caixa de mensagens), Self-Correlating (Autocorrelação) e Orchestration-to-Orchestration (Orquestração para orquestração) (também chamadas Partner Ports). O texto real dos três botões de opção no Orchestration Designer tem muito mais palavras, mas ao examiná-los, você mapeará facilmente os nomes abreviados na interface do usuário.

Dentre esses três tipos de porta, a variedade Message Box é a que aparece com mais freqüência. Ela permite que sua orquestração seja completamente independente das outras, apesar de que talvez você pretenda que ela se comunique consigo mesma. Isso implica na possibilidade de um loop infinito. Voltaremos a esse ponto daqui a pouco.

Quando uma forma Receive com a propriedade Activate definida como True estiver configurada como Message Box Routing, isso quer dizer simplesmente que uma nova instância da orquestração será disparada quando uma mensagem chegar à Message Box que corresponde ao filtro de assinatura fornecido, independentemente da origem da mensagem ou de quem a enviou. Isso poderia ajudá-lo a criar uma orquestração reutilizável, como uma função genérica em uma biblioteca de utilitários. Marty criou um elegante sistema de manipulação de exceções com base em mensagens usando essa técnica, mas essa é uma outra história.

Suponha que você deseje iniciar sua orquestração de duas formas: primeiro, se o operador colocar uma mensagem de "início" em uma pasta em uma porta (física) FILE Static One-way ou, segundo, se a orquestração enviar uma mensagem de início para si mesma, para executar uma outra instância. Sua primeira idéia poderia ser usar uma forma Listen (como um operador OR para orquestrações) com duas formas Receive abaixo dela (uma Specify Later para a porta FILE e uma Direct para Message Box). A vantagem das portas Direct-bound Message Box é que, novamente, elas não dependem da origem da mensagem. Assim, apenas uma forma Receive é necessária para iniciar esta orquestração!

Geralmente, as portas Self-Correlating Direct-Bound são usadas quando se deseja enviar mensagens de uma orquestração para a próxima de forma assíncrona. Digamos que você tenha duas orquestrações, A e B. Entre na Orchestration B e crie uma porta lógica Send sob a seção Parameters, e a defina para usar o Port Type criado na Orchestration A. Agora, todas as mensagens enviadas dessa porta na Orchestration B serão imediatamente roteadas para a porta lógica Receive criada na Orchestration A. Basicamente, estamos aproveitando a natureza de publicação/assinatura do BizTalk para encaminhar mensagens, além de carimbá-las com tokens ocultos de correlação exclusiva, portanto "Self-Correlating". Neste caso, as orquestrações têm algum conhecimento entre si, pois você está compartilhando um tipo de porta entre elas. É possível reduzir a dependência de alguma forma, definindo o Message Type da Operation em Port Type como System.Xml.XmlDocument. Essa é uma ótima maneira de fazer as orquestrações serem executadas de forma assíncrona, com algum tipo de corretor que possa receber Acks ou Nacks de outras orquestrações.

As portas Orchestration-to-Orchestration Direct-Bound (Partner) servem para enviar mensagens de forma assíncrona. Você está adicionando uma restrição mais ampla à assinatura que a existente com portas Message Box Direct-Bound. Neste caso, você informa que aceitará qualquer mensagem da orquestração parceira. Uma orquestração especifica a porta Direct-Bound, e a outra (a parceira) especifica a si própria. Tanto o remetente quanto o receptor podem se referir à porta Direct-Bound. O importante aqui é que você estará conectando duas soluções conhecidas para que se comuniquem, enquanto com as portas Message Box Direct-Bound, o remetente e o receptor se comunicam de forma menos rígida.

Vamos agora à parte divertida. Uma armadilha comum com as portas Direct-Bound, especialmente a variedade Message Box, é a criação de um loop infinito. Imagine uma orquestração simples que consiste em apenas duas formas, uma forma Receive Activate=True (Direct-Bound, claro) e uma forma Send que simplesmente encaminha a mensagem para uma porta FILE. Quando essa orquestração envia a mensagem, para onde ela vai? Como sempre, primeiro para Message Box. Quando uma mensagem chega na Message Box, o BizTalk pesquisa todas as assinaturas correspondentes. E como esta mensagem irá diferir da mensagem que ativou a orquestração primeiro? Não irá; assim, o BizTalk disparará uma outra instância de sua orquestração para processá-la e assim por diante, até que a memória seja insuficiente. Uma maneira de corrigir isso é copiar a mensagem de entrada em uma mensagem de saída recém-construída e alterar o valor de pelo menos uma propriedade promovida, de forma que o filtro de assinatura na sua forma Receive falhará ao fazer a correspondência da nova mensagem. Execute o Administration Console e vá para Group Hub (Agrupar hub) | New Query (Nova consulta) | Open Query (Abrir consulta). A próxima etapa é abrir BTSSubscriptionViewer.btq na pasta BizTalk\SDK\Utilities. Você verá que o BizTalk criará um predicado automaticamente quando o tipo de mensagem for definido para a forma Receive. No Orchestration Designer, adicione um predicado à propriedade Filter Expression de forma que a assinatura inteira tenha a seguinte aparência:





Ou, se preferir não alterar o esquema para adicionar um campo personalizado como esse, também poderá adicionar uma cláusula ao filtro de assinatura na forma Receive para testar se o nome BTS.Operation não é igual ao da sua orquestração.

Você se lembra que dissemos que o BizTalk trata de mensagens? Bem, apague isso. Na verdade, ele trata de assinaturas. Nada acontece a uma mensagem no BizTalk sem uma assinatura em uma porta Send ou em uma Orchestration.



3. Sempre use esquemas internos e externos separados

Sempre transforme as mensagens que receber para o seu próprio esquema canônico, independentemente da simplicidade do esquema ou de sua origem.

Para um processamento em pequena quantidade, isso lhe conferirá bastante flexibilidade no caso de (ou, mais apropriadamente, quando) o remetente alterar o esquema. Você não deseja que a lógica de sua orquestração dependa de quaisquer propriedades ou campos em um esquema que é controlado por outra pessoa. Se a parte remetente alterar o esquema dela, você precisará apenas alterar seu mapa, não sua orquestração. Estamos falando novamente do axioma do caminho indireto.

Ao seguir a prática recomendada de criar projetos separados do Visual Studio para mapas, orquestrações, esquemas internos e esquemas externos, torna-se mais fácil reimplantar a solução atualizada. Isso está se tornando realmente crucial para os Web Services gerados pelo Web Services Publishing Wizard (Assistente de publicação de Web Services) do BizTalk.

Se estiver com preguiça, talvez possa continuar sem inventar seu próprio esquema com novos nomes de campos. Simplesmente copie o esquema de entrada que recebeu e mapeie todos os campos do esquema de origem como estão, mas salve pelo menos uma cópia no seu projeto de esquemas internos e dê-lhe seu próprio nome.

Isso também pode reduzir o número de mapas necessários. Suponha que seja necessário mapear três tipos de mensagens de entrada para três tipos de mensagens de saída (talvez não hoje, mas no futuro). Com a aplicação dessa técnica, você cria um mapa para seu esquema canônico para cada esquema de entrada e, em seguida, um mapa de seu esquema canônico para cada esquema de saída. Há apenas seis mapas para serem criados e mantidos, não nove.

O BizTalk Server 2006 é um aplicativo grande e, felizmente, freqüentemente ele fornece várias maneiras de realizar tarefas. Mas algumas são armadilhas das quais os mais experientes aprenderam a se livrar, por vários motivos:

Evite o BizTalk Explorer no BizTalk Server 2006. Esse recurso foi fundamental no BizTalk Server 2004, então a Microsoft decidiu não tirá-lo do BizTalk Server 2006, apesar de o recurso de pacote do novo aplicativo e o BizTalk Administration Console reprojetado o tornarem redundante. Infelizmente, há determinados casos em que seu uso pode gerar confusões.
Nunca clique em Deploy (Implantar) no nível Project (Projeto) do Solution Explorer do Visual Studio® 2005. Está certo criar projetos independentemente em uma solução, mas você deve clicar em Deploy apenas no nível Solution (Solução). O motivo: o Visual Studio tenta controlar as dependências automaticamente, mas a implantação separada de assemblies no BizTalk pode fazê-lo perder esse controle.
Não espere poder copiar os arquivos de esquema (.XSD) de um projeto para outro sem editar cuidadosamente os atributos do namespace para fazer sua correspondência. Se não o fizer, poderá ter dores de cabeça.
Os profissionais do BizTalk nunca usam o Quick Promote. No tempo que levaria para seguir as etapas necessárias de correção dos tipos fornecidos por ele, presumindo que não esquecesse de fazê-lo, você mesmo poderia simplesmente criá-los de forma explícita e rápida.
Não coloque mapas em Orchestrations, a menos que precise mapear várias mensagens de entrada em uma mensagem ou gerar uma nova mensagem usando o conteúdo modificado (mapeado) de uma mensagem existente como base. Para uma implantação mais simples, é melhor colocar seus mapas em portas Receive e Send. Se o seu parceiro comercial revisar o esquema dele ou se você adicionar um novo parceiro que exige um novo mapa, não vai desejar ser forçado a atualizar seu esquema e sua orquestração.

Nunca exponha seus esquemas internos diretamente no WSDL

Isso significa que você nunca deve clicar no primeiro botão de opção no Web Services Publishing Wizard do BizTalk; sempre clique no segundo botão O primeiro botão de opção foi criado para publicar orquestrações e o segundo foi criado para soluções de mensagens puras, mas é uma boa idéia usar a segunda opção também para orquestrações.


Sim, isso é mais complexo, então sabemos que você espera um bom motivo para fazê-lo. Em uma palavra: interface. Ou, se preferir algo mais detalhado, menos rigidez! Isso lhe confere mais liberdade para alterar sua orquestração sem quebrar o chamador. Pense nisso como uma especialização do conceito da dica #3.

Vamos discutir como você pode fazer isso. Devemos lembrar uma coisa sobre o assistente: ao chegar na Etapa 2, a caixa de diálogo Web Service (Serviço Web)
é necessário clicar com o botão direito do mouse em praticamente tudo. Assim, você nomeará o Web Service e seus métodos que estão sendo criados.

Você precisa compilar o projeto de esquemas no BizTalk antes de chegar a essa etapa do Web Services Publishing Wizard; então, poderá navegar até o assembly. Na realidade, como você verá a seguir, faz sentido continuar e implantar a solução antes de executar o assistente. Mais um detalhe: ao publicar uma orquestração como um Web Service, altere a propriedade Type Modifier no tipo de porta da orquestração de Internal para Public antes da compilação e da implantação. Se não tiver feito isso ao criar a porta pela primeira vez, precisará pesquisar de verdade para chegar lá (realce o tipo de porta no painel Types (Tipos) em Orchestration View, não clicando na porta em Port Surface (Superfície da porta), que exibe um conjunto diferente de propriedades). Uma outra vantagem de publicar esquemas como Web Services é que você não precisará mais fazer isso!

Você precisará clicar com o botão direito do mouse nos nós Request e Response para escolher o esquema no qual as mensagens da Web serão baseadas. Normalmente, as orquestrações publicadas terão uma forma lógica Receive e uma forma Send para a comunicação com o chamador do Web Service. Essas formas terão mensagens associadas e essas mensagens terão um tipo de esquema (um tipo de mensagem com várias partes não é necessário, mas é recomendável). Então, você precisa informar o assistente para usar seu esquema de face externa (lembre-se da dica 3). Em seguida, você usará mapas na porta Receive (mapas de entrada e de saída) para transformar os esquemas de solicitação e resposta do Web Service nos esquemas internos esperados por sua orquestração. Quando o cliente adicionar uma referência para seu Web Service, ele obterá uma classe proxy que inclui um tipo para seu esquema de face externa. O cliente usará esse tipo para criar e preencher uma mensagem de solicitação a ser enviada ao Web Service. E ele prenderá a resposta do Web Service em um objeto que se baseia no esquema de resposta externo

Também será necessário lembrar de escolher o Pipeline XML no local Receive, ou o BizTalk não criará as propriedades BTS Message Context, uma das quais é o Message Type da mensagem de entrada do Web Service. O BizTalk sabe o Message Type porque ele o analisou utilizando o XML Disassembler no pipeline e promoveu a propriedade; ele usa esse tipo para executar o mapa de forma a transformar a solicitação no tipo que a orquestração espera.

O que realmente importa é que o nome da operação selecionado no assistente deve corresponder exatamente ao nome da operação especificado na porta lógica na orquestração. Simplesmente aceitar todos os padrões não funcionará, pois o nome da operação padrão no Orchestration Designer é "Operation_1", enquanto o nome padrão no assistente é "WebMethod1"

recomendável defini-los com um nome significativo com o formato verbo-nome, como UpdateInventory.

Lembre-se, as mensagens, mesmo mensagens de solicitação de Web Service de entrada, são roteadas para uma orquestração com base em uma assinatura. Ao ligar uma porta lógica a uma porta física, o que é necessário com portas Request-Response publicadas como Web Services (mesmo ao publicar por meio de esquemas), o BizTalk cria uma assinatura automática para você. É possível exibir a assinatura no BizTalk Administration Console selecionando "Subscriptions" como valor na janela de consulta. A assinatura do SOAP é pouco diferente da que geralmente é criada para outras portas lógica-para-física que não são Direct-Bound. As assinaturas regulares criadas pelo BizTalk para orquestrações terão a seguinte aparência:





Você pode ver que o nome digitado no assistente como MethodName deve corresponder ao nome de Operation da porta lógica na orquestração, ou a mensagem mapeada de solicitação da Web nunca será roteada para a orquestração.

Ao chegar à caixa de diálogo Web Service Project (Projeto do Web Service) no assistente, insira a URL do Web Service, por exemplo: http://localhost/MyBizTalkWebService. Além disso, você também precisa permitir que o BizTalk crie os locais de recebimento no aplicativo. Como você já implantou o aplicativo, poderá escolhê-lo na lista suspensa. Para obter mais detalhes sobre tudo isso, consulte o artigo intitulado "Como usar o Web Services Publishing Wizard do BizTalk para publicar esquemas como um Web Service" no arquivo de ajuda do BizTalk.

Eu sei que dissemos que o BizTalk trata de assinaturas, mas essa não é nossa palavra final. Como você pôde perceber nas duas últimas dicas, ele trata realmente de esquemas. Cada mensagem e cada mapa depende de um esquema (ou dois); assim, dominar os esquemas é vital para ser proficiente no BizTalk.



5. Sempre otimize o registro do BizTalk para Web Services

Se a sua orquestração do BizTalk for publicada como um Web Service, definitivamente você desejará ajustar alguns dos parâmetros padrão do ASP.NET usados pelo BizTalk. Na verdade, esses parâmetros afetam todos os artefatos do BizTalk que usam o CLR, incluindo o XLANG. O BizTalk multiplica automaticamente esses valores recomendados pelo número de CPUs que você possui. Estas são as etapas:

1. Antes de modificar o Registro, faça um backup do mesmo.

2. Crie um arquivo no Bloco de Notas com o código a seguir.



Ao criar o arquivo desta maneira, você poderá reutilizá-lo facilmente em outras máquinas que executam o BizTalk. Os valores de DWORD são hexadecimais (os scripts do Registro não usam o prefixo 0x padrão em valores hexadecimais).

3. Substitua a cadeia de caracteres "BTSHOST" pelo nome do host do BizTalk de sua máquina. Você pode executar o RegEdit primeiro para examinar o nome da chave real em sua caixa.

4. Se você salvar o arquivo com um sufixo .REG, poderá clicar duas vezes nele para executá-lo na instalação do BizTalk.

5. Execute o RegEdit e navegue até a chave CLR Hosting para verificar se os valores foram adicionados corretamente.

Consulte msdn2.microsoft.com/en-us/library/aa561380.aspx para obter mais detalhes sobre esta e outras otimizações e msdn2.microsoft.com/en-us/library/aa475435.aspx para ver um artigo excelente sobre o ajuste de desempenho para mensagens de baixa latência.



6. Sempre defina o arquivo de chave do assembly com um caminho relativo

Esta dica o ajudará a verificar a solução no controle de versão e criá-lo em uma outra caixa. Alguns desenvolvedores de sua equipe podem organizar seus ambientes com letras de unidade diferentes ou você poderá alterar a sua no futuro. Isso é realmente simples, mas talvez você esteja se perguntando o que acontece com todos esses pontos.

É recomendável que o primeiro desenvolvedor da solução crie um arquivo de chave de nome forte na mesma pasta que o arquivo da solução do Visual Studio (.sln). Em seguida, crie subpastas dessa pasta da solução para manter cada projeto do Visual Studio por tipo de artefato, como mapas, pipelines, orquestrações, esquemas internos, esquemas externos e qualquer componente do .NET que esteja sendo compilado. A propósito, independentemente de quantas vezes você já ouviu este conselho, não o encare como uma regra rígida. Se você souber que determinados artefatos provavelmente serão revisados em conjunto no futuro (como um mapa e seus esquemas), coloque-os no mesmo projeto para reduzir o número de componentes que terá de reimplantar. Durante o desenvolvimento, podemos compartilhar o mesmo arquivo de chave entre os projetos da solução e entre os desenvolvedores. (A criação de arquivos de chave seguros para a produção é um outro assunto.) Simplesmente verifique o arquivo de chave no controle de versão juntamente com os outros artefatos de sua solução. Agora, indique o caminho do arquivo de chave para cada assembly da solução. Para fazer isso em projetos do BizTalk, use "..\..\..\Key.snk",

Isso funciona porque o BizTalk cria os binários em uma subpasta com um nome semelhante a [SuaSolução]\[SeuProjeto]\bin\Desenvolvimento. Assim, três saltos do diretório pai leva o BizTalk de volta à pasta da solução com o arquivo de chave.

Observe que se você adicionar projetos da Biblioteca de Classes do .NET Framework à sua solução, eles serão compilados com uma estrutura de diretórios um pouco diferente dos projetos do BizTalk, e a interface do usuário do Visual Studio para definir o caminho do arquivo de chave não permitirá que você insira um caminho relativo. Uma solução é editar .csproj (no C#) ou .vbproj (no Visual Basic®) como um arquivo de texto. Pesquise o nome do arquivo de chave até o qual você navegou na interface do usuário de propriedades do projeto do Visual Studio e o substitua por um caminho relativo que sobe apenas um pai, como ..\Key.snk. Não esqueça de adicionar o assembly do .NET Framework ao GAC após cada compilação. Você pode fazê-lo automaticamente com uma etapa pós-compilação no Visual Studio. São necessários apenas caminhos completos e aspas ao redor das cadeias de caracteres com espaços, como o seguinte monstro (tudo em uma linha):






7. Nunca subestime o código de exemplo gratuito

Segue uma dica rápida que vale seu comprimento em ouro. O arquivo de ajuda do BizTalk documenta mais de 50 aplicativos e scripts de exemplo (instalados na pasta SDK\Samples) que você pode aprender, adaptar e reutilizar. Você também encontrará mais de 30 aplicativos úteis do BizTalk na página msdn2.microsoft.com/en-us/biztalk/aa937647.aspx. Finalmente, o Guia dos Bloggers para o BizTalk (disponível em GotDotNet.com) é um compêndio de mais de 400 artigos técnicos, incluindo vários trechos e exemplos de código úteis. Eu mantenho um atalho para o Guia dos Bloggers na minha área de trabalho; esse é um dos primeiros lugares que eu olho quando me aventuro em um território novo do BizTalk.

Certo, eu admito, se você já sabia disso, pode achar essa dica muito fraca. Mas, considerando que muitas vezes é difícil encontrar código de exemplo profissional do BizTalk, achamos que valeria a pena lembrar que esse depósito está sempre ao seu alcance. O mais importante é que esses exemplos não são úteis apenas quando você é um iniciante no BizTalk, essas referências são úteis sempre.

A propósito, não esqueça de verificar no MSDN o arquivo de ajuda do BizTalk que é atualizado periodicamente. Você pode baixá-lo em formato PDF ou .chm zipado, ou navegar até ele online.



8. Depurar o XSLT no Visual Studio

Talvez este seja o recurso menos conhecido do Visual Studio e ele não exige que o BizTalk seja instalado. O depurador do XSLT permite que você veja os resultados de uma transformação enquanto ela é executada, defina pontos de interrupção e examine as variáveis locais e a pilha de chamadas. É possível até mesmo percorrer o script XSLT no C# ou no Visual Basic.



Em seguida, inseri o arquivo XSLT que você vê no painel esquerdo da Figura 7. Ele criará um documento Hello World e, se o elemento do nó possuir um atributo igual a “debug”, ele o expulsará também.

Agora, com o cursor no arquivo XSLT (isso é importante), defina a propriedade Input para que seja igual ao caminho do arquivo de dados XML que vai ser transformado. Saiba que clicar com o botão direito do mouse no próprio nome do arquivo XSLT na janela do Solution Explorer exibirá um outro conjunto de propriedades, as propriedades de File, não as propriedades de Document. Isso deveria ser mais intuitivo, mas depois de aprender, é fácil. E se há uma coisa que separa os profissionais dos caras medianos, é o desejo de explorar. Você também pode definir a propriedade Output ou aproveitar o espetáculo enquanto acontece a transformação no painel central.

Quando o documento ativo no Visual Studio for um arquivo XSLT, o menu suspenso XML (na barra de menus principal) incluirá um comando Debug XSLT. Clique nele e você poderá acompanhar o código da transformação, passando até mesmo pelas sub-rotinas.