مرجع ضبط الخادم الوكيل لواجهة برمجة التطبيقات

يتم الآن عرض مستندات Apigee Edge.
انتقِل إلى مستند Apigee X. المعلومات

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

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

تتمثل الطرق الأكثر شيوعًا لتعديل عمليات ضبط الخادم الوكيل في ما يلي:

• استخدام محرِّر XML في واجهة مستخدم Edge
• نزِّل الإعدادات وعدِّلها محليًا، كما هو موضّح في التطوير المحلي لعمليات ضبط الخادم الوكيل.

التطوير المحلي لإعدادات الخادم الوكيل

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

يصف هذا القسم كيفية استخدام واجهة المستخدم لتنزيل دمج وكيل حالي وتعديله، ثم تحميله مرة أخرى إلى Edge للنشر. يمكنك أيضًا استخدام apigeetools لتنزيل إعداد جديد للخادم الوكيل ونشره (باستخدام الأمرَين fetchproxy وdeployproxy على التوالي).

لتعديل إعدادات الخادم الوكيل محليًا باستخدام واجهة المستخدم:

1. نزِّل إعدادات الخادم الوكيل الحالية في واجهة مستخدم Edge. (في عرض خوادم واجهة برمجة التطبيقات، اختَر المشروع > تنزيل النسخة السابقة.)
2. على جهازك المحلي، أنشِئ دليلاً جديدًا ووسِّع ملف ZIP الذي تم تنزيله فيه.

   لتوسيع ملف ZIP، يمكنك استخدام أداة مساعدة مثل unzip، على النحو الموضّح في المثال التالي:

   mkdir myappdir
   unzip ./my-app_app_rev3_2019_04_20.zip -d myappdir

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

3. عدِّل الملفات المصدر حسب الضرورة. للحصول على وصف للملفات المصدر في إعداد الخادم الوكيل، يُرجى الاطّلاع على ملفات الإعداد وبنية الدليل للخادم الوكيل لواجهة برمجة التطبيقات.

   على سبيل المثال، لتفعيل ميزة مراقبة السلامة في الخادم الوكيل لواجهة برمجة التطبيقات، عليك تعديل ملف الإعداد TargetEndpoint في دليل /apiproxy/targets/. الملف التلقائي في هذا الدليل هو default.xml، ولكن قد تتضمن ملفات بأسماء مختلفة إذا كنت تستخدم الأهداف الشرطية.

   في هذه الحالة، إذا لم يتوفر ملف الإعداد TargetEndpoint والدليل الخاص به، عليك إنشاؤهما.

4. بعد الانتهاء من تعديل ملفات تهيئة الخادم الوكيل، تأكد من حفظ التغييرات.
5. غيِّر إلى الدليل الجديد الذي أنشأته بعد توسيع ملفات ZIP (جذر ملفات الإعداد الموسّعة).

   على سبيل المثال، إذا وسّعت الملفات إلى دليل /myappdir، يمكنك تغييرها إلى ذلك الدليل، كما يبيِّن المثال التالي:

   cd myappdir

   عليك التغيير إلى هذا الدليل قبل إعادة أرشفة ملفات إعداد الخادم الوكيل لأنّك لا تريد تضمين دليل /myappdir في ملف ZIP. يجب أن يكون دليل المستوى الأعلى في ملف ZIP /apiproxy.

6. أعِد أرشفة ملفات إعداد الخادم الوكيل، بما في ذلك الملفات الجديدة أو التي تم تغييرها. يمكنك استخدام أداة مساعدة مثل zip، كما يوضِّح المثال التالي:

   zip my-new-proxy.zip -r .

   يجب أن يكون دليل المستوى الأعلى في ملف ZIP /apiproxy.

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

   تعمل شبكة Edge على زيادة رقم النسخة السابقة لإعدادات الخادم الوكيل الجديدة لك عند تحميلها.

