Apigee Edge दस्तावेज़ देखा जा रहा है.
Apigee X दस्तावेज़ पर जाएं. जानकारी
RequestVariableNotMessageType
गड़बड़ी का कोड
steps.servicecallout.RequestVariableNotMessageType
गड़बड़ी के जवाब का मुख्य हिस्सा
{ "fault": { "faultstring": "ServiceCallout[policy_name]: request variable [variable_name] value is not of type Message", "detail": { "errorcode": "steps.servicecallout.RequestVariableNotMessageType" } } }
वजह
यह गड़बड़ी तब होती है, जब सेवा कॉलआउट की नीति के <Request>
एलिमेंट में दिया गया वैरिएबल, मैसेज टाइप का न हो. अगर वैरिएबल कोई स्ट्रिंग है या बिना मैसेज वाला कोई अन्य टाइप है, तो आपको यह गड़बड़ी दिखेगी.
मैसेज टाइप वैरिएबल से पूरे एचटीटीपी अनुरोध और उनके जवाब दिखते हैं. बिल्ट-इन Edge फ़्लो वैरिएबल request
, response
, और message
टाइप मैसेज हैं. मैसेज वैरिएबल के बारे में ज़्यादा जानने के लिए, वैरिएबल रेफ़रंस देखें.
संक्रमण की जांच
उस सेवा कॉलआउट की नीति की पहचान करें जहां गड़बड़ी हुई है. साथ ही, उस वैरिएबल के नाम की पहचान करें जिसका टाइप गलत है. आपको ये दोनों आइटम, गड़बड़ी के जवाब के
faultstring
एलिमेंट में मिल सकते हैं. उदाहरण के लिए, इसfaultstring
में, नीति का नामExecuteGeocodingRequest
और वैरिएबलPostalCode
है:"faultstring": "ServiceCallout[ExecuteGeocodingRequest]: request variable PostalCode value is not of type Message"
सेवा कॉलआउट की नीति के एक्सएमएल में, पुष्टि करें कि
<Request>
एलिमेंट में मौजूद वैरिएबल सेट का नाम, गड़बड़ी वाली स्ट्रिंग में पहचाने गए वैरिएबल के नाम से मैच होता है (ऊपर दिया गया चरण #1). उदाहरण के लिए, यह नीतिPostalCode
नाम के रिक्वेस्ट वैरिएबल के बारे में बताती है. यह वैरिएबलfaultstring
में मौजूद वैरिएबल से मेल खाता है:<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ServiceCallout name="ExecuteGeocodingRequest"> <Request variable="PostalCode"/> <Response>GeocodingResponse</Response> <HTTPTargetConnection> <URL>http://maps.googleapis.com/maps/api/geocode/json</URL> </HTTPTargetConnection> </ServiceCallout>
तय करें कि यह वैरिएबल किसी तरह के मैसेज का है या नहीं:
- एपीआई प्रॉक्सी बंडल में वह कोड ढूंढें जहां सबसे पहले वैरिएबल तय किया गया था.
- ज़्यादातर मामलों में, आपको दिखेगा कि समस्या वाला वैरिएबल किसी दूसरी नीति में बनाया गया है और भरा गया है. यह वैरिएबल, सेवा की कॉलआउट नीति से पहले लागू होता है. उदाहरण के लिए, 'मैसेज असाइन करें' नीति का इस्तेमाल, आम तौर पर एपीआई प्रॉक्सी फ़्लो में वैरिएबल बनाने और उन्हें भरने के लिए किया जाता है.
- यह पता लगाने के बाद कि वैरिएबल को किस नीति के तहत तय किया गया है और सबसे पहले भरा गया है, आपको नीचे बताए गए तरीके से वैरिएबल का टाइप तय करना होगा:
type
एट्रिब्यूट की वैल्यू देखें (अगर मौजूद हो).- अगर
type
एट्रिब्यूट मौजूद नहीं है, तो वैरिएबल को स्ट्रिंग माना जाता है.
- अगर वैरिएबल का टाइप, मैसेज नहीं है (जैसे कि स्ट्रिंग), तो यही गड़बड़ी की वजह है. वैरिएबल के रेफ़रंस में जाकर, सामान्य वैरिएबल और उनके टाइप के बारे में जाना जा सकता है.
उदाहरण के लिए, मान लें कि सेवा की कॉलआउट नीति में रेफ़र किया गया PostalCode
वैरिएबल, यहां दी गई मैसेज असाइन करने की नीति में बनाया गया था. ध्यान दें कि PostalCode
को फ़्लो वैरिएबल request.queryparam.postalcode
की वैल्यू असाइन की गई है. यह वैल्यू एक स्ट्रिंग है, क्योंकि वैरिएबल असाइनमेंट में कोई type
एट्रिब्यूट मौजूद नहीं है.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<AssignMessage name="GenerateGeocodingRequest">
<AssignTo createNew="true" type="request">GeocodingRequest</AssignTo>
<Set>
<QueryParams>
<QueryParam name="address">{request.queryparam.postalcode}</QueryParam>
<QueryParam name="region">{request.queryparam.country}</QueryParam>
<QueryParam name="sensor">false</QueryParam>
</QueryParams>
<Verb>GET</Verb>
</Set>
<AssignVariable>
<Name>PostalCode</Name>
<Ref>request.queryparam.postalcode</Ref>
</AssignVariable>
<AssignVariable>
<Name>Country</Name>
<Ref>request.queryparam.country</Ref>
</AssignVariable>
</AssignMessage>
अब याद रखें कि PostalCode
वैरिएबल का इस्तेमाल, सेवा कॉलआउट की नीति के <Request>
एलिमेंट में किया जाता है:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ServiceCallout name="ExecuteGeocodingRequest">
<Request variable="PostalCode"/>
<Response>GeocodingResponse</Response>
<HTTPTargetConnection>
<URL>http://maps.googleapis.com/maps/api/geocode/json</URL>
</HTTPTargetConnection>
</ServiceCallout>
PostalCode
टाइप मैसेज नहीं है (इस उदाहरण में यह एक स्ट्रिंग है), इसलिए आपको गड़बड़ी कोड यह मिला है: steps.servicecallout.RequestVariableNotMessageType
.
रिज़ॉल्यूशन
पक्का करें कि फ़ेल हो चुकी सेवा कॉलआउट नीति के <Request>
एलिमेंट में सेट किया गया वैरिएबल, मैसेज टाइप का फ़्लो वैरिएबल है. इसके अलावा, आपके पास सीधे सेवा कॉलआउट की नीति में, मैसेज टाइप का नया वैरिएबल बनाने का विकल्प है (जैसा कि नीति के दस्तावेज़ में बताया गया है) और उसका इस्तेमाल करें.
इस नीति को ठीक करने के लिए, आपको <Request>
एलिमेंट में बदलाव करना होगा, ताकि मैसेज टाइप के मौजूदा या नए वैरिएबल के बारे में बताया जा सके. उदाहरण के लिए, 'मैसेज असाइन करें' नीति में सेट किया गया वैरिएबल GeocodingRequest
, टाइप मैसेज वाला है और सेवा कॉलआउट नीति में ठीक से काम करेगा. उदाहरण के लिए:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ServiceCallout name="ExecuteGeocodingRequest">
<Request variable="GeocodingRequest"/>
<Response>GeocodingResponse</Response>
<HTTPTargetConnection>
<URL>http://maps.googleapis.com/maps/api/geocode/json</URL>
</HTTPTargetConnection>
</ServiceCallout>
RequestVariableNotRequestMessageType
गड़बड़ी का कोड
steps.servicecallout.RequestVariableNotRequestMessageType
गड़बड़ी के जवाब का मुख्य हिस्सा
{ "fault": { "faultstring": "ServiceCallout[policy_name]: request variable [variable_name] value is not of type Request Message", "detail": { "errorcode": "steps.servicecallout.RequestVariableNotRequestMessageType" } } }
वजह
यह गड़बड़ी तब होती है, जब सेवा कॉलआउट की नीति के <Request>
एलिमेंट में दिया गया वैरिएबल, अनुरोध मैसेज टाइप का न हो. अगर वैरिएबल, रिस्पॉन्स मैसेज टाइप, स्ट्रिंग या किसी अन्य टाइप का वैरिएबल है, तो आपको यह गड़बड़ी दिखेगी.
मैसेज टाइप वैरिएबल, पूरे एचटीटीपी अनुरोधों और रिस्पॉन्स को दिखाते हैं. बिल्ट-इन Edge फ़्लो वैरिएबल request
, response
, और message
टाइप मैसेज हैं. मैसेज वैरिएबल के बारे में ज़्यादा जानने के लिए, वैरिएबल रेफ़रंस देखें.
संक्रमण की जांच
उस सेवा कॉलआउट की नीति की पहचान करें जहां गड़बड़ी हुई है. साथ ही, उस वैरिएबल के नाम की पहचान करें जिसका टाइप गलत है. आपको ये दोनों आइटम, गड़बड़ी के जवाब के
faultstring
एलिमेंट में मिल सकते हैं. उदाहरण के लिए, इसfaultstring
में, नीति का नामExecuteGeocodingRequest
और वैरिएबलvar_response
है:"faultstring": "ServiceCallout[ExecuteGeocodingRequest]: request variable var_response value is not of type Message"
सेवा कॉलआउट की नीति के एक्सएमएल में, पुष्टि करें कि
<Request>
एलिमेंट में मौजूद वैरिएबल सेट का नाम, गड़बड़ी वाली स्ट्रिंग में पहचाने गए वैरिएबल के नाम से मैच होता है (ऊपर दिया गया चरण #1). उदाहरण के लिए, यह नीतिvar_response
नाम के रिक्वेस्ट वैरिएबल के बारे में बताती है. यह वैरिएबलfaultstring
में मौजूद वैरिएबल से मेल खाता है:<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ServiceCallout name="ExecuteGeocodingRequest"> <Request variable="var_response"/> <Response>GeocodingResponse</Response> <HTTPTargetConnection> <URL>http://maps.googleapis.com/maps/api/geocode/json</URL> </HTTPTargetConnection> </ServiceCallout>
वैरिएबल, अनुरोध किए गए मैसेज टाइप का है या नहीं, इससे पता लगाएं:
- एपीआई प्रॉक्सी बंडल में वह कोड ढूंढें जहां सबसे पहले वैरिएबल तय किया गया था.
- ज़्यादातर मामलों में, आपको दिखेगा कि समस्या वाला वैरिएबल किसी दूसरी नीति में बनाया गया है और भरा गया है. यह वैरिएबल, सेवा की कॉलआउट नीति से पहले लागू होता है. उदाहरण के लिए, 'मैसेज असाइन करें' नीति का इस्तेमाल, आम तौर पर एपीआई प्रॉक्सी फ़्लो में वैरिएबल बनाने और उन्हें भरने के लिए किया जाता है.
- यह पता लगाने के बाद कि वैरिएबल को किस नीति के तहत तय किया गया है और सबसे पहले भरा गया है, आपको नीचे बताए गए तरीके से वैरिएबल का टाइप तय करना होगा:
type
एट्रिब्यूट की वैल्यू देखें (अगर मौजूद हो).- अगर
type
एट्रिब्यूट मौजूद नहीं है, तो वैरिएबल को स्ट्रिंग माना जाता है.
- अगर वैरिएबल का टाइप अनुरोध मैसेज टाइप नहीं है, तो यही गड़बड़ी की वजह है. वैरिएबल के रेफ़रंस में जाकर, सामान्य वैरिएबल और उनके टाइप के बारे में जाना जा सकता है.
उदाहरण के लिए, मान लें कि सेवा की कॉलआउट नीति में रेफ़र किया गया var_response
वैरिएबल, यहां दी गई मैसेज असाइन करने की नीति में बनाया गया था. ध्यान दें कि var_response
को response
टाइप दिया गया है. इसलिए, var_response
वैरिएबल का टाइप, रिस्पॉन्स मैसेज है.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<AssignMessage name="GenerateGeocodingRequest">
<AssignTo createNew="true" type="request">GeocodingRequest</AssignTo>
<AssignTo createNew="true" type="response">var_response</AssignTo>
<Set>
<QueryParams>
<QueryParam name="address">{request.queryparam.postalcode}</QueryParam>
<QueryParam name="region">{request.queryparam.country}</QueryParam>
<QueryParam name="sensor">false</QueryParam>
</QueryParams>
<Verb>GET</Verb>
</Set>
<AssignVariable>
<Name>PostalCode</Name>
<Ref>request.queryparam.postalcode</Ref>
</AssignVariable>
<AssignVariable>
<Name>Country</Name>
<Ref>request.queryparam.country</Ref>
</AssignVariable>
</AssignMessage>
याद रखें कि var_response
वैरिएबल का इस्तेमाल, सेवा कॉलआउट की नीति के <Request>
एलिमेंट में किया गया है.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ServiceCallout name="ExecuteGeocodingRequest">
<Request variable="var_response"/>
<Response>GeocodingResponse</Response>
<HTTPTargetConnection>
<URL>http://maps.googleapis.com/maps/api/geocode/json</URL>
</HTTPTargetConnection>
</ServiceCallout>
var_response
, अनुरोध का मैसेज नहीं है (इसका टाइप रिस्पॉन्स मैसेज है), इसलिए आपको गड़बड़ी का यह कोड मिला है: steps.servicecallout.RequestVariableNotRequestMessageType
.
रिज़ॉल्यूशन
पक्का करें कि फ़ेल हो चुकी सेवा कॉलआउट नीति के <Request>
एलिमेंट में सेट किया गया वैरिएबल, मैसेज का अनुरोध टाइप का वैरिएबल है. इसके अलावा, सेवा कॉलआउट की नीति (जैसा कि नीति के दस्तावेज़ में बताया गया है) में ही, अनुरोध के लिए मैसेज टाइप का नया वैरिएबल बनाया जा सकता है और उसका इस्तेमाल किया जा सकता है.
इस नीति को ठीक करने के लिए, आपको <Request>
एलिमेंट में बदलाव करना होगा, ताकि अनुरोध के टाइप वाले मैसेज के मौजूदा या नए वैरिएबल के बारे में बताया जा सके. यह सेवा कॉलआउट की नीति में काम करेगा. उदाहरण के लिए:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ServiceCallout name="ExecuteGeocodingRequest">
<Request variable="GeocodingRequest"/>
<Response>GeocodingResponse</Response>
<HTTPTargetConnection>
<URL>http://maps.googleapis.com/maps/api/geocode/json</URL>
</HTTPTargetConnection>
</ServiceCallout>
ExecutionFailed
गड़बड़ी का कोड
steps.servicecallout.ExecutionFailed
गड़बड़ी के जवाब का मुख्य हिस्सा
{ "fault": { "faultstring": "Execution of ServiceCallout [policy_name] failed. Reason: Host not reachable", "detail": { "errorcode": "steps.servicecallout.ExecutionFailed" } } }
या
{ "fault": { "faultstring": "Execution of ServiceCallout [policy_name] failed. Reason: ResponseCode [http_code] is treated as error", "detail": { "errorcode": "steps.servicecallout.ExecutionFailed" } } }
संभावित कारण
इस गड़बड़ी की ये वजहें हो सकती हैं:
Cause | जानकारी |
अमान्य या गलत यूआरएल | सेवा कॉलआउट की नीति में मौजूद टारगेट यूआरएल गलत है या उसका होस्ट नाम अमान्य है या पहुंच से बाहर है. |
बैकएंड सर्वर में गड़बड़ी | बैकएंड सर्वर, 4XX या 5XX का गड़बड़ी वाला रिस्पॉन्स दिखाता है. |
वजह: गलत या गलत यूआरएल
सेवा कॉलआउट की नीति में मौजूद टारगेट यूआरएल गलत है या उसका होस्ट नाम अमान्य है या पहुंच से बाहर है.
संक्रमण की जांच
उस सेवा कॉलआउट की नीति की पहचान करें जिसकी वजह से गड़बड़ी हुई. नीति का नाम, गड़बड़ी के रिस्पॉन्स के
faultstring
एलिमेंट में दिखता है. उदाहरण के लिए, नीचे दिए गएfaultstring
में, सेवा कॉलआउट की उस नीति का नामExecuteGeocodingRequest
है जो लागू नहीं हो सकी."faultstring": "ServiceCallout[ExecuteGeocodingRequest]"
सफल न होने वाली सेवा कॉलआउट नीति में,
<URL>
एलिमेंट की जांच करें. अगर यह गलत है या इसका होस्ट नाम अमान्य है या ऐसा होस्ट नाम है जो पहुंच से बाहर है, तो इस गड़बड़ी की वजह यही है. उदाहरण के लिए, नीचे दी गई सेवा कॉलआउट नीति एक अमान्य<URL>
के बारे में बताती है:<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ServiceCallout name="ExecuteGeocodingRequest"> <Request variable="GeocodingRequest"/> <Response>GeocodingResponse</Response> <HTTPTargetConnection> <URL>http://</URL> </HTTPTargetConnection> </ServiceCallout>
<URL>
एलिमेंट में सिर्फ़http://
प्रोटोकॉल है, लेकिन इसका होस्टनेम मान्य नहीं है. इसलिए, सेवा कॉलआउट की नीति इस गड़बड़ी के साथ काम नहीं करती:Execution of ServiceCallout ExecuteGeocodingRequest failed. Reason: Host not reachable
.
रिज़ॉल्यूशन
पक्का करें कि सेवा कॉलआउट की नीति में मौजूद <URL>
एलिमेंट में ऐसा मान्य यूआरएल है जिसे ऐक्सेस किया जा सकता है.
ऊपर दिखाई गई सेवा कॉलआउट की नीति को ठीक करने के लिए, <URL>
एलिमेंट में बदलाव करके, मान्य यूआरएल की जानकारी दी जा सकती है:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ServiceCallout name="ExecuteGeocodingRequest">
<Request variable="GeocodingRequest"/>
<Response>GeocodingResponse</Response>
<HTTPTargetConnection>
<URL>http://maps.googleapis.com/maps/api/geocode/json</URL>
</HTTPTargetConnection>
</ServiceCallout>
वजह: बैकएंड सर्वर में गड़बड़ी
बैकएंड सर्वर, 4XX या 5XX का गड़बड़ी वाला रिस्पॉन्स दिखाता है.
संक्रमण की जांच
उस सेवा कॉलआउट की नीति की पहचान करें जिसकी वजह से गड़बड़ी हुई. नीति का नाम, गड़बड़ी के रिस्पॉन्स के
faultstring
एलिमेंट में दिखता है. उदाहरण के लिए, नीचे दिए गएfaultstring
में, सेवा कॉलआउट की उस नीति का नामExecuteGeocodingRequest
है जो लागू नहीं हो सकी."faultstring": "ServiceCallout[ExecuteGeocodingRequest]
गड़बड़ी के जवाब वाले मुख्य हिस्से में
faultstring
की जांच करें और देखें किReason
में 4XX या 5XX रिस्पॉन्स कोड मौजूद हैं या नहीं. उदाहरण के लिए, नीचे दी गई गड़बड़ी वाली स्ट्रिंग साफ़ तौर पर बताती है कि बैकएंड सर्वर से रिस्पॉन्स कोड 502 मिला है:"faultstring": "Execution of ServiceCallout ExecuteGeocodingRequest failed. Reason: ResponseCode 502 is treated as error"
रिज़ॉल्यूशन
गड़बड़ी वाला रिस्पॉन्स कोड पता लगने के बाद, 4XX या 5XX की गड़बड़ी की तरह ही इस समस्या को भी हल किया जा सकता है. समस्या हल करने और 4XX या 5XX की गड़बड़ियों को ठीक करने के बारे में निर्देश के लिए, रनटाइम की गड़बड़ी (4XX/5XX) प्लेबुक देखें.