Geekly articles weekly

Tutorial DataPower

Materi yang ditulis bersama oleh wedmeed


Pada 2017, ketika proyek kami dimulai di Vietnam, kami menemui binatang buas IBM DataPower untuk kami. IBM DataPower adalah produk gerbang antara klien dan backend yang dirancang untuk menyaring, merutekan, memperkaya atau transformasi pesan lainnya yang melewatinya (selanjutnya disebut sebagai permintaan). Itu perlu untuk belajar dengan cepat, tidak ada waktu untuk penumpukan, jadi kami diminta untuk membiasakan diri dengan itu, setelah itu ada berjam-jam konferensi Skype dengan rekan kami dari Moskow, yang menyampaikan kepada kami pengetahuan dan pengalamannya dengan produk ini.


Belajar mandiri didasarkan pada mempelajari dokumentasi dan menonton video pelatihan dari Internet - dan di sini saya menunggu untuk menangkap. Saya praktis tidak dapat menemukan informasi dalam bahasa Rusia. Omong-omong, pengetahuan saya tentang bahasa Inggris pada waktu itu tidak pada tingkat tertinggi, selain itu adalah proyek pertama saya dan, mungkin, faktor-faktor ini mempersulit hidup saya. Ini mendorong saya untuk menulis artikel pelatihan dalam bahasa Rusia dan dengan cara yang sesederhana mungkin bagi pengembang pemula yang menemukan produk ini dan berusaha untuk dengan cepat memahami dasar-dasarnya. Artikel ini tidak akan membebaskan Anda dari membaca dokumentasi, tetapi itu akan membuat hidup lebih mudah pada tahap awal pemahaman "cara kerjanya."


Perlu juga dicatat bahwa struktur yang diberikan dalam praktek akan dekat dengan proyek nyata, yang akan memungkinkan Anda untuk menggunakannya sebagai basis, memperluas dan melengkapi kebutuhan Anda. Sebagai kesimpulan, beberapa kata tentang proyek yang sudah dilaksanakan, serta beberapa fitur yang perlu diperhatikan, akan diberikan ke bagian Teori.




Bagian 1. Menginstal DataPower dengan Docker Toolbox


Instal dan jalankan aplikasi Docker Toolbox. Segera setelah memulai, Anda akan melihat alamat IP mesin, di mana DataPower akan tersedia di masa depan:




Untuk memulai gambar, Anda perlu mengubah beberapa pengaturan mesin virtual (relevan untuk versi IDG.2018.4.1.0) dan mulai ulang:


  1. Hentikan mesin buruh pelabuhan dengan perintah:

    docker-machine stop
  2. Sistem -> Motherboard -> Memori utama: minimum 4096Mb;
  3. Sistem -> Prosesor: minimum 2;
  4. Tampilan -> Layar -> Memori video: setidaknya 128Mb;
  5. Kami meluncurkan mesin buruh pelabuhan dengan perintah:

     docker-machine start

    Catatan Jika diminta untuk memulai ulang docker-machine env, jalankan:

     docker-machine env
  6. Selanjutnya, Anda harus mengempiskan gambar IBM DataPower:

     docker pull ibmcom/datapower
  7. Kemudian meluncurkan wadah buruh pelabuhan dengan perintah berikut:

     docker run -it \ -v $PWD/config:/drouter/config \ -v $PWD/local:/drouter/local \ -e DATAPOWER_ACCEPT_LICENSE=true \ -e DATAPOWER_INTERACTIVE=true \ -p 9090:9090 \ -p 3630:3630 \ -p 9022:22 \ -p 7170:7170 \ --name idg \ ibmcom/datapower
  8. Setelah menyelesaikan perintah, tekan Enter dan masukkan admin / admin sebagai nama pengguna dan kata sandi
  9. Untuk memulai Antarmuka Manajemen Web, gunakan perintah:

     co

    dan

     web-mgmt 0 9090
  10. Setelah semua langkah ini, jalankan di browser https://192.168.99.100:9090/

