Kā lietot kartes un pielāgotas apliecinājuma kodi apliecinājuma ziņojumi HL7 BizTalk Server R2 2013

1. problēmas

Šis jaunais līdzeklis attiecas tikai uz saņemt ports/vieta. Pašlaik visas BizTalk saņemt ports ir Ienākošā kartes rekvizītu. Pēc šī labojumfaila instalēšanas nav pieejams papildu rekvizītu saņemšanas vietā HL7 komplementāro kartes lietošana Šo papildu rekvizītu var lietot karti divvirzienu saņemt atrašanās vietu, kas ir Izmantot tiešo sinhrona HL7 apliecinājuma kopu (=) spēkā. Šo labojumfailu tikai nolūks ir ļauj lietotājam norādīt kartes apliecinājuma iestatot (=) spēkā Izmantot tiešo sinhrona HL7 apliecinājuma .

Pēc šī labojumfaila instalēšanas jūs redzēsit divas papildu rekvizīti MLLP saņemt konfigurācijas logs. Divi rekvizītu noklusējuma iestatījums ir tukša, ir jāizveido un Izmantot tiešo sinhrona HL7 apliecinājuma jāiestata (=) spēkā.



Lai iestatītu divus rekvizītus, rīkojieties šādi:

1. OutboundMap montāžas Name rekvizīta nepieciešama pilno vārdu montāžas ir izvietots izejošais karti, kā redzams šajā piemērā:
   
   

   Izejošais, Version = no 1.0.0.0, Culture neutral, PublicKeyToken = = 83f92b3673c9005dMontāžas ir iepriekš kešoti globālās montāžas. Pretējā gadījumā neizdosies transformāciju.

2. OutboundMap Name rekvizīta prasa karti, tostarp nosaukumvietas pilno vārdu.

Šī jaunā funkcionalitāte viens trūkums: HL7 apliecinājuma netiek izsekoti. Ja apliecinājuma, ir jāreģistrē, jāiestata Ienākošā kartes rekvizītu BizTalk saņemt portu. Tehniski jums tiks lietoti karte apliecinājuma, kas tika ieviesta ziņojuma lodziņa un apliecinājuma atgrieztā iepriekšējās sistēmas. Gan būtu identiski, jo gan būs pašu karti lietot. Šī ekrānuzņēmums ir iekļauts skaidrojums un ir nepieciešams tikai tad, ja ir reģistrētas apliecinājuma.



Piezīme. Iespēja Izmantot tiešo sinhrona HL7 apliecinājuma uzlabo ienākošo ziņojumu apstrādes veiktspēju. Tas tiek darīts, nosūtot apliecinājuma atpakaļ pie iepriekšējās sistēmas, tiklīdz ziņojums tiek novietots uz ziņojuma lodziņu. Šis iestatījums uzlabo veiktspēju, ja ir spēkā kāds no šiem nosacījumiem:

• Saņemt ports ir divvirzienu saņemt portu un Izmantot tiešo sinhrona HL7 apliecinājuma opcija ir iestatīta uz True MLLP saņemt porta konfigurācijas.

• BizTalk HL7 DASM lieto, lai ģenerētu komplementāro DASM komponents ir jāizmanto kā iekļauts noklusējuma BTAHL72XReceivePipeline vai izmantojot vietējos BTAHL7. HL72fDasm pielāgotā konveijera komponentu.

• Maršruta apliecinājuma nosūtīt konveijera pieprasījumu atbildes uz saņemt porta iestatījumu puse avota jābūt HL7 konfigurācijas pārlūks un Apliecinājums tips ir jāiestata vērtība nav neviena.

2. problēmas

Jaunais līdzeklis attiecas uz sūtīt tikai portu. Pēc šī labojumfaila instalēšanas darbība pamatā ir pieņemami apliecinājuma kodu, kas ir nevis kods, ko nodrošina sistēmas lejupstraumes nolaižamajā sarakstā atlasiet.

