Cara Menangani Kegagalan Adaptor

Secara umum, adaptor harus menangguhkan pesan yang tidak dapat diproses. Misalnya, adaptor penerima yang mengalami kegagalan pengiriman biasanya harus menangguhkan pesan, meskipun keputusan ini tergantung pada tujuan adaptor. Ada juga pertimbangan keamanan sekeliling menangani kegagalan. Misalnya, jika adaptor secara otomatis menangguhkan semua pesan yang gagal, adaptor mungkin terbuka untuk serangan penolakan layanan yang menyebabkan antrean Ditangguhkan BizTalk Server terisi. Beberapa adaptor, seperti HTTP, dapat mengembalikan kode kegagalan ke klien yang menunjukkan bahwa permintaan telah ditolak. Untuk jenis adaptor ini, sering kali masuk akal untuk mengembalikan kode kegagalan daripada menangguhkan pesan. Biasanya mengirim adaptor hanya menangguhkan pesan setelah semua percobaan ulang habis untuk transportasi primer dan sekunder.

Kaitkan Pemrosesan Kesalahan dengan Operasi Individu dan Bukan dengan Batch yang Berisi Operasi

Batching pesan dalam adaptor harus tidak terlihat oleh pengguna adaptor. Ini berarti bahwa kegagalan satu operasi dalam batch tidak boleh memengaruhi operasi lain dengan cara apa pun. Namun, batch bersifat atomik, sehingga kegagalan satu pesan menghasilkan kesalahan untuk batch, dan tidak ada operasi yang diproses.

Anda menulis kode yang bertanggung jawab untuk menangani kesalahan, mengirim ulang pesan yang berhasil, dan menangguhkan pesan yang tidak berhasil. Untungnya, BizTalk Server menyediakan struktur kesalahan terperinci yang memungkinkan adaptor Anda menentukan operasi tertentu yang gagal. Ini memungkinkan pembangunan batch lebih lanjut di mana operasi yang berhasil dikirim ulang dan yang gagal ditangguhkan.

Status akhir operasi tidak boleh dipengaruhi oleh batching dalam adaptor.

Gunakan SetErrorInfo untuk Melaporkan Kegagalan ke BizTalk Server

Jika Menangguhkan pesan, Anda harus memberikan informasi kegagalan ke BizTalk Server dari konteks pesan sebelumnya. BizTalk Server menyediakan kemampuan pelaporan kesalahan menggunakan metode SetErrorInfo pada antarmuka IBaseMessage dan ITransportProxy . Anda dapat melaporkan kesalahan sebagai berikut:

• Ketika kegagalan terjadi saat memproses pesan, atur pengecualian menggunakan SetErrorInfo(Exception e) pada pesan (IBaseMessage) untuk ditangguhkan. Ini memungkinkan mesin untuk mempertahankan kesalahan dengan pesan untuk diagnosis nanti dan mencatatnya ke log peristiwa untuk memberi tahu administrator.

• Jika Anda mengalami kesalahan selama inisialisasi atau pembukuan internal (bukan selama pemrosesan pesan), Anda harus memanggil SetErrorInfo(Exception e) pada pointer ITransportProxy yang diteruskan kepada Anda selama inisialisasi. Jika adaptor Anda didasarkan pada implementasi BaseAdapter, Anda harus selalu memiliki akses ke pointer ini. Jika tidak, Anda harus yakin bahwa Anda menyimpannya dalam cache.

  Melaporkan kesalahan dengan salah satu metode ini menghasilkan pesan kesalahan yang ditulis ke log peristiwa. Penting bagi Anda untuk mengaitkan kesalahan dengan pesan terkait jika Anda dapat melakukannya.

Menangani Kondisi Database-Offline

Jika salah satu database BizTalk Server offline, layanan BizTalk akan mendaur ulang. Mesin Olahpesan berusaha sebaik mungkin untuk mematikan semua lokasi penerima sebelum mendaur ulang layanan. Jika ini memakan waktu lebih dari 60 detik, layanan berakhir. Karena mesin ditransaksikan, ini tidak menyebabkan kehilangan data.

Waktu habis ini dapat disetel dalam registri dengan menggunakan kunci :

DWORD   
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTSSvc{Host Guid}\MessagingDBFailoverShutdownTimeLimit  

Untuk adaptor terisolasi, karena BizTalk Server tidak memiliki proses, lokasi terima dinonaktifkan ketika salah satu database BizTalk Server offline. Setelah database kembali online, lokasi terima tersebut diaktifkan kembali.

