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

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

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

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

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

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

تطوير إعدادات الخادم الوكيل على الجهاز

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

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

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

1. نزِّل إعدادات الخادم الوكيل الحالية في واجهة مستخدم Edge. (في عرض "خوادم وكيل واجهة برمجة التطبيقات" (API Proxies)، انقر على المشروع (Project) > تنزيل المراجعة (Download Revision)).
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
  • إعدادات 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

كيفية ضبط RouteRules

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

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

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

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

يمكن أن يستدعي ProxyEndpoint أيضًا خدمة خلفية مباشرةً. يتجاوز استدعاء عنوان URL المباشر أي إعدادات TargetEndpoints مسماة ضمن /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 أو محتوى الرسالة أو مَعلمات طلب البحث أو المعلومات السياقية، مثل وقت اليوم أو اللغة أو غير ذلك.

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

على سبيل المثال، يقيّم مزيج RouteRule التالي أولاً الطلب الوارد للتحقّق من قيمة عنوان HTTP. إذا كان عنوان HTTP routeTo يتضمّن القيمة TargetEndpoint1، تتم إعادة توجيه الطلب إلى TargetEndpoint الذي يحمل الاسم 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

‫TargetEndpoint هو المكافئ الصادر لـ ProxyEndpoint. تعمل TargetEndpoint كعميل لخدمة أو واجهة برمجة تطبيقات خلفية، إذ ترسل الطلبات وتتلقّى الردود.

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

إعدادات TargetEndpoint

/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>

عناصر TargetEndpoint Configuration

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

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

يمكنك ضبط إحدى هذه الإعدادات فقط في TargetEndpoint.

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

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

عناصر إعدادات TargetEndpoint الخاصة ببروتوكول أمان طبقة النقل (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/SSL بشكل ديناميكي

يمكنك أيضًا ضبط تفاصيل بروتوكول أمان طبقة النقل (TLS) وطبقة المقابس الآمنة (SSL) بشكل ديناميكي لتلبية متطلبات وقت التشغيل المرنة. على سبيل المثال، إذا كان الخادم الوكيل يتصل بهدفَين مختلفَين محتمَلَين (هدف اختبار وهدف إنتاج)، يمكنك أن تجعل خادم API الوكيل يكتشف بشكل آلي البيئة التي يتم استدعاؤها ويضبط مراجع مخزن المفاتيح ومخزن الشهادات الموثوقة بشكل ديناميكي. توضّح مقالة منتدى Apigee التالية هذا السيناريو بالتفصيل وتقدّم أمثلة على خوادم وكيلة لواجهة برمجة التطبيقات يمكن نشرها: Dynamic SSLInfo for TargetEndpoint using variable reference.

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

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

<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/SSL بشكل ديناميكي

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

لمزيد من المعلومات، يُرجى الاطّلاع على تعديل شهادة TLS.

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

على سبيل المثال، يوضّح ما يلي TargetEndpoint الذي يستخدم مرجعًا إلى مخزن المفاتيح:

<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 مع موازنة التحميل المستهدَفة

تتيح TargetEndpoints موازنة التحميل على مستوى عدة خوادم TargetServer مسماة باستخدام ثلاث خوارزميات لموازنة التحميل.

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

السياسات

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

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

مرفق السياسة

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

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

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

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

يتم تطبيق السياسات بالترتيب الذي يتم إرفاقها به في Flow. على سبيل المثال:

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

عناصر إعدادات ربط السياسة

عمليات سير العمل

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

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

بالإضافة إلى ذلك، يمكنك إضافة PostClientFlow إلى ProxyEndpoint، والذي يتم تنفيذه بعد إرجاع الرد إلى تطبيق العميل الذي أرسل الطلب. يمكن ربط سياسة MessageLogging وإضافة Google Stackdriver Logging بهذا المسار فقط. يقلّل 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>
    ...

يتم تنفيذ مسار معالجة خادم وكيل واجهة برمجة التطبيقات (API) في "التدفقات" بالتسلسل التالي:

مسار الطلب:

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

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

1. Target Response PreFlow
2. مسارات الردّ الشرطية المستهدَفة (اختياري)
3. Target Response PostFlow
4. Proxy Response PreFlow
5. عمليات سير مشروطة لردود الخادم الوكيل (اختياري)
6. Proxy Response 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، ويتم تنفيذ سير عمل شرطي واحد فقط.

على سبيل المثال، في إعدادات Flow التالية، سيؤدي أي طلب وارد لا يتضمّن لاحقة المسار /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>

المراجع

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

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

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

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