Posts Subscribe comment Comments

Left

SELAMAT DATANG DI BLOGKU, BLOG YANG PENUH SOFWARE DAN TUTORIAL

Memikirkan kembali Peran SARM pada tahun 2011

Hal ini hampir 1 pagi, dan saya masih sampai mencoba untuk menyelesaikan sedikit riset lewat internet. Secara kebetulan aku menemukan artikel yang berbicara tentang Siebel Application Response Measurement (SARM). Bagaimana peluang untuk hal ini terjadi di tengah malam? Pikirku. Apa yang lebih menakjubkan adalah bahwa penulis yang dimaksud salah satu posting saya sebelumnya (terima kasih, @ lex)! Walaupun saya mulai mengantuk, aku merasa terdorong untuk memberikan tanggapan.

SARM memang tidak digunakan oleh setiap pelanggan Siebel meskipun seharusnya. Dalam sebuah survei yang kita laksanakan di Oracle OpenWorld beberapa tahun yang lalu, kami mengetahui bahwa ada dua alasan bagi administrator untuk tidak mengaktifkan SARM - 1. terlalu sulit untuk memahami data; 2. SARM itu dianggap terlalu banyak mengkonsumsi overhead. Ada beberapa kebenaran dalam # 1, tapi Siebel Transaksi Diagnostic Tool dalam Manajemen Aplikasi Suite untuk Siebel harus memiliki memecahkan sebagian besar masalah ini. Alih-alih Anda harus khawatir tentang mengambil hak set file log SARM dan berjalan SARMquery secara manual, alat tersebut untuk Anda, dan menghasilkan laporan grafis yang bagus yang membantu Anda dengan cepat memvisualisasikan dan memahami kinerja data diagnostik yang menangkap SARM.

 

# 2 adalah sedikit mitos sekalipun. SARM tidak mengkonsumsi kapasitas, tetapi jumlah yang mengkonsumsi cukup masuk akal untuk wawasan kritis bahwa ia menyediakan untuk mengelola aplikasi Siebel dengan benar. Alternatif tidak menyalakan SARM adalah memiliki Siebel sebagai blackbox, yang tidak membuatnya sangat mudah dikelola.
  
Sementara SARM berguna, ada juga alat lainnya yang satu harus digunakan untuk mengelola kinerja aplikasi Siebel. Aku menutup topik ini dalam artikel saya sebelumnya "Pendekatan Holistik untuk Monitoring CRM Siebel" beberapa waktu lalu. Alasan mengapa SARM harus digunakan dalam hubungannya dengan alat-alat lain adalah bahwa kita telah membuat teknologi yang tersedia beberapa pelengkap baru yang lebih cocok untuk melaksanakan beberapa tugas kinerja aplikasi manajemen sejak kami memperkenalkan SARM.

SARM diciptakan in-house di Siebel. Pada saat itu, kami pikir kami akan menggunakannya sebagai kerangka kerja semua mencakup baik untuk monitoring dan diagnostik. Namun, seperti dalam proyek pengembangan perangkat lunak 1.0, tidak ada sumber daya yang cukup untuk semua bangunan yang kita inginkan, jadi kami harus fase dalam kemampuan. SARM pertama kali dibuat tersedia di 7,5, dan kami membuat perangkat tambahan setelah kerangka kerja dalam 7.7 dan 8.0. Selain keterbatasan sumber daya, kita juga harus hidup dengan keterbatasan teknologi. Maksud asli mendukung antarmuka 2.0 ARM adalah untuk memberikan pakan dalam-memori untuk alat pemantauan sehingga tanda dapat dikirim jika jatuh waktu respon aplikasi di bawah target pelayanan tingkat. Namun, karena ARM 2.0 API bidang data tidak cukup lebar untuk SARM untuk melewatkan data kontekstual seperti nama layar dan melihat, manfaat dari antarmuka untuk memonitor real-time terbatas, dan ini sama sekali tidak berguna untuk kinerja diagnostik sebagai data kontekstual sangat penting untuk pemecahan masalah aplikasi.

Kelemahan lain dari SARM adalah bahwa instrumentasi SARM tidak tersedia dalam kerangka klien Siebel UI. Akibatnya, SARM hanya bisa mengatakan waktu server, dan bukan transaksi end-to-end meminta waktu pengguna akhir melihat. Ini berarti bahwa setiap masalah jaringan yang terkait sama sekali tidak terlihat SARM. Pada saat kami mencoba mengatasi kekurangan ini, Siebel sudah bagian dari Oracle, dan kami memiliki opsi baru yang tersedia.

