Pesan
Pesan Enterprise Message Service (EMS), seperti pesan JMS, berisi tiga bagian terpisah: header, properti, dan isi. Header adalah satu-satunya bagian yang diperlukan dari pesan EMS. Topik ini menjelaskan bagaimana pesan diperlakukan di Microsoft BizTalk Adapter untuk Layanan Pesan Perusahaan TIBCO.
Catatan
Untuk mengatur atau mengambil bidang header (misalnya, atur Prioritas Pesan atau ID Korelasi) atau properti pesan dari orkestrasi, Anda harus menambahkan referensi ke Microsoft.BizTalk.Adapters.TIBCOEMSProperties.dll dalam proyek Anda menggunakan Penjelajah Solusi.
Header pesan berisi serangkaian bidang yang telah ditentukan sebelumnya yang berisi nilai. BizTalk Adapter untuk TIBCO Enterprise Message Service tahu apa yang dapat dan tidak dapat diatur di header. Jika Anda mencoba mengatur nilai baca-saja, adaptor mengalihkan atau mengatur nilai Anda di bagian Properti{} .
Dalam contoh berikut, perhatikan bahwa Properties= { Destination={String:Queue[Q2]} }. Properties
adalah properti yang berisi string, dan konten string adalah Q2. Ini tidak ada hubungannya dengan bagian Tujuan; ini berisi string nilai yang Anda tetapkan yang tidak dapat pergi ke tempat lain, sehingga adaptor telah menahannya di sini di bagian ini.
Properti ReplyTo
dapat diatur dalam orkestrasi untuk memberi tahu konsumen akhirnya tempat mengirim respons. EMS mengatur Destination
properti saat pesan diterima dari TIBCOEMS. Properti kedua ini baca-saja di orkestrasi yang menerima pesan dari TIBCOEMS dan tidak dapat diedit dalam orkestrasi.
Misalnya, orkestrasi tidak dapat mengirimkan pesan dan mengatur tujuan secara dinamis di dalam orkestrasi. Nilai Tujuan diatur oleh port tempat pesan dikirimkan.
Jika Anda ingin mengirim pesan ke antrean yang berbeda, Anda harus membuat port pengiriman untuk setiap antrean. Orkestrasi kemudian dapat memutuskan port mana yang akan ditetapkan pesan.
Dalam contoh pesan berikut, Destination= {Queue[Q1]}
bersifat baca-saja. Nilai ini diatur oleh TIBCOEMS ketika server menerima pesan. Nilai untuk Tujuan, Q1, berasal dari Properti Transportasi.
TextMessage={
Header={ MessageID={ID:EMS-SERVER.824437A58B11C75F4:1}
Destination={Queue[Q1]}
' This is READONLY. It gets set by the server when the
' message is received by the server (EMS). It is set in the
' Transport Properties when you specify that you want to
' listen for messages on Q1.
ReplyTo={}
DeliveryMode={Persistent}
Redelivered={False}
CorrelationID={}
MsgType={}
Timestamp={12/1/2005 11:59:01 PM}
Expiration={0}
Priority={1} }
Properties={ Destination={String:Queue[Q2]} }
' This is a property that contains a string, and the
' contents of the string is Q2. This has nothing to do with
' the Destination section above – it is just another
' property that is set.
' This is in the schema. The adapter knows what it can and
' cannot set in an EMS header. The values that the adapter
' cannot set are put in the Properties section.
text={<?xml version="1.0" encoding="utf-16"?>
<ns0:Employees xmlns:ns0="http://BizTalk_Server_Project1.Employee">
<Emp Id="Id_0">
Name>Name_0</Name>
</Emp>
</ns0:Employees>
}
Header berisi serangkaian bidang yang telah ditentukan sebelumnya yang berisi nilai, yang dipromosikan adaptor ke konteks pesan BizTalk Server untuk digunakan dalam orkestrasi. Properti yang dipromosikan identik dalam definisi properti header standar seperti yang ditentukan oleh spesifikasi JMS dan ekstensi TIBCO Enterprise Message Service. Semua properti kecuali untuk dua tersedia untuk orkestrasi seperti yang diterima dari EMS: Destination
dan ReplyTo
menjelaskan tujuan yang tidak dapat dipetakan dengan benar untuk digunakan dalam orkestrasi sebagai properti tunggal.
Adaptor BizTalk untuk TIBCO EMS memetakan properti TIBCOEMS ke jenis string dan menggunakan representasi string Tujuan. Ini terlihat seperti StaticQueue[queuename]
atau StatisTopic[topicname]
. Orkestrasi dapat mengatur nilai untuk ReplyTo
, dan adaptor menggantinya dengan objek tujuan yang valid di header.
Adaptor menyediakan skema dan rakitan referensi yang menjelaskan semua properti header TIBCO EMS yang dapat digunakan oleh orkestrasi. Properti ini dapat digunakan untuk memfilter pesan masuk atau untuk ditambahkan ke pesan keluar. Aturan yang mengatur filter orkestrasi berbeda dari aturan untuk pemilih pesan untuk server EMS. Misalnya, orkestrasi dapat memfilter pada TibcoEMS.ReplyTo
properti atau TibcoEMS.Destination
, tetapi tidak ada dukungan dalam spesifikasi JMS untuk mengizinkan pemilih pesan pada properti yang sama ini.
Ketika properti ini ditentukan oleh orkestrasi, properti tersebut disertakan dalam properti header pesan JMS. Atau, ketika pesan EMS diterima, properti header ini disalin ke konteks pesan BizTalk Server.
Saat properti cocok dengan konfigurasi port, nilai properti pada pesan lebih diutamakan pada konfigurasi port. Misalnya, jika prioritas diatur ke 4 di port, tetapi Anda mengatur prioritas pesan ke 9 dalam logika orkestrasi, pesan diterima oleh TIBCO EMS sebagai memiliki prioritas 9.
Tabel berikut ini menjelaskan bagaimana setiap properti digunakan oleh BizTalk Adapter untuk Layanan Pesan Perusahaan TIBCO.
Nama | Jenis | Deskripsi |
---|---|---|
TibcoEMS.MessageID | string | Mengirim panggilan menetapkan ID unik ke setiap pesan dan merekamnya di header. Semua nilai ID pesan dimulai dengan ID awalan tiga karakter (yang dicadangkan untuk tujuan ini). Baca-saja. Mengubah nilai tidak memengaruhi pesan. |
TibcoEMS.Timestamp | long | Mengirim panggilan merekam tanda waktu UTC di header. Ini menunjukkan perkiraan waktu server menerima pesan. Nilainya dalam milidetik sejak 1 Januari 1970 Baca-saja. Mengubah nilai tidak memengaruhi pesan. |
TibcoEMS.Redelivered | boolean | Server mengatur header untuk menunjukkan apakah pesan mungkin menduplikasi pesan yang dikirim sebelumnya: - false—Server sebelumnya belum mencoba mengirimkan pesan ini kepada konsumen. - true—Kemungkinan, tetapi tidak dijamin, bahwa server sebelumnya telah mencoba mengirimkan pesan ini kepada konsumen, tetapi konsumen tidak mengembalikan pengakuan tepat waktu. Baca-saja. Mengubah nilai tidak memengaruhi pesan. |
TibcoEMS.Destination | string | Mengirim panggilan merekam tujuan (antrean atau topik) pesan di header ini. Format diadaptasi dari tujuan ke string. Format sebelumnya dijelaskan. Baca-saja. Mengubah nilai tidak memengaruhi pesan. |
TibcoEMS.DeliveryMode | string | Memiliki dua nilai yang mungkin: PERSISTEN dan NON-PERSISTENT. Nilai default adalah mode PERSISTEN. Adaptor menunggu pengakuan dari server EMS sebelum mengakui pesan yang dikirim ke BizTalk Server. Item konfigurasi properti header dan port ini mengontrol waktu yang diperlukan EMS untuk mengirim pengakuan ini ke adaptor dan mengontrol keandalan transmisi pesan. Menggunakan mode pengiriman PERSISTEN—server EMS menunggu hingga pesan berhasil bertahan di server EMS. Tindakan ini menjamin bahwa pesan telah tiba dalam antrean. Saat Anda menggunakan pengiriman mode PERSISTEN, pertimbangkan hal berikut: Semakin besar pesan, semakin lama waktu yang dibutuhkan BizTalk Server untuk mempertimbangkan pesan seperti yang dikirim. Menggunakan mode NON-PERSISTENT—server EMS mengembalikan pengakuan sebelum mempertahankan pesan. Jika kegagalan terjadi dengan server EMS, pesan mungkin hilang ketika dianggap berhasil dikirim oleh BizTalk Server. |
TibcoEMS.Expiration | long | Lama waktu pesan akan hidup sebelum kedaluwarsa. Jika diatur ke 0, pesan tidak kedaluwarsa. Waktu hidup ditentukan dalam milidetik. |
TibcoEMS.Priority | int | Menggunakan peringkat numerik, antara 0 dan 9, untuk menentukan prioritas pesan seperti biasa atau dipercepat. Angka yang lebih besar mewakili prioritas yang lebih tinggi. |
TibcoEMS.CorrolationID | string | Dapat digunakan untuk menautkan pesan, seperti menautkan pesan respons ke pesan permintaan. Biasanya ini adalah nilai yang sama dengan EMS.JMSMessageID . Ini biasanya digunakan bersama dengan EMS.JMSReplyTo properti . |
TibcoEMS.ReplyTo | string | Tujuan yang harus dikirimi balasan pesan. Format identik dengan EMS.JMSDestination dan juga konfigurasi port. |
TibcoEMS.Type | string | Tidak menjelaskan jenis pesan (teks, byte, string ...). Beberapa penyedia JMS menggunakan repositori pesan untuk menyimpan definisi jenis pesan. Program klien dapat menyimpan nilai di bidang ini untuk mereferensikan definisi dalam repositori. EMS mendukung header ini tetapi tidak menggunakannya. Spesifikasi JMS tidak menentukan repositori definisi pesan standar, juga tidak menentukan kebijakan penamaan untuk definisi jenis pesan. Beberapa penyedia memerlukan definisi jenis pesan untuk setiap pesan aplikasi. Untuk menjamin kompatibilitas dengan penyedia tersebut, program klien dapat mengatur header ini, bahkan jika aplikasi klien tidak menggunakannya. Untuk menjamin portabilitas, klien dapat mengatur header ini dengan nilai simbolis (bukan harfiah), dan mengonfigurasinya agar sesuai dengan repositori penyedia. |
Integrator dapat menentukan sekumpulan properti untuk dipromosikan ke konteks pesan BizTalk Server, setelah itu properti ditambahkan ke bagian properti pesan JMS. Integrator berhati-hati saat menentukan jenis properti saat membuat skema. Jika nilai properti ini digunakan dalam pemilih pesan, operasi tertentu valid tergantung pada jenis properti. Misalnya, jika pemilih pesan myMessageProperty > 5 digunakan, properti harus didefinisikan sebagai nilai bilangan bulat, dan adaptor menempatkan nilai dalam pesan sebagai nilai bilangan bulat. Agar properti dipromosikan, nama properti harus dimulai dengan EMSX. Mereka juga tidak boleh memiliki nama yang sama dengan properti yang telah ditentukan sebelumnya.
BizTalk Adapter for TIBCO Enterprise Message Service menyediakan skema dan assembly, yang mendeklarasikan properti khusus EMS dan JMS yang dapat muncul di bagian ini. Ini dapat ditambah untuk menyertakan kelalaian apa pun. Semua properti EMSX yang dirujuk dalam konteks pesan dimasukkan ke bagian properti pesan dari pesan EMS. Untuk informasi selengkapnya, lihat Panduan Pengguna TIBCO EMS.
EMS mendukung semua pesan yang dijumlahkan dalam spesifikasi JMS: teks, byte, streaming, peta, dan objek. Adapter BizTalk untuk TIBCO EMS hanya mendukung jenis pesan teks.
JMS tidak mengharuskan pesan jenis teks berisi isi berformat XML. Adaptor tidak memproses isi pesan; ini disediakan untuk BizTalk Server seperti yang diterima. Oleh karena itu, pesan yang dikirimkan ke BizTalk oleh adaptor mungkin tidak selalu diurai sebagai data XML.
Pesan dapat dipertahankan di server EMS untuk menjamin pengiriman tepat satu kali kepada pelanggan; namun, ini dapat berdampak signifikan pada performa adaptor. Saat Anda mengirim pesan, EMS menyimpan pesan di penyimpanan lokal sebelum mengakui penerimaan pesan ke adaptor. Anda dapat mengatur properti ini berdasarkan per pesan dalam orkestrasi atau untuk semua pesan yang diproses oleh port.
Dari aspek penerimaan, adaptor dapat melewatkan pesan ketika tidak berlangganan topik. Pesan yang diposting ke topik ketika tidak ada langganan yang tidak dipertahankan oleh EMS. Adaptor membutuhkan mekanisme untuk menerima posting pesan bahkan ketika saat ini tidak berlangganan; namun, seperti penggunaan pesan persisten, ini memiliki dampak signifikan pada performa EMS, dan tidak selalu diperlukan.
Catatan
Ada mekanisme untuk menerima dari sudut pandang EMS, tetapi tidak diimplementasikan, juga tidak benar-benar diinginkan. Ini hanya masalah dengan topik; antrean tidak terpengaruh. Topik umumnya digunakan untuk data khusus waktu -- tanda kutip saham, misalnya. Jika harga saham terlewat, Anda tahu bahwa itu akan diposting lagi nanti.
Untuk alasan ini, konfigurasi port memungkinkan Anda mengaktifkan atau menonaktifkan persistensi pesan di server EMS.
BizTalk Adapter untuk Layanan Pesan Perusahaan TIBCO selalu mengakui penerimaan pesan ketika pesan tersebut dikirim dengan benar ke BizTalk Server. Ini berarti bahwa pesan yang tidak diakui dikirimkan kembali dari EMS ke adaptor. Adapter tidak dapat mengontrol berapa kali pesan dikirim kembali oleh EMS karena ini adalah konfigurasi tujuan itu sendiri; namun, adaptor dapat mengontrol apakah pesan dikirim ke MessageBox atau tidak. Server EMS mengontrol berapa kali pesan gagal dikirim ke antrean.
Untuk pesan yang dikirim ulang, server EMS mengatur JMSRedelivered
properti ke True dan menaikkan JMSXDeliveryCount
. Kedua nilai properti tersedia untuk orkestrasi. Anda tidak dapat memindahkan pesan ke antrean EMS yang tidak terkirim tanpa mengirimkannya ke sana. Melakukan ini akan mengubah properti pesan.
Ketika pesan mencapai jumlah redelifry maksimum yang dikonfigurasi, server EMS menentukan apakah pesan harus dihapus atau dimasukkan ke antrean $sys.undelivered. Server EMS membuat keputusan berdasarkan JMS_TIBCO_PRESERVE_UNDELIVERED
properti ; jika True, pesan masuk ke antrean yang tidak terkiror, atau dihapus. Properti ini dapat diatur dalam orkestrasi sebelum mengirim pesan. Setelah pengiriman, properti pesan tidak dapat diubah. Pesan yang dikirim ke EMS diakui ke BizTalk Server ketika berhasil. Jika ada kegagalan mengirim tema ke EMS, tema tersebut akan ditangguhkan dan ditandai sebagai dapat diulang.