المشاكل المعروفة في Apigee

عند استخدام متغيّر تدفق cachehit بعد سياسة LookupCache، بسبب طريقة إرسال نقاط تصحيح الأخطاء للسلوك غير المتزامن، تعبئ LookupPolicy عنصر DebugInfo قبل تنفيذ دالة الاستدعاء، ما يؤدي إلى حدوث خطأ.

الحلّ: كرِّر العملية (إجراء مكالمة ثانية) مرة أخرى بعد المكالمة الأولى مباشرةً.

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

الحلّ: استخدِم سياسة KeyValueMapOperations للتنقّل في إصدارات ذاكرة التخزين المؤقت وتجاوز الحاجة إلى إلغاء صلاحية ذاكرة التخزين المؤقت.

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

الحلّ البديل: تجنَّب عمليات نشر واجهة برمجة التطبيقات الوكيلة أو SharedFlow المتزامنة.

• تتوافق Apigee Edge مع مواصفات OpenAPI 3.0 عند إنشاء المواصفات باستخدام محرِّر المواصفات و نشر واجهات برمجة التطبيقات باستخدام SmartDocs على البوابة، على الرغم من أنّ مجموعة فرعية من الميزات غير متاحة بعد.

  على سبيل المثال، الميزات التالية من مواصفات OpenAPI 3.0 غير متاحة بعد:

  • allOf خصائص لدمج المخططات وتوسيع نطاقها
  • المراجع البعيدة

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

  ملاحظة: بما أنّ محرِّر المواصفات أقل تقييدًا من SmartDocs عند عرض مستندات مرجعية لواجهة برمجة التطبيقات، قد تلاحظ نتائج مختلفة بين الأداتَين.

• عند استخدام ميزة "تجربة واجهة برمجة التطبيقات هذه" في البوابة، يتم ضبط رأس Accept على application/json بغض النظر عن القيمة التي تم ضبطها لـ consumes في مواصفات OpenAPI.
• ‎138438484: لا تتوفّر إمكانية استخدام خوادم متعددة.

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

• سيتم دمج ميزة البحث في البوابة المدمجة في إصدار مستقبلي.

عند استخدام سياسة SetOauthV2Info، إذا تعذّر تحليل AccessToken إلى متغيّر أو كان فارغًا، تؤدي السياسة إلى حدوث خطأ في قاعدة البيانات:

{
              "fault": {
                "faultstring": "Error while accessing datastore;Please retry later",
                "detail": {
                  "errorcode": "datastore.ErrorWhileAccessingDataStore"
                }
              }
            }
            

يختلف هذا السلوك عن الإصدارات السابقة من Apigee، حيث كان هذا السيناريو يؤدي إلى حدوث خطأ "invalid_access_token":

{
              "fault": {
                "faultstring": "Invalid Access Token",
                "detail": {
                  "errorcode": "keymanagement.service.invalid_access_token"
                }
              }
            }
            

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

<!-- Sample Raise Fault Policy --->
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<RaiseFault async="false" continueOnError="false" enabled="true" name="RaiseFault-MissingAccessToken">
    <DisplayName>RaiseFault-MissingAccessToken</DisplayName>
    <Properties/>
    <FaultResponse>
        <Set>
            <Headers/>
            <Payload contentType="application/json">{"fault":{"faultstring":"Invalid Access Token","detail":{"errorcode":"keymanagement.service.invalid_access_token"}}}</Payload>
            <StatusCode>500</StatusCode>
            <ReasonPhrase>Internal Server Error</ReasonPhrase>
        </Set>
    </FaultResponse>
    <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</RaiseFault>

يمكن إضافة سياسة RaiseFault بشكل مشروط قبل سياسة SetOauthV2Info في عملية الخادم الوكيل كما هو موضّح في المثال أدناه:

<Step>
  <!-- Execute RaiseFault policy if access_token flow variable is null -->
  <Condition>access_token = null</Condition>
  <Name>RaiseFault-MissingAccessToken</Name>
</Step>
<Step>
  <!-- Execute SetOAuthV2Info policy if access_token flow variable is null -->
  <Condition>access_token != null</Condition>
  <Name>SetOAuthV2Info</Name>
</Step>

ستُصدر شركة Apigee تصحيحًا لاستعادة السلوك المذكور أعلاه لإصدارَي Edge For Private Cloud 4.52.02 و4.53.00.