Bagian 2. Domain


2.1. Teori


Domain di DataPower memungkinkan Anda memisahkan alat administrasi dan pengembangan, serta memberikan keamanan.


Setelah instalasi, hanya ada domain default dari mana domain aplikasi dapat dibuat. Setiap domain memiliki konfigurasi parameternya sendiri.


Beberapa sumber daya dan parameter umum hanya dapat didefinisikan dalam domain default, ini termasuk antarmuka jaringan, pengguna dan kontrol akses, domain aplikasi, dan lainnya.


Domain aplikasi adalah bagian pengembangan untuk layanan pemrosesan permintaan. Layanan yang ditentukan di dalamnya tidak dapat dibagikan dengan domain aplikasi lain. Domain aplikasi dapat di-restart secara terpisah dan mandiri, tanpa perlu restart penuh DataPower.


Anda dapat membuat, memulai kembali, mengatur ulang, menjeda, memperbarui, atau menghapus domain. Anda dapat menemukan informasi lebih rinci tentang semua fitur administrasi dalam dokumentasi resmi.


Sedikit tentang proyek yang sudah selesai. Kami menggunakan 3 domain:


  • default - domain default yang berisi sumber daya dan parameter bersama;
  • trunk - domain utama yang berisi semua yang diperlukan untuk memproses permintaan;
  • pengaturan - pengaturan dan domain keamanan, file lokal berisi informasi tentang aturan perutean layanan dan pengaturan keamanan.

Kebutuhan untuk mentransfer semua pengaturan ke domain terpisah muncul sehubungan dengan pencarian untuk jalur penyebaran yang lebih sederhana. Seperti di banyak proyek, lingkungan pengembang, pengujian dan produksi dipisahkan, dan transfer ke domain pengaturan terpisah memungkinkan kami untuk menginstal semua domain utama dari lingkungan pengembang di lingkungan lain melalui ekspor / impor, tanpa risiko kehilangan pengaturan lingkungan.


2.2. Berlatih


  • Di bidang pencarian, masukkan "domain", pilih "Domain Aplikasi" dan klik "Tambah"
  • Di sini Anda perlu menentukan nama domain, komentar (jika diinginkan) dan mengaktifkan audit dan pencatatan. Isi kolom dan terapkan perubahannya
  • Demikian pula menambahkan "trunk" domain lain
  • Pergi ke Tinjau perubahan
  • dan simpan konfigurasi domain
  • Anda dapat memeriksa status objek yang dibuat dengan masuk ke domain default di pohon navigasi di Status -> Main -> Status Obyek
  • Pilih Lihat berdasarkan: jenis
  • Temukan Domain Aplikasi dalam daftar dan periksa status objek: masing-masing harus disimpan, dihidupkan, dan dalam status naik. Jika demikian, lanjutkan ke bab berikutnya.



Bagian 3. Manajer antrian


Manajer antrian bukan merupakan komponen wajib dari IBM DataPower, tetapi melalui contoh MQ Anda dapat menunjukkan kekuatan penuh dari produk ini. Kami akan menggunakan MQ dari IBM. Selama pengujian yang dijelaskan dalam Bab 6, kita perlu mengirim pesan ke manajer antrian lokal. Pada artikel ini, saya akan melakukan ini menggunakan utilitas rfhutil, tetapi Anda dapat menggunakan metode apa pun yang tersedia untuk Anda. Untuk pengujian, Anda harus membuat koneksi dari DP ke manajer antrian lokal menggunakan MQ Queue Manager.



3.1. Teori


Manajer antrian menyediakan pertukaran data antara gateway dan manajer antrian jarak jauh.


Anda juga dapat mengkonfigurasi MQ Queue Manager Group, yang akan meningkatkan toleransi kesalahan sistem. Ini dapat berguna, misalnya, jika Anda ingin menghubungkan klien ke salah satu set manajer antrian yang bekerja dan dalam beberapa kasus, yang dapat Anda temukan di dokumentasi resmi.


