服務呼叫執行階段錯誤疑難排解

您正在查看 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> 元素中指定的變數不是 message，就會發生這個錯誤。如果變數是字串或任何其他非訊息類型，系統就會顯示這個錯誤。

訊息類型變數代表整個 HTTP 要求和回應。內建 Edge 流程變數 request、response 和 message 屬於訊息類型。如要進一步瞭解訊息變數，請參閱「變數參考資料」。

診斷

1. 找出發生錯誤的服務呼叫政策，以及類型不正確的變數名稱。您可以在錯誤回應的 faultstring 元素中找到這兩個項目。舉例來說，在下列 faultstring 中，政策名稱是 ExecuteGeocodingRequest，變數則為 PostalCode：

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

2. 在失敗的服務呼叫政策 XML 中，確認 <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. 在 API Proxy 軟體包中找出變數，其中先定義變數。
   2. 在大多數情況下，您會發現問題變數已建立，並填入在服務呼叫政策之前執行的其他政策中。例如，Assign Message 政策常用於在 API Proxy 流程中建立和填入變數。
   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>

現在，請記得在服務呼叫政策的 <Request> 元素中使用 PostalCode 變數：

<?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> 元素，指定類型為訊息的現有變數或新變數。舉例來說，在 Assign Message 政策中設定的變數 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 類型變數代表整個 HTTP 要求和回應。內建 Edge 流程變數 request、response 和 message 屬於訊息類型。如要進一步瞭解訊息變數，請參閱「變數參考資料」。

診斷

1. 找出發生錯誤的服務呼叫政策，以及類型不正確的變數名稱。您可以在錯誤回應的 faultstring 元素中找到這兩個項目。舉例來說，在下列 faultstring 中，政策名稱是 ExecuteGeocodingRequest，變數則為 var_response：

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

2. 在失敗的服務呼叫政策 XML 中，確認 <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. 在 API Proxy 軟體包中找出變數，其中先定義變數。
   2. 在大多數情況下，您會發現問題變數已建立，並填入在服務呼叫政策之前執行的其他政策中。例如，Assign Message 政策常用於在 API Proxy 流程中建立和填入變數。
   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 錯誤。