7. حمِّل إعدادات الخادم الوكيل الجديدة باستخدام واجهة مستخدم Edge. (في طريقة عرض الخوادم الوكيلة لواجهة برمجة التطبيقات، اختَر مشروع > تحميل مراجعة جديدة.)

   إذا ظهرت لك رسالة خطأ مثل Bundle is invalid. Empty bundle.، تأكَّد من أنّ دليل المستوى الأعلى لملف ZIP هو /apiproxy. وإذا لم يكن الأمر كذلك، يمكنك إعادة أرشفة ملفات ضبط الخادم الوكيل من جذر الدليل الموسَّع.

   بعد تحميل إعدادات الخادم الوكيل الجديدة، تزيد Edge من رقم النسخة السابقة وتعرضها في طريقة عرض ملخّص المراجعة.

   لا ينشر Edge الإصدار الجديد لك بعد تحميله باستخدام واجهة المستخدم.

8. نشر النسخة الجديدة

لمزيد من المعلومات، يُرجى الاطّلاع على البرنامج التعليمي: كيفية تنزيل خادم وكيل باستخدام واجهة المستخدم وواجهة برمجة تطبيقات الإدارة في منتدى Apigee.

بنية الخادم الوكيل لواجهة برمجة التطبيقات

يتألف الخادم الوكيل لواجهة برمجة التطبيقات من الإعدادات التالية:

بنية دليل الخادم الوكيل لواجهة برمجة التطبيقات ومحتواه

يتم تحديد المكوّنات الواردة في الجدول أعلاه من خلال ملفات الإعداد في بنية الدليل التالية:

ملفات الإعداد وبنية الدليل للخادم الوكيل لواجهة برمجة التطبيقات

يشرح هذا القسم ملفات الإعداد وبنية الدليل للخادم الوكيل لواجهة برمجة التطبيقات.

• الإعداد الأساسي
• ProxyEndpoint
• TargetEndpoint
  • إعداد نقطة نهاية بروتوكول أمان طبقة النقل (TLS)/طبقة المقابس الآمنة (SSL)
• السياسات
• التدفقات
• المراجع

الضبط الأساسي

/apiproxy/weatherapi.xml

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

نموذج الضبط:

<APIProxy name="weatherapi">
</APIProxy>

عناصر الإعداد الأساسية

ProxyEndpoint

تُظهر الصورة التالية مسار الطلب/الاستجابة:

/apiproxy/proxies/default.xml

تحدّد إعدادات ProxyEndpoint الواجهة الواردة (المواجهة للعميل) للخادم الوكيل لواجهة برمجة التطبيقات. عند ضبط ProxyEndpoint، يعني ذلك أنّك تضبط إعدادات شبكة تحدِّد الطريقة التي يجب أن تستدعي بها تطبيقات العميل ("التطبيقات") واجهة برمجة التطبيقات التي تم إنشاء خادم وكيل لها.

سيتم تخزين نموذج إعداد ProxyEndpoint التالي ضمن /apiproxy/proxies:

<ProxyEndpoint name="default">
  <PreFlow/>
  <Flows/>
  <PostFlow/>
  <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <VirtualHost>default</VirtualHost>
  </HTTPProxyConnection>
  <FaultRules/>
  <DefaultFaultRule/>
  <RouteRule name="default">
    <TargetEndpoint>default</TargetEndpoint>
  </RouteRule>
</ProxyEndpoint>

عناصر الضبط المطلوبة في ProxyEndpoint الأساسي هي:

عناصر إعداد ProxyEndpoint

كيفية ضبط قواعد التوجيه

تشير قيمة TargetEndpoint المُسمّاة إلى ملف إعداد ضمن /apiproxy/targets تعيد قاعدة RouteRule التوجيه إليه طلب بعد أن تتم معالجته بواسطة ProxyEndpoint.

على سبيل المثال، تشير قاعدة RouteRule التالية إلى إعدادات /apiproxy/targets/myTarget.xml:

<RouteRule name="default">
  <TargetEndpoint>myTarget</TargetEndpoint>
