Memproses Pesan
Semua komponen yang dijelaskan sejauh ini berperan dalam pemrosesan pesan saat mengalir melalui BizTalk Server. Bagian ini memberikan detail selengkapnya tentang bagaimana komponen-komponen ini berinteraksi secara fungsional, dimulai dengan menerima pesan. Gambar berikut menunjukkan make-up port penerima dan alur pesan melalui proses penerimaan.
Port penerima terdiri dari satu atau beberapa lokasi penerima dan nol atau lebih peta. Peta adalah lembar gaya Extensible Stylesheet Language Transformations (XSLT) yang digunakan untuk mengubah pesan XML dari satu struktur atau format ke struktur lain dan sering digunakan dalam proses penerimaan untuk menormalkan pesan menjadi format internal. Lokasi penerima mengontrol titik akhir yang menerima pesan. Lokasi terima terdiri dari konfigurasi titik akhir untuk adaptor penerima, dan alur penerima.
pemrosesan
Peran Adapter
Adaptor penerima memulai proses penerimaan pesan dengan membaca aliran data dan membuat pesan. Misalnya, adaptor file melihat bahwa file telah ditempatkan di lokasi yang dikonfigurasi dan membaca file tersebut dalam aliran. Adaptor membuat pesan (implementasi antarmuka Microsoft.BizTalk.Message.Interop.IBaseMessage), menambahkan bagian ke dalamnya (implementasi antarmuka Microsoft.BizTalk.Message.Interop.IBasePart), dan menyediakan aliran data sebagai konten bagian.
Selain itu, adaptor menulis dan mempromosikan ke dalam properti konteks pesan yang terkait dengan lokasi, jenis adaptor, dan lainnya yang terkait dengan adaptor. Setelah pesan dan konteksnya dibuat, adaptor meneruskan pesan ke Endpoint Manager. Pesan kemudian diproses melalui alur penerima, yang telah dikonfigurasi untuk lokasi penerima. Setelah pesan diproses oleh alur, peta dapat digunakan untuk mengubah pesan menjadi format yang diinginkan sebelum Endpoint Manager menerbitkan pesan dengan Agen Pesan.
Peran Alur
Meskipun adaptor adalah adaptor yang membuat pesan awal, sebagian besar pemrosesan yang terjadi pada pesan yang diterima terjadi di alur penerima. Pemrosesan alur berkaitan dengan konten pesan serta konteks pesan. Konten pesan umumnya ditangani dalam tahap pendekodean, pembongkaran, dan validasi, sementara konteks pesan dapat ditangani di semua tahap. Namun, alur tidak selalu bertindak pada konten atau konteks. Misalnya, alur pass-through default tidak memiliki komponen yang dikonfigurasi dan tidak melakukan pemrosesan pada konten atau konteks pesan. Untuk kesederhanaan, dokumen ini berfokus pada komponen pembongkaran karena umumnya berdampak terbesar pada perutean pesan.
Pekerjaan pembongkar adalah memproses pesan masuk dari adaptor dan membongkarnya ke dalam banyak pesan, dan mengurai data pesan. Ketika pesan masuk memiliki banyak pesan yang lebih kecil, ini dikenal sebagai pertukaran. Pembongkar file datar dan pembongkar XML menangani pertukaran dengan memungkinkan pengembang untuk mengonfigurasi informasi tentang konten pembungkusan (yaitu, skema header dan trailing untuk pembongkar file datar dan skema amplop untuk pembongkar XML) dan konten isi (berpotensi berulang). Selain itu, kedua pembbongkar ini mengurai pesan asli ke dalam konten XML. Pemisah kustom tidak selalu mengurai konten ke dalam XML jika pemrosesan XML lebih lanjut di BizTalk Server tidak diperlukan. Contoh skenario mungkin mencakup situasi perutean sederhana di mana pesan yang memasuki sistem di lokasi penerimaan tertentu dikirim ke port pengiriman tertentu tanpa pemetaan atau pemrosesan berbasis XML lainnya.
Perutean dengan Jenis Pesan
Salah satu properti pesan paling umum yang digunakan dalam perutean adalah jenis pesan. Saat pengembang membuat skema untuk menentukan struktur pesan, skema ini menentukan jenis pesan untuk pesan tersebut. Jenis ditentukan oleh simpul akar dan namespace layanan dalam definisi skema. Misalnya, dokumen XML yang terlihat seperti berikut ini akan memiliki jenis pesan http://tempuri.org/samples/MessageType#Message
<Message xmlns=http://tempuri.org/samples/MessageType>
<SomeOtherElement type="sample"/>
</Message>
Untuk menggunakan jenis pesan dalam perutean, pesan harus dipromosikan ke dalam konteks. Pembakaran digunakan untuk mempromosikan nilai ini ke dalam konteks pesan serta komponen alur dengan pengetahuan struktur pesan yang paling spesifik. Pembbongkar XML dan File Datar mempromosikan jenis pesan saat memproses pesan, dan setiap pemisah kustom juga harus mempromosikan properti ini untuk memastikan perutean yang tepat.
Penting untuk dicatat bahwa pesan tidak diperlukan untuk memiliki jenis. Seperti disebutkan sebelumnya, bagian-bagian pesan dapat berupa data biner apa pun dan tidak perlu memiliki skema yang mendefinisikan strukturnya. Jenis bagian pesan ini umumnya diteruskan melalui BizTalk Server tanpa banyak, jika ada, pemrosesan yang dilakukan di atasnya oleh BizTalk Server itu sendiri, meskipun komponen alur kustom, adaptor, atau kode yang disebut dari orkestrasi dapat berinteraksi dengan bagian-bagian ini.
Komponen alur, seperti adaptor, juga menulis dan mempromosikan properti ke dalam konteks pesan. Bahkan, komponen alur adalah mekanisme paling umum yang digunakan sebagian besar pengembang untuk mendapatkan properti ke dalam konteks pesan. Pengembang membuat skema dan dapat mempromosikan properti dalam skema. Informasi ini disimpan dalam skema sebagai anotasi yang kemudian dapat digunakan oleh komponen alur. Semua komponen pemisah dan perakitan bawaan - FlatFile, XML, dan BizTalk Framework - gunakan skema dokumen untuk mengambil informasi tentang properti yang akan dipromosikan. Dengan menggunakan pernyataan Xml Path Language (XPath) dari anotasi, pemisah mengetahui lokasi dalam dokumen elemen yang akan dipromosikan. Selama proses streaming melalui dokumen, pembakaran menemukan elemen-elemen yang cocok dengan salah satu pernyataan JalurX dan mempromosikan atau menulis nilai ke dalam konteks yang sesuai.
Komponen alur kustom juga dapat ditulis untuk menangani mendapatkan properti ke dalam konteks untuk data arbitrer dalam pesan yang diterima atau dikirim. Untuk mempromosikan properti ke dalam konteks dan membuatnya berguna untuk perutean, yang mungkin mengapa nilai dipromosikan, skema properti dengan definisi untuk properti harus dibuat dan disebarkan ke BizTalk Server. Sebelum Anda menentukan skema properti yang akan digunakan oleh komponen kustom, Anda harus memahami berbagai jenis properti yang dipromosikan. Properti yang dipromosikan yang ditentukan dalam skema properti dapat memiliki salah satu dari dua jenis dasar:
Microsoft.XLANGs.BaseTypes.MessageDataPropertyBase
Properti dengan jenis dasar MessageDataPropertyBase menunjukkan bahwa nilai untuk properti ini berasal dari konten pesan. Ini adalah nilai default untuk properti yang ditentukan dalam skema properti dan merupakan penggunaan yang paling umum. MessageContextPropertyBase menunjukkan properti yang dimaksudkan untuk menjadi bagian dari konteks pesan tetapi tidak selalu berasal dari data pesan secara langsung. Properti dengan MessageContextPropertyBase sebagai jenis dasarnya sering dipromosikan oleh adaptor dan pembongkar dan menyertakan properti umum seperti jenis pesan dan jenis adaptor.
Penting untuk memahami berbagai jenis dan menggunakannya dengan tepat saat menentukan properti. Salah satu implikasi paling signifikan terjadi saat mengakses properti konteks untuk pesan dalam orkestrasi. Jika properti diidentifikasi sebagai MessageDataPropertyBase, Orkestrasi Designer memeriksa skema pesan yang diterima dan memastikan bahwa itu mendefinisikan properti yang dipromosikan yang cocok. Jika tidak ada properti yang ditemukan dalam skema yang terkait dengan properti yang dipromosikan yang diakses, maka Designer tidak memungkinkan Anda untuk mengaksesnya. Di sisi lain, jika properti didefinisikan sebagai MessageContextPropertyBase, jenis pesan tidak masalah dan properti dapat diakses.
Dalam alur kustom, mekanisme untuk mempromosikan atau menulis properti ke konteks sangat mirip. Untuk menulis properti, Anda menggunakan panggilan ke metode IBaseMessageContext Write untuk menempatkan nilai dalam konteks. Untuk properti yang dipromosikan, Anda cukup menggunakan metode IBaseMessageContext Promote sebagai gantinya. Masing-masing metode ini mengambil nama properti, namespace layanan, dan nilai. Untuk properti yang dipromosikan, nama dan namespace adalah properti yang ditentukan dalam skema properti dan paling mudah diakses dengan mereferensikan perakitan skema properti dan menggunakan properti pada kelas yang dibuat untuk properti. Bidang yang dibedakan menggunakan namespace umum,
http://schemas.microsoft.com/BizTalk/2003/btsDistinguishedFields, dan ekspresi JalurX yang digunakan untuk mengambil nilai biasanya digunakan sebagai nama.Kode di bawah ini menunjukkan contoh mempromosikan dan menulis properti ke dalam konteks. Perhatikan bahwa dalam contoh ini, bidang khusus sedang ditulis ke dalam konteks. Ini hanya berguna untuk orkestrasi di mana skema pesan mengidentifikasi bidang khusus sehingga Orkestrasi Designer tahu tentang bidang . Mungkin berguna untuk menulis properti ke dalam konteks untuk digunakan oleh komponen alur lain di sisi penerima atau pengiriman.
//create an instance of the property to be promoted
SOAP.MethodName methodName = new SOAP.MethodName();
//call the promote method on the context using the property class for name
//and namespace
pInMsg.Context.Promote(methodName.Name.Name, methodName.Name.Namespace,
"theSOAPMethodName");
//write a distinguished field to the context
pInMsg.Context.Write("theDistinguishedProperty",
"http://schemas.microsoft.com/BizTalk/2003/btsDistinguishedFields",
"theDistinguishedValue");
Ingatlah fakta berikut saat menulis atau mempromosikan nilai ke dalam konteks:
Menulis nilai ke dalam konteks dengan nama dan namespace yang sama yang digunakan sebelumnya untuk mempromosikan properti menyebabkan properti tersebut tidak lagi dipromosikan. Tulisan pada dasarnya menimpa promosi.
Menulis nilai null ke dalam konteks akan menghapus nilai, karena properti bernilai null tidak diizinkan.
Panjang properti yang dipromosikan dibatasi hingga 256 karakter sementara properti tertulis tidak memiliki batasan panjang.
Properti yang dipromosikan digunakan dalam perutean pesan dan berukuran terbatas untuk alasan efisiensi dalam perbandingan dan penyimpanan. Meskipun properti tertulis tidak memiliki batasan ukuran yang keras, menggunakan nilai yang terlalu besar dalam konteks akan berdampak pada performa, karena nilai-nilai tersebut masih harus diproses dan diteruskan dengan pesan.
Ketika pesan siap dikirim dari BizTalk Server, pesan akan menjalani proses pelengkap di port pengiriman. Peta diterapkan ke pesan sebelum alur pengiriman dijalankan, memungkinkan pesan diubah menjadi format khusus pelanggan atau aplikasi sebelum diproses oleh alur dan dikirim melalui adaptor. Dalam alur kirim, alih-alih mempromosikan properti ke dalam konteks pesan, properti diturunkan dari konteks ke dalam pesan.
Lihat juga
Arsitektur Runtime
Cara BizTalk Server Memproses Pesan Besar