Tips untuk Merancang Adaptor Anda

Bagian ini berisi petunjuk dan tips yang telah dipelajari pengembang adaptor saat merancang adaptor.

Properti Handler Harus Berupa String jika Digunakan sebagai Konfigurasi Default

Tampaknya menarik untuk menggunakan properti pada lembar properti handler yang dihasilkan XSD sebagai default untuk properti Lokasi mereka karena jika nilai tidak diatur di Lokasi runtime secara otomatis menggunakan nilai yang ditetapkan dalam handler. Tetapi ada beberapa masalah yang membuat ini kurang berguna.

Masalahnya muncul dengan tidak mengetahui apakah nilai yang disajikan ke runtime akan ditimpa atau tidak. Cara umum untuk melakukan ini adalah dengan memiliki beberapa gagasan NULL yang ditentukan untuk nilai dan kemudian menjalankan pengujian terhadap nilai tersebut. Masalah saat menggunakan lembar properti berbasis XSD di BizTalk Server adalah bahwa NULL hanya didukung untuk string. Bahkan jika Anda ingin adaptor Anda memiliki pengaturan default melalui penggunaan pengujian NULL ini dan bersedia membatasi adaptor ke jenis string, adaptor masih terekspos ke bagian antarmuka pengguna yang sangat aneh.

Lembar properti yang dihasilkan XSD hanya mendukung pengaturan properti kembali ke NULL dengan mengklik kanan properti, di mana menu konteks nullify? muncul dan properti dapat diatur ke NULL. Tidak ada umpan balik visual tentang apakah properti adalah NULL.

Pertimbangan untuk Menerapkan Wizard Pembuatan Skema

Programmer suka membuat kode terhadap model objek yang ditik dengan kuat. Memanipulasi XML dalam kode pada awalnya dapat tampak canggung dan rentan terhadap kesalahan. Tetapi beberapa trik dan penggunaan cerdas dari dukungan yang ditawarkan oleh .NET Framework dapat menyederhanakan masalah secara dramatis.

Jangan membuat dokumen XML dengan perangkaian string

Salah satu kesalahan terburuk yang harus dilakukan dengan XML adalah mencoba dan menghasilkannya dari perangkaian string dan pernyataan cetak dalam memori. Ini mengonsumsi sejumlah besar waktu dan memori CPU. Bahkan untuk cuplikan XML yang paling sepele, lebih mudah untuk menggunakan alat seperti XmlWriter atau Document Object Model (DOM). Jika Anda menggunakan XmlWriter, jangan gunakan kemampuan tulis mentah, karena penulis kehilangan status dokumen.

Pada durasi, XmlWriter lebih disukai daripada XML DOM karena masalah konsumsi memori tinggi yang terkait dengan DOM. Namun, pada waktu konfigurasi atau desain, kemungkinan besar ini tidak akan menjadi masalah. Menggunakan DOM memfasilitasi penggunaan kueri XPATH, yang dapat menjadi alat tambahan yang berguna.

Pertimbangkan untuk menentukan kerangka dokumen XML Anda sebagai sumber daya

Jika Anda membuat dokumen XML besar dari alat desain dan dokumen yang dihasilkan selalu mengikuti struktur dasar yang sama, pertimbangkan untuk menempatkan seluruh file XML kerangka sebagai sumber daya dalam proyek untuk memungkinkan membuat perubahan saat Anda perlu mengeditnya.

Muat kode ke dalam DOM lalu tambahkan daging yang diperlukan ke tulang dokumen dengan menggunakan XPATH untuk memilih simpul yang ingin Anda tambahkan. Dalam hal ini, Anda membuat file Web Services Description Language (WSDL). Wizard menyimpan file WSDL kerangka dalam sumber daya dan menambahkan bagian turunan Definisi Skema XML (XSD) yang dihasilkan. Ini menggunakan selectNode dengan jalurx untuk menemukan induk yang tepat. Ini adalah kode antarmuka pengguna, sehingga performa tidak menjadi masalah, dan implementasi yang dihasilkan bersih, kuat, dan dapat dipertahankan.

Pertimbangkan Untuk Menempatkan Langkah-Langkah Pemrosesan di Alur BizTalk

Secara umum adaptor yang dibangun di Microsoft memindahkan pemrosesan berbasis format pesan keluar dari adaptor dan ke dalam alur BizTalk. Contoh yang baik adalah adaptor ke sumber data terstruktur tetapi non-XML.

Dalam hal ini, adaptor hanya mendapatkan data dan alur BizTalk digunakan untuk mengurainya dan mengonversinya menjadi XML yang setara. Manfaatnya adalah komponen alur itu sendiri menjadi bagian arsitektur yang dapat digunakan kembali.

Membuat Perilaku Adapter Dapat Dikonfigurasi

Salah satu pelajaran yang dipelajari dari program beta adaptor MQSeries adalah bahwa tidak semua pelanggan senang dengan perilaku yang sama. Ini terutama berlaku ketika menangani kesalahan dan pemesanan. Solusinya adalah membuat perilaku dapat dikonfigurasi. Anda dapat menentukan apakah adaptor mendukung pemesanan, apakah kegagalan dipindahkan ke antrean Ditangguhkan, atau apakah itu menyebabkan adaptor berhenti memproses dan menonaktifkan dirinya sendiri. Membuat perilaku tersebut dapat dikonfigurasi dapat secara signifikan menyederhanakan kehidupan pelanggan ketika mereka perlu menulis orkestrasi atau skrip kompleks di luar BizTalk Server untuk mencapai hasil yang sama.

Mendukung Korelasi dengan Antrean Pesan

Banyak platform olahpesan mendukung gagasan ID korelasi di header pesan untuk mendukung skenario respons permintaan tingkat aplikasi. Contohnya termasuk MQSeries, MSMQ, dan SQL Service Broker. Tampaknya akan menarik untuk memetakan pola permintaan-respons dari sistem olahpesan eksternal ke adaptor kirim-respons di BizTalk Server. Namun ini tidak masuk akal karena di mana transaksi berada. Secara khusus, pengiriman ke sistem olahpesan eksternal memerlukan penerapan transaksi sebelum ujung antrean lainnya melihat data. Penerimaan juga harus merupakan transaksi terpisah.

Solusi di BizTalk Server adalah untuk:

• Menggunakan set korelasi dalam orkestrasi

• Mengonfigurasi dua port terpisah: satu untuk kirim dan satu untuk penerimaan

  Dalam kasus sederhana, orkestrasi menentukan ID korelasi yang terkait dengan pesan oleh adaptor. Ini diteruskan ke adaptor sebagai properti konteks pada pesan. Dalam kasus yang lebih kompleks, skenario meminta sistem olahpesan eksternal untuk mengalokasikan ID. Dalam hal ini dapat diteruskan kembali dari port kirim ke orkestrasi dengan pesan respons. Pesan respons ini hanya untuk meneruskan kembali ID dan bukan respons pesan yang sebenarnya.