Apigee Edge के दस्तावेज़ देखे जा रहे हैं.
Apigee X के दस्तावेज़. जानकारी पर जाएं
Apigee Edge के साथ काम करने वाले डेवलपर के तौर पर, आपको मुख्य डेवलपमेंट से जुड़ी गतिविधियों में, एपीआई प्रॉक्सी को कॉन्फ़िगर करना होगा. ये एपीआई या बैकएंड सेवाओं के लिए प्रॉक्सी के तौर पर काम करते हैं. इस दस्तावेज़ में, एपीआई प्रॉक्सी बनाते समय कॉन्फ़िगरेशन के लिए उपलब्ध सभी एलिमेंट का रेफ़रंस दिया गया है.
अगर आपको एपीआई प्रॉक्सी बनाने का तरीका जानना है, तो हमारा सुझाव है कि आप आसान एपीआई प्रॉक्सी बनाएं विषय से शुरू करें.
प्रॉक्सी कॉन्फ़िगरेशन में बदलाव करने के सबसे सामान्य तरीके ये हैं:
- Edge यूज़र इंटरफ़ेस (यूआई) में एक्सएमएल एडिटर का इस्तेमाल करना
- कॉन्फ़िगरेशन डाउनलोड करें और उसे प्रॉक्सी कॉन्फ़िगरेशन के लोकल डेवलपमेंट में स्थानीय तौर पर बदलें.
प्रॉक्सी कॉन्फ़िगरेशन का लोकल डेवलपमेंट
आप अपने प्रॉक्सी कॉन्फ़िगरेशन डाउनलोड कर सकते हैं, ताकि आप उन्हें किसी लोकल मशीन पर बदल सकें. इसके बाद, Edge पर नतीजे अपलोड करें. इस तरीके से, आपको अपने सोर्स कंट्रोल, वर्शन, और शेयर किए गए अन्य वर्कफ़्लो में प्रॉक्सी कॉन्फ़िगरेशन जोड़ने की सुविधा मिलती है. इसके अलावा, स्थानीय प्रॉक्सी कॉन्फ़िगरेशन पर काम करके, अपने खुद के एक्सएमएल एडिटर और पुष्टि करने वाले टूल का इस्तेमाल किया जा सकता है.
इस सेक्शन में बताया गया है कि मौजूदा प्रॉक्सी कॉन्फ़िगरेशन को डाउनलोड करने के लिए यूज़र इंटरफ़ेस (यूआई) का इस्तेमाल कैसे करें. इसके बाद, उस कॉन्फ़िगरेशन में बदलाव करें और डिप्लॉयमेंट के लिए इसे Edge पर वापस अपलोड कैसे करें. नए प्रॉक्सी कॉन्फ़िगरेशन को डाउनलोड और डिप्लॉय करने के लिए,
apigeetool
भी इस्तेमाल किया जा सकता है. इसके लिए, क्रम से fetchproxy
और
deployproxy
निर्देशों का इस्तेमाल किया जा सकता है.
यूज़र इंटरफ़ेस (यूआई) का इस्तेमाल करके, प्रॉक्सी कॉन्फ़िगरेशन में स्थानीय तौर पर बदलाव करने के लिए:
- Edge यूज़र इंटरफ़ेस (यूआई) में मौजूदा प्रॉक्सी कॉन्फ़िगरेशन डाउनलोड करें. (एपीआई प्रॉक्सी व्यू में, प्रोजेक्ट > डाउनलोड में बदलाव चुनें.)
- अपनी लोकल मशीन पर, एक नई डायरेक्ट्री बनाएं और उसमें डाउनलोड की गई ZIP फ़ाइल को
बड़ा करके देखें.
ZIP फ़ाइल को बड़ा करने के लिए,
unzip
जैसी सुविधा का इस्तेमाल किया जा सकता है. इसका उदाहरण नीचे दिया गया है:mkdir myappdir
unzip ./my-app_app_rev3_2019_04_20.zip -d myappdir
ZIP फ़ाइल का बड़ा किया गया कॉन्टेंट, एपीआई प्रॉक्सी स्ट्रक्चर में बताए गए स्ट्रक्चर से मिलता-जुलता होना चाहिए.
- सोर्स फ़ाइलों में ज़रूरत के मुताबिक बदलाव करें. प्रॉक्सी कॉन्फ़िगरेशन में सोर्स फ़ाइलों की जानकारी के लिए, एपीआई प्रॉक्सी की कॉन्फ़िगरेशन फ़ाइलें और डायरेक्ट्री स्ट्रक्चर देखें.
उदाहरण के लिए, अपने एपीआई प्रॉक्सी में स्वास्थ्य की निगरानी करने की सुविधा चालू करने के लिए,
/apiproxy/targets/
डायरेक्ट्री में TargetEndpoint कॉन्फ़िगरेशन फ़ाइल में बदलाव करें. इस डायरेक्ट्री की डिफ़ॉल्ट फ़ाइलdefault.xml
है. हालांकि, अगर शर्त के साथ टारगेट का इस्तेमाल किया जाता है, तो अलग-अलग नामों वाली फ़ाइलें भी हो सकती हैं.ऐसे मामले में, अगर TargetEndpoint कॉन्फ़िगरेशन फ़ाइल और उसकी डायरेक्ट्री मौजूद नहीं है, तो उन्हें बनाएं.
- प्रॉक्सी कॉन्फ़िगरेशन वाली फ़ाइलों में बदलाव करने के बाद, बदलावों को सेव करना न भूलें.
- उस नई डायरेक्ट्री में बदलें जिसे आपने ZIP फ़ाइलों (बड़े की गई कॉन्फ़िगरेशन फ़ाइलों का रूट) को बड़ा करते समय बनाया था.
उदाहरण के लिए, अगर आपने फ़ाइलों को
/myappdir
डायरेक्ट्री में बड़ा किया है, तो उस डायरेक्ट्री का इस्तेमाल करें, जैसा कि इस उदाहरण में दिखाया गया है:cd myappdir
अपनी प्रॉक्सी कॉन्फ़िगरेशन फ़ाइलों को फिर से संग्रहित करने से पहले, आपको इस डायरेक्ट्री में बदलाव करना चाहिए, क्योंकि आप नहीं चाहते कि
/myappdir
डायरेक्ट्री को ZIP फ़ाइल में शामिल किया जाए. ZIP फ़ाइल में टॉप-लेवल की डायरेक्ट्री/apiproxy
होनी चाहिए. - नई या बदली गई फ़ाइलों के साथ-साथ प्रॉक्सी कॉन्फ़िगरेशन की फ़ाइलों को फिर से संग्रहित करें. आप
zip
जैसी किसी सुविधा का इस्तेमाल कर सकते हैं, जैसा कि नीचे दिए गए उदाहरण में बताया गया है:zip my-new-proxy.zip -r .
ZIP फ़ाइल में टॉप-लेवल की डायरेक्ट्री
/apiproxy
होनी चाहिए.ZIP फ़ाइल नाम के लिए कोई खास ज़रूरत नहीं है. उदाहरण के लिए, आपको फ़ाइल के नाम में बदलाव की संख्या बढ़ाने या तारीख बताने की ज़रूरत नहीं है. हालांकि, ऐसा करना, डीबग करने या सोर्स कंट्रोल करने में काम आ सकता है.
जब आप नए प्रॉक्सी कॉन्फ़िगरेशन को अपलोड करते हैं, तो Edge आपके लिए बदलाव की संख्या बढ़ा देता है.
- Edge यूज़र इंटरफ़ेस (यूआई) का इस्तेमाल करके, नया प्रॉक्सी कॉन्फ़िगरेशन अपलोड करें. (एपीआई प्रॉक्सी व्यू में, प्रोजेक्ट > नया बदलाव अपलोड करें चुनें.)
अगर आपको Bundle is invalid. Empty bundle. जैसी गड़बड़ी मिलती है, तो पक्का करें कि आपकी ZIP फ़ाइल की टॉप-लेवल की डायरेक्ट्री
/apiproxy
हो. अगर ऐसा नहीं है, तो बड़ी की गई डायरेक्ट्री के रूट में से अपनी प्रॉक्सी कॉन्फ़िगरेशन फ़ाइलों को फिर से संग्रहित करें.अपना नया प्रॉक्सी कॉन्फ़िगरेशन अपलोड करने के बाद, Edge रिविज़न की संख्या बढ़ाता है और इसे बदलावों की खास जानकारी व्यू में दिखाता है.
यूज़र इंटरफ़ेस (यूआई) के साथ अपलोड करने के बाद, Edge आपके लिए नया वर्शन डिप्लॉय नहीं करता.
- अपने नए वर्शन को डिप्लॉय करें.
ज़्यादा जानकारी के लिए, Apigee Community में, ट्यूटोरियल: यूज़र इंटरफ़ेस (यूआई) और मैनेजमेंट एपीआई का इस्तेमाल करके प्रॉक्सी डाउनलोड करने का तरीका देखें.
एपीआई प्रॉक्सी स्ट्रक्चर
एपीआई प्रॉक्सी में ये कॉन्फ़िगरेशन होते हैं:
बेस कॉन्फ़िगरेशन | एपीआई प्रॉक्सी के लिए मुख्य कॉन्फ़िगरेशन सेटिंग. बुनियादी कॉन्फ़िगरेशन देखें. |
प्रॉक्सीEndpoint कॉन्फ़िगरेशन | इनबाउंड एचटीटीपी कनेक्शन (ऐप्लिकेशन का अनुरोध करने से लेकर Apigee Edge तक), अनुरोध और रिस्पॉन्स फ़्लो, और नीति के अटैचमेंट की सेटिंग. ProxyEndpoint देखें. |
TargetEndpoint कॉन्फ़िगरेशन | आउटबाउंड एचटीटीपी कनेक्शन (Apigee Edge से लेकर बैकएंड सेवा तक), अनुरोध और रिस्पॉन्स फ़्लो, और नीति के अटैचमेंट की सेटिंग. TargetEndpoint देखें. |
फ़्लो | ProxyEndpoint और TargetEndpoint का अनुरोध और रिस्पॉन्स पाइपलाइन, जिनसे नीतियां जोड़ी जा सकती हैं. फ़्लो देखें. |
नीतियां | एक्सएमएल फ़ॉर्मैट की ऐसी कॉन्फ़िगरेशन फ़ाइलें जो Apigee Edge की नीति के स्कीमा के मुताबिक हों. नीतियां देखें. |
संसाधन | कस्टम लॉजिक लागू करने के लिए, नीतियों में रेफ़र की गई स्क्रिप्ट, JAR फ़ाइलें, और XSLT फ़ाइलें. संसाधन देखें. |
एपीआई प्रॉक्सी डायरेक्ट्री का स्ट्रक्चर और उसका कॉन्टेंट
ऊपर दी गई टेबल में कॉम्पोनेंट, नीचे दी गई डायरेक्ट्री की कॉन्फ़िगरेशन फ़ाइलों से तय किए जाते हैं:
एपीआई प्रॉक्सी का कॉन्फ़िगरेशन फ़ाइलें और डायरेक्ट्री स्ट्रक्चर
इस सेक्शन में, एपीआई प्रॉक्सी की कॉन्फ़िगरेशन फ़ाइलों और डायरेक्ट्री के स्ट्रक्चर के बारे में बताया गया है.
बेस कॉन्फ़िगरेशन
/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 एक यूआरआई फ़्रैगमेंट (उदाहरण के लिए, बेस पाथ में वाइल्डकार्ड का इस्तेमाल करना एपीआई प्रॉक्सी बेस पाथ में एक या उससे ज़्यादा "*" वाइल्डकार्ड का इस्तेमाल किया जा सकता है. उदाहरण के लिए, अहम जानकारी: Apigee, बेस पाथ के पहले
एलिमेंट के तौर पर, वाइल्डकार्ड "*" का इस्तेमाल नहीं करता है. उदाहरण के लिए, यह काम नहीं करता: |
/ | हां |
VirtualHost |
किसी एनवायरमेंट के लिए खास बेस यूआरएल के साथ एपीआई प्रॉक्सी को जोड़ता है. वर्चुअलहोस्ट, नाम का एक कॉन्फ़िगरेशन होता है, जो किसी एनवायरमेंट के लिए एक या एक से ज़्यादा यूआरएल के बारे में जानकारी देता है. ProxyEndpoint के लिए तय किए गए वर्चुअलहोस्ट, ऐसे डोमेन और पोर्ट तय करते हैं जिन पर एपीआई प्रॉक्सी दिखाई गई है. साथ ही, एक्सटेंशन के हिसाब से वह यूआरएल तय होता है जिसका इस्तेमाल ऐप्लिकेशन, एपीआई प्रॉक्सी को शुरू करने के लिए करते हैं. डिफ़ॉल्ट रूप से, एनवायरमेंट के लिए दो नाम वाले VirtualHosts तय किए जाते हैं:
|
डिफ़ॉल्ट | नहीं |
Properties |
वैकल्पिक एचटीटीपी कॉन्फ़िगरेशन सेटिंग के सेट को
<ProxyEndpoint> की प्रॉपर्टी के तौर पर बताया जा सकता है. |
लागू नहीं | नहीं |
FaultRules |
इससे पता चलता है कि ProxyEndpoint किसी गड़बड़ी पर कैसे प्रतिक्रिया देता है. गड़बड़ी का नियम दो आइटम के बारे में
बताता है:
गड़बड़ियां ठीक करना देखें. |
लागू नहीं | नहीं |
DefaultFaultRule |
ऐसी किसी भी गड़बड़ी (सिस्टम, ट्रांसपोर्ट, मैसेज या नीति) को हैंडल करता है जिसे गड़बड़ी के किसी दूसरे नियम से साफ़ तौर पर ठीक नहीं किया जाता. गड़बड़ियां ठीक करना देखें. |
लागू नहीं | नहीं |
RouteRule |
ProxyEndpoint अनुरोध की पाइपलाइन से प्रोसेस होने के बाद, इनबाउंड अनुरोध के मैसेज का डेस्टिनेशन तय करता है. आम तौर पर, RouteRule एक नाम वाले TargetEndpoint कॉन्फ़िगरेशन की जानकारी देता है, लेकिन यह सीधे किसी यूआरएल पर भी ले जा सकता है. | ||
Name |
ज़रूरी एट्रिब्यूट, जिससे RouteRule का नाम दिया गया है. नाम में इस्तेमाल किए जा सकने वाले वर्ण, इन वर्णों तक सीमित हैं: A-Za-z0-9._\-$ % . उदाहरण के लिए, Cat2 %_ एक कानूनी नाम है. |
लागू नहीं | हां |
Condition |
यह एक वैकल्पिक कंडीशनल स्टेटमेंट है, जिसका इस्तेमाल रनटाइम पर डाइनैमिक रूटिंग के लिए किया जाता है. शर्त वाले Routeरूल का इस्तेमाल किया जा सकता है. उदाहरण के लिए, बैकएंड वर्शनिंग के लिए कॉन्टेंट-आधारित रूटिंग को चालू करने के लिए. | लागू नहीं | नहीं |
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 की सुविधा को लागू करती है.
स्क्रिप्ट को आपके एपीआई प्रॉक्सी की संसाधन फ़ाइलों के साथ शामिल करना ज़रूरी है. किसी मौजूदा एपीआई प्रॉक्सी में 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> की वैल्यू के तौर पर इसके अलावा, Apigee, उदाहरण के लिए, टारगेट सर्टिफ़िकेट में <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 |
नीति का आंतरिक नाम. नाम में इस्तेमाल किए जाने वाले वर्ण,
इसके अलावा, मैनेजमेंट यूज़र इंटरफ़ेस (यूआई) प्रॉक्सी एडिटर में नीति को किसी अलग और आम भाषा के नाम से लेबल करने के लिए, |
लागू नहीं | हां |
enabled |
नीति लागू करने के लिए, नीति को "बंद" करने के लिए, |
true | नहीं |
continueOnError |
किसी नीति के काम न करने पर गड़बड़ी दिखाने के लिए, इसे किसी नीति के काम न करने के बावजूद, फ़्लो एक्ज़ीक्यूशन जारी रखने के लिए, |
false | नहीं |
async |
ध्यान दें: इस एट्रिब्यूट की मदद से, नीति को एसिंक्रोनस तरीके से नहीं चलाया जाता.
ज़्यादातर मामलों में, इसे
एपीआई प्रॉक्सी में एसिंक्रोनस व्यवहार का इस्तेमाल करने के लिए, JavaScript ऑब्जेक्ट मॉडल देखें. |
false | नहीं |
नीति अटैचमेंट
इस इमेज में, एपीआई के प्रॉक्सी फ़्लो को लागू करने का क्रम दिखाया गया है:
जैसा कि ऊपर दिखाया गया है:
फ़्लो प्रोसेस करने के तरीके के तौर पर नीतियां अटैच की गई हैं. नीति के नाम का इस्तेमाल, उस नीति के बारे में बताने के लिए किया जाता है जिसे लागू करने की प्रोसेस के चरण के तौर पर बताया गया है. नीति अटैचमेंट का फ़ॉर्मैट इस तरह है:
<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> ...
एपीआई प्रॉक्सी प्रोसेसिंग पाइपलाइन नीचे बताए गए क्रम में फ़्लो एक्ज़ीक्यूट करती है:
पाइपलाइन का अनुरोध करें:
- प्रॉक्सी अनुरोध PreFlow
- प्रॉक्सी अनुरोध के कंडिशनल फ़्लो (ज़रूरी नहीं)
- प्रॉक्सी अनुरोध PostFlow
- टारगेट अनुरोध प्रीफ़्लो
- टारगेट के लिए कंडिशनल फ़्लो (ज़रूरी नहीं)
- टारगेट अनुरोध PostFlow
रिस्पॉन्स पाइपलाइन:
- टारगेट रिस्पॉन्स प्रीफ़्लो
- टारगेट रिस्पॉन्स के कंडिशनल फ़्लो (ज़रूरी नहीं)
- टारगेट रिस्पॉन्स PostFlow
- प्रॉक्सी रिस्पॉन्स PreFlow
- प्रॉक्सी रिस्पॉन्स कंडीशनल फ़्लो (ज़रूरी नहीं)
- प्रॉक्सी रिस्पॉन्स PostFlow
- 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 ट्रांसफ़ॉर्मेशन होते हैं, जिन्हें नीतियों का इस्तेमाल करके फ़्लो में अटैच किया जा सकता है. ये मैनेजमेंट यूज़र इंटरफ़ेस (यूआई) में एपीआई प्रॉक्सी एडिटर के "स्क्रिप्ट" सेक्शन में दिखती हैं.
इस्तेमाल किए जा सकने वाले रिसॉर्स टाइप के लिए, संसाधन फ़ाइलें देखें.
संसाधनों को एपीआई प्रॉक्सी, किसी एनवायरमेंट या संगठन में सेव किया जा सकता है. हर मामले में, नीति में संसाधन के नाम का इस्तेमाल किया जाता है. एपीआई सेवाएं, एपीआई प्रॉक्सी की जगह एनवायरमेंट से संगठन के लेवल पर जाकर नाम का समाधान करती हैं.
संगठन के लेवल पर सेव किए गए संसाधन को किसी भी एनवायरमेंट में बनी नीतियों से रेफ़र किया जा सकता है. एनवायरमेंट लेवल पर सेव किए गए संसाधन को उस एनवायरमेंट की नीतियों से रेफ़र किया जा सकता है. एपीआई प्रॉक्सी लेवल पर सेव किए गए संसाधन का इस्तेमाल, सिर्फ़ उस एपीआई प्रॉक्सी में मौजूद नीतियों से किया जा सकता है.