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

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

Apigee 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. उस नई डायरेक्ट्री में बदलें जिसे आपने ZIP फ़ाइलों (बड़े की गई कॉन्फ़िगरेशन फ़ाइलों का रूट) को बड़ा करते समय बनाया था.

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

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

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

बेस कॉन्फ़िगरेशन एपीआई प्रॉक्सी के लिए मुख्य कॉन्फ़िगरेशन सेटिंग. बुनियादी कॉन्फ़िगरेशन देखें.
प्रॉक्सीEndpoint कॉन्फ़िगरेशन इनबाउंड एचटीटीपी कनेक्शन (ऐप्लिकेशन का अनुरोध करने से लेकर Apigee Edge तक), अनुरोध और रिस्पॉन्स फ़्लो, और नीति के अटैचमेंट की सेटिंग. ProxyEndpoint देखें.
TargetEndpoint कॉन्फ़िगरेशन आउटबाउंड एचटीटीपी कनेक्शन (Apigee Edge से लेकर बैकएंड सेवा तक), अनुरोध और रिस्पॉन्स फ़्लो, और नीति के अटैचमेंट की सेटिंग. TargetEndpoint देखें.
फ़्लो ProxyEndpoint और TargetEndpoint का अनुरोध और रिस्पॉन्स पाइपलाइन, जिनसे नीतियां जोड़ी जा सकती हैं. फ़्लो देखें.
नीतियां एक्सएमएल फ़ॉर्मैट की ऐसी कॉन्फ़िगरेशन फ़ाइलें जो Apigee Edge की नीति के स्कीमा के मुताबिक हों. नीतियां देखें.
संसाधन कस्टम लॉजिक लागू करने के लिए, नीतियों में रेफ़र की गई स्क्रिप्ट, JAR फ़ाइलें, और XSLT फ़ाइलें. संसाधन देखें.

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

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

उस डायरेक्ट्री के स्ट्रक्चर को दिखाता है जिसमें apiप्रॉक्सी रूट है. apiप्रॉक्सी डायरेक्ट्री में सीधे तौर पर
    नीतियां, प्रॉक्सी, संसाधन, और टारगेट डायरेक्ट्री मौजूद होती हैं. साथ ही, Weatherapi.xml फ़ाइल भी मौजूद होती है.

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

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

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

/apiproxy/weatherapi.xml

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

कॉन्फ़िगरेशन का नमूना:

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

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

नाम जानकारी डिफ़ॉल्ट ज़रूरी है?
APIProxy
name एपीआई प्रॉक्सी का नाम, जो हर संगठन के लिए अलग होना चाहिए. नाम में जिन वर्णों का इस्तेमाल करने की अनुमति है वे सिर्फ़ इन वर्णों तक सीमित हैं: A-Za-z0-9_- लागू नहीं हां
revision एपीआई प्रॉक्सी कॉन्फ़िगरेशन का वर्शन नंबर. आपको बदलाव के नंबर को अलग से सेट करने की ज़रूरत नहीं है, क्योंकि Apigee Edge, एपीआई प्रॉक्सी के मौजूदा वर्शन को अपने-आप ट्रैक करता है. लागू नहीं नहीं
ConfigurationVersion यह एपीआई प्रॉक्सी कॉन्फ़िगरेशन स्कीमा के मुताबिक एपीआई प्रॉक्सी कॉन्फ़िगरेशन स्कीमा का वर्शन है. फ़िलहाल, सिर्फ़ मेजर वर्शन 4 और माइनरवर्शन 0 के लिए वैल्यू इस्तेमाल की जा सकती है. इस सेटिंग का इस्तेमाल आने वाले समय में किया जा सकता है, ताकि एपीआई प्रॉक्सी फ़ॉर्मैट को बेहतर बनाया जा सके. 4.0 नहीं
Description एपीआई प्रॉक्सी के बारे में टेक्स्ट के साथ जानकारी. अगर बताया गया है, तो यह जानकारी Edge मैनेजमेंट के यूज़र इंटरफ़ेस (यूआई) में दिखेगी. लागू नहीं नहीं
DisplayName उपयोगकर्ता के लिए ऐसा नाम जो एपीआई प्रॉक्सी कॉन्फ़िगरेशन के name एट्रिब्यूट से अलग हो. लागू नहीं नहीं
Policies इस एपीआई प्रॉक्सी की /policies डायरेक्ट्री में मौजूद नीतियों की सूची. आम तौर पर आपको यह एलिमेंट तब ही दिखेगा, जब Edge मैनेजमेंट यूज़र इंटरफ़ेस (यूआई) का इस्तेमाल करके एपीआई प्रॉक्सी बनाया गया था. यह सिर्फ़ एक 'मेनिफ़ेस्ट' सेटिंग है, जिसे एपीआई प्रॉक्सी के कॉन्टेंट को देखने के लिए डिज़ाइन किया गया है. लागू नहीं नहीं
ProxyEndpoints इस एपीआई प्रॉक्सी की /proxies डायरेक्ट्री में मौजूद प्रॉक्सीEndpoints की सूची. आपको यह एलिमेंट आम तौर पर तब ही दिखेगा, जब Edge मैनेजमेंट यूज़र इंटरफ़ेस (यूआई) का इस्तेमाल करके एपीआई प्रॉक्सी बनाया गया था. यह सिर्फ़ एक 'मेनिफ़ेस्ट' सेटिंग है, जिसे एपीआई प्रॉक्सी के कॉन्टेंट को देखने के लिए डिज़ाइन किया गया है. लागू नहीं नहीं
Resources इस एपीआई प्रॉक्सी की /resources डायरेक्ट्री में मौजूद संसाधनों (JavaScript, Python, Java, XSLT) की सूची. आम तौर पर आपको यह एलिमेंट तब ही दिखेगा, जब Edge मैनेजमेंट यूज़र इंटरफ़ेस (यूआई) का इस्तेमाल करके एपीआई प्रॉक्सी बनाया गया हो. यह सिर्फ़ एक 'मेनिफ़ेस्ट' सेटिंग है, जिसे एपीआई प्रॉक्सी के कॉन्टेंट को देखने की सुविधा देने के लिए डिज़ाइन किया गया है. लागू नहीं नहीं
Spec एपीआई प्रॉक्सी से जुड़े OpenAPI स्पेसिफ़िकेशन की पहचान करता है. वैल्यू किसी यूआरएल या स्पेसिफ़िकेशन स्टोर में मौजूद पाथ पर सेट है.

