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

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 कम्यूनिटी में ट्यूटोरियल: यूज़र इंटरफ़ेस (यूआई) और मैनेजमेंट एपीआई का इस्तेमाल करके प्रॉक्सी डाउनलोड करने का तरीका देखें.

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

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

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

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

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

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

• बुनियादी कॉन्फ़िगरेशन
• 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>

नल रूट

RouteRule को शून्य के तौर पर तय किया जा सकता है. इससे उन स्थितियों में मदद मिलती है जिनमें अनुरोध के मैसेज को TargetEndpoint पर फ़ॉरवर्ड करने की ज़रूरत नहीं होती. यह तब काम आता है, जब ProxyEndpoint सभी ज़रूरी प्रोसेसिंग करता है. उदाहरण के लिए, JavaScript का इस्तेमाल करके किसी बाहरी सेवा को कॉल करना या एपीआई सेवाओं के कुंजी/वैल्यू स्टोर से डेटा वापस पाना.

उदाहरण के लिए, यहां एक ऐसे रूट के बारे में बताया गया है जिसमें कोई वैल्यू नहीं है:

<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 होता है. यह 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 में इनमें से सिर्फ़ एक को कॉन्फ़िगर करें.

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

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

टीएलएस/एसएसएल 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>

आउटबाउंड क्लाइंट की पुष्टि करने की सुविधा चालू किए गए 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>

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

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

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

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

उदाहरण के लिए, यहां एक 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 with target load balancing

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

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

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

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