MLLP sūtīt portu pārbaudes kods ACK ACK (MSA.1_AcknowledgmentCode lauks ppl segment) atgrieza lejupstraumes sistēmu un salīdzinājumā ar pieņemamu apliecinājuma kodi, kas ir iestatīti MLLP nosūtīt porta konfigurācijas rekvizītos. Pašreizējo pieņemams apliecinājuma kodi, kas nodrošina MLLP sūtīt portu ietver AA, iespējams, AV un CE, AR CR. Var atlasīt visus apliecinājuma kodus vai kombinācija (AA un CA) (AA, iespējams, AV un CE) (AA, iespējams, AR un CR) par derīgu. Taču nepastāv iespēja ievadīt pieņemams apliecinājuma kodu kombināciju.

Papildu kodi pieņemams apliecinājuma vērtību ar nosaukumu "Custom" pievieno rekvizītu Pieņemams apliecinājuma kodu nolaižamajā sarakstā. Visas iepriekšējās kombinācijas joprojām un tiek lietotas, kā tas bija pirms tika pievienots jauns līdzeklis.





Pēc Pielāgota atlasīts, jāievada arī jaunās vērtības Pieņemams apliecinājuma kodi pielāgotu rekvizītu. Šīs jaunās vērtības apliecinājuma katru atdala ar komatu (,).

Pēc šī labojumfaila instalēšanas darbība ir atkarīga no Pieņemams apliecinājuma kodi iestatījumu, kas ir atlasīta. ACK kods, kas tiek atgriezta atbilst atlasītajam kodam pieņemams, ja apstrāde notiek sekmīgi. Tas vēlreiz standarta apliecinājuma kodi un aptur visus apliecinājuma kodu, kas ir nav norādīta (kas veiks nestandarta vai apliecinājuma-pielāgots kods).

Šajā gadījumā nozīmē tabulā. Rakstiska interpretācija izriet tabulā.



AA un CA ziņojumu apstrādes vienmēr izdodas neatkarīgi no jebkura pieņemams apliecinājuma kodus iestatījums ir atlasīts. Šeit ir vairāk informācijas par Pieņemamu apliecinājuma kodi iestatījumiem:

• AA, CA: Mēģinājumu AV CE, AR CR un aptur jebkuru citu.

• AA, iespējams, AV, CE: Pieņēmis un veiksmīgi: AA, iespējams, AV un CE mēģinājumu AR un CR. aptur jebkuru citu.

• AA, iespējams, AR CR: Pieņēmis un veiksmīgi: AA, iespējams, AR CR un mēģinājumu AV un CE. Aptur jebkuru citu.

• AA, iespējams, AR CR, AV, CE: Pieņēmis un veiksmīgi: AA, iespējams, AR, CR, AV CE un citas tiek atgriezta. ACK atkārtota un ziņojumu apturēta.

• Pielāgota (vērtības ir ievadīts un atdalīti ar komatu). Piemērs: AA AV, Foo, ZZ, ZZZ). Akceptētais un veiksmīgi: AA, iespējams, AV, kā arī citu ievadīts pielāgotās apliecinājuma Foo, ZZ un ZZZ šajā gadījumā. Mēģinājuma CE, AR.

• Visi apliecinājuma kodi, kas nav norādīta Pieņemama Custom apliecinājuma kodi netiek atkārtoti un ir pārtraukta.

Ievadot standarta apliecinājuma nav pieņemams apliecinājumakodiem, tiek atgriezts kļūdas ziņojums, kas līdzīgs šim:

Netradicionāli apliecinājuma shēmu būtu jāmaina, pievienojot standarta ACKs (AA AV, AR, iespējams, CE, CR) esošo sarakstu. Visas papildu pieņemams pielāgotu ACKs (ZZ, piemēram, XX) ir jāpievieno apliecinājuma shēmu MSA.1_AcknowledgementCode jomā. Ja netiek pievienoti papildu pielāgotas ACKs shēmu, konveijera validācija neizdodas "Tabulas vērtība nav atrasts" kļūdas.