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>
요소에 지정된 변수가 메시지 유형이 아닌 경우에 발생합니다. 변수가 문자열 또는 기타 메시지 외 유형이면 이 오류가 표시됩니다.
메시지 유형 변수는 전체 HTTP 요청 및 응답을 나타냅니다. 기본 제공 Edge 흐름 변수 request
, response
, message
는 메시지 유형입니다. message 변수에 대한 자세한 내용은 변수 참조를 확인하세요.
진단
오류가 발생한 서비스 콜아웃 정책과 유형이 잘못된 변수의 이름을 확인합니다. 두 항목은 모두 오류 응답의
faultstring
요소에서 찾을 수 있습니다. 예를 들어 다음faultstring
에서 정책 이름은ExecuteGeocodingRequest
이고 변수는PostalCode
입니다."faultstring": "ServiceCallout[ExecuteGeocodingRequest]: request variable PostalCode value is not of type Message"
실패한 서비스 콜아웃 정책 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>
이 변수의 유형이 메시지인지 확인합니다.
- 변수가 먼저 정의된 API 프록시 번들 내에서 코드를 찾습니다.
- 대부분의 경우 문제 변수가 Service Callout 정책보다 먼저 실행되는 다른 정책에서 생성되고 채워지는 것을 확인할 수 있습니다. 예를 들어 Assign Message 정책은 일반적으로 API 프록시 흐름에서 변수를 만들고 채우는 데 사용됩니다.
- 변수가 먼저 정의되고 채워지는 정책을 확인한 후에는 해당 변수 유형을 다음과 같이 확인해야 합니다.
type
속성 값(있는 경우)을 확인합니다.type
속성이 없으면 변수가 문자열로 간주됩니다.
- 변수 유형이 메시지가 아닌 경우(예: 문자열) 이는 오류의 원인이 됩니다. 일반적인 변수 및 유형에 대해서 알아보려면 변수 참조를 확인하세요.
예를 들어 서비스 콜아웃 정책에서 참조된 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>
요소에 지정된 변수가 요청 메시지 유형이 아닌 경우에 발생합니다. 변수가 응답 메시지 유형, 문자열 또는 기타 유형일 경우 이 오류가 표시됩니다.
메시지 유형 변수는 전체 HTTP 요청 및 응답을 나타냅니다. 기본 제공 Edge 흐름 변수 request
, response
, message
는 메시지 유형입니다. message 변수에 대한 자세한 내용은 변수 참조를 확인하세요.
진단
오류가 발생한 Service Callout 정책 및 잘못된 유형의 변수 이름을 식별합니다. 두 항목은 모두 오류 응답의
faultstring
요소에서 찾을 수 있습니다. 예를 들어 다음faultstring
에서 정책 이름은ExecuteGeocodingRequest
이고 변수는var_response
입니다."faultstring": "ServiceCallout[ExecuteGeocodingRequest]: request variable var_response value is not of type Message"
실패한 서비스 콜아웃 정책 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>
변수가 요청 메시지 유형인지 확인합니다.
- 변수가 먼저 정의된 API 프록시 번들 내에서 코드를 찾습니다.
- 대부분의 경우 문제 변수가 Service Callout 정책보다 먼저 실행되는 다른 정책에서 생성되고 채워지는 것을 확인할 수 있습니다. 예를 들어 Assign Message 정책은 일반적으로 API 프록시 흐름에서 변수를 만들고 채우는 데 사용됩니다.
- 변수가 먼저 정의되고 채워지는 정책을 확인한 후에는 해당 변수 유형을 다음과 같이 확인해야 합니다.
type
속성 값(있는 경우)을 확인합니다.type
속성이 없으면 변수가 문자열로 간주됩니다.
- 변수 유형이 요청 메시지 유형이 아닌 경우 오류의 원인이 됩니다. 일반적인 변수 및 유형에 대해서 알아보려면 변수 참조를 확인하세요.
예를 들어 Service Callout 정책에서 참조되는 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
변수가 서비스 콜아웃 정책의 <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" } } }
가능한 원인
이 오류의 가능한 원인은 다음과 같습니다.
원인 | 설명 |
잘못되었거나 형식이 잘못된 URL | 서비스 콜아웃 정책의 대상 URL 형식이 잘못되었거나 호스트 이름이 잘못되었거나 연결할 수 없습니다. |
백엔드 서버 오류 | 백엔드 서버가 4XX 또는 5XX라는 오류 응답을 반환합니다. |
원인: URL이 잘못되었거나 형식이 잘못됨
Service Callout 정책의 대상 URL 형식이 잘못되었거나 호스트 이름이 잘못되었거나 연결할 수 없습니다.
진단
오류를 일으킨 서비스 콜아웃 정책을 확인합니다. 정책 이름이 오류 응답의
faultstring
요소에 표시됩니다. 예를 들어 다음faultstring
에서 실패한 서비스 콜아웃 정책의 이름은ExecuteGeocodingRequest
입니다."faultstring": "ServiceCallout[ExecuteGeocodingRequest]"
실패한 서비스 콜아웃 정책에서
<URL>
요소를 검사합니다. 호스트 이름이 잘못되었거나 액세스할 수 없거나 호스트 이름에 도달할 수 없는 경우 오류가 발생한 것입니다. 예를 들어 다음 Service Callout 정책은 잘못된<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
오류가 표시됩니다.
해결 방법
실패한 Service Callout 정책의 <URL>
요소에 연결 가능한 호스트 이름이 있는 유효한 URL이 있는지 확인합니다.
위에 표시된 서비스 콜아웃 정책을 수정하려면 <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라는 오류 응답을 반환합니다.
진단
오류를 발생시킨 Service Callout 정책을 식별합니다. 정책 이름이 오류 응답의
faultstring
요소에 표시됩니다. 예를 들어 다음faultstring
에서 실패한 서비스 콜아웃 정책의 이름은ExecuteGeocodingRequest
입니다."faultstring": "ServiceCallout[ExecuteGeocodingRequest]
오류 응답 본문의
faultstring
을 검토하고Reason
에 나열된 4XX 또는 5XX 응답 코드가 있는지 확인합니다. 예를 들어, 다음 faultstring은 백엔드 서버에서 응답 코드 502가 반환되었음을 명확하게 표시합니다."faultstring": "Execution of ServiceCallout ExecuteGeocodingRequest failed. Reason: ResponseCode 502 is treated as error"
해결 방법
오류 응답 코드를 확인한 후에는 4XX 또는 5XX 오류와 마찬가지로 이 문제를 해결할 수 있습니다. 4XX 또는 5XX 오류의 문제 해결 및 해결 방법에 관한 안내는 런타임 오류 (4XX/5XX) 플레이북을 참고하세요.