Dari pengalaman proyek, perlu dicatat hanya satu fitur: pada satu waktu kami ingin mencoba menerapkan load balancing menggunakan DataPower, khususnya, menggunakan kelompok manajer antrian, tetapi dalam praktiknya kami tidak menemukan kemungkinan seperti itu. Solusi alternatif adalah membuat sekelompok manajer antrian.



3.2. Berlatih


3.2.1. Persiapan


  1. Instal WebSphere MQ;
  2. Buat LOCAL_DP_QM manajer antrian lokal, dapat diakses di port 3630;
  3. Konfigurasikan saluran DP.SVRCONN;

    Saat membuat saluran, perintah berikut mungkin berguna bagi Anda:


     strmqm LOCAL_DP_QM /*  mq*/ runmqsc LOCAL_DP_QM /*   mq*/ DEFINE CHANNEL (DP.SVRCONN) CHLTYPE(SVRCONN) MCAUSER('evlasenko') /* */ SET CHLAUTH('DP.SVRCONN') TYPE(USERMAP) CLNTUSER('evlasenko') USERSRC(channel) ADDRESS('*') ACTION(ADD) /*      */ SET CHLAUTH(DP.SVRCONN) TYPE(BLOCKUSER) USERLIST('nobody') /*   */ ALTER LISTENER (SYSTEM.DEFAULT.LISTENER.TCP) TRPTYPE(TCP) PORT(3630) control(QMGR) /*    3630*/ ALTER AUTHINFO (SYSTEM.DEFAULT.AUTHINFO.IDPWOS) AUTHTYPE(IDPWOS) CHCKCLNT(OPTIONAL) /* */ REFRESH SECURITY TYPE(CONNAUTH) /*  */ endmqm LOCAL_DP_QM /*  mq*/ strmqm LOCAL_DP_QM /*  mq*/ END

  4. Buat antrian DP.IIB.REQIN dan DP.IIB.RESIN
  5. Jalankan rfhutil di bawah nama pengguna yang salurannya dibuat. Di baris Nama Manajer Antrian (untuk terhubung ke), tulis:

     DP.SVRCONN/TCT/127.0.0.1(3630)

  6. Coba muat daftar nama antrian, seharusnya tidak ada kesalahan di jendela pesan. Koneksi ke saluran telah diverifikasi.

3.2.2. Buat Manajer Antrian IBM MQ


  1. Buka domain trunk.
  2. Dalam pencarian, ketik MQ, pilih IBM MQ Queue Manager, dan klik Add.
  3. Anda perlu menentukan nama (TEST_QM), nama host manajer antrian, nama manajer antrian dan nama saluran, serta batas waktu. Konfigurasikan dan simpan perubahan.


Periksa status objek manajer antrian dengan cara yang sama seperti memeriksa status domain. Untuk melakukan ini, pilih Status Objek dan filter Lihat berdasarkan: dari domain trunk. Di bagian "Manajer Antrian IBM MQ", cari objek yang sesuai dan periksa statusnya.


Bagian 4. Multiprotocol Gateways


4.1. Teori


Multi-Protocol Gateway (MPG) adalah gateway multi-protokol yang memungkinkan Anda untuk menerima permintaan dari klien menggunakan berbagai protokol, dan kemudian mentransfernya ke server yang berbeda menggunakan berbagai protokol. Protokol yang digunakan oleh klien mungkin tidak cocok dengan protokol yang digunakan oleh server akses jarak jauh.


Dalam pengaturan MPG utama, Anda dapat menentukan komponen-komponen berikut:

  • Manajer XML - mengontrol kompilasi dan caching style sheet (xsl, xslt), caching dokumen.
  • Kebijakan - terdiri dari aturan, yang masing-masing mendefinisikan serangkaian tindakan yang diterapkan pada pesan yang melewati gateway.
  • Pengaturan sisi depan dan belakang (url pengaturan, jenis pesan masuk dan keluar, batas waktu dan banyak lagi).

