Fehlerbehebung bei ServiceCallout-Laufzeitfehlern

Sie lesen gerade die Dokumentation zu Apigee und Apigee Hybrid.
Apigee Edge-Dokumentation aufrufen.

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 im Element <Request> der ServiceCallout-Richtlinie angegebene Variable 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 Ablaufvariablen request, response und message sind vom Typ message.

Diagnose

  1. Ermitteln Sie die ServiceCallout-Richtlinie mit dem Fehler und den Namen der Variable, die einen unzulässigen Typ hat. Sie finden beide Elemente im Element faultstring der Fehlerantwort. Beispiel: Im folgenden faultstring lautet der Richtlinienname ExecuteGeocodingRequest und die Variable PostalCode:

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

  2. Prüfen Sie in der XML-Datei der fehlgeschlagenen ServiceCallout-Richtlinie, ob der Name der Variablen im Element <Request> mit dem im Fehlerstring angegebenen Variablennamen übereinstimmt (Schritt 1 oben). Beispiel: Die folgende Richtlinie gibt eine Anfragevariable mit dem Namen PostalCode an, was mit faultstring ü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>

  3. Bestimmen Sie, ob diese Variable vom Typ "message" ist oder nicht:

    1. Suchen Sie den Code innerhalb des API-Proxy-Bundles, wo die Variable zuerst definiert wurde.
    2. In den meisten Fällen wurde die problematische Variable in einer anderen Richtlinie erstellt und weitergegeben, die vor der ServiceCallout-Richtlinie ausgeführt wurde. Beispiel: Die Richtlinie "Nachricht zuweisen" wird häufig verwendet, um Variablen in einem API-Proxy-Ablauf zu erstellen und weiterzugeben.
    3. 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.
    4. 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 Sie in der Referenz zu Ablaufvariablen.

Beispiel: Die Variable PostalCode, auf die in der ServiceCallout-Richtlinie verwiesen wird, wurde in der folgenden AssignMessage-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 ServiceCallout-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

Achten Sie darauf, dass die im Element <Request> in der fehlgeschlagene ServiceCallout-Richtlinie angegebene Variable eine vorhandene Ablaufvariable vom Typ message ist. Alternativ können Sie direkt in der ServiceCallout-Richtlinie eine neue Nachrichtentypvariable erstellen (wie in der ServiceCallout-Richtlinie 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 „Nachricht zuweisen“-Richtlinie festgelegt wurde, ist vom Typ „Message“ und funktioniert in der ServiceCallout-Richtlinie korrekt. Beispiele:

<?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 im Element <Request> der ServiceCallout-Richtlinie angegebene Variable nicht vom Typ message ist. Wenn die Variable ein Antworttyp, ein String oder ein anderer Typ ist, wird dieser Fehler angezeigt.

Die Variable vom Typ message stellt alle HTTP-Anfragen und -Antworten dar. Die integrierten Ablaufvariablen request, response und message sind vom Typ message.

Diagnose

  1. Ermitteln Sie die ServiceCallout-Richtlinie mit dem Fehler und den Namen der Variable, die einen unzulässigen Typ hat. Sie finden beide Elemente im Element faultstring der Fehlerantwort. Beispiel: Im folgenden faultstring lautet der Richtlinienname ExecuteGeocodingRequest und die Variable var_response:

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

  2. Prüfen Sie in der XML-Datei der fehlgeschlagenen ServiceCallout-Richtlinie, ob der Name der Variablen im Element <Request> mit dem im Fehlerstring angegebenen Variablennamen übereinstimmt (Schritt 1 oben). Beispiel: Die folgende Richtlinie gibt eine Anfragevariable mit dem Namen var_response an, was mit faultstring ü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>

  3. Prüfen Sie, ob die Variable den Typ "Anfragenachricht" hat oder nicht:

    1. Suchen Sie den Code innerhalb des API-Proxy-Bundles, wo die Variable zuerst definiert wurde.
    2. In den meisten Fällen wurde die problematische Variable in einer anderen Richtlinie erstellt und weitergegeben, die vor der ServiceCallout-Richtlinie ausgeführt wurde. Beispiel: Die Richtlinie "Nachricht zuweisen" wird häufig verwendet, um Variablen in einem API-Proxy-Ablauf zu erstellen und weiterzugeben.
    3. 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.
    4. 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 Referenz zu Ablaufvariablen.

Beispiel: Die Variable var_response, auf die in der ServiceCallout-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>

Beachten Sie, dass die Variable var_response im Element <Request> der ServiceCallout-Richtlinie verwendet wird.

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

Achten Sie darauf, dass die im Element <Request> in der fehlgeschlagene ServiceCallout-Richtlinie angegebene Variable eine vorhandene Variable vom Typ message ist. Alternativ können Sie direkt in der ServiceCallout-Richtlinie eine neue Anfragenachrichtentypvariable erstellen (wie in der ServiceCallout-Richtlinie 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 ServiceCallout-Richtlinie korrekt verarbeitet wird. Beispiele:

<?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 ServiceCallout-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 ServiceCallout-Richtlinie ist fehlerhaft oder weist einen ungültigen oder nicht erreichbaren Hostnamen auf.

Diagnose

  1. Ermitteln Sie die ServiceCallout-Richtlinie, die den Fehler verursacht hat. Der Richtlinienname wird im faultstring-Element der Fehlerantwort angezeigt. Im folgenden faultstring lautet der Name der fehlgeschlagenen ServiceCallout-Richtlinie beispielsweise ExecuteGeocodingRequest.

    "faultstring": "ServiceCallout[ExecuteGeocodingRequest]"

  2. Prüfen Sie in der fehlgeschlagenen ServiceCallout-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 CalloutRichtlinie 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 Protokoll http://, aber keinen gültigen Hostnamen. Daher schlägt die ServiceCallout-Richtlinie mit dem Fehler Execution of ServiceCallout ExecuteGeocodingRequest failed. Reason: Host not reachable fehl.

Lösung

Sorgen Sie dafür, dass das Element <URL> in der fehlgeschlagenen ServiceCallout-Richtlinie eine gültige URL mit einem erreichbaren Hostnamen enthält.

Um die oben gezeigte ServiceCallout-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

  1. Ermitteln Sie die ServiceCallout-Richtlinie, die den Fehler verursacht hat. Der Richtlinienname wird im faultstring-Element der Fehlerantwort angezeigt. Im folgenden faultstring lautet der Name der fehlgeschlagenen ServiceCallout-Richtlinie beispielsweise ExecuteGeocodingRequest.

    "faultstring": "ServiceCallout[ExecuteGeocodingRequest]

  2. Prüfen Sie das faultstring im Fehlerantworttext und sehen Sie nach, ob im Reason 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.