</RouteRule>

استدعاء عنوان URL المباشر

يمكن أيضًا لـ ProxyEndpoint استدعاء خدمة خلفية مباشرةً. يتجاوز استدعاء عنوان URL المباشر أي إعداد مُسمّى لنقاط النهاية المستهدفة ضمن /apiproxy/targets. لهذا السبب، يُعد الهدف TargetEndpoint إعدادًا اختياريًا للخادم الوكيل في واجهة برمجة التطبيقات، على الرغم من أنّه لا يُنصح من الناحية العملية باستخدام الاستدعاء المباشر من ProxyEndpoint.

على سبيل المثال، تُجري قاعدة RouteRule التالية طلب HTTP إلى http://api.mycompany.com/v2.

<RouteRule name="default">
  <URL>http://api.mycompany.com/v2</URL> 
</RouteRule>

المسارات المشروطة

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

تعمل قواعد المسار الشرطي مثل العبارات الشرطية الأخرى في Apigee Edge. اطّلِع على مرجع الشروط ومرجع المتغيّرات.

على سبيل المثال، تقيّم مجموعة RouteRule التالية أولاً الطلب الوارد للتحقّق من قيمة عنوان HTTP. وإذا كان عنوان HTTP routeTo يحتوي على القيمة TargetEndpoint1، تتم إعادة توجيه الطلب إلى نقطة النهاية الهدف باسم TargetEndpoint1. إذا لم يكن الأمر كذلك، ستتم إعادة توجيه الطلب الوارد إلى http://api.mycompany.com/v2.

<RouteRule name="MyRoute">
  <Condition>request.header.routeTo = "TargetEndpoint1"</Condition>
  <TargetEndpoint>TargetEndpoint1</TargetEndpoint>
</RouteRule>
<RouteRule name="default">
  <URL>http://api.mycompany.com/v2</URL>
</RouteRule>

المسارات الخالية

يمكن تحديد RouteRule الفارغة لدعم السيناريوهات التي لا يلزم فيها إعادة توجيه رسالة الطلب إلى TargetEndpoint. ويكون هذا الإجراء مفيدًا عندما يُجري ProxyEndpoint جميع عمليات المعالجة اللازمة، مثلاً عن طريق استخدام JavaScript لطلب خدمة خارجية أو استرداد البيانات من البحث في مخزن القيم/المفاتيح في خدمات واجهة برمجة التطبيقات.

على سبيل المثال، يحدد ما يلي مسارًا خاليًا:

<RouteRule name="GoNowhere"/>

يمكن أن تكون المسارات الفارغة المشروطة مفيدة. في المثال التالي، يتم إعداد مسار فارغ لتنفيذه عندما يحتوي عنوان HTTP request.header.X-DoNothing على قيمة أخرى غير null.

<RouteRule name="DoNothingOnDemand">
  <Condition>request.header.X-DoNothing != null</Condition>
</RouteRule>

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

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

<RouteRule name="DoNothingUnlessTheCacheIsStale">
  <Condition>lookupcache.LookupCache-1.cachehit is true</Condition>
</RouteRule>

TargetEndpoint

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

لا يحتاج الخادم الوكيل لواجهة برمجة التطبيقات إلى أي نقاط نهاية هدف. يمكن ضبط ProxyEndpoints لطلب عناوين URL مباشرةً. عادةً ما يحتوي الخادم الوكيل لواجهة برمجة التطبيقات الذي لا يشتمل على TargetEndpoints على نقطة ProxyEndpoint تستدعي بشكلٍ مباشر خدمة خلفية أو تم إعداده لاستدعاء خدمة باستخدام JavaScript أو JavaScript.

إعداد نقطة النهاية المستهدفة

/targets/default.xml

تحدّد TargetEndpoint الاتصال الصادر من Apigee Edge إلى خدمة أو مورد آخر.

في ما يلي نموذج لإعدادات TargetEndpoint:

<TargetEndpoint name="default">
  <PreFlow/>
  <Flows/>
  <PostFlow/>
  <HTTPTargetConnection>
    <URL>http://mocktarget.apigee.net</URL>
    <SSLInfo/>
  </HTTPTargetConnection>
  <FaultRules/>
  <DefaultFaultRule/>
  <ScriptTarget/>
  <LocalTargetConnection/>
</TargetEndpoint>

عناصر ضبط نقطة النهاية المستهدفة

يمكن لنقطة النهاية المستهدفة استدعاء هدف بإحدى الطرق التالية:

• HTTPTargetConnection لاستدعاءات HTTP(S)
• LocalTargetConnection لسلسلة الخادم الوكيل المحلي إلى الخادم الوكيل
• ScriptTarget لطلبات البيانات الواردة إلى نص Node.js البرمجي الذي يستضيفه Edge.

اضبط مصدرًا واحدًا فقط من هذه الإعدادات في TargetEndpoint.

ضبط بروتوكول أمان طبقة النقل (TLS)/طبقة المقابس الآمنة (SSL)

تحتاج غالبًا ما تحتاج نقاط النهاية إلى إدارة اتصالات HTTPS باستخدام بنية أساسية غير متجانسة في الخلفية. ولهذا السبب، يتوفر عدد من إعدادات ضبط بروتوكول أمان طبقة النقل (TLS)/طبقة المقابس الآمنة (SSL).

عناصر إعداد نقطة النهاية الهدف (TLS)/طبقة المقابس الآمنة (SSL)

<Ciphers>
 <Cipher>TLS_RSA_WITH_3DES_EDE_CBC_SHA</Cipher>    
 <Cipher>TLS_RSA_WITH_DES_CBC_SHA</Cipher>
</Ciphers>

<Protocols>
 <Protocol>TLSv1.1</Protocol>
 <Protocol>TLSv1.2</Protocol>
</Protocols>

<CommonName wildcardMatch="true">*.myhost.com</CommonName>

نموذج TargetEndpoint مع تفعيل مصادقة العميل الصادر

<TargetEndpoint name="default">
  <HttpTargetConnection>
        <URL>https://myservice.com</URL>
    <SSLInfo>
      <Enabled>true</Enabled>
      <ClientAuthEnabled>true</ClientAuthEnabled>
      <KeyStore>myKeystore</KeyStore>
      <KeyAlias>myKey</KeyAlias>
      <TrustStore>myTruststore</TrustStore>
    </SSLInfo>
  </HttpTargetConnection>
</TargetEndpoint>

للحصول على التعليمات التفصيلية، يُرجى الاطّلاع على ضبط بروتوكول أمان طبقة النقل (TLS) من Edge إلى الخلفية (السحابة الإلكترونية والسحابة الخاصة).

استخدام متغيّرات التدفق لضبط قيم بروتوكول أمان طبقة النقل (TLS) وطبقة المقابس الآمنة بشكل ديناميكي

ويمكنك أيضًا ضبط تفاصيل بروتوكول أمان طبقة النقل أو طبقة المقابس الآمنة ديناميكيًا لتلبية متطلبات وقت التشغيل المرن. على سبيل المثال، إذا كان الخادم الوكيل يتصل بهدفين من المحتمل أن يكونا مختلفَين (هدف اختباري وهدف إنتاج)، يمكنك أن تطلب من الخادم الوكيل لواجهة برمجة التطبيقات اكتشاف البيئة التي يتصل بها بشكل آلي وإضافة مراجع ديناميكية إلى ملف تخزين المفاتيح وملف تخزين المفاتيح الملائمَين. تشرح مقالة "منتدى Apigee" التالية هذا السيناريو بمزيد من التفصيل، وتقدّم أمثلة عن الخادم الوكيل لواجهة برمجة التطبيقات القابلة للنشر: https://community.apigee.com/articles/21424/dynamic-sslinfo-for-targetendpoint-using-variable.html.

