Flat Files Hierárquicos

Me deparei com esta situação em um projeto há uns seis meses atrás... e na época não encontrei nenhum artigo ou dica de como fazer isso. Fui tentando achar a forma certa de fazer, e o resultado saiu bom, então resolvi compartilhar a dica aqui neste espaço.

É fácil criar schemas de flat files posicionais que possuam múltiplos tipos de registros. Para isso, basta configurar a propriedade Tag Identifier e Tag Offset para cada um dos tipos de registro esperados, de forma que o pipeline do BizTalk tenha como identificar cada registro. Se utilizarmos o Flat File Wizard, basta que informemos a propriedade Tag no momento da especificação do leiaute do registro, conforme a figura abaixo:

Desta forma, o para o seguinte arquivo:

HEADXXXXXXXXXXXXXXXXXXXX
BOD1XXXXXXXXXXXXXXXXXXXX
BOD1XXXXXXXXXXXXXXXXXXXX
BOD1XXXXXXXXXXXXXXXXXXXX
FOOTXXXXXXXXXXXXXXXXXXXX

...ficaria com um schema parecido com o da figura abaixo:



...ou traduzindo para um pseudo-schema resumido, ficaria assim:

(Registro posicional, com tag=HEAD)
(Elemento da tag)
(Restante do registro)
(Registro posicional, com tag=BOD1, minOccurs="0", maxOccurs="unbounded")
(Elemento da tag)
(Restante do registro)

(Registro posicional, com tag=FOOT)
(Elemento da tag)
(Restante do registro)

Até aqui nenhuma novidade. O problema começa quando passamos a ter mais de uma seção Body no arquivo flat. Algo mais ou menos assim:

HEADXXXXXXXXXXXXXXXXXXXX
BOD1XXXXXXXXXXXXXXXXXXXX
BOD2XXXXXXXXXXXXXXXXXXXX
BOD2XXXXXXXXXXXXXXXXXXXX
BOD2XXXXXXXXXXXXXXXXXXXX
BOD1XXXXXXXXXXXXXXXXXXXX
BOD2XXXXXXXXXXXXXXXXXXXX
BOD2XXXXXXXXXXXXXXXXXXXX
BOD2XXXXXXXXXXXXXXXXXXXX
FOOTXXXXXXXXXXXXXXXXXXXX

A idéia deste flat file é que existam vários registros do tipo BOD2 para cada um dos vários registros do tipo BOD1. Neste caso, precisaríamos definir um novo tipo de registro no Flat File Wizard, chamado BOD2, que a exemplo do BOD1, também seria configurado para múltiplas ocorrências. O problema é que o pipeline do BizTalk não entende desta forma. Ele vai entender que existem vários registros BOD1 e BOD2 no arquivo, mas que estes registros estão independentes! A ilustração abaixo mostra o squema gerado, e o squema desejado:

Nosso desafio aqui é fazer um flat file hierárquico. Fazer com que o elemento Body2 esteja dentro do elemento Body1. Mas se simplesmente colocarmos o grupo Body2 dentro do grupo Body1, teremos um outro problema: a tag identificadora de registro do Body2 não seria reconhecida pelo parser do pipeline, pois o registro Body2 foi rebaixado a categoria de sub-registro do elemento Body. Como podemos fazer então?

A solução é um pouco esquisita, mas bastante simples. Criamos um elemento um nível acima de Body1, chamado Conjunto1, do tipo delimitado, com o delimitador 0x0D 0x0A (CRLF), com o tag BOD1 e as propriedades minOccurs=0 e maxOccurs="unbounded", enquanto que o elemento Body1 deixa de ter a tag BOD1 que foi colocada anteriormente e também deixa de ter as propriedades minOccurs e maxOccurs.

(Registro posicional, com tag=HEAD)
(Elemento da tag)
(Restante do registro)
(Registro delimitado, com tag=BOD1, minOccurs="0", maxOccurs="unbounded")
(Elemento da tag)
(Restante do registro)
(Registro posicional)
(Restante do registro)
(Registro posicional, com tag=BOD2, minOccurs="0", maxOccurs="unbounded")
(Elemento da tag)
(Restante do registro)

(Registro posicional, com tag=FOOT)
(Elemento da tag)
(Restante do registro)

O schema final vai ficar assim:

Parece complicado, mas é bastante simples. E funciona muito bem!

Como último lembrete, não se esqueça de mudar a propriedade Parser Optimization de "Speed" para "Complexity", para que o parser faça a interpretação correta dos campos opcionais.