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

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

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

আপনি যদি API প্রক্সি কীভাবে তৈরি করতে হয় তা শিখছেন, তাহলে আপনাকে এই বিষয় দিয়ে শুরু করার সাজেশন দেওয়া হয় একটি সাধারণ API প্রক্সি তৈরি করুন।

প্রক্সি কনফিগারেশন এডিট করার সবচেয়ে সাধারণ উপায়গুলি হল:

• Edge UI-এর মধ্যে XML এডিটর ব্যবহার করা
• প্রক্সি কনফিগারেশনের লোকাল ডেভেলপমেন্ট নিবন্ধে যেভাবে বর্ণনা করা হয়েছে সেইভাবে কনফিগারেশন ডাউনলোড করে লোকালি এডিট করুন।

প্রক্সি কনফিগারেশনের লোকাল ডেভেলপমেন্ট

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

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

UI ব্যবহার করে লোকালি প্রক্সি কনফিগারেশন এডিট করতে:

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

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

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

   ZIP ফাইলের এক্সপ্যান্ড করা কন্টেন্ট API প্রক্সি স্ট্রাকচারে বর্ণিত স্ট্রাকচারের মতো হতে হবে।

3. প্রয়োজন অনুযায়ী সোর্স ফাইল এডিট করুন। প্রক্সি কনফিগারেশনে সোর্স ফাইলের বিবরণ পেতে API প্রক্সির কনফিগারেশন ফাইল ও ডিরেক্টরি স্ট্রাকচার দেখুন।

   যেমন, আপনার API প্রক্সিতে স্বাস্থ্য সংক্রান্ত মনিটরিং চালু করতে, /apiproxy/targets/ ডিরেক্টরিতে TargetEndpoint কনফিগারেশন ফাইল এডিট করুন। এই ডিরেক্টরির ডিফল্ট ফাইল হল 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 UI ব্যবহার করে নতুন প্রক্সি কনফিগারেশন আপলোড করুন। (API প্রক্সি ভিউতে, প্রোজেক্ট > নতুন রিভিশন আপলোড করুন বিকল্প বেছে নিন।)

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

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

   আপনি UI-এর মাধ্যমে আপলোড করার পরে Edge আপনার জন্য নতুন রিভিশন ডেপ্লয় করে না।

8. আপনার নতুন রিভিশন ডেপ্লয় করুন।

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

API প্রক্সি স্ট্রাকচার

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

API প্রক্সি ডিরেক্টরি স্ট্রাকচার ও কন্টেন্ট

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

কনফিগারেশন ফাইল ও ডিরেক্টরি API প্রক্সির স্ট্রাকচার

এই বিভাগে API প্রক্সির কনফিগারেশন ফাইল ও ডিরেক্টরি স্ট্রাকচার ব্যাখ্যা করা হয়েছে।

• বেস কনফিগারেশন
• ProxyEndpoint
• TargetEndpoint
  • TLS/SSL TargetEndpoint কনফিগারেশন
• নীতি
• ফ্লো
• রিসোর্স

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

/apiproxy/weatherapi.xml

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

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

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

বেস কনফিগারেশন এলিমেন্ট

ProxyEndpoint

নিচের ছবিতে অনুরোধ/উত্তর সংক্রান্ত ফ্লো দেখানো হয়েছে:

/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-এ প্রয়োজনীয় কনফিগারেশন এলিমেন্ট হল:

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 চেইন করা যেতে পারে। ইনবাউন্ড অনুরোধ নামযুক্ত TargetEndpoint কনফিগারেশনে, সরাসরি URL-এ বা দু'টির কোনও একটিতে রাউট করা যেতে পারে, HTTP হেডার, মেসেজ কন্টেন্ট, কোয়েরি প্যারামিটার বা প্রাসঙ্গিক তথ্যের উপর ভিত্তি করে, যেমন দিনের সময়, লোকেল ইত্যাদি।

কন্ডিশনাল RouteRules, 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>

নাল রুট

