413 كيان الطلب كبير جدًا - OverBigBody

أنت الآن بصدد الاطّلاع على مستندات Apigee Edge.
انتقِل إلى مستندات Apigee X. info

المشكلة

يتلقّى تطبيق العميل رمز حالة HTTP 413 Request Entity Too Large مع رمز الخطأ protocol.http.TooBigBody كاستجابة لطلبات البيانات من واجهة برمجة التطبيقات.

رسالة الخطأ

يتلقّى تطبيق العميل رمز الاستجابة التالي: 

HTTP/1.1 413 Request Entity Too Large

بالإضافة إلى ذلك، قد تظهر لك رسالة الخطأ التالية: 

{
   "fault":{
      "faultstring":"Body buffer overflow",
      "detail":{
         "errorcode":"protocol.http.TooBigBody"
      }
   }
}

الأسباب المحتملة

يحدث هذا الخطأ إذا كان حجم الحمولة التي يرسلها تطبيق العميل إلى Apigee Edge كجزء من طلب HTTP أكبر من الحدّ المسموح به في Apigee Edge .

في ما يلي الأسباب المحتملة لهذا الخطأ :

السبب الوصف تعليمات تحديد المشاكل وحلّها التي تنطبق على
حجم حمولة الطلب أكبر من الحدّ المسموح به يتجاوز حجم الحمولة التي يرسلها تطبيق العميل كجزء من طلب HTTP إلى Apigee Edge الحدّ المسموح به في Apigee Edge. مستخدمو Edge Public Cloud وEdge Private Cloud
يتجاوز حجم حمولة الطلب الحدّ المسموح به بعد فك الضغط حجم الحمولة المُرسَلة بتنسيق مضغوط من خلال تطبيق العميل كجزء من طلب HTTP إلى Apigee Edge يتجاوز الحدّ المسموح به عند فك ضغطها بواسطة Apigee Edge. مستخدمو Edge Public Cloud وEdge Private Cloud

خطوات التشخيص الشائعة

استخدِم إحدى الأدوات أو التقنيات التالية لتشخيص هذا الخطأ:

API Monitoring

لتشخيص الخطأ باستخدام "مراقبة واجهة برمجة التطبيقات"، اتّبِع الخطوات التالية:

  1. سجِّل الدخول إلى واجهة مستخدم Apigee Edge بصفتك مستخدمًا لديه دور مناسب.

  2. الانتقال إلى المؤسسة التي تريد التحقيق في المشكلة فيها

  3. انتقِل إلى صفحة تحليل > مراقبة واجهة برمجة التطبيقات > التحقيق.
  4. اختَر الفترة الزمنية المحدّدة التي لاحظت فيها الأخطاء.
  5. يمكنك اختيار فلتر الخادم الوكيل لتضييق نطاق رمز الخطأ.
  6. رسم بياني لرمز الخطأ مقابل الوقت

  7. اختَر خلية تحتوي على رمز الخطأ protocol.http.TooBigBody ورمز الحالة 413 كما هو موضّح أدناه:

  8. تظهر المعلومات حول رمز الخطأ protocol.http.TooBigBody كما هو موضح أدناه:

  9. انقر على عرض السجلات ووسِّع صف الطلب الذي تعذّر تنفيذه. بعد ذلك، من نافذة السجلّات، سجِّل التفاصيل كما هو موضّح أدناه :

    غير مضغوط

    السيناريو 1: إرسال حمولة الطلب في شكل غير مضغوط

    من نافذة "السجلّات"، سجِّل التفاصيل التالية:

    • رمز الحالة: 413
    • مصدر الخطأ: proxy
    • رمز الخطأ: protocol.http.TooBigBody
    • طول الطلب(بالبايت): 15360440 (حوالي 15 ميغابايت)

    إذا كانت قيمة مصدر الخطأ هي proxy، وكانت قيمة رمز الخطأ هي protocol.http.TooBigBody، وكان طول الطلب أكبر من 10 ميغابايت، يشير ذلك إلى أنّ طلب HTTP من العميل يتضمّن حجم حمولة طلب أكبر من الحدّ المسموح به في Apigee.

    مضغوط

    السيناريو 2: إرسال حمولة الطلب في شكل مضغوط

    من نافذة السجلّات، دوِّن التفاصيل التالية:

    • رمز الحالة: 413
    • مصدر الخطأ: proxy
    • رمز الخطأ: protocol.http.TooBigBody
    • طول الطلب(بايت): 15264 (~15 كيلوبايت)

    إذا كانت قيمة مصدر الخطأ هي proxy، وكانت قيمة رمز الخطأ هي protocol.http.TooBigBody، وكان طول الطلب أقل من 10 ميغابايت، يشير ذلك إلى أنّ حجم حمولة طلب HTTP من العميل أقل من الحدّ المسموح به في تنسيقه المضغوط، ولكن حجم الحمولة أكبر من الحدّ المسموح به عند فك ضغطها بواسطة Apigee.

