حدود المعدل (Rate Limits) في API

عند بناء تكامل مع منصة فاتورة لإصدار الفواتير الإلكترونية ومقاصتها، تعمل البنية بسلاسة ما دام حجم الطلبات منخفضاً. لكن السلوك يتغير حين ترتفع الأحمال: دفعة فواتير عند إغلاق اليوم، أو موسم ذروة، أو إعادة معالجة طابور متراكم. هنا تظهر حدود المعدل (Rate Limits). هذا الدليل يشرح ما حدود المعدل، وكيف تتعرف على استجابة 429 Too Many Requests، وكيف تقرأ ترويسة Retry-After، وكيف تصمم استراتيجيات التهدئة (throttling) والطوابير (queueing) والإرسال على دفعات (batching) لإصدار عالي الحجم يبقى داخل الحدود دون أن يخسر فاتورة واحدة.

هذا المقال جزء من مركز المطوّرين ضمن الفاتورة الإلكترونية من قيود. ويفترض أنك قرأت مدخل واجهة API للفوترة الإلكترونية ونقاط نهاية API لمنصة فاتورة، وتعرف الفرق بين واجهة المقاصة وواجهة الإبلاغ، إضافة إلى معالجة الأخطاء في API التي تشرح كيف تصنّف الاستجابات القادمة من المنصة.

ما المقصود بحدود المعدل في واجهة API

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

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

المهم أن تفهم أن حد المعدل لا يعني أن فاتورتك خاطئة. الفاتورة قد تكون صحيحة تماماً ومتوافقة مع كل قواعد التحقق، لكنها وصلت في توقيت تجاوزت فيه الوتيرة المسموحة. لذلك يختلف التعامل مع هذا الرفض جذرياً عن التعامل مع رفض بسبب بيانات غير صالحة. الأول يُحلّ بإعادة الإرسال بعد فترة، والثاني يحتاج تصحيح البيانات أولاً.

تتفاوت آليات حساب الحد بين الأنظمة. بعضها يعتمد نافذة ثابتة (fixed window) تعدّ الطلبات في كل دقيقة مثلاً ثم تصفّر العدّاد. بعضها يعتمد نافذة منزلقة (sliding window) أكثر سلاسة. وبعضها يطبّق خوارزمية «الدلو المثقوب» (token bucket) التي تمنحك رصيداً يتجدد بمعدل ثابت ويسمح بدفعات قصيرة فوق المتوسط. لا تبنِ منطقك على افتراض آلية بعينها، بل اقرأ سلوك المنصة الفعلي من استجاباتها وتعامل معه كما هو.

استجابة 429 Too Many Requests

حين تتجاوز حد المعدل، تردّ منصة فاتورة برمز حالة HTTP يساوي 429 ومعناه «طلبات كثيرة جداً». هذا الرمز هو الإشارة المعيارية في عالم الويب لتجاوز السقف، وهو مختلف تماماً عن رموز أخطاء البيانات (من فئة 400) ورموز أخطاء الخادم (من فئة 500).

التمييز بين هذه الفئات الثلاث أساس بناء استجابة صحيحة:

• رمز 429. تجاوزت حد المعدل. الطلب صحيح لكن وتيرتك مرتفعة. الحل: انتظر ثم أعد الإرسال نفسه دون تعديل.
• فئة 400 (مثل 400 و422). خطأ في بيانات الفاتورة أو بنية الطلب. إعادة الإرسال دون تصحيح ستفشل دائماً. الحل: صحّح البيانات أولاً.
• فئة 500 (مثل 500 و503). خطأ مؤقت في الخادم. الطلب قد يكون صحيحاً والخدمة متعثرة لحظياً. الحل: أعد المحاولة مع تباعد زمني.

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

فيما يلي مثال مبسّط لاستجابة تجاوز الحد كما قد تصلك:

HTTP/1.1 429 Too Many Requests
Retry-After: 30
Content-Type: application/json

{
  "status": "RATE_LIMITED",
  "message": "Request rate exceeded. Retry after the specified interval.",
  "retryAfterSeconds": 30
}

لاحظ عنصرين: رمز الحالة 429 في السطر الأول، وترويسة Retry-After التي تخبرك بالضبط متى يمكنك المحاولة من جديد. هذان العنصران هما ما يبني عليه نظامك قراره.

ترويسة Retry-After: متى تعيد المحاولة