যেসব ক্ষেত্রে অনুরোধ মেসেজ TargetEndpoint-এ ফরওয়ার্ড করার প্রয়োজন নেই, সেইসব পরিস্থিতিকে সাপোর্ট করার জন্য একটি নাল RouteRule সংজ্ঞায়িত করা যেতে পারে। প্রক্সি এন্ডপয়েন্ট যখন প্রয়োজনীয় সব প্রসেসিং করে, তখন এটি কাজে লাগে। যেমন, কোনও এক্সটার্নাল পরিষেবা কল করার জন্য JavaScript ব্যবহার করা অথবা API পরিষেবার কী/ভ্যালু স্টোর থেকে লুক-আপের মাধ্যমে ডেটা পাওয়া।

যেমন, নিম্নলিখিতটি একটি নাল রুটকে সংজ্ঞায়িত করে:

<RouteRule name="GoNowhere"/>

শর্তসাপেক্ষ নাল রুট কাজে লাগতে পারে। নিচের উদাহরণে, একটি নাল রুট কনফিগার করা হয়েছে যা তখনই এক্সিকিউট হবে যখন HTTP হেডারে request.header.X-DoNothing null ছাড়া অন্য কোনও ভ্যালু থাকবে।

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

মনে রাখবেন, RouteRules চেইন করা যেতে পারে, তাই কন্ডিশনাল নাল রুট সাধারণত কন্ডিশনাল রাউটিং সাপোর্ট করার জন্য ডিজাইন করা RouteRules-এর একটি সেটের কম্পোনেন্ট হবে।

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

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

TargetEndpoint

ProxyEndpoint-এর আউটবাউন্ড সমতুল্য হল TargetEndpoint. TargetEndpoint একটি ব্যাকএন্ড পরিষেবা বা API-এর ক্লায়েন্ট হিসেবে কাজ করে -- এটি অনুরোধ পাঠায় এবং উত্তর পায়।

API প্রক্সির কোনও TargetEndpoints না থাকলেও চলে। সরাসরি URL-এ কল করার জন্য ProxyEndpoints কনফিগার করা যায়। কোনও TargetEndpoints না থাকা API প্রক্সিতে সাধারণত একটি 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 নিম্নলিখিত যেকোনও একটি উপায়ে টার্গেটকে কল করতে পারে:

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

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

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

আউটবাউন্ড ক্লায়েন্ট যাচাইকরণ চালু করা আছে এমন Sample 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 থেকে ব্যাকএন্ডে (ক্লাউড ও প্রাইভেট ক্লাউড) TLS কনফিগার করা দেখুন।

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

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

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

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

তবে, আপনি চাইলে TargetEndpoint কনফিগার করে, তার পরিবর্তে কীস্টোর বা ট্রাস্টস্টোরের রেফারেন্স ব্যবহার করতে পারেন। রেফারেন্স ব্যবহার করার সুবিধা হল, মেসেজ প্রসেসর রিস্টার্ট না করেই 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

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

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

নীতি

API প্রক্সির /policies ডিরেক্টরিতে API প্রক্সির ফ্লোতে অ্যাটাচ করার জন্য উপলভ্য সব নীতি থাকে।

নীতি কনফিগারেশন এলিমেন্ট

নীতি অ্যাটাচমেন্ট

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

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

ফ্লো-এর প্রসেসিং ধাপ হিসেবে নীতি অ্যাটাচ করা হয়। প্রসেসিং ধাপ হিসেবে এনফোর্স করা হবে এমন নীতিকে রেফার করতে নীতির নাম ব্যবহার করা হয়। নীতি অ্যাটাচমেন্টের ফর্ম্যাট হল নিম্নলিখিত:

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

কোনও Flow-তে নীতিগুলি যেভাবে অ্যাটাচ করা হয় সেই ক্রম অনুযায়ী সেগুলি প্রয়োগ করা হয়। যেমন:

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

নীতি অ্যাটাচমেন্ট কনফিগারেশন এলিমেন্ট

ফ্লো

ProxyEndpoint এবং TargetEndpoint, অনুরোধ ও উত্তর মেসেজ প্রসেস করার জন্য একটি পাইপলাইন নির্ধারণ করে। প্রসেসিং পাইপলাইনে একটি অনুরোধ ফ্লো ও একটি উত্তর ফ্লো থাকে। প্রতিটি অনুরোধ ফ্লো ও উত্তর ফ্লোকে প্রিফ্লো, এক বা একাধিক ঐচ্ছিক 'কন্ডিশনাল' বা 'নামযুক্ত' ফ্লো এবং পোস্টফ্লোতে ভাগ করা হয়।

