सेवा कॉलआउट रनटाइम की गड़बड़ी से जुड़ी समस्या हल करना

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, मैसेज टाइप के होते हैं. मैसेज वैरिएबल के बारे में ज़्यादा जानने के लिए, वैरिएबल का रेफ़रंस देखें.

संक्रमण की जांच

1. उस सेवा कॉलआउट नीति की पहचान करें जहां गड़बड़ी हुई है. साथ ही, उस वेरिएबल का नाम भी बताएं जिसका टाइप गलत है. आपको ये दोनों आइटम, गड़बड़ी के जवाब के faultstring एलिमेंट में मिल सकते हैं. उदाहरण के लिए, नीचे दिए गए faultstring में, नीति का नाम ExecuteGeocodingRequest और वैरिएबल PostalCode है:

   "faultstring": "ServiceCallout[ExecuteGeocodingRequest]: request variable PostalCode value is not of type Message"

2. सेवा कॉलआउट की वह नीति जो लागू नहीं हो सकी, एक्सएमएल में यह पुष्टि करें कि <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>
   

3. यह पता लगाएं कि यह वैरिएबल, मैसेज टाइप का है या नहीं:

   1. एपीआई प्रॉक्सी बंडल में वह कोड ढूंढें जहां वैरिएबल को पहले तय किया गया था.
   2. ज़्यादातर मामलों में, आपको दिखेगा कि समस्या वाला वैरिएबल बनाया गया है और सेवा कॉलआउट की नीति से पहले लागू होने वाली किसी दूसरी नीति में अपने-आप भर दिया गया है. उदाहरण के लिए, मैसेज असाइन करने की नीति का इस्तेमाल, आम तौर पर एपीआई प्रॉक्सी फ़्लो में वैरिएबल बनाने और उन्हें पॉप्युलेट करने के लिए किया जाता है.
   3. जिस नीति में वैरिएबल को पहले से तय और पॉप्युलेट किया गया है उसे ढूंढने के बाद, आपको उस वैरिएबल का टाइप इस तरह से तय करना होगा:
      • type एट्रिब्यूट की वैल्यू देखें (अगर मौजूद हो).
      • अगर type एट्रिब्यूट मौजूद नहीं है, तो वैरिएबल को स्ट्रिंग माना जाता है.
   4. अगर वैरिएबल का टाइप मैसेज नहीं है, जैसे कि स्ट्रिंग, तो गड़बड़ी की वजह यही है. वैरिएबल रेफ़रंस में, सामान्य वैरिएबल और उनके टाइप के बारे में जानकारी मिल सकती है.

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

संक्रमण की जांच

1. उस सेवा कॉलआउट नीति की पहचान करें जहां गड़बड़ी हुई है. साथ ही, उस वेरिएबल का नाम भी बताएं जिसका टाइप गलत है. आपको ये दोनों आइटम, गड़बड़ी के जवाब के faultstring एलिमेंट में मिल सकते हैं. उदाहरण के लिए, यहां दिए गए faultstring में, नीति का नाम ExecuteGeocodingRequest है और वैरिएबल var_response है:

   "faultstring": "ServiceCallout[ExecuteGeocodingRequest]: request variable var_response value is not of type Message"

2. सेवा कॉलआउट की नीति के एक्सएमएल में, पुष्टि करें कि <Request> एलिमेंट में सेट किए गए वैरिएबल का नाम, गड़बड़ी की स्ट्रिंग (ऊपर दिया गया पहला चरण) में पहचाने गए वैरिएबल के नाम से मेल खाता हो. उदाहरण के लिए, नीचे दी गई नीति में 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>
   

