Använda kartor och anpassade koder för ACK ACK-meddelanden i HL7 för BizTalk Server 2013 R2

För nummer 1

Den här nya funktionen gäller endast ta emot Port eller plats. För närvarande kan få alla BizTalk port har en egenskap för Inkommande mappningar . När snabbkorrigeringen har installerats, finns det ytterligare en egenskap i ta emot-plats att använda en mappning för en HL7 ACK. Egenskapen ytterligare kan du använda en karta till ett dubbelriktat får plats med Använd direkt synkron HL7 ACK inställt på (=) Sant. Det enda syftet med den här snabbkorrigeringen är att ge användaren möjlighet att ange en mappning för en bekräftelse när Använd direkt synkron HL7 ACK (=) Sant.

När du har installerat snabbkorrigeringen visas ytterligare två egenskaper i MLLP får plats konfigurationsfönstret. Standardinställningen för de två egenskaperna är tomt och måste fyllas och Använd direkt synkron HL7 ACK (=) Truemåste anges.



Så här anger du två egenskaper:

1. Sammansättningsnamnet för OutboundMap -egenskapen kräver det fullständiga namnet på sammansättningen som utgående kartan finns, som i följande exempel:
   
   

   Utgående, Version = 1.0.0.0, Culture = neutral, PublicKeyToken = 83f92b3673c9005dSammansättningen måste tidigare cachelagrad av den globala sammansättningscachen. Annars misslyckas omvandlingen.

2. Egenskapen Name för OutboundMap kräver det fullständiga namnet på kartan bland annat namnområde.

En brist i denna nya funktion: HL7 ACK spåras inte. Om du måste spåra ACK, måste du också ange Inkommande mappningar egenskap i rapporten BizTalk ta emot port. Tekniskt, du vill använda kartan ACK som fördes i meddelanderutan och ACK som returnerades till det överordnade systemet. Båda ska vara identiska eftersom båda har samma karta används. Följande skärmdump ingår förtydligas och krävs endast om ACK måste följas.



Obs! Alternativet Använd direkt synkron HL7 ACK förbättrar prestanda för bearbetning av inkommande meddelande. Detta görs genom att skicka ACK tillbaka till det överordnade systemet så snart meddelandet deponeras i meddelanderutan. Den här inställningen förbättrar prestanda om följande villkor är uppfyllda:

• Ta emot porten är en tvåvägs ta emot-port och alternativet Använd direkt synkron HL7 ACK anges till True i portkonfiguration visas MLLP.

• BizTalk HL7 DASM används för att generera ACK. DASM-komponenten måste användas antingen som ingår i standard BTAHL72XReceivePipeline eller med hjälp av den inbyggda BTAHL7. HL72fDasm komponent i en anpassad rörledning.

• Väg ACK skicka rörledningen på begäran-svar ta emot port partens källa måste vara i Explorer HL7 konfiguration och Bekräftelse typ måste anges till ett annat värde än Ingen.

För nummer 2

Den nya funktionen gäller skicka portar endast. När du har installerat snabbkorrigeringen kommer problemet att baseras på godtagbara ACK-kod som du väljer i listan i stället för koden som tillhandahålls av nedströms system.

Skicka MLLP port kontrollerar ACK-koden i ACK (MSA segment MSA.1_AcknowledgmentCode fält) som returneras av nedströms systemet och jämför den med acceptabel ACK-koder som har angetts i MLLP skicka port konfigurationsegenskaper. Aktuella godtagbara ACK-koder som stöds av MLLP skicka port är AA, CA, AE, CE, P.A. och CR. Du kan välja alla ACK koderna eller en kombination av dessa (AA och CA) (AA, CA, AE och CE) (AA, CA, P.A. och CR) giltigt. Men det finns inget alternativ för att ange en godtagbar ACK kod kombination.

Ytterligare godtagbara ACK koderna värde som heter "Anpassad" läggs till i listrutan i egenskapen Godtagbara ACK koderna . Alla tidigare kombinationer finns kvar och används som före den nya funktionen har lagts till.





När anpassad väljs måste du också ange nya värden i egenskapen Godtagbara egna ACK koderna . Dessa nya ACK-värden måste vara avgränsade med kommatecken (,).

När du har installerat snabbkorrigeringen beror problemet på inställningen Godtagbara ACK koderna som väljs. Om ACK-koden som returneras matchar den valda acceptabla koden, sker bearbetning korrekt. Den igen för standard ACK koderna och uppehåll för ACK-kod som inte finns (som blir det en icke-standard eller en icke-anpassad ACK-kod).

I följande tabell representerar det här scenariot. En skriftlig tolkning följer efter tabellen.



För AA och CA lyckas meddelandet bearbetas alltid oavsett alla godtagbara ACK koderna inställning som väljs. Här följer mer information om inställningar för Godtagbara ACK-koder :

• AA, CA: Försök AE, CE, P.A., CR och förhindrar att andra.

• AA, CA, AE, CE: Accepterat och framgångsrik: AA, CA, AE, CE och försök P.A. och krediterat skjuter upp något annat.

• AR, AA, CA CR: Accepterat och framgångsrik: AA, CA, P.A., CR och försök AE och CE. Gör uppehåll i något annat.

• AA, CA, P.A., CR, AE, CE: Accepterat och framgångsrik: AA, CA, P.A., CR, AE, CE och några andra returneras. ACK igen och uppehåll i meddelandet.

• Anpassad (värden anges och avgränsade med kommatecken). Exempel: AA, AE, Foo, ZZ, ZZZ). Accepterad och framgångsrik: AA, CA, AE plus andra angivna anpassade ACK Foo, ZZ och ZZZ i det här fallet. Försök CE, P.A.

• ACK-kod som har angetts i Godtagbara egna ACK koderna gjorts inte och upphävs.

När en standard ACK inte har angivits under Godtagbara ACK kodernareturneras ett fel av följande slag:

Out-of-the-box ACK schemat måste ändras genom att lägga till den befintliga listan över standard Ack (AA, AE, P.A., CA, CE, CR). Eventuella ytterligare godtagbara anpassade Ack (XX, ZZ, till exempel) måste du lägga till fältet MSA.1_AcknowledgementCode ACK-schemat. Om ytterligare anpassade Ack inte läggs till i schemat, misslyckas pipeline-valideringen med felet "tabellvärde hittades inte".