التتبّع

لتشخيص الخطأ باستخدام "أداة التتبُّع"، اتّبِع الخطوات التالية:

  1. فعِّل جلسة التتبُّع، ثم اتّبِع إحدى الخطوتَين التاليتَين:
    • انتظِر إلى أن يظهر الخطأ 413 Request Entity Too Large أو
    • إذا كان بإمكانك إعادة إظهار المشكلة، أجرِ طلب البيانات من واجهة برمجة التطبيقات وأعِد إظهار الخطأ 413 Request Entity Too Large.

  2. تأكَّد من تفعيل خيار عرض جميع معلومات التدفق.

  3. اختَر أحد الطلبات التي تعذّر تنفيذها وافحص التتبُّع.
  4. انتقِل إلى المرحلة تم استلام الطلب من العميل.

    غير مضغوط

    السيناريو 1: إرسال حمولة الطلب في شكل غير مضغوط

    يُرجى مراعاة المعلومات التالية:

    • لم يتم تضمين الحقل Content-Encoding:
    • Content-Length: 15360204

    مضغوط

    السيناريو 2: إرسال حمولة الطلب في شكل مضغوط

    يُرجى مراعاة المعلومات التالية:

    • Content-Encoding: gzip
    • Content-Length: 14969
    • Content-Type: application/x-gzip
  5. تنقَّل بين مراحل التتبُّع المختلفة وحدِّد مكان حدوث الخطأ.

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

  7. دوِّن قيمة الخطأ من التتبُّع. يعرض نموذج التتبُّع أعلاه ما يلي:
    • الخطأ: Body buffer overflow
    • error.class: com.apigee.errors.http.user.RequestTooLarge

  8. انتقِل إلى الردّ المُرسَل إلى العميل ودوِّن قيم الخطأ من التتبُّع. يعرض نموذج التتبُّع أدناه ما يلي:

    • الخطأ: 413 Request Entity Too Large
    • محتوى الخطأ: {"fault":{"faultstring":"Body buffer overflow","detail":{"errorcode":"protocol.http.TooBigBody"}}}
  9. انتقِل إلى مرحلة AX (تسجيل بيانات الإحصاءات) في التتبُّع وانقر عليها.

  10. في قسم تفاصيل المرحلة، انتقِل للأسفل إلى المتغيّرات التي تمّت قراءتها.

  11. حدِّد قيمة المتغيّر client.received.content.length، الذي يشير إلى:
    • الحجم الفعلي لحزمة بيانات الطلب عند إرسالها بتنسيق غير مضغوط
    • حجم حمولة الطلب بعد أن يزيل Apigee ضغطها، وذلك عندما يتم إرسال الحمولة بتنسيق مضغوط. ستكون القيمة دائمًا مماثلة لقيمة الحدّ المسموح به (10 ميغابايت) في هذا السيناريو.

    غير مضغوط

    السيناريو 1: حمولة الطلب في شكل غير مضغوط

    المتغيّر client.received.content.length: 15360204

    مضغوط

    السيناريو 2: حمولة الطلب بتنسيق مضغوط

    المتغيّر client.received.content.length: 10489856

  12. يوضّح الجدول التالي سبب عرض الخطأ 413 من خلال Apigee في الحالتَين التاليتَين استنادًا إلى قيمة المتغيّر client.received.content.length:
    السيناريو قيمة client.received.content.length سبب التعذُّر
    حمولة الطلب بتنسيق غير مضغوط ‫15 ميغابايت تقريبًا الحجم > الحدّ الأقصى المسموح به وهو 10 ميغابايت
    حمولة الطلب بالتنسيق المضغوط ‫10 ميغابايت تقريبًا

    تم تجاوز الحدّ الأقصى للحجم عند فك الضغط

