Este artigo foi traduzido por máquina.

Soluções EDI do BizTalk

Processando requerimentos de assistência médica com o BizTalk Server 2010

Mark Beckner

O BizTalk Server 2010 introduz uma plataforma totalmente refeita para gerenciar a troca de documentos EDI (Electronic Data Interchange) entre parceiros comerciais. Se você já trabalhou com edições anteriores da plataforma, você pode ter encontrado algumas dores de cabeça com a definição da troca de documentos entre diversas partes. Com a versão mais recente, você tem total controle sobre a organização e a definição das configurações de documentos relacionados a qualquer intercâmbio entre as partes.

O BizTalk Server 2010 também oferece uma experiência muito mais aprimorado durante o desenvolvimento de mapas.

Para ilustrar esses novos recursos, vou orientá-lo pelas etapas necessárias para a criação de uma solução EDI. Cada solution EDI desenvolvido em 2010 do BizTalk Server segue um padrão básico:

• Adicionando e modificando esquemas EDI base.
• Criação de mapeamentos entre o documento EDI e interno/externo de mensagens.
• Implementando as orquestrações para lidar com o fluxo de trabalho associado ao processamento de documentos EDI.
• Configurando definições de parceiro comercial, incluindo as partes, perfis de negócios, contratos e confirmações.
• Configurando as portas para permitir o recebimento ou a entrega de documentos, através de FTP, AS2 ou outro protocolo.

Para fins de ilustração, vamos examinar a troca de documentos entre um hospital e uma unidade de processamento. Os documentos trocados entre as partes serão Health Insurance Portability and Accountability Act (HIPAA)-compatível com 837 Professional e Institutional arquivos.

Trabalhando com esquemas

Na maioria das soluções EDI, você estará trabalhando com dois tipos básicos de esquema: esquemas EDI que representam arquivos simples trocados com parceiros comerciais e os esquemas internos que representam os tipos de documentos necessários para processar os dados dentro do documento EDI.

No meu exemplo, a solução troca 837 documentos com parceiros externos, mas usa um formato de documento diferentes para processamento interno. O esquema interno representa um arquivo de plano de ECSIF: um formato comum para os processadores de declarações. Os 837 esquemas que acompanham o BizTalk e podem ser adicionados a um projeto do Visual Studio, mas os esquemas internos (como um ECSIF) devem ser criados manualmente.

O BizTalk Server 2010 é fornecido com milhares de esquemas existentes que definem a maioria dos documentos EDI em uso atualmente. Para acessar os esquemas, execute o executável MicrosoftEdiXSDTemplates encontrado no diretório \Arquivos de Programas\Microsoft BizTalk Server 2010\XSD_Schema\EDI $. Para os fins deste exemplo, usarei o Professional 837 e Institutional esquemas em conformidade com HIPAA encontrados na pasta HIPAA\00501. Adicionar o arquivo XSD para um projeto do Visual Studio permite que ele seja referenciado e usado por outros componentes do BizTalk — mais importante, por mapas.

Figura 1 mostra o esquema de Professional 5010 837 dentro do Visual Studio 2010. Observe o número de nós neste esquema: a 837 é um dos documentos EDI mais complexos e podem ser extremamente complicado para se trabalhar. Ele contém centenas de nós que são praticamente idênticos, que representa as informações de assinante e pacientes.

Figura 1 O esquema Professional 5010 837

Figura 2 mostra o esquema interno que representa o formato ECSIF. Este esquema foi gerado usando o Assistente de esquema de arquivo simples. O assistente pode ser apontado para uma instância válida de arquivo simples para criar um XSD. Um número de campos no nó FileHeader foi promovido neste esquema. Os campos promovidos permitem para aprimorado de filtragem e opções de mapeamento.

Figura 2 O formato de esquema do destino ECSIF

Depois que os esquemas foram definidos e adicionados ao projeto do Visual Studio, você pode começar a construção fora os mapas. Nesse caso, observarei vários cenários que são úteis em um documento 837 de mapeamento.

O desenvolvimento de mapas

A interface de mapeamento do BizTalk Server 2010 foi extensivamente revisada e apresenta uma variedade de novos recursos. Esses recursos incluem automáticos, zoom nó correspondente e recursos de pesquisa. Um dos avanços mais perceptíveis é a capacidade de clicar em uma linha ou functoid e ter todos os outros mapeamentos desaparecer ao plano de fundo.