Beberapa kata tentang proyek ini:


Proyek ini menggunakan 4 gateway multi-protokol (perutean, 2 transformasional untuk sistem akhir yang berbeda dan satu lagi yang dirancang untuk menerima file dari domain pengaturan). Diagram di bawah ini menunjukkan skema interaksi umum:



Jumlah MPG dapat bervariasi tergantung pada arsitektur solusi secara keseluruhan. Dalam kasus kami, DataPower menghadapi bus integrasi (IIB) dan layanan microser, yang memiliki perbedaan antarmuka yang signifikan (json / http versus xml / mq), sehingga diputuskan untuk membuat MPG transformasional untuk setiap backend spesifik dan beri nama sesuai. Untuk semua klien, kami bekerja di json / http, jadi perutean MPG adalah satu. MPG utama terdiri dari 3 aturan untuk memproses pesan - permintaan, respons, dan kesalahan. Setiap aturan terdiri dari tindakan yang diperlukan, seperti transformasi, pencatatan, perutean, dan lainnya.


Dari fitur - jika dalam kebijakan Anda menggunakan tindakan ConvertQueryParamToXML, maka perhatikan InputConversion. Jika Anda mengatur Pengkodean Default ke JSON dan mencoba mengirim permintaan GET, Anda akan terkejut menemukan bahwa pesan tersebut belum mengalami transformasi apa pun yang Anda tentukan dan Anda tidak akan menemukan jejaknya. Fitur ini akan membantu mengatasi pembuatan aturan terpisah untuk permintaan GET.


4.2. Berlatih


4.2.1. Persiapan


Anda dapat menemukan semua file yang diperlukan untuk bekerja di tautan https://github.com/EvgenyaVlasenko/IBM_DataPower.git

4.2.1.1. Batang domain


  1. Buka domain trunk.
  2. Di panel kontrol, pilih Manajemen File.
  3. Di direktori lokal, buat struktur direktori berikut dan tempatkan file yang sesuai di dalamnya (setiap file berisi deskripsi singkat tentang fungsi apa yang dikerjakannya, serta diskusi yang lebih rinci tentang ini nanti dalam artikel).


4.2.1.2. Pengaturan domain


  1. Buka domain pengaturan.
  2. Di panel kontrol, pilih Manajemen File.
  3. Di direktori lokal, buat struktur direktori berikut dan tempatkan file yang sesuai di dalamnya (file juga berisi deskripsi singkat tentang mereka).


4.2.2. Buat GetFileMPG


