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

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

Message टाइप के वैरिएबल, पूरे एचटीटीपी अनुरोध और रिस्पॉन्स दिखाते हैं. बिल्ट-इन एज फ़्लो वैरिएबल request, response, और message मैसेज टाइप के होते हैं. मैसेज वैरिएबल के बारे में ज़्यादा जानने के लिए, वैरिएबल का रेफ़रंस देखें.

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

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

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

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

  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) प्लेबुक देखें.