Um im Rahmen des Multi-step API Monitorings einen Prüfpunkt zur Inhaltsprüfung einzurichten oder einen Wert zur Speicherung als Variable zu extrahieren, musst Du spezifizieren, welchen Wert wir berücksichtigen sollen. Es gibt die folgenden Möglichkeiten:

  • Response body as JSON: Wähle diese Option, wenn der Inhalt der Antwort JSON-Daten enthält und Du ein bestimmtes Element in der JSON-Struktur untersuchen oder aufzeichnen möchtest. Gib im Feld für Eigenschaften der Prüfpunkte oder Variablen an, welches JSON-Element wir untersuchen sollen.

    Beispiel

    Nehmen wir an, die JSON-Antwort hat folgenden Inhalt:

    {
      "access_token":"MjAxNy0xMC0wMlQxMDoxMDoyNy42NDkwOTEzWg==",
      "token_type":"Bearer",
      "expires_in":86400
    }

    Um den Wert des Attributs access_token aufzuzeichnen, gib access_token als Eigenschaft an.

    Ein anderes JSON-Beispiel: Nehmen wir an, Deine JSON-Daten enthalten ein Array eines oder mehrerer Elemente, in diesem Fall eine Reihe von drei Produkten:

    [
      {
        "Name": "Alpha Cygnus IX",
        "Price": 20000,
      },
      {
        "Name": "Norcadia Prime",
        "Price": 25000,
      },
      {
        "Name": "Risa",
        "Price": 37500,
      }
    ]

    Um ein Attribut eines dieser Produkte zu erhalten, müssen wir zunächst auf ein besonderes Element der Reihe durch Bereitstellen eines Index zeigen. Der Index des ersten Elements in einem JSON-Array ist immer Null: [0]. Um also das Attribut „Price“ des ersten Produkts in unserem Array zu erfassen, würden wir [0].Price angeben.

    Hinweis: Wenn der Antwortinhalt nicht als JSON geparst werden kann, wird diese Funktion einen Fehler erzeugen.

  • Response body as XML: Wenn der Inhalt der Antwort ein XML-Dokument enthält, wähle diese Option und bestimme eine XPath-Anfrage, um einzugrenzen, welcher Inhalt untersucht oder aufgezeichnet werden soll.

    Beispiel

    Nehmen wir an, die XML-Antwort hat folgenden Inhalt:

    <AuthInfo>
      <access_token>MjAxNy0xMC0wMlQxMDowOTo1My45MDUxNjEyWg==</access_token>
      <expires_in>86400</expires_in>
      <token_type>Bearer</token_type>
    </AuthInfo>

    To capture the inner value of the access_token aufzuzeichnen, verwende die XPath-Anfrage /AuthInfo/access_token/text() als Eigenschaft.

    Wenn der Antwortinhalt nicht als eigenständiges XML-Dokument geparst werden kann, wenn die XPath-Anfrage ungültig ist oder keinen tatsächlichen Wert aus dem Dokument wählen kann, wird eine Fehlermeldung erzeugt.

  • Response body as text:Wenn der Antwortinhalt weder JSON noch XML (zum Beispiel unformatierter Text, HTML oder ein proprietäres Format) ist, kannst Du diese Option verwenden, um den Inhalt zu durchsuchen. Standardmäßig betrachten wir den gesamten Inhalt der Antwort. Dies reicht aus, wenn Du einen einfachen Enthält-Abgleich durchführen möchtest. (Zum Beispiel: Die Antwort muss die Phrase „Price“ enthalten. Der Test ist erfolgreich, solang das Wort „Price“ irgendwo im Inhalt erscheint.) Um den gesamten Inhalt für den Prüfpunkt oder als Variablendefinition zu verwenden, sollte das Eigenschaftenfeld frei bleiben.

    Wenn Du jedoch Inhalt von einer bestimmten Stelle im Dokument extrahieren möchtest, musst auf irgendeine Weise definieren, welcher Teil des Inhalts dafür infrage kommt. Dafür gibst Du einen regulären Ausdruck im Eigenschaftenfeld an. Anhand des Musterabgleichs durch reguläre Ausdrücke versuchen wir, den Regex zuzuweisen und verwenden den ersten Abgleich, um den Wert aus dem Inhalt aufzuzeichnen.

    Bitte beachte, dass diese Optionen nur für Textinhalte gelten (obwohl sie auch auf Antworten mit JSON oder XML angewendet werden können, da diese auch als Text gelten). Das Durchsuchen binärer Inhalte wird nicht unterstützt.

    Please note that these options apply to text content only (although it may be applied to responses containing JSON or XML as well, since those are still just text); searching binary content is not supported.

  • Status code: Diese Option untersucht den numerischen HTTP-Statuscode, der Teil jeder HTTP-Antwort ist. In den meisten Fällen wird man einfach prüfen wollen, dass der Status 200 ist (was OK bedeutet) oder zumindest keinen Fehlercode darstellt. Tatsächlich ist dies eine Standardüberprüfung: Wenn Du keinen Prüfpunkt für Statuscode angibst, werden wir die folgende Prüfung automatisch ausführen, da 4xx und 5xx Codes in der Regel Fehlercodes sind:

    Status code Is less than 400

    Wenn Du jedoch einen Prüfpunkt für Statuscode definierst, wird dies unseren Standardtest außer Kraft setzen. Wenn Du beispielsweise

    Status code Is equal to 200

    definierst, werden wir genau diese Bedingung prüfen.

    Prüfpunkte mit Statuscode 301, 302, 303, 307 oder 308 (d. h. ein Weiterleitungscode) sind ein Sonderfall. Weitere Informationen findest Du unter Handhabung von Redirects.

  • Status description: Diese Option untersucht die Textbeschreibung des HTTP-Statuscodes (zuvor Reason-Phrase genannt). Das kann nützlich sein, wenn man das Verhalten bestimmter Fehlerbedingungen der API überprüft: Damit verifizierst Du, dass eine sinnvolle Statusbeschreibung zurückgegeben wird, wenn eine fehlerhafte Eingabe in Deiner API erfolgt.

  • Response completed: Diese Option gibt immer einen booleschen Wert in Bezug darauf zurück, ob eine HTTP-Anfrage vollständig ausgeführt wird. Es gibt ein „falsch“ zurück, wenn wir nicht feststellen können, mit welchem Server wir verbinden sollen, wenn keine Verbindung errichtet werden konnte oder wenn der Server nicht mit einer zeitgemäßen HTTP-Antwort reagierte. In allen anderen Fällen gibt es ein „wahr“ zurück.

    Diese Option muss in den meisten Fällen nicht spezifiziert werden, da wir das automatisch prüfen: Auf Grundlage dieses Prüfpunkttyps werden wir einen Fehler melden, wenn wir keine HTTP-Antwort von dem Server erhalten.

    Response completed Is equal to true

    In einigen Sonderfällen ist es möglich, diesen Test umzukehren: Wenn Du stattdessen „Falsch“ spezifizierst, werden wir prüfen, dass eine erfolgreiche Antwort NICHT möglich ist. Das kann nützlich sein, wenn man eine Webanwendung oder eine API hat, die nur innerhalb Deines Netzwerks verfügbar sein soll, selbst wenn der entsprechende Domainname öffentlich erreichbar ist. Mit dieser Prüfung verifizieren wir, dass wir die API oder Webanwendung nicht erreichen können.

  • Response header: Diese Option ermöglicht Dir, besondere HTTP-Antwort-Header zu untersuchen. Gib dazu den Namen des Headers im Eigenschaftenfeld an.

  • Cookie: Diese Option gibt den aktuellen Wert eines Cookies zurück. Gib dazu den Namen des Cookies im Eigenschaftenfeld an. Bitte beachte, dass die von Deinem Server zurückgegebenen Cookies als Session-Cookies behandelt werden: Cookie-Werte werden gespeichert, aktualisiert und zurück an den Server gegeben, während das gesamte Szenario bis zum letzten Schritt ausgeführt wird. Danach werden alle Cookies entfernt, unabhängig von den Ablaufanweisungen. Das bedeutet, dauerhafte Cookies werden im Wesentlichen als Session-Cookies behandelt.

  • Content length: Diese Option verzeichnet die Größe (in Bytes) des Antwortinhalts. Bitte beachte, dass dies die tatsächliche Länge des Inhalts ist, nachdem der Antwortinhalt dekomprimiert wurde (sofern Dein Server ihn zuvor komprimiert hatte).

  • Duration: Diese Option gibt die Gesamtzeit (in Millisekunden) an, die benötigt wurde, um die Anfrage auszuführen und eine Antwort zu erhalten. Damit kannst Du die Performance für einzelne Schritte überwachen.

Diese Option gibt die Gesamtzeit (in Millisekunden) an, die benötigt wurde, um die Anfrage auszuführen und eine Antwort zu erhalten. Damit kannst Du die Performance für einzelne Schritte überwachen.