ServiceCallout 런타임 오류 문제 해결

Apigee 및 Apigee Hybrid 문서입니다.
Apigee Edge 문서 보기

RequestVariableNotMessageType

오류 코드

steps.servicecallout.RequestVariableNotMessageType

오류 응답 본문

{
    "fault": {
        "faultstring": "ServiceCallout[POLICY_NAME]: request variable [VARIABLE_NAME] value is not of type Message",
        "detail": {
            "errorcode": "steps.servicecallout.RequestVariableNotMessageType"
        }
    }
}

원인

이 오류는 ServiceCallout 정책의 <Request> 요소에 지정된 변수가 message 유형이 아닌 경우에 발생합니다. 변수가 문자열 또는 기타 메시지 외 유형이면 이 오류가 표시됩니다.

메시지 유형 변수는 전체 HTTP 요청 및 응답을 나타냅니다. 기본 제공 흐름 변수 request, response, message는 message 유형입니다.

진단

  1. 오류가 발생한 ServiceCallout 정책 및 잘못된 유형의 변수 이름을 식별합니다. 두 항목은 모두 오류 응답의 faultstring 요소에서 찾을 수 있습니다. 예를 들어 다음 faultstring에서 정책 이름은 ExecuteGeocodingRequest이고 변수는 PostalCode입니다.

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

  2. 실패한 ServiceCallout 정책 XML에서 <Request> 요소에 설정된 변수 이름이 위의 1단계의 오류 문자열에서 식별된 변수 이름과 일치하는지 확인합니다. 예를 들어 다음 정책은 faultstring의 항목과 일치하는 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>

  3. 이 변수의 유형이 메시지인지 확인합니다.

    1. 변수가 먼저 정의된 API 프록시 번들 내에서 코드를 찾습니다.
    2. 대부분의 경우 문제 변수가 ServiceCallout 정책보다 먼저 실행되는 다른 정책에서 생성되고 채워지는 것을 확인할 수 있습니다. 예를 들어 Assign Message 정책은 일반적으로 API 프록시 흐름에서 변수를 만들고 채우는 데 사용됩니다.
    3. 변수가 먼저 정의되고 채워지는 정책을 확인한 후에는 해당 변수 유형을 다음과 같이 확인해야 합니다.
      • type 속성 값(있는 경우)을 확인합니다.
      • type 속성이 없으면 변수가 문자열로 간주됩니다.
    4. 변수 유형이 메시지가 아닌 경우(예: 문자열) 이는 오류의 원인이 됩니다. 일반적인 변수 및 유형에 대해서는 흐름 변수 참조에서 자세히 알아볼 수 있습니다.

예를 들어 ServiceCallout 정책에서 참조되는 PostalCode 변수가 다음 AssignMessage 정책에서 생성되었다고 가정합니다. 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 변수가 ServiceCallout 정책의 <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 오류 메시지가 표시됩니다.

해결 방법

실패한 ServiceCallout 정책의 <Request> 요소에 설정된 변수가 message 유형 흐름 변수인지 확인하거나 ServiceCallout 정책에서 직접 새 메시지 유형 변수를 만들어(ServiceCallout 정책에 설명되어 있음) 사용할 수 있습니다.

정책을 수정하려면 <Request> 요소를 수정하여 메시지 유형의 기존 또는 새로운 변수를 지정합니다. 예를 들어 메시지 할당 정책에 설정된 변수 GeocodingRequest는 메시지 유형이며 ServiceCallout 정책에서 문제없이 작동합니다. 예를 들면 다음과 같습니다.

<?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"
        }
    }
}

원인

이 오류는 ServiceCallout 정책의 <Request> 요소에 지정된 변수가 message 유형이 아닌 경우에 발생합니다. 변수가 응답 메시지 유형, 문자열 또는 기타 유형일 경우 이 오류가 표시됩니다.

message 유형 변수는 전체 HTTP 요청 및 응답을 나타냅니다. 기본 제공 흐름 변수 request, response, message는 message 유형입니다.

