تشخيص سريع و قوي و حل مشكلات تطبيقات الشيربوينت باعتماد Azure Application Insights - الحلقة 2

بعد الحلقة الاولى التي شرحت فيها كيفية تفعيل خدمة Azure Application Insights لمتابعة اداء مواقع و تطبيقات الشيربوينت وحل مشكلات الاداء, سأوضح في هذا الموضوع انواع الرسوم البيانية و المخرجات المهمة لهذه الخدمة المميزة.

1- بعد ان نجحنا في تثبيت "Application Insights Status Monitor"  على الخادم و ربطه بـ IIS فقد اصبح بالامكان الحصول على معلومات عن اداء الخادم و متابعة استجابته للطلبات. قم بالضغط على زر "Performance" لتلاحظ فتح نافذة "Server Responses" :

* Server Response Time  : هو الوقت المستغرق من الخادم من حين استقبال الطلب الى الانتهاء من تجهيز الرد و ارساله الى العميل

* Dependency Duration : هو الوقت المستغرق للنداء الذي بين خادم الويب و الخوادم الاخرى ذات العلاقة كخادم قواعد البيانات او خوادم التطبيقات ...

* Server Request : هو اجمالي طلبات http التي استقبلها الخادم

لاحظ انك كلما ضغطت على جزء من الشاشة ستفتح لك شاشة جديدة من الرسوم و المعلومات الهامة :) ففي البلوك الذي يتم فيه عرض معدل تحميل الصفحات اضغط على صفحة /sitepages/home.aspx سيتم عرض نافذة جديدة فيه الحالات التي مرت بها الصفحة اثناء استدعائها من قبل الزوار:

بالضغط على احدى الطلبات سترى تفاصيل اكثر عنها بما ذلك IP المستخدم الذي لم يستطع فتح صفحة موقعك مثلا ... معلومة كهذه و تكررها في ساعة ما من اليوم قد تلفت انتباهك الى وجود اشكال بالصفحة او بادائها و بالتالي بامكانك حسن التعامل مع زوار موقعك : فعلى سبيل المثال تستطيع ارسال رسالة اعتذار عبر البريد و غير ذلك من اجراءات التواصل ..  بامكانك ايضا معرفة الوقت الذي يستغرقه المتصفح لتحميل ملفات CSS و JS وهو ما يعطيك اشارة الى ضرورة التقليل في حجمها مثلا ...

2- للتعرف على حالات عدم تمكن الزوار من فتح صفحات موقعك قم بالضغط على Failures كما في الصورة التالية :

ستلاحظ كالعادة انفتاح نفاذة لتفاصيل الطلبات التي شهدت اخفاقا او FAILURE و هنا نسبة اخفاق كل عملية من اجمالي الاخفاقات مما يتيح لك امكانية عمل اولويات لاصلاح المشكلات الموجودة :

3- للتعرف على اداء الخادم و الحاجة الى عمل Scale Up او زيادة لموارد التالية :  المعالج , الذاكرة ... قم بالاطلاع على نافذة Servers و التي تعرض اداء خوادم مزرعتك كما هو موضح :

* Process CPU : نسبة استهلاك المعالج.

* Available Memory : الذاكرة المتاحة.

* Process IO Rate : اجمالي البايتس المقروءة و المكتوبة في الثانية على الملفات و الشبكة .

* Exception Rate : الاستثناءات الواردة في الثانية.

* ASP.NET Request Rate : معدل جميع الطلبات إلى التطبيق في الثانية.

4- كنا في الحلقة (1) اضفنا سكربت JS لتفعيل متابعة تحليلات الاستخدام للشاشات لذلك ستحصل على معلومات قيمة جدا عن الضغط على "BROWSER" :

* Client Processing Time : المدة الزمنية بين تحميل DOM و اخر بايت يتم تحميله في المتصفح

* Send Request Time : الوقت بين الربط بالشبكة و استقبال اول بايت

* Receiving Response Time : المدة بين اول بايت و اخر بايت

* Page Views : عدد الزيارات على الصفحات

بامكانك ايضا ملاحظة بلوك : متوسط وقت تحميل الصفحات. معدل تحميل صفحة Home.aspx هو 3.28 ثانية وهي في الحقيقة مدة مرتفعة نوعا ما لذلك لابد من معالجة الصفحة. 