NGINX

لتشخيص الخطأ باستخدام سجلّات الوصول إلى NGINX، اتّبِع الخطوات التالية:

  1. إذا كنت مستخدمًا في Private Cloud، يمكنك استخدام سجلّات الوصول إلى NGINX لتحديد المعلومات الأساسية حول أخطاء HTTP 413.

  2. تحقَّق من سجلّات الوصول إلى NGINX:

    /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

  3. ابحث لمعرفة ما إذا كانت هناك أي أخطاء 413 خلال مدة زمنية معيّنة (إذا حدثت المشكلة في الماضي) أو إذا كانت هناك أي طلبات لا تزال غير ناجحة مع ظهور 413.
  4. إذا عثرت على أي أخطاء 413 تتطابق مع X-Apigee-fault-code مع قيمة protocol.http.TooBigBody، حدِّد قيمة X-Apigee-fault-source.

    غير مضغوط

    السيناريو 1 : حجم حمولة الطلب بالتنسيق غير المضغوط

    يحتوي نموذج الإدخال أعلاه من سجلّ الوصول إلى NGINX على القيم التالية لـ X-Apigee-fault-code وX-Apigee-fault-source:

    عناوين الاستجابة القيمة
    X-Apigee-fault-code protocol.http.TooBigBody
    X-Apigee-fault-sourc policy

    لاحظ طول الطلب: 15360440 (14.6 ميغابايت > الحدّ المسموح به)

    مضغوط

    السيناريو 2 : حجم حمولة الطلب بالتنسيق المضغوط

    يحتوي نموذج الإدخال أعلاه من سجلّ الوصول إلى NGINX على القيم التالية لكل من X-Apigee-fault-code وX-Apigee-fault-source:

    عناوين الاستجابة القيمة
    X-Apigee-fault-code protocol.http.TooBigBody
    X-Apigee-fault-source policy

    لاحظ طول الطلب: 15264 (14.9 ألف < الحدّ المسموح به)

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

السبب: حجم حمولة الطلب أكبر من الحدّ المسموح به

التشخيص

  1. حدِّد رمز الخطأ ومصدر الخطأ وحجم حمولة الطلب للخطأ الذي تم رصده باستخدام "مراقبة واجهة برمجة التطبيقات" أو "أداة التتبُّع" أو سجلّات الوصول إلى NGINX كما هو موضّح في خطوات التشخيص الشائعة مع السيناريو رقم 1 (غير مضغوط).
  2. إذا كانت قيمة مصدر الخطأ هي policy أو proxy، يشير ذلك إلى أنّ حجم حمولة الطلب التي أرسلها تطبيق العميل إلى Apigee أكبر من الحدّ المسموح به في Apigee Edge.
  3. تأكَّد من حجم حمولة الطلب كما تم تحديده في الخطوة رقم 1.
  4. يمكنك أيضًا التأكّد مما إذا كان حجم حمولة الطلب أكبر من الحد المسموح به وهو 10 ميغابايت من خلال التحقّق من الطلب الفعلي باتّباع الخطوات التالية:
    1. إذا لم يكن لديك إذن الوصول إلى الطلب الفعلي الذي أرسله تطبيق العميل، انتقِل إلى الحل.
    2. إذا كان بإمكانك الوصول إلى الطلب الفعلي الذي أرسله تطبيق العميل، اتّبِع الخطوات التالية:
      1. تحقَّق من حجم الحمولة التي تم تمريرها في الطلب.
      2. إذا تبيّن لك أنّ حجم الحمولة يتجاوز الحدّ المسموح به في Apigee Edge، يكون ذلك هو سبب المشكلة.

        3. نموذج طلب:

        curl http://<hostalias>/testtoobigbody -k -X POST -F file=@test15mbfile -v

        في الحالة أعلاه، يبلغ حجم الملف test15mbfile حوالي 15 ميغابايت. إذا كنت تستخدم برنامجًا آخر، احصل على سجلّات البرنامج لمعرفة حجم الحمولة التي يتم إرسالها.