Menulis ke Log Peristiwa

Adaptor dapat menulis entri log peristiwa dengan menggunakan antarmuka IBTTransportProxy yang melewati pengecualian. Adaptor yang dikembangkan dalam kode asli perlu diteruskan dalam antarmuka IErrorInfo , IBTTransportProxy.SetErrorInfo( Exceptione).

Mesin Olahpesan menulis ke log peristiwa atas nama adaptor untuk peristiwa seperti ketika adaptor mencoba kembali pesan setelah kegagalan transmisi, memindahkan pesan ke transportasi cadangannya, atau menangguhkan pesan. Untuk operasi seperti ini adaptor hanya perlu mengatur pengecualian pada pesan sebelum memanggil API. Fragmen kode berikut menunjukkan hal ini:

IBaseMessage msg;  
...  
// Set exception on msg to indicate why transmission failed...  
msg.SetErrorInfo(  
 new ApplicationException(  
 "The TCP connection was closed by the destination"));  

Menangani Kesalahan Batch Receive-Specific

Menangani Kegagalan Penerimaan

Ketika adaptor mengirimkan operasi (atau batch operasi) ke BizTalk Server mungkin ada berbagai alasan kegagalan. Dua yang paling signifikan adalah:

• Alur penerima gagal.

• Kegagalan perutean terjadi saat menerbitkan pesan.

  Mesin Olahpesan secara otomatis mencoba menangguhkan pesan saat mendapatkan kegagalan alur penerimaan. Operasi penangguhan mungkin tidak selalu berhasil. Misalnya, jika Mesin Olahpesan mengalami kegagalan perutean saat menerbitkan pesan, mesin bahkan tidak mencoba menangguhkan pesan.

  Selalu mungkin bahwa pesan akan gagal. Dalam situasi seperti itu, adaptor harus secara eksplisit memanggil MOVEToSuspendQ API dan harus mencoba menangguhkan pesan. Saat adaptor mencoba menangguhkan pesan, salah satu hal berikut ini harus benar:

• Objek pesan yang sama dengan adaptor yang dikirimkan (disarankan) harus ditangguhkan.

• Jika adaptor harus membuat pesan baru, maka adaptor harus mengatur konteks pesan pesan baru dengan penunjuk ke konteks pesan pesan yang awalnya dikirimkan. Ini karena konteks pesan pesan memiliki banyak informasi berharga tentang pesan dan kegagalan. Informasi ini diperlukan untuk men-debug pesan yang gagal.

Beberapa adaptor, seperti adaptor HTTP yang disediakan dengan BizTalk Server, tidak mengharuskan pesan ditangguhkan. Adaptor ini dapat mengembalikan kesalahan kembali ke klien mereka.

Penyebab kegagalan

Penyebab kegagalan sederhana adalah kesalahan yang dapat terjadi saat batch dibangun atau ketika IBTTransportBatch::D one dipanggil.

• Kegagalan pengiriman. Panggilan Kirim dapat gagal karena sejumlah alasan terbatas, dan semuanya fatal. Alasan ini meliputi:

• Kesalahan kehabisan memori terjadi di ruang proses BizTalk Server.

• Rakitan skema telah dihilangkan dari penyebaran. Dalam hal ini, Kirim gagal dengan kesalahan kripto. Dalam adaptor MQSeries, pengecualian kegagalan generik dari BizTalk Server ditangkap, dan pesan kesalahan yang diperluas ditulis dalam log peristiwa sistem. Pesan ini menunjukkan bahwa salah satu kemungkinan penyebab kesalahan adalah bahwa rakitan skema entah bagaimana telah dihilangkan dari penyebaran.

  Secara umum, jika Pengiriman gagal, Anda harus mencoba menangguhkan pesan menggunakan transaksi yang sama.

• Kegagalan IBTTransportBatch::D one. Panggilan IBTTransportBatch::D one dapat gagal karena salah satu dari beberapa alasan. Secara umum, Anda harus selalu mencoba satu operasi penangguhan dan mengakhiri transaksi hanya jika itu gagal. Salah satu kode kesalahan yang mungkin Anda terima dari kegagalan IBTTransportBatch::D one adalah BizTalk Server mencoba mematikan. Dalam hal ini, Anda hanya harus mengakhiri transaksi dan meninggalkannya karena panggilan Hentikan mungkin terjadi secara bersamaan. Skenario lain terjadi ketika Anda telah berhasil membangun batch dan berhasil menjalankan IBTTransportBatch::D one. Dalam kasus ini, kesalahan dikembalikan di BatchComplete dan adaptor harus menentukan apa yang harus dilakukan dengannya. Bagian lainnya berkaitan dengan kasus ini.