* Users : بالضغط على الصفحة المختارة ستظهر نافذة تفاصيل جديدة تظهر مرات دخول الزوار على الصفحة. كذلك عدد الزوار لتلك الصفحة.

5- بالرجوع الى الصفحة الرئيسية في البوابة و الضغط على "Browser" ستظهر تحليلات الاستخدام:

* Users : عدد الزوار المختلفين

* Sessions : عدد جلسات المستخدمين

* Top Sessions By Country: هنا سيظهر لك عدد الجلسات حسب بلدان زوار الموقع ...

بصراحة خدمة رائعة جدا خصوصا مع الضعف النسبي  في المخرجات الذي تعاني منه خدمة "تحليلات البحث" في الشيربوينت و التي سبق و شرحتها في الموضوع التالي لذلك فانها تساعد جدا على اتخاذ القرارات الفنية المناسبة في الوقت المناسب !! 

سلسلة شرح تطبيقات الخدمات (1) : تحليلات الشيربوينت 2013

مقارنة بين CSOM و REST لمن يبرمج على الشيربوينت

سافترض في هذا الموضوع ان القارئ يعلم ماهو CSOM و ماهو REST.
وكما هو معلوم فان مبرمج الشيربوينت بامكانه الاتصال عن بعد بمنصة الشيربوينت عن طريق نموذجين الذين ذكرتهما .
لكن يوجد سؤال محير دائما ما يخطر ببال المبرمج اي اسلوب استخدم CSOM او REST ؟
لذلك أمل ان يكون هذا الموضوع مساعدا لك على الاختيار حيث ساضع فيه جمله من الامور او معايير المقارنة التي تسهل عليك ذلك . لكن المقارنة المذكورة ليست مقارنة من هو الافضل ؟ : لان الافضل منهما في حالات قد لا يكون الافضل في حالات الاخرى لذلك فان المقارنة بينهما  نسبية و ليست مطلقة.

 اود ان اذكر 5 امور او اعتبارات مهمة - حسب رأيي - في اختيار الواجهة البرمجية (API) المناسبة لك عند تعاملك مع الشيربوينت :

1- الاعتبارات الفنية :

* من حيث الخدمة المستهدف التعامل معها :

	.NET		JavaScript
	CSOM	REST	CSOM	REST
Workflow	نعم	لا	نعم	لا
Managed Metadata	نعم	لا	نعم	لا

* من حيث البنية التحتية المستخدمة :

	.NET		JavaScript
	CSOM	REST	CSOM	REST
Windows / Microsoft	نعم	نعم	نعم	نعم
LAMP, Android, IOS, …	خاص بمايكروسف فقط	نعم	خاص بمايكروسف فقط	نعم

* من حيث نوعية تعاملك مع  الشيربوينت في عملك :

	.NET		JavaScript
	CSOM	REST	CSOM	REST
فقط للتعامل مع البيانات التي في الشيربوينت	*	نعم	*	نعم
التعامل مع امكانيات شيربوينت : كانشاء الصلاحيات و القوائم و انواع المحتوى ...	نعم	*	نعم	*

*: لا اقصد هنا بالنجمة الحمراء ان الحالة غير ممكن لكن ليست الافضل من حيث سهولة الاستخدام.

* حسب طريقة الرفع او نوع الحل البرمجي المراد انتاجه :

	.NET		JavaScript
	CSOM	REST	CSOM	REST
Farm Solution	نعم	نعم	نعم	نعم
SharePoint Hosted Apps	لا	لا	نعم	نعم
Cloud Hosted Apps	نعم	نعم	نعم	نعم
Apps for Office	لا	لا	نعم	نعم

2-  لاعتبارات الاداء :