الدقة

انتقِل إلى درجة الدقة.

السبب: يتجاوز حجم حمولة الطلب الحدّ المسموح به بعد فك الضغط

إذا تم إرسال حمولة الطلب بتنسيق مضغوط وتم ضبط عنوان الطلب Content-Encoding على gzip, ، ستزيل Apigee ضغط حمولة الطلب. أثناء عملية فك الضغط، إذا تبيّن لخدمة Apigee أنّ حجم الحمولة أكبر من 10 ميغابايت، أي الحدّ المسموح به، تتوقف عملية فك الضغط، ويتم الردّ على الفور بالرمز 413 Request Entity Too Large مع رمز الخطأ protocol.http.TooBigBody.

التشخيص

  1. حدِّد رمز الخطأ ومصدر الخطأ وحجم حمولة الطلب للخطأ الذي تم رصده باستخدام &quot;مراقبة واجهة برمجة التطبيقات&quot; أو &quot;أداة التتبُّع&quot; أو سجلات الوصول إلى NGINX كما هو موضّح في خطوات التشخيص الشائعة مع السيناريو رقم 2 (مضغوط).
  2. إذا كان مصدر الخطأ يتضمّن القيمة policy أو proxy، يشير ذلك إلى أنّ حجم حمولة الطلب التي أرسلها تطبيق العميل إلى Apigee أكبر من الحدّ المسموح به في Apigee Edge.
  3. تأكَّد من حجم حمولة الطلب كما هو محدّد في الخطوة 1.
    • إذا كان حجم الحمولة أكبر من الحدّ المسموح به وهو 10 ميغابايت، سيكون هذا هو سبب الخطأ.
    • إذا كان حجم الحمولة أقل من الحدّ المسموح به وهو 10 ميغابايت، من المحتمل أن يتم تمرير حمولة الطلب بتنسيق مضغوط. في هذه الحالة، تحقَّق من حجم حمولة الطلب المضغوطة غير المضغوطة.
  4. يمكنك التأكّد مما إذا تم إرسال الطلب من العميل بتنسيق مضغوط وكان الحجم غير المضغوط أكبر من الحد المسموح به باستخدام إحدى الطريقتَين التاليتَين:

    التتبّع

    لإثبات صحة البيانات باستخدام أداة "التتبُّع"، اتّبِع الخطوات التالية:

    1. إذا كنت قد سجّلت عملية تتبُّع للطلب الذي تعذّر تنفيذه، يُرجى الرجوع إلى الخطوات المفصّلة في عملية التتبُّع و
      1. تحديد قيمة المتغيّر client.received.content.length
      2. تأكَّد مما إذا كان الطلب الوارد من العميل يتضمّن العنوان Content-Encoding: gzip
    2. إذا كانت قيمة المتغيّر client.received.content.length أكبر من 10 ميغابايت، الحدّ المسموح به، وكان عنوان الطلب Content-Encoding: gzip، يكون هذا هو سبب حدوث الخطأ.

    الطلب الفعلي

    لإثبات صحة الرمز باستخدام الطلب الفعلي، اتّبِع الخطوات التالية:

    1. إذا لم يكن لديك إذن الوصول إلى الطلب الفعلي الذي أرسله تطبيق العميل، انتقِل إلى الحل.
    2. إذا كان بإمكانك الوصول إلى الطلب الفعلي الذي أرسله تطبيق العميل، اتّبِع الخطوات التالية:
      1. تحقَّق من حجم الحمولة التي تم تمريرها في الطلب مع العنوان Content-Encoding الذي تم إرساله في الطلب.

      2. تحقَّق مما إذا كان حجم الحمولة غير المضغوط أكبر من الحدّ المسموح به في Apigee Edge

        نموذج طلب:

        curl https://<hostalias>/testtoobigbody -k -X POST -F file=@test15mbfile.gz -H "Content-Encoding: gzip" -v

        في الحالة أعلاه، حجم الملف test15mbfile.gz أقل من الحدّ الأقصى المسموح به، إلا أنّ حجم الملف غير المضغوط test15mbfile يبلغ 15 ميغابايت تقريبًا، ويبلغ حجم العنوان Content-Encoding ‏gzip.

        إذا كنت تستخدم برنامجًا آخر، احصل على سجلّات البرنامج لمعرفة حجم الحمولة التي يتم إرسالها وما إذا كان عنوان Content-Encoding مضبوطًا على gzip.

    سجلّات "معالج الرسائل"

    لإثبات صحة البيانات باستخدام سجلّات "معالج الرسائل"، اتّبِع الخطوات التالية:

    1. إذا كنت مستخدمًا في Private Cloud، يمكنك استخدام سجلّات &quot;معالج الرسائل&quot; لتحديد المعلومات الأساسية حول أخطاء HTTP 413.

    2. تحقَّق من سجلّات "معالج الرسائل":

      /opt/apigee/var/log/edge-message-processor/logs/system.log

    3. ابحث لمعرفة ما إذا كانت هناك أي أخطاء 413 خلال مدة زمنية محددة (إذا حدثت المشكلة في الماضي) أو إذا كانت هناك أي طلبات لا تزال غير ناجحة مع 413.

      يمكنك استخدام سلاسل البحث التالية:

      grep -ri "chunkCount"

      grep -ri "RequestTooLarge"
    4. ستجد أسطرًا من system.log مشابهة لما يلي (قد يختلف TotalRead وchunkCount في حالتك): 
      2021-07-06 13:29:57,544  NIOThread@1 ERROR HTTP.SERVICE -
  TrackingInputChannel.checkMessageBodyTooLarge()
  : Message is too large.  TotalRead 10489856 chunkCount 2570

