مرجع پیکربندی پراکسی میانای برنامه‌سازی کاربردی

درحال مشاهده اسناد Apigee Edge هستید.
به اسناد Apigee X بروید. اطلاعات

به‌عنوان توسعه‌دهنده‌ای که با Apigee Edge کار می‌کند، فعالیت‌های توسعه اصلی شما شامل پیکربندی پراکسی‌های API است که به‌عنوان پراکسی برای APIها یا سرویس‌های زیرینه عمل می‌کنند. این سند مرجعی از همه عناصر پیکربندی دردسترس شما هنگام ساختن پراکسی‌های API است.

اگر درحال یادگیری نحوه ساختن پراکسی‌های API هستید، توصیه می‌شود با موضوع ساختن پراکسی API ساده شروع کنید.

رایج‌ترین روش‌های ویرایش پیکربندی‌های پراکسی عبارت‌اند از:

• استفاده از ویرایشگر XML در «میانای کاربر Edge»
• پیکربندی را بارگیری کنید و آن را به‌صورت محلی ویرایش کنید، همان‌طور که در توسعه محلی پیکربندی‌های پراکسی توضیح داده شده است.

توسعه محلی پیکربندی‌های پراکسی

می‌توانید پیکربندی‌های پراکسی خود را بارگیری کنید تا بتوانید آن‌ها را در یک ماشین محلی ویرایش کنید. وقتی کارتان تمام شد، نتایج را در Edge بارگذاری می‌کنید. این رویکرد به شما امکان می‌دهد پیکربندی‌های پراکسی را در کنترل منبع، نسخه‌بندی، و دیگر گردش کارهای هم‌رسانی‌شده ادغام کنید. علاوه‌براین، با کار کردن روی پیکربندی پراکسی به‌صورت محلی، می‌توانید از ویرایشگر XML و ابزارهای اعتبارسنجی خودتان استفاده کنید.

این بخش نحوه استفاده از واسط کاربر برای بارگیری پیکربندی پراکسی موجود، ویرایش آن، و سپس بارگذاری مجدد آن در Edge برای استقرار را شرح می‌دهد. همچنین می‌توانید از apigeetool برای بارگیری و استقرار پیکربندی پراکسی جدید (بااستفاده از دستورات fetchproxy و deployproxy، به‌ترتیب) استفاده کنید.

برای ویرایش پیکربندی پراکسی به‌صورت محلی بااستفاده از واسط کاربر:

1. پیکربندی پراکسی کنونی را در «واسط کاربر Edge» بارگیری کنید. (در نمای «پراکسی‌های API»، پروژه > بارگیری بازبینی را انتخاب کنید.)
2. در ماشین محلی‌تان، دایرکتوری جدیدی ایجاد کنید و فایل ZIP بارگیری‌شده را در آن ازهم باز کنید.

   برای ازهم باز کردن فایل ZIP، می‌توانید از ابزاری مثل unzip استفاده کنید، همان‌طور که مثال زیر نشان می‌دهد:

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

   محتوای ازهم بازشده فایل ZIP باید مشابه ساختار توضیح‌داده‌شده در ساختار پراکسی API باشد.

3. فایل‌های منبع را درصورت نیاز ویرایش کنید. برای شرح فایل‌های منبع در پیکربندی پراکسی، به فایل‌های پیکربندی و ساختار دایرکتوری پراکسی API مراجعه کنید.

   برای مثال، برای فعال کردن پایش سلامتی در پراکسی API، فایل پیکربندی 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» بارگذاری کنید. (در نمای پراکسی‌های API ، پروژه > بارگذاری بازبینی جدید را انتخاب کنید.)

   اگر خطایی مثل Bundle is invalid. Empty bundle. دریافت کردید، مطمئن شوید دایرکتوری سطح بالای فایل ZIP شما /apiproxy باشد. اگر این‌طور نیست، فایل‌های پیکربندی پراکسی را از ریشه دایرکتوری ازهم بازشده دوباره بایگانی کنید.

   پس‌از بارگذاری پیکربندی پراکسی جدید، Edge شماره بازبینی را افزایش می‌دهد و آن را در نمای خلاصه بازبینی نمایش می‌دهد.

   ‫Edge پس‌از بارگذاری نسخه جدید با «واسط کاربر»، آن را برایتان مستقر نمی‌کند.

