Catatan
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba masuk atau mengubah direktori.
Akses ke halaman ini memerlukan otorisasi. Anda dapat mencoba mengubah direktori.
BizTalk Server, pada intinya, mesin penanganan pesan. Untuk memahami detail BizTalk Server, penting untuk memahami pesan dan bagaimana pesan diwakili, disimpan, dan diproses oleh BizTalk Server. Detail tentang cara kerja BizTalk Server dengan pesan menjadi lebih mudah dipahami setelah Anda mendapatkan pemahaman tentang apa itu pesan.
Setiap pesan di BizTalk Server dianggap sebagai pesan multi-bagian dan terdiri dari nol bagian atau lebih. Setiap pesan dengan satu atau beberapa bagian memiliki salah satu bagian ini yang diidentifikasi sebagai bagian tubuh. Setiap bagian terdiri dari potongan data biner yang dapat mewakili dokumen XML, file datar, kelas .NET berseri, atau aliran data biner lainnya. Anda menggunakan bagian isi pesan untuk mengidentifikasi jenis pesan yang dapat digunakan untuk perutean.
Konsep yang sangat penting untuk dipahami adalah bahwa semua pesan tidak dapat diubah di BizTalk Server. Ini berarti bahwa setelah pesan dibuat, pesan tidak dapat diubah. Pesan dianggap dibuat setelah ditempatkan ke dalam database MessageBox. Setiap perubahan pada pesan mengharuskan pesan baru dibuat dan digunakan dari titik tersebut ke depan. Ini sangat jelas dalam Designer Orkestrasi, di mana aturan kompilasi memaksa Anda untuk mengikuti pedoman ketat tentang membuat pesan sebelum menggunakannya, dan tidak mengizinkan pesan diubah di luar blok konstruksinya. Jika Anda perlu mengubah pesan, Anda harus membuat blok konstruksi baru yang membuat pesan dengan jenis yang sama, menyalin pesan asli ke pesan baru, lalu membuat perubahan apa pun pada pesan baru sebelum meninggalkan blok konstruksi.
Properti Pesan
Selain bagian-bagian yang membentuk pesan, setiap pesan dalam sistem memiliki sekumpulan properti yang sesuai dengannya dalam apa yang dikenal sebagai konteks pesan. Properti ini dapat berupa nilai yang diekstrak dari atau terkait dengan pesan itu sendiri. Misalnya, adaptor menempatkan properti ke dalam konteks yang terkait dengan penerimaan pesan, seperti lokasi di mana pesan diterima, dan jenis adaptor yang digunakan untuk menerima pesan. Properti dapat ditulis ke konteks, atau dipromosikan ke dalam konteks. Perbedaan antara kedua opsi ini adalah bahwa properti yang dipromosikan dapat digunakan sebagai kriteria dalam perutean pesan sementara properti tertulis tidak dapat.
Konsep menulis atau mempromosikan nilai ke konteks ini terkait dengan, tetapi tidak sama dengan, mempromosikan properti di Editor BizTalk. Di Editor BizTalk, elemen atau atribut dalam skema dapat ditandai sebagai properti yang dipromosikan atau bidang khusus. Item yang ditandai dengan anotasi PropertyField dalam skema pesan Anda akan menyebabkan pembakaran alur menempatkan properti Yang Dipromosikan dalam konteks. Item yang ditandai dengan anotasi DistinguishedField dalam skema pesan Anda akan menyebabkan pembakaran alur menempatkan properti Tertulis ke dalam konteks.
Desain untuk properti yang dipromosikan dimulai dengan desain korelasi pesan: kemampuan untuk menghubungkan pesan yang diterima ke instans orkestrasi yang sudah berjalan. Untuk korelasi, ada kebutuhan untuk menentukan properti atau sekumpulan properti yang menyediakan tautan antara pesan dalam orkestrasi. Misalnya, dalam proses pembelian, Anda perlu menghubungkan pesan berdasarkan PurchaseOrderID. Namun, dalam banyak kasus bisnis, nama bidang atau atribut tertentu dalam pesan mungkin tidak cocok. Skema pesanan pembelian mungkin memiliki elemen bernama POId, sementara skema faktur pendamping mungkin memiliki elemen bernama OrderID. Untuk menghubungkan pesan pada properti bernama seperti PurchaseOrderID dalam situasi ini, pengembang harus dapat mengabstraksi nama properti yang akan dikorelasikan dari sumber nilai. Skema properti mendukung abstraksi ini.
Skema properti memungkinkan Anda menentukan properti yang dipromosikan di lokasi umum dan membuatnya dirujuk oleh skema lain. Seperti skema lain, skema properti memiliki namespace, tetapi tidak seperti skema lain, skema hanya dapat memiliki elemen yang ditentukan (yaitu, bukan rekaman atau atribut). Setiap elemen yang didefinisikan dalam skema properti memiliki nama dan jenis. Karena skema properti mungkin perlu direferensikan oleh lebih dari satu skema, dan karena informasi dalam skema properti harus tersedia untuk komponen saat runtime, skema properti harus disebarkan ke BizTalk Server seperti semua skema lainnya. Selain langkah-langkah penyebaran skema normal, informasi tentang properti yang dipromosikan diekstrak dan disimpan dalam tabel bt_documentSpec dalam database Manajemen.
Setelah skema properti dibuat, elemen dan atribut dengan jenis yang sama (misalnya. bilangan bulat) dapat dipromosikan sebagai salah satu properti bernama dalam skema properti.
Untuk menyelesaikan contoh kasus dari atas, pengembang akan melakukan langkah-langkah berikut untuk menentukan properti bersama yang diperlukan untuk korelasi.
Buat skema properti dan tentukan elemen jenis xs:int bernama PurchaseOrderId.
Buat skema PurchaseOrder dan tambahkan elemen atau atribut jenis xs:int bernama POId.
Menggunakan perintah tampilkan promosi di Editor BizTalk, pengembang menambahkan bidang POId ke daftar properti yang dipromosikan dan menunjukkan bahwa itu harus dipromosikan sebagai properti PurchaseOrderId yang ditentukan dalam skema properti dengan memilih properti PurchaseOrderId bernama dari daftar.
Buat skema Faktur dan tambahkan elemen atau atribut jenis xs:int bernama OrderId.
Menggunakan perintah tampilkan promosi di Editor BizTalk, pengembang menambahkan bidang OrderId ke daftar properti yang dipromosikan dan menunjukkan bahwa itu harus dipromosikan sebagai properti PurchaseOrderId yang ditentukan dalam skema properti dengan memilih properti PurchaseOrderId bernama dari daftar.
Sekarang setelah definisi ini ada dalam skema dokumen, komponen alur dapat mempromosikan OrderId dan POId dengan benar sebagai properti bernama PurchaseOrderID sehingga dapat digunakan untuk perutean dan korelasi. Untuk detail selengkapnya tentang proses promosi ini, lihat topik "Pemrosesan Pesan" dalam dokumen ini.
Salah satu manfaat properti yang dipromosikan adalah bahwa nilai elemen yang dipromosikan tersedia dalam konteks pesan. Ini berarti bahwa mengambil nilai tersebut murah, karena tidak memerlukan pemuatan pesan ke dalam memori untuk menjalankan pernyataan JalurX pada pesan. Sebagai gantinya, tas properti sederhana dapat digunakan bersama dengan kunci untuk mendapatkan nilainya. Jenis perilaku ini diinginkan dalam situasi selain perutean pesan dan merupakan alasan untuk membuat bidang khusus. Sementara properti yang dipromosikan dipromosikan ke dalam konteks pesan, bidang khusus ditulis ke dalam konteks pesan. Namun tidak seperti properti yang dipromosikan, tidak ada skema properti untuk bidang khusus. Inilah sebabnya mengapa bidang khusus tidak dapat digunakan untuk perutean dan oleh karena itu tidak tersedia sebagai kriteria filter dalam port kirim atau orkestrasi menerima bentuk. Namun, bidang yang dibedakan dapat digunakan dalam orkestrasi untuk membaca atau menulis nilai dari konteks pesan alih-alih harus memuat pesan ke dalam memori dan mengekstrak nilai.
Selain mempromosikan atau menulis properti ke dalam konteks pesan, predikat pesan juga dapat ditambahkan ke konteks. Predikat pesan digunakan sebagai ukuran keamanan di BizTalk Server dan memberikan informasi kontekstual tentang pesan, yang harus cocok dengan nilai yang ditentukan untuk host mana pun yang akan dirutekan pesan. Langkah keamanan ini memungkinkan Anda untuk mengonfigurasi lingkungan BizTalk Server sewaktu-waktu memungkinkan host tertentu menjadi satu-satunya host yang dapat menerima dan memproses pesan tertentu. Sebagai contoh, di BizTalk Server Administration Console, host dapat dikonfigurasi dengan thumbprint sertifikat yang akan digunakan untuk pendekodean dan dekripsi pesan. Mengonfigurasi properti ini membuat properti aplikasi untuk host tersebut di MessageBox. Pesan aman yang diterima dan didekripsi menggunakan thumbprint ini kemudian hanya dirutekan ke host dengan thumbprint yang dikonfigurasi.