ध्यान दें: स्पेसिफ़िकेशन स्टोर, सिर्फ़ New Edge में उपलब्ध है. स्पेसिफ़िकेशन स्टोर के बारे में ज़्यादा जानकारी के लिए, कारोबार से जुड़ी खास जानकारी को मैनेज और शेयर करने से जुड़ी जानकारी देखें.
लागू नहीं नहीं
TargetServers इस एपीआई प्रॉक्सी के किसी भी TargetEndpoints में रेफ़र किए गए TargetServers की सूची है. आम तौर पर आपको यह एलिमेंट तब ही दिखेगा, जब Edge मैनेजमेंट यूज़र इंटरफ़ेस (यूआई) का इस्तेमाल करके एपीआई प्रॉक्सी बनाया गया था. यह सिर्फ़ एक 'मेनिफ़ेस्ट' सेटिंग है, जिसे एपीआई प्रॉक्सी के कॉन्टेंट को देखने के लिए डिज़ाइन किया गया है. लागू नहीं नहीं
TargetEndpoints इस एपीआई प्रॉक्सी की /targets डायरेक्ट्री में, TargetEndpoints की सूची है. आपको यह एलिमेंट आम तौर पर तब ही दिखेगा, जब Edge मैनेजमेंट यूज़र इंटरफ़ेस (यूआई) का इस्तेमाल करके एपीआई प्रॉक्सी बनाया गया था. यह सिर्फ़ एक 'मेनिफ़ेस्ट' सेटिंग है, जिसे एपीआई प्रॉक्सी के कॉन्टेंट को देखने के लिए डिज़ाइन किया गया है. लागू नहीं नहीं

ProxyEndpoint

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

एचटीटीपी सेवा को कॉल करने वाला क्लाइंट दिखाता है. अनुरोध को एचटीटीपी सेवा के प्रोसेस करने से पहले, प्रॉक्सी एंडपॉइंट और फिर टारगेट एंडपॉइंट से
  भेजा जाता है. क्लाइंट को वापस भेजे जाने से पहले, रिस्पॉन्स, टारगेट एंडपोइंग
  और फिर प्रॉक्सी एंडपॉइंट से होता है.

/apiproxy/proxies/default.xml

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

नीचे दिया गया 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 के ज़रूरी कॉन्फ़िगरेशन एलिमेंट यहां दिए गए हैं:

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

नाम जानकारी डिफ़ॉल्ट ज़रूरी है?
ProxyEndpoint
name ProxyEndpoint का नाम. एपीआई प्रॉक्सी कॉन्फ़िगरेशन में यह सबसे अलग होना चाहिए, जब (बहुत कम मामलों में) एक से ज़्यादा ProxyEndpoint तय किए गए हों. नाम में, आपको जिन वर्णों का इस्तेमाल करने की अनुमति है वे सिर्फ़ इन वर्णों के लिए इस्तेमाल किए जा सकते हैं: A-Za-z0-9._\-$ %. लागू नहीं हां
PreFlow यह नीति किसी अनुरोध या जवाब के PreFlow फ़्लो में नीतियों के बारे में बताती है. लागू नहीं हां
Flows
किसी अनुरोध या जवाब के कंडीशनल फ़्लो में नीतियों के बारे में बताता है.
लागू नहीं हां
PostFlow
यह नीति किसी अनुरोध या जवाब के PostFlow फ़्लो में नीतियों के बारे में बताती है.
लागू नहीं हां
HTTPProxyConnection एपीआई प्रॉक्सी से जुड़े नेटवर्क पते और यूआरआई पाथ के बारे में बताता है
BasePath