8. نسخه جدیدتان را پیاده کنید.

برای اطلاعات بیشتر، آموزش گام‌به‌گام: نحوه بارگیری پراکسی بااستفاده از رابط کاربری و API مدیریت در انجمن Apigee را ببینید.

ساختار پراکسی میانای برنامه‌سازی کاربردی

پراکسی API از پیکرببندی زیر تشکیل شده است:

ساختار فهرست راهنمای پراکسی API و محتوا

عناصر جدول بالا براساس فایل‌های پیکربندی در ساختار دایرکتوری زیر تعریف می‌شوند:

فایل‌های پیکربندی و ساختار دایرکتوری یک پراکسی API

این بخش فایل‌های پیکربندی و ساختار دایرکتوری یک پراکسی API را توضیح می‌دهد.

• پیکربندی پایه
• ProxyEndpoint
• TargetEndpoint
  • پیکربندی «نقطه پایانی هدف» TLS/SSL
• خط‌مشی‌ها
• جریان‌ها
• منابع

پیکربندی پایه

/apiproxy/weatherapi.xml

پیکربندی پایه برای پراکسی API که نام پراکسی API را تعریف می‌کند. نام باید در سازمان منحصربه‌فرد باشد.

پیکربندی نمونه:

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

عناصر پیکربندی پایه

ProxyEndpoint

تصویر زیر جریان درخواست/پاسخ را نشان می‌دهد:

/apiproxy/proxies/default.xml

پیکربندی ProxyEndpoint رابط ورودی (مشتری‌محور) را برای یک میانای برنامه‌سازی کاربردی پراکسی تعریف می‌کند. وقتی ProxyEndpoint را پیکربندی می‌کنید، پیکربندی شبکه‌ای راه‌اندازی می‌کنید که نحوه فراخوانی API واسطه‌شده توسط برنامه‌های مشتری («برنامه‌ها») را تعریف می‌کند.

پیکربندی نمونه زیر از 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 به آن ارسال می‌کند.

برای مثال، «قانون مسیر» زیر به پیکربندی /apiproxy/targets/myTarget.xml اشاره می‌کند:

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

فراخوانی مستقیم نشانی وب

‫ProxyEndpoint می‌تواند مستقیماً سرویس زیرینه را فراخوانی کند. فراخوانی مستقیم نشانی وب از هرگونه پیکربندی TargetEndpoints نام‌گذاری‌شده در /apiproxy/targets) عبور می‌کند. به همین دلیل، TargetEndpoint پیکربندی اختیاری میانای برنامه‌سازی کاربردی پراکسی است، هرچند در عمل، فراخوانی مستقیم از ProxyEndpoint توصیه نمی‌شود.

برای مثال، RouteRule زیر با http://api.mycompany.com/v2 تماس HTTP برقرار می‌کند.

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

مسیرهای شرطی

‫RouteRules (قوانین مسیر) را می‌توان به‌هم زنجیر کرد تا از مسیریابی پویا در زمان اجرا پشتیبانی کند. درخواست‌های ورودی می‌توانند براساس سرایندهای HTTP، محتوای پیام، پارامترهای پُرسمان، یا اطلاعات زمینه‌ای مثل زمان روز، منطقه، و غیره به پیکربندی‌های TargetEndpoint نام‌گذاری‌شده، مستقیماً به نشانی‌های وب، یا ترکیبی از این دو هدایت شوند.

‫Conditional 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>

مسیرهای Null

«قانون مسیر» تهی می‌تواند برای پشتیبانی از سناریوهایی تعریف شود که در آن‌ها پیام درخواست نیازی به بازارسال به «نقطه پایانی هدف» ندارد. این کار زمانی مفید است که ProxyEndpoint همه پردازش‌های لازم را انجام دهد، برای مثال بااستفاده از JavaScript برای فراخوانی سرویس خارجی یا بازیابی داده‌ها از جستجو در فروشگاه کلید/مقدار «سرویس‌های API».

