Fehlerbehebung bei HTTP 404- und HTTP 500-Fehlern in SOAP-basierten APIs

Zusammenfassung

In diesem Artikel wird erläutert, wie Sie eine SOAP-basierte API behandeln, die HTTP 404- und HTTP 500-Fehler in Azure API Management zurückgibt.

Dieser Artikel ist das zweite Szenario des Azure API Management Problembehandlungs-Reihenlabors. Stellen Sie sicher, dass Sie die Anweisungen zum Einrichten der Laborumgebung gemäß den Laboranweisungen der Reihe zur Problembehandlung von API Management befolgen.

Ursprüngliche Produktversion: API-Verwaltungsdienst
Ursprüngliche KB-Nummer: 4464934

Symptome

Die unter http://www.dneonline.com/calculator.asmx verfügbare Rechner-API führt vier Operationen aus: Addieren, Subtrahieren, Multiplizieren und Dividieren, auf Grundlage von zwei Eingabeparametern: intA und intB. Diese API verwendet einen ASMX-dateibasierten Dienst, der das SOAP-Protokoll (Simple Object Access Protocol) 1.1 verwendet, sodass die Eingabeparameter im SOAP-Umschlagtext übergeben werden.

In diesem Szenario funktionieren die Operationen Hinzufügen und Subtrahieren wie erwartet, aber beim Ausführen der Operation Multiplizieren treten HTTP 404-Fehler auf und bei der Operation DividierenHTTP 500-Fehler.

Die erwartete Ausgabe eines Multiplikationsvorgangs sollte etwa wie im folgenden Beispiel aussehen:

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <soap:Body>
      <MultiplyResponse xmlns="http://tempuri.org/">
         <MultiplyResult>int</MultiplyResult>
      </MultiplyResponse>
   </soap:Body>
</soap:Envelope>

Die erwartete Ausgabe eines Dividierenvorgangs sollte etwa wie im folgenden Beispiel aussehen:

<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   <soap:Body>
      <DivideResponse xmlns="http://tempuri.org/">
         <DivideResult>int</DivideResult>
      </DivideResponse>
   </soap:Body>
</soap:Envelope>

Troubleshooting

Um zu ermitteln, welche Ursachen die HTTP 404- und HTTP 500-Antworten verursachen (unabhängig davon, ob es sich um die API-Verwaltung oder die Back-End-SOAP-API handelt), sammeln Sie eine API-Verwaltungsinspektorablaufverfolgung , um die Anforderung und Antwort zu prüfen.

Wenn mehrere Vorgänge HTTP 404 - oder HTTP 500-Fehler verursachen, weist sie darauf hin, dass der Ursprungsserver keine aktuelle Darstellung für die Zielressource finden kann oder nicht offenlegen kann, dass vorhanden ist.

Wenn Sie den Back-End-Abschnitt einer API Management Inspector-Ablaufverfolgung untersuchen, wird dieselbe Beobachtung aus der Meldung ersichtlich, wie im folgenden Beispiel gezeigt:

    {
      "backend": [
        {
          "source": "configuration",
          "timestamp": "2018-07-29T12:30:08.3500317Z",
          "elapsed": "00:00:00.7276962",
          "data": {
            "message": "Unable to identify Api or Operation for this request. Responding to the caller with 404 Resource Not Found."
          }
        }
      ]
    }

Sie müssen zunächst die Anfrage-URL und die Header untersuchen, die von API Management aus Test an die Backend-API gesendet werden, und sie mit einem Beispiel einer SOAP-Anfrage für die Operation Multiply vergleichen, die Sie unter http://www.dneonline.com/calculator.asmx ausgeführt haben.

