يسمح لنا Salesforce بمعالجة أو تنفيذ عدد معين من البيانات / السجلات في وقت واحد. هناك بعض الحدود لبيانات DML ، وفئات Apex ، وما إلى ذلك ، للتنفيذ أو المعالجة. تُعرف هذه الحدود باسم حدود الحاكم. في هذا البرنامج التعليمي ، سنرى ما هي حدود الحاكم وكيف يمكن التعامل معها. أيضًا ، توفر Salesforce Apex فئة 'الحد' لمعرفة الحدود المتعلقة بوسائل الشرح وفئات Apex ومكونات الويب البرق وبيانات SOSL و SOQL.
حدود الحاكم
ضع في اعتبارك سيناريو يكون فيه Alish و Subash شخصان يستخدمان Salesforce org. تريد أليس معالجة أو تنفيذ 1000 عبارة DML في معاملة واحدة. بالتوازي مع ذلك ، يريد Subash تحميل 5000 سجل في وقت واحد. إذا فعلوا ذلك بالتوازي ، فلن يقبل Salesforce ويصبح محمومًا. ومن ثم ، تأتي حدود الحاكم في الصورة. في هذه الحالة ، يمكن لـ Alish معالجة 100 DML في وقت واحد ويمكن لـ Subash معالجة 500 سجل في المرة الواحدة. يمكنهم استخدام AsynchronousBatch Apex للقيام بكل معاملة على سلسلة منفصلة دون إزعاج كل منهم وإكمال مهمتهم.
بشكل أساسي ، تحد حدود الحاكم في Salesforce من المعالجة والتنفيذ في معاملات متعددة. تحسب 'حدود Apex لكل معاملة' لكل معاملة ويتعامل 'حد Apex المخصص للحجم' مع حجم الكود. تدعم Salesforce عمليتين: العمليات المتزامنة وغير المتزامنة. في العملية المتزامنة ، يتم تنفيذ البرنامج النصي Apex دفعة واحدة أثناء العملية غير المتزامنة ، يتم تنفيذ البرنامج النصي Apex عن طريق الانقسام إلى مهام متعددة.
الحدود المسموح بها
دعونا نناقش الحد الأقصى للسيناريوهات المختلفة:
- يمكن معالجة / تشغيل 100 استعلام SOQL في Apex المتزامن و 200 استعلام SOQL في Apex غير المتزامن.
- سيتم إرجاع 50000 سجل فقط من استعلام SOQL لكل من القمة المتزامنة وغير المتزامنة.
- إذا استخدمنا Database.getQueryLocator () ، فسيتم إرجاع 10000 فقط في المرة لكل من Apex المتزامن وغير المتزامن.
- في كلا السيناريوهين ، يبلغ عدد استعلامات SOSL الصادرة 20.
- حجم الكومة المطلوب لمعالجة Apex المتزامن هو 6 ميغا بايت. بالنسبة إلى Apex غير المتزامن ، يكون حجم الكومة المطلوب ضعفًا مما يجعله 12 ميجابايت.
- الحد الأقصى لوقت وحدة المعالجة المركزية المسموح به لـ Apex المتزامن هو 10000 مللي ثانية و 60.000 مللي ثانية للـ Apex غير المتزامن.
- يُسمح فقط بـ 10 دقائق للتنفيذ لكل من Apex.
- في كلتا الحالتين ، لا يمكننا استخدام سوى 10 طريقة sendEmail () مع 100 مستلم.
- يجب أن تكون الأحرف الموجودة في فئة Apex أو في مشغل Apex في حدود مليون شخص.
- في Batch Apex (غير متزامن) ، الحجم هو 200. ترجع QueryLocator () من فئة 'قاعدة البيانات' 50 مليون سجل لكل معاملة.
- فقط 5 مهام Apex ستكون في قائمة الانتظار أو نشطة.
مثال على فئة LIMIT:
يمكن أن تحدد Apex حدود الحاكم في فئة 'LIMIT'. توفر هذه الفئة بعض الطرق التي تخبر حدود الحاكم. لنلق نظرة على المثال التالي الذي يعرض بعض حدود الحاكم:
System.debug ('عدد الاستعلامات المجمعة التي يمكن معالجتها:' + Limits.getLimitAggregateQueries ())؛
System.debug ('عدد عبارات خدمة الويب التي يمكن معالجتها:' + Limits.getLimitCallouts ())؛
System.debug ('عدد السجلات يمكن معالجتها:' + Limits.getLimitDmlRows ())؛
System.debug (يمكن استدعاء عدد عبارات DML: '+ Limits.getLimitDmlStatements ())؛
System.debug ('إجمالي حجم الذاكرة بالبايت:' + Limits.getLimitHeapSize ())؛
System.debug ('يمكن إصدار عدد استعلامات SOQL:' + Limits.getLimitQueries ())؛
System.debug ('يمكن إصدار عدد السجلات:' + Limits.getLimitQueryRows ())؛
System.debug ('عدد استعلامات SOSL التي يمكن إصدارها:' + Limits.getLimitSoslQueries ())؛
انتاج:
يمكن أيضًا التحقق من عدد عبارات / صفوف DML التي يمكن إرجاعها باستخدام طرق 'dome' الموجودة في فئة 'LIMIT'.
- Limits.getDMLStatements () يُرجع إجمالي عبارات DML المستخدمة في مثيل.
- Limits.getDMLRows () يُرجع العدد الإجمالي للصفوف التي تم إرجاعها بواسطة عبارات DML.
- Limits.getCpuTime () إرجاع وقت استخدام وحدة المعالجة المركزية (CPU) للمعاملة الحالية بالمللي ثانية.
مثال على الاستخدام:
دعنا نكتب استعلام SOQL الذي يُرجع السجلين من كائن 'WorkOrder'. بعد ذلك ، احذف هذين السجلين باستخدام 'حذف' DML.
System.debug ('عبارات DML:' + Limits.getDMLStatements ()) ؛System.debug ('Rows:' + Limits.getDmlRows ()) ؛
System.debug ('CPU Time' + Limits.getCpuTime ()) ؛
// SOQL Query لتحديد صفين من كائن WorkOrder
قائمة حسابات
// استخدم حذف DML لحذف صفين
حذف الحسابات
System.debug ('** بعد SOQL: **') ؛
System.debug ('عبارات DML:' + Limits.getDMLStatements ()) ؛
System.debug ('Rows:' + Limits.getDmlRows ()) ؛
System.debug ('CPU Time' + Limits.getCpuTime ()) ؛
انتاج:
في المثال المعطى ، لا توجد عبارات DML و 0 صفوف. وقت وحدة المعالجة المركزية الحالي هو 1 مللي ثانية. بعد إرجاع صفين من استعلام SOQL وحذف هذين الصفين ، يكون إجمالي عدد عبارات DML التي تم إرجاعها بواسطة Limits.getDMLStatements () هو 1 ، وإجمالي الصفوف التي تم إرجاعها بواسطة Limits.getDMLRows () هو 2 ، ووحدة المعالجة المركزية الوقت اللازم لتنفيذ هذه المعاملة هو 51 مللي ثانية.
مثال على أفضل الممارسات: 'لا تستخدم DML داخل الحلقة'
دعونا نرى كيف يمكننا تشغيل الكود دون الحصول على حد الحاكم. نقوم أولاً بإنشاء سجل على كائن 'المنتج' (API - Product2) من كائن 'WorkOrder' من خلال تعيين 'WorkOrder' موضوع 'اسم المنتج' في حلقة 'for' نفسها. دعونا نرى الكود التالي:
المنتج 2 prod_obj ؛لـ (WorkOrder wo_object: [حدد الموضوع من WorkOrder])
{
prod_obj = منتج 2 جديد (الاسم = wo_object.Subject) ؛
أدخل prod_obj ؛
}
يمكننا القيام بذلك بطريقة أفضل من خلال إعلان قائمة (prod_s) ثم تخزين prod_obj في القائمة. يمكننا إدراج هذه القائمة في المنتج خارج الحلقة.
قائمةالمنتج 2 prod_obj ؛
لـ (WorkOrder wo_object: [حدد الموضوع من WorkOrder])
{
prod_obj = منتج 2 جديد (الاسم = wo_object.Subject) ؛
prod_s.add (prod_obj) ،
}
أدخل prod_obj ؛
خاتمة
لقد تعلمنا الآن ما هي حدود Apex في Salesforce مع شرح مفصل. من الأفضل استخدام عملية Apex غير المتزامنة للحصول على حدود حاكم أفضل عند مقارنتها بـ Synchronous Apex. تعرفنا أيضًا على حدود الحاكم لسيناريوهات مختلفة وقدمنا عينة توضيحية بخصوص عدد الحد من فئة 'الحد'. لقد تحققنا أيضًا من عدد عبارات DML والصفوف ووقت وحدة المعالجة المركزية عن طريق تشغيل عبارة DML واحدة. اختتمنا هذا الدليل بمناقشة أحد أمثلة أفضل الممارسات.