Memproses kesalahan BatchComplete

BatchComplete adalah panggilan balik yang disediakan oleh adaptor yang dipanggil oleh BizTalk Server untuk menunjukkan status penyelesaian operasi batch.

Parameter terpenting yang diteruskan ke BatchComplete adalah status hResultbatch . Ini menunjukkan keberhasilan atau kegagalan untuk batch. Jika batch gagal, itu berarti bahwa tidak ada operasi dalam batch yang berhasil. Adaptor melewati struktur status batch dan menentukan pesan mana yang gagal (ini dikenal sebagai pemfilteran batch).

Kesalahan BatchComplete nontransaksi

Untuk adaptor nontransaksi, Anda harus memilih respons anda jika terjadi kegagalan untuk operasi SubmitMessage/SubmitRequestMessage atau SubmitResponseMessage . Biasanya adaptor menangguhkan pesan dengan memanggil MoveToSuspendQ.

Operasi berikut selalu diharapkan untuk lulus: DeleteMessage, MoveToSuspendQ, ResubmitMessage. Jika operasi ini gagal, biasanya berarti ada bug di adaptor. Anda tidak perlu menulis kode untuk menangani kegagalan dalam kasus ini. Namun jika batch gagal karena operasi lain gagal, maka operasi ini harus dijalankan kembali dalam batch baru.

Jika adaptor memanggil MovetoBackupTransport dan itu gagal (karena tidak ada transportasi cadangan), maka adaptor harus memanggil MoveToSuspendQ untuk menangguhkan pesan.

Kesalahan Transactional BatchComplete

Ketika Anda mengirimkan batch ke BizTalk Server menggunakan transaksi yang dibuat oleh adaptor, Anda harus mengikuti salah satu dari dua skenario ini:

• Gunakan batch pesan tunggal. Kirim batch pesan tunggal ke BizTalk Server. Jika pesan tunggal itu gagal, maka Anda dapat mengirim batch kedua bizTalk Server secara legal di bawah transaksi yang sama, tetapi Anda harus memindahkan pesan yang menyinggung ke antrean Ditangguhkan daripada mengirimkannya kembali. Setelah pesan gagal dihapus, pengiriman batch kedua akan berhasil. Setelah itu terjadi, Anda dapat melakukan transaksi ketika BizTalk Server mengonfirmasi bahwa batch kedua berhasil. Jika batch kedua gagal, adaptor harus membatalkan transaksi, atau menemukan di tempat lain untuk menempatkan pesan tersebut. Dalam skenario ini, Anda segera mengambil hit performa yang signifikan karena pemrosesan pembatalan transaksi.

  Ada beberapa teknik yang dapat Anda gunakan untuk meningkatkan performa adaptor. Misalnya, adaptor MQSeries menyesuaikan pendekatannya secara dinamis pada durasi. Ini berjalan dengan 100 batch pesan. Jika mengalami kesalahan, itu harus mengakhiri batch, tetapi beralih ke batch pesan tunggal untuk waktu yang singkat karena melewati pesan buruk. Kemudian kembali ke batch 100 pesan. Jika mengalami kesalahan lagi, kesalahan akan melambat lagi.

• Gunakan suspensi preemptive. Buat batch multi-pesan di mana pesan yang salah ditangguhkan terlebih dahulu. Batch berisi campuran operasi Kirim dan MoveToSuspendQ , dan merupakan batch pertama dan satu-satunya di bawah transaksi. Ini harus berhasil karena data buruk ditangguhkan secara preemptive, dan transaksi dapat dilakukan (setelah menunggu untuk menerima konfirmasi dari BizTalk Server).

  Ini mungkin tampaknya perlu melihat ke masa depan, tetapi teknik ini telah digunakan dalam adaptor MSMQ. Itu tergantung pada memiliki ID pesan yang unik. Adaptor ini membuat batch pesan. Jika ada yang gagal, itu mengembalikan transaksi (dan oleh karena itu batch), tetapi mengingat ID pesan dalam struktur data sementara. (Untuk mencegah struktur ini tumbuh tanpa batas waktu, item di dalamnya dihapus setelah beberapa penundaan waktu tetap.) Sebelum setiap batch dikirimkan, adaptor memeriksa daftar ID pesan yang buruk. Jika melihatnya, ia tahu bahwa pesan akan gagal (karena gagal sekali di masa lalu), dan secara preemptive menangguhkannya daripada mencoba mengirimkannya.

  Tidak setiap adaptor memiliki ID pesan yang unik, dan penyimpanan transaksional cenderung tidak memilikinya. Karena itu, banyak adaptor transaksional dibatasi untuk mengirim batch pesan tunggal.

