حدود واجهة برمجة التطبيقات (API Limits) في Salesforce: تخطيط التكاملات للتعامل مع الأحمال والاسترداد

ما الذي يتعطل أولاً عند تجاهل حدود واجهة برمجة التطبيقات (API Limits)

الشركة التي تدير ثلاث عمليات تكامل في وقت واحد - مزامنة ليلية لنظام تخطيط موارد المؤسسات (ERP)، وخطاف ويب (Webhook) من نظام دفع، ولوحة تحكم خارجية تسحب البيانات كل خمس دقائق - لا تتعطل تدريجياً. بل تعمل بشكل ممتاز حتى تتجاوز حداً معيناً، وعندئذٍ تُرفض كل استدعاء إضافي لواجهة برمجة التطبيقات (API) برمز REQUEST_LIMIT_EXCEEDED حتى يتم إعادة التعيين اليومي. لا يوجد إنذار مبكر مدمج يمنع ذلك مقدماً - هناك فقط لوحة تحكم (Dashboard) يمكن النظر إليها، إذا كان أحدهم قد بنى عملية للتحقق منها.

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

خريطة الحدود ذات الصلة عملياً

ليس كل حد موجود في Salesforce مهم بنفس القدر لتصميم عمليات التكامل. هذه هي التي تحدد الهندسة المعمارية بالفعل:

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

ميزانية الاستدعاءات: كيف تبنيها بشكل صحيح

الأداة الرئيسية لمنع الحظر ليست المراقبة بعد وقوع الحدث، بل هي ميزانية محددة مسبقاً لكل مستهلك لواجهة برمجة التطبيقات (API). المبدأ هو: كل نظام خارجي، وكل مستخدم تكامل (Integration User)، وكل عملية مجدولة تحصل على تخصيص محدد من الحصة الإجمالية، بدلاً من الحصول على "قدر ما يلزم".

يتضمن بناء الميزانية ثلاث مراحل:

1. رسم خرائط المستهلكين - قائمة بكل عملية تستدعي واجهة برمجة التطبيقات (API): عمليات التكامل الخارجية، Apex المجدول (Scheduled Apex)، Data Loader اليدوي، أدوات ذكاء الأعمال (BI). لكل منها مستخدم تكامل (Integration User) منفصل لتمكين عزل الاستهلاك في Event Monitoring.
2. حساب الحمل بناءً على حجم العمل، وليس على الافتراضات - كم عدد السجلات التي يتم نقلها يومياً، وكم عدد الاستدعاءات المطلوبة لكل سجل (بما في ذلك استرداد القوائم ذات الصلة)، وماذا يحدث في أوقات الذروة (نهاية الربع، Black Friday، إغلاق الشهر).
3. تخصيص احتياطي - لا يتم تقسيم 100% من الحصة بين العمليات القائمة. يتم الاحتفاظ بـ 15% - 20% كاحتياطي للعمليات الطارئة، والتقارير المخصصة (ad-hoc)، والصيانة - وإلا فإن أي إضافة صغيرة تدفع المؤسسة إلى تجاوز الحد الأقصى.

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

REST مقابل Bulk: متى يصبح التبديل مجدياً

الخطأ الأكثر شيوعاً هو استخدام واجهة برمجة تطبيقات REST API عادية لنقل البيانات بكميات كبيرة، لأن هذا هو ما يتم بناؤه أولاً ويعمل في إثبات المفهوم (PoC). تظهر المشكلة عندما يزداد الحجم: يحسب REST كل طلب (حتى 200 سجل في Composite) كاستدعاء منفصل مقابل الحصة، بينما ينفذ Bulk API 2.0 دفعات تصل إلى 10,000 سجل ويتم احتسابه بتكلفة أقل بكثير لكل سجل.

قاعدة إرشادية عملية: إذا كانت عملية واحدة تقوم بتحديث أكثر من حوالي 2000 سجل في تشغيل واحد، فإن الانتقال إلى Bulk API يكاد يكون مجدياً دائماً - حتى لو كان ذلك يعني تغيير رمز المستهلك للعمل بشكل غير متزامن مع الاستقصاء (Polling) حول حالة المهمة بدلاً من الاستجابة الفورية. الثمن هو زمن استجابة (Latency) أعلى (دقائق بدلاً من ثوانٍ)، ولذلك فإن Bulk API غير مناسب للعمليات التي تتطلب قراراً في الوقت الفعلي، مثل التحقق من المخزون قبل تأكيد الطلب.

Backoff و Retry: منع الإغراق الذاتي

عندما يفشل استدعاء API بسبب تجاوز الحد الأقصى (Limit), فإن الاستجابة الفطرية لمعظم الفرق هي المحاولة مرة أخرى على الفور. هذا بالضبط هو السلوك الذي يحوّل الحظر المؤقت إلى مشكلة مستمرة: إذا حاولت عشر عمليات مرة أخرى في نفس اللحظة, فإنها تدفع النظام أعمق في الحظر بدلاً من السماح له بالتعافي.

تتطلب آلية Backoff الصحيحة ثلاثة مكونات معاً:

