Slik bruker du kart og egendefinerte ACK-koder på ACK-meldinger i HL7 for BizTalk Server 2013 R2

For problem 1

Denne nye funksjonen gjelder bare for mottak Port /-plassering. For øyeblikket mottar et BizTalk port-egenskapen er en Innkommende tilordninger . Når denne hurtigreparasjonen er installert, er det en ekstra egenskap tilgjengelig i mottak hvor det skal bruke et kart på en HL7-Ack Denne ekstra (TidsavbruddForODBC) kan du bruke et kart til en toveis får plassering som har Bruk direkte synkron HL7 ACK til (=) Sann. Det eneste formålet med denne hurtigreparasjonen er å tillate brukeren å angi et kart for en Bekreftelse når Bruk direkte synkron HL7 SPOR er satt til (=) Sann.

Når du har installert hurtigreparasjonen, vil du se to andre egenskaper i MLLP mottar plasseringen konfigurasjon-vinduet. Standardinnstillingen for de to egenskapene er tomt, og de må fylles ut, og Bruk direkte synkron HL7 ACK må være satt til (=) Sann.



Hvis du vil angi to egenskaper, gjør du følgende:

1. OutboundMap samlingsnavn egenskapen krever at det fulle navnet på samlingen som utgående kartet er vert for, som i følgende eksempel:
   
   

   Utgående, versjon = 1.0.0.0, Culture = nøytral, PublicKeyToken = 83f92b3673c9005dSamlingen må tidligere være hurtigbufret av den globale samlingsbufferen. Hvis ikke, mislykkes transformasjonen.

2. OutboundMap Name -egenskapen krever det fullstendige navnet på kartet inkludert navneområde.

En shortcoming av den nye funksjonaliteten: HL7-ACK spores ikke. Du må holde rede på ACK, må du også angi Innkommende kart -egenskapen i BizTalk får port. Teknisk sett vil du bruke kartet til SPOR som ble satt inn i melding-boksen og ACK som ble returnert til oppstrøms-systemet. Begge må være identiske fordi begge har samme kart brukes. Følgende skjermbilde er inkludert for å klargjøre og er bare nødvendig hvis ACK må følges.



Obs! Alternativet Bruk direkte synkron HL7-SPOR forbedrer ytelsen ved behandling av innkommende melding. Dette gjøres ved å sende ACK tilbake til foregående systemet så snart meldingen lagres i meldingsboksen. Denne innstillingen forbedrer ytelsen hvis følgende betingelser er oppfylt:

• Motta porten er en toveis mottak-port, og Bruk direkte synkron HL7 ACK -alternativet er satt til True i MLLP motta portkonfigurasjonen.

• BizTalk-HL7 DASM brukes til å generere Ack DASM-komponenten må brukes enten som er inkludert i standard BTAHL72XReceivePipeline, eller ved hjelp av den opprinnelige BTAHL7. HL72fDasm-komponenten i en egendefinert rørledning.

• Rute-ACK til sending rørledningen på forespørsel-svar får port innstillingen av kilde-part må være i HL7 konfigurasjon Explorer, og Bekreftelse Type må være satt til en annen verdi enn Ingen.

For problemet 2

Den nye funksjonen gjelder hvis du vil sende bare porter. Når du har installert hurtigreparasjonen, baseres virkemåten for akseptabel ACK-koden som du velger i rullegardinlisten i stedet for koden som leveres av downstream systemet.

Sende MLLP Send port kontrollerer ACK-koden i ACK (MSA.1_AcknowledgmentCode felt med MSA segment) som returneres av downstream systemet og sammenligner den med akseptabel ACK-kodene som er angitt i MLLP egenskaper for port-konfigurasjon. Gjeldende godkjente ACK-kodene som støttes av MLLP sende port inkluderer AA, CA, AE, CE, AR og CR. Du kan velge alle ACK-koder eller en kombinasjon av dem (AA og CA), (AA, CA, AE og CE), (AA, CA, AR og CR) som gyldig. Men det finnes ingen alternativer for å angi en akseptabel ACK-kodekombinasjonen.

En ekstra akseptabel ACK-koder -verdi som heter "Egendefinert" blir lagt til i rullegardinlisten i egenskapen Akseptabel ACK-koder . Alle tidligere kombinasjonene forblir og brukes slik den var før den nye funksjonen ble lagt til.





Etter at Egendefinert er valgt, må du også angi nye verdier i egenskapen Akseptabel egendefinert ACK-koder . Disse nye ACK-verdier må være atskilt med et komma (,).

Når du har installert hurtigreparasjonen, avhenger virkemåten av innstillingen for Akseptabel ACK-koder som er valgt. Hvis ACK-koden som er returnert stemmer overens med den valgte koden for akseptabel, skjer behandlingen ble. Det vil prøve på nytt for standard ACK-koder og hvilemodus for ACK-kode som ikke er oppført (som gjør det en ikke-standard eller en ikke-tilpasset ACK-kode).

Den følgende tabellen representerer dette scenariet. En skriftlig tolkning følger tabellen.



Meldingen behandler alltid lykkes uansett noen akseptabel ACK koder innstillingen som er valgt for AA og CA. Her er mer informasjon om innstillinger for Akseptabel ACK-koder :

• AA, CA: Forsøk AE, CE, AR CR og utsetter alle andre.

• AA, CA, AE, CE: Godtatt og vellykket: AA, CA, AE, CE og forsøk AR og Kreditnotabeløp Innstiller alle andre.

• AA, CA, AR CR: Godtatt og vellykket: AA, CA, AR, CR og forsøk AE og CE. Stopper alle andre.

• AA, CA, AR, CR, AE, CE: Godtatt og vellykket: AA, CA, AR, CR, AE, CE og ingen andre returneres. Bekreftelser på nytt, og meldingen er deaktivert.

• Egendefinert (verdier angitt og atskilt med komma). Eksempel: AA, AE, Foo, ZZ, ZZZ). Godtatt og vellykket: AA, CA, AE, pluss andre angitt egendefinert ACK som Foo, ZZ og ZZZ i dette tilfellet. Forsøk CE, AR.

• ACK-kode som ikke er angitt i Akseptabel egendefinert ACK-koder forsøkt på nytt ikke og er deaktivert.

Når det ikke er angitt en standard ACK under Akseptable ACK-koder, returneres en feil som ligner på følgende:

Ut av esken ACK-skjemaet må endres ved å legge til den eksisterende listen over standard bekreftelse (AA, AE, AR, CA, CE, CR). Eventuelle ekstra akseptabel egendefinerte bekreftelse (XX, ZZ, for eksempel) må legges til MSA.1_AcknowledgementCode -feltet i SPOR-skjemaet. Hvis de ekstra egendefinerte bekreftelse ikke er lagt til skjemaet, mislykkes pipeline-valideringen med feilmeldingen "Verdi ikke funnet".