Einführung
Die Auftragsabwicklung muss eine Bestellung speichern und anschließend ihre abgeschlossene Zusammenfassung lesen. Du verbindest diese Aufgaben in einem Workflow und vergleichst seinen Ausführungsverlauf mit dem tatsächlichen Geschäftsergebnis.
Schließe zuerst DynamoDB aus Lambda lesen und schreiben und dessen Voraussetzungen zu IAM-Rollen und Logging ab. Diese unabhängige VM stellt einen Worker und Tabellen bereit; du erstellst den Workflow. EventBridge-Routing ist ein separater Zweig.
Bezug zu Zertifizierungen
Dieses Lab bietet praktische Übungen zu den folgenden Prüfungsthemen.
- Solutions Architect – Associate (SAA-C03) · Aufgabe 2.1: Step-Functions-Aufgabenorchestrierung und Prüfung der Geschäftsergebnisse.
- Developer – Associate (DVA-C02) · Aufgabe 1.1: Step-Functions-Aufgabenorchestrierung und Prüfung der Geschäftsergebnisse.
- DevOps Engineer – Professional (DOP-C02) · Aufgabe 5.1, Aufgabe 2.3: Grundlagenübung: Step-Functions-Aufgabenorchestrierung und Prüfung der Geschäftsergebnisse.
- Solutions Architect – Professional (SAP-C02) · Aufgabe 2.4: Grundlagenübung: Step-Functions-Aufgabenorchestrierung und Prüfung der Geschäftsergebnisse.
Den Workflow zum Aufrufen seines Workers autorisieren
Untersuche in diesem Schritt den bereitgestellten Geschäftsworker und erstelle eine separate Ausführungsrolle für Step Functions.
Die Workflow-Rolle ruft die Funktion auf. Die separate Lambda-Rolle führt die Tabellenoperationen aus.
Verwende AWS View neben Terminal, um die CLI-Abfragen mit den tatsächlichen Ressourcen und Ergebnissen dieses Labs zu vergleichen. Erhalte die bereitgestellten Referenzdaten.
Ein Workflow verbindet Aufgaben und Entscheidungen. Eine Zustandsmaschine definiert diese Zustände; eine Ausführung führt die Definition mit einer bestimmten Eingabe aus. Diese neue VM stellt eine Worker-Funktion und unabhängige Bestell-, Diagnose- und Referenztabellen bereit. Es gibt noch keine Zustandsmaschine oder Workflow-Rolle. Der Worker nimmt eine Bestellung an, schreibt ihre Menge und ihren Gesamtbetrag und kann später ihre Zusammenfassung lesen. Seine Lambda-Ausführungsrolle autorisiert diese separaten Tabellenoperationen bereits.
Beginne im Projektverzeichnis. Shellzuweisungen speichern zurückgegebene Kennungen; --query wählt ein Antwortfeld aus, und --output text liefert eine wiederverwendbare Zeichenfolge.
cd /home/labex/project
WORKER_NAME=labex-ev03-worker
WORKER_ARN=$(aws lambda get-function-configuration \
--function-name labex-ev03-worker \
--query FunctionArn \
--output text)
aws lambda get-function-configuration \
--function-name labex-ev03-worker \
--query '{Name:FunctionName,Role:Role,Runtime:Runtime,Timeout:Timeout}'
aws stepfunctions list-state-machines
Der Worker verwendet Python3.12 und seine eigene Lambda-Rolle; die Maschinenliste ist leer. Step Functions benötigt seine eigene Ausführungsrolle. Eine Vertrauensrichtlinie erlaubt dem Step-Functions-Dienst, diese Rolle anzunehmen; eine Berechtigungsrichtlinie erlaubt der daraus entstehenden Sitzung, genau diesen Worker aufzurufen. Ein Here-Dokument mit einer in Anführungszeichen gesetzten Markierung schreibt wörtliches JSON, und file:// liest es in die Anfrage ein.
cat > workflow-trust.json <<'JSON'
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "states.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
JSON
ROLE_ARN=$(aws iam create-role \
--role-name labex-ev03-workflow-role \
--assume-role-policy-document file://workflow-trust.json \
--query Role.Arn \
--output text)
Schreibe ein gewöhnliches Berechtigungsdokument. Die Shell setzt $WORKER_ARN ein und begrenzt diese Berechtigung auf den bereitgestellten Worker.
cat > workflow-invoke.json <<EOF
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "lambda:InvokeFunction",
"Resource": "$WORKER_ARN"
}
]
}
EOF
aws iam put-role-policy \
--role-name labex-ev03-workflow-role \
--policy-name InvokeWorker \
--policy-document file://workflow-invoke.json
aws iam get-role-policy --role-name labex-ev03-workflow-role --policy-name InvokeWorker
Die Richtlinie enthält eine genaue Funktions-ARN. Step Functions erhält nicht die DynamoDB-Berechtigungen des Workers: Der Worker führt diese Aufrufe mit seiner separaten Lambda-Rolle aus. Führe die Autorisierungsprüfung aus.
Entscheidungen und zwei tatsächliche Aufgaben definieren
Definiere in diesem Schritt einen Bestellworkflow, der die Menge prüft, die Bestellung speichert und ihre tatsächliche Zusammenfassung liest.
StoreOrder speichert seine tatsächliche Nutzlast unter saved.result; ReadSummary wählt diese Bestell-ID aus und liest die abgeschlossene Zusammenfassung.
Amazon States Language (ASL) ist eine JSON-Definition einer Zustandsmaschine. StartAt wählt den ersten Zustand aus. Eine Choice folgt einem Zweig, wenn dessen Bedingung zutrifft, und folgt ansonsten Default. Eine Task ruft einen Dienst auf. Next verbindet Zustände; End: true beendet erfolgreich, während Fail mit einem Fehler endet.
Die optimierte Lambda-Aufgabenintegration verwendet arn:aws:states:::lambda:invoke. Parameters liefert Funktionsargumente: Ein Schlüssel, der auf .$ endet, wertet einen JSONPath aus, und $ wählt die vollständige aktuelle Eingabe aus. Die Lambda-Integration gibt Metadaten sowie Payload zurück. ResultSelector behält nur diese Nutzlast bei, ResultPath fügt sie unter saved ein und erhält dabei die ursprüngliche Bestelleingabe, und die nächste Aufgabe wählt die gespeicherte Bestell-ID aus. Ihr OutputPath gibt nur die tatsächliche Zusammenfassungsnutzlast zurück.
Schreibe die wörtliche Definition und ersetze dann ihren Worker-Platzhalter mit jq --arg:
cat > workflow-template.json <<'JSON'
{
"StartAt": "CheckQuantity",
"States": {
"CheckQuantity": {
"Type": "Choice",
"Choices": [
{
"Variable": "$.quantity",
"NumericGreaterThan": 0,
"Next": "StoreOrder"
}
],
"Default": "Rejected"
},
"StoreOrder": {
"Type": "Task",
"Resource": "arn:aws:states:::lambda:invoke",
"Parameters": {
"FunctionName": "WORKER_NAME",
"Payload.$": "$"
},
"ResultSelector": {
"result.$": "$.Payload"
},
"ResultPath": "$.saved",
"Next": "ReadSummary"
},
"ReadSummary": {
"Type": "Task",
"Resource": "arn:aws:states:::lambda:invoke",
"Parameters": {
"FunctionName": "WORKER_NAME",
"Payload": {
"stage": "summary",
"id.$": "$.saved.result.id"
}
},
"OutputPath": "$.Payload",
"End": true
},
"Rejected": {
"Type": "Fail",
"Error": "OrderRejected",
"Cause": "Quantity must be positive"
}
}
}
JSON
jq --arg worker "$WORKER_NAME" '.States.StoreOrder.Parameters.FunctionName=$worker | .States.ReadSummary.Parameters.FunctionName=$worker' workflow-template.json > workflow.json
MACHINE_ARN=$(aws stepfunctions create-state-machine \
--name labex-ev03-orders \
--type STANDARD \
--role-arn "$ROLE_ARN" \
--definition file://workflow.json \
--query stateMachineArn \
--output text)
aws stepfunctions describe-state-machine \
--state-machine-arn "$MACHINE_ARN" \
--query '{Name:name,Role:roleArn,Definition:definition}'
Die Antwort nennt die Maschine und ihre Workflow-Rolle, und die Definition nennt den bereitgestellten Worker in beiden Aufgaben. Noch wurde keine Bestellung verarbeitet. Klicke auf AWS View neben Terminal, um die tatsächliche Maschinendefinition und leere Ausführungs- und Bestelllisten zu sehen. Führe die Definitionsprüfung aus.
Geschäftsergebnisse und eine verweigerte Ausführung prüfen
Führe in diesem Schritt eine gültige Bestellung, eine ungültige Menge und eine Ausführung ohne Aufrufberechtigung aus.
start-execution startet asynchrone Arbeit und gibt eine Ausführungs-ARN zurück. Die folgende begrenzte Shellschleife liest ihren Status alle zwei Sekunden, bis sie nicht mehr läuft. $(...) erfasst Befehlsausgaben, seq liefert den Schleifenzähler, und break verlässt die Schleife, wenn die Bedingung zutrifft. Wenn der Status nach der Schleife weiterhin RUNNING ist, untersuche den Dienst, bevor du fortfährst.
EXECUTION_ARN=$(aws stepfunctions start-execution \
--state-machine-arn "$MACHINE_ARN" \
--name valid-order \
--input '{"id":"workflow-order","quantity":3}' \
--query executionArn \
--output text)
for attempt in $(seq 1 60); do
STATUS=$(aws stepfunctions describe-execution \
--execution-arn "$EXECUTION_ARN" \
--query status \
--output text)
if test "$STATUS" != RUNNING; then break; fi
sleep 2
done
aws stepfunctions describe-execution \
--execution-arn "$EXECUTION_ARN" \
--query '{Status:status,Output:output}'
aws stepfunctions get-execution-history \
--execution-arn "$EXECUTION_ARN" \
--query 'events[].type'
aws dynamodb get-item \
--table-name labex-ev03-orders \
--key '{"id":{"S":"workflow-order"}}' \
--query Item
Die offizielle Console listet Ausführungsnamen und -status zusammen mit Zeitangaben auf. Ihre Namen und ihr Workflow unterscheiden sich von der Standardmaschine dieses Labs. Vergleiche deinen CLI-Status mit Verlauf und gespeicherten Daten; verwende AWS View für die Ergebnisse dieses Labs.
Quelle: AWS Step Functions.
Der Status ist SUCCEEDED, und die Ausgabe enthält die Bestell-ID, total_cents:850 und completed:true. Das tatsächliche DynamoDB-Element hat die Menge 3 und den Gesamtbetrag 850. Der Verlauf enthält zwei TaskSucceeded-Ereignisse: das Speichern der Bestellung und das Lesen ihrer Zusammenfassung. Ein Ausführungsstatus allein belegt kein Geschäftsergebnis; vergleiche beides.
Teste den Choice-Zweig mit der Menge null:
INVALID_ARN=$(aws stepfunctions start-execution \
--state-machine-arn "$MACHINE_ARN" \
--name invalid-order \
--input '{"id":"invalid-order","quantity":0}' \
--query executionArn \
--output text)
for attempt in $(seq 1 30); do
STATUS=$(aws stepfunctions describe-execution \
--execution-arn "$INVALID_ARN" \
--query status \
--output text)
if test "$STATUS" != RUNNING; then break; fi
sleep 2
done
aws stepfunctions describe-execution \
--execution-arn "$INVALID_ARN" \
--query '{Status:status,Error:error}'
aws dynamodb get-item \
--table-name labex-ev03-orders \
--key '{"id":{"S":"invalid-order"}}' \
--query Item
Der Status ist FAILED mit OrderRejected, und es gibt kein invalid-order-Element. Choice hat es vor dem Aufruf des Workers zurückgewiesen.
Entferne jetzt nur die Invoke-Richtlinie des Workflows. Die Rolle des Workers und ihre Datenberechtigungen bleiben getrennt. Dein Operator darf weiterhin eine Ausführung starten, aber die Workflow-Rolle kann ihre Aufgabe nicht aufrufen:
aws iam delete-role-policy --role-name labex-ev03-workflow-role --policy-name InvokeWorker
DENIED_ARN=$(aws stepfunctions start-execution \
--state-machine-arn "$MACHINE_ARN" \
--name denied-order \
--input '{"id":"denied-order","quantity":2}' \
--query executionArn \
--output text)
for attempt in $(seq 1 30); do
STATUS=$(aws stepfunctions describe-execution \
--execution-arn "$DENIED_ARN" \
--query status \
--output text)
if test "$STATUS" != RUNNING; then break; fi
sleep 2
done
aws stepfunctions describe-execution \
--execution-arn "$DENIED_ARN" \
--query '{Status:status,Error:error}'
aws dynamodb get-item \
--table-name labex-ev03-orders \
--key '{"id":{"S":"denied-order"}}' \
--query Item
aws iam put-role-policy \
--role-name labex-ev03-workflow-role \
--policy-name InvokeWorker \
--policy-document file://workflow-invoke.json
Die verweigerte Ausführung schlägt beim Aufruf mit einem Zugriffsverweigerungsfehler fehl; sie erstellt keine Bestellung und führt keine Worker-Aufgabe aus. Die vorgesehene Richtlinie ist wiederhergestellt. AWS View zeigt die tatsächliche erfolgreiche Zusammenfassung und beide Fehler neben der einzigen gespeicherten Bestellung.
Das Beispiel unten zeigt die tatsächliche erfolgreiche Zusammenfassung, zurückgewiesene Ausführungen und die einzige geschäftliche Bestellung.
Führe die Ausführungsprüfung aus.
Workflow-Ressourcen und fiktive Ergebnisse entfernen
Lösche in diesem Schritt deine abgeschlossene Maschine, Workflow-Rolle, Bestellung und Logs und erhalte dabei die vorbereiteten Ressourcen.
Alle drei Ausführungen sind beendet. Das Löschen der Maschine entfernt sie aus der Liste aktiver Maschinen. Entferne die eigene Rollenrichtlinie, bevor du die Rolle löschst, und entferne dann die fiktive Bestellung und die Worker-Log-Gruppe, die durch deine Ausführung erstellt wurden.
aws stepfunctions delete-state-machine --state-machine-arn "$MACHINE_ARN"
aws iam delete-role-policy --role-name labex-ev03-workflow-role --policy-name InvokeWorker
aws iam delete-role --role-name labex-ev03-workflow-role
aws dynamodb delete-item \
--table-name labex-ev03-orders \
--key '{"id":{"S":"workflow-order"}}'
aws dynamodb delete-item \
--table-name labex-ev03-attempts \
--key '{"id":{"S":"workflow-order"}}'
aws logs delete-log-group --log-group-name /aws/lambda/labex-ev03-worker
Lies erfolgreiche Bestandsabfragen, um zu belegen, was erhalten bleibt:
aws stepfunctions list-state-machines
aws iam list-roles --query 'Roles[].RoleName'
aws dynamodb scan --table-name labex-ev03-orders --query Items
aws logs describe-log-groups --query logGroups
aws dynamodb scan --table-name labex-ev03-reference --query Items
Es gibt keine aktiven Maschinen, Bestellungen oder Log-Gruppen. Nur die bereitgestellte Worker-Rolle bleibt erhalten, und das Referenzelement ist unverändert. Behalte den bereitgestellten Worker und die Tabellen bei: Ihre Zugehörigkeit zum Setup unterscheidet sich von deinem erstellten Workflow und deinen Ressourcen. Netzwerk- oder Authentifizierungsfehler belegen niemals eine Löschung.
Entferne die gewöhnlichen Dateien, die in diesem Lab erstellt wurden:
rm -f workflow-trust.json workflow-invoke.json workflow-template.json workflow.json
AWS View zeigt leere Maschinen-, Ausführungs- und Bestelllisten und die erhaltene Referenz. Führe die Bereinigungsprüfung aus, bevor du die VM beendest.
Zusammenfassung
Du hast eine begrenzte Workflow-Ausführungsrolle erstellt, Choice und zwei tatsächliche Lambda-Aufgaben verbunden, tatsächliche Ergebnisse an die nächste Aufgabe weitergegeben und den Ausführungsverlauf mit Geschäftsdaten verglichen. Ungültige Eingaben und fehlende Aufrufberechtigung erzeugten keine Bestellung. Du hast eigene Workflow-Ressourcen und fiktive Ergebnisse entfernt und dabei vorbereitete Ressourcen erhalten.
Die nächste Einheit ergänzt Wiederholungen für temporäre Fehler und eine ausdrückliche Behandlung dauerhafter Fehler.
