Workflows brauchen eine eigene Hostingumgebung? Logic Apps Standard erstellen

#logic-apps #standard #workflows #http

Logic Apps Standard stellt deinen Workflows eine Single-Tenant-Laufzeit mit bereitgestellter Rechenkapazität zur Verfügung. Eine Logic-App-Ressource kann mehrere Workflows enthalten, die sich Hostingkapazität und Konfiguration teilen. Das eignet sich für Integrationen, die planbare Kapazität, private Netzwerkanbindung oder mehr Kontrolle über die Bereitstellung benötigen.

Consumption	Standard
Ein Workflow pro Logic-App-Ressource	Mehrere Workflows pro Logic-App-Ressource
Gemeinsame Multi-Tenant-Laufzeit	Single-Tenant-Laufzeit auf einem Hostingplan
Abrechnung hauptsächlich pro Workflowoperation	Abrechnung der bereitgestellten Hostingkapazität sowie gegebenenfalls Speicher- und Connectornutzung
Praktisch für gelegentliche, einfache Workflows	Geeignet für Integrationen mit gemeinsamer Kapazität und Netzwerkkontrolle

Eine eigene Hostingumgebung bedeutet hier weder dedizierte physische Hardware noch automatisch privaten Zugriff. Wir verwenden einen Workflow Service Plan mit öffentlichem Endpunkt zum Testen. Eine App Service Environment ist nicht erforderlich.

Dieses Lab erstellt HTTP-Anfrage → Antwort in einer neuen Standard-App. Die Consumption-App aus dem vorherigen Trip wird nicht benötigt. Der Hostingplan verursacht auch ohne Workflowausführungen Kosten. Prüfe die Schätzung vor dem Erstellen und lösche die Labressourcen anschließend.

Standard-Logic-App erstellen

Öffne im Azure-Portal Logic Apps → Add / Create. Wähle Standard → Workflow Service Plan beziehungsweise Standard (Workflow Service Plan), falls dies als gemeinsame Option erscheint.

Subscription: CloudTrips TEST
Resource group: rg-cloudtrips-logicapps-standard-test-weu
Logic App name: la-ctstandard-weu
Region: West Europe
Hosting option: Workflow Service Plan
Plan: Create new → asp-ctlogicstandard-weu
Pricing tier: WS1

Ergänze einen eindeutigen Namenszusatz, falls der Appname vergeben ist. Verwende dieselbe Region für App und Plan. Prüfe den angezeigten Preis; WS1 reicht für dieses kleine Lab aus.

Wähle unter Storage die Option Azure Storage und erstelle ein neues Konto:

Storage account: stctlogicstdweu
Performance: Standard
Redundancy: LRS

Der Name muss global eindeutig sein. Wenn du das Konto separat erstellst, verwende General-purpose v2, lasse den hierarchischen Namespace deaktiviert und behalte die Standardsicherheitseinstellungen für Dateifreigaben bei. Dieser Speicher unterstützt die Workflowlaufzeit und den persistenten Zustand; er ist keine Bestelldatenbank, die wir in diesem Lab aufbauen.

Lasse den öffentlichen Zugriff aktiviert und die VNet-Integration beziehungsweise Network Injection deaktiviert. Deaktiviere die optionale Application-Insights-Anbindung für dieses Lab. Behalte für die Authentifizierung am Hostspeicher die Option mit Verbindungszeichenfolge/Zugriffsschlüssel bei, falls angeboten. Deaktiviere den Schlüsselzugriff auf das Speicherkonto für diese Konfiguration nicht.

Wähle Review + create → Create. Warte auf den Abschluss der Bereitstellung und öffne die Logic App. Unter Overview sollte ihr Hostingplan angezeigt werden. Die App stellt zunächst den Host bereit; einen Workflow musst du noch hinzufügen.

Übersicht der Standard-Logic-App mit Hostingplan und Region.

Zustandsbehafteten Workflow hinzufügen