Pertama, buat MPG pembantu sederhana yang akan mengembalikan file dari domain pengaturan.


  1. Buka domain pengaturan.
  2. Di panel kontrol, pilih Gateway Multi-Protokol dan klik Buat.
  3. Tentukan nama (GetFileMPG), deskripsi (opsional), dan tipe backend (dinamis). Bahkan, karena tidak akan ada panggilan ke backend, dan hanya file yang akan dikembalikan dari sistem lokal, dalam contoh ini Anda dapat menentukan semua jenis backend.

  4. Tentukan jenis permintaan dan respons. Jenis yang ditentukan secara eksplisit akan mengurangi jumlah pemeriksaan inline. Menentukan jenis Pass through memungkinkan Anda untuk tidak membuat aturan (dalam hal ini, untuk mengubah respons). Jika kami menentukan Jenis Permintaan juga Lewat, maka kami tidak akan dapat memproses pesan dengan cara apa pun. Opsi ini tidak sesuai dengan kami, jadi kami membatasi jenis permintaan menggunakan Non-XML.


  5. Klik pada + dan pilih HTTP Handler untuk membuat Protokol Sisi Depan yang baru.


  6. Di sini Anda harus menentukan nama, alamat ip, port, dan daftar metode yang diperbolehkan. Perhatikan alamat ip. Jika Anda menentukan 0.0.0.0, maka semua orang dapat mengakses gateway ini. Jika 127.0.0.1 - hanya gateway lain di dalam DataPower yang sama. Karena ada parameter keamanan di antara pengaturan, kami menggunakan opsi kedua. Isi kolom dan klik "Terapkan", protokol akan secara otomatis ditambahkan ke gateway.


  7. Klik pada + untuk menambahkan kebijakan baru.


  8. Isi nama kebijakan "GetFilePolicy".
  9. Buat aturan baru, isi nama dan arah aturan. Karena sebenarnya tidak ada backend, dan hanya file yang diinginkan dikembalikan, hanya akan ada satu aturan (klien ke server).


  10. Klik dua kali pada aksi Match untuk mengkonfigurasinya, pilih aturan yang ada dan terapkan perubahannya. Secara ideologis akan benar untuk menetapkan batas pada kemampuan untuk hanya menerima permintaan, tetapi dalam kerangka tugas pelatihan, Anda dapat memilih yang sudah ada.
  11. Tambahkan tindakan lain - GatewayScript dengan menyeretnya ke aturan dan mengonfigurasinya. Sebagai transformasi, kita akan menggunakan file yang disiapkan, yang di sistem file lokal: /// akan menemukan file dengan nama dari URI dari permintaan yang masuk dan menempatkannya di badan pesan. Hasil operasi akan ditransfer langsung ke buffer output aturan. Simpan perubahannya.


  12. Hasil kebijakan akhir akan terlihat seperti ini:


  13. Pembuatan MPG selesai, simpan perubahannya.
  14. Anda dapat memverifikasi keberhasilan pembuatannya menggunakan Status Objek, mirip dengan memeriksa status domain dan manajer antrian. Untuk melakukan ini, pilih Status Objek dan filter Lihat oleh: layanan dari domain pengaturan. Di bagian "Multi-Protocol Gateway", cari objek yang sesuai dan periksa statusnya.
  15. Anda tidak dapat memanggil MPG ini dari luar, karena Anda melindunginya dengan ip. Ubah sementara ip dari 127.0.0.1 ke 0.0.0.0 dan port dari 7171 ke 7170 dan jalankan permintaan berikut:

     curl -vv -k "http://192.168.99.100:7170/trunk/route/routeRules.xml"

  16. Anda harus mendapatkan jawaban berikut:


  17. Sekali lagi, ubah ip dan port ke 127.0.0.1:7171 yang asli.

4.2.3. Membuat RoutingMPG


