Como aplicar mapas e códigos de confirmação personalizados para mensagens de confirmação no HL7 do BizTalk Server 2013 R2

Para o problema 1

Esta nova funcionalidade aplica-se apenas a porta de recepção/localização. Actualmente, qualquer BizTalk receber porta tem uma propriedade de Mapas de entrada . Depois de instalada esta correcção, não existe uma propriedade adicional disponível na localização de recepção para aplicar um mapa para uma confirmação de HL7 Esta propriedade adicional permite-lhe aplicar um mapa para receber nos dois sentidos localização que tem o conjunto de Utilização directa síncrono HL7 ACK (=), Verdadeiro. A única finalidade desta correcção deve permitir que o utilizador especificar um mapa de uma confirmação quando Utilização directa síncrono HL7 ACK está definida como (=), Verdadeiro.

Depois de instalar a correcção, verá duas propriedades adicionais na MLLP janela de configuração de localização de recepção. A predefinição para as duas propriedades estiver em branco e tem de ser preenchidos e Utilização directa síncrono HL7 ACK tem de ser definida (=), Verdadeiro.



Para definir as duas propriedades, siga estes passos:

1. Propriedade de Nome de assemblagem OutboundMap requer o nome completo da assemblagem em que o mapa de saída estiver alojado, conforme o exemplo seguinte:
   
   

   Saída, versão = 1.0.0.0, idioma = neutro, PublicKeyToken = 83f92b3673c9005dA assemblagem deve ser previamente colocadas em cache pela Assemblagem Global. Caso contrário, a transformação falhará.

2. Propriedade de Nome de OutboundMap requer o nome completo do mapa, incluindo o espaço de nomes.

Uma lacuna desta nova funcionalidade: a confirmação de HL7 não é monitorizada. Se deve controlar a confirmação, também tem de definir os Mapas de entrada de porta de recepção de propriedade no BizTalk. Tecnicamente, que aplicar o mapa Confirmação de que foi colocada na caixa de mensagem e a confirmação de que foi devolvida para o sistema de montante. Ambos devem ser idênticos porque ambos têm o mesmo mapa aplicado. A seguinte captura de ecrã é fornecida de clarificação e só é necessária se a confirmação deve ser monitorizada.



Nota A opção de Utilização directa síncrono HL7 ACK melhora o desempenho do processamento de mensagens de entrada. Isto é feito através do envio da confirmação novamente para o sistema de montante, logo que a mensagem é depositada à caixa de mensagem. Esta definição aumenta o desempenho, caso se verifiquem as seguintes condições:

• A porta de recepção é uma porta bidireccional receber e a opção de Utilização directa síncrono HL7 ACK está definida como True na configuração de porta de MLLP receber.

• BizTalk HL7 DASM é utilizado para gerar a confirmação O componente DASM deve ser utilizado como o incluído no predefinido BTAHL72XReceivePipeline ou utilizando o BTAHL7 nativo. Componente HL72fDasm uma tubagem personalizado.

• A definição de porta de receber confirmação da rota a tubagem de envio no pedido-resposta da parte de origem tem de ser o Explorador de configuração de HL7 e o Tipo de aviso tem de ser definido para um valor diferente de nenhum.

Para o problema 2

A nova funcionalidade aplica-se para enviar apenas a portas. Depois de instalar a correcção, o comportamento irá basear-se o código de confirmação aceitáveis que seleccionou na lista pendente em vez do código que é fornecida pelo sistema a jusante.

Enviar MLLP porta verifica o código de confirmação ACK (campo de MSA.1_AcknowledgmentCode de segmento MSA) que é devolvido pelo sistema a jusante e compara-os códigos de confirmação aceitáveis são definidos no MLLP enviar propriedades de configuração da porta. Códigos actuais de ACK aceitáveis que são suportados por porta MLLP enviar incluem AA, CA, AE, CE, para análise e CR. Pode seleccionar todos os códigos de confirmação ou uma combinação dos mesmos (AA e AC), (AA, CA, AE e "CE"), (AA AC, mapas e CR) como válido. Mas não existe nenhuma opção para introduzir uma combinação de código de confirmação aceitável.

Mais valor aceitável ACK códigos denominado "Custom" é adicionado na lista pendente na propriedade Aceitável códigos de confirmação . Todas as combinações anteriores permanecem e são aplicadas como estavam antes da nova funcionalidade foi adicionada.





Depois de PERSONALIZADO está seleccionado, tem de introduzir os novos valores na propriedade Aceitável códigos de confirmação personalizada . Estes novos valores de confirmação devem ser separados por uma vírgula (,).

Depois de instalar a correcção, o comportamento será dependem da definição de Códigos de confirmação aceitáveis que está seleccionada. Se o código de confirmação devolvido corresponder o código de aceitável de seleccionado, o processamento ocorre com êxito. Será novamente para códigos de confirmação padrão e suspender para qualquer código de confirmação não listou (que fará com que um padrão ou um código de confirmação não personalizado).

A tabela que se segue representa este cenário. A tabela a seguir uma interpretação por escrito.



AA e AC, de processamento de mensagens sempre sucede independentemente de quaisquer aceitáveis ACK códigos de definição que está seleccionada. Segue-se mais informações sobre definições de Códigos de confirmação aceitável :

• AA, CA: Tentativas AE, CE, AR, CR e suspende a qualquer outro.

• AA, CA, AE, CE: Aceite e êxito: AA, CA, AE, "CE" e repetições para análise e crédito suspende a qualquer outro.

• AA, AC, AR, CR: Aceite e êxito: AA, AC, AR, CR e tentativas AE e "CE". Suspende a qualquer outro.

• AA, AC, AR, CR, AE, CE: Aceite e bem sucedida: AA, AC, AR, CR, AE, CE e não outros é devolvido. ACK é repetida e suspenso de mensagem.

• Personalizada (valores são introduzidos e separados por uma vírgula). Exemplo: AA, AE, Foo, ZZ, ZZZ). Aceite e bem sucedida: AA, CA, AE além de quaisquer outros introduzido ACK personalizado como Foo, ZZ e ZZZ, neste caso. Tentativas de "CE", AR.

• Qualquer código de confirmação não for especificado no Aceitável códigos de confirmação personalizada não é repetido e é suspensa.

Quando uma confirmação padrão não for introduzida em Códigos de confirmação aceitável, é devolvido um erro semelhante à seguinte:

O esquema ACK out of box tem de ser modificado através da adição à lista existente de ACKs padrão (AA, AE, AR, CA, CE, CR). Qualquer ACK personalizado aceitável adicional (XX, ZZ, por exemplo) têm de ser adicionado ao campo MSA.1_AcknowledgementCode do esquema de confirmação. Se o ACK personalizada adicional não é adicionada ao esquema, a validação de pipeline falhar com um erro de "Valor da tabela não encontrado".