Lenda do Biztalk 1: "não preciso desenvolver nenhuma linha de código"

Parodiando o Carlos, vou inaugurar a minha participação no blog. São várias as lendas que cercam o desenvolvimento de soluções com o Biztalk e nessa série de posts vou tentar acabar com algumas...

Se você fez algum hands on lab do Biztalk 2006 (ou conversou com algum marketeiro) você vai ter a impressão que nenhum código é necessário para desenvolver soluções.

É importante saber que, ainda que essa afirmação seja verdadeira para projetos pequenos e simples, em todos os projetos reais nos quais eu participei desde a versão 2000 do produto, algum código customizado teve de ser criado.

Isso não é uma noticia ruim, é uma decisão de design da equipe de produto que traz uma flexibilidade que muitos produtos não têm. Enfim, vamos as situações nas quais você precisa abrir o seu Visual Studio e escrever um pouco de C# ou VB.NET.

• Workflow: Por mais simples que seja sua orchestration, é quase certo que você precisará de expressões para manipular as suas mensagens. Quase todos os shapes requerem expressões para funcionarem:
• Decide e Loop: O condicional que determina a operação lógica; 
• Receive: A propriedade Filter Expression que determina que mensagens interessam para a orchestration;
• Listen e Delay: O objeto System.DateTime ou System.TimeSpan que indicam o tempo para aguardar;
• Message Assignment: Uma expressão para criar uma nova mensagem;
• Expression: Qualquer expressão para manipular dados de mensagens ou chamar componentes .NET
• Lógica de Transformação: O Biztalk possui diversos componentes que ajudam na transformação de mensagens, os functoids utilizados nos maps.

Ainda assim, quando o seu projeto passa a ter um número considerável de processos de negócio, é muito provável que existam alguns padrões que sempre se repetem (a formatação de um código de determinado sistema, por exemplo) e que exigirão sempre o mesmo esquema de encadeamento dos functoids básicos (string concatenate + string right + uppercase, por exemplo). 

E para evitar reescrever esse tipo de combinação 100 vezes passa a ser muito mais produtivo criar um functoid que realize essa operação.

Esse tipo de componente deixa o map muito mais legível, além de melhorar o desempenho do map quando ele é muito complexo ou possui schemas muito grandes. E é claro alcançar uma reutilização e produtividade muito maior.

• Lógica de negócio: Nesta categoria entram todos aqueles artefatos que sejam externos ao Biztalk e que precisariam ser desenvolvidos independente da plataforma (como componentes de validação de CPF/CNPJ, componentes de cálculo, etc) e muitas vezes são adaptados de soluções prontas como frameworks corporativos, por exemplo. 
• As regras de negócio também podem estar contidades em componentes utilizados como fatos pelo Business Rules Engine (BRE). Mas também os componentes Fact Retriver e Fact Creator que são responsáveis por criar a sua própria lógica para recuperar fatos do BRE (controlar qual a origem dos fatos ou quando os fatos são atualizados, por exemplo) e criar o seu tipo de fato customizado (e contonar a pequena oferta de tipos de fatos: XML, .NET Assembly ou tabelas, e somente tabelas, no SQL Server).

• Lógica de Processamento de Mensagem: A não ser que pela sua solução apenas trafeguem arquivos texto e XML, provavelmente será necessário criar um componente de pipeline customizado, que realize pré-processamento ou pós-processamente nas mensagens para que o Biztalk seja capaz de trabalhar com elas.
• Se você se pergunta que processamentos seriam estes existem vários exemplos: execução de compactação/descompactação, algoritmos de criptografia ou assinatura digital, tipos de arquivos binários (que precisam receber algum tipo de representação em XML equivalente), etc.
• Todas essas tarefas podem ser realizadas pelo Biztalk com todas as suas vantagens (alta disponibilidade, monitoração, integração com diversas plataformas e aplicações, etc), mas para isso um pouco de código .NET precisa ser escrito.

• Adapters Customizados: Finalmente, se nenhum dos cerca de 300 adapters que existem (entre os disponíveis pela Microsoft ou parceiros) é possível que você precise desenvolver um adapter customizado.
• O desenvolvimento de um adapter customizado é o panteão dos desenvolvedores que utilizam Biztalk,  a expressão máxima de habilidade e complexidade. Mas eu tenho que dizer que não é nada comum desenvolver esse tipo de componente.
• Nos clientes o que geralmente acontece é que o custo de disponibilizar os dados dos sistemas legados em um formato compatível com os adaptadores incluídos no pacote do Biztalk é menor que o de desenvolver um adapter customizado.
• Somente requisitos e pré condições muito específicas de um projeto podem indicar a necessidade de se construir um componente desse tipo.

No próximo post falarei sobre a lenda 2 do desenvolvimento de Biztalk: "vou utilizar Biztalk para reduzir o meu tempo de implementação do projeto". E a lenda 3: "não vou utilizar Biztalk porque custa muito caro". Até lá.