FIX: Perbaikan terbaru tersedia yang menyediakan tambahan pengiriman Mode properti untuk protokol lapisan bawah Minimal mengirim dan menerima adapter di BizTalk akselerator untuk HL7 di lingkungan BizTalk Server 2010

Tentang perbaikan terbaru

Aliran pesan setelah perbaikan terbaru diinstal dan dikonfigurasi

Setelah Anda menerapkan dan mengaktifkan perbaikan terbaru ini, adaptor MLLP mengirimkan pesan yang diterima oleh adaptor MLLP untuk MessageBoxDB. Titik akhir Manager (EPM) panggilan kembali adaptor bersama status pengiriman di BatchComplete metode. Hal ini menyebabkan adaptor untuk mengirim komit ACK/NAK ke sistem Hulu. Pada gilirannya, sistem Hulu menerima ACK/NAK dan kemudian mengirimkan pesan berikutnya. The BatchComplete metode independen dari MaxReceiveInterval menetapkan dan disebut segera setelah pesan yang dikirim ke BizTalk berhasil.

Segera setelah pesan sudah siap untuk mengirim, adaptor Kirim mengirimkan pesan ke sistem Hilir. ACK/NAK diperkirakan jika Menggunakan pengakuan MLLP Transport properti ini diset Benar. Jika Kirim ACK, BizTalk selesai pengolahan berhasil. Jika Kirim NAK, dan jika Menangguhkan pesan permintaan pada MLLP transportasi NAK properti ini diset Benar, pesan ditangguhkan langsung tanpa mencoba kembali pulih. Namun, jika Menangguhkan pesan permintaan pada MLLP transportasi NAK properti ini diset PalsuBizTalk akan coba lagi didasarkan pada pengaturan interval Kirim port coba lagi. (Secara default, Menangguhkan pesan permintaan pada MLLP transportasi NAK properti ini diset Palsu.)

Diagram berikut menunjukkan aliran pesan:

1. Pesan yang dikirim oleh sistem Hulu mengirimkan aplikasi diproses oleh MLLP menerima adaptor.
2. Adaptor MLLP mengirimkan pesan BizTalk/EPM.
3. EPM panggilan kembali adaptor mengenai status pengiriman pesan. EPM melakukan hal ini Batch lengkap metode.
4. Komit ACK/NAK dihasilkan oleh adaptor MLLP dan didasarkan pada status pengiriman Batch. ACK/NAK dikirim ke aplikasi pengiriman.
   
   Catatan Jika status Batch Submission Sukses, adaptor kembali ACK. Namun, jika kegagalan atau jika pengajuan kali keluar (misalnya, jika Batch lengkap metode panggilan kali keluar), adaptor kembali NAK ke aplikasi pengiriman.
   
   
5. EPM tangan atas pesan untuk mengirim MLLP adaptor untuk transmisi.
6. MLLP mengirim adaptor mengirim pesan diproses sistem Hilir.
7. Transportasi tingkat ACK/NAK diharapkan oleh adaptor Kirim MLLP untuk menyelesaikan komunikasi.
8. Jika pesan dalam langkah 7 ACK, adaptor meminta EPM untuk menghapus pesan. Jika tidak, adaptor harus meminta EPM coba lagi yang didasarkan pada pengaturan interval coba lagi. Pilihan baru yang diberikan dalam pengaturan konfigurasi port Kirim untuk menangguhkan pesan langsung, tanpa coba lagi, jika NAK MLLP yang diterima. Secara default, opsi ini disetel ke Palsu. Jika opsi ini disetel ke Benar, pesan akan ditangguhkan langsung, tanpa coba lagi, jika NAK MLLP yang diterima.

Transportasi tingkat ACK/NACK format

Untuk informasi lebih lanjut tentang spesifikasi transportasi, kunjungi situs HL7 berikut:Situs web berisi informasi berikut:

• Contoh MLLP melakukan pengakuan:
  <SB><ACK><EB><CR></CR></EB></ACK></SB>
• Contoh negatif MLLP melakukan pengakuan:
  <SB><NAK><EB><CR></CR></EB></NAK></SB>

