الخميس، 21 نوفمبر، 2013

مشكلة الـ Uploadify مع UAG (Unified Access Gateway)


يعتبر العنصر Uploadify.com من أشهر العناصر المستخدمة في تحميل الملفات بطريقة غير متزامنة علماً أنه يتوفر منه نسختين الأولى فلاش Flash والثانية HTML5. هذه المقالة تتحدث عن تجربة استخدام نسخة الفلاش من Uploadify مع خادم الـ UAG (Unified Access Gateway) الخاص بشركة مايكروسوفت حيث واجهتنا مشكلة ظهور الخطأ التالية:

500 internal server error

عند محاولة تحميل ملفات بغض النظر عن نوعها وأيضاً بغض النظر عن لغة البرمجة المستخدمة. وبعد محاولات كثيرة وبحث تم الاستعانة بشركة مايكروسوفت لحل هذه المشكلة وقد كان جواب مهندس مايكروسوفت كما يلي:



So Multipart/form-data is something that UAG does not support and also according to RFC http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html
The CRLF preceding the encapsulation line is considered part of the boundary so that it is possible to have a part that does not end with a CRLF (line break). Body parts that must be considered to end with line breaks, therefore, should have two CRLFs preceding the encapsulation line, the first of which is part of the preceding body part, and the second of which is part of the encapsulation boundary.
The requirement that the encapsulation boundary begins with a CRLF implies that the body of a multipart entity must itself begin with a CRLF before the first encapsulation line -- that is, if the "preamble" area is not used, the entity headers must be followed by TWO CRLFs. This is indeed how such entities should be composed. A tolerant mail reading program, however, may interpret a body of type multipart that begins with an encapsulation line NOT initiated by a CRLF as also being an encapsulation boundary, but a compliant mail sending program must not generate such entities.
Encapsulation boundaries must not appear within the encapsulations, and must be no longer than 70 characters, not counting the two leading hyphens.
The encapsulation boundary following the last body part is a distinguished delimiter that indicates that no further body parts will follow. Such a delimiter is identical to the previous delimiters, with the addition of two more hyphens at the end of the line:
     --gc0p4Jq0M2Yt08jU534c0p—
More info on page 30 : http://www.ietf.org/rfc/rfc1341.txt

أي أنه من الواضح وجود نقص في المعلومات التي يرسلها Uploadify (Flash Version) وعلى اعتبار أنه لا يمكن التعديل على شيفرة الفلاش فقد كانت نصيحة مهندس مايكروسوفت هي إيقاف عملية فحص المعلومات المرسلة من قبل العنصر Uploadify وبذلك يتم حل المشكلة. وبالفعل تم اتباع الخطوات التالية باستخدام UGA لإيقاف عملية فحص البيانات المرسلة من قبل Uploadify:

http://technet.microsoft.com/en-us/library/dd278134.aspx

علماً أنه في الخطوة رقم 5 يجب استخدام اسم الصفحة التي يُرسل إليها Uploadify البيانات وفي حالتنا كانت كما يلي:

./Uploadify\.ashx.*

ملاحظة: قد لا تظهر هذه المشكلة عند رفع ملف أكبر من 3 ميغا والسبب غير معروف أيضاً وقد يعود لآلية تعامل العنصر Uploadify مع الملفات وآلية رفعها.

شكر خاص للمهندس ياسين رحال لمساعدته في هذه المشكلة.




الاثنين، 18 نوفمبر، 2013

مقدمة إلى ميزة التخزين المجزأ في شيربوينت 2013


التخزين المجزأ في شيربوينت 2013 هو تحسين جديد على بيئة عمل شيربوينت والمرتبط بعملية تخزين البيانات الثنائية (الملفات) الكبيرة، مثل ملفات Word، PowerPoint وغيرها من الملفات الأخرى. ويعتبر التخزين المجزأ ميزة لتحسين أداء عمليتي القراءة والكتابة وتخفيض حيز التخزين اللازم لتخزين فقط التغييرات التي تمت على الملف. وقد تم بناء هذه الميزة باستخدام البروتوكول Cobalt.

البروتوكول Cobalt
عند حفظ ملف في شيربوينت 2010 تم فتحه باستخدام أحد برامج الأوفيس مثلاً، فإن التغييرات التي تمت على الوثيقة فقط يتم إرسالها إلى خادم الشيربوينت وبعدها يعمل الشيربوينت على تجميع التغييرات مع كامل أجزاء الوثيقة الأخرى وبعدها يتم حفظ الوثيقة في قاعدة البيانات. بينما تم تصميم التخزين المجزأ للتأكد من أن كلفة تحديث الملفات في قاعدة البيانات يتناسب مع التغييرات التي تمت على الملف ولا يتم إعادة حفظ كامل الملف مع التغييرات مرة أخرى. وشيربوينت 2013 يحفظ محتوى الملف كمجموعة من البيانات الثنائية المستقلة وهذا ما يسمى بالتخزين المجزأ وكل جزأ يحصل على رقم متسلسل يسمح بإعادة بناء الملف بشكل كامل من جديد عند الحاجة إليه.