• প্রিফ্লো: সবসময় এক্সিকিউট করে। কোনও কন্ডিশনাল ফ্লোয়ের আগে এক্সিকিউট হয়।
• PostFlow: সবসময় এক্সিকিউট হয়। কোনও কন্ডিশনাল ফ্লোয়ের পরে এক্সিকিউট হয়।

এছাড়াও, আপনি ProxyEndpoint-এ একটি PostClientFlow যোগ করতে পারেন, যা অনুরোধকারী ক্লায়েন্ট অ্যাপে উত্তর রিটার্ন করার পরে এক্সিকিউট হয়। শুধুমাত্র 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. প্রক্সি অনুরোধ পোস্টফ্লো
4. টার্গেট অনুরোধ প্রিফ্লো
5. টার্গেট অনুরোধের কন্ডিশনাল ফ্লো (ঐচ্ছিক)
6. টার্গেট রিকোয়েস্ট পোস্টফ্লো

উত্তর দেওয়ার পাইপলাইন:

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

শুধুমাত্র নীতি অ্যাটাচমেন্ট সহ ফ্লোগুলিই ProxyEndpoint বা TargetEndpoint কনফিগারেশনে কনফিগার করতে হবে। PreFlow এবং PostFlow শুধুমাত্র ProxyEndpoint বা TargetEndpoint কনফিগারেশনে নির্দিষ্ট করতে হবে যখন PreFlow বা PostFlow প্রসেসিং চলাকালীন কোনও নীতি প্রয়োগ করার প্রয়োজন হয়।

কন্ডিশনাল ফ্লোয়ের বিপরীতে, প্রিফ্লো ও পোস্টফ্লো এলিমেন্টের ক্রম গুরুত্বপূর্ণ নয়--API প্রক্সি সবসময় পাইপলাইনের উপযুক্ত পয়েন্টে প্রতিটি এলিমেন্ট এক্সিকিউট করবে, এন্ডপয়েন্ট কনফিগারেশনে সেগুলি যেখানেই থাকুক না কেন।

কন্ডিশনাল ফ্লো

ProxyEndpoints এবং TargetEndpoints-এ সীমাহীন সংখ্যক কন্ডিশনাল ফ্লো (এছাড়াও, এগুলিকে 'নামযুক্ত ফ্লো' বলা হয়) কাজ করে।

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

কন্ডিশনাল ফ্লো নির্ধারণ করার মাধ্যমে, আপনি API প্রক্সিতে প্রসেসিং ধাপ প্রয়োগ করার ক্ষমতা পান, যা এইসব বিষয়ের উপর ভিত্তি করে করা হয়:

• অনুরোধ করা 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 ট্রান্সফর্মেশন যেগুলি নীতি ব্যবহার করে ফ্লোতে অ্যাটাচ করা যেতে পারে। ম্যানেজমেন্ট UI-তে API প্রক্সি এডিটরের "স্ক্রিপ্ট" বিভাগে এগুলি দেখা যায়।

কোন কোন রিসোর্স কাজ করে তা জানতে রিসোর্স ফাইল দেখুন।

API প্রক্সি, এনভায়রনমেন্ট বা প্রতিষ্ঠানে রিসোর্স সেভ করা যেতে পারে। প্রতিটি ক্ষেত্রেই, কোনও নীতিতে রিসোর্সকে নাম দিয়ে রেফার করা হয়। API পরিষেবা, API প্রক্সি থেকে এনভায়রনমেন্ট, তারপর অর্গানাইজেশন লেভেলে গিয়ে নাম সংক্রান্ত সমস্যার সমাধান করে।

সংস্থা লেভেলে স্টোর করা কোনও রিসোর্স যেকোনও এনভায়রনমেন্টে নীতি দ্বারা রেফারেন্স করা যেতে পারে। এনভায়রনমেন্ট লেভেলে সেভ করা কোনও রিসোর্স সেই এনভায়রনমেন্টের নীতি দ্বারা রেফারেন্স করা যেতে পারে। API প্রক্সি লেভেলে স্টোর করা রিসোর্স শুধুমাত্র সেই API প্রক্সির নীতি দ্বারা রেফার করা যেতে পারে।