البعض لا يهتم بالاداء او Performance  الا اذا فقده :)
فعادة لا يتم الالتفات الى مسالة اداء الاكواد الا بعدما يتم اكتشاف ضعف فيه. و في هذا الاطار اؤكد لك ان الاختبارات اثبتت ان استخدام REST عادة ما يتسبب في ارسال طلبات لخادم الشيربوينت اضعاف مضاعفة مقارنة باستخدام CSOM.
سبب ذلك انك عندما تستخدم REST فانك تضطر للاتصال بالخادم في كل عملية : اذا اردت انشاء قائمة تتصل بالخادم , اذا اردت اضافة عنصر واحد الى تلك القائمة ستتصل بالخادم مرة اخرى و هكذا ...
لكن عن طريق CSOM فان ذلك يتم دفعة واحدة على هيئة BATCH. بطبيعة الحال مثل هذا السلوك من REST يؤثر حتى على موارد الشبكة من حيث الحمل الزائد عليها ...

3- قابلية الاختبار :
هذا الامر مهم جدا حيث نعرف كلنا صعوبة اختبار اكواد CSOM .
اعتقد ان هذا المعيار بالذات يصب في صالح REST. حيث انه اسهل في الاختبار لانك عندما تختبر اكواد REST فانك تختبر الويب المتعارف عليه (طلبات HTTP ...) على عكس CSOM فانك تحتاج التعامل مع شيئيات شيربوينت "SharePoint Objects".
عموما انت تحتاج الى ما يسمى ادوات المحاكات mock tools مثل : 
- microsoft fakes
- type mock isolator
- nmock
- just mock 


4- حماية الملكية الفكرية :

هذا الامر يهم بالاساس من يقوم بنشر التطبيقات على متجر الاوفيس و شيربوينت.
لا يوجد في الحقيقة الية لحماية اكوادك اذا كانت تعمل على المتصفح حيث ان اي احد بامكانه نسخها بسهولة كما انك عندما تستخدم REST سيصبح من السهل معرفة خدمة الويب التي تقوم باستهلاكها و كذلك جميع مدخلات و مخرجات HTTP التي تصدر عن تطبيقك ...
لكن اذا كنت مجبرا على استخدام SharePoint Hosted App و بالتالي على JavaScript اليك بعض الممارسات التي تجعل من عدم احترام الغير لملكية الفكرية امرا صعبا عليهم :

- بامكانك تعقيد الاكواد باستخدام TypeScript مثلا بدلا من كتابة الاكواد مباشرة عن طريق JaveScript
- استخدم JaveScript Obfuscator 



5- اعتبارات المبرمج :

هذا اخر اعتبار من حيث ترتيب الاهمية ليس لاني لا احب المبرمجين , على العكس فانا بالاساس مبرمج :) لكن لانه حسب رايي الشخصي لابد للمبرمج ان يتاقلم مع اي لغة يطلب منه التعامل معها.

- نحن نعلم ان CSOM هو اسلوب من انتاج مايكرسفت لذلك اذا حاولت استخدام اسلوب اخر , لا اقول انك لا تستطيع تنفيذ ما تحتاج لكن ستحتاج غالبا الى عمل اضافي.

- حاليا لا يمكنك ان تتعامل مع اجراءات العمل في شيربوينت 2013 (workflows) و خدمة Managed Metadata  الا من خلال CSOM لان نقاط REST التي يوفرها شيربوينت حاليا لا يمكنها الاتصال بهذين المكونين .

- اضف الى ما سبق ان قلة الموارد التعليمية الخاصة بـ REST قد تجعل الكثير لا يفضله.

- عدم الرغبة في تعلم REST مع اني اعتقد ان المبرمج لابد ان يكون لديه الرغبة في تعمل الجديد دائما.




الخاتمة:

من يقول ان مستقبل البرمجيات على شيربوينت و غيره في REST مخطأ , قد يكون ذلك صحيحا خارج شيربوينت لكن مع شيربوينت يوجد استثمار كبير جدا من مايكرسفت في CSOM ... و لا اظنهم ستغنون عنه بسهوله !!

ماهي OData وماهي واجهة البرمجة REST API ؟

في بداية الالفية الماضية حدثت طفرة هائلة على مستوى صناعة خدمات الويب او ما يعرف  بالـ web services عندما تم اختراع بروتوكول SOAP 

Simple Object Access Protocol

و الذي يعتمد على XML عند  تشغيل عمليات خدمات الويب.