عند تحديث Edge for Private Cloud من الإصدار 4.51.00 أو 4.52.00 أو 4.52.01 إلى الإصدار 4.52.02، توقّع تأثيرًا إضافيًا على واجهات برمجة التطبيقات الخاصة بوقت التشغيل والإدارة.

يحدث هذا التأثير بعد تعديل عقد Cassandra ويستمر إلى أن يتم تعديل جميع عقد معالج الرسائل وخادم الإدارة.

عند حدوث ذلك، توقّع حدوث تأثير في أحد الجوانب التالية:

• إعادة تحميل رمز OAuth من خلال واجهات برمجة التطبيقات لوقت التشغيل
• واجهات برمجة التطبيقات لإدارة إدراج تطبيقات المطوّرين
• واجهات برمجة التطبيقات لإدارة المنتجات

ستنشر شركة Apigee مستندات تعديل مُعدَّلة لإصدار Edge for Private Cloud 4.52.02 تعالج هذه المشكلة.

لا تؤثّر هذه المشكلة إلا في المستخدمين الذين يستخدمون MINT أو فعّلوا MINT في عمليات تثبيت Edge for Private Cloud.

المكوّن المتأثّر: edge-message-processor

المشكلة: إذا كانت ميزة تحقيق الربح مفعّلة وكنت بصدد تثبيت الإصدار 4.52.01 كعملية تثبيت جديدة أو كنت بصدد الترقية من إصدارات Private Cloud السابقة، ستواجه مشكلة في معالجات الرسائل. ستتم زيادة تدريجية في عدد سلاسل المحادثات المفتوحة، ما سيؤدي إلى استنفاد الموارد. يظهر الاستثناء التالي في سجلّ system.log الخاص بمعالج الرسائل على الحافة:

Error injecting constructor, java.lang.OutOfMemoryError: unable to create new native thread

تم مؤخرًا اكتشاف ثغرة أمنية لرفض الخدمة (DoS) في عدة عمليات تنفيذ لبروتوكول HTTP/2 (CVE-2023-44487)، بما في ذلك في Apigee Edge لخدمات "سحابة خاصة". يمكن أن تؤدي هذه الثغرة الأمنية إلى حجب الخدمة في وظيفة إدارة واجهة برمجة التطبيقات Apigee API. لمزيد من التفاصيل، يُرجى الاطّلاع على نشرة أمان Apigee GCP-2023-032.

تكون مكوّنات جهاز التوجيه وخادم الإدارة في Edge for Private Cloud مفتوحة أمام الإنترنت، ومن المحتمل أن تكون معرّضة للاختراق. على الرغم من أنّ بروتوكول HTTP/2 مفعّل في منفذ التحكم في المكونات الأخرى الخاصة بخدمة Edge في "سحابة Edge الخاصة"، لا يتم الكشف عن أي من هذه المكونات على الإنترنت. في المكونات غير المخصّصة لنظام Edge، مثل Cassandra وZookeeper وغيرها، لا يكون بروتوكول HTTP/2 مفعّلاً. ننصحك باتّباع الخطوات التالية لمعالجة ثغرة Edge for Private Cloud الأمنية:

• الخطوات الخاصة بإصدارات Edge for Private Cloud 4.51.00.11 أو الإصدارات الأحدث
• الخطوات المتعلقة بإصدارات Edge for Private Cloud الأقدم من 4.51.00.11

اتّبِع الخطوات التالية إذا كنت تستخدم الإصدار 4.51.00.11 من Edge Private Cloud أو إصدارًا أحدث:

1. تعديل خادم الإدارة:

   1. في كل عقدة من خوادم الإدارة، افتح /opt/apigee/customer/application/management-server.properties
   2. أضِف هذا السطر إلى ملف المواقع:

      conf_webserver_http2.enabled=false

   3. أعِد تشغيل مكوّن خادم الإدارة:

      apigee-service edge-management-server restart

2. تعديل معالِج الرسائل:

   1. في كل عقدة من عقد معالج الرسائل، افتح /opt/apigee/customer/application/message-processor.properties
   2. أضِف هذا السطر إلى ملف المواقع:

      conf_webserver_http2.enabled=false

   3. أعِد تشغيل مكوّن "معالج الرسائل":

      apigee-service edge-message-processor restart