Memproses kesalahan lain

Dalam semua kasus lain (seperti kegagalan dalam menangguhkan pesan), adaptor harus mengakhiri transaksi. Hasil lainnya menghasilkan pesan duplikat atau dihilangkan.

Setiap kali adaptor dapat, adaptor harus membatalkan transaksi jika batch gagal. Namun ada skenario di mana adaptor tidak dapat membatalkan transaksi. Dalam skenario seperti itu, pesan harus ditangguhkan menggunakan transaksi yang sama.

Memproses kesalahan pada penerimaan transaksional

Pola pemrosesan transaksi umum adalah mengakhiri transaksi ketika terjadi kesalahan. Dalam hal ini semuanya kembali ke keadaan sebelumnya dan tidak ada data yang hilang. Namun, jika Anda menggunakan data dari umpan transaksi (misalnya, menarik baris pada satu waktu dari tabel penahapan dalam database, atau menarik satu pesan pada satu waktu dari produk antrean seperti MQSeries atau MSMQ), maka ini mungkin tidak cukup. Jika Anda hanya mengakhiri transaksi dan kembali dan mengambil data yang sama lagi, kesalahan yang sama kemungkinan akan terjadi dan sistem terjebak dalam perulangan berulang.

Adaptor SQL dalam versi BizTalk Server yang lebih lama dikirim dengan perilaku ini. Namun, segera setelah merilis perilaku adaptor diubah untuk mencoba menangguhkan pesan yang gagal dan melakukan transaksi. Memindahkan pesan ke antrean Ditangguhkan di bawah transaksi yang sama dan kemudian melakukan transaksi akan menghemat data agar tidak hilang dan juga memungkinkan adaptor untuk melewati data yang buruk.

Ketika bagian penerima adaptor diteruskan pesan kesalahan sebagai respons terhadap operasi Kirim pesan, adaptor harus memproses kesalahan tersebut dan memindahkan pesan ke antrean Ditangguhkan.

Dalam kasus batch transaksional di mana adaptor telah membuat objek transaksi dan mengirimkan pesan di bawah transaksi, adaptor harus secara logis memindahkan pesan ke antrean Ditangguhkan di bawah transaksi yang sama ketika kegagalan terjadi. Transaksi memastikan bahwa data tidak dihilangkan, dan bahkan data yang menyebabkan kesalahan tidak boleh dihilangkan.

Menangani Pesan tanpa Langganan

BizTalk Server tidak menerima pesan untuk diterbitkan dalam database MessageBox-nya jika tidak ada langganan yang ditentukan untuk menerimanya. Langganan didaftarkan oleh orkestrasi atau port pengiriman. Beberapa langganan dapat ditentukan, dalam hal ini pesan dikirim ke beberapa tujuan. Jika tidak ada langganan, BizTalk Server menolak pesan dan tidak mencoba untuk menangguhkannya. Jika adaptor tidak menangani kesalahan ini dan secara eksplisit menangguhkan pesan, maka pesan dihilangkan dan datanya berpotensi hilang. Tentu saja adaptor transaksi dapat mengakhiri transaksi dan mengembalikan pesan ke tujuannya.

Pencarian Dukungan dengan Aliran Terima Anda

Aliran sisi penerima harus mendukung metode Pencarian untuk BizTalk Server agar dapat menangguhkan pesan pada kegagalan alur. Jika aliran pesan tidak dapat dicari, maka BizTalk Server menghasilkan kesalahan saat mencoba menjalankan Pencarian.

Dalam banyak kasus mendukung Seek tidaklah mudah. Saat streaming data dari jaringan, misalnya, mungkin sulit untuk kembali ke sumber daya jaringan dan meminta data lagi.

