A Analogia do Carteiro

Durante as minhas aulas ou palestras sobre o produto uma das coisas que eu noto que mais geram dificuldades com os iniciantes, é a interpretação de quando utilizar Distinguished Fields e quando utilizar Properties.

Não pretendo detalhar mais sobre o funcionamento técnico destes recursos, pois apesar deles serem pouco detalhados na  documentação do produto, eles são um pouco melhor explicados no blog do Scott Woodgate e no blog do Abhilash. Se você fizer uma simples consulta no Google, poderá encontrar mais alguns bons textos sobre isso. Uma das minhas explicações prediletas sobre o funcionamento destes recursos está no blog do Hai Ning.

Como via de regra, os distinguished fields são utilizados dentro dos orchestrations, e as properties são utilizadas em operações de messaging, para roteamento de mensagens. Properties costumam ser mais restritivas quanto aos tipos de dados que podem ser utilizados, e elas também costumam gerar um custo maior que o dos distinguished fields. Não é tão complicado, mas costuma confundir muita gente no começo.

O que eu gostaria de compartilhar com vocês, é o uso de uma analogia extremamente simples que eu notei que tem ajudado bastante os meus alunos iniciantes a decidir quando utilizar um recurso e quando utilizar o outro: a analogia do carteiro.

Quando você envia uma carta para, digamos, a sua namorada, você escreve um texto em uma ou mais páginas (eu costumo escrever bastante, minha namorada já acostumou... rs) dobra as folhas e coloca em um envelope. A seguir, você fecha o envelope e escreve alguns dados que são as informações de remetente (opcional) e principalmente as informações de destinatário, tais como o nome, o endereço, o número e o CEP.

O texto que está dentro da carta é um texto que só diz respeito a você (que enviou a carta) e a sua namorada (que vai recebe-la). Ninguém mais precisa saber o que está escrito. O carteiro não precisa ler aquele conteúdo, pois todas as informações que ele precisa para a entrega da mensagem estão do lado de fora do envelope da carta.

E o que tudo isso tem a ver com o BizTalk?

Bem, seguindo a analogia, toda vez que você precisar promover algum campo, compare a leitura da carta pela sua namorada com uma mensagem processada pelo orquestation, e compare as informações que estão do lado de fora do envelope da carta com a engine de envio e recebimento de mensagens do BizTalk:

• Para tudo aquilo que for lido pelo destinatário, utilize distinguished fields.
• Para tudo aquilo que for lido pelo carteiro, utilize properties.

Ou simplificando mais ainda:

• Se você precisar da informação apenas do lado de dentro da carta, utilize distinguished fields.
• Se você precisar da informação do lado de fora da carta, utilize properties.

Vamos aos exemplos práticos:

1. Você precisa filtrar dados de envio em uma send port baseado em um determinado campo: Vamos dizer que este campo chama-se Apartamento, e identifica o número do apartamento onde a sua namorada mora. Seguindo a analogia, este exemplo seria o equivalente a você depositar a carta na caixa do correio próxima a sua casa. A caixa do correio seria a sua send port. Você apenas depositou a carta dentro da caixa, mas quem vai retirar a mensagem da caixa de correio e decidir para que setor ela deve ir é o carteiro. Se é o carteiro que vai ler este campo para saber como endereçar a mensagem, então este campo precisa estar do lado de fora da carta, e consequentemente deve ser uma property.
2. Você precisa filtrar os dados de recebimento em um receive shape baseado em um determinado campo: Este caso é ligeiramente diferente do primeiro caso, mas a analogia também é válida. Isto seria o equivalente ao carteiro entregar a carta na recepção do prédio do apartamento da sua namorada. Neste guichê tem uma série de caixinhas, cada uma delas com um espaço para depositar as cartas de cada apartamento. Se o campo Apartamento for igual a A, o carteiro vai deixar a carta na caixinha do apartamento 201. Se o campo Apartamento for igual a B, ele vai deixar na caixinha do apartamento 202. E posteriormente, a sua namorada vai passar pelo guichê de entrada e vai coletar toda a correspondência. O carteiro precisa da informação do setor para entregar a mensagem corretamente, então o campo Apartamento tem que ser colocado do lado de fora da carta! Se está do lado de fora da carta, então ele precisa ser uma property.
3. Você precisa fazer uma condição dentro do seu orchestration baseado em um determinado campo: Aplicando a analogia, isto seria o equivalente a você perguntar algo para a sua namorada. Você está pedindo ela em casamento, e baseado nisso vocês podem tomar atitudes diferentes (ficarem noivos ou se separarem, por exemplo). Note que neste caso, quem está lendo o pedido é a sua namorada, e não o carteiro. Ele não precisa saber o conteúdo da mensagem! Então nós estamos falando de um distinguished field.
4. Você precisa criar convoys: Os convoys são um recurso do BizTalk para trabalhar com mais de uma mensagem em uma única instância, ou seja, uma aplicação que possui mais de uma porta de recebimento de mensagens, que serão inter-relacionadas. Um caso típico de convoy é a entrada de um paciente em um hospital, onde a orquestration recebe a ficha de entrada do paciente, e depois recebe o histórico do paciente, e só depois de ter as duas informações é que o processo continua e o paciente pode ser operado. Trabalhando com a analogia do carteiro, vamos imaginar que o carteiro passe na casa da sua namorada apenas uma vez por semana. O carteiro recebe centenas de mensagens por dia, mas apenas algumas são destinadas a sua namorada. Você escreve para a sua namorada todos os dias. O carteiro então vai agrupar todas as cartas destinadas a sua namorada em um pacote, e entregar no final da semana. Mas com que critério ele faz isso? Ele precisa de um critério para o agrupamento. Este critério pode ser o endereço dela, ou pode ser algum outro campo. Este campo precisa necessariamente ser lido pelo carteiro para fazer o agrupamento. Se precisa ser lido pelo carteiro, tem que estar do lado de fora do envelope. Então é uma property.

Por último, entenda que a analogia do carteiro é apenas um facilitador para identificarmos os dois recursos, então por favor, não confunda esta analogia com o conceito de Envelopes do BizTalk. Isso é outra coisa, completamente diferente, que inclusive pode ser alvo de um artigo aqui neste espaço.