برای مثال، مورد زیر «مسیر» تهی را تعریف می‌کند:

<RouteRule name="GoNowhere"/>

«مسیرهای» تهی شرطی می‌تواند مفید باشد. در مثال زیر، «مسیر» تهی پیکربندی شده است تا وقتی سرصفحه HTTP request.header.X-DoNothing مقداری غیر از null داشته باشد اجرا شود.

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

به‌خاطر داشته باشید که RouteRules می‌تواند زنجیره‌ای باشد، بنابراین یک Route تهی شرطی معمولاً یکی از اجزای مجموعه‌ای از RouteRules است که برای پشتیبانی از مسیریابی شرطی طراحی شده است.

استفاده عملی از «مسیر» تهی شرطی در پشتیبانی از حافظه نهان است. بااستفاده از مقدار متغیری که توسط خط‌مشی «حافظه نهان» تنظیم شده است، می‌توانید یک پراکسی API را پیکربندی کنید تا وقتی ورودی از حافظه نهان ارائه می‌شود، «مسیر» تهی را اجرا کند.

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

TargetEndpoint

‫TargetEndpoint معادل برون‌سپاری ProxyEndpoint است. ‫TargetEndpoint به‌عنوان کارخواه سرویس زیرینه یا API عمل می‌کند -- درخواست‌ها را ارسال می‌کند و پاسخ‌ها را دریافت می‌کند.

پراکسی API نیازی به داشتن هیچ TargetEndpoints ندارد. ‫ProxyEndpoints را می‌توان پیکربندی کرد تا مستقیماً نشانی‌های وب را فراخوانی کند. پراکسی API بدون 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 عناصر

‫TargetEndpoint می‌تواند هدف را به یکی از روش‌های زیر فراخوانی کند:

• ‫HTTPTargetConnection برای تماس‌های HTTP(S)‎
• ‫LocalTargetConnection برای زنجیره‌سازی کارگزار محلی به کارگزار محلی
• ‫ScriptTarget برای تماس با دستورگان Node.js میزبانی‌شده در Edge

فقط یکی از این موارد را در TargetEndpoint پیکربندی کنید.

پیکربندی «امنیت لایه انتقال»/SSL برای TargetEndpoint

‫TargetEndpoints اغلب باید اتصالات HTTPS را با زیرساخت ناهمگن پشتیبان مدیریت کند. به همین دلیل، تعدادی از تنظیمات پیکربندی TLS/SSL پشتیبانی می‌شوند.

TLS/SSL عناصر پیکربندی TargetEndpoint

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

برای دستورالعمل‌های دقیق، پیکربندی کردن «امنیت لایه انتقال» از Edge تا زیرینه (Cloud و Private Cloud) را ببینید.

استفاده از متغیرهای جریان برای تنظیم پویای مقادیر TLS/SSL

همچنین می‌توانید جزئیات TLS/SSL را به‌صورت پویا تنظیم کنید تا از الزامات زمان اجرای انعطاف‌پذیر پشتیبانی کنید. برای مثال، اگر پراکسی شما به دو هدف بالقوه متفاوت (هدف آزمایشی و هدف تولید) متصل می‌شود، می‌توانید پراکسی API خود را به‌صورت برنامه‌ریزی‌شده طوری تنظیم کنید که محیطی را که درحال فراخوانی است تشخیص دهد و مراجع را به‌صورت پویا به انبار کلید و انبار اطمینان مناسب تنظیم کند. مقاله زیر از «انجمن Apigee» این سناریو را با جزئیات بیشتری توضیح می‌دهد و نمونه‌های پراکسی API قابل‌پیاده‌سازی ارائه می‌دهد: ‫SSLInfo پویا برای TargetEndpoint بااستفاده از مرجع متغیر.

در مثال زیر از نحوه تنظیم برچسب <SSLInfo> در پیکربندی TargetEndpoint، مقادیر را می‌توان در زمان اجرا، برای مثال، با Java Callout، خط‌مشی 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>