Beberapa adaptor yang dikirim dengan BizTalk Server menyimpan data pesan ke file pada disk secara bersamaan saat BizTalk Server membaca data. Ini memungkinkan adaptor untuk menggunakan Pencarian pada file tersebut jika mengalami kesalahan (misalnya dalam pemrosesan alur data pesan). Secara internal adaptor menggunakan kelas ReadOnlySeekableStream yang membungkus aliran masuk yang tidak dapat dicari dan meluap ke disk ketika ambang batas ukuran yang dapat dikonfigurasi tercapai. Untuk pesan yang lebih kecil dari ukuran ambang batas, disk tidak pernah tertembak.

Pertimbangkan Opsi User-Configurable Error-Handling

Terkadang tidak ada respons yang benar terhadap kesalahan. Dalam hal ini, Anda harus mempertimbangkan opsi yang dapat dikonfigurasi pengguna untuk memilih di antara perilaku. Adaptor MQSeries melakukan ini.

Masalah dengan memiliki adaptor menangguhkan pesan ketika melihat kesalahan adalah bahwa antrean Ditangguhkan di BizTalk Server adalah sesuatu dari "lubang hitam." Relatif mudah untuk memasukkan pesan ke dalam antrean, tetapi lebih sulit untuk mengeluarkannya lagi.

Beberapa pengguna adaptor mungkin tidak menginginkan apa pun dalam antrean Ditangguhkan. Misalnya, dalam kasus adaptor MQSeries, pengguna ditawarkan opsi konfigurasi untuk melakukan salah satu hal berikut ini:

• Atur adaptor untuk mengakhiri transaksi saat ini dan nonaktifkan dirinya sendiri saat melihat kesalahan.

• Tangguhkan pesan yang gagal dan terapkan transaksi. Adapter melakukan ini bahkan ketika BizTalk Server telah berhasil menangguhkan pesan. Tindakan ini memenuhi persyaratan pelanggan meskipun menyebabkan log peristiwa tidak benar-benar benar benar.

Menerapkan Urutan Penerimaan dengan Menggunakan Satu Utas dan Menunggu Pada BatchComplete

Antarmuka ke BizTalk Server dirancang untuk performa dan kemampuan untuk meluaskan skala dengan mendukung konkurensi. Namun, jika Anda ingin penerimaan pesan yang diurutkan secara ketat (seperti yang terkadang diperlukan saat menerima pesan dari produk antrean pesan seperti MQSeries atau MSMQ), maka Anda harus melakukan beberapa pekerjaan tambahan di adaptor untuk menonaktifkan beberapa konkurensi tersebut. Ini dapat dilakukan dalam dua langkah:

1. Anda harus menggunakan satu utas untuk semua pemrosesan data dalam adaptor.

2. Anda harus menunggu BizTalk Server memproses setiap batch sepenuhnya. Persyaratan ini penting dan dapat dicapai dengan menggunakan primitif sinkronisasi utas .NET. Misalnya, menggunakan AutoResetEvent, Anda akan:

   • Deklarasikan objek peristiwa tempat objek dapat diakses oleh utas pekerja utama dan objek panggilan balik BatchComplete .

   • Pada utas pekerja utama, kirimkan pesan ke batch seperti biasa tetapi kemudian panggil AutoResetEvent.Reset pada objek peristiwa tepat sebelum panggilan ke batch IBTTransportBatch::D one.

   • Panggil AutoResetEvent.WaitOne pada objek kejadian dari utas yang sama ini. Hal ini menyebabkan utas pekerja utama diblokir. Dalam panggilan balik BatchComplete dari BizTalk Server, Anda kemudian memanggil AutoResetEvent.Set pada objek peristiwa yang sama untuk membuka blokir utas pekerja sehingga siap untuk memproses pesan lain.

   Sangat disarankan bahwa menerima pemesanan seperti ini dibuat dapat dikonfigurasi karena menyebabkan penurunan performa yang signifikan. Banyak, jika tidak sebagian besar, skenario pengguna tidak memerlukan pemesanan pesan. Menangguhkan pesan juga dapat merusak pemesanan. Apa yang harus dilakukan dalam hal ini tergantung pada aplikasi, jadi hal terbaik yang harus dilakukan adapter Anda adalah menawarkan titik konfigurasi kepada pengguna.

   Dalam skenario yang diurutkan, beberapa pelanggan telah menyatakan bahwa mereka lebih suka menghentikan pemrosesan, yaitu, menonaktifkan adaptor, daripada memutuskan pemesanan. Adaptor MQSeries, yang mendukung penerimaan yang diurutkan, menyediakan opsi ini kepada pengguna.

Menangani Kesalahan Batch Send-Specific