ترويسة Retry-After (إعادة المحاولة بعد) هي الآلية المعيارية التي يخبرك بها الخادم كم تنتظر قبل الإرسال التالي. احترام هذه الترويسة هو الفرق بين عميل متعاون يستعيد قدرته على الإرسال بسرعة، وعميل عنيد يطيل فترة حظره على نفسه.

تأتي القيمة بأحد شكلين. الأول عدد ثوانٍ، مثل Retry-After: 30، ومعناه «انتظر ثلاثين ثانية». الثاني تاريخ ووقت بصيغة HTTP، ومعناه «لا ترسل قبل هذه اللحظة». نظامك يجب أن يتعامل مع الشكلين. إذا كانت القيمة رقماً، فهي ثوانٍ نسبية. إذا كانت نصاً يشبه التاريخ، فاحسب الفرق بينه وبين الوقت الحالي.

القاعدة الذهبية: عندما يرسل الخادم Retry-After، استخدم قيمتها كما هي ولا تخمّن وقتاً أقصر من عندك. الخادم يعرف متى تتجدد النافذة لديك، وأنت لا تعرف. تجاهل القيمة وإعادة المحاولة مبكراً يضمن لك رمز 429 جديداً ويستهلك رصيدك على طلبات محكوم عليها بالرفض.

إليك نموذجاً منطقياً لمعالجة الاستجابة 429 واحترام الترويسة:

function handleResponse(response) {
  if (response.statusCode === 429) {
    let waitSeconds = parseRetryAfter(response.headers["retry-after"]);
    if (waitSeconds == null) {
      waitSeconds = 30; // قيمة احتياطية إذا غابت الترويسة
    }
    scheduleRetry(response.request, waitSeconds);
    return;
  }
  // عالج بقية الفئات: 2xx نجاح، 4xx بيانات، 5xx خادم
}

function parseRetryAfter(value) {
  if (!value) return null;
  if (/^\d+$/.test(value)) return parseInt(value, 10);
  const date = new Date(value);
  if (isNaN(date)) return null;
  return Math.max(0, Math.ceil((date - Date.now()) / 1000));
}

هذا النموذج يفصل قرار الانتظار عن بقية منطق المعالجة. عند رمز 429 لا يصحّح بيانات ولا يسجّل خطأ تحقق، بل يحسب فترة الانتظار ويعيد جدولة الطلب نفسه. أما حين تغيب الترويسة لأي سبب، فيلجأ إلى قيمة احتياطية معقولة بدل أن يعيد المحاولة فوراً.

استراتيجية التهدئة (Throttling) من جانب العميل

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

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

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

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

الطوابير (Queueing) لإدارة الإرسال

التهدئة وحدها لا تكفي حين يصل حجم العمل ذروته. تحتاج إلى مكان تحتفظ فيه بالفواتير التي تنتظر دورها في الإرسال. هذا المكان هو الطابور (Queue). الطابور يفصل بين لحظة إنشاء الفاتورة في نظامك ولحظة إرسالها الفعلي إلى منصة فاتورة.

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

الطابور أيضاً يحل مشكلة 429 بأناقة. حين يرد الخادم بتجاوز الحد، لا تفقد الفاتورة، بل تعيدها إلى الطابور مع تأخير زمني يساوي قيمة Retry-After. المُرسِل سيلتقطها مجدداً بعد انقضاء المهلة. هذا يجعل التعامل مع الحد جزءاً طبيعياً من دورة الطابور، لا حالة طوارئ.

عند تصميم الطابور، انتبه إلى الترتيب. الفوترة الإلكترونية تربط كل فاتورة بتجزئة (hash) الفاتورة السابقة لضمان سلامة التسلسل. لذلك إذا كانت فواتيرك تخص جهازاً واحداً يجب إرسالها بالترتيب الصحيح، فلا تستخدم مُرسِلات متوازية تكسر التسلسل. اجعل الإرسال تسلسلياً ضمن السلسلة الواحدة، وراجع واجهة المقاصة Clearance API لفهم متى تكون المقاصة فورية وكيف تؤثر على ترتيب الإرسال.

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

الإرسال على دفعات (Batching) بحكمة

قد تدعم بعض الواجهات إرسال عدة فواتير في طلب واحد. هذا يقلل عدد الطلبات، وبالتالي يخفّف الضغط على حد المعدل. لكن الإرسال على دفعات سلاح ذو حدّين، فاستخدامه دون فهم قد يعقّد معالجة الأخطاء بدل أن يبسّطها.

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

