LabEx
Регистрация

Создание многошагового процесса заказа

AWSBeginner
Практиковаться сейчас

Введение

Исполнение заказа должно сохранить заказ, затем прочитать его завершённую сводку. Вы соедините эти задачи в процессе и сравните историю его выполнения с действительным бизнес-результатом.

Сначала выполните Чтение и запись DynamoDB из Lambda и её предварительные работы по ролям IAM и журналированию. Эта независимая VM предоставляет обработчик и таблицы; процесс создаёте вы. Маршрутизация EventBridge — отдельная ветка.

Связь с сертификацией

Эта лабораторная работа помогает на практике изучить следующие темы экзаменов.

Авторизация процесса для вызова обработчика

На этом шаге проверьте предоставленный бизнес-обработчик и создайте отдельную роль выполнения для Step Functions.

Разрешения процесса и обработчика

Роль процесса вызывает функцию. Отдельная роль Lambda выполняет операции таблиц.

Используйте AWS View рядом с Terminal, чтобы сравнивать запросы CLI с реальными ресурсами и результатами этой работы. Сохраните предоставленные эталонные данные.

Процесс соединяет задачи и решения. Машина состояний определяет эти состояния; выполнение запускает определение с конкретными входными данными. Эта новая VM предоставляет функцию-обработчик и независимые таблицы заказов, диагностики и эталонов. Машины состояний или роли процесса пока нет. Обработчик принимает заказ, записывает его количество и сумму и позже может прочитать сводку. Его роль выполнения Lambda уже авторизует эти отдельные операции таблиц.

Начните в каталоге проекта. Присваивания оболочки сохраняют возвращённые идентификаторы; --query выбирает поле ответа, а --output text выдаёт строку для повторного использования.

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

Обработчик использует Python3.12 и собственную роль Lambda; список машин пуст. Step Functions нужна собственная роль выполнения. Политика доверия позволяет сервису Step Functions принять эту роль; политика разрешений позволяет полученному сеансу вызвать только этот обработчик. Here-document в кавычках записывает буквальный JSON, а file:// читает его в запрос.

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)

Запишите обычный документ разрешений. Оболочка подставляет $WORKER_ARN, ограничивая это разрешение предоставленным обработчиком.

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

Политика имеет один точный ARN функции. Step Functions не получает разрешений DynamoDB обработчика: обработчик выполняет эти вызовы со своей отдельной ролью Lambda. Выполните проверку авторизации.

Определение решений и двух реальных задач

На этом шаге определите процесс заказа, который проверяет количество, сохраняет заказ и читает его реальную сводку.

Входные данные, сохранённый результат и сводка

StoreOrder сохраняет действительную полезную нагрузку под saved.result; ReadSummary выбирает этот идентификатор заказа и читает завершённую сводку.

Amazon States Language (ASL) — определение машины состояний в JSON. StartAt выбирает первое состояние. Choice следует одной ветке при совпадении условия, иначе следует Default. Task вызывает сервис. Next соединяет состояния; End: true завершает успешно, а Fail завершает с ошибкой.

Оптимизированная интеграция задачи Lambda использует arn:aws:states:::lambda:invoke. Parameters задаёт аргументы функции: ключ, заканчивающийся на .$, вычисляет JSONPath, а $ выбирает все текущие входные данные. Интеграция Lambda возвращает метаданные и Payload. ResultSelector оставляет только эту полезную нагрузку, ResultPath вставляет её под saved, сохраняя исходные входные данные заказа, а следующая задача выбирает сохранённый идентификатор заказа. Её OutputPath возвращает только реальную полезную нагрузку сводки.

Запишите буквальное определение, затем замените заполнитель обработчика через 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}'

Ответ называет машину и её роль процесса, а определение называет предоставленный обработчик в обеих задачах. Заказ ещё ничем не обработан. Нажмите AWS View рядом с Terminal, чтобы увидеть реальное определение машины и пустые списки выполнений и заказов. Выполните проверку определения.

