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

यह Apigee Edge के दस्तावेज़ हैं.
पर जाएं Apigee X दस्तावेज़. info

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

संभावित कारण

इस गड़बड़ी की ये वजहें हो सकती हैं:

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