Lenda do Biztalk 1: "não preciso desenvolver nenhuma linha de código" | BizTalk Brasil
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á.