القاعدة العملية: لا تفترض أن نجاح الطلب يعني نجاح كل فاتورة فيه. اقرأ مصفوفة النتائج داخل جسم الاستجابة، وطابق كل نتيجة بمعرّف فاتورتها، وعالج المرفوضة منها بالمسار الصحيح. تجاهل هذه الخطوة يعني أن فواتير مرفوضة قد تمر كأنها نجحت، فتُكتشف المشكلة متأخراً.

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

تصميم إصدار عالي الحجم داخل الحدود

حين تجتمع العناصر السابقة، تحصل على معمارية قادرة على إصدار عالي الحجم دون كسر الحدود. الفكرة أن تبني خط إنتاج متعدد الطبقات، كل طبقة مسؤولة عن جزء، فلا تتكدس المسؤوليات في موضع واحد.

الطبقة الأولى توليد الفواتير من نظامك بأي وتيرة، ووضعها في الطابور بحالة «بانتظار الإرسال». الطبقة الثانية مُرسِل مهدّأ يسحب من الطابور بمعدل آمن تحت الحد، ويحترم ترتيب التسلسل حين يلزم. الطبقة الثالثة معالج للاستجابات يصنّف كل نتيجة: نجاح يُغلق الفاتورة، أو 429 يعيدها للطابور بتأخير Retry-After، أو خطأ بيانات يحوّلها لمسار التصحيح، أو خطأ خادم يعيد المحاولة متدرجاً.

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

في أوقات الذروة، مثل نهاية الشهر أو موسم محدد، قد يتضخّم الطابور. هنا تأتي قيمة الفصل بين الإنتاج والإرسال. الطابور يمتصّ القمة، والمُرسِل يصرّفها بثبات تحت الحد. النتيجة أن كل الفواتير تصل، وإن استغرق ذلك وقتاً أطول قليلاً، دون أن تخسر فاتورة أو تكسر تسلسلاً.

لاختبار هذا التصميم قبل الإنتاج، استعمل بيئة المحاكاة. ابنِ سيناريو ذروة يحاكي دفعة كبيرة، وراقب كيف يتصرف نظامك أمام استجابات 429 المتعمَّدة. راجع مدخل واجهة API للفوترة الإلكترونية لمعرفة كيف تبدأ التكامل من الأساس، ثم تدرّج نحو اختبارات الحمل قبل التشغيل الفعلي.

أخطاء شائعة في التعامل مع حدود المعدل

هناك أنماط متكررة تكسر التكاملات عند مواجهة الحد. معرفتها مسبقاً توفّر عليك دروساً مكلفة في الإنتاج.

إعادة المحاولة الفورية بعد 429. أكثر الأخطاء شيوعاً. حين يصدّ الخادم الطلب، يعيد بعض المطوّرين الإرسال فوراً وبوتيرة أعلى ظناً أنها مشكلة عابرة. النتيجة عكسية: ضغط أكبر وفترة حظر أطول. احترم Retry-After دائماً.

تجاهل ترويسة Retry-After. بعض الأنظمة تستخدم تأخيراً ثابتاً من عندها وتتجاهل ما يرسله الخادم. هذا قد يكون أقصر من اللازم فيكرر الرفض، أو أطول من اللازم فيبطّئ العمل بلا داعٍ. القيمة القادمة من الخادم أدقّ.

إرسال متوازٍ يكسر التسلسل. لتسريع الإرسال يلجأ البعض إلى مُرسِلات متوازية كثيرة. هذا يرفع الضغط على الحد، والأخطر أنه قد يكسر ترتيب تسلسل التجزئة فتُرفض السلسلة. حافظ على الإرسال التسلسلي ضمن السلسلة الواحدة.

فقدان الفواتير عند الرفض. نظام بلا طابور يفقد الفاتورة حين يردّ الخادم بـ 429، أو يتركها معلّقة دون إعادة إرسال. الطابور المستمر يضمن أن كل فاتورة مرفوضة بسبب الحد تعود لدورها لاحقاً.

الخلط بين الرفض بسبب الحد والرفض بسبب البيانات. معاملة 429 كأنها خطأ بيانات يدفعك لتصحيح فاتورة سليمة بلا داعٍ. ومعاملة خطأ بيانات كأنه 429 يدخلك في إعادة محاولة لا تنتهي لفاتورة لن تُقبل أبداً. ميّز بين الفئتين من رمز الحالة أولاً.

التباعد الأسي والعشوائية (Backoff and Jitter)

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

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

