ماذا لو ... ؟ (2)

ماذا لو اتصل عليك احد مستخدمي الشيربوينت ليشتكي من ان حالة عناصر قائمة ما  (List) لا تتغير  و انه لم يعد يستقبل اي بريد تنبيهي من الشيربوينت بخصوص حالة العنصر كما كان الوضع طبيعيا منذ يوم فقط ... ؟

طبعا سيبدأ المستخدم بالخوف من الشيربوينت وربما بان يكره العمل عليه وحينها  ستكون الحالة صعبة بالفعل :)

في مثل هذه الحالة انصح بالعمل وفق المنهجية التالية لاكتشاف سبب الاشكال و كيفية حله و تجنبه مستقبلا :

1- قم بجمع كل ما يمكن جمعه من معلومات عن المشكلة من خلال التواصل مع المستخدم وان لزم الامر قم بالدخول على شاشته عن بعد ... 

2- بعد ان تعرفت من خلال الخطوة السابقة على القائمة التي توجد بها مشكلة و لانك تعرف جيدا جميع مكونات بيئة الشيربوينت لديك :) سترى ان القائمة قد تم ربطها مع نموذج الكتروني باستخدام InfoPath وايضا باجراء عمل شيربوينت (SharePoint workflow)  تم بناؤه عن طريق  SharePoint Designer . (افترضت ذلك لان موضوعنا هنا لا يتعلق باجراءات العمل المعقدة التي تبنى من خلال الاكواد البرمجية )

3- تحديد المشتبه بهم المحتملين في القضية :) 

* وذلك بالتاكد من ان خادم البريد الالكتروني يعمل بشكل صحيح ؟

* هل توجد ما مشكلة في الشبكة ؟

* هل خدمة workflow service تعمل على خادم الشيربوينت ام لا ؟

 4- قم بفتح قائمة Workflow History List والتي تحتوي على كل حالة الخطوات التي حدثت  على الاجراء. بصراحة الكثير لا يعرف هذه القائمة المهمة جدا والتي غالبا ما يكون رابط الدخول عليها كالتالي   http://[servername]/[sitename]/lists/Workflow%20History

هذه القائمة تساعد كثيرا في اكتشاف الاخطاء حيث انها تظهر خطوات الاجراء التي تفشل بشكل متكرر.

غالبا سيكون سبب الاشكال تحديث فني جديد تم على الاجراء عن طريق SharePoint Designer او InfoPath . في هذه الحالة سيكون الحل في اعادة رفع اجراء سليم (redeployment) .عندها اقترح عليك اعادة النظر في اجراءات الاختبار لديكم و التي تسبق الرفع على بيئة الانتاج !

ماذا لو... ؟ (1)

السلام عليكم

احببت ان اشارككم سلسلة من المواضيع الجديدة بعنوان "ماذا لو... ؟" والمقصود ان نقوم بدراسة بعض الحالات المتكررة التي قد يتعرض لها مدير او مبرمج الشيربوينت اثناء عمله اليومي.

والسؤال اليوم هو : ماذا لو لم تجد معرف الارتباط "correlation id" في سجلات الشيربوينت (SharePoint Diagnostic Logs) ؟

كثيرا ما نتعرض الى شاشة مثل التالية :)

هذا امر قد يكون اعتيادي لكن ما قد يسبب لديك مشكلة ان تقوم بالبحث في سجلات التدقيق الخاصة بجميع خواد المزرعة لكنك تتفاجئ ان معرف الارتباط الذي ظهر لك في الشاشة السابقة غير موجود نهائيا !!

هذا لو اعتبرنا انك تقوم بجلب وقراءة سجلات التدقيق بشكل صحيح :)

طيب في هذه الحالة لابد ان يتبادر الى ذهنك في الوهلة الاولى انه لسبب او لاخر قد تكون سجلات الشيربوينت Diagnostic Logs غير مفعلة !

للتاكد من ذلك قم بالدخول على شاشة لوحة التحكم التالية :

ستجد ان اي من انواع السجلات التي يمكن تسجيلها غير مفعل ! فما عليك الا تفعيلها. طبعا لابد ان تكون قبل ذلك قد قمت بتوفير المساحة اللازمة للقرص الصلب مع العلم ان مدة اسبوعين هي المدة الادني المنصوح بها للحفاظ على سجلات الشيربوينت ضمن المجلد المخصص لها قبل ان يتم حذفها آليا من قبل المهام الشيربوينت المجدولة (Timer Jobs) ....

تشخيص سريع و قوي و حل مشكلات تطبيقات الشيربوينت باعتماد 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 ... و لا اظنهم ستغنون عنه بسهوله !!