Sekarang buat RoutingMPG. Berdasarkan permintaan input dan aturan perutean, ia akan menentukan di mana dan dengan parameter apa permintaan harus dikirim.


  1. Buka domain trunk.
  2. Buat Gateway Multi-Protokol baru sesuai dengan klausa 2-10 dari bagian 4.2.2 menggunakan nilai-nilai berikut:
    • 3 - nama: RoutingMPG, tipe backend: Dinamis (untuk kemampuan untuk merutekan permintaan ke MPG yang berbeda jika perlu).
    • 4 - Rq: Non-xml, Rs: Non-xml.
    • 6 - nama: RoutingHTTP_FSH, ip: 0.0.0.0, port: 7170, + Dapatkan metode.
    • 8 - nama: RoutingPolicy.
    • 9 - nama: RoutingPolicy_rule_req, arah: Klien ke Server.

  3. Tambahkan satu tindakan lagi untuk merutekan permintaan. Untuk melakukan ini, seret tindakan “Rute” ke aturan, klik dua kali untuk mengonfigurasinya, isi kolom dan terapkan perubahannya. File route.xsl menerima file pengaturan rute dari domain pengaturan melalui GetFileMPG yang dibuat sebelumnya. Setelah itu, berdasarkan URI, pengaturan yang diperlukan untuk operasi ini sudah dipilih dari file. Beberapa dari mereka digunakan untuk perutean, dan beberapa ditambahkan ke header untuk digunakan dalam MPG lainnya. Parameter input dan output menentukan cara bekerja hanya dengan isi pesan dan sama sekali tidak memengaruhi header dan variabel. Oleh karena itu: input dari nol - karena informasi dari badan pesan tidak digunakan untuk perutean. Outputnya nol - karena hasil transformasi hanyalah perubahan dalam informasi layanan.


  4. Demikian pula, buat 2 aturan lagi dan simpan semua perubahan:
    • Arah: Server-Klien, nama: RoutingPolicy_rule_resp;
      Transformasi: Input INPUT, Output NULL, file transformasi lokal: ///RoutingMPG/transform/resp.xslt. File resp.xslt menerima status http dari respons transformasi MPG dan secara eksplisit menetapkannya ke respons RoutingMPG. Jika ini tidak dilakukan, maka kode default akan diatur ke 200, bahkan jika terjadi kesalahan dalam transformasi MPG.
    • Arah: Kesalahan, nama: RoutingPolicy_rule_error;
      Transformasi: Input INPUT, Output PIPE (sesuai dengan dokumentasi, menggunakan PIPE antara dua node aksi yang berdekatan karena INPUT dan OUTPUT dapat menghilangkan pemrosesan tambahan dan mengurangi jumlah memori yang digunakan), file transformasi adalah lokal: ///RoutingMPG/transform/errors.xsl. File errors.xsl menerima kode kesalahan dan teks dari respons dari MPG transformasi dan menghasilkan pesan kesalahan JSON dalam format yang diharapkan oleh klien.

  5. Hasil kebijakan akhir akan terlihat seperti ini:


  6. Pembuatan MPG selesai, simpan perubahannya.
  7. Menggunakan, misalnya, utilitas curl, jalankan kueri berikut:

     curl -vv -k "http://192.168.99.100:7170/dp/test/transformMessage"

  8. Jika Anda mendapatkan kesalahan berikut, maka semuanya dilakukan dengan benar. Kesalahan ini berarti bahwa pesan berhasil diterima dan diproses, tetapi upaya untuk memanggil backend (dalam hal ini IIBMPG) tidak berhasil. Lanjutkan ke langkah berikutnya.



4.2.4. Pembuatan IIBMPG


