Bagikan melalui

Pesan Batching untuk Pemrosesan Pengiriman

  • Artikel

Kirim Manajemen Batch Adapter

Saat menggunakan transaksi di sisi kirim, transaksi yang sama yang dibuat oleh BizTalk Server dan digunakan untuk mengirim ke sistem target digunakan untuk penghapusan pesan yang sesuai setelah berhasil dikirim. Jika ada yang gagal, transaksi dapat berakhir, dalam hal ini penghapusan dibatalkan, dan data tetap berada di BizTalk Server dan bukan dalam sistem target. Ini mencegah duplikasi pesan. Transaksi hanya didukung untuk adaptor pengiriman asinkron. Anda tidak boleh menggunakan transaksi dengan adaptor pengiriman sinkron.

Tetapi adaptor tidak bisa hanya mengakhiri transaksi; ini juga harus menangani dengan benar status pesan yang diberikannya. Secara khusus, adaptor harus memanggil metode Pengiriman Ulang, MoveToNextTransport, dan MoveToSuspendQ dengan tepat tergantung pada jumlah coba lagi dan apakah transportasi cadangan tersedia.

Penting untuk menempatkan operasi Delete dan SubmitResponse bersama-sama dalam batch yang menggunakan transaksi yang sama. Kegagalan ditangani dengan mengakhiri transaksi (untuk memastikan bahwa data hanya dikirimkan sekali ke sistem eksternal). Tetapi Anda masih ingin mengirim ulang atau memanggil MoveToNextTransport untuk pesan kembali di BizTalk Server. Untuk melakukan ini, gunakan batch normal (non-transaksi) terpisah untuk jenis operasi ini.

Gambar berikut menunjukkan penggunaan batch terpisah untuk pesan respons.

Menggunakan batch terpisah untuk pesan respons

Mengurutkan Batch Transaksional Send-Side menurut Titik Akhir

Batch pesan yang dikirim oleh BizTalk Server ke adaptor dapat mencakup beberapa port kirim (atau titik akhir). Karena adaptor biasanya ingin memiliki transaksi ke satu titik akhir, adaptor harus mengurutkan pesan berdasarkan port kirim (SPName atau OutboundTransportLocation). Dengan melakukan ini, adaptor dapat membuat transaksi yang hanya mencakup port pengiriman tertentu.

Misalnya, ketika adaptor pengiriman FTP menerima batch pesan dari BizTalk Server, adaptor tersebut mendapatkan batch pesan campuran untuk semua port pengiriman FTP yang saat ini aktif. Ini terjadi karena API berbasis singleton, yang berarti bahwa hanya satu adaptor FTP yang dimuat, bukan satu pun per port pengiriman.

Adaptor harus terlebih dahulu mengurutkan batch pesan yang diberikan oleh BizTalk Server ke dalam batch terpisah, satu untuk setiap titik akhir. Kemudian dapat menangani setiap titik akhir secara bergantian dan mungkin akan membuat batch penghapusan untuk setiap titik akhir. Kelas yang dapat digunakan kembali generik BaseAdapter dalam kode sampel SDK berfungsi dengan cara yang sama.

Pengurutan untuk Kirim Dinamis

Orkestrasi BizTalk Server dapat mengirim pesan ke port yang belum dikonfigurasi selama menyediakan detail konfigurasi yang memadai di header pesan dan di URL itu sendiri. BizTalk Server harus mengenali protokol URL.

Saat mengurutkan pesan, Anda harus berhati-hati untuk menetapkan apa yang menentukan titik akhir. Ini terutama berlaku dalam kasus pengiriman dinamis. Jika hanya URI yang menentukan titik akhir, maka semuanya sederhana. Namun, dalam sesi FTP, detail masuk nama pengguna dapat digunakan oleh server FTP untuk menentukan titik akhir yang benar. Dalam hal ini, jika adaptor masuk sebagai akun yang berbeda, adaptor mungkin terhubung ke direktori yang berbeda.

Dalam beberapa kasus, titik akhir yang sebenarnya tidak diketahui sampai Anda menjalankan perintah Enterprise Single Sign-On (SSO) ValidateAndRedeemTicket.

Dalam kasus MQSeries, penentuan apakah akan menggunakan transaksi dapat dikonfigurasi. Mengingat arsitektur dan penggunaan objek COM+ jarak jauh, yang terbaik adalah menganggap titik akhir transaksi sebagai berbeda dari titik akhir non-transaksi.

Untuk meringkas, mengurutkan pesan ke dalam batch titik akhir tunggal mereka terkadang merupakan tugas nontrivial dan dapat melibatkan langkah-langkah tambahan seperti mempertimbangkan nilai konteks dan bahkan hasil panggilan ke SSO.

Pengurutan untuk Kirim Statis

Jika titik akhir adalah titik akhir yang dikonfigurasi secara statis, ada GUID unik pada konteks pesan yang disebut ID port statis (SPID). Nilai ini dapat digunakan untuk mengurutkan titik akhir. Kode berikut dapat digunakan untuk mengambilnya:

string spid = (string)message.Context.Read("SPID", "http://schemas.microsoft.com/BizTalk/2003/system-properties");

Ini berguna ketika Anda mempertimbangkan masalah yang diperkenalkan oleh kerangka kerja konfigurasi berbasis Definisi Skema XML (XSD). Dengan kerangka kerja ini, Anda memiliki properti yang mungkin menjadi bagian dari kunci titik akhir yang terkubur di dalam XML dalam satu properti konteks. Jika Anda memiliki SPID pada konteks, Anda dapat menggunakannya sebagai cara untuk mengurutkan batch. Jika tidak, Anda melakukan pengiriman dinamis dan Anda perlu membuat kunci alternatif untuk mengurutkan batch.

Gambar berikut menunjukkan pengurutan pesan menurut titik akhir.

Mengurutkan pesan menurut titik akhir

Ingatlah bahwa jumlah coba lagi pesan tidak mengetahui keberhasilan atau kegagalan batch. Di sisi kirim, batch pesan mungkin gagal karena beberapa pesan dalam batch telah gagal. Adaptor harus membuat penentuan untuk setiap pesan yang diterimanya. Dalam skenario batch yang gagal, Anda mungkin berasumsi bahwa setiap pesan dikirim ulang. Namun, jika semua pesan dalam batch yang gagal dikirim ulang, jumlah coba lagi (yang dikelola oleh mesin BizTalk Server) salah bertambah bahkan untuk pesan yang berhasil karena kebetulan berada dalam batch yang sama dengan pesan yang gagal. Dalam hal ini, adaptor dapat mereformasi batch keluar dan mencoba kembali pesan yang berhasil terhadap sistem eksternal.