API প্রক্সি কনফিগারেশন রেফারেন্স

আপনি Apigee Edge ডকুমেন্টেশন দেখছেন।
Apigee X ডকুমেন্টেশনে যান । তথ্য

Apigee Edge-এর সাথে কাজ করা একজন ডেভেলপার হিসেবে, আপনার প্রাথমিক ডেভেলপমেন্ট কার্যক্রমের মধ্যে রয়েছে API প্রক্সি কনফিগার করা যা API বা ব্যাকএন্ড পরিষেবার জন্য প্রক্সি হিসেবে কাজ করে। এই ডকুমেন্টটি API প্রক্সি তৈরি করার সময় আপনার কাছে উপলব্ধ সমস্ত কনফিগারেশন উপাদানের একটি রেফারেন্স।

যদি আপনি API প্রক্সি তৈরি করতে শিখছেন, তাহলে "একটি সহজ API প্রক্সি তৈরি করুন" বিষয় দিয়ে শুরু করার পরামর্শ দেওয়া হচ্ছে।

প্রক্সি কনফিগারেশন সম্পাদনা করার সবচেয়ে সাধারণ উপায় হল:

• এজ UI এর মধ্যে XML এডিটর ব্যবহার করা
• প্রক্সি কনফিগারেশনের স্থানীয় বিকাশে বর্ণিত কনফিগারেশনটি ডাউনলোড করুন এবং স্থানীয়ভাবে সম্পাদনা করুন।

প্রক্সি কনফিগারেশনের স্থানীয় উন্নয়ন

আপনি আপনার প্রক্সি কনফিগারেশনগুলি ডাউনলোড করতে পারেন যাতে আপনি সেগুলি স্থানীয় মেশিনে সম্পাদনা করতে পারেন। আপনার কাজ শেষ হয়ে গেলে, আপনি ফলাফলগুলি Edge-এ আপলোড করবেন। এই পদ্ধতিটি আপনাকে আপনার সোর্স নিয়ন্ত্রণ, সংস্করণ এবং অন্যান্য ভাগ করা কর্মপ্রবাহের সাথে প্রক্সি কনফিগারেশনগুলিকে একীভূত করতে দেয়। এছাড়াও, স্থানীয়ভাবে একটি প্রক্সি কনফিগারেশনে কাজ করে, আপনি আপনার নিজস্ব XML সম্পাদক এবং যাচাইকরণ সরঞ্জামগুলি ব্যবহার করতে পারেন।

এই বিভাগে বর্ণনা করা হয়েছে কিভাবে UI ব্যবহার করে একটি বিদ্যমান প্রক্সি কনফিগারেশন ডাউনলোড করতে হয়, এটি সম্পাদনা করতে হয় এবং তারপর স্থাপনের জন্য এটি Edge-এ আপলোড করতে হয়। আপনি apigeetool ব্যবহার করে একটি নতুন প্রক্সি কনফিগারেশন ডাউনলোড এবং স্থাপন করতে পারেন (যথাক্রমে fetchproxy এবং deployproxy কমান্ড ব্যবহার করে)।

UI ব্যবহার করে স্থানীয়ভাবে একটি প্রক্সি কনফিগারেশন সম্পাদনা করতে:

1. Edge UI-তে বর্তমান প্রক্সি কনফিগারেশনটি ডাউনলোড করুন। (API প্রক্সি ভিউতে, Project > Download Revision নির্বাচন করুন।)
2. আপনার স্থানীয় মেশিনে, একটি নতুন ডিরেক্টরি তৈরি করুন এবং ডাউনলোড করা জিপ ফাইলটি এতে প্রসারিত করুন।

   ZIP ফাইলটি প্রসারিত করতে, আপনি unzip এর মতো একটি ইউটিলিটি ব্যবহার করতে পারেন, যেমনটি নিম্নলিখিত উদাহরণে দেখানো হয়েছে:

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

   জিপ ফাইলের বর্ধিত বিষয়বস্তু API প্রক্সি কাঠামোতে বর্ণিত কাঠামোর অনুরূপ হওয়া উচিত।

