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
faultstringder Fehlerantwort. Beispiel: Im folgendenfaultstringlautet der RichtliniennameExecuteGeocodingRequestund 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 NamenPostalCodean, 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
typenicht 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
faultstringder Fehlerantwort. Beispiel: Im folgendenfaultstringlautet der RichtliniennameExecuteGeocodingRequestund 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_responsean, 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
typenicht 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 folgendenfaultstringlautet 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 reachablefehl.
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 folgendenfaultstringlautet der Name der fehlgeschlagenen Service Callout-Richtlinie beispielsweiseExecuteGeocodingRequest."faultstring": "ServiceCallout[ExecuteGeocodingRequest]Prüfen Sie das
faultstringim Fehlerantworttext und sehen Sie nach, ob imReasonein 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.