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

আপনি Apigee Edge-এর ডকুমেন্টেশন দেখছেন।
Apigee X ডকুমেন্টেশন .info- তে যান।

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

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

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

• Edge UI-এর মধ্যে XML এডিটর ব্যবহার করে
• প্রক্সি কনফিগারেশনের স্থানীয় উন্নয়ন (Local development of proxy configurations) অংশে বর্ণিত পদ্ধতি অনুযায়ী কনফিগারেশনটি ডাউনলোড করুন এবং স্থানীয়ভাবে সম্পাদনা করুন।

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

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

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

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

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

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

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

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

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

   উদাহরণস্বরূপ, আপনার এপিআই প্রক্সিতে হেলথ মনিটরিং চালু করতে, /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 Proxies ভিউতে, Project > Upload a New Revision নির্বাচন করুন।)

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

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

   আপনি UI-এর মাধ্যমে আপলোড করার পর Edge আপনার জন্য নতুন সংস্করণটি স্থাপন করে না।

8. আপনার নতুন সংস্করণটি প্রয়োগ করুন।

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

এপিআই প্রক্সি কাঠামো

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

এপিআই প্রক্সি ডিরেক্টরির কাঠামো এবং বিষয়বস্তু

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

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

এই অংশে একটি এপিআই প্রক্সির কনফিগারেশন ফাইল এবং ডিরেক্টরি কাঠামো ব্যাখ্যা করা হয়েছে।

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

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

/apiproxy/weatherapi.xml

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

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

<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-এ Conditional RouteRules অন্যান্য কন্ডিশনাল স্টেটমেন্টের মতোই কাজ করে। Conditions reference এবং Variables reference দেখুন।

উদাহরণস্বরূপ, নিম্নলিখিত 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>

নাল রুট

এমন পরিস্থিতি সমর্থন করার জন্য একটি নাল (null) RouteRule সংজ্ঞায়িত করা যেতে পারে, যেখানে অনুরোধ বার্তাটি TargetEndpoint-এ ফরোয়ার্ড করার প্রয়োজন হয় না। এটি তখন উপযোগী হয় যখন ProxyEndpoint সমস্ত প্রয়োজনীয় প্রক্রিয়াকরণ সম্পাদন করে, উদাহরণস্বরূপ, জাভাস্ক্রিপ্ট ব্যবহার করে কোনো বাহ্যিক পরিষেবা কল করার মাধ্যমে অথবা API Services-এর কী/ভ্যালু স্টোর থেকে ডেটা পুনরুদ্ধার করার মাধ্যমে।

উদাহরণস্বরূপ, নিম্নলিখিতটি একটি নাল রাউট (null Route) সংজ্ঞায়িত করে:

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

টার্গেটএন্ডপয়েন্ট

টার্গেটএন্ডপয়েন্ট হলো প্রক্সিএন্ডপয়েন্টের আউটবাউন্ড সমতুল্য। একটি টার্গেটএন্ডপয়েন্ট কোনো ব্যাকএন্ড পরিষেবা বা এপিআই-এর ক্লায়েন্ট হিসেবে কাজ করে — এটি অনুরোধ পাঠায় এবং প্রতিক্রিয়া গ্রহণ করে।

একটি এপিআই প্রক্সিতে কোনো টার্গেটএন্ডপয়েন্ট থাকার প্রয়োজন নেই। প্রক্সিএন্ডপয়েন্টগুলোকে সরাসরি ইউআরএল কল করার জন্য কনফিগার করা যেতে পারে। টার্গেটএন্ডপয়েন্টবিহীন একটি এপিআই প্রক্সিতে সাধারণত এমন একটি প্রক্সিএন্ডপয়েন্ট থাকে যা হয় সরাসরি কোনো ব্যাকএন্ড সার্ভিসকে কল করে, অথবা জাভা বা জাভাস্ক্রিপ্ট ব্যবহার করে কোনো সার্ভিস কল করার জন্য কনফিগার করা থাকে।

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

/targets/default.xml

টার্গেটএন্ডপয়েন্ট Apigee Edge থেকে অন্য কোনো পরিষেবা বা রিসোর্সে বহির্গামী সংযোগকে সংজ্ঞায়িত করে।

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

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