Langkah selanjutnya adalah membuat MPG transformasional. Misalkan sistem eksternal dalam format permintaan JSON dan internal XML. Kita perlu mengubah pesan input sehingga sistem internal dapat memahaminya. Perlu dicatat bahwa ini tidak selalu merupakan konversi sederhana dari seluruh pesan. Seringkali diperlukan untuk menyampaikan pesan terpotong atau diperbesar, kadang-kadang dengan struktur yang sepenuhnya didesain ulang.


  1. Buka domain trunk.
  2. Buat Gateway Multi-Protokol baru sesuai dengan klausa 2-10 dari bagian 4.2.2 menggunakan nilai-nilai berikut:
    • 3 - nama: IIBMPG, tipe backend: Dinamis
    • 4 - Rq: JSON, Rs: XML
    • 6 - nama: IIBHTTP_FSH, ip: 127.0.0.1 (hanya permintaan dari DataPower yang sama), port: 7172, + Dapatkan metode
    • 8 - Nama: IIBPolicy
    • 9 - nama: IIBPolicy_rule_req, arah: Klien ke Server

  3. Tambahkan deskripsi. Berdasarkan X-DP-Transform-Name di header permintaan, file IIBRuleRoute.xsl menerima dari file lokal: ///IIB/route/IIBRouteRules.xml nama-nama transformasi permintaan, file respons dan kesalahan untuk layanan ini dan menetapkan nilainya ke variabel konteks yang sesuai var: // context / IIB / reqTransform, var: // context / IIB / ansTransform, var: // context / IIB / errTransform. Nilai lain dari tajuk (url, uri, kedaluwarsa, batas waktu) juga ditempatkan dalam variabel konteks.


  4. Tambahkan tindakan lain dengan menyeret Lanjutan ke aturan Anda dan memilih Convert Query Params ke XML dari daftar, konfigurasikan. Anda perlu menambahkan peta konversi input baru, memberinya nama (cmnJSONParseCNVM) dan jenis yang diperlukan (JSON).




  5. Tambahkan transformasi setelah konversi standar dan konfigurasikan. Dalam hal ini, set variabel dalam transformasi sebelumnya digunakan untuk menunjukkan file transformasi. Ini dilakukan agar transformasi bersifat universal, dan file itu sendiri diganti "on the fly" tergantung pada pesan input. Badan pesan sudah siap. Langkah selanjutnya adalah merutekan pesan, dan isi pesan tidak akan berubah, jadi kami membuat variabel dpvar_1 dan menyimpan hasilnya di dalamnya. Variabel inilah yang kami arahkan ke input ke tindakan Hasil. Simpan perubahannya.


  6. Tambahkan tindakan perutean dan atur parameter berikut. File IIBURLRoute.xsl menerima nilai-nilai variabel konteks, beberapa dari mereka ditetapkan sebagai variabel permintaan layanan, dan dari yang lain membentuk URI untuk permintaan ke sistem tujuan, yang juga menyimpan dalam variabel layanan.


  7. Demikian pula, buat 2 aturan lagi dan simpan semua perubahan:
    • Arah: Server-Klien, nama: IIBPolicy_rule_resp;
      Transformasi: Input INPUT, Output PIPE, file transformasi var: // context / IIB / ansTransform (variabel konteks untuk mensubstitusi transformasi respon "on the fly").
    • Arah: Kesalahan, nama: IIBPolicy_rule_error;
      Transformasi: Input NULL, Output PIPE, file transformasi var: // context / IIB / errTransform (variabel konteks untuk mengganti transformasi kesalahan dengan cepat).

  8. Hasil kebijakan akhir akan terlihat seperti ini:

  9. Pembuatan MPG selesai, simpan perubahannya.

Bagian 5. Pengujian


5.1. Persiapan


  1. Unduh, misalnya, utilitas rfhutil untuk membaca dan menulis pesan ke antrian;
  2. File uji terletak di folder tes dari direktori yang sama dengan file proyek.

5.2. Pemeriksaan Kesehatan


  1. Kirim permintaan menggunakan utilitas curl (untuk permintaan di bawah ini, direktori saat ini harus sama dengan example.json).

     curl -vv -k "http://192.168.99.100:7170/dp/test/transformMessage" -H "Content-Type: application/json" --data-binary @example.json

  2. Buka 2 instance utilitas rfhutil dan kurangi pesan dari antrian DP.IIB.REQIN dengan instance pertama;
  3. Buka tab MQMD dan salin MessageID;
  4. Dalam contoh kedua, buka file rs.xml, di tab MQMD, masukkan pengidentifikasi pesan di CorrelID dan letakkan pesan di antrian DP.IIB.RESIN;
  5. Anda harus mendapatkan jawaban yang serupa:


  6. Ulangi langkah 1-3;
  7. rs_error.xml correllId;




6.


6.1. Teori


Log Targets , .


Log Targets . , 4 1000Kb, . 2-4 . , . , DataPower, , , , , , - MPG, .


6.2.


  1. trunk;
  2. Log Target ;
  3. :
    • (IIB_LOG);
    • (File);
    • (Text);
    • timestamp(zulu);
    • (logtemp:///IIB.log — IIBMPG);
    • (1000).


  4. . MPG IIBMPG.


  5. , , ( , ).


  6. ;
  7. ;
  8. .
  9. Log Targets MPG.
  10. :
    • , , .


    • .




7. -


  1. – , . – , , - .
  2. . View Logs. , « », « » .
  3. . . MPG Show Probe -> Enable Probe. . , .


  4. , .

– .

Source: https://habr.com/ru/post/id442686/

More articles:


All Articles