Sie sehen sich die Dokumentation zu Apigee Edge an.
Gehen Sie zur
Apigee X-Dokumentation. Weitere Informationen
RequestVariableNotMessageType
Fehlercode
steps.servicecallout.RequestVariableNotMessageType
Fehlerantworttext
{ "fault": { "faultstring": "ServiceCallout[policy_name]: request variable [variable_name] value is not of type Message", "detail": { "errorcode": "steps.servicecallout.RequestVariableNotMessageType" } } }
Ursache
Dieser Fehler tritt auf, wenn eine Variable, die im <Request>
-Element der Service-Callout-Richtlinie angegeben ist, nicht vom Typ Message ist. Wenn die Variable ein String oder ein anderer Nicht-Nachrichtentyp ist, wird dieser Fehler angezeigt.
Nachrichtentypvariablen stellen ganze HTTP-Anfragen und -Antworten dar. Die integrierten Edge-Flussvariablen request
, response
und message
haben den Typ Nachricht. Weitere Informationen zu Nachrichtenvariablen finden Sie in der Variablenreferenz.
Diagnose
Ermitteln Sie die Service Callout-Richtlinie mit dem Fehler und den Namen der Variable, die einen unzulässigen Typ hat. Sie finden diese Informationen im Element
faultstring
der Fehlerantwort. Beispiel: Im folgendenfaultstring
lautet der RichtliniennameExecuteGeocodingRequest
und die VariablePostalCode
:"faultstring": "ServiceCallout[ExecuteGeocodingRequest]: request variable PostalCode value is not of type Message"
Prüfen Sie in der XML-Datei der fehlgeschlagenen Service-Callout-Richtlinie, ob der Name der Variablen im
<Request>
-Element mit dem im Fehlerstring angegebenen Variablennamen übereinstimmt (Schritt 1 oben). Beispiel: Die folgende Richtlinie gibt eine Anfragevariable mit dem NamenPostalCode
an, was mitfaultstring
übereinstimmt:<?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>
Bestimmen Sie, ob diese Variable vom Typ "message" ist oder nicht:
- Suchen Sie den Code innerhalb des API-Proxy-Bundles, wo die Variable zuerst definiert wurde.
- In den meisten Fällen wurde die problematische Variable in einer anderen Richtlinie erstellt und weitergegeben, die vor der Service Callout-Richtlinie ausgeführt wurde. Beispiel: Die Richtlinie "Nachricht zuweisen" wird häufig verwendet, um Variablen in einem API-Proxy-Ablauf zu erstellen und weiterzugeben.
- Nachdem Sie die Richtlinie ermittelt haben, in der die Variable zuerst definiert und ausgefüllt wird, müssen Sie den Typ dieser Variable so bestimmen:
- Prüfen Sie den Wert des
type
-Attributs (falls vorhanden). - Ist das Attribut
type
nicht vorhanden, so wird die Variable als String betrachtet.
- Prüfen Sie den Wert des
- Ist der Typ der Variablen nicht "Message" (z. B. ein String), so ist dies die Ursache des Fehlers. Weitere Informationen zu gängigen Variablen und ihren Typen finden sich in der Variablenreferenz.
Beispiel: Die Variable PostalCode
, auf die in der Service Callout-Richtlinie verwiesen wird, wurde in der folgenden "Nachricht zuweisen"-Richtlinie erstellt. Beachten Sie, dass PostalCode
der Wert der Ablaufvariablen request.queryparam.postalcode
zugewiesen wird. Dieser Wert ist ein String, da in der Variablenzuweisung kein type
-Attribut vorhanden ist.
<?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>
Denken Sie daran, dass die Variable PostalCode
im Element <Request>
der Service Callout-Richtlinie verwendet wird:
<?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>
Da PostalCode
nicht vom Typ "Message" ist (in diesem Beispiel ist es ein String) erhalten Sie den Fehlercode: steps.servicecallout.RequestVariableNotMessageType
.
Lösung
Die Variable, die im <Request>
-Element in der fehlgeschlagenen Service-Callout-Richtlinie festgelegt ist, ist eine Variable des Typs Message und vorhanden. Alternativ können Sie direkt in der Service Callout-Richtlinie eine neue Nachrichtentypvariable erstellen (wie in der Richtliniendokumentation erläutert) und verwenden.
Um die Richtlinie zu korrigieren, müssen Sie das Element <Request>
ändern, um eine vorhandene oder neue Variable vom Typ "Message" anzugeben. Beispiel: Die Variable GeocodingRequest
, die in der Richtlinie "Nachricht zuweisen" festgelegt wurde, ist vom Typ "Message" und funktioniert in der Service Callout-Richtlinie korrekt. Beispiel:
<?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
Fehlercode
steps.servicecallout.RequestVariableNotRequestMessageType
Fehlerantworttext
{ "fault": { "faultstring": "ServiceCallout[policy_name]: request variable [variable_name] value is not of type Request Message", "detail": { "errorcode": "steps.servicecallout.RequestVariableNotRequestMessageType" } } }
Ursache
Dieser Fehler tritt auf, wenn eine Variable, die im <Request>
-Element der Service-Callout-Richtlinie angegeben ist, nicht vom Typ Anfragenachricht ist. Wenn die Variable ein Antworttyp, ein String oder ein anderer Typ ist, wird dieser Fehler angezeigt.
Nachrichtentypvariablen stellen ganze HTTP-Anfragen und -Antworten dar. Die integrierten Edge-Flussvariablen request
, response
und message
haben den Typ Nachricht. Weitere Informationen zu Nachrichtenvariablen finden sich in der Variablenreferenz.
Diagnose
Ermitteln Sie die Service Callout-Richtlinie mit dem Fehler und den Namen der Variable, die einen unzulässigen Typ hat. Sie finden diese Informationen im Element
faultstring
der Fehlerantwort. Beispiel: Im folgendenfaultstring
lautet der RichtliniennameExecuteGeocodingRequest
und die Variablevar_response
:"faultstring": "ServiceCallout[ExecuteGeocodingRequest]: request variable var_response value is not of type Message"
Prüfen Sie in der XML-Datei der fehlgeschlagenen Service-Callout-Richtlinie, ob der Name der Variablen im
<Request>
-Element mit dem im Fehlerstring angegebenen Variablennamen übereinstimmt (Schritt 1 oben). Beispiel: Die folgende Richtlinie gibt eine Anfragevariable mit dem Namenvar_response
an, was mitfaultstring
übereinstimmt:<?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>
Prüfen Sie, ob die Variable den Typ "Anfragenachricht" hat oder nicht:
- Suchen Sie den Code innerhalb des API-Proxy-Bundles, wo die Variable zuerst definiert wurde.
- In den meisten Fällen wurde die problematische Variable in einer anderen Richtlinie erstellt und weitergegeben, die vor der Service Callout-Richtlinie ausgeführt wurde. Beispiel: Die Richtlinie "Nachricht zuweisen" wird häufig verwendet, um Variablen in einem API-Proxy-Ablauf zu erstellen und weiterzugeben.
- Nachdem Sie die Richtlinie ermittelt haben, in der die Variable zuerst definiert und ausgefüllt wird, müssen Sie den Typ dieser Variable so bestimmen:
- Prüfen Sie den Wert des
type
-Attributs (falls vorhanden). - Ist das Attribut
type
nicht vorhanden, so wird die Variable als String betrachtet.
- Prüfen Sie den Wert des
- Wenn der Typ der Variablen nicht vom Typ Anfragenachricht ist, ist dies die Ursache des Fehlers. Weitere Informationen zu gängigen Variablen und ihren Typen finden Sie in der Variablenreferenz.
Beispiel: Die Variable var_response
, auf die in der Service Callout-Richtlinie verwiesen wird, wurde in der folgenden "Nachricht zuweisen"-Richtlinie erstellt. Beachten Sie, dass var_response
den Typ response
erhält. Daher ist der Typ der Variablen var_response
"Antwortnachricht".
<?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>
Zur Erinnerung: Die Variable var_response
wird im <Request>
-Element der Service Callout-Richtlinie verwendet.
<?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>
Da es sich bei var_response
nicht um eine Anfragenachricht handelt (vom Typ her ist es eine Antwortnachricht) erhalten Sie den Fehlercode: steps.servicecallout.RequestVariableNotRequestMessageType
.
Lösung
Die Variable, die im <Request>
-Element in der fehlgeschlagenen Service-Callout-Richtlinie festgelegt ist, ist eine Variable des Typs Anforderungsnachricht und vorhanden. Alternativ können Sie direkt in der Service Callout-Richtlinie eine neue Anforderungsnachrichtenvariable erstellen (wie in der Richtliniendokumentation erläutert) und verwenden.
Um die Richtlinie zu korrigieren, müssen Sie das Element <Request>
ändern, um eine vorhandene oder neue Anfragenachrichtvariable anzugeben, die in der Service Callout-Richtlinie korrekt verarbeitet wird. Beispiel:
<?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
Fehlercode
steps.servicecallout.ExecutionFailed
Fehlerantworttext
{ "fault": { "faultstring": "Execution of ServiceCallout [policy_name] failed. Reason: Host not reachable", "detail": { "errorcode": "steps.servicecallout.ExecutionFailed" } } }
oder
{ "fault": { "faultstring": "Execution of ServiceCallout [policy_name] failed. Reason: ResponseCode [http_code] is treated as error", "detail": { "errorcode": "steps.servicecallout.ExecutionFailed" } } }
Mögliche Ursachen
Mögliche Ursachen für diesen Fehler:
Ursache | Beschreibung |
Ungültige oder fehlerhafte URL | Die Ziel-URL in der Service Callout-Richtlinie ist fehlerhaft oder weist einen ungültigen oder nicht erreichbaren Hostnamen auf. |
Back-End-Serverfehler | Der Back-End-Server gibt die Fehlerantwort 4XX oder 5XX zurück. |
Ursache: Ungültige oder fehlerhafte URL
Die Ziel-URL in der Service Callout-Richtlinie ist fehlerhaft oder weist einen ungültigen oder nicht erreichbaren Hostnamen auf.
Diagnose
Ermitteln Sie die Service-Callout-Richtlinie, die den Fehler verursacht hat. Der Richtlinienname wird im
faultstring
-Element der Fehlerantwort angezeigt. Im folgendenfaultstring
lautet der Name der fehlgeschlagenen Service-Callout-Richtlinie beispielsweiseExecuteGeocodingRequest
."faultstring": "ServiceCallout[ExecuteGeocodingRequest]"
Prüfen Sie in der fehlgeschlagenen Service-Callout-Richtlinie das Element
<URL>
. Wenn es fehlerhaft ist oder einen ungültigen oder nicht erreichbaren Hostnamen aufweist, ist dies der Grund für diesen Fehler. Beispiel: Die folgende Service Callout-Richtlinie gibt ein ungültiges<URL>
an:<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ServiceCallout name="ExecuteGeocodingRequest"> <Request variable="GeocodingRequest"/> <Response>GeocodingResponse</Response> <HTTPTargetConnection> <URL>http://</URL> </HTTPTargetConnection> </ServiceCallout>
Das
<URL>
-Element hat nur das Protokollhttp://
, aber keinen gültigen Hostnamen. Daher schlägt die Service Callout-Richtlinie mit dem FehlerExecution of ServiceCallout ExecuteGeocodingRequest failed. Reason: Host not reachable
fehl.
Lösung
Sorgen Sie dafür, dass das Element <URL>
in der fehlgeschlagenen Service-Callout-Richtlinie eine gültige URL mit einem erreichbaren Hostnamen enthält.
Um die oben gezeigte Service Callout-Richtlinie zu korrigieren, ändern Sie das Element <URL>
und geben eine gültige URL an:
<?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>
Ursache: Back-End-Serverfehler
Der Back-End-Server gibt die Fehlerantwort 4XX oder 5XX zurück.
Diagnose
Ermitteln Sie die Service-Callout-Richtlinie, die den Fehler verursacht hat. Der Richtlinienname wird im
faultstring
-Element der Fehlerantwort angezeigt. Im folgendenfaultstring
lautet der Name der fehlgeschlagenen Service Callout-Richtlinie beispielsweiseExecuteGeocodingRequest
."faultstring": "ServiceCallout[ExecuteGeocodingRequest]
Prüfen Sie das
faultstring
im Fehlerantworttext und sehen Sie nach, ob imReason
ein Antwortcode vom Typ 4XX oder 5XX aufgeführt wird. Beispiel: Der folgende Fehlerstring gibt klar an, dass der Antwortcode 502 vom Back-End-Server zurückgegeben wurde:"faultstring": "Execution of ServiceCallout ExecuteGeocodingRequest failed. Reason: ResponseCode 502 is treated as error"
Lösung
Sobald Sie den Fehlerantwortcode ermittelt haben, können Sie das Problem wie jeden beliebigen Fehler vom Typ 4XX oder 5XX beheben. In den Playbooks zu Laufzeitfehlern (4XX/5XX) finden Sie eine Anleitung zur Behebung von 4XX- oder 5XX-Fehlern.