진단

  1. 오류가 발생한 ServiceCallout 정책 및 잘못된 유형의 변수 이름을 식별합니다. 두 항목은 모두 오류 응답의 faultstring 요소에서 찾을 수 있습니다. 예를 들어 다음 faultstring에서 정책 이름은 ExecuteGeocodingRequest이고 변수는 var_response입니다.

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

  2. 실패한 ServiceCallout 정책 XML에서 <Request> 요소에 설정된 변수 이름이 위의 1단계의 오류 문자열에서 식별된 변수 이름과 일치하는지 확인합니다. 예를 들어 다음 정책은 faultstring의 항목과 일치하는 var_response라는 요청 변수를 지정합니다.

    <?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 프록시 번들 내에서 코드를 찾습니다.
    2. 대부분의 경우 문제 변수가 ServiceCallout 정책보다 먼저 실행되는 다른 정책에서 생성되고 채워지는 것을 확인할 수 있습니다. 예를 들어 Assign Message 정책은 일반적으로 API 프록시 흐름에서 변수를 만들고 채우는 데 사용됩니다.
    3. 변수가 먼저 정의되고 채워지는 정책을 확인한 후에는 해당 변수 유형을 다음과 같이 확인해야 합니다.
      • type 속성 값(있는 경우)을 확인합니다.
      • type 속성이 없으면 변수가 문자열로 간주됩니다.
    4. 변수 유형이 요청 메시지 유형이 아닌 경우 오류의 원인이 됩니다. 일반적인 변수 및 유형에 대해서는 흐름 변수 참조에서 자세히 알아볼 수 있습니다.

예를 들어 ServiceCallout 정책에서 참조되는 var_response 변수가 다음 Assign Message 정책에서 생성되었다고 가정합니다. 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 변수가 ServiceCallout 정책의 <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이 표시됩니다.

해결 방법

실패한 ServiceCallout 정책의 <Request> 요소에 설정된 변수가 message 유형 변수인지 확인하거나 ServiceCallout 정책에서 직접 새 요청 메시지 유형 변수를 만들어(ServiceCallout 정책에 설명되어 있음) 사용할 수 있습니다.

정책을 수정하려면 <Request> 요소를 수정하여 요청 메시지 유형인 기존 또는 새로운 변수를 지정해야 하며 ServiceCallout 정책에서 작동합니다. 예를 들면 다음과 같습니다.

<?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"
        }
    }
}

가능한 원인

이 오류의 가능한 원인은 다음과 같습니다.

원인 설명
잘못되었거나 형식이 잘못된 URL ServiceCallout 정책의 대상 URL 형식이 잘못되었거나 호스트 이름이 잘못되었거나 연결할 수 없습니다.
백엔드 서버 오류 백엔드 서버가 4XX 또는 5XX라는 오류 응답을 반환합니다.

원인: URL이 잘못되었거나 형식이 잘못됨

ServiceCallout 정책의 대상 URL 형식이 잘못되었거나 호스트 이름이 잘못되었거나 연결할 수 없습니다.

진단

  1. 오류를 발생시킨 ServiceCallout 정책을 식별합니다. 정책 이름이 오류 응답의 faultstring 요소에 표시됩니다. 예를 들어 다음 faultstring에서 실패한 ServiceCallout 정책 이름은 ExecuteGeocodingRequest입니다.

    "faultstring": "ServiceCallout[ExecuteGeocodingRequest]"

  2. 실패한 ServiceCallout 정책에서 <URL> 요소를 검사합니다. 호스트 이름이 잘못되었거나 액세스할 수 없거나 호스트 이름에 도달할 수 없는 경우 오류가 발생한 것입니다. 예를 들어 다음 ServiceCallout 정책은 잘못된 <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://만 있고 유효한 호스트 이름이 없습니다. 따라서 ServiceCallout 정책이 실패하고 Execution of ServiceCallout ExecuteGeocodingRequest failed. Reason: Host not reachable 오류가 표시됩니다.

해결 방법

실패한 ServiceCallout 정책의 <URL> 요소에 연결 가능한 호스트 이름이 있는 유효한 URL이 있는지 확인합니다.

위에 표시된 ServiceCallout 정책을 수정하려면 <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. 오류를 발생시킨 ServiceCallout 정책을 식별합니다. 정책 이름이 오류 응답의 faultstring 요소에 표시됩니다. 예를 들어 다음 faultstring에서 실패한 ServiceCallout 정책 이름은 ExecuteGeocodingRequest입니다.

    "faultstring": "ServiceCallout[ExecuteGeocodingRequest]

  2. 오류 응답 본문의 faultstring을 검토하고 Reason에 나열된 4XX 또는 5XX 응답 코드가 있는지 확인합니다. 예를 들어, 다음 faultstring은 백엔드 서버에서 응답 코드 502가 반환되었음을 명확하게 표시합니다.

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

해결 방법

오류 응답 코드를 확인한 후에는 4XX 또는 5XX 오류와 마찬가지로 이 문제를 해결할 수 있습니다.