Zum Hauptinhalt springen

HTTP-Anfrage

Nutze den Schritt HTTP-Anfrage, wenn dein Flow eine externe API, einen Webhook oder einen Webservice aufrufen soll. Er ist die Standard-Action für Integrationen: Daten aus einem Partnersystem abrufen, Updates an eine Drittanbieter-App senden oder eine Automation außerhalb von Business Central auslösen.

Typische Einsatzszenarien sind:

  • Auftragsdaten an einen Versanddienstleister senden.
  • Einen Validierungsservice aufrufen, um Kundendaten anzureichern.
  • Einen Webhook in einem Portal oder einer Middleware auslösen.

Schritt konfigurieren​

Öffne den Flow-Editor, füge HTTP-Anfrage hinzu und fülle die Konfigurationskarte aus.

Beschreibung​

  • Zweck: Macht auf einen Blick klar, was der Aufruf im Flow bewirkt.
  • Wann ausfüllen: Immer. Die Beschreibung erscheint im Editor und in der Ausführungshistorie.
  • Tipp: Nenne Zielsystem und Absicht, zum Beispiel POST Sendung an DHL.

Anmeldedaten​

  • Zweck: Verweise auf eine AutoFlow-Anmeldedaten-Konfiguration, die den Aufruf authentifiziert. Die hinterlegte Authentifizierung und sämtliche Standard-Header werden automatisch angewandt.
  • Wann ausfüllen: Wann immer das Zielsystem Authentifizierung verlangt. Leer lassen für öffentliche Endpunkte oder Einzelfälle, in denen du Credentials lieber manuell als Header tippen willst.
  • Funktionsweise: Bei Auswahl berechnet der Auth-Typ der Anmeldedaten beim Ausführen des Schritts die richtigen Header (oder Query-Parameter). Auth-Header werden nie im Ausführungsprotokoll abgelegt — Geheimnisse erscheinen also nirgends. Hat die Anmeldedaten-Konfiguration eine Basis-URL, wird eine relative Request-URL automatisch damit präfixiert (/widgets wird zu https://api.beispiel/v1/widgets).
  • Konfliktbehandlung: Tippst du zusätzlich einen Authorization-Header manuell, gewinnt die Anmeldedaten-Authentifizierung — der manuelle Header wird verworfen. Standard-Header aus den Anmeldedaten werden zuerst gesetzt; manuelle Header der Anfrage überschreiben sie; Auth-Header gewinnen am Ende über alle.

Anfrage-URL​

  • Zweck: Der Endpunkt, den die Anfrage aufruft.
  • Wann ausfüllen: Verpflichtend. Ohne URL kann kein Aufruf erfolgen.
  • Tipp: Verwende vollständige URLs inklusive Protokoll (https://). Wenn der Endpunkt dynamisch ist, mappe ihn aus vorherigen Step-Outputs oder Variablen.

Anfragemethode​

  • Zweck: Legt das HTTP-Verb fest, mit dem der Endpunkt aufgerufen wird.
  • Wann ausfüllen: Verpflichtend. Wähle das Verb, das die API erwartet.
  • Tipp: GET für Lesezugriffe, POST zum Erstellen, PUT/PATCH für Updates und DELETE zum Entfernen. HEAD und OPTIONS sind für Spezialfälle verfügbar.

Anfrageheader​

  • Zweck: Metadaten angeben, die die API erwartet (Authentifizierung, Content-Type etc.).
  • Wann ausfüllen: Optional, aber für die meisten APIs unverzichtbar.
  • Funktionsweise: Jeder Eintrag ist ein Name/Wert-Paar. Header-Namen wählst du aus der vordefinierten Liste (z. B. Authorization, Content-Type oder Accept).
  • Tipp: Setze Content-Type, wenn du einen Body sendest, und Authorization für geschützte Endpunkte.

Anfrage-Body​

  • Zweck: Der Payload, den du mit der Anfrage sendest.
  • Wann ausfüllen: Nur für POST, PUT und PATCH verfügbar. In diesen Fällen brauchst du ihn in der Regel.
  • Tipp: Nutze JSON für moderne APIs und passe die Struktur an das erwartete Schema an.

Der Body-Editor​

Der Body wird in einem Code-Editor geschrieben: Er hebt JSON und XML hervor, nummeriert die Zeilen und hebt zusammengehörige Klammern hervor. Welche Sprache hervorgehoben wird, richtet sich nach dem Content-Type-Header aus der Tabelle darüber — alles JSON-artige (application/json, application/problem+json) wird als JSON hervorgehoben, alles XML-artige als XML, alles andere als einfacher Text in Festbreitenschrift.

SmartFields, SmartFormulas, SmartDates und SmartControls funktionieren hier genauso, und die Schaltflächen oben rechts fügen sie an der Cursorposition ein. Anders als in den einzeiligen Wertfeldern bleiben sie als reiner Text sichtbar — {{customer.name}} statt einer abgerundeten Kachel — damit der Payload gültiger, lesbarer Quelltext bleibt, den du in den Schritt hinein- und wieder herauskopieren kannst. Jeder Platzhalter ist nach Art eingefärbt, und ein Klick darauf öffnet dasselbe Menü wie überall sonst: Feld ersetzen, Formatierung bearbeiten, Bedingung ändern und so weiter. Wird der Payload länger, öffnest du mit der Schaltfläche zum Vergrößern einen Vollbild-Editor.

Anfrage testen​

Sobald der Schritt konfiguriert ist, sendest du die Anfrage mit Testlauf (in der Aktionsleiste oder Strg+T) direkt von der Konfigurationskarte aus — du musst den Flow nicht erst veröffentlichen und auslösen.

Da URL, Header oder Body SmartFields enthalten können, die ihre Werte erst zur Laufzeit erhalten, bittet dich AutoFlow zunächst, diese zu ergänzen. Es listet jeden in URL, Headern und Body verwendeten SmartField-Platzhalter auf — eine Zeile je Platzhalter — und du gibst den für den Test zu verwendenden Wert ein. Jeder eigenständige Platzhalter ist eine eigene Zeile: {{customer.name}} und {{customer.no}} werden getrennt aufgeführt. Für längere Werte öffnest du über die AssistEdit-Schaltfläche (...) neben einem Wert den mehrzeiligen Editor (Text mit mehr als 250 Zeichen wird unterstützt).

Wenn du bestätigst, ersetzt AutoFlow jeden Platzhalter durch den von dir angegebenen Wert, wendet das ausgewählte Credential an und sendet die Anfrage. Das ist ein echter, authentifizierter Aufruf an den Endpunkt — richte den Test daher auf eine sichere Umgebung, wenn der Aufruf Seiteneffekte hat. Die Antwort wird angezeigt, damit du das Ergebnis prüfen kannst: der Status, die Header (lesbar formatiert) und der Body. Mit Kopieren oben rechts am Body kopierst du den vollständigen Payload — praktisch, um ihn beim Aufbau eines Parser-Schritts einzufügen.

Outputs​

Der Schritt liefert drei Outputs, die du in späteren Actions verwenden kannst:

  • responseStatus: Der HTTP-Statuscode als Text.
  • responseHeaders: Die Response-Header als JSON-Text.
  • responseBody: Der Response-Payload als Text.

Nutze diese Outputs, um deinen Flow zu verzweigen, Fehler zu protokollieren oder Response-Daten in Business-Central-Datensätze zu überführen.

Best Practices​

  • Fehler früh behandeln: Prüfe responseStatus und füge bei Nicht-2xx-Antworten einen Entscheidungsstep hinzu.
  • Geheimnisse schützen: Verwende AutoFlow-Anmeldedaten statt API-Keys, Tokens oder Passwörter direkt in Header zu kopieren. Anmeldedaten sind verschlüsselt gespeichert, erscheinen nicht im Protokoll und lassen sich an einer einzigen Stelle ändern.
  • Formate explizit setzen: Setze Content-Type und Accept, wenn die API strikte Medientypen verlangt.