3. यह तय करें कि वैरिएबल, अनुरोध मैसेज टाइप का है या नहीं:

   1. एपीआई प्रॉक्सी बंडल में वह कोड ढूंढें जहां वैरिएबल को पहले तय किया गया था.
   2. ज़्यादातर मामलों में, आपको दिखेगा कि समस्या वाला वैरिएबल बनाया गया है और सेवा कॉलआउट की नीति से पहले लागू होने वाली किसी दूसरी नीति में अपने-आप भर दिया गया है. उदाहरण के लिए, मैसेज असाइन करने की नीति का इस्तेमाल, आम तौर पर एपीआई प्रॉक्सी फ़्लो में वैरिएबल बनाने और उन्हें पॉप्युलेट करने के लिए किया जाता है.
   3. जिस नीति में वैरिएबल को पहले से तय और पॉप्युलेट किया गया है उसे ढूंढने के बाद, आपको उस वैरिएबल का टाइप इस तरह से तय करना होगा:
      • type एट्रिब्यूट की वैल्यू देखें (अगर मौजूद हो).
      • अगर type एट्रिब्यूट मौजूद नहीं है, तो वैरिएबल को स्ट्रिंग माना जाता है.
   4. अगर वैरिएबल का टाइप अनुरोध मैसेज टाइप का नहीं है, तो गड़बड़ी की वजह यही है. वैरिएबल रेफ़रंस में, सामान्य वैरिएबल और उनके टाइप के बारे में जानकारी मिल सकती है.

उदाहरण के लिए, मान लें कि सेवा कॉलआउट नीति में रेफ़र किया गया 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 कोड वाली गड़बड़ी का रिस्पॉन्स दिखाता है.

वजह: यूआरएल अमान्य है या गलत है

सेवा कॉलआउट की नीति में मौजूद टारगेट यूआरएल गलत है या उसका होस्टनेम अमान्य है या उस पर ऐक्सेस नहीं किया जा सकता.

संक्रमण की जांच

1. उस सेवा कॉलआउट नीति की पहचान करें जिसकी वजह से गड़बड़ी हुई है. नीति का नाम, गड़बड़ी के जवाब के faultstring एलिमेंट में दिखता है. उदाहरण के लिए, यहां दिए गए faultstring में, काम न करने वाली सेवा कॉलआउट नीति का नाम ExecuteGeocodingRequest है.

   "faultstring": "ServiceCallout[ExecuteGeocodingRequest]"

2. सेवा कॉलआउट की वह नीति जो लागू नहीं हो सकी उसमें, <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 कोड वाली गड़बड़ी का रिस्पॉन्स दिखाता है.

संक्रमण की जांच

1. उस सेवा कॉलआउट नीति की पहचान करें जिसकी वजह से गड़बड़ी हुई है. नीति का नाम, गड़बड़ी के जवाब के faultstring एलिमेंट में दिखता है. उदाहरण के लिए, यहां दिए गए faultstring में, काम न करने वाली सेवा कॉलआउट नीति का नाम ExecuteGeocodingRequest है.

   "faultstring": "ServiceCallout[ExecuteGeocodingRequest]

2. गड़बड़ी के जवाब वाले मुख्य हिस्से में faultstring की जांच करें और देखें कि क्या Reason में 4XX या 5XX रिस्पॉन्स कोड मौजूद हैं. उदाहरण के लिए, यहां दी गई गड़बड़ी की जानकारी से साफ़ तौर पर पता चलता है कि बैकएंड सर्वर से रिस्पॉन्स कोड 502 मिला था:

   "faultstring": "Execution of ServiceCallout ExecuteGeocodingRequest failed. Reason: ResponseCode 502 is treated as error"

रिज़ॉल्यूशन

गड़बड़ी का रिस्पॉन्स कोड पता करने के बाद, इस समस्या को ठीक करने का तरीका वही होगा जो 4XX या 5XX वाली गड़बड़ी को ठीक करने के लिए इस्तेमाल किया जाता है. 4XX या 5XX कोड वाली गड़बड़ियों को हल करने के बारे में जानने के लिए, रनटाइम गड़बड़ी (4XX/5XX) प्लेबुक देखें.