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 유형입니다.
진단
오류가 발생한 ServiceCallout 정책 및 잘못된 유형의 변수 이름을 식별합니다. 두 항목은 모두 오류 응답의
faultstring요소에서 찾을 수 있습니다. 예를 들어 다음faultstring에서 정책 이름은ExecuteGeocodingRequest이고 변수는PostalCode입니다."faultstring": "ServiceCallout[ExecuteGeocodingRequest]: request variable PostalCode value is not of type Message"실패한 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>이 변수의 유형이 메시지인지 확인합니다.
- 변수가 먼저 정의된 API 프록시 번들 내에서 코드를 찾습니다.
- 대부분의 경우 문제 변수가 ServiceCallout 정책보다 먼저 실행되는 다른 정책에서 생성되고 채워지는 것을 확인할 수 있습니다. 예를 들어 Assign Message 정책은 일반적으로 API 프록시 흐름에서 변수를 만들고 채우는 데 사용됩니다.
- 변수가 먼저 정의되고 채워지는 정책을 확인한 후에는 해당 변수 유형을 다음과 같이 확인해야 합니다.
type속성 값(있는 경우)을 확인합니다.type속성이 없으면 변수가 문자열로 간주됩니다.
- 변수 유형이 메시지가 아닌 경우(예: 문자열) 이는 오류의 원인이 됩니다. 일반적인 변수 및 유형에 대해서는 흐름 변수 참조에서 자세히 알아볼 수 있습니다.
예를 들어 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 유형입니다.
진단
오류가 발생한 ServiceCallout 정책 및 잘못된 유형의 변수 이름을 식별합니다. 두 항목은 모두 오류 응답의
faultstring요소에서 찾을 수 있습니다. 예를 들어 다음faultstring에서 정책 이름은ExecuteGeocodingRequest이고 변수는var_response입니다."faultstring": "ServiceCallout[ExecuteGeocodingRequest]: request variable var_response value is not of type Message"실패한 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>변수가 요청 메시지 유형인지 확인합니다.
- 변수가 먼저 정의된 API 프록시 번들 내에서 코드를 찾습니다.
- 대부분의 경우 문제 변수가 ServiceCallout 정책보다 먼저 실행되는 다른 정책에서 생성되고 채워지는 것을 확인할 수 있습니다. 예를 들어 Assign Message 정책은 일반적으로 API 프록시 흐름에서 변수를 만들고 채우는 데 사용됩니다.
- 변수가 먼저 정의되고 채워지는 정책을 확인한 후에는 해당 변수 유형을 다음과 같이 확인해야 합니다.
type속성 값(있는 경우)을 확인합니다.type속성이 없으면 변수가 문자열로 간주됩니다.
- 변수 유형이 요청 메시지 유형이 아닌 경우 오류의 원인이 됩니다. 일반적인 변수 및 유형에 대해서는 흐름 변수 참조에서 자세히 알아볼 수 있습니다.
예를 들어 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 형식이 잘못되었거나 호스트 이름이 잘못되었거나 연결할 수 없습니다.
진단
오류를 발생시킨 ServiceCallout 정책을 식별합니다. 정책 이름이 오류 응답의
faultstring요소에 표시됩니다. 예를 들어 다음faultstring에서 실패한 ServiceCallout 정책 이름은ExecuteGeocodingRequest입니다."faultstring": "ServiceCallout[ExecuteGeocodingRequest]"실패한 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라는 오류 응답을 반환합니다.
진단
오류를 발생시킨 ServiceCallout 정책을 식별합니다. 정책 이름이 오류 응답의
faultstring요소에 표시됩니다. 예를 들어 다음faultstring에서 실패한 ServiceCallout 정책 이름은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 오류와 마찬가지로 이 문제를 해결할 수 있습니다.