3. تعديل جهاز التوجيه:

   1. في كل عقدة موجّه، افتح /opt/apigee/customer/application/router.properties.
   2. أضِف هذا السطر إلى ملف المواقع:

      conf_webserver_http2.enabled=false

   3. أعِد تشغيل مكوّن "معالج الرسائل":

      apigee-service edge-router restart

4. تعديل QPID:

   1. في كل عقدة QPID، افتح /opt/apigee/customer/application/qpid-server.properties
   2. أضِف هذا السطر إلى ملف المواقع:

      conf_webserver_http2.enabled=false

   3. أعِد تشغيل مكوّن "معالج الرسائل":

      apigee-service edge-qpid-server restart

5. تعديل Postgres:

   1. في كل عقدة من عقد Postgres، افتح /opt/apigee/customer/application/postgres-server.properties.
   2. أضِف هذا السطر إلى ملف المواقع:

      conf_webserver_http2.enabled=false

   3. أعِد تشغيل مكوّن "معالج الرسائل":

      apigee-service edge-postgres-server restart

اتّبِع الخطوات التالية إذا كنت تستخدم إصدارات Edge for Private Cloud أقدم من 4.51.00.11:

1. تعديل خادم الإدارة:

   1. في كل عقدة من خوادم الإدارة، افتح /opt/apigee/customer/application/management-server.properties
   2. أضِف السطرَين التاليَين إلى ملف الخصائص:

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. أعِد تشغيل مكوّن خادم الإدارة:

      apigee-service edge-management-server restart

2. تعديل معالِج الرسائل:

   1. في كل عقدة من عقد معالج الرسائل، افتح /opt/apigee/customer/application/message-processor.properties
   2. أضِف السطرَين التاليَين إلى ملف الخصائص:

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. أعِد تشغيل مكوّن "معالج الرسائل":

      apigee-service edge-message-processor restart

3. تعديل جهاز التوجيه:

   1. في كل عقدة موجّه، افتح /opt/apigee/customer/application/router.properties.
   2. أضِف السطرَين التاليَين إلى ملف الخصائص:

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. أعِد تشغيل مكوّن "معالج الرسائل":

      apigee-service edge-router restart

4. تعديل QPID:

   1. في كل عقدة QPID، افتح /opt/apigee/customer/application/qpid-server.properties
   2. أضِف السطرَين التاليَين إلى ملف الخصائص:

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. أعِد تشغيل مكوّن "معالج الرسائل":

      apigee-service edge-qpid-server restart

5. تعديل Postgres:

   1. في كل عقدة من عقد Postgres، افتح /opt/apigee/customer/application/postgres-server.properties.
   2. أضِف السطرَين التاليَين إلى ملف الخصائص:

      conf_webserver_http2.enabled=false
      conf/webserver.properties+http2.enabled=false

   3. أعِد تشغيل مكوّن "معالج الرسائل":

      apigee-service edge-postgres-server restart

تواجه أداة Apigee-postgresql مشاكل في الترقية من الإصدار 4.50 أو 4.51 من Edge for Private Cloud إلى الإصدار 4.52. تحدث المشاكل بشكل أساسي عندما يكون عدد الجداول أكبر من 500.

يمكنك التحقّق من إجمالي عدد الجداول في Postgres من خلال تنفيذ استعلام SQL أدناه:

select count(*) from information_schema.tables

الحلّ البديل: عند تحديث Apigee Edge 4.50.00 أو 4.51.00 إلى 4.52.00، تأكَّد من تنفيذ الخطوة التمهيدية قبل ترقية Apigee-postgresql.

149245401: لا يتم عرض إعدادات تجمع اتصالات LDAP لـ JNDI التي تم ضبطها من خلال مورد LDAP ، ويؤدي الإعداد التلقائي لـ JNDI إلى إجراء عمليات اتصال لمرة واحدة في كل مرة. ونتيجةً لذلك، يتم فتح اتصالات وإغلاقها في كل مرة لاستخدام واحد، ما يؤدي إلى إنشاء عدد كبير من عمليات الاتصال في الساعة مع خادم LDAP.

الحلّ:

لتغيير سمات مجموعة اتصالات LDAP، اتّبِع الخطوات التالية لضبط تغيير شامل على مستوى جميع سياسات LDAP.

1. أنشئ ملفًا لخصائص الإعدادات إذا لم يكن متوفّرًا:

   /opt/apigee/customer/application/message-processor.properties

