एपीआई प्रॉक्सी कॉन्फ़िगरेशन के बारे में जानकारी

आपको Apigee Edge का दस्तावेज़ दिख रहा है.
Apigee X के दस्तावेज़ पर जाएं. जानकारी

Apigee Edge का इस्तेमाल करने वाले डेवलपर के तौर पर, आपकी मुख्य डेवलपमेंट गतिविधियों में ये शामिल हैं: एपीआई प्रॉक्सी कॉन्फ़िगर करना. ये एपीआई या बैकएंड सेवाओं के लिए प्रॉक्सी के तौर पर काम करती हैं. इस दस्तावेज़ में, एपीआई प्रॉक्सी बनाते समय उपलब्ध सभी कॉन्फ़िगरेशन एलिमेंट के बारे में जानकारी दी गई है.

अगर आपको एपीआई प्रॉक्सी बनाने का तरीका सीखना है, तो हमारा सुझाव है कि आप एक सामान्य एपीआई प्रॉक्सी बनाएं विषय से शुरुआत करें.

प्रॉक्सी कॉन्फ़िगरेशन में बदलाव करने के सबसे सामान्य तरीके ये हैं:

• Edge यूज़र इंटरफ़ेस में एक्सएमएल एडिटर का इस्तेमाल करना
• कॉन्फ़िगरेशन डाउनलोड करें और उसे स्थानीय तौर पर बदलें. इसके बारे में प्रॉक्सी कॉन्फ़िगरेशन का लोकल डेवलपमेंट लेख में बताया गया है.

प्रॉक्सी कॉन्फ़िगरेशन का लोकल डेवलपमेंट

अपने प्रॉक्सी कॉन्फ़िगरेशन डाउनलोड किए जा सकते हैं, ताकि उन्हें लोकल मशीन पर बदला जा सके. काम पूरा होने के बाद, नतीजों को Edge पर अपलोड करें. इस तरीके से, प्रॉक्सी कॉन्फ़िगरेशन को सोर्स कंट्रोल, वर्शनिंग, और शेयर किए गए अन्य वर्कफ़्लो में इंटिग्रेट किया जा सकता है. इसके अलावा, प्रॉक्सी कॉन्फ़िगरेशन पर स्थानीय तौर पर काम करके, अपने एक्सएमएल एडिटर और पुष्टि करने वाले टूल इस्तेमाल किए जा सकते हैं.

इस सेक्शन में, यूज़र इंटरफ़ेस (यूआई) का इस्तेमाल करके, मौजूदा प्रॉक्सी कॉन्फ़िगरेशन को डाउनलोड करने, उसमें बदलाव करने, और फिर उसे Edge पर डिप्लॉय करने के लिए वापस अपलोड करने का तरीका बताया गया है. apigeetool का इस्तेमाल करके भी, नया प्रॉक्सी कॉन्फ़िगरेशन डाउनलोड और डिप्लॉय किया जा सकता है. इसके लिए, fetchproxy और deployproxy कमांड का इस्तेमाल करें.

यूज़र इंटरफ़ेस (यूआई) का इस्तेमाल करके, प्रॉक्सी कॉन्फ़िगरेशन में स्थानीय तौर पर बदलाव करने के लिए:

1. Edge यूआई में, मौजूदा प्रॉक्सी कॉन्फ़िगरेशन डाउनलोड करें. (एपीआई प्रॉक्सी व्यू में, प्रोजेक्ट > डाउनलोड रिवीजन चुनें.)
2. अपनी लोकल मशीन पर, एक नई डायरेक्ट्री बनाएं और डाउनलोड की गई ZIP फ़ाइल को उसमें एक्सट्रैक्ट करें.

   ZIP फ़ाइल को बड़ा करने के लिए, unzip जैसी किसी यूटिलिटी का इस्तेमाल किया जा सकता है. इसका उदाहरण यहां दिया गया है:

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

   ZIP फ़ाइल के कॉन्टेंट का स्ट्रक्चर, एपीआई प्रॉक्सी स्ट्रक्चर में बताए गए स्ट्रक्चर जैसा होना चाहिए.