3. প্রয়োজনে সোর্স ফাইলগুলি সম্পাদনা করুন। প্রক্সি কনফিগারেশনে সোর্স ফাইলগুলির বিবরণের জন্য, API প্রক্সির কনফিগারেশন ফাইল এবং ডিরেক্টরি কাঠামো দেখুন।

   উদাহরণস্বরূপ, আপনার API প্রক্সিতে স্বাস্থ্য পর্যবেক্ষণ সক্ষম করতে, /apiproxy/targets/ ডিরেক্টরিতে TargetEndpoint কনফিগারেশন ফাইলটি সম্পাদনা করুন। এই ডিরেক্টরিতে ডিফল্ট ফাইলটি হল default.xml , যদিও আপনি যদি শর্তসাপেক্ষ targets ব্যবহার করেন তবে বিভিন্ন নামের ফাইল থাকতে পারে।

   এই ক্ষেত্রে, যদি TargetEndpoint কনফিগারেশন ফাইল এবং এর ডিরেক্টরি বিদ্যমান না থাকে, তাহলে সেগুলি তৈরি করুন।

4. প্রক্সি কনফিগারেশন ফাইল সম্পাদনা শেষ করার পরে, আপনার পরিবর্তনগুলি সংরক্ষণ করতে ভুলবেন না।
5. জিপ ফাইলগুলি (প্রসারিত কনফিগারেশন ফাইলগুলির মূল) প্রসারিত করার সময় আপনি যে নতুন ডিরেক্টরিটি তৈরি করেছিলেন তাতে পরিবর্তন করুন।

   উদাহরণস্বরূপ, যদি আপনি ফাইলগুলি /myappdir ডিরেক্টরিতে প্রসারিত করে থাকেন, তাহলে নিচের উদাহরণে দেখানো হিসাবে সেই ডিরেক্টরিতে পরিবর্তন করুন:

   cd myappdir

   আপনার প্রক্সি কনফিগারেশন ফাইলগুলি পুনরায় আর্কাইভ করার আগে আপনার এই ডিরেক্টরিতে পরিবর্তন করা উচিত কারণ আপনি /myappdir ডিরেক্টরিটি ZIP ফাইলে অন্তর্ভুক্ত করতে চান না। ZIP ফাইলের শীর্ষ-স্তরের ডিরেক্টরিটি /apiproxy হতে হবে।

6. নতুন বা পরিবর্তিত ফাইল সহ প্রক্সি কনফিগারেশন ফাইলগুলি পুনরায় আর্কাইভ করুন। আপনি zip এর মতো একটি ইউটিলিটি ব্যবহার করতে পারেন, যেমনটি নিম্নলিখিত উদাহরণে দেখানো হয়েছে:

   zip my-new-proxy.zip -r .

   জিপ ফাইলের শীর্ষ-স্তরের ডিরেক্টরিটি /apiproxy হতে হবে।

   জিপ ফাইলের নামের জন্য কোনও বিশেষ প্রয়োজনীয়তা নেই। উদাহরণস্বরূপ, আপনাকে সংশোধন নম্বর বাড়ানোর বা ফাইলের নামে তারিখ নির্দিষ্ট করার প্রয়োজন নেই, তবে এটি করা ডিবাগিং বা উৎস নিয়ন্ত্রণের জন্য কার্যকর হতে পারে।

   নতুন প্রক্সি কনফিগারেশন আপলোড করার সময় এজ আপনার জন্য এর সংশোধন সংখ্যা বৃদ্ধি করে।

