आपको Apigee Edge का दस्तावेज़ दिख रहा है.
Apigee X के दस्तावेज़ पर जाएं. जानकारी
क्या
Service Callout नीति की मदद से, अपने एपीआई प्रॉक्सी फ़्लो से किसी दूसरी सेवा को कॉल किया जा सकता है. आपके पास बाहरी सेवा (जैसे कि बाहरी RESTful सेवा एंडपॉइंट) या आंतरिक सेवाओं (जैसे कि एक ही संगठन और एनवायरमेंट में एपीआई प्रॉक्सी) को कॉलआउट करने का विकल्प होता है.
- बाहरी इस्तेमाल के उदाहरण में, तीसरे पक्ष के ऐसे एपीआई को कॉलआउट किया जाता है जो आपके प्रॉक्सी से बाहर का है. तीसरे पक्ष के एपीआई से मिले जवाब को पार्स किया जाता है और आपके एपीआई के जवाब वाले मैसेज में डाला जाता है. इससे, ऐप्लिकेशन के असली उपयोगकर्ताओं के लिए डेटा को बेहतर बनाया जाता है और उसे "मैश अप" किया जाता है. अनुरोध फ़्लो में, सेवा कॉलआउट नीति का इस्तेमाल करके भी अनुरोध किया जा सकता है. इसके बाद, एपीआई प्रॉक्सी के TargetEndpoint को जवाब में जानकारी दी जा सकती है.
- किसी अन्य इस्तेमाल के उदाहरण में, आपको उसी संगठन और एनवायरमेंट में मौजूद किसी प्रॉक्सी को कॉल करना होता है जिसमें मौजूद प्रॉक्सी से कॉल किया जा रहा है. उदाहरण के लिए, यह तब काम आ सकता है, जब आपके पास कोई ऐसा प्रॉक्सी हो जो कुछ अलग-अलग लो-लेवल फ़ंक्शनलिटी उपलब्ध कराता हो और एक या उससे ज़्यादा अन्य प्रॉक्सी उनका इस्तेमाल करते हों. उदाहरण के लिए, बैकएंड डेटा स्टोर के साथ create/read/update/delete ऑपरेशन करने वाली कोई प्रॉक्सी, डेटा को क्लाइंट के सामने लाने वाली कई अन्य प्रॉक्सियों के लिए टारगेट प्रॉक्सी हो सकती है.
यह नीति, एचटीटीपी और एचटीटीपीएस पर किए गए अनुरोधों के साथ काम करती है.
नमूने
किसी इंटरनल प्रॉक्सी को लोकल कॉल करना
<LocalTargetConnection>
<APIProxy>data-manager</APIProxy>
<ProxyEndpoint>default</ProxyEndpoint>
</LocalTargetConnection>इस उदाहरण में, data-manager नाम की लोकल एपीआई प्रॉक्सी (यानी कि एक ही संगठन और एनवायरमेंट में मौजूद) को कॉलआउट बनाया गया है. इसमें, default नाम के प्रॉक्सी एंडपॉइंट के बारे में बताया गया है.
यूआरएल को वैरिएबल के तौर पर इस्तेमाल करना
<HTTPTargetConnection>
<URL>http://example.com/{request.myResourcePath}</URL>
</HTTPTargetConnection>इस उदाहरण में, टारगेट के यूआरएल को डाइनैमिक तरीके से भरने के लिए, यूआरएल में वैरिएबल का इस्तेमाल किया गया है. यूआरएल के प्रोटोकॉल वाले हिस्से, http:// को किसी वैरिएबल से तय नहीं किया जा सकता. साथ ही, आपको यूआरएल के डोमेन वाले हिस्से और बाकी यूआरएल के लिए अलग-अलग वैरिएबल इस्तेमाल करने होंगे.
Google जियोकोडिंग / अनुरोध तय करना
<ServiceCallout name="ServiceCallout-GeocodingRequest1"> <DisplayName>Inline request message</DisplayName> <Request variable="authenticationRequest"> <Set> <QueryParams> <QueryParam name="address">{request.queryparam.postalcode}</QueryParam> <QueryParam name="region">{request.queryparam.country}</QueryParam> <QueryParam name="sensor">false</QueryParam> </QueryParams> </Set> </Request> <Response>GeocodingResponse</Response> <Timeout>30000</Timeout> <HTTPTargetConnection> <URL>http://maps.googleapis.com/maps/api/geocode/json</URL> </HTTPTargetConnection> </ServiceCallout>
http://maps.googleapis.com/maps/api/geocode/json
अनुरोध ऑब्जेक्ट बनाने के लिए, Assign Message जैसी नीति का इस्तेमाल करने के बजाय, इसे सीधे तौर पर Service Callout नीति में तय किया जा सकता है. इस उदाहरण में, सेवा कॉलआउट नीति बाहरी सेवा को पास किए गए तीन क्वेरी पैरामीटर की वैल्यू सेट करती है. सर्विस कॉलआउट नीति में, पूरा अनुरोध मैसेज बनाया जा सकता है. इसमें पेलोड, एन्कोडिंग टाइप (जैसे कि application/xml), हेडर, फ़ॉर्म पैरामीटर वगैरह के बारे में जानकारी दी जाती है.
यहां एक और उदाहरण दिया गया है, जिसमें सेवा के कॉलआउट से जुड़ी नीति का उल्लंघन होने से पहले ही अनुरोध किया गया है.
<ServiceCallout name="ServiceCallout-GeocodingRequest2"> <Request clearPayload="false" variable="GeocodingRequest"/> <Response>GeocodingResponse</Response> <Timeout>30000</Timeout> <HTTPTargetConnection> <URL>http://maps.googleapis.com/maps/api/geocode/json</URL> </HTTPTargetConnection> </ServiceCallout>
अनुरोध के मैसेज का कॉन्टेंट, GeocodingRequest नाम के वैरिएबल से निकाला जाता है. इस वैरिएबल में वैल्यू, AssignMessage नीति के ज़रिए भरी जा सकती है. जवाब के मैसेज को GeocodingResponse नाम के वैरिएबल को असाइन किया जाता है. यहां यह Extract Variables नीति के ज़रिए पार्स किया जा सकता है. इसके अलावा, इसे JavaScript या Java में लिखे गए कस्टम कोड के ज़रिए भी पार्स किया जा सकता है. यह नीति, Google Geocoding API से जवाब मिलने के लिए 30 सेकंड तक इंतज़ार करती है. इसके बाद, यह टाइम आउट हो जाती है.
इस उदाहरण में दिए गए सर्विस कॉलआउट के साथ-साथ, Assign Message और Extract Variables नीतियों का इस्तेमाल करने वाली पूरी एपीआई प्रॉक्सी का सैंपल देखने के लिए, नीति कंपोज़िशन का इस्तेमाल करना लेख पढ़ें.
कॉल टारगेट सर्वर
<ServiceCallout async="false" continueOnError="false" enabled="true" name="service-callout"> <DisplayName>service-callout</DisplayName> <Properties/> <Request clearPayload="true" variable="myRequest"> <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables> </Request> <Response>myResponse</Response> <HTTPTargetConnection> <LoadBalancer> <Algorithm>RoundRobin</Algorithm> <Server name="httpbin"/> <Server name="yahoo"/> </LoadBalancer> <Path>/get</Path> </HTTPTargetConnection> </ServiceCallout>
यह नीति, टारगेट सर्वर को कॉल करने और उन पर लोड बैलेंसिंग करने के लिए, LoadBalancer एट्रिब्यूट का इस्तेमाल करती है. इस उदाहरण में, लोड को "httpbin" और "yahoo" नाम के दो टारगेट सर्वर के बीच बांटा गया है. अपनी प्रॉक्सी के लिए टारगेट सर्वर सेट अप करने और लोड बैलेंसिंग को कॉन्फ़िगर करने के बारे में जानकारी के लिए, बैकएंड सर्वर के बीच लोड बैलेंसिंग लेख पढ़ें.
सेवा कॉलआउट एक्सटेंशन से जुड़ी नीति के बारे में जानकारी
ऐसे कई उदाहरण हैं जहां एपीआई प्रॉक्सी में, सेवा कॉलआउट नीति का इस्तेमाल किया जा सकता है. उदाहरण के लिए, एपीआई प्रॉक्सी को कॉन्फ़िगर करके, बाहरी सेवा को कॉल किया जा सकता है. इससे भौगोलिक स्थान का डेटा, खरीदार की समीक्षाएं, पार्टनर के खुदरा कैटलॉग के आइटम वगैरह डिलीवर किए जा सकते हैं.
आम तौर पर, कॉलआउट का इस्तेमाल दो अन्य नीतियों के साथ किया जाता है: मैसेज असाइन करना और वैरिएबल निकालना.
- अनुरोध: Assign Message, रिमोट सेवा को भेजे गए अनुरोध वाले मैसेज को पॉप्युलेट करता है.
-
जवाब: Extract Variables नीति, जवाब को पार्स करती है और खास कॉन्टेंट निकालती है.
सेवा कॉलआउट की नीति में आम तौर पर ये चीज़ें शामिल होती हैं:
- मैसेज की नीति असाइन करना: यह अनुरोध मैसेज बनाता है, एचटीटीपी हेडर और क्वेरी पैरामीटर भरता है, एचटीटीपी वर्ब सेट करता है वगैरह.
- Service Callout नीति: यह Assign Message नीति से बनाए गए मैसेज का रेफ़रंस देती है. साथ ही, यह बाहरी कॉल के लिए टारगेट यूआरएल और टारगेट सेवा से मिले जवाब ऑब्जेक्ट के लिए नाम तय करती है.
बेहतर परफ़ॉर्मेंस के लिए, Service Callout के जवाबों को भी कैश मेमोरी में सेव किया जा सकता है. इसके बारे में Apigee Community के इस थ्रेड में बताया गया है: How can I store the results of the ServiceCallout policy in cache and later retrieve it from cache?. - Extract Variables policy: आम तौर पर, यह JSONPath या XPath एक्सप्रेशन को तय करता है. यह एक्सप्रेशन, Service Callout से जनरेट हुए मैसेज को पार्स करता है. इसके बाद, नीति ऐसे वैरिएबल सेट करती है जिनमें सर्विस कॉलआउट के रिस्पॉन्स से पार्स की गई वैल्यू शामिल होती हैं.
Service Callout नीति के साथ-साथ Assign Message और Extract Variables नीतियों का इस्तेमाल करने वाली पूरी एपीआई प्रॉक्सी का सैंपल देखने के लिए, नीति कंपोज़िशन का इस्तेमाल करना लेख पढ़ें.
गड़बड़ी को ठीक करने के लिए कस्टम कोड
एलिमेंट का रेफ़रंस
इस नीति के लिए, इन एलिमेंट और एट्रिब्यूट को कॉन्फ़िगर किया जा सकता है:
<ServiceCallout async="false" continueOnError="false" enabled="true" name="Service-Callout-1"> <DisplayName>Custom label used in UI</DisplayName> <Request clearPayload="true" variable="myRequest"> <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables> <Remove> <ReasonPhrase/> <StatusCode/> <Path/> <Version/> <Verb/> </Remove> <Copy> <ReasonPhrase/> <StatusCode/> <Path/> <Version/> <Verb/> </Copy> <Add> <Headers/> <QueryParams/> <FormParams/> </Add> <Set> <Headers/> <QueryParams/> <FormParams/> <Payload/> <ReasonPhrase/> <StatusCode/> <Path/> <Version/> <Verb/> </Set> </Request> <Response>calloutResponse</Response> <Timeout>30000</Timeout> <HTTPTargetConnection> <URL>http://example.com</URL> <LoadBalancer/> <SSLInfo/> <Properties/> </HTTPTargetConnection> <LocalTargetConnection> <APIProxy/> <ProxyEndpoint/> <Path/> </LocalTargetConnection> </ServiceCallout>
<ServiceCallout> एट्रिब्यूट
<ServiceCallout async="false" continueOnError="false" enabled="true" name="Service-Callout-1">
यहां दी गई टेबल में, ऐसे एट्रिब्यूट के बारे में बताया गया है जो नीति के सभी पैरंट एलिमेंट में एक जैसे होते हैं:
| एट्रिब्यूट | ब्यौरा | डिफ़ॉल्ट | मौजूदगी |
|---|---|---|---|
name |
नीति का अंदरूनी नाम. इसके अलावा, नीति को लेबल करने के लिए, |
लागू नहीं | ज़रूरी है |
continueOnError |
किसी नीति के काम न करने पर, गड़बड़ी दिखाने के लिए नीति के लागू होने के बाद भी फ़्लो को एक्ज़ीक्यूट करने के लिए, इसे |
गलत | वैकल्पिक |
enabled |
नीति को लागू करने के लिए, नीति को बंद करने के लिए, |
सही | वैकल्पिक |
async |
यह एट्रिब्यूट अब काम नहीं करता. |
गलत | बहिष्कृत |
<DisplayName> एलिमेंट
इस कॉलम में नीति को लेबल करने के लिए, name एट्रिब्यूट के साथ-साथ इस्तेमाल करें
मैनेजमेंट यूज़र इंटरफ़ेस (यूआई) प्रॉक्सी एडिटर, जिसका नाम अलग और सामान्य भाषा में है.
<DisplayName>Policy Display Name</DisplayName>
| डिफ़ॉल्ट |
लागू नहीं अगर आप इस एलिमेंट को छोड़ देते हैं, तो नीति की |
|---|---|
| मौजूदगी | वैकल्पिक |
| टाइप | स्ट्रिंग |
<Request> एलिमेंट
यह उस वैरिएबल के बारे में बताता है जिसमें अनुरोध का वह मैसेज होता है जिसे एपीआई प्रॉक्सी से दूसरी सेवा को भेजा जाता है. इस वैरिएबल को फ़्लो में मौजूद पिछली नीति के ज़रिए बनाया जा सकता है. इसके अलावा, इसे सेवा के बारे में कॉलआउट करने से जुड़ी नीति में इनलाइन भी बनाया जा सकता है.
<Request clearPayload="true" variable="myRequest"> <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables> <Remove> <ReasonPhrase/> <StatusCode/> <Path/> <Version/> <Verb/> </Remove> <Copy> <ReasonPhrase/> <StatusCode/> <Path/> <Version/> <Verb/> </Copy> <Add> <Headers/> <QueryParams/> <FormParams/> </Add> <Set> <Headers/> <QueryParams/> <FormParams/> <Payload/> <ReasonPhrase/> <StatusCode/> <Path/> <Version/> <Verb/> </Set> </Request>
<Remove>, <Copy>, <Add>, और <Set> टैग का सिंटैक्स, Assign Message policy के सिंटैक्स जैसा ही होता है.
अगर अनुरोध के मैसेज को हल नहीं किया जा सकता या वह अनुरोध के मैसेज के अमान्य टाइप का है, तो नीति गड़बड़ी का मैसेज दिखाती है.
सबसे आसान उदाहरण में, अनुरोध का वह मैसेज पास किया जाता है जिसे एपीआई प्रॉक्सी के फ़्लो में पहले ही भर दिया गया था:
<Request clearPayload="true" variable="myRequest"/>
इसके अलावा, बाहरी सेवा को भेजे गए अनुरोध के मैसेज को, सेवा के बारे में ज़्यादा जानकारी देने वाली सुविधा की नीति में भी भरा जा सकता है:
<Request> <Set> <Headers> <Header name="Accept">application/json</Header> </Headers> <Verb>POST</Verb> <Payload contentType="application/json">{"message":"my test message"}</Payload> </Set> <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables> </Request>
| डिफ़ॉल्ट | अगर आपने Request एलिमेंट या उसके किसी एट्रिब्यूट को शामिल नहीं किया है, तो Edge इन डिफ़ॉल्ट वैल्यू को असाइन करता है:
<Request clearPayload="true" variable="servicecallout.request"/> आइए, देखते हैं कि इन डिफ़ॉल्ट वैल्यू का क्या मतलब है. सबसे पहले,
अगर डेटा मास्किंग का इस्तेमाल किया जा रहा है, तो इस डिफ़ॉल्ट नाम के बारे में जानना ज़रूरी है. अगर आपने वैरिएबल का नाम नहीं डाला है, तो आपको अपने मास्क कॉन्फ़िगरेशन में |
| उपलब्धता | ज़रूरी नहीं. |
| समस्या | लागू नहीं |
विशेषताएं
| एट्रिब्यूट | ब्यौरा | डिफ़ॉल्ट | मौजूदगी |
|---|---|---|---|
| variable |
उस वैरिएबल का नाम जिसमें अनुरोध का मैसेज शामिल होगा. |
servicecallout.request |
वैकल्पिक |
| clearPayload |
अगर clearPayload विकल्प को सिर्फ़ तब false पर सेट करें, जब सर्विस कॉलआउट के लागू होने के बाद अनुरोध मैसेज की ज़रूरत हो. |
सही | वैकल्पिक |
<Request>/<IgnoreUnresolvedVariables> एलिमेंट
सही है पर सेट होने पर, यह नीति अनुरोध में मौजूद, वैरिएबल से जुड़ी किसी भी ऐसी गड़बड़ी को अनदेखा कर देती है जिसे ठीक नहीं किया गया है.
<Request clearPayload="true" variable="myRequest"> <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables> </Request>
| डिफ़ॉल्ट | गलत |
| उपलब्धता | वैकल्पिक |
| समस्या | बूलियन |
<Response> एलिमेंट
इस एलिमेंट को तब शामिल करें, जब एपीआई प्रॉक्सी लॉजिक को आगे की प्रोसेसिंग के लिए रिमोट कॉल से मिले जवाब की ज़रूरत हो.
यह एलिमेंट मौजूद होने पर, उस वैरिएबल का नाम तय करता है जिसमें बाहरी सेवा से मिला रिस्पॉन्स मैसेज शामिल होगा. टारगेट से मिले जवाब को वैरिएबल में तब ही असाइन किया जाता है, जब नीति पूरे जवाब को पढ़ लेती है. अगर किसी वजह से रिमोट कॉल नहीं हो पाता है, तो नीति के तहत गड़बड़ी का मैसेज दिखता है.
अगर इस एलिमेंट को शामिल नहीं किया जाता है, तो एपीआई प्रॉक्सी किसी रिस्पॉन्स का इंतज़ार नहीं करती. एपीआई प्रॉक्सी फ़्लो का एक्ज़ीक्यूशन, इसके बाद के फ़्लो चरणों के साथ जारी रहता है. इसके अलावा, यह भी ध्यान रखें कि Response एलिमेंट के बिना, टारगेट से मिले जवाब को बाद के चरणों में प्रोसेस नहीं किया जा सकता. साथ ही, प्रॉक्सी फ़्लो के लिए रिमोट कॉल में हुई गड़बड़ी का पता लगाने का कोई तरीका नहीं होता.
ServiceCallout का इस्तेमाल करते समय, Response एलिमेंट को शामिल न करने का एक सामान्य तरीका यह है: किसी बाहरी सिस्टम में मैसेज लॉग करना.
<Response>calloutResponse</Response>
| डिफ़ॉल्ट | NA |
| उपलब्धता | वैकल्पिक |
| समस्या | स्ट्रिंग |
<Timeout> एलिमेंट
यह मिलीसेकंड में वह समय होता है जब Service Callout नीति, टारगेट से जवाब मिलने का इंतज़ार करेगी. इस वैल्यू को रनटाइम के दौरान डाइनैमिक तौर पर सेट नहीं किया जा सकता. अगर सेवा कॉलआउट में टाइम आउट होता है, तो एचटीटीपी 500 कोड वाली गड़बड़ी दिखती है. साथ ही, नीति लागू नहीं होती और एपीआई प्रॉक्सी में गड़बड़ी की स्थिति दिखती है. इसके बारे में गड़बड़ियों को ठीक करना लेख में बताया गया है.
<Timeout>30000</Timeout>
| डिफ़ॉल्ट | 55,000 मिलीसेकंड (55 सेकंड), Apigee Edge के लिए एचटीटीपी टाइम आउट की डिफ़ॉल्ट सेटिंग |
| उपलब्धता | वैकल्पिक |
| समस्या | पूर्णांक |
<HTTPTargetConnection> एलिमेंट
यह ट्रांसपोर्ट की जानकारी देता है. जैसे, यूआरएल, टीएलएस/एसएसएल, और एचटीटीपी प्रॉपर्टी. <TargetEndpoint> कॉन्फ़िगरेशन रेफ़रंस देखें.
<HTTPTargetConnection>
<URL>http://example.com</URL>
<LoadBalancer/>
<SSLInfo/>
<Properties/>
</HTTPTargetConnection>| डिफ़ॉल्ट | लागू नहीं |
| उपलब्धता | ज़रूरी है |
| समस्या | लागू नहीं |
<HTTPTargetConnection>/<URL> एलिमेंट
जिस सेवा को कॉल किया जा रहा है उसका यूआरएल:
<HTTPTargetConnection>
<URL>http://example.com</URL>
</HTTPTargetConnection>किसी वैरिएबल की मदद से, यूआरएल के कुछ हिस्से को डाइनैमिक तौर पर बदला जा सकता है. हालांकि, यूआरएल के प्रोटोकॉल वाले हिस्से, यानी कि नीचे दिए गए http:// को किसी वैरिएबल से तय नहीं किया जा सकता. यहां दिए गए उदाहरण में, क्वेरी पैरामीटर की वैल्यू तय करने के लिए वैरिएबल का इस्तेमाल किया गया है:
<URL>http://example.com/forecastrss?w=${request.header.woeid}</URL>
इसके अलावा, यूआरएल पाथ के किसी हिस्से को वैरिएबल के साथ सेट करें:
<URL>http://example.com/{request.resourcePath}?w=${request.header.woeid}</URL>अगर आपको यूआरएल के डोमेन और पोर्ट के बारे में बताने के लिए किसी वैरिएबल का इस्तेमाल करना है, तो सिर्फ़ डोमेन और पोर्ट के लिए एक वैरिएबल का इस्तेमाल करें. साथ ही, यूआरएल के किसी अन्य हिस्से के लिए दूसरे वैरिएबल का इस्तेमाल करें:
<URL>http://{request.dom_port}/{request.resourcePath}</URL>| डिफ़ॉल्ट | लागू नहीं |
| उपलब्धता | ज़रूरी है |
| समस्या | स्ट्रिंग |
<HTTPTargetConnection>/<SSLInfo> एलिमेंट
बैकएंड सेवा के लिए टीएलएस/एसएसएल कॉन्फ़िगरेशन. TLS/एसएसएल कॉन्फ़िगरेशन से जुड़ी मदद के लिए, Edge से बैकएंड (क्लाउड और प्राइवेट क्लाउड) तक TLS कॉन्फ़िगर करना और एपीआई प्रॉक्सी कॉन्फ़िगरेशन रेफ़रंस में "TLS/एसएसएल TargetEndpoint कॉन्फ़िगरेशन" देखें.
देखें.<HTTPTargetConnection>
<URL>https://example.com</URL>
<SSLInfo>
<Enabled>true</Enabled>
<ClientAuthEnabled>true</ClientAuthEnabled>
<KeyStore>ref://mykeystoreref</KeyStore> ## Use of a reference is recommended
<KeyAlias>myKey</KeyAlias>
<TrustStore>myTruststore</TrustStore>
<Ciphers/>
<Protocols/>
</SSLInfo>
</HTTPTargetConnection>| डिफ़ॉल्ट | लागू नहीं |
| उपलब्धता | वैकल्पिक |
| समस्या | लागू नहीं |
<HTTPTargetConnection>/<Properties> एलिमेंट
बैकएंड सेवा के लिए एचटीटीपी ट्रांसपोर्ट प्रॉपर्टी. ज़्यादा जानकारी के लिए, एंडपॉइंट प्रॉपर्टी का रेफ़रंस देखें.
<HTTPTargetConnection>
<URL>http://example.com</URL>
<Properties>
<Property name="allow.http10">true</Property>
<Property name="request.retain.headers">
User-Agent,Referer,Accept-Language
</Property>
</Properties>
</HTTPTargetConnection>| डिफ़ॉल्ट | लागू नहीं |
| उपलब्धता | वैकल्पिक |
| समस्या | लागू नहीं |
<HTTPTargetConnection>/<LoadBalancer> एलिमेंट
एक या उससे ज़्यादा टारगेट सर्वर को कॉल करता है और उन पर लोड बैलेंसिंग करता है. सैंपल सेक्शन में, कॉल टारगेट सर्वर का सैंपल देखें. बैकएंड सर्वर पर लोड बैलेंस करना लेख भी पढ़ें. इस कम्यूनिटी पोस्ट में, सर्विस कॉलआउट नीति और रूट के नियमों का इस्तेमाल करके, टारगेट सर्वर को कॉल करने के तरीकों के बारे में बताया गया है. इसे भी पढ़ें.
<HTTPTargetConnection> <LoadBalancer> <Algorithm>RoundRobin</Algorithm> <Server name="httpbin"/> <Server name="yahoo"/> </LoadBalancer> <Path>/get</Path> </HTTPTargetConnection>
| डिफ़ॉल्ट | लागू नहीं |
| उपलब्धता | वैकल्पिक |
| समस्या | लागू नहीं |
<LocalTargetConnection> एलिमेंट
यह विकल्प, सेवा के कॉलआउट के टारगेट के तौर पर, किसी लोकल प्रॉक्सी को सेट करता है. लोकल प्रॉक्सी का मतलब है कि प्रॉक्सी, उसी संगठन और एनवायरमेंट में है.
टारगेट के बारे में ज़्यादा जानकारी देने के लिए, <APIProxy> और <ProxyEndpoint> एलिमेंट या <Path> एलिमेंट का इस्तेमाल करें.
<LocalTargetConnection> <APIProxy/> <ProxyEndpoint/> <Path/> </LocalTargetConnection>
| डिफ़ॉल्ट | लागू नहीं |
| उपलब्धता | ज़रूरी है |
| समस्या | लागू नहीं |
<LocalTargetConnection>/<APIProxy> एलिमेंट
उस एपीआई प्रॉक्सी का नाम जिसे लोकल कॉल टारगेट कर रहा है. प्रॉक्सी उसी संगठन और एनवायरमेंट में होनी चाहिए जिसमें कॉल करने वाली प्रॉक्सी है.
<LocalTargetConnection> <APIProxy>data-manager</APIProxy> <ProxyEndpoint>default</ProxyEndpoint> </LocalTargetConnection>
<APIProxy> एलिमेंट के साथ-साथ, <ProxyEndpoint> एलिमेंट को भी शामिल करें. इससे उस प्रॉक्सी एंडपॉइंट का नाम तय किया जा सकेगा जिसे कॉल के लिए टारगेट किया जाना चाहिए.
<LocalTargetConnection> <APIProxy/> <ProxyEndpoint/> </LocalTargetConnection>
| डिफ़ॉल्ट | लागू नहीं |
| उपलब्धता | ज़रूरी है |
| समस्या | स्ट्रिंग |
<LocalTargetConnection>/<ProxyEndpoint> एलिमेंट
उस प्रॉक्सी एंडपॉइंट का नाम जिसे कॉल का टारगेट बनाया जाना चाहिए. यह <APIProxy> एलिमेंट के साथ तय की गई एपीआई प्रॉक्सी में एक प्रॉक्सी एंडपॉइंट है.
<LocalTargetConnection> <APIProxy>data-manager</APIProxy> <ProxyEndpoint>default</ProxyEndpoint> </LocalTargetConnection>
| डिफ़ॉल्ट | लागू नहीं |
| उपलब्धता | वैकल्पिक |
| समस्या | लागू नहीं |
<LocalTargetConnection>/<Path> एलिमेंट
टारगेट किए जा रहे एंडपॉइंट का पाथ. एंडपॉइंट, उसी संगठन और एनवायरमेंट में मौजूद प्रॉक्सी को रेफ़र करना चाहिए जिसमें कॉल करने वाली प्रॉक्सी मौजूद है.
अगर आपको प्रॉक्सी का नाम नहीं पता है या आप उस पर भरोसा नहीं कर सकते, तो <APIProxy>/<ProxyEndpoint> के बजाय इसका इस्तेमाल करें. पाथ को भरोसेमंद टारगेट माना जा सकता है.
<LocalTargetConnection> <Path>/data-manager</Path> </LocalTargetConnection>
| डिफ़ॉल्ट | लागू नहीं |
| उपलब्धता | वैकल्पिक |
| समस्या | लागू नहीं |
स्कीमा
फ़्लो वैरिएबल
फ़्लो वैरिएबल की मदद से, रनटाइम के दौरान नीतियों और फ़्लो के डाइनैमिक व्यवहार को चालू किया जा सकता है. यह एचटीटीपी हेडर, मैसेज के कॉन्टेंट या फ़्लो के कॉन्टेक्स्ट पर आधारित होता है. सेवा कॉलआउट नीति लागू होने के बाद, पहले से तय किए गए ये फ़्लो वैरिएबल उपलब्ध होते हैं. फ़्लो वैरिएबल के बारे में ज़्यादा जानने के लिए, वैरिएबल का रेफ़रंस देखें.
सेवा के बारे में जानकारी देने वाले कॉलआउट के लिए, अनुरोध और जवाब अलग-अलग होते हैं. साथ ही, इस डेटा को वैरिएबल के ज़रिए ऐक्सेस किया जा सकता है. मुख्य मैसेज में request.* और response.* वैरिएबल प्रीफ़िक्स का इस्तेमाल किया जा रहा है. इसलिए, सर्विस कॉलआउट से जुड़ा मैसेज डेटा पाने के लिए, myrequest.* और calloutResponse.* प्रीफ़िक्स का इस्तेमाल करें. ये प्रीफ़िक्स, सर्विस कॉलआउट कॉन्फ़िगरेशन में डिफ़ॉल्ट रूप से मौजूद होते हैं. नीचे दी गई टेबल में पहले उदाहरण से पता चलता है कि सर्विस कॉलआउट में एचटीटीपी हेडर कैसे मिलेंगे.
| वैरिएबल | ब्यौरा |
|---|---|
|
यहां सेवा के बारे में बताने वाले कॉलआउट के अनुरोध और जवाब के हेडर पाने का एक उदाहरण दिया गया है. ये हेडर, मुख्य अनुरोध और जवाब से मिलने वाले हेडर की तरह ही होते हैं.
यहां calloutResponse, सर्विस कॉलआउट में मौजूद रिस्पॉन्स के लिए वैरिएबल का नाम है. वहीं, myRequest, अनुरोध के लिए वैरिएबल का नाम है. उदाहरण के लिए:
यह फ़ंक्शन, Service Callout रिस्पॉन्स का Content-Length हेडर दिखाता है. |
स्कोप: सेवा कॉलआउट से आगे सेवा के बारे में जानकारी देने वाले कॉलआउट के अनुरोध या जवाब में मौजूद मैसेज हेडर. उदाहरण के लिए, अगर एपीआई प्रॉक्सी टारगेट http://example.com है और सर्विस कॉलआउट टारगेट http://mocktarget.apigee.net है, तो ये वैरिएबल, http://mocktarget.apigee.net पर कॉलआउट के लिए हेडर हैं. |
servicecallout.requesturi |
स्कोप: सर्विस कॉलआउट के अनुरोध से आगे ServiceCallout नीति के लिए TargetEndpoint यूआरआई. यूआरआई, TargetEndpoint यूआरएल होता है. इसमें प्रोटोकॉल और डोमेन की जानकारी शामिल नहीं होती. |
servicecallout.{policy-name}.target.url |
स्कोप: सर्विस कॉलआउट के अनुरोध से आगे सेवा के बारे में जानकारी देने वाले कॉलआउट के लिए टारगेट यूआरएल. |
|
यहां |
स्कोप: सेवा कॉलआउट के जवाब से आगे यह सर्विस कॉलआउट से मिले जवाब की बॉडी होती है. |
servicecallout.{policy-name}.expectedcn |
स्कोप: सर्विस कॉलआउट के अनुरोध से आगे ServiceCallout नीति में बताए गए TargetEndpoint का अनुमानित सामान्य नाम. यह सिर्फ़ तब काम करता है, जब TargetEndpoint, टीएलएस/एसएसएल एंडपॉइंट को रेफ़र करता है. |
servicecallout.{policy-name}.failed |
स्कोप: सर्विस कॉलआउट के जवाब से आगे बूलियन, जिससे यह पता चलता है कि नीति लागू हुई या नहीं. अगर नीति लागू हुई, तो वैल्यू 'गलत है' होगी. अगर नीति लागू नहीं हुई, तो वैल्यू 'सही है' होगी. |
गड़बड़ियां
इस सेक्शन में, गड़बड़ी के कोड और गड़बड़ी के मैसेज के बारे में बताया गया है. साथ ही, इन गड़बड़ियों के वैरिएबल के बारे में भी बताया गया है, जो Edge की मदद से सेट किए जाते हैं. यह जानकारी जानना ज़रूरी है कि क्या आप गड़बड़ियों को ठीक करता है. ज़्यादा जानने के लिए, आपके लिए ज़रूरी जानकारी देखें नीति से जुड़ी गड़बड़ियों और हैंडलिंग के बारे में जानकारी गलतियां.
रनटाइम की गड़बड़ियां
नीति के लागू होने पर ये गड़बड़ियां हो सकती हैं.
| गड़बड़ी कोड | एचटीटीपी कोड स्थिति | वजह | ठीक करें |
|---|---|---|---|
steps.servicecallout.ExecutionFailed |
500 |
यह गड़बड़ी तब हो सकती है, जब:
|
build |
steps.servicecallout.RequestVariableNotMessageType |
500 | नीति में दिए गए अनुरोध वैरिएबल का टाइप मैसेज नहीं है. उदाहरण के लिए, अगर यह कोई स्ट्रिंग या कोई दूसरा गैर-मैसेज टाइप है, तो आपको यह गड़बड़ी दिखेगी. | build |
steps.servicecallout.RequestVariableNotRequestMessageType |
500 | नीति में दिए गए अनुरोध वैरिएबल का टाइप, अनुरोध मैसेज नहीं है. इसके लिए उदाहरण के लिए, अगर यह रिस्पॉन्स का टाइप है, तो आपको यह गड़बड़ी दिखेगी. | build |
डिप्लॉयमेंट से जुड़ी गड़बड़ियां
ये गड़बड़ियां तब हो सकती हैं, जब इस नीति वाली प्रॉक्सी को डिप्लॉय किया जाता है.
| गड़बड़ी का नाम | वजह | ठीक करें |
|---|---|---|
URLMissing |
<HTTPTargetConnection> में <URL> एलिमेंट
मौजूद नहीं है या खाली है. |
build |
ConnectionInfoMissing |
यह गड़बड़ी तब होती है, जब नीति में
<HTTPTargetConnection> या <LocalTargetConnection>
एलिमेंट. |
build |
InvalidTimeoutValue |
यह गड़बड़ी तब होती है, जब <Timeout> की वैल्यू नेगेटिव या शून्य होती है. |
build |
गड़बड़ी के वैरिएबल
रनटाइम की गड़बड़ी होने पर ये वैरिएबल सेट किए जाते हैं. ज़्यादा जानकारी के लिए, आपके लिए ज़रूरी जानकारी देखें नीति से जुड़ी गड़बड़ियों के बारे में जानकारी.
| वैरिएबल | कहां | उदाहरण |
|---|---|---|
fault.name="fault_name" |
fault_name गड़बड़ी का नाम है, जैसा कि ऊपर रनटाइम में गड़बड़ियां टेबल में बताया गया है. गड़बड़ी का नाम, गड़बड़ी के कोड का आखिरी हिस्सा होता है. | fault.name = "RequestVariableNotMessageType" |
servicecallout.policy_name.failed |
policy_name, उपयोगकर्ता की ओर से बताया गया उस नीति का नाम है जिसमें गड़बड़ी हुई है. | servicecallout.SC-GetUserData.failed = true |
गड़बड़ी के रिस्पॉन्स का उदाहरण
{ "fault":{ "detail":{ "errorcode":"steps.servicecallout.RequestVariableNotMessageType" }, "faultstring":"ServiceCallout[ServiceCalloutGetMockResponse]: request variable data_str value is not of type Message" } }
गड़बड़ी के नियम का उदाहरण
<faultrule name="VariableOfNonMsgType"></faultrule><FaultRule name="RequestVariableNotMessageType">
<Step>
<Name>AM-RequestVariableNotMessageType</Name>
</Step>
<Condition>(fault.name = "RequestVariableNotMessageType")</Condition>
</FaultRule>मिलते-जुलते विषय
- मैसेज जनरेट करना या उनमें बदलाव करना: मैसेज की नीति असाइन करें
- वैरिएबल निकालना: Extract Variables policy
- वैरिएबल: वैरिएबल रेफ़रंस
- TLS/एसएसएल कॉन्फ़िगरेशन
- Edge से बैकएंड (क्लाउड और प्राइवेट क्लाउड) तक टीएलएस कॉन्फ़िगर करना
- एपीआई प्रॉक्सी कॉन्फ़िगरेशन रेफ़रंस में "TLS/SSL TargetEndpoint कॉन्फ़िगरेशन"
- एचटीटीपी ट्रांसपोर्ट प्रॉपर्टी: एंडपॉइंट प्रॉपर्टी का रेफ़रंस
- सेवा कॉलआउट का विकल्प: JavaScript में लिखा गया HTTPClient. इसके बारे में जानने के लिए, JavaScript ऑब्जेक्ट मॉडल देखें