Pengelompokan Pesan untuk Pemrosesan Pengiriman

Mengirim Adapter Manajemen Batch

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 menyelesaikan transaksi; ia juga harus mengelola dengan benar status pesan yang diterimanya. 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 terpisah (non-transaksi) untuk jenis operasi ini.

Gambar berikut menunjukkan penggunaan 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 pengiriman (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, ia 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 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 pada gilirannya dan mungkin akan membangun batch penghapusan untuk setiap titik akhir. Kelas yang dapat digunakan kembali generik BaseAdapter dalam kode sampel SDK berfungsi dengan cara yang sama.

Pengurutan untuk Pengiriman 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 mungkin digunakan oleh server FTP untuk menentukan titik akhir yang sebenarnya. Dalam hal ini, jika adaptor masuk sebagai akun yang berbeda, adaptor mungkin terhubung ke direktori yang berbeda.

Dalam beberapa kasus, titik akhir benar 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 pada satu titik akhir terkadang merupakan tugas yang tidak mudah dan mungkin melibatkan langkah tambahan seperti mempertimbangkan nilai konteks dan hingga mengevaluasi hasil dari panggilan ke SSO.

Pengurutan pada Pengiriman 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 ini, Anda memiliki properti yang mungkin merupakan bagian dari kunci titik akhir yang tertanam 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.

Ingatlah bahwa jumlah percobaan ulang terkait pesan tidak berhubungan dengan keberhasilan atau kegagalan batch. Di sisi pengiriman, sekumpulan pesan mungkin gagal karena beberapa pesan dalam batch tersebut mengalami kegagalan. 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 diajukan ulang, penghitungan ulang (yang dikelola oleh mesin BizTalk Server) ditambahkan secara salah bahkan untuk pesan yang berhasil karena berada dalam batch yang sama dengan pesan yang gagal. Dalam hal ini, adaptor dapat mengubah batch keluar dan mengirim ulang pesan yang berhasil ke sistem eksternal.