Menangani Kirim Coba Lagi dan Batching

Berikut adalah contoh umum batching send-side:

• BizTalk Server memberikan batch pesan ke adaptor.

• Ketika adaptor menentukan bahwa adaptor telah memberikan pesan ke tujuannya dengan benar, adaptor menjalankan penghapusan kembali di BizTalk Server yang menunjukkan bahwa itu dilakukan. (Seperti biasa, beberapa pesan penghapusan dapat di-batch secara sewenang-wenang untuk meningkatkan performa.)

  Jika adaptor sisi kirim gagal memproses pesan, maka dapat melakukan salah satu dari beberapa hal dengan pesan tersebut:

• Adapter harus memberi tahu BizTalk Server bahwa ia ingin pesan dicoba kembali. BizTalk Server tidak secara otomatis mencoba kembali pesan. BizTalk Server menyimpan hitungan percobaan ulang, dan jumlah ini dapat dilihat dalam konteks pesan.

• Adapter dapat menentukan bahwa ia tidak dapat memproses pesan. Dalam hal ini, adaptor mungkin memindahkan pesan ke transportasi berikutnya. Adapter melakukan ini dengan panggilan MoveToNextTransport pada objek Batch .

• Adaptor dapat memindahkan pesan ke antrean Ditangguhkan.

  Adaptor menentukan apa yang terjadi pada pesan. Namun, disarankan agar Anda memiliki adaptor bertingkah konsisten karena ini membuat penginstalan BizTalk Server lebih mudah didukung.

  Sangat disarankan agar adaptor berkinerja seperti yang dijelaskan di bawah ini. Adaptor yang dikirim dengan BizTalk Server berulah seperti ini.

Perilaku yang Direkomendasikan untuk Menangani Kesalahan Kirim dalam Batch

Adaptor pengiriman menerima beberapa pesan dan mengirimkannya ke BizTalk Server.

Untuk setiap pesan yang berhasil, adaptor harus menghapus pesan tersebut di BizTalk Server. Semua komunikasi kembali ke BizTalk Server dilakukan melalui batch, dan penghapusan dapat di-batch. Mereka tidak harus menjadi batch yang sama dengan yang dibuat BizTalk Server pada adaptor. Jika ada pesan respons (seperti dalam skenario SolicitResponse), pesan tersebut harus dikirimkan kembali ke BizTalk Server (dengan SubmitResponse) bersama dengan penghapusan terkait.

• Jika pemrosesan pesan dalam adaptor tidak berhasil, periksa jumlah coba lagi.

  • Jika jumlah coba lagi tidak terlampaui, kirim ulang pesan ke BizTalk Server, ingatlah untuk mengatur waktu coba lagi pada pesan. Konteks pesan menyediakan jumlah coba lagi dan interval coba lagi yang harus digunakan adaptor.

  • Jika jumlah coba lagi terlampaui, maka adaptor harus mencoba memindahkan pesan dengan menggunakan MoveToNextTransport. Pesan kirim ulang dan MoveToNextTransport dapat dicampur dengan penghapusan dalam batch yang sama kembali ke BizTalk Server. Ini tidak diperlukan, tetapi bisa menjadi langkah yang berguna.

• Pengiriman ulang dan MoveToNextTransport adalah cara bagi adaptor untuk menangani kegagalan. Tetapi mungkin ada kegagalan dalam pemrosesan kegagalan. Dalam hal ini, dalam memproses respons dari BizTalk Server (dalam metode BatchComplete ) adaptor harus membuat batch lain terhadap BizTalk Server untuk menunjukkan apa yang harus dilakukan dengan kegagalan tersebut.

  Ikuti langkah-langkah ini saat memproses kegagalan yang terjadi dalam pemrosesan kegagalan lain:

  • Jika pengiriman ulang gagal, gunakan MoveToNextTransport.

  • Jika MoveToNextTransport gagal, gunakan MoveToSuspendQ.

  Anda harus terus membuat batch di BizTalk Server hingga Anda menerima tindakan yang berhasil kembali di BizTalk Server.

Serialisasi Properti Konteks Pesan

Semua objek yang ditetapkan ke properti konteks pesan harus dapat diserialisasikan. Jika tidak, Mesin Olahpesan akan memberikan pengecualian jenis E_NOINTERFACE. Nilai pengembalian ini secara ambigu mewakili objek yang tidak dapat diserialisasikan yang mencoba ditetapkan konteks pesan.