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

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

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

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

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

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

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

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

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

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

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

   জিপ ফাইলটি প্রসারিত করতে, আপনি একটি ইউটিলিটি ব্যবহার করতে পারেন যেমন 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. আপনি জিপ ফাইলগুলি প্রসারিত করার সময় যে নতুন ডিরেক্টরিটি তৈরি করেছিলেন তা পরিবর্তন করুন (প্রসারিত কনফিগারেশন ফাইলগুলির মূল)।

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

   cd myappdir

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

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

   zip my-new-proxy.zip -r .

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

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

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

7. এজ UI ব্যবহার করে নতুন প্রক্সি কনফিগারেশন আপলোড করুন। ( এপিআই প্রক্সি ভিউতে, প্রজেক্ট > একটি নতুন রিভিশন আপলোড করুন নির্বাচন করুন।)

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

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

   আপনি UI এর সাথে আপলোড করার পরে এজ আপনার জন্য নতুন সংশোধন স্থাপন করে না।

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 কনফিগারেশন /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>

একটি মৌলিক প্রক্সিএন্ডপয়েন্টে প্রয়োজনীয় কনফিগারেশন উপাদানগুলি হল:

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

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

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

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

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

সরাসরি URL আহ্বান

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

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

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

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

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

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

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

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

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

/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 নিম্নলিখিত উপায়ে একটি লক্ষ্য কল করতে পারে:

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

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

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

<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 কনফিগার করা দেখুন (ক্লাউড এবং প্রাইভেট ক্লাউড)।

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

নমনীয় রানটাইম প্রয়োজনীয়তা সমর্থন করার জন্য আপনি গতিশীলভাবে TLS/SSL বিবরণ সেট করতে পারেন। উদাহরণস্বরূপ, যদি আপনার প্রক্সি দুটি সম্ভাব্য ভিন্ন লক্ষ্যগুলির সাথে সংযোগ করে (একটি পরীক্ষার লক্ষ্য এবং একটি উত্পাদন লক্ষ্য), আপনি আপনার API প্রক্সি প্রোগ্রাম্যাটিকভাবে সনাক্ত করতে পারেন যে এটি কোন পরিবেশে কল করছে এবং গতিশীলভাবে উপযুক্ত কীস্টোর এবং ট্রাস্টস্টোরে রেফারেন্স সেট করতে পারে৷ নিম্নলিখিত Apigee সম্প্রদায় নিবন্ধটি এই দৃশ্যটিকে আরও বিস্তারিতভাবে ব্যাখ্যা করে এবং স্থাপনযোগ্য API প্রক্সি উদাহরণ প্রদান করে: https://community.apigee.com/articles/21424/dynamic-sslinfo-for-targetendpoint-using-variable.html ।

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

ভেরিয়েবলগুলি শুধুমাত্র নিম্নলিখিত উপাদানগুলিতে অনুমোদিত।

<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 শংসাপত্রের মেয়াদ শেষ হলে আপনাকে বিবেচনা করতে হবে, অথবা সিস্টেম কনফিগারেশনে পরিবর্তনের জন্য আপনাকে শংসাপত্র আপডেট করতে হবে। প্রাইভেট ক্লাউড ইনস্টলেশনের জন্য একটি প্রান্তে, স্ট্যাটিক মান ব্যবহার করে বা ফ্লো ভেরিয়েবল ব্যবহার করে 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

লক্ষ্য লোড ব্যালেন্সিং সহ TargetEndpoint

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

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

নীতিমালা

API প্রক্সির /policies ডিরেক্টরিতে API প্রক্সিতে ফ্লোতে সংযুক্ত করার জন্য উপলব্ধ সমস্ত নীতি রয়েছে।

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

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

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

উপরে দেখানো হিসাবে:

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

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

নীতিগুলি সেই ক্রম অনুসারে প্রয়োগ করা হয় যাতে তারা একটি প্রবাহের সাথে সংযুক্ত থাকে৷ যেমন:

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

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

প্রবাহিত হয়

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

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

উপরন্তু, আপনি 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. প্রক্সি অনুরোধ PreFlow
2. প্রক্সি অনুরোধ শর্তসাপেক্ষ প্রবাহ (ঐচ্ছিক)
3. প্রক্সি অনুরোধ পোস্টফ্লো
4. লক্ষ্য অনুরোধ PreFlow
5. লক্ষ্য অনুরোধ শর্তাধীন প্রবাহ (ঐচ্ছিক)
6. লক্ষ্য অনুরোধ পোস্টফ্লো

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

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

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

শর্তসাপেক্ষ প্রবাহের বিপরীতে, প্রিফ্লো এবং পোস্টফ্লো উপাদানগুলির ক্রম গুরুত্বপূর্ণ নয়--এন্ডপয়েন্ট কনফিগারেশনে তারা যেখানেই উপস্থিত হোক না কেন 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 মূল্যায়ন করা হয় তা কার্যকর করা হয় এবং শুধুমাত্র একটি শর্তসাপেক্ষ ফ্লো চালানো হয়।

উদাহরণস্বরূপ, নিম্নলিখিত ফ্লো কনফিগারেশনে, যে কোনো অন্তর্মুখী অনুরোধ যা পাথ প্রত্যয় /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>

সম্পদ

"রিসোর্স" (এপিআই প্রক্সিতে ব্যবহারের জন্য রিসোর্স ফাইল) হল স্ক্রিপ্ট, কোড এবং এক্সএসএল ট্রান্সফরমেশন যা পলিসি ব্যবহার করে ফ্লোতে সংযুক্ত করা যেতে পারে। এগুলি ব্যবস্থাপনা UI-তে API প্রক্সি সম্পাদকের "স্ক্রিপ্ট" বিভাগে প্রদর্শিত হয়৷

সমর্থিত সম্পদ প্রকারের জন্য সম্পদ ফাইল দেখুন।

সম্পদগুলি একটি API প্রক্সি, একটি পরিবেশ বা একটি সংস্থায় সংরক্ষণ করা যেতে পারে। প্রতিটি ক্ষেত্রে, একটি সম্পদ একটি নীতিতে নাম দ্বারা উল্লেখ করা হয়। API পরিষেবাগুলি API প্রক্সি থেকে পরিবেশে, সংস্থার স্তরে যাওয়ার মাধ্যমে নামটির সমাধান করে৷

সংস্থার স্তরে সঞ্চিত একটি সংস্থান যে কোনও পরিবেশে নীতি দ্বারা উল্লেখ করা যেতে পারে। পরিবেশ স্তরে সঞ্চিত একটি সংস্থান সেই পরিবেশের নীতিগুলি দ্বারা উল্লেখ করা যেতে পারে। API প্রক্সি স্তরে সঞ্চিত একটি সংস্থান শুধুমাত্র সেই API প্রক্সির নীতিগুলির দ্বারা উল্লেখ করা যেতে পারে৷