एक ज़रूरी स्ट्रिंग, जो खास तौर पर उस यूआरआई पाथ की पहचान करती है जिसका इस्तेमाल Apigee Edge करता है, ताकि आने वाले मैसेज को सही एपीआई प्रॉक्सी पर रूट किया जा सके.

BasePath एक यूआरआई फ़्रैगमेंट (उदाहरण के लिए, /weather) है, जो एपीआई प्रॉक्सी (उदाहरण के लिए, http://apifactory-test.apigee.net) के बेस यूआरएल से जुड़ा होता है. BasePath को एनवायरमेंट में यूनीक होना चाहिए. एपीआई प्रॉक्सी जनरेट या इंपोर्ट होने पर, उस प्रॉपर्टी की खासियत की पुष्टि की जाती है.

बेस पाथ में वाइल्डकार्ड का इस्तेमाल करना

एपीआई प्रॉक्सी बेस पाथ में एक या उससे ज़्यादा "*" वाइल्डकार्ड का इस्तेमाल किया जा सकता है. उदाहरण के लिए, /team/*/members के बेस पाथ की मदद से क्लाइंट, https://[host]/team/blue/members और https://[host]/team/green/members को कॉल कर सकते हैं. इसके लिए, आपको नई एपीआई प्रॉक्सी बनाने की ज़रूरत भी नहीं होती. ध्यान दें कि /**/ का इस्तेमाल नहीं किया जा सकता.

अहम जानकारी: Apigee, बेस पाथ के पहले एलिमेंट के तौर पर, वाइल्डकार्ड "*" का इस्तेमाल नहीं करता है. उदाहरण के लिए, यह काम नहीं करता: /*/search. बेस पाथ को "*" के साथ शुरू करने पर, अचानक गड़बड़ियां हो सकती हैं. ऐसा उस तरीके की वजह से होता है जिससे Edge मान्य पाथ की पहचान करता है.

/ हां
VirtualHost

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

ProxyEndpoint के लिए तय किए गए वर्चुअलहोस्ट, ऐसे डोमेन और पोर्ट तय करते हैं जिन पर एपीआई प्रॉक्सी दिखाई गई है. साथ ही, एक्सटेंशन के हिसाब से वह यूआरएल तय होता है जिसका इस्तेमाल ऐप्लिकेशन, एपीआई प्रॉक्सी को शुरू करने के लिए करते हैं.

डिफ़ॉल्ट रूप से, एनवायरमेंट के लिए दो नाम वाले VirtualHosts तय किए जाते हैं: default और secure. कोई संगठन भी कस्टम डोमेन तय कर सकता है. यह पक्का करने के लिए कि एपीआई प्रॉक्सी सिर्फ़ एचटीटीपीएस पर उपलब्ध हो, उदाहरण के लिए, HTTPProxyConnection में VirtualHost को secure पर सेट करें.

डिफ़ॉल्ट नहीं
Properties वैकल्पिक एचटीटीपी कॉन्फ़िगरेशन सेटिंग के सेट को <ProxyEndpoint> की प्रॉपर्टी के तौर पर बताया जा सकता है. लागू नहीं नहीं
FaultRules
इससे पता चलता है कि ProxyEndpoint किसी गड़बड़ी पर कैसे प्रतिक्रिया देता है. गड़बड़ी का नियम दो आइटम के बारे में बताता है:
  • ऐसी शर्त जो पहले से तय कैटगरी, सबकैटगरी या गड़बड़ी के नाम के आधार पर गड़बड़ी को ठीक करने के बारे में बताती है
  • एक या एक से ज़्यादा ऐसी नीतियां जो यह तय करती हैं कि किसी शर्त से जुड़ी गड़बड़ी के नियम क्या हैं

गड़बड़ियां ठीक करना देखें.

लागू नहीं नहीं
DefaultFaultRule

ऐसी किसी भी गड़बड़ी (सिस्टम, ट्रांसपोर्ट, मैसेज या नीति) को हैंडल करता है जिसे गड़बड़ी के किसी दूसरे नियम से साफ़ तौर पर ठीक नहीं किया जाता.

गड़बड़ियां ठीक करना देखें.

लागू नहीं नहीं
RouteRule ProxyEndpoint अनुरोध की पाइपलाइन से प्रोसेस होने के बाद, इनबाउंड अनुरोध के मैसेज का डेस्टिनेशन तय करता है. आम तौर पर, RouteRule एक नाम वाले TargetEndpoint कॉन्फ़िगरेशन की जानकारी देता है, लेकिन यह सीधे किसी यूआरएल पर भी ले जा सकता है.
Name ज़रूरी एट्रिब्यूट, जिससे RouteRule का नाम दिया गया है. नाम में इस्तेमाल किए जा सकने वाले वर्ण, इन वर्णों तक सीमित हैं: A-Za-z0-9._\-$ %. उदाहरण के लिए, Cat2 %_ एक कानूनी नाम है. लागू नहीं हां
Condition यह एक वैकल्पिक कंडीशनल स्टेटमेंट है, जिसका इस्तेमाल रनटाइम पर डाइनैमिक रूटिंग के लिए किया जाता है. शर्त वाले Routeरूल का इस्तेमाल किया जा सकता है. उदाहरण के लिए, बैकएंड वर्शनिंग के लिए कॉन्टेंट-आधारित रूटिंग को चालू करने के लिए. लागू नहीं नहीं
TargetEndpoint

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

TargetEndpoint को कोई नाम देकर, आप यह बताते हैं कि अनुरोध मैसेज को ProxyEndpoint के अनुरोध की पाइपलाइन के ज़रिए प्रोसेस किए जाने के बाद कहां फ़ॉरवर्ड किया जाना चाहिए. ध्यान दें कि यह एक वैकल्पिक सेटिंग है.

ProxyEndpoint किसी यूआरएल को सीधे कॉल कर सकता है. उदाहरण के लिए, एचटीटीपी क्लाइंट की भूमिका में काम करने वाला JavaScript या Java रिसॉर्स, TargetEndpoint की बुनियादी ज़िम्मेदारी पूरी कर सकता है, जो किसी बैकएंड सेवा पर अनुरोध भेजता है.

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

रूटरूल को कॉन्फ़िगर करने का तरीका

नाम का TargetEndpoint, /apiproxy/targets के तहत बनाई गई ऐसी कॉन्फ़िगरेशन फ़ाइल होता है जिस पर Route Rules के लिए अनुरोध को फ़ॉरवर्ड किया जाता है. इसके लिए, ProxyEndpoint को प्रोसेस किया जाता है.

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

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

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

<RouteRule name="GoNowhere"/>

शर्त के साथ शून्य वाले रूट काम के हो सकते हैं. नीचे दिए गए उदाहरण में, एचटीटीपी हेडर request.header.X-DoNothing में null के अलावा कोई दूसरी वैल्यू होने पर शून्य रूट को लागू करने के लिए कॉन्फ़िगर किया गया है.

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

याद रखें, Routeनियमों की चेन बनाई जा सकती है, इसलिए कंडीशनल नल रूट, कंडीशनल रूटिंग के साथ काम करने के लिए डिज़ाइन किए गए 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
name TargetEndpoint का नाम है, जो एपीआई प्रॉक्सी कॉन्फ़िगरेशन में यूनीक होना चाहिए. किसी वेबसाइट पर जाने से पहले, सीधे तौर पर आउटबाउंड प्रोसेसिंग के अनुरोध करने के लिए, प्रॉक्सीEndpoint रास्ते के नियम में TargetEndPoint के नाम का इस्तेमाल किया जाता है. नाम में इस्तेमाल किए जा सकने वाले वर्ण, इन वर्णों तक सीमित हैं: A-Za-z0-9._\-$ %. लागू नहीं हां
PreFlow यह नीति किसी अनुरोध या जवाब के PreFlow फ़्लो में नीतियों के बारे में बताती है. लागू नहीं हां
Flows
किसी अनुरोध या जवाब के कंडीशनल फ़्लो में नीतियों के बारे में बताता है.
लागू नहीं हां
PostFlow
यह नीति किसी अनुरोध या जवाब के PostFlow फ़्लो में नीतियों के बारे में बताती है.
लागू नहीं हां
HTTPTargetConnection

अपने चाइल्ड एलिमेंट के साथ यह एचटीटीपी के ज़रिए बैकएंड रिसॉर्स पहुंच के बारे में बताता है.

अगर HTTPTargetConnection का इस्तेमाल किया जाता है, तो दूसरी तरह के टारगेट कनेक्शन (ScriptTarget या LocalTargetConnection) को कॉन्फ़िगर न करें.

URL उस बैकएंड सेवा के नेटवर्क पते के बारे में बताता है जिस पर TargetEndpoint मैसेज का अनुरोध भेजता है. लागू नहीं नहीं
LoadBalancer

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

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

सभी बैकएंड सर्वर पर लोड बैलेंसिंग देखें.

लागू नहीं नहीं
Properties वैकल्पिक एचटीटीपी कॉन्फ़िगरेशन सेटिंग के सेट को <TargetEndpoint> की प्रॉपर्टी के तौर पर बताया जा सकता है. लागू नहीं नहीं
SSLInfo इसके अलावा, API प्रॉक्सी और टारगेट सेवा के बीच TLS/SSL कनेक्शन को कंट्रोल करने के लिए, TargetEndpoint पर TLS/एसएसएल सेटिंग तय करें. TLS/SSL TargetEndpoint कॉन्फ़िगरेशन देखें. लागू नहीं नहीं
LocalTargetConnection अपने चाइल्ड एलिमेंट की मदद से, यह तय करता है कि किस संसाधन तक स्थानीय तौर पर पहुंचा जा सकता है. ऐसा करके, लोड बैलेंसिंग और मैसेज प्रोसेसर जैसी नेटवर्क की विशेषताओं को नज़रअंदाज़ किया जाता है.

टारगेट रिसॉर्स तय करने के लिए, APIप्रॉक्सी चाइल्ड एलिमेंट (ProxyEndpoint एलिमेंट के साथ) या पाथ चाइल्ड एलिमेंट शामिल करें.

ज़्यादा जानकारी के लिए, Chaining API प्रॉक्सी एक साथ देखें.

अगर LocalTargetConnection का इस्तेमाल किया जाता है, तो दूसरी तरह के टारगेट कनेक्शन (HTTPTargetConnection या ScriptTarget) को कॉन्फ़िगर न करें.

APIProxy अनुरोधों के टारगेट के तौर पर इस्तेमाल करने के लिए, एपीआई प्रॉक्सी का नाम बताता है. टारगेट प्रॉक्सी उसी संगठन और एनवायरमेंट में होना चाहिए जिसमें प्रॉक्सी भेजने वाला अनुरोध करता है. यह पाथ एलिमेंट का इस्तेमाल करने का एक विकल्प है. लागू नहीं नहीं
ProxyEndpoint टारगेट प्रॉक्सी के ProxyEndpoint का नाम बताने के लिए, APIProxy के साथ इस्तेमाल किया जाता है. लागू नहीं नहीं
Path यह अनुरोधों के टारगेट के तौर पर इस्तेमाल करने के लिए, एपीआई प्रॉक्सी का एंडपॉइंट पाथ तय करती है. टारगेट प्रॉक्सी, उसी संगठन और एनवायरमेंट में होना चाहिए जिसमें प्रॉक्सी मैसेज भेजने वाला है. यह APIप्रॉक्सी का इस्तेमाल करने का एक विकल्प है. लागू नहीं नहीं
FaultRules
इससे तय होता है कि TargetEndpoint किसी गड़बड़ी पर कैसे प्रतिक्रिया देता है. गड़बड़ी का नियम दो आइटम के बारे में बताता है:
  • ऐसी शर्त जो पहले से तय कैटगरी, सबकैटगरी या गड़बड़ी के नाम के आधार पर गड़बड़ी को ठीक करने के बारे में बताती है
  • एक या एक से ज़्यादा ऐसी नीतियां जो यह तय करती हैं कि किसी शर्त से जुड़ी गड़बड़ी के नियम क्या हैं

गड़बड़ियां ठीक करना देखें.

लागू नहीं नहीं
DefaultFaultRule

ऐसी सभी गड़बड़ियों (सिस्टम, ट्रांसपोर्ट, मैसेज सेवा या नीति) को हैंडल करता है जिन्हें किसी अन्य फ़ॉल्टरूल के ज़रिए साफ़ तौर पर ठीक नहीं किया जाता है.

गड़बड़ियां ठीक करना देखें.

लागू नहीं नहीं
ScriptTarget
ResourceURL

यह रिसॉर्स टाइप (नोड) और मुख्य Node.js स्क्रिप्ट का नाम बताता है, जो TargetEndpoint की सुविधा को लागू करती है.

<ResourceURL>node://server.js</ResourceURL>

स्क्रिप्ट को आपके एपीआई प्रॉक्सी की संसाधन फ़ाइलों के साथ शामिल करना ज़रूरी है. किसी मौजूदा एपीआई प्रॉक्सी में Node.js जोड़ना लेख देखें.

अगर ScriptTarget का इस्तेमाल किया जाता है, तो दूसरी तरह के टारगेट कनेक्शन (HTTPTargetConnection या LocalTargetConnection) को कॉन्फ़िगर न करें.

लागू नहीं हां
EnvironmentVariable

विकल्प के तौर पर, एनवायरमेंट वैरिएबल को मुख्य Node.js स्क्रिप्ट पर पास करें.

Node.js मॉड्यूल के लिए Edge की सुविधा के बारे में जानकारी लेख पढ़ें.

लागू नहीं नहीं
Arguments

वैकल्पिक रूप से, मुख्य Node.js स्क्रिप्ट पर आर्ग्युमेंट पास करें.

Node.js मॉड्यूल के लिए Edge की सुविधा के बारे में जानकारी लेख पढ़ें.

लागू नहीं नहीं

TLS/SSL TargetEndpoint कॉन्फ़िगरेशन

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

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

नाम जानकारी डिफ़ॉल्ट ज़रूरी है?
SSLInfo
Enabled यह बताता है कि एंडपॉइंट के लिए TLS/एसएसएल चालू है या नहीं. अगर <URL> एचटीटीपीएस प्रोटोकॉल के बारे में बताता है, तो डिफ़ॉल्ट वैल्यू true है और अगर <URL> एचटीटीपी के बारे में बताता है, तो false. अगर <URL> एचटीटीपीएस के बारे में बताता है, तो सही होता है नहीं
TrustStore भरोसेमंद सर्वर सर्टिफ़िकेट वाला कीस्टोर. लागू नहीं नहीं
ClientAuthEnabled ऐसी सेटिंग जो आउटबाउंड क्लाइंट की पुष्टि करने की सुविधा (2-वे TLS/एसएसएल) चालू करती है false नहीं
KeyStore आउटबाउंड क्लाइंट की पुष्टि करने के लिए इस्तेमाल होने वाली निजी कुंजियों वाला कीस्टोर लागू नहीं हां (अगर ClientAuthEnabled सही है)
KeyAlias आउटबाउंड क्लाइंट की पुष्टि करने के लिए इस्तेमाल किए जाने वाले निजी पासकोड का अन्य नाम लागू नहीं हां (अगर ClientAuthEnabled सही है)
Ciphers

आउटबाउंड TLS/एसएसएल के लिए, इस्तेमाल किए जा सकने वाले साइफ़र. अगर कोई साइफ़र तय नहीं किया गया है, तो जेवीएम के लिए उपलब्ध सभी साइफ़र को अनुमति दी जाएगी.

साइफ़र को प्रतिबंधित करने के लिए, इस्तेमाल किए जा सकने वाले साइफ़र की सूची में नीचे दिए गए एलिमेंट जोड़ें:

<Ciphers>
 <Cipher>TLS_RSA_WITH_3DES_EDE_CBC_SHA</Cipher>    
 <Cipher>TLS_RSA_WITH_DES_CBC_SHA</Cipher>
</Ciphers>
लागू नहीं नहीं
Protocols

आउटबाउंड TLS/एसएसएल के लिए काम करने वाले प्रोटोकॉल. अगर कोई प्रोटोकॉल तय नहीं किया गया है, तो JVM के लिए उपलब्ध सभी प्रोटोकॉल को अनुमति दी जाएगी.

प्रोटोकॉल पर पाबंदी लगाने के लिए, काम करने वाले प्रोटोकॉल की सूची में ये एलिमेंट जोड़ें:

<Protocols>
 <Protocol>TLSv1.1</Protocol>
 <Protocol>TLSv1.2</Protocol>
</Protocols>
लागू नहीं नहीं
CommonName

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

डिफ़ॉल्ट रूप से बताई गई वैल्यू, टारगेट सर्टिफ़िकेट के सामान्य नाम से एग्ज़ैक्ट मैच करती है. उदाहरण के लिए, <CommonName> की वैल्यू के तौर पर *.myhost.com का इस्तेमाल करने से, टारगेट होस्टनेम की पुष्टि सिर्फ़ तब होगी, जब टारगेट सर्टिफ़िकेट में सटीक वैल्यू *.myhost.com को सामान्य नाम के तौर पर दिखाया गया हो.

इसके अलावा, Apigee, wildcardMatch एट्रिब्यूट का इस्तेमाल करके, वाइल्डकार्ड की मदद से मैच कर सकता है.

उदाहरण के लिए, टारगेट सर्टिफ़िकेट में abc.myhost.com के तौर पर दिए गए सामान्य नाम का मिलान होने और उसकी पुष्टि की जाएगी. ऐसा तब होगा, जब <CommonName> एलिमेंट की जानकारी इस तरह दी गई हो:

<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 से बैकएंड (Cloud और Private Cloud) में TLS को कॉन्फ़िगर करना देखें.

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

रनटाइम की सुविधाजनक शर्तों का समर्थन करने के लिए, TLS/एसएसएल की जानकारी को डाइनैमिक तौर पर भी सेट किया जा सकता है. उदाहरण के लिए, अगर आपका प्रॉक्सी दो अलग-अलग टारगेट (टेस्ट टारगेट और प्रोडक्शन टारगेट) से कनेक्ट करता है, तो अपने एपीआई प्रॉक्सी से प्रोग्राम के ज़रिए यह पता लगाया जा सकता है कि वह किस नेटवर्क से कॉल कर रहा है. साथ ही, प्रॉक्सी सर्वर को सही कीस्टोर और ट्रस्टस्टोर के लिए डाइनैमिक तौर पर सेट किया जा सकता है. यहां Apigee कम्यूनिटी के लेख में, इस स्थिति के बारे में ज़्यादा जानकारी दी गई है. साथ ही, लागू किए जा सकने वाले एपीआई प्रॉक्सी के उदाहरण दिए गए हैं: https://community.apigee.com/articles/21424/dynamic-sslinfo-for-targetendpoint-using-variable.html.

TargetEndpoint कॉन्फ़िगरेशन में <SSLInfo> टैग को सेट करने के तरीके के बारे में नीचे दिए गए उदाहरण में, रनटाइम के दौरान वैल्यू दी जा सकती हैं. उदाहरण के लिए, Java कॉलआउट, JavaScript नीति या 'मैसेज असाइन करें' नीति से. उन सभी मैसेज वैरिएबल का इस्तेमाल करें जिनमें आपको सेट की जाने वाली वैल्यू हैं.

वैरिएबल की अनुमति सिर्फ़ नीचे दिए गए एलिमेंट में ही दी जा सकती है.

<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/एसएसएल की वैल्यू सेट करने के लिए, रेफ़रंस का इस्तेमाल करना

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

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

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

उदाहरण के लिए, नीचे एक ऐसा 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 एपीआई कॉल का इस्तेमाल करें:

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

Targetएंडपॉइंट, लोड को बैलेंस करने वाले तीन एल्गोरिदम का इस्तेमाल करके, कई नाम वाले TargetServers का इस्तेमाल करके लोड को बैलेंस कर सकते हैं.

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

नीतियां

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

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

नाम जानकारी डिफ़ॉल्ट ज़रूरी है?
Policy
name

नीति का आंतरिक नाम. नाम में इस्तेमाल किए जाने वाले वर्ण, A-Za-z0-9._\-$ % तक सीमित हैं. हालांकि, Edge मैनेजमेंट के यूज़र इंटरफ़ेस (यूआई) में अतिरिक्त पाबंदियां लागू होती हैं. उदाहरण के लिए, उन वर्णों को अपने-आप हटाना जो अक्षर और अंक नहीं हैं.

इसके अलावा, मैनेजमेंट यूज़र इंटरफ़ेस (यूआई) प्रॉक्सी एडिटर में नीति को किसी अलग और आम भाषा के नाम से लेबल करने के लिए, <DisplayName> एलिमेंट का इस्तेमाल करें.

लागू नहीं हां
enabled

नीति लागू करने के लिए, true पर सेट करें.

नीति को "बंद" करने के लिए, false पर सेट करें. अगर नीति किसी फ़्लो से जुड़ी हुई है, तब भी उसे लागू नहीं किया जाएगा.

true नहीं
continueOnError

किसी नीति के काम न करने पर गड़बड़ी दिखाने के लिए, इसे false पर सेट करें. ज़्यादातर नीतियों में, ऐसा व्यवहार की उम्मीद होती है.

किसी नीति के काम न करने के बावजूद, फ़्लो एक्ज़ीक्यूशन जारी रखने के लिए, true पर सेट करें.

false नहीं
async

ध्यान दें: इस एट्रिब्यूट की मदद से, नीति को एसिंक्रोनस तरीके से नहीं चलाया जाता. ज़्यादातर मामलों में, इसे false की डिफ़ॉल्ट वैल्यू के साथ रहने दें.

true पर सेट करने पर, नीति का एक्ज़ीक्यूशन किसी दूसरे थ्रेड पर ऑफ़लोड किया जाता है. इससे मुख्य थ्रेड को खाली छोड़ दिया जाता है, ताकि ज़्यादा अनुरोधों को हैंडल किया जा सके. ऑफ़लाइन प्रोसेसिंग पूरी हो जाने पर, मुख्य थ्रेड वापस आता है और मैसेज फ़्लो को हैंडल करता है. कुछ मामलों में, true पर एक साथ काम करने वाली प्रोसेस को सेट करने से, एपीआई प्रॉक्सी की परफ़ॉर्मेंस बेहतर होती है. हालांकि, एक साथ कई काम न करने वाली फ़ाइलों का इस्तेमाल करने से, बहुत ज़्यादा थ्रेड स्विच करने से परफ़ॉर्मेंस पर बुरा असर पड़ सकता है.

एपीआई प्रॉक्सी में एसिंक्रोनस व्यवहार का इस्तेमाल करने के लिए, JavaScript ऑब्जेक्ट मॉडल देखें.

false नहीं

नीति अटैचमेंट

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

दिखाता है कि क्लाइंट किसी एचटीटीपी सेवा को कॉल कर रहा है. अनुरोध को
  ProxyEndpoint और TargetEndpoint का सामना करना पड़ता है. इन दोनों में नीतियों को ट्रिगर करने वाले चरण शामिल होते हैं. एचटीटीपी सेवा से रिस्पॉन्स मिलने के बाद, रिस्पॉन्स को TargetEndpoint प्रोसेस किया जाता है और फिर क्लाइंट को वापस
 भेजने से पहले ProxyEndpoing की मदद से प्रोसेस किया जाता है. अनुरोध की तरह ही, जवाब को भी नीतियों के हिसाब से कुछ चरणों में प्रोसेस किया जाता है.

जैसा कि ऊपर दिखाया गया है:

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

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

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

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

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

नाम जानकारी डिफ़ॉल्ट ज़रूरी है?
Step
Name इस चरण परिभाषा के मुताबिक लागू की जाने वाली नीति का नाम. लागू नहीं हां
Condition शर्तों वाला स्टेटमेंट, जिससे तय होता है कि नीति लागू है या नहीं. अगर किसी नीति से कोई शर्त जुड़ी है, तो नीति सिर्फ़ तब लागू होती है, जब शर्तों के साथ दिए गए स्टेटमेंट का आकलन सही पर होता है. लागू नहीं नहीं

फ़्लो

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

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

इसके अलावा, आपके पास ProxyEndpoint में PostClientFlow को जोड़ने का विकल्प है, जो अनुरोध करने वाले क्लाइंट ऐप्लिकेशन से रिस्पॉन्स वापस मिलने के बाद काम करता है. इस फ़्लो में सिर्फ़ MessageLogging नीति और Google स्टैकड्राइवर लॉगिंग एक्सटेंशन को अटैच किया जा सकता है. PostClientFlow, एपीआई प्रॉक्सी के इंतज़ार के समय को कम करता है और लॉग करने के लिए जानकारी उपलब्ध कराता है. इसका हिसाब तब तक नहीं लगाया जाता, जब तक क्लाइंट को रिस्पॉन्स वापस नहीं मिल जाता, जैसे कि client.sent.start.timestamp और client.sent.end.timestamp. इस फ़्लो का इस्तेमाल मुख्य रूप से, रिस्पॉन्स मैसेज के शुरू और खत्म होने के टाइमस्टैंप के बीच के टाइम इंटरवल को मापने के लिए किया जाता है.

आसानी से सिखाने का तरीका बताने वाला वीडियो देखें

वीडियो: PostClientFlow में, मैसेज लॉग करने की सुविधा का इस्तेमाल करने के बारे में बताने वाला यह छोटा सा वीडियो देखें.

यहां PostClientFlow का एक उदाहरण दिया गया है. इसमें मैसेज को लॉग करने की नीति अटैच की गई है.

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

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

पाइपलाइन का अनुरोध करें:

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

रिस्पॉन्स पाइपलाइन:

  1. टारगेट रिस्पॉन्स प्रीफ़्लो
  2. टारगेट रिस्पॉन्स के कंडिशनल फ़्लो (ज़रूरी नहीं)
  3. टारगेट रिस्पॉन्स PostFlow
  4. प्रॉक्सी रिस्पॉन्स PreFlow
  5. प्रॉक्सी रिस्पॉन्स कंडीशनल फ़्लो (ज़रूरी नहीं)
  6. प्रॉक्सी रिस्पॉन्स PostFlow
  7. PostClientFlow जवाब (ज़रूरी नहीं)

सिर्फ़ नीति अटैचमेंट वाले फ़्लो को ProxyEndpoint या TargetEndpoint कॉन्फ़िगरेशन में कॉन्फ़िगर किया जाना चाहिए. जब PreFlow या PostFlow की प्रोसेसिंग के दौरान किसी नीति को लागू करने की ज़रूरत होती है, तब PreFlow और PostFlow के बारे में सिर्फ़ 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>   

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

नाम जानकारी डिफ़ॉल्ट ज़रूरी है?
Flow अनुरोध या रिस्पॉन्स प्रोसेस करने की ऐसी पाइपलाइन जिसे ProxyEndpoint या TargetEndpoint की मदद से तय किया गया है
Name फ़्लो का यूनीक नाम. लागू नहीं हां
Condition यह शर्त वाला स्टेटमेंट, जो सही या गलत का आकलन करने के लिए, ज़्यादा वैरिएबल पर आकलन करता है. पहले से तय PreFlow और PostFlow टाइप के अलावा, अन्य सभी फ़्लो को लागू करने के लिए, कोई शर्त तय करनी होगी. लागू नहीं हां
Request अनुरोध के मैसेज की प्रोसेसिंग से जुड़ी पाइपलाइन लागू नहीं नहीं
Response जवाब वाले मैसेज की प्रोसेसिंग से जुड़ी पाइपलाइन लागू नहीं नहीं

चरण प्रोसेस करना

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

इस्तेमाल किए जा सकने वाले रिसॉर्स टाइप के लिए, संसाधन फ़ाइलें देखें.

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

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