7. Edge UI ব্যবহার করে নতুন প্রক্সি কনফিগারেশন আপলোড করুন। ( API Proxies ভিউতে, Project > Upload a New Revision নির্বাচন করুন।)

   যদি আপনি Bundle is invalid. Empty bundle. এর মতো একটি ত্রুটি পান, তাহলে নিশ্চিত করুন যে আপনার ZIP ফাইলের শীর্ষ-স্তরের ডিরেক্টরি /apiproxy । যদি তা না হয়, তাহলে প্রসারিত ডিরেক্টরির রুট থেকে আপনার প্রক্সি কনফিগারেশন ফাইলগুলি পুনরায় সংরক্ষণাগারভুক্ত করুন।

   আপনার নতুন প্রক্সি কনফিগারেশন আপলোড করার পরে, এজ রিভিশন নম্বরটি বাড়িয়ে রিভিশন সারাংশ ভিউতে প্রদর্শন করে।

   UI দিয়ে আপলোড করার পর, Edge আপনার জন্য নতুন সংস্করণটি স্থাপন করে না।

8. আপনার নতুন সংস্করণটি স্থাপন করুন।

আরও তথ্যের জন্য টিউটোরিয়ালটি দেখুন: Apigee কমিউনিটিতে UI এবং ব্যবস্থাপনা API ব্যবহার করে কীভাবে একটি প্রক্সি ডাউনলোড করবেন ।

API প্রক্সি কাঠামো

একটি API প্রক্সিতে নিম্নলিখিত কনফিগারেশন থাকে:

API প্রক্সি ডিরেক্টরি গঠন এবং বিষয়বস্তু

উপরের টেবিলের উপাদানগুলি নিম্নলিখিত ডিরেক্টরি কাঠামোর কনফিগারেশন ফাইল দ্বারা সংজ্ঞায়িত করা হয়েছে:

একটি API প্রক্সির কনফিগারেশন ফাইল এবং ডিরেক্টরি কাঠামো

এই বিভাগটি একটি API প্রক্সির কনফিগারেশন ফাইল এবং ডিরেক্টরি কাঠামো ব্যাখ্যা করে।

• বেস কনফিগারেশন
• প্রক্সিএন্ডপয়েন্ট
• টার্গেটএন্ডপয়েন্ট
  • TLS/SSL টার্গেটএন্ডপয়েন্ট কনফিগারেশন
• নীতিমালা
• প্রবাহিত হয়
• রিসোর্স

বেস কনফিগারেশন

/apiproxy/weatherapi.xml

একটি API প্রক্সির বেস কনফিগারেশন, যা API প্রক্সির নাম নির্ধারণ করে। নামটি অবশ্যই একটি প্রতিষ্ঠানের মধ্যে অনন্য হতে হবে।

নমুনা কনফিগারেশন:

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

বেস কনফিগারেশন উপাদান

প্রক্সিএন্ডপয়েন্ট

নিচের ছবিটি অনুরোধ/প্রতিক্রিয়া প্রবাহ দেখায়:

/apiproxy/proxies/default.xml

ProxyEndpoint কনফিগারেশন একটি API প্রক্সির জন্য ইনবাউন্ড (ক্লায়েন্ট-ফেসিং) ইন্টারফেস সংজ্ঞায়িত করে। যখন আপনি একটি 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-এ প্রয়োজনীয় কনফিগারেশন উপাদানগুলি হল:

প্রক্সিএন্ডপয়েন্ট কনফিগারেশন এলিমেন্ট

কিভাবে RouteRules কনফিগার করবেন

একটি নামযুক্ত TargetEndpoint বলতে /apiproxy/targets এর অধীনে একটি কনফিগারেশন ফাইল বোঝায় যেখানে ProxyEndpoint দ্বারা প্রক্রিয়াকরণের পরে RouteRule একটি অনুরোধ ফরোয়ার্ড করে।

উদাহরণস্বরূপ, নিম্নলিখিত RouteRule কনফিগারেশন /apiproxy/targets/myTarget.xml কে বোঝায়:

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

সরাসরি URL আমন্ত্রণ