Catatan

• Dalam contoh ini, <SB>merujuk pada karakter mulai blok (1 byte). Ini sesuai dengan <VT>karakter ASCII, atau <0x0B>.<b00> </b00> </0x0B> </VT> </SB>
  
  Ini seharusnya tidak dikelirukan dengan SOH atau STX ASCII karakter.
• Dalam contoh ini, <ACK>atau <NAK>merujuk pada pengakuan karakter (1 byte. Sesuai dengan <ACK>ASCII karakter, atau <0x06>) atau negatif-pengakuan karakter (1 byte. Sesuai dengan <NAK>karakter ASCII, atau <0x15>).<b00> </b00> </0x15> </NAK> </0x06> </ACK> </NAK> </ACK>
• Dalam contoh ini, <EB>merujuk pada akhir blok karakter (1 byte). Ini sesuai dengan <FS>karakter ASCII, atau <0x1C>.</0x1C> </FS> </EB>
• Dalam contoh ini,<CR>merujuk kepada karakter Carriage Return (1 byte). Ini sesuai dengan<CR>Karakter ASCII, atau <0x0D>.</0x0D></CR></CR>
• Microsoft menyediakan informasi kontak pihak ketiga untuk membantu Anda menemukan dukungan teknis. Informasi kontak ini dapat berubah tanpa pemberitahuan. Microsoft tidak menjamin ketepatan dari informasi kontak pihak ketiga ini.

Cara mengkonfigurasi menerima dan mengirim port untuk menggunakan properti baru

Mengkonfigurasi menerima dan mengirim pelabuhan sebagai berikut.

Catatan Menerima dan mengirim pengaturan port dapat digunakan secara terpisah atau bersama-sama.

Menerima port konfigurasi

• Port harus pelabuhan satu arah.
• The Memerintahkan pengiriman parameter diaktifkan.
• Anda harus mengatur Menggunakan pengakuan MLLP Transport properti untuk Benar untuk mengaktifkan transportasi tingkat pengakuan. Secara default, properti ini diatur ke Palsu Ada port atau port baru.

Mengirim konfigurasi port

• Port harus pelabuhan satu arah.
• Solicit-respon modus harus diatur ke Tidak.
• The Memerintahkan pengiriman parameter diaktifkan.
• Anda harus mengatur Menggunakan pengakuan MLLP Transport properti untuk Benar untuk mengaktifkan transportasi tingkat pengakuan. Secara default, properti ini diatur ke Palsu Ada port atau port baru.
• Anda harus mengatur Menangguhkan pesan permintaan pada MLLP transportasi NAK properti untuk Benar Jika pesan perlu ditangguhkan langsung tanpa menjadi retried ketika NAK transportasi yang diterima dari sistem Hilir. Jika tidak, pesan akan retried untuk jumlah kali yang diatur dalam transportasi pilihan Kirim pelabuhan lanjutan. Secara default, properti ini diatur ke Palsu Ada port atau port baru.

Tentang "Penggunaan MLLP transportasi pengakuan" properti

Tabel berikut menjelaskan tentang perilaku yang diharapkan dari satu arah atau dua arah pelabuhan yang menggunakan Menggunakan pengakuan MLLP Transport properti. Kombinasi diperlukan pengaturan harus diterapkan seperti yang dijelaskan di bagian "Cara untuk mengaktifkan perbaikan terbaru".

Catatan

• "Hulu sistem" mengacu pada aplikasi pengiriman. Mengirim pesan ke BizTalk. Ini pesan masuk ke BizTalk.
• "Hilir sistem" mengacu pada aplikasi menerima. Menerima pesan dari BizTalk. Pesan ini keluar untuk BizTalk.

Dua arah menerima dan mengirim pelabuhan perilaku tidak berubah. Satu arah menerima dan mengirim pelabuhan perilaku juga tidak berubah kecuali Menggunakan pengakuan MLLP Transport properti diatur ke true.