3. सोर्स फ़ाइलों में ज़रूरत के मुताबिक बदलाव करें. प्रॉक्सी कॉन्फ़िगरेशन में मौजूद सोर्स फ़ाइलों के बारे में जानने के लिए, एपीआई प्रॉक्सी की कॉन्फ़िगरेशन फ़ाइलें और डायरेक्ट्री स्ट्रक्चर लेख पढ़ें.

   उदाहरण के लिए, अपनी एपीआई प्रॉक्सी में सेहत की निगरानी की सुविधा चालू करने के लिए, /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 होनी चाहिए.

   ZIP फ़ाइल के नाम के लिए कोई खास ज़रूरी शर्तें नहीं हैं. उदाहरण के लिए, आपको फ़ाइल के नाम में संशोधन संख्या बढ़ाने या तारीख तय करने की ज़रूरत नहीं है. हालांकि, ऐसा करने से डीबग करने या सोर्स कंट्रोल करने में मदद मिल सकती है.

   Edge, नए प्रॉक्सी कॉन्फ़िगरेशन का वर्शन नंबर अपने-आप बढ़ा देता है. ऐसा तब होता है, जब आप उसे अपलोड करते हैं.

7. Edge के यूज़र इंटरफ़ेस (यूआई) का इस्तेमाल करके, नया प्रॉक्सी कॉन्फ़िगरेशन अपलोड करें. (एपीआई प्रॉक्सी व्यू में, प्रोजेक्ट > नया वर्शन अपलोड करें को चुनें.)

   अगर आपको Bundle is invalid. Empty bundle. जैसी कोई गड़बड़ी मिलती है, तो पक्का करें कि आपकी ZIP फ़ाइल की टॉप-लेवल डायरेक्ट्री /apiproxy हो. अगर ऐसा नहीं है, तो रूट डायरेक्ट्री से अपनी प्रॉक्सी कॉन्फ़िगरेशन फ़ाइलों को फिर से संग्रहित करें.

   नया प्रॉक्सी कॉन्फ़िगरेशन अपलोड करने के बाद, Edge, वर्शन नंबर को बढ़ा देता है और उसे बदलाव की खास जानकारी व्यू में दिखाता है.

   यूज़र इंटरफ़ेस (यूआई) का इस्तेमाल करके अपलोड करने के बाद, Edge आपके लिए नया वर्शन डिप्लॉय नहीं करता.

8. अपने नए वर्शन को डिप्लॉय करें.

ज़्यादा जानकारी के लिए, Apigee Community में ट्यूटोरियल: यूज़र इंटरफ़ेस (यूआई) और मैनेजमेंट एपीआई का इस्तेमाल करके प्रॉक्सी डाउनलोड करने का तरीका देखें.

एपीआई प्रॉक्सी का स्ट्रक्चर

एपीआई प्रॉक्सी में यह कॉन्फ़िगरेशन होता है:

एपीआई प्रॉक्सी डायरेक्ट्री का स्ट्रक्चर और कॉन्टेंट

ऊपर दी गई टेबल में मौजूद कॉम्पोनेंट, यहां दिए गए डायरेक्ट्री स्ट्रक्चर में मौजूद कॉन्फ़िगरेशन फ़ाइलों से तय होते हैं:

एपीआई प्रॉक्सी की कॉन्फ़िगरेशन फ़ाइलें और डायरेक्ट्री स्ट्रक्चर

इस सेक्शन में, एपीआई प्रॉक्सी की कॉन्फ़िगरेशन फ़ाइलों और डायरेक्ट्री स्ट्रक्चर के बारे में बताया गया है.

• बुनियादी कॉन्फ़िगरेशन
• ProxyEndpoint
• TargetEndpoint
  • TLS/एसएसएल TargetEndpoint कॉन्फ़िगरेशन
• नीतियां
• फ़्लो
• संसाधन

बेस कॉन्फ़िगरेशन

/apiproxy/weatherapi.xml