একটি ProxyEndpoint সরাসরি একটি ব্যাকএন্ড পরিষেবাও চালু করতে পারে। ডাইরেক্ট URL ইনভোকেশন /apiproxy/targets এর অধীনে যেকোনো নামক TargetEndpoints কনফিগারেশনকে বাইপাস করে। এই কারণে, TargetEndpoint একটি ঐচ্ছিক API প্রক্সি কনফিগারেশন, যদিও বাস্তবে, ProxyEndpoint থেকে সরাসরি ইনভোকেশন সুপারিশ করা হয় না।

উদাহরণস্বরূপ, নিম্নলিখিত RouteRule http://api.mycompany.com/v2 এ একটি HTTP কল করে।

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

শর্তসাপেক্ষ রুট

রানটাইমে গতিশীল রাউটিং সমর্থন করার জন্য RouteRules-কে শৃঙ্খলিত করা যেতে পারে। HTTP হেডার, বার্তার বিষয়বস্তু, কোয়েরি প্যারামিটার, অথবা দিনের সময়, লোকেল ইত্যাদির উপর ভিত্তি করে ইনবাউন্ড অনুরোধগুলিকে নামযুক্ত TargetEndpoint কনফিগারেশনে, সরাসরি URL-এ, অথবা দুটির সংমিশ্রণে রাউট করা যেতে পারে।

কন্ডিশনাল রুটরুলস Apigee Edge-এ অন্যান্য কন্ডিশনাল স্টেটমেন্টের মতো কাজ করে। কন্ডিশন রেফারেন্স এবং ভেরিয়েবল রেফারেন্স দেখুন।

উদাহরণস্বরূপ, নিম্নলিখিত RouteRule সংমিশ্রণটি প্রথমে একটি HTTP হেডারের মান যাচাই করার জন্য ইনবাউন্ড অনুরোধ মূল্যায়ন করে। যদি HTTP হেডার routeTo এর মান TargetEndpoint1 থাকে, তাহলে অনুরোধটি TargetEndpoint1 নামক TargetEndpoint-এ ফরোয়ার্ড করা হয়। যদি না থাকে, তাহলে ইনবাউন্ড অনুরোধটি 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 সমস্ত প্রয়োজনীয় প্রক্রিয়াকরণ সম্পাদন করে, উদাহরণস্বরূপ জাভাস্ক্রিপ্ট ব্যবহার করে একটি বহিরাগত পরিষেবা কল করা বা 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 হল একটি ProxyEndpoint এর আউটবাউন্ড সমতুল্য। একটি TargetEndpoint একটি ব্যাকএন্ড পরিষেবা বা API এর ক্লায়েন্ট হিসাবে কাজ করে -- এটি অনুরোধ পাঠায় এবং প্রতিক্রিয়া গ্রহণ করে।

একটি API প্রক্সিতে কোনও TargetEndpoints থাকা প্রয়োজন হয় না। ProxyEndpoints সরাসরি URL গুলিতে কল করার জন্য কনফিগার করা যেতে পারে। TargetEndpoints ছাড়া একটি API প্রক্সিতে সাধারণত একটি ProxyEndpoint থাকে যা হয় সরাসরি একটি ব্যাকএন্ড পরিষেবা কল করে, অথবা যা জাভা বা জাভাস্ক্রিপ্ট ব্যবহার করে কোনও পরিষেবা কল করার জন্য কনফিগার করা থাকে।

টার্গেটএন্ডপয়েন্ট কনফিগারেশন

/targets/default.xml

টার্গেটএন্ডপয়েন্ট অ্যাপিগি এজ থেকে অন্য কোনও পরিষেবা বা রিসোর্সের সাথে আউটবাউন্ড সংযোগ সংজ্ঞায়িত করে।

এখানে একটি নমুনা TargetEndpoint কনফিগারেশন দেওয়া হল:

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

টার্গেটএন্ডপয়েন্ট কনফিগারেশন এলিমেন্ট

একটি TargetEndpoint নিম্নলিখিত উপায়ে একটি টার্গেটকে কল করতে পারে:

• HTTP(S) কলের জন্য HTTPTargetConnection
• স্থানীয় প্রক্সি-থেকে-প্রক্সি চেইনিংয়ের জন্য LocalTargetConnection
• Edge-হোস্টেড Node.js স্ক্রিপ্টে কল করার জন্য ScriptTarget