لكنه في الحقيقة و رغم التطور التقني الذي احدثه تسبب في تعقيد بعض الحلول التي كانت تبدو في غير حاجة الى كثير اجزاء ومكونات يتكلبها استهلاك SOAP...

لذلك ظهرت واجهة REST وهي الاختصار لـ REpresentational  State Transfer و الذي يتسم بالسهولة و الاعتماد الكلي على ثنائيات HTTP request/response  و على انواع المحتوى التالية المتداولة عبر الانترنت :

- text/html

- text/xml

- application/xml

- application/atom+xml

- application/json

لذلك فان REST API ليست تقنية جديدة بل مجموعة ممارسات جديدة مستخدمة في عمل و استهلاك خدمات الويب.

في المقابل OData هي عبارة عن مجموعة من واجهات REST تم دمجها وفق معايير محددة لتقوم بدور طبقة "الاتصال بالمعلومات" او "data access layer" لذلك لنقل من باب المجاز انها ADO.NET الخاص بالانترنت :) و التي تتيح الاستفادة من العمليات المعروفة على البيانات : انشاء , قراءة , تعديل , حذف باستخدام عمليات HTTP التالية : get, post, put, merge, delete
ولان OData يعتمد على REST لذلك فان الجهة التي ستقوم باستهلاكه عن بعد ستستهلك في الحقيقة روابط من نوع URI ...

تشخيص سريع و قوي و حل مشكلات تطبيقات الشيربوينت باعتماد Azure Application Insights - الحلقة 1

هل خطر ببالك ان تمتلك لوحة تحكم تعرض رسوما بيانية مباشرة و لحظية لحالة واداء تطبيقات الشيربوينت الخاصة بك مثل اللوحة التالية ؟ هل خطر ببالك متابعة حالة خوادم الشيربوينت و ادائها ؟

اذا كان لديك اشتراك MSDN فسيكون بامكانك الحصول على لوحة مماثلة في غضون دقائق . دعونا نتعرف على الخطوات اللازمة لذلك :

1- قم بالدخول على بوابة AZURE من خلال الرابط التالي https://portal.azure.com/

2- قم باضافة الخدمة من خلال الضغط على زر New ثم اختر مجموعة خدمات المبرمج Developer Services :

3 - قم باختيار Application Insights و ابدأ بعمل الاعدادات من خلال تعباة اسم اللوحة الجديدة و اختيار نوع التطبيق Asp.net Application :

4- ستظهر لك بعد اكمال الخدوات الشابقة لوحة تحكم بدون بيانات لذا اضغط على ايقونة السحابة التي ستفتح لك نافذة Quick Start :

5- قم بالضغط على "Get code to monitor my web pages" و ستظهر لك نافذة بها مقتطف كود بلغة JavaScript قم بنسخه و ادخاله في كود MasterPage الخاص بتطبيقك قبل سطر

 <head/>

وذلك لمتابعة جميع الشاشاة التي تسدعي ذلك MasterPage.

في صورة كنت ترغب في متابعة صفحة بعينها دون باقي صفحات الموقع قم بادخالها كما يلي :

الان ادخل مقتطف الكود في المربع : 

بعد الحفظ ستبدأ خدمة Azure بالتعرف على بيانات اداء الصفحات التي تاثرت بالاكواد المضافة قبل قليل . اذا كنت تريد ان تتعرف على اداء الخوادم ايضا قم بعمل التالي : 

6- قم بتنزيل الاداة من خلال الرابط المبين في الصورة ادناه :

7- قم بنقل الاداة و اسمها "ApplicationInsightsStatusMonitor.exe" الى الخادم الذي تريد متابعته و الذي يفترض ان يكون خادم ويب Front End Server .

بعد تثبيت الاداة سيكون لديك البرنامج التالي على الخادم :

8- قم بتفعيله من خلال الضغط على "Add Application Insights"  بعد ذلك قم بادخال معرف الخدمة الذي يظهر في الصورالتالية :

9 - بعد التفعيل فانك تحتاج الى اعادة تشغيل IIS :

10- اخيرا الخدمة جاهزة للاستخدام و التحليل :) 

في الحلقة المقبلة اعدكم بشرح مفصل لكل ميزة في هذه الخدمة التي اظنها ممتعة حقا ...