एपीआई प्रॉक्सी के लिए बुनियादी कॉन्फ़िगरेशन, जो एपीआई प्रॉक्सी का नाम तय करता है. संगठन में नाम यूनीक होना चाहिए.

कॉन्फ़िगरेशन का सैंपल:

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

बेस कॉन्फ़िगरेशन एलिमेंट

ProxyEndpoint

नीचे दी गई इमेज में, अनुरोध/जवाब का फ़्लो दिखाया गया है:

/apiproxy/proxies/default.xml

ProxyEndpoint कॉन्फ़िगरेशन, एपीआई प्रॉक्सी के लिए इनबाउंड (क्लाइंट के लिए उपलब्ध) इंटरफ़ेस तय करता है. ProxyEndpoint को कॉन्फ़िगर करने का मतलब है कि आपने एक नेटवर्क कॉन्फ़िगरेशन सेट अप किया है. इससे यह तय होता है कि क्लाइंट ऐप्लिकेशन ('ऐप्लिकेशन') को प्रॉक्सी किए गए एपीआई को कैसे शुरू करना चाहिए.

नीचे दिए गए 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>

यूआरएल को सीधे तौर पर शुरू करना

ProxyEndpoint, सीधे तौर पर बैकएंड सेवा को भी चालू कर सकता है. यूआरएल को सीधे तौर पर इनवोक करने से, /apiproxy/targets में मौजूद TargetEndpoints कॉन्फ़िगरेशन को बायपास किया जाता है. इस वजह से, TargetEndpoint एक वैकल्पिक एपीआई प्रॉक्सी कॉन्फ़िगरेशन है. हालांकि, व्यवहार में ProxyEndpoint से सीधे तौर पर इनवोक करने का सुझाव नहीं दिया जाता.

उदाहरण के लिए, यहां दी गई RouteRule, http://api.mycompany.com/v2 को एक एचटीटीपी कॉल करती है.

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

शर्तों के हिसाब से तय किए गए रूट

RouteRules को चेन किया जा सकता है, ताकि रनटाइम के दौरान डाइनैमिक राउटिंग की जा सके. इनबाउंड अनुरोधों को इन जगहों पर भेजा जा सकता है: नाम वाले TargetEndpoint कॉन्फ़िगरेशन, सीधे यूआरएल या दोनों के कॉम्बिनेशन पर. ऐसा एचटीटीपी हेडर, मैसेज के कॉन्टेंट, क्वेरी पैरामीटर या कॉन्टेक्स्ट के हिसाब से जानकारी के आधार पर किया जाता है. जैसे, दिन का समय, स्थान-भाषा वगैरह.

कंडिशनल RouteRule, Apigee Edge पर अन्य कंडिशनल स्टेटमेंट की तरह काम करती हैं. शर्तों के रेफ़रंस और वैरिएबल के रेफ़रंस देखें.

उदाहरण के लिए, यहां दिए गए RouteRule कॉम्बिनेशन में, सबसे पहले इनबाउंड अनुरोध का आकलन किया जाता है. इससे एचटीटीपी हेडर की वैल्यू की पुष्टि की जा सकती है. अगर एचटीटीपी हेडर 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 तय किया जा सकता है. यह तब काम आता है, जब ProxyEndpoint सभी ज़रूरी प्रोसेसिंग करता है. उदाहरण के लिए, JavaScript का इस्तेमाल करके किसी बाहरी सेवा को कॉल करना या API सेवाओं के कुंजी/वैल्यू स्टोर से डेटा वापस पाना.

उदाहरण के लिए, यहां एक शून्य रूट तय किया गया है:

<RouteRule name="GoNowhere"/>

शर्त के हिसाब से शून्य किए गए रूट काम के हो सकते हैं. यहां दिए गए उदाहरण में, एक नल रूट को कॉन्फ़िगर किया गया है. यह तब लागू होगा, जब एचटीटीपी हेडर 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>

TargetEndpoint

TargetEndpoint, ProxyEndpoint की तरह ही आउटबाउंड होता है. TargetEndpoint, बैकएंड सेवा या एपीआई के क्लाइंट के तौर पर काम करता है. यह अनुरोध भेजता है और जवाब पाता है.

