حدود النظام الأساسي
لا يوفر النظام الأساسي قدراً غير محدود من الموارد، ويتم فرض قيود على عدد استدعاءات API التي يمكن إجراؤها.
يحتاج مهندس الحلول إلى التأكد من أن الحل لا يتجاوز الحدود التي يفرضها النظام الأساسي من خلال التصميم المناسب والتأكد من أن الكود المخصص يمكنه المعالجة عند انتهاك الحدود.
طلبات API
وتتكون الطلبات فِي Microsoft Power Platform من إجراءات متنوعة يقوم بها المستخدم عبر المنتجات المختلفة. تصف القائمة التالية ما يشكل طلب API، على مستوى عالٍ:
- Power Apps - جميع طلبات API إلى الموصلات وMicrosoft Dataverse.
- Power Automate - جميع طلبات API إلى الموصلات، وإجراءات HTTP، والإجراءات المضمنة من تهيئة المتغيرات إلى إجراء إنشاء بسيط. يتم احتساب كل من الإجراءات الناجحة والفاشلة ضمن هذه الحدود. بالإضافة إلى ذلك، تعد عمليات إعادة المحاولة والطلبات الأخرى من ترقيم الصفحات عمليات تنفيذ للإجراء. كقاعدة أساسية، كل خطوة فِي تدفق سحابة Power Automate عبارة عن طلب API.
- Dataverse- جميع عمليات الإنشاء والقراءة والتحديث والحذف (CRUD) وتعيين العمليات ومشاركتها، بما فِي ذلك طلبات النظام الداخلية المستندة إلى المستخدم والمطلوبة لإكمال حركات CRUD، بالإضافة إلى العمليات الخاصة مثل المشاركة أو التعيين. يمكن أن تكون هذه الطلبات من أي عميل أو تطبيق ويمكن أن تستخدم أي نقطة نهاية. تتضمن هذه الطلبات، على سبيل المثال لا الحصر، المكونات الإضافية ومهام سير العمل الكلاسيكية وعناصر التحكم المخصصة التي تنفذ العمليات المذكورة سابقاً.
حدود الاستحقاق
تمثل حدود الاستحقاق عدد طلبات API التي يحق للمستخدمين تقديمها كل يوم. يعتمد الحد المخصص على نوع الترخيص الذي تم تعيينه لكل مستخدم. تستند حدود استحقاق API إلى فترة 24 ساعة، على النحو الموضح فِي الجدول التالي.
| المنتجات | طلبات لكل ترخيص مدفوع لكل 24 ساعة |
|---|---|
| مستخدمو ترخيص Power Platform المدفوع (باستثناء Power Apps لكل تطبيق، وPower Automate لسير العمل، وPower Virtual Agents) وDynamics 365 باستثناء Dynamics 365 Team Member | 40,000 |
| خطة للدفع حسب الاستخدام من Power Apps، ومستخدمو ترخيص Power Apps المدفوع لكل تطبيق، وتطبيقات Microsoft 365 مع الوصول إلى Power Platform، وDynamics 365 Team Member | 6,000 |
| خطة Power Automate لكل سير عمل، وعرض Power Virtual Agents الأساسي، وحزمة الوظائف الإضافية فِي Power Virtual Agents | 250,000 |
| تسجيل الدخول إلى مداخل Power Apps المدفوعة | 200 |
يوفر Dataverse القدرة على الحصول على هويات لا تتطلب ترخيص مستخدم للتفاعل مع الخدمة. الأنواع الأربعة للمستخدمين هي:
- مستخدمو التطبيق
- المستخدمون غير التفاعليون
- المستخدمون الإداريون
- مستخدم النظام
يتمتع كل مستأجر بقدرة طلب أساسية لكل مستأجر لا يمكن استخدامها إلا من قبل هؤلاء المستخدمين وليس من قبل المستخدمين الذين لديهم تراخيص قياسية. تعتمد سعة الطلب الأساسية هذه على نوع الاشتراك، على النحو التالي:
- إذا كان لدى المستأجر اشتراك Dynamics 365 enterprise واحد على الأقل، يحصل على 100,000 طلب كل 24 ساعة.
- إذا كان لدى المستأجر اشتراك Dynamics 365 professional واحد على الأقل، يحصل على 50,000 طلب كل 24 ساعة.
- إذا كان لدى المستأجر اشتراك Microsoft Power Apps أو Power Automate واحد على الأقل، يحصل على 25,000 طلب كل 24 ساعة.
يسمح المكون الإضافي لسعة Power Apps وPower Automate للعملاء بزيادة الحدود المعينة لكل مستخدم. يزيد كل مكون إضافي للسعة من حدود الطلب بمقدار 10,000 طلب آخر كل 24 ساعة.
ملاحظة
للحصول على مزيد من المعلومات، راجع حدود طلب API.
حدود الخدمة
بصرف النظر عن الحد اليومي لطلب API، تتوفر حدود حماية الخدمة الخاصة بكل خدمة. كما هو الحال مع الحدود اليومية، تساعد حدود الخدمة على الحفاظ على جودة الخدمة من خلال حماية الخدمة من السلوك الضار أو الصاخب الذي قد يؤدي بخلاف ذلك إلى تعطيل الخدمة لجميع العملاء.
تساعد حدود API لحماية الخدمة على ضمان عدم قدرة المستخدمين الذين يقومون بتشغيل التطبيقات على التداخل بعضهم مع بعض بناءً على قيود الموارد. لن تؤثر الحدود على المستخدمين العاديين للنظام الأساسي. قد تتأثر فقط التطبيقات التي تؤدي العديد من طلبات API. توفر الحدود مستوى من الحماية من الزيادات العشوائية وغير المتوقعة فِي أحجام الطلبات التي تهدد التوفر وخصائص الأداء للنظام الأساسي Dataverse.
تحدّد Microsoft عدد الاتصالات المتزامنة لكل حساب مستخدم، وعدد طلبات API لكل اتصال، ومقدار وقت التشغيل الذي يمكن استخدامه لكل اتصال. يتم تقييم هذه القيود فِي نافذة انزلاقية مدتها خمس دقائق. عند تجاوز أحد هذه الحدود، يتم طرح استثناء من جانب النظام الأساسي.
هام
لا يمكن زيادة حدود حماية الخدمة.
ملاحظة
للحصول على مزيد من المعلومات، راجع حدود API.
إعادة محاولة النُهُج والأنماط
يجب أن يعالج المنطق المخصص الذي يستخدم واجهات API عمليات إعادة المحاولة. عند حدوث خطأ فِي حد واجهة API لحماية الخدمة، فإنه يوفر قيمة تشير إلى أنه يمكن معالجة المدة قبل أي طلبات جديدة من المستخدم.
ترجع واجهة Web API خطأ 429 إذا تم الوصول إلى الحد الأقصى. تتضمن الاستجابة Retry-After عدد الثواني. باستخدام خدمة المؤسسة، يتم إرجاع قيمة TimeSpan فِي مجموعة OrganizationServiceFault.ErrorDetails باستخدام المفتاح إعادة محاولة بعد.
ملاحظة
يجب توخي الحذر للتأكد من أنك لا تزيد الأمر سوءاً من خلال إعادة المحاولة.
لمزيد من المعلومات، راجع حدود حماية الخدمة.
الحد من استدعاءات API
يجب ألا يعتمد تصميم الحل على توفر سعة غير محدودة. بالنسبة للمستخدمين العاديين للتطبيقات التفاعلية، تم تعيين الحدود على مستوى عالٍ بما فيه الكفاية حتى لا يتأثر المستخدمون.
يجب أن تكون التطبيقات المصممة لتحميل البيانات فِي Dataverse أو إجراء تحديثات مجمعة قادرة أيضاً على إدارة أخطاء حد API لحماية الخدمة. تعطي هذه التطبيقات الأولوية للإنتاجية حتى يتمكن المستخدمون من إكمال عملهم فِي أقل وقت ممكن. يجب أن يكون لهذه التطبيقات إستراتيجية محددة لإعادة محاولة العمليات.
ترسل تطبيقات المدخل عادةً طلبات من مستخدمين مجهولين عبر حساب خدمة رئيسي. نظراً لأن حدود API لحماية الخدمة تستند إلى أساس كل مستخدم على حدة، يمكن لتطبيقات المدخل الوصول إلى حدود API لحماية الخدمة استناداً إلى مقدار حركة المرور التي يواجهها المدخل.
يجب تحسين عمليات التكامل لتقليل عدد استدعاءات API.
يجب على مهندس الحل أيضاً مراعاة التوافر العالي فِي تصميم الحل.