استفاده از ارجاع‌ها برای تنظیم پویای مقادیر «امنیت لایه انتقال»/ پوسته ایمن

هنگام پیکربندی TargetEndpoint که از HTTPS استفاده می‌کند، باید درنظر بگیرید که وقتی گواهی TLS/SSL منقضی می‌شود یا تغییر در پیکربندی سیستم شما را ملزم به به‌روزرسانی گواهی می‌کند، چه اتفاقی می‌افتد. در نصب Edge for Private Cloud، هنگام پیکربندی TLS/SSL بااستفاده از مقادیر ثابت یا بااستفاده از متغیرهای جریان، احتمالاً باید «پردازشگرهای پیام» را بازراه‌اندازی کنید.

برای اطلاعات بیشتر، به‌روزرسانی گواهینامه «امنیت لایه انتقال» را ببینید.

بااین‌حال، می‌توانید «نقطه پایانی هدف» را به‌صورت اختیاری پیکربندی کنید تا به‌جای آن از مرجع به انبار کلید یا انبار اعتماد استفاده کند. مزیت استفاده از مرجع این است که می‌توانید مرجع را به‌روز کنید تا به انبار کلید یا انبار اعتماد دیگری اشاره کند و گواهینامه TLS/SSL را بدون نیاز به راه‌اندازی مجدد «پردازشگرهای پیام» به‌روز کنید.

برای مثال، در زیر TargetEndpoint نشان داده شده است که از مرجع انبار کلید استفاده می‌کند:

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

برای ایجاد مرجع با نام keystoreref، از فراخوانی POST API زیر استفاده کنید:

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 در یک پراکسی API شامل همه خط‌مشی‌های دردسترس برای پیوستن به «جریان‌ها» در پراکسی API است.

عناصر پیکربندی خط‌مشی

پیوست خط‌مشی

تصویر زیر توالی اجرای جاری‌سازی پراکسی API را نشان می‌دهد:

همان‌طور که در بالا نشان داده شده است:

خط‌مشی‌ها به‌عنوان مراحل پردازش به جریان‌ها پیوست می‌شوند. نام خط‌مشی برای ارجاع دادن به خط‌مشی‌ای که باید به‌عنوان «مرحله» پردازش اجرا شود استفاده می‌شود. قالب پیوست خط‌مشی به‌صورت زیر است:

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

خط‌مشی‌ها به ترتیبی که به یک «جریان» پیوست شده‌اند اجرا می‌شوند. برای مثال:

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

پیکربندی پیوست خط‌مشی عناصر

جریان‌های کار

‫ProxyEndpoint و TargetEndpoint خط لوله‌ای را برای پردازش پیام درخواست و پاسخ تعریف می‌کنند. خط لوله پردازش از جریان درخواست و جریان پاسخ تشکیل شده است. هر جریان درخواست و جریان پاسخ به PreFlow، یک یا چند جریان اختیاری «شرطی» یا «نام‌گذاری‌شده»، و PostFlow تقسیم می‌شود.

• PreFlow: همیشه اجرا می‌شود. قبل‌از هر «جریان» شرطی اجرا می‌شود.
• PostFlow: همیشه اجرا می‌شود. پس‌از هر «جریان» شرطی اجرا می‌شود.

علاوه‌براین، می‌توانید PostClientFlow را به ProxyEndpoint اضافه کنید که پس‌از برگرداندن پاسخ به برنامه مشتری درخواست‌کننده اجرا می‌شود. فقط خط‌مشی MessageLogging و افزونه Google Stackdriver Logging می‌توانند به این جریان پیوست شوند. ‫PostClientFlow تأخیر کارگزار API را کاهش می‌دهد و اطلاعات را برای گزارش‌گیری دردسترس قرار می‌دهد. این گزارش‌گیری تا زمانی که پاسخ به مشتری برگردانده نشود محاسبه نمی‌شود، مثلاً 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. جریان پیش‌از درخواست پراکسی
2. جریان‌های شرطی درخواست پراکسی (اختیاری)
3. Proxy Request PostFlow
4. جریان پیش‌از درخواست هدف
5. جریان‌های شرطی درخواست هدف (اختیاری)
6. Target Request PostFlow