एपीआई प्रॉक्सी में TargetEndpoints का होना ज़रूरी नहीं है. ProxyEndpoints को सीधे तौर पर यूआरएल कॉल करने के लिए कॉन्फ़िगर किया जा सकता है. 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
• लोकल प्रॉक्सी-टू-प्रॉक्सी चेनिंग के लिए LocalTargetConnection
• Edge पर होस्ट की गई Node.js स्क्रिप्ट को कॉल करने के लिए ScriptTarget

TargetEndpoint में इनमें से सिर्फ़ एक को कॉन्फ़िगर करें.

TargetEndpoint के लिए टीएलएस/एसएसएल कॉन्फ़िगरेशन

TargetEndpoints को अक्सर अलग-अलग बैकएंड इंफ़्रास्ट्रक्चर के साथ एचटीटीपीएस कनेक्शन मैनेज करने होते हैं. इस वजह से, टीएलएस/एसएसएल कॉन्फ़िगरेशन की कई सेटिंग काम करती हैं.

TargetEndpoint कॉन्फ़िगरेशन एलिमेंट के लिए 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>

ज़्यादा जानकारी के लिए, Edge से लेकर बैकएंड (क्लाउड और प्राइवेट क्लाउड) तक टीएलएस कॉन्फ़िगर करना लेख पढ़ें.

टीएलएस/एसएसएल वैल्यू को डाइनैमिक तौर पर सेट करने के लिए, फ़्लो वैरिएबल का इस्तेमाल करना

टीएलएस/एसएसएल की जानकारी को डाइनैमिक तौर पर भी सेट किया जा सकता है, ताकि रनटाइम से जुड़ी ज़रूरी शर्तों को पूरा किया जा सके. उदाहरण के लिए, अगर आपकी प्रॉक्सी दो अलग-अलग टारगेट (टेस्ट टारगेट और प्रोडक्शन टारगेट) से कनेक्ट होती है, तो आपके पास अपनी एपीआई प्रॉक्सी को प्रोग्राम के हिसाब से यह पता लगाने की सुविधा होती है कि वह किस एनवायरमेंट को कॉल कर रही है. साथ ही, सही कीस्टोर और ट्रस्टस्टोर के लिए रेफ़रंस को डाइनैमिक तौर पर सेट करने की सुविधा होती है. 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 वैल्यू को डाइनैमिक तौर पर सेट करने के लिए रेफ़रंस का इस्तेमाल करना

एचटीटीपीएस का इस्तेमाल करने वाले TargetEndpoint को कॉन्फ़िगर करते समय, आपको यह ध्यान रखना होगा कि टीएलएस/एसएसएल सर्टिफ़िकेट कब एक्सपायर होता है. इसके अलावा, सिस्टम कॉन्फ़िगरेशन में बदलाव होने पर, आपको सर्टिफ़िकेट अपडेट करना पड़ सकता है. Edge for Private Cloud इंस्टॉलेशन में, स्टैटिक वैल्यू या फ़्लो वैरिएबल का इस्तेमाल करके टीएलएस/एसएसएल को कॉन्फ़िगर करते समय, आपको मैसेज प्रोसेसर को रीस्टार्ट करना पड़ सकता है.

ज़्यादा जानकारी के लिए, टीएलएस सर्टिफ़िकेट अपडेट करना लेख पढ़ें.

हालांकि, आपके पास TargetEndpoint को कॉन्फ़िगर करने का विकल्प होता है, ताकि वह कीस्टोर या ट्रस्टस्टोर के रेफ़रंस का इस्तेमाल कर सके. रेफ़रंस का इस्तेमाल करने का फ़ायदा यह है कि टीएलएस/एसएसएल सर्टिफ़िकेट को अपडेट करने के लिए, आपको मैसेज प्रोसेसर को रीस्टार्ट करने की ज़रूरत नहीं होती. इसके बजाय, किसी दूसरे कीस्टोर या ट्रस्टस्टोर की ओर इशारा करने के लिए, रेफ़रंस को अपडेट किया जा सकता है.