Untuk informasi lebih lanjut, lihat dokumentasi adaptor MLLP. Jika satu arah menerima dan kirim port memiliki konfigurasi yang sesuai, meningkatkan kinerja. Jika Menggunakan pengakuan MLLP Transport properti dari dua arah port atau port arah diatur ke false, jenis ACK yang dihasilkan berlanjut tanpa perubahan. Dalam situasi ini, jenis ACK yang dihasilkan tergantung pada pengaturan BTAHL7 konfigurasi Explorer untuk aplikasi yang mengirim pesan. Nilai di bidang MSH 15 dan MSH 16 pesan tertentu dapat menimpa pengaturan ini. Namun, jika Menggunakan pengakuan MLLP Transport properti dari dua arah port atau port arah diatur ke false, Anda dapat mengatur konfigurasi untuk aplikasi yang mengharapkan ACKs statis hanya dengan menggunakan konfigurasi BTAHL7 Explorer. Waktu habis perilaku untuk port tetap tidak berubah.

Perilaku yang diharapkan pada sudut kasus ketika properti yang digunakan adalah sebagai berikut:

MENERIMA

• WrongMLLPFormat: pesan tidak diserahkan kepada BizTalk.
• WrongHL7Format: pesan yang dikirim ke BizTalk, dan MLLP ACK/NAK ditransmisikan yang didasarkan pada status Batch selesai.
• TransmittingSocketIssue: MLLP ACK/NAK tidak menular, meskipun pesan yang dikirim ke BizTalk.
• ReceivingSocketIssue: pesan tidak menerima dan karena itu tidak dikirimkan, dan transmisi MLLP ACK/NAK tidak dikirim.
• Jika pengajuan ke BizTalk gagal, NAK ditransmisikan.
• Jika status negatif Batch lengkap yang diterima, NAK ditransmisikan.

MENGIRIM dan mengirim pelabuhan properti "berhenti mengirim pesan berikutnya pada kegagalan pesan saat ini" = True

• WrongMLLPFormat: pesan dibatalkan karena MLLP ACK/NACK tidak dapat membaca. Pengolahan tidak akan melanjutkan sampai ditangguhkan pesan dihapus.
• WrongHL7Format: pesan gagal sebelum mencapai adaptor. Pengolahan tidak akan melanjutkan sampai ditangguhkan pesan dihapus.
• TransmittingSocketIssue: pesan dibatalkan. Pengolahan tidak akan melanjutkan sampai ditangguhkan pesan dihapus.
• ReceivingSocketIssue: pesan dibatalkan. Pengolahan tidak akan melanjutkan sampai ditangguhkan pesan dihapus.

Perilaku yang diharapkan ketika Menangguhkan pesan permintaan pada MLLP transportasi NAK properti ini diset Benar atau untuk Palsu adalah sebagai berikut:

• Ketika Menangguhkan pesan permintaan pada MLLP transportasi NAK properti ini diset Benar dan NAK diterima, pesan ditangguhkan tanpa coba lagi untuk mengirim.
• Ketika Menangguhkan pesan permintaan pada MLLP transportasi NAK properti diatur ke pengaturan default Palsu, coba lagi mengirim pesan dimulai, berdasarkan pengaturan interval Kirim port coba lagi.

Perubahan untuk utilitas MLLP SDK

MLLP SDK Utility termasuk parameter baru berikut. Semua parameter lainnya tetap tidak berubah. Untuk informasi lebih lanjut, lihat dokumentasi produk.

• Untuk MLLPReceive.exe, gunakan parameter baru untuk kembali MLLP ACK/NAK setelah pesan diterima. Sebagai contoh:
  MLLPReceive/p 12000 /sb 11 /eb 28 /cr 13 /MLLPTransACK
  MLLPReceive/p 12000 /sb 11 /eb 28 /cr 13 /MLLPTransNAK
• Untuk MLLPSend.exe, gunakan parameter baru untuk menunggu untuk MLLP ACK/NAK. Sebagai contoh:
  MLLPSend /sb 11 /eb 28 /cr 13/f "C:\HL7\ls.txt" /I 127.0.0.1 p 11000 /UseMLLPTransACK