روند پردازش پاسخ:

1. جریان پیش‌از پاسخ هدف
2. جریان‌های شرطی پاسخ هدف (اختیاری)
3. Target Response PostFlow
4. جریان پیش‌از پاسخ پراکسی
5. جریان‌های شرطی پاسخ پراکسی (اختیاری)
6. Proxy Response PostFlow
7. پاسخ PostClientFlow (اختیاری)

فقط آن دسته از «جریان‌هایی» که پیوست خط‌مشی دارند باید در پیکربندی‌های ProxyEndpoint یا TargetEndpoint پیکربندی شوند. وقتی خط‌مشی‌ای نیاز به اجرا درطول پردازش PreFlow یا PostFlow داشته باشد، PreFlow و PostFlow فقط باید در پیکربندی ProxyEndpoint یا TargetEndpoint مشخص شوند.

برخلاف جاری‌سازی‌های شرطی، ترتیب عناصر «جاری‌سازی پیش‌از اجرا» و «جاری‌سازی پس‌از اجرا» مهم نیست--کارگزار API همیشه هرکدام را در نقطه مناسبی از خط لوله اجرا می‌کند، صرف‌نظر از اینکه در پیکربندی «نقطه پایانی» کجا ظاهر می‌شوند.

جریان‌های شرطی

‫ProxyEndpoints و TargetEndpoints از تعداد نامحدودی از جریان‌های شرطی (که به‌عنوان «جریان‌های نام‌دار» نیز شناخته می‌شوند) پشتیبانی می‌کنند.

کارگزاری API شرایط مشخص‌شده در جریان شرطی را آزمایش می‌کند و اگر شرط برآورده شود، مراحل پردازش در جریان شرطی توسط کارگزاری API اجرا می‌شود. اگر شرط برآورده نشود، مراحل پردازش در جریان شرطی دور زده می‌شوند. جریان‌های شرطی به ترتیبی که در پراکسی API تعریف شده است ارزیابی می‌شوند و اولین جریانی که شرط آن برآورده شود اجرا می‌شود.

با تعریف کردن جاری‌سازی‌های شرطی، این قابلیت را به‌دست می‌آورید که مراحل پردازش را در یک پراکسی API براساس موارد زیر اعمال کنید:

• URI درخواست
• فعل HTTP (دریافت/قرار دادن/پست کردن/حذف کردن)
• مقدار پارامتر پُرسمان، سرایند، و پارامتر فرم
• بسیاری از انواع دیگر شرایط

برای مثال، جاری‌سازی شرطی زیر مشخص می‌کند که فقط زمانی اجرا شود که مسیر منبع درخواست /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>

منابع

«منابع» (فایل‌های منبع برای استفاده در پراکسی‌های API) عبارت‌اند از دستورگان‌ها، کد، و تبدیل‌های XSL که می‌توانند بااستفاده از خط‌مشی‌ها به «جریان‌ها» پیوست شوند. این موارد در بخش «دستورگان» ویرایشگر کارگزار API در واسط کاربر مدیریت نشان داده می‌شود.

برای اطلاع از انواع منبع پشتیبانی‌شده، فایل‌های منبع را ببینید.

منابع را می‌توان در یک پراکسی API، یک محیط، یا یک سازمان ذخیره کرد. در هر مورد، منبع با نام در «خط‌مشی» ارجاع داده می‌شود. «سرویس‌های میانای برنامه‌سازی کاربردی» نام را با حرکت از کارگزار میانای برنامه‌سازی کاربردی به محیط و سپس به سطح سازمان حل‌وفصل می‌کند.

منابع ذخیره‌شده در سطح سازمان می‌توانند توسط «خط‌مشی‌ها» در هر محیطی ارجاع داده شوند. منابع ذخیره‌شده در سطح محیط را می‌توان توسط «خط‌مشی‌ها» در آن محیط ارجاع داد. منبع ذخیره‌شده در سطح پراکسی API فقط می‌تواند توسط «خط‌مشی‌ها» در آن پراکسی API ارجاع داده شود.