Como qualquer desenvolvedor de mapa EDI saberão, alguns mapas obtém extremamente complexos, com várias guias e dezenas (ou até mesmo centenas) de functoids. Descobrir quais dados do esquema de origem é mapeado para quais dados no esquema de destino e quais functoids estão sendo usados para fazer esse mapeamento podem ser difícil visualizar. Clicando em qualquer uma das linhas ou functoids usado, todos os mapeamentos relacionados serão realçados.

Um exemplo de um mapa complexo com um conjunto específico de mapeamento lógica realçada é mostrado na a Figura 3. Isso traz um desenvolvimento de mapa de ponto do BizTalk é geralmente ignorado: há momentos para usar a interface do mapa, e há momentos para não usá-lo. Nem todos os mapeamento realizado no BizTalk é mais adequado para o mapeamento padrão — às vezes, usam abordagens alternativas está em ordem. Alternativas incluem componentes de script e externos in-line, incluindo XSLT e Microsoft.NET Framework disponíveis.

Figura 3 destacar os recursos em mapas do BizTalk Server 2010

Desenvolvimento de mapa do BizTalk geralmente consiste em uma combinação de functoids padrão e in-line XSLT e TRANSLATION FROM VPE FOR CSHARP. Há momentos até mesmo shelling check-out para uma folha de estilos XSLT externa é em ordem (que ignora o BizTalk mapper totalmente). Mapas EDI podem ficar complicados e requerem criatividade e planejamento acabar com a solução necessária.

Para ilustrar o uso de inline TRANSLATION FROM VPE FOR CSHARP, vamos examinar uma função comum de mapear uma saída 837 arquivo Professional ou Institutional: o mapeamento dos segmentos de hierárquicos (HL). Os segmentos HL exigem valores incrementais para cada registro no arquivo e indicam relações pai/filho. Não há realmente nenhuma combinação de tradicional functoid permitirá que esses valores to ser configuradas corretamente. No entanto, há uma abordagem simples in-line TRANSLATION FROM VPE FOR CSHARP que permite que os valores corretos. Essa abordagem requer duas functoids de script: uma que armazena uma variável global e mapeia os HL01, enquanto o segundo mapeia HL02 (que depende do valor de HL01).

O script de functoid HL01 tem esta aparência:

intHL01 int;pública int getHL01() {intHL01 + +;retornar intHL01;}

Aqui está o código do script de HL02:

pública int getHL02() {retornar intHL01 -1;}

Figura 4 mostra os functoids colocados no mapa.

Figura 4 segmento da HL 837 saída de mapeamento

Outra situação geralmente surge em documentos EDI do mapeamento é a necessidade de usar in-line XSLT. Isso é uma das habilidades mais importantes para incorporar o mapeamento do BizTalk e é algo que você deve familiarizar com. Ele permite que muitas opções em torno da criação de um loop e o nó que simplesmente não estão disponíveis usando combinações de functoid padrão.

Uma ilustração do uso de XSLT embutido em um mapa é mostrada na a Figura 5. Esse código demonstra como usar a funcionalidade de modelo chamada de XSLT embutido para passar um parâmetro do documento de origem (nome) e criar um nó do documento de destino 837.

Figura 5 passando parâmetros para um XSLT in-line chamar o Script de modelo

Ao desenvolver um mapa do BizTalk, pense sempre a capacidade de manutenção a longo prazo do mapa. Isso é algo que você poderá atualizar facilmente? Isso é algo que outra pessoa pode trabalhar no futuro? Boa prática de codificação não deve ser esquecida ao trabalhar com mapas do BizTalk e alguma quantidade de planejamento e arquitetura deve ser envolvida no desenvolvimento de mapas que tenham muita lógica ou funcionalidades complexas dentro deles.

Orquestrações

O uso de orquestrações em soluções EDI não é um requisito. Em geral, documentos simplesmente precisam ser mapeados de um formato para outro e entregue, sem a necessidade para a inclusão de fluxo de trabalho.

Em alguns casos, no entanto, um documento talvez precise possui várias etapas de processamento feito a ele antes que ele esteja pronto para ser entregue. Para ilustrar isso, posso configurar uma orquestração mapa e arquivamento de mensagens a uma tabela no SQL Server. A orquestra será configurada com um filtro para garantir que somente os documentos de um determinado tipo são processados por ela.