একটি TargetEndpoint-এ এর মধ্যে শুধুমাত্র একটি কনফিগার করুন।

TLS/SSL টার্গেটএন্ডপয়েন্ট কনফিগারেশন

TargetEndpoints-কে প্রায়শই ভিন্নধর্মী ব্যাকএন্ড পরিকাঠামোর সাথে 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 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 থেকে ব্যাকএন্ডে TLS কনফিগার করা (ক্লাউড এবং প্রাইভেট ক্লাউড) দেখুন।

TLS/SSL মানগুলিকে গতিশীলভাবে সেট করতে ফ্লো ভেরিয়েবল ব্যবহার করা

নমনীয় রানটাইম প্রয়োজনীয়তা সমর্থন করার জন্য আপনি TLS/SSL বিবরণও গতিশীলভাবে সেট করতে পারেন। উদাহরণস্বরূপ, যদি আপনার প্রক্সি দুটি সম্ভাব্য ভিন্ন লক্ষ্যের সাথে সংযুক্ত থাকে (একটি পরীক্ষামূলক লক্ষ্য এবং একটি উৎপাদন লক্ষ্য), তাহলে আপনি আপনার API প্রক্সি প্রোগ্রাম্যাটিকভাবে সনাক্ত করতে পারেন যে এটি কোন পরিবেশকে কল করছে এবং গতিশীলভাবে উপযুক্ত keystore এবং truststore-এ রেফারেন্স সেট করতে পারেন। নিম্নলিখিত Apigee Community নিবন্ধটি এই পরিস্থিতিটি আরও বিশদে ব্যাখ্যা করে এবং স্থাপনযোগ্য API প্রক্সি উদাহরণ প্রদান করে: পরিবর্তনশীল রেফারেন্স ব্যবহার করে TargetEndpoint-এর জন্য Dynamic SSLInfo ।

একটি TargetEndpoint কনফিগারেশনে <SSLInfo> ট্যাগ কীভাবে সেট করা হবে তার নিম্নলিখিত উদাহরণে, রানটাইমে মানগুলি সরবরাহ করা যেতে পারে, উদাহরণস্বরূপ, একটি 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 মানগুলিকে গতিশীলভাবে সেট করার জন্য রেফারেন্স ব্যবহার করা

HTTPS ব্যবহার করে এমন একটি TargetEndpoint কনফিগার করার সময়, আপনাকে সেই কেসটি বিবেচনা করতে হবে যখন TLS/SSL সার্টিফিকেটের মেয়াদ শেষ হয়ে যায়, অথবা সিস্টেম কনফিগারেশনে কোনও পরিবর্তনের জন্য আপনাকে সার্টিফিকেট আপডেট করতে হয়। Edge for Private Cloud ইনস্টলেশনে, স্ট্যাটিক মান ব্যবহার করে বা ফ্লো ভেরিয়েবল ব্যবহার করে TLS/SSL কনফিগার করার সময়, এমন একটি সম্ভাবনা থাকে যে আপনাকে Message Processors পুনরায় চালু করতে হবে।

আরও জানতে, একটি TLS সার্টিফিকেট আপডেট করুন দেখুন।

তবে, আপনি ঐচ্ছিকভাবে TargetEndpoint কনফিগার করতে পারেন যাতে keystore বা truststore-এর রেফারেন্স ব্যবহার করা যায়। রেফারেন্স ব্যবহারের সুবিধা হল, আপনি Message Processors পুনরায় চালু না করেই TLS/SSL সার্টিফিকেট আপডেট করার জন্য রেফারেন্সটি অন্য কোনও keystore বা truststore-এ নির্দেশ করতে পারেন।

উদাহরণস্বরূপ, নিচে দেখানো হল একটি TargetEndpoint যা keystore-এর একটি রেফারেন্স ব্যবহার করে:

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

keystoref নামের রেফারেন্স তৈরি করতে নিম্নলিখিত 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

