يربط CRM خدمة خارجية، فتصل رسالة خطأ نصية تتغير عند تبديل اللغة. يعتمد التكامل على كلمة داخل الرسالة ثم يتوقف عن تصنيف المشكلة بعد تعديل الصياغة. الحل يبدأ بعقد للخطأ يفصل ما يقرؤه الإنسان عما يستخدمه البرنامج لاتخاذ القرار.
اختر هوية مستقرة لنوع المشكلة
تحدد مواصفة RFC 9457 صيغة Problem Details، ومنها application/problem+json. يمثل type هوية نوع المشكلة، بينما يقدم title ملخصًا بشريًا وdetail شرحًا لهذه الواقعة. وتوصي المواصفة بعدم تحليل detail برمجيًا لاستخراج معلومات؛ يمكن تعريف حقول امتداد واضحة عند الحاجة.
اقترح للتكامل التجريبي نوعًا موثقًا لمشكلة رفض الانتقال بين مراحل البيع، بدل البحث عن كلمة «مرفوض». لا تجعل ترجمة الرسالة تغير هوية النوع. وإذا وفرتم instance لتتبع الواقعة، فحددوا من يستطيع فتح التفاصيل المرتبطة به، ولا تجعلوا معرفه تصريح وصول.
طابق جسم الخطأ مع HTTP
إذا أُرسل الحقل status في الجسم، تلزم المواصفة جهة التوليد باستعمال الرمز نفسه في استجابة HTTP الفعلية. لا ترد 200 ثم تضع 403 داخل JSON وتفترض أن المراقبة والمكتبات ستفهم الفشل. راقب العناوين والرمز والجسم من طلب حقيقي في بيئة الاختبار.
| حالة مصطنعة | دليل القبول |
|---|---|
| تغيير لغة الرسالة | يبقى تصنيف النوع ثابتًا |
| وجود status في الجسم | يطابق رمز HTTP الصادر |
| امتداد غير معروف للعميل | لا يكسر قراءة الحقول المعروفة |
| خطأ داخلي متعمد | لا يكشف تفاصيل تشغيل حساسة |
اكتب تفصيلًا يساعد على التصحيح
قل ما يستطيع المستخدم فعله ضمن صلاحياته، مثل استكمال حقل مطلوب. لا تنسخ stack trace أو استعلام SQL أو مسار الخادم أو رمز وصول إلى الرد. اجعل المعلومات التشخيصية المحمية في سجل مناسب، واربط البلاغ بمعرف غير سري يتيح لفريق الدعم التحقيق.
اعتمد العقد مع المستهلك
في تكامل أنظمة CRM راجع عينات الردود مع فريق الفحص التقني، واختبر المستهلك نفسه بدل صحة JSON فقط. معيار القبول أن يصنف التكامل الخطأ دون تخمين نصي، ويعرض للمستخدم خطوة مفهومة مع بقاء تفاصيل التشغيل محمية.