A orquestração pode ser configurada para se inscrever em praticamente qualquer um dos campos dentro os segmentos ISA ou ST de um documento EDI (entre muitas outras propriedades). Para configurar uma orquestração para se inscrever em um campo específico em um documento, um filtro pode ser definido na forma recebimento inicial de coordenação, como mostrado na a Figura 6.

Figura 6 Definindo um filtro em uma orquestração

Com o filtro especificado, a orquestração agora pode fazer o processamento necessário do documento EDI. Nesse caso, a orquestração irá mapear os dados do formato 837 no formato ECSIF e, em seguida, gravar essas informações em uma tabela de arquivo no SQL Server. O mapeamento dos documentos é feito por meio de uma forma de transformação e a inclusão de um arquivo de mapa, mas a gravação das informações para o SQL Server possui um número de opções disponíveis para ele.

Ao pensar do SQL Server, muitos desenvolvedores BizTalk presumem que eles precisam usar um dos adaptadores disponíveis para gravar em SQL. A verdade é que, na maioria dos casos, os adaptadores SQL são excessivamente complexos para chamadas de banco de dados básica. Geralmente, a abordagem mais fácil e mais ter suporte para a interação com o SQL Server é através do uso de um personalizado.Classe NET assembly. Ao desenvolver classes que serão chamados de orquestração, certifique-se sempre e marca a classe como serializável para garantir que o BizTalk pode chamá-lo de qualquer tipo de estado de transação:

o namespace Demo.BizTalk.Helper {[Serializable] public class DataAccess {}}

O desenvolvimento de orquestrações para soluções EDI não é diferente para outros tipos de implementações do BizTalk. O principal a lembrar ao desenvolver orquestrações é to keep it simple. Há uma arte para desenvolvimento do BizTalk e organizar seus projetos do BizTalk corretamente. Se você tiver planejado e desenvolvido corretamente, você acabará com uma solução fácil de fazer as atualizações e implantar um ambiente de produção.

Configurações de parceiro comercial

O BizTalk Server 2010 introduz uma nova interface para gerenciar a troca de documentos EDI entre parceiros comerciais. Ela é composta de três níveis básicos de organização: a parte, o perfil de negócios e o contrato.

A parte representa a organização de nível superior do parceiro comercial. Configurações neste artefato referem-se a coisas que são comuns em todos os documentos que estão sendo trocados com este parceiro comercial. Por exemplo, os certificados que podem ser necessários para comunicação segura seriam configurados nesse nível.

No meu exemplo, eu tenho duas partes: o processador de declarações e o hospital. Cada um é definida como seu próprio parceiro exclusivo do BizTalk. Tudo o que precisa ser configurado é o nome, como mostrado na a Figura 7.

Figura 7 configuração de festa de nível superior

Uma festa terá um ou mais perfis de negócios associados a ele. O perfil de negócios representa um departamento em uma organização que tem sua própria identidade de negócios exclusivo ao enviar ou receber documentos EDI. Uma identidade de negócios é o valor que aparece no segmento de ISA06 ou ISA08 um documento EDI (dependendo se o documento está sendo enviado ou recebido) e identifica exclusivamente o parceiro comercial de todas as outras entidades. Muitas organizações terão um perfil único de negócios, mas alguns exigem vários perfis.

No meu exemplo, o processador de declarações tem dois perfis de negócios: processamento de solicitações que represente profissional e outra que representa institucional processamento de avisos de sinistro. O hospital também tem dois perfis de negócios: a ramificação nacional e internacional ramificação. Figura 8 mostra as partes com seus perfis de negócios.

Figura 8 perfis de negócios associados com as partes

Como o perfil de negócios representa uma identidade de negócios exclusivo dentro de uma festa, configurações nesse nível lidam com informações que é comuns em todos os documentos que serão trocados com essa identidade. Todas as configurações de entrada e saídas que são comuns em todos os tipos de documento que está sendo trocados serão configuradas: os protocolos usados (X12, EDIFACT, AS2), as configurações de validação, os conjuntos de transação (documentos EDI são permitidos nesse nível), reconhecimentos e algumas das configurações de envelope são todos configuradas em um perfil de negócios. Em muitos casos, as informações padrão podem ser usadas nesse nível, porque a configuração dos contratos específicos de um perfil de negócios definirá essas informações e muito mais.

Um perfil de negócios pode ter um ou mais contratos. Um contrato representa a maneira que as duas partes estão esperando trocar um ou mais tipos de documento com outro. Isso é onde os detalhes específicos sobre o envelope, as confirmações e os conjuntos de transação permitidos são definidos. Pode permitir a um contrato para certos documentos sejam trocados confirmações 997 configurado, enquanto outro contrato pode permitir a outros tipos de documento a deixarem os Agradecimentos.

