Fehlerbehebung bei Service-Callout-Laufzeitfehlern

Sie lesen die Dokumentation zu Apigee Edge.
Sehen Sie sich die Apigee X-Dokumentation an.
info

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-Ablaufvariablen request, response und message sind vom Typ „Nachricht“. Weitere Informationen zu Nachrichtenvariablen finden Sie in der Variablenreferenz.

Diagnose

  1. 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 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 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 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 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.
    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 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

  1. 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 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 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 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 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.
    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 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>

Wie bereits erwähnt, wird die Variable var_response im Element <Request> 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

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

    "faultstring": "ServiceCallout[ExecuteGeocodingRequest]"

  2. 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 Protokoll http://, aber keinen gültigen Hostnamen. Daher schlägt die Service Callout-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 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

  1. Ermitteln Sie die Service-Callout-Richtlinie, die den Fehler verursacht hat. Der Richtlinienname wird im faultstring-Element der Fehlerantwort angezeigt. Im folgenden faultstring lautet der Name der fehlgeschlagenen Service Callout-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. In den Playbooks zu Laufzeitfehlern (4XX/5XX) finden Sie eine Anleitung zur Behebung von 4XX- oder 5XX-Fehlern.