انتبه إلى الفرق المهم: التباعد الأسي للأخطاء العابرة من فئة الخادم، أما الرمز 429 فله قاعدته الخاصة. عند 429 احترم قيمة Retry-After القادمة من الخادم أولاً، ولا تستبدلها بحسابك الأسي. اجعل التباعد الأسي مسارك الاحتياطي حين لا توجد ترويسة صريحة، أو حين يكون الخطأ من فئة الخادم لا من فئة الحد.

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

مراقبة المعدل في الإنتاج

لا تكتمل استراتيجية المعدل دون طبقة مراقبة تخبرك بسلوك نظامك الفعلي. القياس يحوّل ضبط المعدل من رقم ثابت تخمّنه مرة إلى تكيّف حي مع الواقع. ثلاثة مؤشرات تستحق المتابعة المستمرة.

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

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

طول الطابور وزمن الانتظار فيه. طابور يتضخم باستمرار دون أن يفرغ مؤشر على أن معدل الإنتاج يفوق معدل الإرسال الآمن لفترة طويلة. هذا طبيعي في ذروة قصيرة، لكن إن استمر فأنت بحاجة إما لرفع المعدل الآمن إن سمحت المنصة، أو لإعادة توزيع العمل على نوافذ أهدأ.

اربط هذه المؤشرات بتنبيهات. تنبيه حين تتجاوز نسبة 429 عتبة معينة، وتنبيه حين يتجاوز طول الطابور حداً يهدد التأخر عن مواعيد الإبلاغ. المراقبة دون تنبيه سجلّ يُقرأ بعد فوات الأوان، أما التنبيه فيمنحك فرصة التدخل قبل أن يتحول الضغط إلى فواتير متأخرة.

ما يتولّاه قيود نيابة عنك

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

يدير قيود شهادة CSID والتوقيع الرقمي والمقاصة والإبلاغ مع منصة فاتورة تلقائياً. حين ترتفع أحجام إصدارك، تتكفّل المنصة بتنظيم تدفّق الطلبات نحو منصة فاتورة بما يحافظ على التوافق ويتجنب الاصطدام بالحدود، دون أن تتدخل أنت في تفاصيل المعدل أو التأخير أو إعادة الجدولة.

هذا الفصل يعني أن فريقك يركّز على منطق العمل: إنشاء الفواتير الصحيحة وإدارة العملاء والتقارير، بينما يتكفّل قيود بالطبقة التقنية للتكامل. أما إن كنت تبني تكاملك المباشر الخاص لأسباب تخصّك، فما ورد في هذا الدليل هو خريطتك لتصميم إصدار عالي الحجم يصمد في الإنتاج.

الخطوات التالية في مركز المطوّرين

حدود المعدل حلقة في سلسلة بناء تكامل متين. بعد أن فهمت كيف تبقى تحت السقف، تبقى موضوعات مكمّلة تجعل تكاملك جاهزاً للإنتاج.

ابدأ بـمعالجة الأخطاء في API لفهم كيف تصنّف كل استجابة قادمة من المنصة وتبني خريطة إصلاح لكل رمز. ثم راجع إرسال الفاتورة عبر API لتتقن دورة الإرسال الكاملة من بناء الطلب إلى قراءة النتيجة. واطّلع على واجهة المقاصة Clearance API وواجهة الإبلاغ Reporting API لتفهم الفرق بين المسارين وأثره على ترتيب الإرسال وحجمه.

وحين تنتقل إلى التشغيل الفعلي، تأكد من أن طبقة المصادقة لديك تجدّد رموزها قبل انتهائها حتى لا تتعطل سلسلة الإرسال. راجع المصادقة في واجهة الفوترة لمعرفة كيف تبني هذه الطبقة بثبات.

خلاصة عملية

حدود المعدل ليست عائقاً بل قاعدة لعب واضحة. الرمز 429 يطلب منك التهدئة، وترويسة Retry-After تخبرك متى تعود، والطابور يضمن ألا تفقد فاتورة، والتهدئة الاستباقية تجنّبك الاصطدام أصلاً، والإرسال على دفعات يخفّف الضغط حين يُقرأ بنتائجه الفردية. اجمع هذه العناصر في معمارية من طبقات تفصل الإنتاج عن الإرسال عن معالجة الاستجابة، وستصدر بحجم عالٍ دون أن تخسر فاتورة أو تكسر تسلسلاً. وإن أردت تجاوز هذا البناء كلياً، فإصدارك عبر قيود ينقل هذه الطبقة التقنية إلى المنصة ويترك لك منطق عملك.