Geschäftsworkflow braucht einen HTTP-Endpunkt? Logic App mit Anfrage und Antwort erstellen

Eine Logic App verbindet Workflow-Schritte visuell. Ein HTTP-Aufruf kann den Workflow starten, Daten übergeben und eine Antwort erhalten. Ein Shop könnte beispielsweise eine Bestellung an einen Workflow senden, der später den Lagerbestand prüft oder eine Freigabe anfordert.

Dieses Lab erstellt einen einfachen Endpunkt: HTTP-Anfrage → Response. Er gibt die übermittelte Bestell-ID zurück. Damit prüfst du, ob die Eingabe im Workflow angekommen ist. Die Bestellung wird nicht gespeichert, freigegeben oder versendet. Anwendungscode, VM und Ressourcen aus den Messaging-Trips sind nicht nötig.

Consumption Logic App erstellen

Suche im Azure-Portal nach Logic Apps → Add / Create. Wähle für diesen kleinen Workflow Consumption:

Subscription: CloudTrips TEST
Resource group: rg-cloudtrips-logicapps-test-weu
Logic App name: la-ctorders-http-weu
Region: West Europe
Plan type: Consumption
Log Analytics: Disabled for this lab, if offered

Consumption rechnet Workflow-Operationen ab und benötigt keinen dedizierten Hostingplan. Prüfe die Kostenschätzung und erstelle die Ressource. Bietet der Erstellungsablauf zuerst Hostingoptionen an, wähle die mehrmandantenfähige Consumption-Option.

Request-Trigger hinzufügen

Öffne die Logic App → Development Tools → Logic app designer. Beginne bei entsprechender Auswahl mit einem leeren Workflow. Wähle Add a trigger, suche Request und wähle den integrierten Trigger When an HTTP request is received.

Verwende den Request-Connector, nicht die HTTP-Aktion zum Aufrufen eines anderen Dienstes. Setze Method in den Triggerparametern auf POST. Ist Method ausgeblendet, öffne Add new parameter oder Advanced parameters.

Füge unter Request Body JSON Schema Folgendes ein:

{
  "type": "object",
  "properties": {
    "orderId": { "type": "string" },
    "product": { "type": "string" },
    "quantity": { "type": "integer" }
  },
  "required": ["orderId", "product", "quantity"]
}

Das Schema beschreibt das eingehende JSON und stellt seine Felder im Designer bereit. Lass den relativen Pfad leer. Die generierte URL holen wir nach dem Hinzufügen der Antwort und dem Speichern ab.

Antwort hinzufügen

Wähle unter dem Trigger + → Add an action. Suche Response und wähle die integrierte Aktion aus Request:

Status Code: 200
Headers:
  Content-Type: application/json

Trage unter Body ein:

{
  "status": "received",
  "orderId": "@{triggerBody()?['orderId']}",
  "message": "CloudTrips workflow received your order."
}

Der Ausdruck triggerBody()?['orderId'] liest orderId aus der eingehenden Anfrage. In diesem JSON-Inhalt fügt @{...} den Wert in den Antworttext ein. Der Designer kann ihn nach dem Speichern als Token für dynamischen Inhalt darstellen.

Lass die asynchrone Antwort deaktiviert, falls diese Einstellung angezeigt wird. Wähle Save. Öffne den Trigger erneut und kopiere seine generierte HTTP POST URL beziehungsweise HTTP URL.

Die vollständige URL enthält eine Signatur, die Aufrufe autorisiert. Zeige sie nicht in Screenshots oder öffentlichen Texten. Klappe die Triggereinstellungen vor dem Screenshot des Workflows zu.

Endpunkt aufrufen

Öffne Azure Cloud Shell → Bash. Führe den folgenden Block aus und füge die vollständige kopierte URL an der Eingabeaufforderung ein. Die URL bleibt beim Einfügen unsichtbar und wird nicht in die Befehlshistorie geschrieben. pip-Pakete oder zusätzliche Dateien sind nicht nötig.

read -r -s -p 'Paste the HTTP POST URL, then press Enter: ' ct_logic_url
printf '\n'

curl --include --max-time 30 \
  --request POST "$ct_logic_url" \
  --header 'Content-Type: application/json' \
  --data '{"orderId":"CT-9001","product":"Notebook","quantity":1}'

unset ct_logic_url

Erwarte HTTP 200 und diesen JSON-Inhalt:

{
  "status": "received",
  "orderId": "CT-9001",
  "message": "CloudTrips workflow received your order."
}

Die tatsächliche orderId zeigt, dass der Workflow deine Anfrage verwendet hat. Teste einen anderen Wert, indem du den Block mit CT-9002 im Anfrageinhalt erneut ausführst und die URL wieder einfügst.

Das Öffnen der URL im Browser sendet GET statt des hier konfigurierten POST. Teste den Endpunkt mit dem obigen Befehl. Bei 401 oder 403 kopiere die vollständige aktuelle URL einschließlich Query-String. Bei 202 ohne Antwortinhalt prüfe, ob die Response-Aktion gespeichert und die asynchrone Antwort deaktiviert ist. Enthält die Antwort den Ausdruck als wörtlichen Text, füge orderId über das dynamische Inhaltsfeld des Triggers in den Response-Body ein und speichere.

Workflow-Ausführung prüfen

Öffne Overview → Runs history an der Logic App. Aktualisiere die Ansicht und öffne den neuesten Lauf mit Succeeded. Klappe den Request-Trigger auf und prüfe seinen Eingabeinhalt. Prüfe anschließend Statuscode und Inhalt der Response-Aktion. In beiden sollte CT-9001 stehen oder CT-9002 nach dem zweiten Test.

Der Trigger startet den Workflow. Aktionen führen seine Schritte aus. Die Response-Aktion antwortet dem ursprünglichen HTTP-Aufrufer. Später kannst du Geschäftsschritte zwischen Trigger und Antwort ergänzen. Lange Abläufe benötigen ein bewusst asynchrones Design, statt den Aufrufer unbegrenzt warten zu lassen.

Abschluss

Behalte die Logic App, wenn du den Workflow erweitern möchtest. Andernfalls lösche rg-cloudtrips-logicapps-test-weu. Deaktivieren verhindert neue Triggerausführungen. Löschen entfernt zusätzlich den aufrufbaren Endpunkt und die Ausführungshistorie.