Öffne im Appmenü Workflows → Workflows → Add. Verwende:

Workflow name: order-intake
State type: Stateful

Stateful speichert den Ausführungszustand dauerhaft und bietet einen Ausführungsverlauf. Dadurch lässt sich dieses Lab leicht überprüfen. Stateless eignet sich für kurze Ausführungen ohne dauerhaften Workflowzustand; der Ausführungsverlauf ist dabei standardmäßig nicht aktiviert.

Erstelle den Workflow, wähle order-intake und öffne Designer unter Tools. Füge den integrierten Trigger Request → When an HTTP request is received hinzu. Setze Method: POST, gegebenenfalls über die erweiterten Parameter. Lasse den relativen Pfad leer.

Füge unter Request Body JSON Schema Folgendes ein:

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

Wähle unter dem Trigger + → Add an action → Request → Response. Verwende:

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

Setze Body auf:

{
  "status": "received",
  "orderId": "@{triggerBody()?['orderId']}",
  "workflow": "order-intake"
}

Der Ausdruck liest die Bestell-ID aus der eingehenden Anfrage. Lasse die asynchrone Antwort deaktiviert. Speichere den Workflow, öffne den Trigger erneut und kopiere seine generierte HTTP POST URL / HTTP URL. Diese URL gehört zu diesem Workflow, nicht zu allen Workflows der App.

Die URL enthält eine Signatur zur Autorisierung. Halte sie aus Screenshots heraus und klappe die Triggereinstellungen vor der Aufnahme des Designers zu.

Standard-Workflowdesigner mit Request-Trigger und Response-Aktion; die signierte URL ist ausgeblendet.

Workflow ausführen

Öffne Azure Cloud Shell → Bash. Füge diesen Block ein und anschließend die vollständige Trigger-URL an der verdeckten Eingabeaufforderung:

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-10001"}'

unset ct_logic_url

Erwartet werden HTTP 200 und dieser Antwortinhalt:

{
  "status": "received",
  "orderId": "CT-10001",
  "workflow": "order-intake"
}

Damit ist bestätigt, dass der Workflow die Anfrage empfangen und ihre Bestell-ID zurückgegeben hat. Eine tatsächliche Bestellung wird dadurch weder gespeichert noch verarbeitet.

Kehre zu Workflows → Workflows → order-intake → Overview → Run history zurück. Aktualisiere die Ansicht, öffne die neueste Succeeded-Ausführung und erweitere Trigger und Response-Aktion, um Ein- und Ausgaben zu vergleichen. Bei Standard gehört der Verlauf zum jeweiligen Workflow; öffne daher den Workflow und suche nicht nur in der Übersicht der App.

Erfolgreiche zustandsbehaftete Workflowausführung mit HTTP-Anfrage und Antwort zur Bestell-ID CT-10001.

Bei 401/403 kopiere die vollständige aktuelle Trigger-URL einschließlich Querystring. Bei 202 ohne Antwortinhalt prüfe, ob die Response-Aktion gespeichert und die asynchrone Antwort deaktiviert ist. Lädt der Designer unmittelbar nach der Bereitstellung nicht, warte auf den Start des Hosts und aktualisiere die Ansicht. Bei anhaltenden Speicherfehlern prüfe Erreichbarkeit und Authentifizierung des Hostspeicherkontos.

Abschluss

Du hast jetzt einen Standard-Host, seinen Laufzeitspeicher und einen zustandsbehafteten Workflow. Unter derselben App könntest du einen weiteren Workflow hinzufügen, ohne eine weitere Logic-App-Ressource anzulegen; beide würden die Hostingkapazität der App teilen.

Lösche zum Aufräumen rg-cloudtrips-logicapps-standard-test-weu einschließlich Hostingplan und Speicherkonto. Das Stoppen der App oder Löschen nur des Workflows beendet die laufenden Plankosten nicht. Behalte die Ressourcengruppe nur, wenn du diese kostenpflichtige Hostingumgebung weiter nutzen möchtest.