بينما في شيربوينت 2010 عند تحميل ملف إلى مكتبة وثائق يتم إنشاء سجل جديد في الجدول AllDocStreams لتخزين المعلومات الثنائية للملف. وأيضاً يتم إرسال التغييرات فقط إلى خدم شيربوينت 2010 لكن يتم تخزين كامل الملف مع التغييرات مرة أخرى في سجل منفصل. وهذا حسن عملية استخدام الشبكة في شيربوينت 2010 لكن كان لم يخدم في عملية خفض كلفة حيز التخزين. وباستخدام التخزين المجزأ في شيربوينت 2013 تم تحسين هذه الميزة وذلك بتقسيم البيانات الثنائية لملف إلى أكثر من جزء ويتم تخزينها في جدول جديد اسمه DocStreams وكل جزء يحتوي على رقم ID متسلسل وعندما يحدث تغيير على الملف يتم تحديث فقط الجزء المتعلق بالتغيير الذي تم على الملف.

وبمقارنة سريعة بين تطبيق التخزين المجزأ في شيربوينت 2013 وبين آلية التخزين في شيربوينت 2010 فإن عمليات القراءة والكتابة انخفضت تقريباً بمعدل النصف مقارنة مع 2010 إضافة إلى خفض كبير في حيز التخزين.

مثلاً، في حال أن المستخدم يعمل على ملف Power Point حجمه 10 ميغا ونفذ بعض التعديلات عليه ومن ثم حفظ الملف مرة أخرى، عندها البروتوكول المحسن في شيربوينت 2013 المسؤول عن عملية التخزين المجزأ يعمل على تعديل السجلات الموجودة في الجدول DocStreams المرتبة بالتغيير الذي حدث.

الجدول DocStreams
يتم إنشاء الجدول DocStreams في كل قاعدة بيانات محتوى في شيربوينت 2013 حيث يتم تخزين كل جزء من المحتوى الثنائي المجزأ في سجل، علماً أنه تمت إضافة الأعمدة التالية إلى الجدول للتعامل مع عملية التخزين المجزأ:
  • BSN: رقم تسلسلي يحدد ترتيب الجزء ضمن جميع الأجزاء التابعة لنفس المحتوى الثنائي.
  • Data: يحتوي على جزء من البيانات الثنائي إلا إن كان المحتوى الثنائي مخزن باستخدام تقنية الـ RBS (Remote BLOB Storage) أي حيز التخزين البعيد.
  • Offset: الإزاحة ضمن المحتوى الثنائي الذي ينتمي إليه الجزء.
  • Length: حجم جزء المحتوى الثنائي بالبايتات.
  • RbsId: في حال أن جزء المحتوى الثنائي مخزن باستخدام تقنية RBS عندها يجب أن يحتوي معرف يشير إلى الـ RBS وإلا قيمة هذا العمود تكون تساوي NULL.
ملاحظة: بشكل افتراضي ميزة التخزين المجزأ تكون مفعلة ولا يمكن إيقافها.

الخاصية FileReadChunkSize
تم إضافة الخاصية FileReadChunkSize في شيربوينت 2010 كخاصية تحكم مرتبطة بالتخزين المؤقت للبيانات الثنائية BLOB Cache والتي تسمح لمدير بيئة عمل شيربونيت التحكم بحجم البيانات التي سيتم إرسالها في حال طلب ملف من قبل المستخدم. علماً أن خاصية التخزين المؤقت للبيانات الثنائي BLOB Cache تُستخدم عند طلب بيانات ثنائية مثل الصور وملفات الفيديو. وفي حال أن الملف المطلوب حجمه أصغر من قيمة الخاصية FileReadChunkSize (القيمة الافتراضية 100 كيلو) أو يساوي قيمة الخاصية LargeFileChunkSize (القيمة الافتراضية تساوي 5 ميغا) عندها يتم إحضار معلومات الملف من خادم قواعد البيانات مباشرة.

الخاصية FileWriteChunkSize
تُستخدم هذه الخاصية للتحكم بحجم جزء التخزين المجزأ الواحد. ويجب الانتباه إلى أن تحديد قيمة غير مدروسة بشكل صحيح لهذه الخاصية قد تؤدي إلى مشاكل في أداء بيئة عمل الشيربوينت عند استخدام قيمة صغيرة جداً في وقت يتم فيه استخدام ملفات الفيديو بشكل متكرر.