उदाहरण के लिए, यहां एक ऐसा 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 के बीच लोड बैलेंसिंग की सुविधा देता है.

ज़्यादा जानकारी के लिए, बैकएंड सर्वर के बीच लोड बैलेंसिंग लेख पढ़ें.

नीतियां

एपीआई प्रॉक्सी में मौजूद /policies डायरेक्ट्री में, वे सभी नीतियां होती हैं जिन्हें एपीआई प्रॉक्सी में मौजूद फ़्लो से जोड़ा जा सकता है.

नीति कॉन्फ़िगरेशन एलिमेंट

नीति अटैच करना

इस इमेज में, एपीआई प्रॉक्सी के फ़्लो को लागू करने का क्रम दिखाया गया है:

ऊपर दिखाए गए तरीके से:

नीतियों को फ़्लो में प्रोसेसिंग के चरणों के तौर पर अटैच किया जाता है. नीति के नाम का इस्तेमाल, उस नीति को रेफ़रंस देने के लिए किया जाता है जिसे प्रोसेसिंग के चरण के तौर पर लागू करना है. नीति के अटैचमेंट का फ़ॉर्मैट यह है:

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

नीतियों को उसी क्रम में लागू किया जाता है जिस क्रम में उन्हें फ़्लो से जोड़ा जाता है. उदाहरण के लिए:

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

नीति अटैच करने के कॉन्फ़िगरेशन एलिमेंट

फ़्लो

ProxyEndpoint और TargetEndpoint, अनुरोध और जवाब के मैसेज को प्रोसेस करने के लिए पाइपलाइन तय करते हैं. प्रोसेसिंग पाइपलाइन में, अनुरोध फ़्लो और जवाब फ़्लो शामिल होता है. हर अनुरोध और जवाब के फ़्लो को PreFlow, एक या उससे ज़्यादा वैकल्पिक 'conditional' या 'named' फ़्लो, और PostFlow में बांटा जाता है.

• PreFlow: यह हमेशा लागू होता है. यह किसी भी शर्त वाले फ़्लो से पहले लागू होता है.
• PostFlow: यह हमेशा लागू होता है. यह किसी भी शर्त के साथ काम करने वाले फ़्लो के बाद काम करता है.

इसके अलावा, ProxyEndpoint में PostClientFlow जोड़ा जा सकता है. यह अनुरोध करने वाले क्लाइंट ऐप्लिकेशन को जवाब मिलने के बाद काम करता है. इस फ़्लो में सिर्फ़ MessageLogging नीति और Google Stackdriver Logging Extension को जोड़ा जा सकता है. PostClientFlow से एपीआई प्रॉक्सी की लेटेन्सी कम हो जाती है. साथ ही, यह ऐसी जानकारी को लॉग करने के लिए उपलब्ध कराता है जिसकी गिनती तब तक नहीं की जाती, जब तक क्लाइंट को जवाब नहीं मिल जाता. जैसे, 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>
    ...

एपीआई प्रॉक्सी प्रोसेसिंग पाइपलाइन, फ़्लो को इस क्रम में लागू करती है:

अनुरोध पाइपलाइन:

1. प्रॉक्सी अनुरोध का PreFlow
2. प्रॉक्सी अनुरोध के लिए शर्तों के साथ फ़्लो (ज़रूरी नहीं)
3. Proxy Request PostFlow
4. टारगेट अनुरोध का PreFlow
5. Target Request Conditional Flows (ज़रूरी नहीं)
6. Target Request PostFlow

जवाब देने की पाइपलाइन:

1. Target Response PreFlow
2. जवाब देने के लिए शर्तों के आधार पर फ़्लो को टारगेट करना (ज़रूरी नहीं)
3. Target Response PostFlow
4. Proxy Response PreFlow
5. प्रॉक्सी रिस्पॉन्स के लिए शर्त के साथ फ़्लो (ज़रूरी नहीं)
6. Proxy Response PostFlow
7. PostClientFlow Response (ज़रूरी नहीं)