• Exponential Backoff - يتزايد وقت الانتظار بين المحاولات بشكل أسي (على سبيل المثال 2, 4, 8, 16 ثانية), ولا يبقى ثابتاً.
• Jitter - إضافة عشوائية صغيرة لوقت الانتظار, حتى لا تحاول العمليات المتوازية مرة أخرى في نفس الثانية بالضبط وتخلق موجة جديدة من الحمل.
• Circuit Breaker - بعد عدد متتالٍ من الفشل (على سبيل المثال خمسة), تتوقف العملية تماماً عن المحاولة لفترة زمنية محددة وتبلغ عن ذلك لأنظمة المراقبة, بدلاً من الاستمرار في "طرق الباب".

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

سيناريو: تجارة تجزئة بثلاث نقاط تكامل

لنفترض أن هناك شبكة تجزئة متوسطة الحجم، تضم حوالي 40 فرعًا، وتدير Salesforce Service Cloud مع نظام نقطة البيع (POS) ونظام تخطيط موارد المؤسسات (ERP) للمخزون. ثلاث عمليات تكامل نشطة: مزامنة المخزون كل 15 دقيقة من نظام ERP (حوالي 8,000 منتج)، وخطاف ويب (Webhook) من نظام POS في كل معاملة تفشل (حوالي 300 في اليوم)، ولوحة تحكم خارجية لـ Power BI تسحب بيانات الخدمة كل ساعة.

في الشهر الذي أضافت فيه الشبكة برنامج ولاء جديدًا، دخلت عملية تكامل رابعة: التحقق من نقاط الولاء في الوقت الفعلي من Salesforce من كل نقطة بيع، ما أضاف حوالي 6,000 استدعاء إضافي يوميًا. في غضون أسبوعين، بدأت مزامنة المخزون تفشل حوالي الساعة 2-3 مساءً، وهي ساعة الذروة لنقاط البيع. قام الفريق في البداية بفحص نظام ERP وظنوا أن المشكلة هناك، لكن سجلات Salesforce أظهرت REQUEST_LIMIT_EXCEEDED بالضبط في هذه الفترة الزمنية.

لم يكن الحل هو شراء حصة إضافية، بل كان تغيير الأولويات: تم نقل التحقق من نقاط الولاء للاستخدام في Platform Cache للنتائج التي لا تتغير بشكل متكرر، مما قلل الاستدعاءات بحوالي 70%، وتم نقل مزامنة المخزون من REST إلى Bulk API مع تشغيل كل 30 دقيقة بدلاً من 15. النتيجة: نفس التغطية التجارية، استهلاك حصة أقل بنسبة 45%، واحتياطي حقيقي للنمو القادم.

المخاطر وإجراءات الوقاية المحددة

قائمة التحقق قبل إضافة تكامل جديد

• معرفة النسبة المئوية من الحصة اليومية المستهلكة حالياً، حسب Integration User
• فحص حجم الذروة (وليس متوسط الحجم) للتكامل الجديد
• اتخاذ قرار بين REST و Bulk API بناءً على حد الحجم، وليس بناءً على سهولة التطوير
• وجود آلية Backoff مع Jitter و Circuit Breaker في رمز المستهلك (Consumer Code)
• تعريف تنبيه عندما يتجاوز استهلاك الحصة اليومية 70%
• فحص الاستخدام المحتمل لـ Platform Cache لتقليل الاستدعاءات المتكررة
• وجود احتياطي بنسبة 15% - 20% من الحصة لم يُخصص مسبقاً
• تحديد مالك تشغيلي (Operational Owner) يتلقى التنبيه وليس فقط سجلاً تقنياً

كيفية مراقبة ذلك بشكل مستمر

تتطلب المراقبة الموثوقة مزيجًا من ثلاثة مصادر: Event Monitoring (أو Shield Event Monitoring) لاستهلاك واجهة برمجة التطبيقات (API) الفعلي حسب المستخدم، و Apex Limits في الرمز البرمجي نفسه (Limits.getLimitApiRequests()) للتحقق المحلي في وقت التشغيل، ولوحة التحكم المدمجة تحت Company Information التي تعرض الاستهلاك مقابل الحصة على مستوى المؤسسة. لا يكفي أي من هذه المصادر بمفرده: الأول يظهر الاتجاه، والثاني يمنع الفشل داخل عملية واحدة، والثالث يعمل كحالة يومية لفريق التشغيل.

المقياس الذي يجب مراقبته على المدى الطويل ليس فقط "كم تم استهلاكه" بل "ما هو معدل النمو الشهري في الاستهلاك" - لأن هذا هو ما يسمح بالتنبؤ متى ستصل المؤسسة إلى الحد الأقصى، بدلاً من الاستجابة بعد وقوع الحظر بالفعل. عندما تكون هناك عدة أنظمة تعتمد على بعضها البعض، فمن المفيد أيضاً فحص نمط التكامل الكلي مقابل ربط Salesforce بأنظمة ERP، ومسألة التنفيذ - Flow مقابل Apex - والتي تؤثر أيضاً على كفاءة الاستدعاءات، في Salesforce Flow أو Apex.

ملخص

Salesforce API Limits ليست مشكلة يتم حلها بمجرد اكتشافها - بل هي متغير يجب أن يكون جزءًا من كل قرار تكامل منذ اليوم الأول. ميزانية طلبات موثقة حسب Integration User، اختيار واعي بين REST و Bulk بناءً على الحجم، وآلية Backoff تمنع الإغراق الذاتي - هذه الثلاثة معًا هي ما يميز المؤسسة التي تكتشف المشكلة عندما تكون محظورة بالفعل، عن المؤسسة التي ترى المشكلة تقترب قبل شهر وتتصرف في الوقت المناسب.