في المثال التالي حول كيفية ضبط علامة <SSLInfo> في إعدادات TargetEndpoint، يمكن توفير القيم في وقت التشغيل، على سبيل المثال، باستخدام وسيلة شرح Java أو سياسة JavaScript أو سياسة "تعيين رسالة". استخدِم متغيّرات الرسالة التي تحتوي على القيم التي تريد ضبطها.

يُسمح بالمتغيرات في العناصر التالية فقط.

<SSLInfo>
    <Enabled>{myvars.ssl.enabled}</Enabled>
    <ClientAuthEnabled>{myvars.ssl.client.auth.enabled}</ClientAuthEnabled>
    <KeyStore>{myvars.ssl.keystore}</KeyStore>
    <KeyAlias>{myvars.ssl.keyAlias}</KeyAlias>
    <TrustStore>{myvars.ssl.trustStore}</TrustStore>
</SSLInfo>

استخدام المراجع لضبط قيم بروتوكول أمان طبقة النقل (TLS)/طبقة المقابس الآمنة بشكل ديناميكي

عند ضبط TargetEndpoint تستخدم بروتوكول HTTPS، يجب مراعاة حالة انتهاء صلاحية شهادة بروتوكول أمان طبقة النقل (TLS) أو طبقة المقابس الآمنة (SSL)، أو عندما يتطلب منك تغيير إعدادات النظام تحديث الشهادة. عند تثبيت Edge for Private Cloud، قد تحتاج إلى إعادة تشغيل معالجات الرسائل عند ضبط بروتوكول أمان طبقة النقل (TLS) أو طبقة المقابس الآمنة (SSL) باستخدام قيم ثابتة أو من خلال استخدام متغيرات التدفق.

لمعرفة مزيد من المعلومات، يُرجى الاطّلاع على تعديل شهادة بروتوكول أمان طبقة النقل (TLS).

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

على سبيل المثال، الموضح أدناه هو نقطة نهاية الاستهداف التي تستخدم مرجعًا إلى ملف تخزين المفاتيح:

<SSLInfo> 
    <Enabled>true</Enabled> 
    <ClientAuthEnabled>false</ClientAuthEnabled> 
    <KeyStore>ref://keystoreref</KeyStore> 
    <KeyAlias>myKeyAlias</KeyAlias> 
</SSLInfo>

استخدِم طلب POST API التالي لإنشاء المرجع باسم keystoreref:

curl -X POST  -H "Content-Type:application/xml" https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/references \
-d '<ResourceReference name="keystoreref">
    <Refers>myTestKeystore</Refers>
    <ResourceType>KeyStore</ResourceType>
</ResourceReference>' -u email:password

يحدد المرجع اسم ملف تخزين المفاتيح ونوعه.

استخدم استدعاء GET API التالي لعرض المرجع:

curl -X GET https://api.enterprise.apigee.com/v1/o/[org_name}/e/{env_name}/references/keystoreref -u uname:password

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

curl -X PUT -H "Content-Type:application/xml" https://api.enterprise.apigee.com/v1/o/{org_name}/e/{env_name}/references/keystoreref \
-d '<ResourceReference name="keystoreref">
    <Refers>myNewKeystore</Refers>
    <ResourceType>KeyStore</ResourceType>
</ResourceReference>' -u email:password

TargetEndpoint مع موازنة التحميل الهدف

تدعم نقاط النهاية المستهدفة موازنة التحميل على مستوى عدة خوازمات مسماة من TargetServers، وذلك باستخدام ثلاث خوارزميات لموازنة التحميل.

للحصول على تعليمات تفصيلية، يُرجى الاطّلاع على موازنة التحميل على مستوى الخوادم الخلفية.

السياسات

يحتوي دليل /policies في الخادم الوكيل لواجهة برمجة التطبيقات على جميع السياسات المتاحة التي يمكن إرفاقها بمسارات المساعدة في الخادم الوكيل لواجهة برمجة التطبيقات.

عناصر ضبط السياسة

مرفق السياسة