2021-07-06 13:29:57,545  NIOThread@1 INFO  HTTP.SERVICE -
  ExceptionHandler.handleException()
  : Exception trace: com.apigee.errors.http.user.RequestTooLarge
  : Body buffer overflow
    5. أثناء عملية فك الضغط، بمجرد أن يحدّد &quot;معالج الرسائل&quot; أنّ إجمالي عدد وحدات البايت التي تمت قراءتها أكبر من 10 ميغابايت، يتوقف عن العمل ويعرض السطر التالي: 
      Message is too large.  TotalRead 10489856 chunkCount 2570

      يشير ذلك إلى أنّ حجم حمولة الطلب أكبر من 10 ميغابايت، وأنّ Apigee يعرض الخطأ RequestTooLarge عندما يبدأ الحجم في تجاوز الحدّ الأقصى البالغ 10 ميغابايت، مع رمز الخطأ protocol.http.TooBigBody.

الدقة

تحديد الحجم

الخيار 1 [إجراء يُنصح به]: إصلاح تطبيق العميل لكي لا يرسل حجم حمولة أكبر من الحد المسموح به

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

  2. إذا لم يكن ذلك مرغوبًا فيه، عدِّل تطبيق العميل بحيث يرسل حجم الطلب / الحِمل أقل من الحد المسموح به.

    في المثال المذكور أعلاه، يمكنك حلّ المشكلة من خلال تمرير ملف أصغر حجمًا، لنفترض أنّه حمولة test5mbfile (بحجم 5 ميغابايت) كما هو موضّح أدناه: 

    curl https://<host>/testtoobigbody -k -X POST -F file=@test5mbfile -v
  3. إذا كان ذلك مرغوبًا وأردت إرسال طلب/حمولة أكبر من الحد المسموح به، انتقِل إلى الخيارات التالية.

نمط عنوان URL الموقَّع

الخيار 2 [يُنصح به]: استخدام نمط عناوين URL الموقّعة ضمن Apigee JavaCallout