Die Header einer Anforderung aus einer Inspector-Ablaufverfolgung in API Management sehen in etwa wie im folgenden Beispiel aus:

    {
      "data": {
        "request": {
          "method": "POST",
          "url": "https://pratyay.azure-api.net/calc",
          "headers": [
            {
              "name": "Ocp-Apim-Subscription-Key",
              "value": "34ae22db7f2c4c5da7b74a55adf03223"
            },
            {
              "name": "X-Forwarded-For",
              "value": "223.226.79.35"
            },
            {
              "name": "Cache-Control",
              "value": "no-cache"
            },
            {
              "name": "Connection",
              "value": "Keep-Alive"
            },
            {
              "name": "Content-Length",
              "value": "292"
            },
            {
              "name": "Content-Type",
              "value": "application/soap+xml; action=http://tempuri.org/Multiply"
            },
            {
              "name": "Accept",
              "value": "*/*"
            },
            {
              "name": "Accept-Encoding",
              "value": "gzip,deflate,br"
            },
            {
              "name": "Accept-Language",
              "value": "en-US,en;q=0.5"
            },
            {
              "name": "Host",
              "value": "pratyay.azure-api.net"
            },
            {
              "name": "Referer",
              "value": "https://apimanagement.hosting.portal.azure.net/apimanagement/Content/1.0.385.3/apimap/apimap-apis/index.html?locale=en&trustedAuthority=https://ms.portal.azure.com"
            }
          ]
        }
      }
    }

Die SOAP 1.1-Anforderung benötigt einen Anforderungsheader SOAPAction , der in der ursprünglichen Anforderung fehlt, die von der API-Verwaltung gesendet wird, wie im folgenden Beispiel gezeigt:

    Host: www.dneonline.com
    Content-Type: text/xml; charset=utf-8
    Content-Length: length
    SOAPAction: "http://tempuri.org/Multiply"

Das Hinzufügen der SOAPAction Kopfzeile mit dem Wert http://tempuri.org/Multiply löst das Problem. Fügen Sie den Anforderungsheader unter der Frontend Definition des Multipliziervorgangs hinzu, und legen Sie dann den Wert als Standardwert auf der Registerkarte " Kopfzeilen " fest. Sie müssen diesen Headerwert nicht mehr für jede Anforderung senden.

Screenshot der Registerkarte „Header“ der Operation „Multiply“ mit dem SOAPAction-Header und seinem Standardwert.

Ein Divide-Vorgang, der zu HTTP 500 (Interner Serverfehler)-Fehlern führt, weist darauf hin, dass der Server auf einen unerwarteten Zustand gestoßen ist, der ihn daran gehindert hat, die Anfrage zu verarbeiten. Diese Bedingung bedeutet, dass der Back-End-Dienst Ihren Anforderungstext nicht verarbeiten kann, der von der API-Verwaltung gesendet wurde.

Sie können nun den Anforderungstext untersuchen, der von der API-Verwaltung gesendet wird. Der Nenner (intB) wird auf Null festgelegt, was zu einer unbehandelten Ausnahme führt. Diese Bedingung ist die Ursache des HTTP 500 (Interner Serverfehler).

Das folgende Beispiel zeigt den Anforderungstext, der von der API Management Inspector-Ablaufverfolgung für einen Dividieren-Vorgang gesendet wird:

    POST calc HTTP/1.1
    
    Host: pratyay.azure-api.net
    SOAPAction: http://tempuri.org/Divide
    Cache-Control: no-cache
    Ocp-Apim-Trace: true
    Content-Type: application/soap+xml; action=http://tempuri.org/Divide
    Ocp-Apim-Subscription-Key: ********************************
    
    <?xml version="1.0" encoding="utf-8"?>
    <Envelope xmlns="http://www.w3.org/2003/05/soap-envelope">
      <Body>
        <Divide xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://tempuri.org/">
          <intA>1</intA>
          <intB>0</intB>
        </Divide>
      </Body>
    </Envelope>

Wenn Sie die Anforderungsinhaltsdarstellung auf der Registerkarte "Anforderung " überprüfen, die in der Frontend Definition des Dividieren-Vorgangs vorhanden ist, können Sie sehen, dass der IntB-Wert auf Null festgelegt ist. Ändern Sie den Wert von intB in einen Wert ungleich null. Diese Änderung sollte das Problem beheben.

Bildschirmaufnahme der Registerkarte „Anforderung“ des Divide-Vorgangs, wobei der intB-Eingabewert auf null gesetzt ist.