تُظهر الصورة التالية تسلسل تنفيذ تدفقات الخادم الوكيل لواجهة برمجة التطبيقات:

كما هو موضح أعلاه:

يتم إرفاق السياسات كخطوات معالجة بسياسة التدفقات. يُستخدم اسم السياسة للإشارة إلى السياسة التي سيتم فرضها كخطوة معالجة. في ما يلي تنسيق مرفق السياسة:

<Step><Name>MyPolicy</Name></Step>

يتم فرض السياسات بالترتيب الذي يتم تطبيقها به في التدفق. مثال:

<Step><Name>FirstPolicy</Name></Step>
<Step><Name>SecondPolicy</Name></Step>

عناصر ضبط مرفقات السياسة

التدفقات

تحدّد ProxyEndpoint وTargetEndpoint مسارًا لمعالجة الطلبات ورسائل الاستجابة. يتكون مسار المعالجة من تدفق الطلب وتدفق الاستجابة. يتم تقسيم مسار كل طلب وعملية استجابة إلى تنسيق فرعي، وتدفق واحد أو أكثر من النوع "شرطي" أو "مُسمّى" أو PostFlow.

• PreFlow: يتم التنفيذ دائمًا. يتم تنفيذه قبل أي تدفقات شرطية.
• PostFlow: يُنفذ دائمًا. يتم التنفيذ بعد أي تدفقات شرطية.

بالإضافة إلى ذلك، يمكنك إضافة PostClientFlow إلى ProxyEndpoint، إذ يتم تنفيذه بعد إرجاع الاستجابة إلى تطبيق العميل الطالب. لا يمكن إرفاق سوى سياسة MessageLogging وإضافة تسجيل الدخول Google Stackdriver في هذا المسار. يقلل PostClientFlow من وقت استجابة الخادم الوكيل لواجهة برمجة التطبيقات، ويوفّر معلومات لتسجيل الدخول التي لا يتم احتسابها إلا بعد عرض الاستجابة للعميل، مثل client.sent.start.timestamp وclient.sent.end.timestamp.ويستخدم المسار بشكل أساسي لقياس الفاصل الزمني بين الطوابع الزمنية للبدء والانتهاء لرسالة الرد.

مشاهدة فيديو تعليمات سريع

في ما يلي مثال على PostClientFlow مع إرفاق سياسة تسجيل الرسائل.

    ...
    <PostFlow name="PostFlow">
        <Request/>
        <Response/>
    </PostFlow>
    <PostClientFlow>
        <Request/>
        <Response>
            <Step>
                <Name>Message-Logging-1</Name>
            </Step>
        </Response>
    </PostClientFlow>
    ...

ينفِّذ مسار معالجة الخادم الوكيل لواجهة برمجة التطبيقات العمليات بالتسلسل التالي:

مسار الطلب:

1. التدفق المسبق لطلب الخادم الوكيل
2. التدفقات الشَرطية لطلبات الخادم الوكيل (اختياري)
3. PostFlow لطلب الخادم الوكيل
4. التدفق المسبق للطلب المستهدف
5. التدفقات الشرطية للطلب المستهدف (اختياري)
6. PostFlow للطلب المستهدف

مسار الاستجابة:

1. التدفق المُسبَق للاستجابة المستهدَفة
2. التدفقات الشَرطية للاستجابة المستهدفة (اختيارية)
3. PostFlow للاستجابة المستهدَفة
4. التدفق المُسبَق لاستجابة الخادم الوكيل
5. التدفقات الشرطية لاستجابة الخادم الوكيل (اختياري)
6. PostFlow لاستجابة الخادم الوكيل
7. رد PostClientFlow (اختياري)

يجب إعداد المسارات التي تتضمّن مرفقات سياسة فقط في إعدادات ProxyEndpoint أو TargetEndpoint. لا يجب تحديد PreFlow وPostFlow إلا في إعداد ProxyEndpoint أو في ضبط TargetEndpoint فقط عندما يكون من المطلوب فرض سياسة أثناء معالجة PreFlow أو PostFlow.

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