بالنسبة إلى حمولات أكبر من 10 ميغابايت، تنصح Apigee باستخدام نمط عناوين URL الموقّعة ضمن Apigee JavaCallout، كما هو موضّح في مثال Edge Callout: Signed URL Generator على GitHub.

البث

الخيار 3 : استخدام البث

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

CwC

الخيار 4 : استخدام السمة CwC لزيادة الحد الأقصى للمخزن المؤقت

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

توفّر Apigee السمة CwC التي تتيح لها زيادة الحدّ الأقصى لحجم حمولة الطلب والاستجابة. للحصول على التفاصيل، يُرجى الرجوع إلى ضبط الحد الأقصى لحجم الرسالة على جهاز التوجيه أو معالج الرسائل

الحدود

تتوقّع Apigee ألا يرسل تطبيق العميل وخادم الخلفية أحجام حمولات أكبر من الحدّ المسموح به كما هو موضّح في Request/response size ضمن حدود Apigee Edge.

  1. إذا كنت مستخدمًا في السحابة الإلكترونية العامة، يكون الحدّ الأقصى لحجم حمولة الطلب والاستجابة هو ما هو موثّق في Request/response size ضمن حدود Apigee Edge.
  2. إذا كنت مستخدمًا في Private Cloud، فمن المحتمل أنّك عدّلت الحدّ التلقائي لحجم حمولة الطلب والاستجابة (على الرغم من أنّ هذه الممارسة غير موصى بها). يمكنك تحديد الحد الأقصى لحجم حمولة الطلب باتّباع التعليمات الواردة في مقالة كيفية التحقّق من الحدّ الحالي.

كيف يمكن التحقّق من الحدّ الحالي؟

يوضّح هذا القسم كيفية التأكّد من تعديل الموقع HTTPRequest.body.buffer.limit بقيمة جديدة في "معالجات الرسائل".

  1. على جهاز &quot;معالج الرسائل&quot;، ابحث عن السمة HTTPRequest.body.buffer.limit في الدليل /opt/apigee/edge-message- processor/conf وتحقّق من القيمة التي تم ضبطها باستخدام الأمر التالي: 
    grep -ri "HTTPRequest.body.buffer.limit" /opt/apigee/edge-message-processor/conf
  2. في ما يلي نموذج للنتيجة من الأمر أعلاه: 
    /opt/apigee/edge-message-processor/conf/http.properties:HTTPRequest.body.buffer.limit=10m

  3. في مثال الناتج أعلاه، لاحظ أنّه تم ضبط السمة HTTPRequest.body.buffer.limit بالقيمة 10m في http.properties.

    يشير ذلك إلى أنّ الحدّ الأقصى لحجم حمولة الطلب الذي تم ضبطه في Apigee for Private Cloud هو 10 ميغابايت.

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

يجب جمع معلومات التشخيص

اجمع معلومات التشخيص التالية، ثم تواصَل مع فريق دعم Apigee Edge:

إذا كنت مستخدمًا لخدمة السحابة الإلكترونية العامة، يُرجى تقديم المعلومات التالية:

  • اسم المؤسسة
  • اسم البيئة
  • اسم خادم وكيل لواجهة برمجة التطبيقات
  • أمر curl الكامل المُستخدَم لإعادة إنتاج الخطأ 413
  • ملف التتبُّع لطلبات البيانات من واجهة برمجة التطبيقات

إذا كنت مستخدمًا في Private Cloud، يُرجى تقديم المعلومات التالية:

  • رسالة الخطأ الكاملة التي تم رصدها للطلبات التي تعذّر تنفيذها
  • اسم المؤسسة
  • اسم البيئة
  • حزمة خادم وكيل لواجهة برمجة التطبيقات
  • ملف التتبُّع لطلبات البيانات من واجهة برمجة التطبيقات التي تعذّر تنفيذها
  • أمر curl الكامل المُستخدَم لإعادة إنتاج الخطأ 413

  • سجلّات الوصول إلى NGINX /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

    حيث: يتم استبدال ORG وENV وPORT# بالقيم الفعلية.

  • سجلّات نظام "معالج الرسائل" /opt/apigee/var/log/edge-message-processor/logs/system.log