التقاط البيانات من خدمة ويب .Net التي تفشل بسبب رمز خطأ HTTP 500

Question

لدي خدمة ويب .net مستضافة في IIS 6.0 والتي تفشل بشكل دوري مع http 500 لأن العميل يتصل بها ببيانات لا تتطابق مع wsdl.

أشياء مثل وجود عنصر محدد في إحدى الطرق على أنه من النوع int وعنصر xml الوارد يحتوي على رقم عشري.

تعريف عنصر WSDL:

<s:element minOccurs="1" 
    maxOccurs="1" 
    form="unqualified" name="ItemCount" type="s:int" >  

العنصر المقدم:

<ItemCount>1.0</ItemCount>

يؤدي هذا إلى ترك خطأ 500 في سجلات IIS ولكن لا يتم إرجاع أي معلومات حول خطأ الصابون أو بيانات الإدخال التي تسببت في الخطأ.

لقد قمت حاليًا بتشخيص العديد من المشكلات المتعلقة بالبيانات المقدمة من خلال التقاط كل شيء باستخدام wireshark ولكني أرغب في معرفة الخيارات الأخرى التي ربما تكون أقل تدخلاً.

هل هناك أي طريقة لالتقاط البيانات المرسلة والتي تسبب الأخطاء الـ 500 (نأمل أن يتم التقاط البيانات فقط عند حدوث الخطأ 500)؟ربما عن طريق:

• تكوين IIS
• تكوين خدمة الويب
• تغيير رمز خدمة الويب

يحرر بعد اختبار الإجابة المقدمة من tbreffni

الإجابة التي تناسب ما كنت عليه بعد tbreffni - كانت هناك العديد من الاستجابات الجيدة الأخرى ولكن الإجابة تسمح بالتقاط الحمولة النافعة التي تسبب أخطاء إلغاء التسلسل دون تشغيل شيء مثل عازف الكمان أو wireshark.

تعتبر المعلومات المتعلقة بالحصول على ملحق SOAP للتشغيل خفيفة بعض الشيء، لذا فقد قمت بتضمين الخطوات التي وجدتها ضرورية أدناه:

• أنشئ امتداد SOAP كملف .dll وفقًا لملف MSDN شرط
• أضف ملف .dll إلى دليل bin لتتبع الخدمة

• في web.config الخاص بالخدمة المراد تتبعها، قم بإضافة ما يلي إلى قسم خدمات الويب، مع استبدال SOAPTraceExtension.TraceExtension وSOAPTraceExtension لمطابقة الامتداد الخاص بك.

  <خدمات الويب>
  <soapExtensionTypes>
  <add type="SOAPTraceExtension.TraceExtension، SOAPTraceExtension" الأولوية = "1" المجموعة = "0"/>
  </soapExtensionTypes>
  </ويب سيرفيسز>

Answer 1

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

لتنفيذ معالج الاستثناء لخدمة ويب .Net، تحتاج إلى إنشاء ملحق SOAP.انظر ما يلي مقالة MSDN على سبيل المثال.لقد استخدمت هذا النهج في العديد من خدمات الويب الخاصة بالإنتاج، وكان لا يقدر بثمن في تحديد المشكلات التي تحدث ومكان حدوثها.

Answer 2

سأحاول العابث أو هنا.ليس خصيصًا لخدمات الويب وعادةً ما يكون مخصصًا لجانب العميل، ويمكن استخدامه كطريقة عكسية الوكيل.

إنه قادر جدًا على استخدام البرنامج النصي ويدرك "الطلب/الاستجابة" لذلك أعتقد أنه من المحتمل أن تتمكن من التقاط 500 خطأ فقط.

Answer 3

لم أستخدم هذا بنفسي مطلقًا، لكنني وجدت هذا للتو في MSDN: تمكين التتبع في خدمات ويب ASP.NET

Answer 4

هل نظرت إلى التتبع المستند إلى طلب IIS ؟: http://technet.microsoft.com/en-us/library/cc786920.aspx

Answer 5

بعد بعض التفكير، أفضل حل يمكنني رؤيته حاليًا هو تجميع خدمة ويب واجهة خفيفة الوزن تقبل كائن XML كمدخل.

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

• التعامل مع أي أخطاء، وتسجيل البيانات المصدر وخطأ الصابون الذي تم إرجاعه
• تمرير مرة أخرى إلى العميل الردود من البيانات الجيدة

سيكون هذا مجرد إجراء مؤقت (أنا أعارض بشدة خدمات الويب غير الواضحة بشأن XML التي يقبلونها) ولكنه ربما يمنحني المزيد من النفوذ للتغلب على حدبة تشخيص الأخطاء مثل هذه في الإنتاج حيث يكون العميل الاتصال بخدمة الويب لا يحترم wsdl أو القدرة على قراءة أخطاء الصابون التي تم إرجاعها.

لحسن الحظ في هذه الحالة، لا يوجد سوى طرف واحد يقوم بالنشر على خدمة الويب - طرق اكتشاف الحزم (عازف الكمان أو Wireshark) ممكنة ولكن عدم تسجيل 500 خطأ جعلني أفكر "ما هي الخيارات الأفضل الموجودة؟".

Answer 6

إذا كنت تريد استخدام أداة، فاستخدم WireShark.

بخلاف ذلك، فإن أسهل طريقة هي التقاط "كل شيء" (على افتراض أنك تستخدم ASMX) وهي تمكين التتبع على system.net.

http://blogs.msdn.com/dgorti/archive/2005/09/18/471003.aspx

إذا كنت تستخدم WCF، فهو يتمتع بدعم رائع للتتبع ويمكنك استخدام svctraceviewer لعرض سجلات التتبع.لا يبدو أنك تستخدم WCF بالرغم من ذلك.