টার্গেট লোড ব্যালেন্সিং সহ টার্গেটএন্ডপয়েন্ট

TargetEndpoints তিনটি লোড ব্যালেন্সিং অ্যালগরিদম ব্যবহার করে একাধিক নামযুক্ত TargetServers জুড়ে লোড ব্যালেন্সিং সমর্থন করে।

বিস্তারিত নির্দেশাবলীর জন্য, ব্যাকএন্ড সার্ভার জুড়ে লোড ব্যালেন্সিং দেখুন।

নীতিমালা

একটি API প্রক্সিতে /policies ডিরেক্টরিতে API প্রক্সিতে Flows-এর সাথে সংযুক্ত করার জন্য উপলব্ধ সমস্ত নীতি থাকে।

নীতি কনফিগারেশন উপাদান

নীতি সংযুক্তি

নিচের ছবিতে API প্রক্সি ফ্লো এক্সিকিউশন সিকোয়েন্স দেখানো হয়েছে:

উপরে দেখানো হয়েছে:

পলিসিগুলি প্রক্রিয়াকরণের ধাপ হিসেবে Flows- এর সাথে সংযুক্ত করা হয়। পলিসির নামটি প্রয়োগের ধাপ হিসেবে প্রয়োগ করা নীতির উল্লেখ করতে ব্যবহৃত হয়। পলিসি সংযুক্তির ফর্ম্যাটটি নিম্নরূপ:

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

নীতিগুলি একটি প্রবাহের সাথে যে ক্রমে সংযুক্ত থাকে সেই ক্রমে প্রয়োগ করা হয়। উদাহরণস্বরূপ:

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

নীতি সংযুক্তি কনফিগারেশন উপাদান

প্রবাহিত হয়

ProxyEndpoint এবং TargetEndpoint অনুরোধ এবং প্রতিক্রিয়া বার্তা প্রক্রিয়াকরণের জন্য একটি পাইপলাইন সংজ্ঞায়িত করে। একটি প্রক্রিয়াকরণ পাইপলাইনে একটি অনুরোধ প্রবাহ এবং একটি প্রতিক্রিয়া প্রবাহ থাকে। প্রতিটি অনুরোধ প্রবাহ এবং প্রতিক্রিয়া প্রবাহ একটি PreFlow, এক বা একাধিক ঐচ্ছিক 'শর্তসাপেক্ষ' বা 'নামযুক্ত' প্রবাহ এবং একটি PostFlow-এ বিভক্ত।

• প্রিফ্লো: সর্বদা কার্যকর হয়। যেকোনো শর্তাধীন প্রবাহের আগে কার্যকর হয়।
• পোস্টফ্লো: সর্বদা কার্যকর হয়। যেকোনো শর্তাধীন প্রবাহের পরে কার্যকর হয়।

অতিরিক্তভাবে, আপনি ProxyEndpoint-এ একটি PostClientFlow যোগ করতে পারেন, যা অনুরোধকারী ক্লায়েন্ট অ্যাপে প্রতিক্রিয়া ফেরত পাঠানোর পরে কার্যকর হয়। এই প্রবাহের সাথে শুধুমাত্র MessageLogging নীতি এবং Google Stackdriver লগিং এক্সটেনশন সংযুক্ত করা যেতে পারে। PostClientFlow API প্রক্সি ল্যাটেন্সি কমায় এবং লগিংয়ের জন্য তথ্য উপলব্ধ করে যা ক্লায়েন্টে প্রতিক্রিয়া ফেরত না আসা পর্যন্ত গণনা করা হয় না, যেমন client.sent.start.timestamp এবং client.sent.end.timestamp । প্রবাহটি মূলত প্রতিক্রিয়া বার্তার জন্য শুরু এবং শেষ টাইমস্ট্যাম্পের মধ্যে সময়ের ব্যবধান পরিমাপ করার জন্য ব্যবহৃত হয়।

কীভাবে করবেন তার একটি দ্রুত ভিডিও দেখুন