No meu exemplo, o processador de declarações e o hospital exchanging documents. O hospital enviará a declaração (X 12 837 institucional versão 5010) para o processador de declarações e o processador de declarações enviará uma confirmação (X 12 997) para o hospital. Figura 9 mostra a configuração do identificador de envelope e a Figura 10 mostra a transação de definir a configuração no contrato de documentos de fluxo a partir do hospital para o processador de declarações. Observe as guias na parte superior da janela que indica o fluxo do documento.

Figura 9 Definindo as configurações de Envelope ISA em um contrato

Figura 10 Configurar conjuntos de transação em um contrato

Figura 11 mostra a configuração de confirmações enviadas volta do processador declarações para o hospital.

Figura 11 as confirmações de Configurando um contrato

Se a troca de documentos com mais de um único parceiro comercial, você deverá notar que a maioria das suas configurações são praticamente idênticos — a única coisa alterando serão os identificadores no segmento ISA do envelope.

Para facilitar o desenvolvimento, certifique-se de usar a funcionalidade de modelo disponível na tela de configuração do contrato. Há dois botões que você esteja interessado: Salvar como modelo e carregar do modelo. Quando você tiver um parceiro comercial totalmente configurado e os documentos EDI estão fluindo de ponta a ponta com as configurações de envelope correto e confirmações, basta salvar as configurações de contrato como um modelo e usá-los como ponto de partida para futuros contratos.

Entrega de documentos e configurações de porta

A entrega real de documentos para ou do BizTalk para parceiros comerciais externos é feita por meio da configuração de portas. A porta define o tipo de mecanismo de entrega (FTP, arquivo e assim por diante) e contém o pipeline do BizTalk que transforma o documento XML no BizTalk em documento EDI flat file esperado pelos parceiros comerciais. O pipeline contém a lógica para interpretar o envelope EDI em um documento (ou crie uma) e para determinar qual o documento de terceiros resolve.

Para entender como portas processam documentos EDI, vejamos uma confirmação de envio. Como vimos anteriormente, as confirmações são configuradas nos contratos de terceiros BizTalk. Quando um documento chega, o BizTalk pode gerar automaticamente uma confirmação de 997. O que acontece é que o BizTalk cria o XML 997 e descarta-lo na caixa de mensagem do BizTalk, mas ele realmente não rotear a mensagem em qualquer lugar. Uma porta de envio deve ser instalado e configurada para converter o XML em um arquivo simples, adicionar o envelope e entregá-lo para o destino apropriado.

Como configurar a porta de envio para fornecer uma confirmação requer três etapas básicas:

1. A definição do protocolo de entrega e de porta de envio
2. A inclusão do pipeline de EdiSend (ou pipeline personalizados com componentes de pipeline EDI)
3. A configuração de filtros para ouvir Agradecimentos apropriados

É simples de configurar a porta de envio para enviar documentos para um local específico. Figura 12 mostra uma porta de envio configurado com o pipeline de EdiSend. A porta de envio gravará arquivos para um diretório de arquivos com o envelope cheio de EDI e formatação no lugar.

Figura 12 o Pipeline de configuração e informações de entrega em uma porta

Também é fácil fazer a configuração do filtro na porta de envio. Ele requer simplesmente especificando que ele só deve pegar confirmações geradas pelo sistema para este parceiro comercial (em oposição a entrada 997s do parceiro). Figura 13 mostra um conjunto totalmente configurado de filtros.

Figura 13 filtragem em uma porta de envio

Problema solucionado

A nova funcionalidade EDI no BizTalk Server 2010 está concentrada principalmente no gerenciamento de parceiros comerciais. As relações hierárquicas e organizações que eram impossíveis com edições anteriores da plataforma agora podem ser modeladas com relativa facilidade. Além disso, a interface de mapa foi aprimorada, e a experiência do desenvolvedor com o mapeamento será bem melhor. Com várias melhorias e maior funcionalidade, qualquer solução EDI pode ser modelada e desenvolvidos usando o BizTalk Server 2010 com êxito.

Mark Beckner é o fundador da Inotek Consulting Group LLC. Ele trabalha em conjunto Microsoft, incluindo o BizTalk, SharePoint, Dynamics CRM e geral.NET development. Ele pode ser contatado em mbeckner@inotekgroup.com.