Проверка бизнес-результатов и запрещённого выполнения

На этом шаге запустите допустимый заказ, недопустимое количество и выполнение без разрешения вызова.

start-execution запускает асинхронную работу и возвращает ARN выполнения. Следующий ограниченный цикл оболочки читает статус каждые две секунды, пока выполнение не перестанет работать. $(...) захватывает вывод команды, seq задаёт число повторений цикла, а break выходит из цикла при совпадении условия. Если после цикла остаётся RUNNING, проверьте сервис перед продолжением.

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

Пример списка выполнений в официальной консоли Step Functions

Официальная консоль перечисляет имена и статусы выполнений вместе со временем. Её имена и процесс отличаются от машины Standard этой работы. Сравните свой статус CLI с историей и сохранёнными данными; используйте AWS View для результатов этой работы.

Источник: AWS Step Functions.

Статус — SUCCEEDED, а вывод содержит идентификатор заказа, total_cents:850 и completed:true. Действительная запись DynamoDB имеет количество 3 и сумму 850. История содержит два события TaskSucceeded: сохранение заказа и чтение его сводки. Один статус выполнения не подтверждает бизнес-результат; сравните оба.

Проверьте ветку Choice с количеством ноль:

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

Статус — FAILED с OrderRejected, записи invalid-order нет. Choice отклонил её до вызова обработчика.

Теперь удалите только политику Invoke процесса. Роль обработчика и разрешения данных остаются отдельными. Вашему оператору по-прежнему разрешено запускать выполнение, но роль процесса не может вызвать его задачу:

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

Запрещённое выполнение завершается ошибкой отказа в доступе при вызове; оно не создаёт заказ и не выполняет задачу обработчика. Нужная политика восстановлена. AWS View показывает реальную успешную сводку и обе ошибки рядом с единственным сохранённым заказом.

Пример ниже показывает реальную успешную сводку, отклонённые выполнения и один бизнес-заказ.

AWS View показывает реальную сводку процесса и неудачные выполнения

Выполните проверку выполнения.

Удаление ресурсов процесса и синтетических результатов

На этом шаге удалите завершённую машину, роль процесса, заказ и журналы, сохранив предоставленные ресурсы.

Все три выполнения завершены. Удаление машины исключает её из списка активных машин. Удалите политику роли упражнения перед удалением роли, затем удалите синтетический заказ и группу журналов обработчика, созданную вашим выполнением.

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

Прочитайте успешные перечни, чтобы доказать оставшиеся ресурсы:

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

Активных машин, заказов или групп журналов нет. Остаётся только предоставленная роль обработчика, а эталонная запись неизменна. Сохраните предоставленные обработчик и таблицы: ответственность за их подготовку отличается от ваших созданных ресурсов процесса. Ошибки сети или аутентификации никогда не доказывают удаление.

Удалите обычные файлы, созданные в этой работе:

rm -f workflow-trust.json workflow-invoke.json workflow-template.json workflow.json

AWS View показывает пустые списки машин, выполнений и заказов и сохранённый эталон. Выполните проверку очистки перед завершением VM.

Резюме

Вы создали ограниченную роль выполнения процесса, соединили Choice и две реальные задачи Lambda, передали действительные результаты следующей задаче и сравнили историю выполнения с бизнес-данными. Недопустимые входные данные и отсутствие разрешения вызова не создали заказ. Вы удалили ресурсы процесса упражнения и синтетические результаты, сохранив предоставленные ресурсы.

Следующая работа добавляет повторные попытки для временных ошибок и явную обработку постоянных ошибок.

Связанные AWS Курсы
Основы AWS для начинающих

Основы AWS для начинающих

aws
AWS S3 для начинающих

AWS S3 для начинающих

aws
AWS IAM для начинающих

AWS IAM для начинающих

aws