2. أضِف ما يلي إلى الملف (استبدِل قيم سمات Java Naming and Directory Interface (JNDI) استنادًا إلى متطلبات إعداد موارد LDAP).

   bin_setenv_ext_jvm_opts="-Dcom.sun.jndi.ldap.connect.pool.maxsize=20
   -Dcom.sun.jndi.ldap.connect.pool.prefsize=2
   -Dcom.sun.jndi.ldap.connect.pool.initsize=2
   -Dcom.sun.jndi.ldap.connect.pool.timeout=120000
   -Dcom.sun.jndi.ldap.connect.pool.protocol=ssl"

3. تأكَّد من أنّ الملف /opt/apigee/customer/application/message-processor.properties هو ملك apigee:apigee.
4. أعِد تشغيل كل معالج رسائل.

للتأكّد من أنّ خصائص JNDI في حوض اتصالات LDAP مفعّلة، يمكنك تنفيذ tcpdump لمراقبة سلوك حوض اتصالات LDAP بمرور الوقت.

‎139051927: تؤثر مدة الاستجابة العالية لمعالجة الوكيل في "معالج الرسائل" في جميع وكلاء واجهة برمجة التطبيقات. تشمل الأعراض تأخّرًا في أوقات المعالجة يتراوح بين 200 و300 مللي ثانية مقارنةً بالمعدّل الطبيعي لوقت ردّ واجهة برمجة التطبيقات ، ويمكن أن يحدث ذلك بشكل عشوائي حتى مع انخفاض عدد عمليات الجلسة في الثانية. يمكن أن يحدث ذلك عندما يكون هناك أكثر من 50 خادمًا مستهدفًا يجري فيه معالِج الرسائل عمليات اتصال.

السبب الأساسي: تحتفظ معالجات الرسائل بذاكرة تخزين مؤقت تربط عنوان URL للخادم المستهدَف بعنصر HTTPClient ل عمليات الاتصال الصادرة إلى الخوادم المستهدَفة. يتم ضبط هذا الإعداد تلقائيًا على 50، وقد يكون منخفضًا جدًا لمعظم عمليات النشر. عندما يتضمّن النشر مجموعات متعدّدة من عناوين URL للمؤسسة/البيئة في عملية الإعداد، وكان يتضمّن عددًا كبيرًا من الخوادم المستهدَفة يتجاوز 50 خادمًا، تتم باستمرار إزالة عناوين URL للخادم المستهدَف من ذاكرة التخزين المؤقت، ما يؤدي إلى حدوث تأخيرات.

التحقّق من الصحة: لتحديد ما إذا كان إخراج عنوان URL للخادم المستهدَف يتسبّب في مشكلة وقت الاستجابة، ابحث فيملف log.system الخاص بمُعالج الرسائل عن الكلمة الرئيسية onEvict أو Eviction. يشير ظهورها في السجلات إلى أنّ عناوين URL للخادم المستهدَف يتم إزالتها من ذاكرة التخزين المؤقت لـ HTTPClient لأنّ حجم ذاكرة التخزين المؤقت صغير جدًا.

حلّ بديل: بالنسبة إلى الإصدارَين 19.01 و19.06 من Edge for Private Cloud، يمكنك تعديل ذاكرة التخزين المؤقت لـ HTTPClient وضبطها، /opt/apigee/customer/application/message-processor.properties:

conf/http.properties+HTTPClient.dynamic.cache.elements.size=500

بعد ذلك، أعِد تشغيل معالِج الرسائل. أجرِ التغييرات نفسها لجميع معالجات الرسائل.

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

ملاحظة: في الإصدار 50.00 من Edge for Private Cloud، يكون الإعداد التلقائي هو 500.

‎157933959: إنّ عمليات الإدراج والتعديل المتزامنة لجدول الربط بين المفاتيح والقيم (KVM) نفسه على مستوى المؤسسة أو البيئة تؤدي إلى ظهور بيانات غير متّسقة وفقدان التعديلات.

ملاحظة: ينطبق هذا التقييد على Edge for Private Cloud فقط. لا ينطبق هذا القيد على Edge for Public Cloud وHybrid.

للحصول على حل بديل في Edge for Private Cloud، أنشئ وحدة تحكّم افتراضية للأجهزة في نطاق apiproxy.