नीति अटैचमेंट वाले फ़्लो को ही ProxyEndpoint या TargetEndpoint कॉन्फ़िगरेशन में कॉन्फ़िगर किया जाना चाहिए. प्रीफ़्लो और पोस्टफ़्लो को सिर्फ़ ProxyEndpoint या TargetEndpoint कॉन्फ़िगरेशन में तब तय किया जाना चाहिए, जब प्रीफ़्लो या पोस्टफ़्लो प्रोसेसिंग के दौरान किसी नीति को लागू करना हो.

शर्त के साथ लागू होने वाले फ़्लो के उलट, PreFlow और PostFlow के एलिमेंट का क्रम मायने नहीं रखता. एपीआई प्रॉक्सी, पाइपलाइन में हमेशा सही समय पर हर एलिमेंट को लागू करेगी. भले ही, वे एंडपॉइंट कॉन्फ़िगरेशन में कहीं भी दिखें.

कंडिशनल फ़्लो

ProxyEndpoints और TargetEndpoints में, शर्तों के हिसाब से काम करने वाले फ़्लो (इन्हें 'नाम वाले फ़्लो' भी कहा जाता है) की कोई सीमा नहीं होती.

एपीआई प्रॉक्सी, शर्त वाले फ़्लो में बताई गई शर्त की जांच करती है. अगर शर्त पूरी हो जाती है, तो एपीआई प्रॉक्सी, शर्त वाले फ़्लो में प्रोसेसिंग के चरणों को पूरा करती है. अगर शर्त पूरी नहीं होती है, तो शर्त के हिसाब से तय किए गए फ़्लो में प्रोसेसिंग के चरणों को छोड़ दिया जाता है. शर्त के आधार पर फ़्लो का आकलन, एपीआई प्रॉक्सी में तय किए गए क्रम में किया जाता है. जिस फ़्लो की शर्त पूरी होती है उसे सबसे पहले लागू किया जाता है.

शर्तों के हिसाब से फ़्लो तय करने पर, आपको एपीआई प्रॉक्सी में प्रोसेसिंग के चरण लागू करने की सुविधा मिलती है. ये चरण, इन बातों के आधार पर लागू किए जाते हैं:

• अनुरोध URI
• एचटीटीपी वर्ब (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>

संसाधन

"संसाधन" (एपीआई प्रॉक्सी में इस्तेमाल की जाने वाली संसाधन फ़ाइलें) स्क्रिप्ट, कोड, और XSL ट्रांसफ़ॉर्मेशन होते हैं. इन्हें नीतियों का इस्तेमाल करके फ़्लो से जोड़ा जा सकता है. ये मैनेजमेंट यूज़र इंटरफ़ेस (यूआई) में, एपीआई प्रॉक्सी एडिटर के "स्क्रिप्ट" सेक्शन में दिखते हैं.

जिन संसाधन टाइप के लिए यह सुविधा उपलब्ध है उनके बारे में जानने के लिए, संसाधन फ़ाइलें देखें.

संसाधन, एपीआई प्रॉक्सी, एनवायरमेंट या संगठन में सेव किए जा सकते हैं. हर मामले में, किसी संसाधन को नीति में नाम से रेफ़रंस किया जाता है. एपीआई सेवाएं, एपीआई प्रॉक्सी से एनवायरमेंट और फिर संगठन के लेवल पर जाकर नाम का पता लगाती हैं.

संगठन के लेवल पर सेव किए गए संसाधन का रेफ़रंस, किसी भी एनवायरमेंट में नीतियों के लिए इस्तेमाल किया जा सकता है. एनवायरमेंट लेवल पर सेव किए गए किसी संसाधन का रेफ़रंस, उस एनवायरमेंट में मौजूद नीतियां दे सकती हैं. एपीआई प्रॉक्सी लेवल पर सेव किए गए किसी संसाधन को सिर्फ़ उस एपीआई प्रॉक्सी में मौजूद नीतियां रेफ़रंस कर सकती हैं.