Ringkasan
Artikel ini menjelaskan hotfix yang menyediakan dua properti Mode pengiriman tambahan untuk sedikit lebih rendah lapisan Protocol (MLLP) mengirim dan menerima Port ketika Anda menggunakan akselerator BizTalk untuk HL7 di lingkungan Microsoft BizTalk Server 2010:
-
Gunakan MLLP transportasi pengakuan
Properti ini tidak tersedia di kedua satu arah menerima Port dan Port satu arah kirim.
-
Menangguhkan pesan permintaan MLLP transportasi NAK
Properti ini tersedia hanya dalam satu arah kirim Port.
MLLP menerima adapter mendukung kedua mode respons satu arah dan dua arah permintaan. Jika adaptor terima dikonfigurasi, pengolahan HL7 menggunakan parameter Memerintahkan pengiriman . Hal ini menjamin bahwa urutan pengiriman pesan dipertahankan. Saat menerima MLLP adapter beroperasi dalam mode dua arah, adaptor tidak menerima pesan baru dari sistem hulu hingga adaptor menghasilkan pengakuan aplikasi (MSA) untuk pesan sebelumnya ke sistem hulu. Dihasilkan ACK/NAK dikirim ke pangkalan data kotak pesan (MessageBoxDB). MessageBoxDB menunggu untuk interval polling berikutnya sebelum mengirimkan ACK/NAK ke sistem hulu.
Sistem hulu mengirimkan pesan hanya satu per satu dan hanya setelah menerima ACK/NAK. Selain itu, interval BizTalk polling dikonfigurasi, dan parameter Pengiriman memerintahkan diatur ke True. Ini berarti bahwa jumlah pesan yang diproses per detik terbatas. Perbaikan terbaru ini menyediakan konfigurasi tambahan untuk satu arah mengirim dan menerima Port. Tidak mempengaruhi ACK/NAK. Namun, terutama meningkatkan jumlah dokumen yang diproses per detik. Anda harus menggunakan penghitung kinerja untuk mengambil baseline sebelum dan setelah Anda menerapkan perbaikan terbaru ini. Ketika Anda benchmark, Anda harus mengirim wajar jumlah pesan selama jangka waktu yang wajar. Misalnya, Anda dapat menggunakan berikut ini:-
Untuk BizTalk: pesan kategori, gunakan penghitung Dokumen diproses/detik .
-
Untuk BizTalk: latensi pesan kategori, gunakan semua penghitung yang tersedia.
Salah satu opsi untuk menambah jumlah dokumen yang diproses per detik adalah MaxReceiveInterval pengaturan untuk BizTalk host yang lebih rendah. Tergantung pada lingkungan keseluruhan, pada penyetelan komputer yang menjalankan Biz Talk Server 2010, dan volume dokumen yang diproses, menurunkan setelan MaxReceiveInterval dapat memiliki efek yang merugikan pada kinerja dari contoh SQL Server. Untuk SQL Server tuning dan BizTalk tuning, Lihat semua artikel teknis yang tersedia.
Informasi lebih lanjut
Catatan Hotfix ini juga mengatasi masalah dalam akselerator Microsoft BizTalk 2010 untuk HL7. Untuk informasi selengkapnya tentang masalah ini, klik nomor artikel berikut ini untuk melihat artikel di Pangkalan Pengetahuan Microsoft:
2454887 peristiwa mungkin salah masuk untuk pesan berbasis MLLP di 2009 akselerator BizTalk untuk HL7 komputer yang menjalankan Microsoft BizTalk Server 2009 atau Microsoft BizTalk Server 2010
Informasi Hotfix
Tersedia hotfix yang didukung dari Microsoft. Namun, hotfix ini ditujukan untuk memperbaiki masalah yang dijelaskan di artikel ini. Hotfix ini hanya berlaku untuk sistem yang mengalami masalah yang dijelaskan di artikel ini. Hotfix ini mungkin akan menerima pengujian tambahan. Oleh karena itu, jika Anda tidak terlalu dipengaruhi oleh masalah ini, kami sarankan Anda menunggu pemutakhiran perangkat lunak berikutnya yang berisi perbaikan terbaru ini.
Apabila hotfix tersedia untuk diunduh, ada bagian "Tersedia unduhan Hotfix" di bagian atas artikel Pangkalan Pengetahuan ini. Jika bagian ini tidak muncul, hubungi layanan pelanggan Microsoft dan dukungan untuk mendapatkan hotfix. Catatan Jika terjadi masalah tambahan atau apabila pemecahan masalah apa pun diperlukan, Anda mungkin harus membuat permintaan layanan secara terpisah. Biaya dukungan biasa akan berlaku untuk dukungan tambahan pertanyaan dan masalah yang tidak memenuhi syarat untuk hotfix ini. Untuk daftar lengkap nomor telepon layanan pelanggan Microsoft dan dukungan atau untuk membuat permintaan layanan terpisah, kunjungi situs web Microsoft berikut:http://support.microsoft.com/contactus/?ws=supportCatatan Formulir "Tersedia Unduhan Hotfix" menampilkan bahasa hotfix tersedia. Jika Anda tidak melihat bahasa Anda, hal ini karena hotfix tidak tersedia untuk bahasa tersebut.
Prasyarat
Anda harus memiliki akselerator Microsoft BizTalk untuk HL7 (BTAHL7) diinstal untuk menerapkan hotfix ini.
Informasi menghidupkan ulang
Anda mungkin harus memulai ulang komputer setelah menerapkan hotfix ini. Jika Anda diminta untuk me-restart, Anda harus me-restart BizTalk layanan. Untuk informasi selengkapnya tentang prosedur ini, baca berkas Readme.txt yang disertakan dalam paket hotfix ini.
Informasi penggantian
Hotfix ini tidak menggantikan hotfix yang diedarkan sebelumnya.
Informasi file
Versi bahasa Inggris dari hotfix ini memiliki atribut berkas (atau atribut berkas yang lebih baru) yang tercantum dalam tabel berikut. Tanggal dan waktu untuk berkas-berkas tersebut dicantumkan dalam Waktu Universal Terkoordinasi (UTC). Ketika Anda melihat informasi berkas, akan diubah ke waktu lokal. Untuk menemukan perbedaan antara waktu UTC dan waktu lokal, gunakan tab Zona Waktu di item Tanggal dan Waktu di Panel Kontrol.
Nama file |
Versi file |
Ukuran file |
Tanggal |
Waktu |
Platform |
---|---|---|---|---|---|
Microsoft.solutions.btahl7.mllp.dll |
3.9.526.2 |
116,608 |
07-Jun-2011 |
15:27 |
x86 |
Microsoft.solutions.btahl7.shared.dll |
3.9.526.2 |
92,040 |
07-Jun-2011 |
15:27 |
x86 |
Mllpreceive.exe |
3.9.526.2 |
26,456 |
07-Jun-2011 |
15:27 |
x86 |
Mllpsend.exe |
3.9.526.2 |
26,448 |
07-Jun-2011 |
15:27 |
x86 |
Tentang perbaikan terbaru
Aliran pesan setelah hotfix diinstal dan dikonfigurasi
Setelah Anda menerapkan dan mengaktifkan hotfix ini, MLLP adapter mengirimkan pesan yang diterima oleh adapter MLLP untuk MessageBoxDB. Titik akhir Manager (EPM) panggilan kembali adaptor bersama-sama dengan status pengiriman dalam metode BatchComplete . Hal ini menyebabkan adaptor mengirim commit ACK NAK ke sistem hulu. Sebaliknya, sistem hulu menerima ACK/NAK dan kemudian mengirimkan pesan berikutnya. Metode BatchComplete independen dari pengaturan MaxReceiveInterval dan disebut segera setelah pesan yang dikirim ke BizTalk berhasil.
Segera siap untuk mengirim pesan, adaptor kirim mengirimkan pesan ke sistem hilir. ACK/NAK diharapkan jika Menggunakan MLLP transportasi pengakuan properti diatur ke True. Jika kirim ACK, BizTalk selesai pemrosesan berhasil. Jika kirim NAK, dan jika properti Menangguhkan pesan permintaan pada MLLP transportasi NAK diatur ke True, pesan ditangguhkan langsung tanpa mencoba kembali. Namun, jika properti Menangguhkan permintaan pesan di MLLP transportasi NAK diatur ke False, BizTalk akan coba lagi didasarkan pada setelan interval kirim port coba lagi. (Secara default, properti Menangguhkan pesan permintaan pada MLLP transportasi NAK diatur ke False.) Diagram berikut menunjukkan aliran pesan:
-
Pesan yang dikirim oleh sistem hulu mengirimkan aplikasi diproses oleh MLLP menerima adaptor.
-
MLLP adapter mengirimkan pesan untuk BizTalk EPM.
-
EPM panggilan kembali adaptor tentang status pengiriman pesan. EPM dilakukan dalam metode Batch selesai .
-
Commit ACK NAK dihasilkan oleh MLLP adapter dan didasarkan pada status pengiriman Batch. ACK/NAK dikirim ke aplikasi pengiriman.
Catatan Jika status pengiriman Batch keberhasilan, adaptor mengembalikan ACK. Namun, jika ada kegagalan atau pengiriman waktu habis (misalnya, jika panggilan metode Batch selesai waktu habis), adaptor kembali NAK ke aplikasi pengiriman. -
EPM tangan melalui pesan untuk adapter MLLP Kirim untuk transmisi.
-
MLLP mengirim adaptor mengirim pesan diproses ke sistem hilir.
-
Tingkat transportasi ACK NAK diharapkan oleh adapter MLLP Kirim untuk menyelesaikan komunikasi.
-
Jika pesan dalam langkah 7 ACK, adaptor meminta EPM untuk menghapus pesan. Jika tidak, adaptor memiliki meminta EPM pengulangan yang didasarkan pada setelan interval coba lagi. Opsi baru yang disediakan dalam pengaturan konfigurasi port Kirim untuk menangguhkan pesan secara langsung, tanpa coba lagi, jika NAK MLLP menerima. Secara default, opsi ini diatur ke palsu. Jika opsi ini disetel ke True, pesan akan ditangguhkan secara langsung, tanpa coba lagi, jika NAK MLLP diterima.
Format tingkat ACK/NACK transportasi
Situs web ini berisi informasi berikut ini:
-
Contoh MLLP Commit pemberitahuan:
<SB><ACK><EB><CR>
-
Contoh dari negatif MLLP melakukan pemberitahuan:
<SB><NAK><EB><CR>
Catatan
-
Dalam contoh ini, < SB > merujuk ke karakter blok mulai (1 byte). Ini berkaitan dengan karakter ASCII < VT > atau < 0x0B >.
Hal ini tidak boleh bingung dengan SOH atau STX ASCII karakter. -
Dalam contoh ini, < ACK > atau < NAK > Lihat karakter pengakuan (1 byte. Sesuai dengan karakter ASCII < ACK > atau < 0x06 >) atau negatif-pengakuan karakter (1 byte. Berkaitan dengan karakter ASCII < NAK > atau < 0x15 >).
-
Dalam contoh ini, < EB > merujuk ke akhir blok karakter (1 byte). Ini berkaitan dengan karakter ASCII < FS > atau < 0x1C >.
-
Dalam contoh ini, < CR > merujuk ke karakter kembali ke awal (1 byte). Ini berkaitan dengan karakter ASCII < CR > atau < 0x0D >.
-
Microsoft menyediakan informasi kontak pihak ketiga untuk membantu Anda menemukan dukungan teknis. Informasi kontak ini dapat berubah tanpa pemberitahuan. Microsoft tidak menjamin keakuratan informasi kontak dari pihak ketiga ini.
Cara mengkonfigurasi terima dan kirim Port menggunakan properti baru
Mengkonfigurasi terima dan kirim Port sebagai berikut.
Catatan Pengaturan port terima dan kirim dapat digunakan secara mandiri atau bersama-sama.Menerima konfigurasi port
-
Port harus port satu arah.
-
Parameter Memerintahkan pengiriman harus diaktifkan.
-
Anda harus menetapkan properti Penggunaan MLLP transportasi pengakuan ke True untuk mengaktifkan transportasi tingkat pengakuan. Secara default, properti ini diatur ke False untuk port yang sudah ada atau port yang baru.
Kirim konfigurasi port
-
Port harus port satu arah.
-
Mode solicit-respons harus ditetapkan ke tidak ada.
-
Parameter Memerintahkan pengiriman harus diaktifkan.
-
Anda harus menetapkan properti Penggunaan MLLP transportasi pengakuan ke True untuk mengaktifkan transportasi tingkat pengakuan. Secara default, properti ini diatur ke False untuk port yang sudah ada atau port yang baru.
-
Anda harus menetapkan properti Menangguhkan pesan permintaan pada MLLP transportasi NAK untuk benar jika pesan perlu ditangguhkan langsung tanpa dicoba lagi ketika NAK transportasi yang diterima dari sistem hilir. Jika tidak, pesan akan diulangi untuk jumlah waktu yang ditetapkan di transportasi advanced options kirim port. Secara default, properti ini diatur ke False untuk port yang sudah ada atau port yang baru.
Tentang properti "Gunakan MLLP transportasi pengakuan"
Tabel berikut ini menjelaskan perilaku yang diharapkan satu arah atau dua arah port yang menggunakan properti Menggunakan MLLP transportasi pengakuan . Kombinasi diperlukan pengaturan harus diterapkan seperti yang dijelaskan di bagian "Cara mengaktifkan hotfix".
Catatan-
"Sistem hulu" mengacu pada aplikasi pengiriman. Ini mengirim pesan ke BizTalk. Pesan ini tidak masuk ke BizTalk.
-
"Sistem hilir" mengacu pada aplikasi menerima. Menerima pesan dari BizTalk. Pesan ini keluar untuk BizTalk.
Jenis port |
Opsi V2 MLLP |
Opsi V2 MLLP Off |
---|---|---|
Satu arah menerima |
Kirim MLLP ACK/NAK ke sistem hulu dalam metode BatchComplete . |
Tidak ada perubahan dalam perilaku. Dalam situasi ini, tidak ada ACK/NAK dikirim ke sistem hulu. |
Dua arah menerima |
Tidak ada perubahan dalam perilaku. Dalam situasi ini, HL7 ACK/NAK dalam metode TransmitMessage dikirim ke sistem hulu. Catatan Opsi ini tidak didukung. Sebagai contoh, mengabaikan bahkan jika nilainya disetel ke True. |
Tidak ada perubahan dalam perilaku. Dalam situasi ini, HL7 ACK/NAK dalam metode TransmitMessage dikirim ke sistem hulu. |
Kirim satu arah |
MLLP ACK/NAK dari sistem hilir menunggu setelah pesan yang dikirim. |
Tidak ada perubahan dalam perilaku. Dalam situasi ini, ACK/NAK dari sistem hilir tidak menunggu untuk setelah pesan yang dikirim. |
Kirim dua arah atau kirim satu arah dengan respons meminta mode diaktifkan |
Tidak ada perubahan dalam perilaku. Dalam situasi ini, HL7 ACK/NAK dari sistem hilir adalah menunggu setelah pesan yang dikirim. Catatan Opsi ini tidak didukung. Sebagai contoh, mengabaikan bahkan jika nilainya disetel ke True. |
Tidak ada perubahan dalam perilaku. Dalam situasi ini, HL7 ACK/NAK dari sistem hilir adalah menunggu setelah pesan yang dikirim. |
Dua arah menerima dan kirim port perilaku tidak berubah. Satu arah menerima dan kirim port perilaku juga tidak diganti kecuali properti Penggunaan MLLP transportasi pengakuan diatur ke true. Untuk informasi selengkapnya, baca dokumentasi adapter MLLP. Jika satu arah menerima dan kirim Port memiliki konfigurasi yang sesuai, meningkatkan kinerja. Jika properti Penggunaan MLLP transportasi pengakuan port dua arah atau port satu arah diatur ke false, jenis ACK yang dihasilkan tetap tanpa perubahan. Dalam situasi ini, jenis ACK yang dihasilkan tergantung pada setelan penjelajah konfigurasi BTAHL7 untuk aplikasi yang mengirim pesan. Nilai dalam kolom MSH 15 dan MSH 16 pesan tertentu dapat mengganti pengaturan ini. Namun, jika properti Penggunaan MLLP transportasi pengakuan port dua arah atau port satu arah diatur ke false, Anda dapat menetapkan konfigurasi untuk aplikasi yang seharusnya statis ACKs hanya menggunakan BTAHL7 konfigurasi Explorer. Waktu habis perilaku untuk port tidak berubah. Perilaku yang diharapkan di sudut kasus ketika properti yang digunakan adalah sebagai berikut: RECEIVE
-
WrongMLLPFormat: pesan tidak dikirim ke BizTalk.
-
WrongHL7Format: pesan yang dikirim ke BizTalk, dan MLLP ACK/NAK ditransmisikan yang didasarkan pada status Batch selesai.
-
TransmittingSocketIssue: MLLP ACK/NAK tidak ditransmisikan, meskipun pesan yang dikirim ke BizTalk.
-
ReceivingSocketIssue: pesan tidak diterima dan oleh karena itu tidak dikirim, dan transmisi MLLP ACK/NAK tidak dikirim.
-
Jika pengiriman untuk BizTalk gagal, NAK dikirim.
-
Jika status negatif Batch lengkap yang diterima, NAK dikirim.
Mengirim dan kirim port properti "stop mengirim pesan berikutnya saat ini kegagalan pesan" = True
-
WrongMLLPFormat: pesan ditangguhkan karena MLLP ACK/NACK tidak dapat dibaca. Pemrosesan tidak akan tetap sampai ditangguhkan pesan dihapus.
-
WrongHL7Format: pesan gagal sebelum mencapai adaptor. Pemrosesan tidak akan tetap sampai ditangguhkan pesan dihapus.
-
TransmittingSocketIssue: pesan ditangguhkan. Pemrosesan tidak akan tetap sampai ditangguhkan pesan dihapus.
-
ReceivingSocketIssue: pesan ditangguhkan. Pemrosesan tidak akan tetap sampai ditangguhkan pesan dihapus.
Perilaku yang diharapkan ketika Menangguhkan permintaan pesan di MLLP transportasi NAK properti diatur ke True atau menjadi False adalah sebagai berikut:
-
Ketika Menangguhkan permintaan pesan di MLLP transportasi NAK properti diatur ke True dan NAK diterima, pesan ditangguhkan tanpa coba lagi untuk mengirimnya.
-
Ketika Menangguhkan permintaan pesan di MLLP transportasi NAK properti diatur ke pengaturan default False, coba lagi untuk mengirim pesan dimulai, berdasarkan pengaturan interval kirim port coba lagi.
Perubahan utilitas MLLP SDK
MLLP SDK utilitas meliputi parameter baru berikut. Semua parameter lainnya tidak berubah. Untuk informasi selengkapnya, lihat dokumentasi produk.
-
Untuk MLLPReceive.exe, menggunakan parameter baru untuk mengembalikan MLLP ACK/NAK setelah pesan yang diterima. Misalnya:
MLLPReceive /p 12000 /sb 11 /eb 28 /cr 13 /MLLPTransACK
MLLPReceive /p 12000 /sb 11 /eb 28 /cr 13 /MLLPTransNAK -
Untuk MLLPSend.exe, menggunakan parameter baru untuk menunggu untuk MLLP ACK/NAK. Misalnya:
MLLPSend /sb 11 /eb 28 /cr 13/f "C:\HL7\ls.txt" /I 127.0.0.1 /p 11000 /UseMLLPTransACK
Referensi
Untuk informasi selengkapnya tentang cara mengelola setelan kinerja pada BizTalk server, kunjungi situs web Microsoft Developer Network (MSDN) berikut:
Mengelola pengaturan kinerja BizTalk ServerUntuk informasi selengkapnya tentang pesan penghitung kinerja, kunjungi website MSDN berikut:
Pesan penghitung kinerjaUntuk informasi lebih lanjut tentang memerintahkan pengiriman pesan, kunjungi website MSDN berikut:
Memerintahkan pengiriman pesanUntuk informasi lebih lanjut tentang akselerator BizTalk 2010 HL7 (BTAHL7), kunjungi website Microsoft berikut:
Akselerator BizTalk 2010 untuk HL7 dokumentasi (BTAHL7)Untuk informasi selengkapnya tentang metode IBTBatchCallBack.BatchComplete , kunjungi website MSDN berikut:
Metode IBTBatchCallBack.BatchCompleteUntuk informasi lebih lanjut tentang perbaikan terbaru BizTalk Server, klik nomor artikel berikut ini untuk melihat artikel di Pangkalan Pengetahuan Microsoft:
2003907 informasi tentang perbaikan terbaru BizTalk Server