التدفقات الشرطية

يتيح ProxyEndpoints وTargetEndpoints عددًا غير محدود من المسارات الشرطية (التي تُعرَف أيضًا باسم "المسارات المُسمّاة").

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

من خلال تحديد التدفقات الشرطية، يمكنك تطبيق خطوات المعالجة في خادم وكيل لواجهة برمجة التطبيقات استنادًا إلى ما يلي:

• عنوان URI للطلب
• فعل HTTP (GET/PUT/POST/DELETE)
• قيمة معلمة طلب البحث والعنوان ومَعلمة النموذج
• العديد من أنواع الشروط الأخرى

على سبيل المثال، يوضّح التدفق الشرطي التالي أنّه يتم تنفيذه فقط عندما يكون مسار مورد الطلب هو /accesstoken. يؤدي أي طلب وارد ضمن المسار /accesstoken إلى تنفيذ هذا المسار، بالإضافة إلى أي سياسات يتم إرفاقها بالمسار. وإذا لم يتضمن مسار الطلب اللاحقة /accesstoken، لن يتم تنفيذ المسار (على الرغم من احتمال حدوث تدفق شرطي آخر).

<Flows>
  <Flow name="TokenEndpoint">
    <Condition>proxy.pathsuffix MatchesPath "/accesstoken"</Condition>
    <Request>
      <Step>
        <Name>GenerateAccessToken</Name>
      </Step>
    </Request> 
  </Flow>
</Flows>   

عناصر إعداد التدفق

جارٍ معالجة الخطوة

يتم فرض الترتيب التسلسلي للتدفقات الشرطية بواسطة Apigee Edge. يتم تنفيذ التدفقات الشرطية من أعلى إلى أسفل. يتم تنفيذ أول تدفق شرطي يتم تقييم شرطه إلى true، ويتم تنفيذ تدفق شرطي واحد فقط.

على سبيل المثال، في إعدادات التدفق التالي، سيؤدي أي طلب وارد لا يتضمّن لاحقة المسار /first أو /second إلى تنفيذ ThirdFlow، ما يؤدي إلى فرض سياسة تُسمى Return404.

<Flows>
  <Flow name="FirstFlow">
    <Condition>proxy.pathsuffix MatchesPath "/first"</Condition>
    <Request>
      <Step><Name>FirstPolicy</Name></Step>
    </Request>
  </Flow>
  <Flow name="SecondFlow">
    <Condition>proxy.pathsuffix MatchesPath "/second"</Condition>
    <Request>
      <Step><Name>FirstPolicy</Name></Step>
      <Step><Name>SecondPolicy</Name></Step>
    </Request>
  </Flow>
  <Flow name="ThirdFlow">
    <Request>
      <Step><Name>Return404</Name></Step>
    </Request>
  </Flow>
</Flows>

المراجع

"الموارد" (ملفات الموارد التي يمكن استخدامها في الخوادم الوكيلة لواجهة برمجة التطبيقات) هي نصوص برمجية ورموز أو عمليات تحويل XSL يمكن إرفاقها بالمسارات باستخدام السياسات. وتظهر هذه الأخطاء في قسم "النصوص البرمجية" لمحرِّر الخادم الوكيل لواجهة برمجة التطبيقات في واجهة مستخدم الإدارة.

راجِع ملفات الموارد للتعرّف على أنواع الموارد المتوافقة.

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

ويمكن الإشارة إلى مورد مخزَّن على مستوى المؤسسة من خلال "السياسات" في أي بيئة. يمكن الإشارة إلى مورد مخزَّن على مستوى البيئة من خلال "السياسات" في تلك البيئة. لا يمكن الإشارة إلى مورد مخزَّن على مستوى الخادم الوكيل لواجهة برمجة التطبيقات إلا من خلال "السياسات" في الخادم الوكيل لواجهة برمجة التطبيقات هذا.