Opsi baru ini adalah sebuah teknologi baru yang disebut Real User Experience Insight (Ruei). Ternyata Siebel bukan satu-satunya aplikasi di mana kita harus memecahkan masalah kinerja aplikasi manajemen di Oracle. Bahkan, administrator dari Oracle E-Business Suite, PeopleSoft, dan JD Edwards EnterpriseOne semua perlu untuk memantau kinerja aplikasi. Daripada membangun sesuatu satu off untuk Siebel, kami butuh sesuatu yang bekerja di semua aplikasi, dan dapat digunakan di masa depan untuk Aplikasi Fusion. Ruei sesuai tagihan sempurna.


 

Ruei, yang juga merupakan bagian dari Manajemen Aplikasi Suite untuk Siebel, jauh melampaui apa yang SARM dapat Anda lakukan dalam beberapa aspek dan merupakan pelengkap sempurna untuk SARM. Pertama, Ruei tidak mengkonsumsi kapasitas pemrosesan pada salah satu aplikasi web Siebel, dan server database. Ruei menggunakan protokol jaringan pendekatan analisis pengumpulan data pemantauan, yang tidak memerlukan perangkat lunak yang harus diinstal pada server kotak Siebel, maka tidak mengganggu dengan aplikasi Siebel. Pendekatan asli yang kami pikir tentang pelaksanaan akan membutuhkan berjalan SARM di klien, dan hanya akan bekerja untuk kerangka HI Siebel. Pendekatan-pendekatan lain yang memerlukan agen untuk menjadi statis atau dinamis diinstal pada klien Siebel atau server untuk mencegat akhir Siebel lalu lintas pengguna juga dapat mengganggu operasi Siebel.

Kedua, karena Ruei menggunakan analisis jaringan protokol, dapat mengukur waktu end-to-end respon dan volume lalu lintas jaringan yang menghasilkan aplikasi Siebel. Informasi ini dapat digunakan di triase masalah kinerja awal untuk memutuskan apakah masalah waktu respon disebabkan oleh jaringan atau server. Juga, karena informasi jaringan menangkap Ruei, Anda seringkali dapat menentukan lokasi fisik dari user melalui pemetaan alamat jaringan yang dibangun ke alat.
Ketiga, Ruei tidak hanya dapat mengukur waktu respon pengguna akhir, tetapi juga menangkap kesalahan yang pengguna akhir lihat di user interface. wawasan ini sangat penting untuk melaksanakan dukungan teknis sebagai pengguna akhir mungkin atau tidak dapat melaporkan kesalahan yang mereka lihat pada permintaan bantuan mereka dengan benar. Kesalahan statistik juga dapat digunakan untuk meningkatkan kegunaan dari pelatihan aplikasi atau pengguna, seperti terjadinya mengulangi kesalahan mungkin menunjukkan bahwa user interface terlalu sulit untuk digunakan, atau pengguna hanya tidak dilatih dengan benar.
Keempat, butiran halus Ruei menyediakan banyak real-time memperingatkan tentang masalah kinerja Siebel daripada yang mungkin melalui pendekatan 2.0 ARM API yang SARM mengimplementasikan. Dengan Ruei, orang bisa menetapkan target KPI pada layar tertentu Siebel, pandangan atau applet, dan memiliki tanda pergi ketika persentase tertentu dari kegiatan di objek-objek pergi di atas target level pelayanan yang bisa diterima.
Akhirnya, Ruei dilengkapi dengan built-in database OLAP dan satu set alat yang sangat bagus untuk menghasilkan laporan kinerja baik ad-hoc dan pra-ditetapkan. Anda bahkan dapat menggunakannya untuk melakukan klik analisis arus yang biasanya dilakukan dengan perangkat lunak analisis web untuk menjawab pertanyaan yang analis bisnis peduli. Anggap saja sebagai alat intelijen bisnis untuk memahami pengalaman pengguna akhir.
Jika Ruei sangat bagus, artinya bahwa SARM tidak lagi diperlukan? Tentu saja tidak. Ruei dapat memberitahu Anda dari perspektif bisnis dan perspektif pengguna akhir yang pengguna akhir, di mana mereka berasal, apa yang mereka coba lakukan pada Siebel dan jenis waktu respon dan kesalahan yang mereka terima. Namun, kecuali untuk masalah jaringan, tidak akan memberitahu Anda mengapa aplikasi berjalan lambat. Anda perlu SARM untuk ini.
Selain Ruei, yang menyediakan pemantauan pengguna nyata dalam Manajemen Aplikasi Suite untuk Siebel, suite ini juga mencakup perangkat untuk pemantauan pengguna sintetis, pemantauan alur kerja, pemantauan Siebel komponen, monitoring log file, dan pemantauan mengubah konfigurasi. Informasi lebih lanjut tentang produk dapat ditemukan di website ini.

RAMALAN DENGAN PASANGAN KAMU