টার্গেটএন্ডপয়েন্ট কনফিগারেশন উপাদানসমূহ

একটি টার্গেটএন্ডপয়েন্ট নিম্নলিখিত উপায়গুলির মধ্যে যেকোনো একটির মাধ্যমে একটি টার্গেটকে কল করতে পারে:

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

একটি টার্গেটএন্ডপয়েন্টে এগুলোর মধ্যে কেবল একটি কনফিগার করুন।

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 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 বিবরণও সেট করতে পারেন। উদাহরণস্বরূপ, যদি আপনার প্রক্সি দুটি সম্ভাব্য ভিন্ন টার্গেটের (একটি টেস্ট টার্গেট এবং একটি প্রোডাকশন টার্গেট) সাথে সংযোগ স্থাপন করে, তাহলে আপনি আপনার এপিআই প্রক্সিকে প্রোগ্রাম্যাটিকভাবে শনাক্ত করতে দিতে পারেন যে এটি কোন এনভায়রনমেন্টকে কল করছে এবং সেই অনুযায়ী উপযুক্ত কীস্টোর ও ট্রাস্টস্টোরের রেফারেন্স ডাইনামিকভাবে সেট করতে পারেন। নিম্নলিখিত Apigee কমিউনিটি আর্টিকেলটি এই পরিস্থিতিটি আরও বিস্তারিতভাবে ব্যাখ্যা করে এবং স্থাপনযোগ্য এপিআই প্রক্সির উদাহরণ প্রদান করে: Dynamic SSLInfo for TargetEndpoint using variable reference ।

একটি 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 ব্যবহার করে এমন একটি টার্গেটএন্ডপয়েন্ট কনফিগার করার সময়, আপনাকে সেই পরিস্থিতিটি বিবেচনা করতে হবে যখন TLS/SSL সার্টিফিকেটের মেয়াদ শেষ হয়ে যায়, অথবা সিস্টেম কনফিগারেশনে কোনো পরিবর্তনের কারণে সার্টিফিকেটটি আপডেট করার প্রয়োজন হয়। একটি Edge for Private Cloud ইনস্টলেশনে, স্ট্যাটিক ভ্যালু বা ফ্লো ভ্যারিয়েবল ব্যবহার করে TLS/SSL কনফিগার করার সময়, মেসেজ প্রসেসরগুলো রিস্টার্ট করার প্রয়োজন হতে পারে।

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

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

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

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

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

নীতিমালা

একটি এপিআই প্রক্সির /policies ডিরেক্টরিতে সেই সমস্ত পলিসি থাকে যা এপিআই প্রক্সির ফ্লো-গুলির সাথে সংযুক্ত করা যায়।

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

পলিসি সংযুক্তি

নিম্নলিখিত চিত্রটি এপিআই প্রক্সি ফ্লো-এর নির্বাহের ক্রম দেখায়:

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

পলিসিগুলো ফ্লো-এর সাথে প্রসেসিং স্টেপ হিসেবে সংযুক্ত থাকে। প্রসেসিং স্টেপ হিসেবে যে পলিসিটি প্রয়োগ করা হবে, সেটিকে নির্দেশ করার জন্য পলিসিটির নাম ব্যবহার করা হয়। একটি পলিসি সংযুক্তির ফরম্যাটটি নিম্নরূপ:

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

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

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

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

প্রবাহ

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

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

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

একটি দ্রুত নির্দেশনামূলক ভিডিও দেখুন

Here's an example of a PostClientFlow with a message logging policy attached.

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

The API proxy processing pipeline executes Flows in the following sequence:

Request Pipeline:

1. Proxy Request PreFlow
2. Proxy Request Conditional Flows (Optional)
3. Proxy Request PostFlow
4. Target Request PreFlow
5. Target Request Conditional Flows (Optional)
6. Target Request PostFlow

Response Pipeline:

1. Target Response PreFlow
2. Target Response Conditional Flows (Optional)
3. Target Response PostFlow
4. Proxy Response PreFlow
5. Proxy Response Conditional Flows (Optional)
6. Proxy Response PostFlow
7. PostClientFlow Response (Optional)

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.