Por que escolher Biztalk?

Vai implantar SOA na sua empresa e precisa de uma ferramenta ESB? Precisa integrar dois sistemas com protocolos diferentes, no estilo B2B? Ou quer integrar seus aplicativos que estão no AppFabric Azure com aqueles on-Premise? O Biztalk 2010 pode ser a ferramenta perfeita pra vc!

Esse post é dirigido aqueles leitores que querem saber o que é o Biztalk e pra que serve.

Leia mais »»

Tendência Mercado Biztalk no Brasil

Quando eu fui nomeada MVP de Biztalk, achei o máximo, uma grande honra, pois além de ser a primeira mulher brasileira a ser nomeada MVP, sou a única MVP do produto na América Latina!

Mas depois da minha nomeação, senti um certo desprezo pelo produto por parte de pessoas que trabalham em TI. Quem não conhecia o Biztalk, perguntava se era da Nestle, e quem conhecia, torcia a cara: MVP de Biztalk? ugh! Biztalk? Mas Biztalk vai morrer… Estuda notepad, paint..

Leia mais »»

Lançamento da Revista Digital "Codificando .Net e-Magazine"

Para inaugurar minha participação no blog gostaria de fazer uma recomendação a todos. Numa iniciativa inovadora a comunidade Codificando .NET lança hoje (01/06) a revista digital Codificando e-Magazine.

Será em formato pdf, gratuita e com muita informação interessante para o pessoal de desenvolvimento de softwares em geral.

O download pode ser feito em http://www.codificandomagazine.net/

Nela você encontrará, entre tantas coisas interessantes, uma coluna sobre BizTalk Server, intitulada BizTalk.ing, que é assinada por mim.

Nessa primeira coluna a abordagem é dirigida ao pessoal que já ouviu falar em BizTalk, mas ainda não sabe o que vem a ser. Imagino que esse seja o caso de um numero bem grande de desenvolvedores e entusiastas de tecnologia Microsoft.

Eis um trecho da coluna desse mês:

“A idéia da Microsoft (já no lançamento da primeira versão do produto em 2000) era aproveitar todos os padrões criados pelo mercado numa única ferramenta. O objetivo dessa ferramenta é resolver problemas de integração de aplicações de forma mais simples e fácil. Resumidamente falando, o BizTalk é colocado entre as aplicações A e B possibilitando a “conversa” entre essas aplicações. Isso pode ser feito apenas com a troca de mensagens entre as aplicações (messaging), ou implementando regras de negócio (orquestrações). Tudo isso de forma transacional, com registros de logs e capacidade de agregar inteligência ao ambiente, fazendo a análise dos dados que trafegam pelo BizTalk e disponibilizando uma base de BI para consultas gerenciais dos processos e geração de “relatórios analíticos”.”

Acho que vocês puderam notar por esse trecho que o texto é bem “básico” e que tentei ser o mais “didático” possível. A idéia é que nos próximos meses possamos discutir, de forma mais aprofundada, não apenas o produto BizTalk, mas sim os vários aspectos da integração de aplicações.

Espero que o pessoal encha minha caixa postal com dúvidas. Tentarei responder todas as duvidas e as mais “bacanas” virarão post aqui do blog.

Nos vemos em breve!!!

Leia mais »»

Lenda do Biztalk 2: "vou utilizar Biztalk e reduzir o prazo do meu projeto"

Esta lenda é muito perigosa e terrivelmente comum nos projetos de Biztalk. 

Devido a falta de conhecimento sobre o produto ou uma venda mal conduzida, o cliente muitas vezes fica com a impressão que pode resolver uma data de entrega não realista com um simples "vamos por o Biztalk aí", com aquela velha mentalidade de tentar achar uma solução simples para um problema complexo.

A verdade, nos projetos em que estive envolvido, o que acontece é que alguns grandes riscos de projetos tradicionais como, por exemplo, mudar uma lógica de transformação ou trocar um sistema envolvido em uma operação, são trocados, nos projetos de Biztalk, por outros riscos como desafio de customizar a ferramenta para acessar um tipo proprietário de arquivo.

Ou seja, os riscos que teimam em tentar fazer os projetos atrasarem ainda estão lá, apenas são desafios diferentes que os de projetos normais.

A grande vacina contra esse pensamento costuma ser a realização de pequenas provas de conceito (POCs). As POCs são mini-projetos de duas semanas a um mês cujo produto é uma demonstração de que a ferramenta pode ser utilizada para a finalidade que se deseja.

Esse é um modelo muito comum e encorajado pela Microsoft, que muitas vezes disponibiliza recursos de um parceiro como a ITGROUP para fornecer mentoring na realização destes pequenos projetos.

De qualquer maneira você pode baixar aqui uma cópia trial de 120 dias para fazer quaisquer testes necessários.

Leia mais »»

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á.

Leia mais »»

O BizTalk e a concorrência...

Pra inaugurar o blog, vamos lá! ;-)

Uma das coisas que a gente vai aprendendo com os anos de experiência é que não existem ferramentas perfeitas - se a ferramenta atende melhor uma determinada necessidade, ela atende pior (ou deixa de atender) um outro tipo de necessidade. Se ela é amigável demais, ela costuma ter menos recursos, e se ela tem recursos demais, ela tende a ser uma ferramenta complexa.

Uma boa ferramenta acaba sendo aquela que atinge um ponto de equilíbrio entre atender uma grande parte de necessidades sem se tornar complexa demais, ou então que seja simples e que permita extensões e customizações.

Com o BizTalk não é diferente. Nos vários projetos que eu encarei nos últimos anos, deparei-me com algumas situações em que a ferramenta parecia não atender a alguma necessidade com a mesma eficiência que as ferramentas concorrentes, e muitas vezes isso nos pega desprevenidos, pois nem sempre conhecemos os pontos fortes e fracos dos concorrentes . Com base nisso, selecionei uma coletânea de artigos da Microsoft que traçam um paralelo entre o BizTalk e os concorrentes para inaugurar este blog.

Não, não se trata de uma cartilha que nos ensina a ressaltar as virtudes e esconder os defeitos do produto! Na verdade, estes artigos da Microsoft procuram ser bem honestos, e compartilham desta minha visão de que não existem ferramentas perfeitas. O que eles procuram fazer, é justamente nos mostrar os pontos fortes e fracos de cada tecnologia, para que possamos nos preparar melhor para as dificuldades, e tirar proveito dos pontos fortes do produto.

Então vamos lá:

• Ascential (Mercator) vs. BizTalk Server 2004 Discussion
• BEA WebLogic vs. BizTalk Server 2004 Discussion Guide
• IBM Websphere Business Integration vs. BizTalk Server 2004 Discussion Guide
• IBM WebSphere Integration Message Broker vs. BizTalk Server 2004 Discussion Guide
• Oracle BPEL Process Manager vs. Biztalk Server 2004 Discussion Guide
• SeeBeyond vs. BizTalk Server 2004 Discussion Guide
• Tibco vs. BizTalk Server 2004 Discussion Guide
• webMethods vs. BizTalk Server 2004 Discussion Guide

Leia mais »»