এখানে একটি পোস্টক্লায়েন্টফ্লোর উদাহরণ দেওয়া হল যেখানে একটি বার্তা লগিং নীতি সংযুক্ত করা আছে।

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

API প্রক্সি প্রক্রিয়াকরণ পাইপলাইন নিম্নলিখিত ক্রমানুসারে প্রবাহ কার্যকর করে:

অনুরোধ পাইপলাইন:

1. প্রক্সি অনুরোধ প্রিফ্লো
2. প্রক্সি অনুরোধ শর্তসাপেক্ষ প্রবাহ (ঐচ্ছিক)
3. প্রক্সি অনুরোধ পোস্টফ্লো
4. টার্গেট রিকোয়েস্ট প্রিফ্লো
5. টার্গেট অনুরোধ শর্তসাপেক্ষ প্রবাহ (ঐচ্ছিক)
6. টার্গেট রিকোয়েস্ট পোস্টফ্লো

প্রতিক্রিয়া পাইপলাইন:

1. টার্গেট রেসপন্স প্রিফ্লো
2. টার্গেট রেসপন্স কন্ডিশনাল ফ্লো (ঐচ্ছিক)
3. টার্গেট রেসপন্স পোস্টফ্লো
4. প্রক্সি রেসপন্স প্রিফ্লো
5. প্রক্সি রেসপন্স কন্ডিশনাল ফ্লো (ঐচ্ছিক)
6. প্রক্সি রেসপন্স পোস্টফ্লো
7. পোস্টক্লায়েন্টফ্লো রেসপন্স (ঐচ্ছিক)

Only those Flows with policy attachments need to be configured in ProxyEndpoint or TargetEndpoint configurations. PreFlow and PostFlow need only be specified in a ProxyEndpoint or TargetEndpoint configuration when a policy needs to be enforced during PreFlow or PostFlow processing.

In contrast to conditional flows, the ordering of PreFlow and PostFlow elements is not important--the API proxy will always execute each at the appropriate point in the pipeline, regardless of where they appear in the Endpoint configuration.

Conditional Flows

ProxyEndpoints and TargetEndpoints support an unlimited number of conditional flows (also known as 'named flows').

The API proxy tests for the condition specified in the conditional flow and, if the condition is met, the processing steps in the conditional flow are executed by the API proxy. If the condition is not met, then the processing steps in the conditional flow are bypassed. Conditional flows are evaluated in the order defined in the API proxy and the first one whose condition is met is executed.

By defining conditional flows, you gain the ability to apply processing steps in an API proxy based on:

• Request URI
• HTTP verb (GET/PUT/POST/DELETE)
• Value of a query param, header, and form param
• Many other types of conditions

For example, the following conditional flow specifies that it is executed only when the request resource path is /accesstoken . Any inbound request with the path /accesstoken causes this flow to be executed, along with any policies that are attached to the flow. If the request path does not include the suffix /accesstoken , then the flow does not execute (although another conditional flow might).

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

Flow Configuration Elements

Step processing

The sequential ordering of conditional Flows is enforced by Apigee Edge. Conditional Flows execute from top to bottom. The first conditional Flow whose condition evaluates to true is executed, and only one conditional Flow is executed.

For example, in the following Flow configuration, any inbound request that does not include the path suffix /first or /second will cause the ThirdFlow to execute, enforcing the policy called 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>

রিসোর্স

"Resources" (resource files for use in API proxies) are scripts, code, and XSL transformations that can be attached to Flows using policies. These appear in the "Scripts" section of the API proxy editor in the management UI.

See Resource files for the supported resource types.

Resources can be stored in an API proxy, an environment, or an organization. In each case, a resource is referenced by name in a Policy. API Services resolves the name by moving from the API proxy, to environment, to organization level.

A resource stored at the organization level can be referenced by Policies in any environment. A resource stored at the environment level can be referenced by Policies in that environment. A resource stored at the API proxy level can be referenced only by Policies in that API proxy.