Я написал несколько функций Lambda, которые отображаются как конечные точки Rest через API Gateway. Я выбрал «Интеграцию лямбда-прокси», поскольку это казалось простым способом начать работу.
Теперь я хочу объединить две из этих функций в цепочку с помощью AWS Step Functions. Общая интеграция и конфигурация работают нормально, за исключением того, как создавать правильные входы для каждой задачи.
Используя консоль, я могу запустить Execution и дать следующий JSON:
{
"headers": {
"Authorization": "Bearer 12345"
},
"body": "\"some\": \"json\"",
"queryParameters: {
"more": "here"
}
}
Вот как выглядят входные данные для моих лямбда-функций, поскольку я везде использую интеграцию с лямбда-прокси.
Результат выглядит примерно так:
{
"isBase64Encoded": false,
"statusCode": 200,
"headers": {
"Access-Control-Allow-Origin": "*"
},
"body": "{\"message\":\"Great\"}"
}
Это также хорошо и автономно, API Gateway сопоставляет эту информацию с правильными кодами возврата HTTP, ответами и всем остальным.
Теперь: как мне создать эти входные JSON при использовании пошаговых функций. Самый первый ввод, конечно же, легко сделать с помощью консоли. Но как мне создать следующий ввод и смешать его с частью предыдущего вывода? Некоторые проблемы в маркированном списке:
Мне интересно, действительно ли пошаговые функции не работают с лямбда-выражениями, созданными для интеграции с лямбда-прокси. Так ли это? Как люди, использующие Step Functions, не сталкиваются с этими проблемами?

Функция Step разработана для прямой интеграции с лямбда-выражением, а не через шлюз api, поэтому пошаговые функции не обрабатывают ее, ускользнув от Jain естественным образом.
Если вы хотите, чтобы ваш лямбда-код был доступен как через шлюз api, так и через пошаговую функцию, я бы рекомендовал следующее: Разделите логику лямбда-кода на 2 части, т.е. основная логика и оболочка над базовой логикой, которая в основном выполняет функции извлечения полей из тела и отмены их экранирования. Таким образом, ваш шлюз api может вызывать лямбду-оболочку, а функция step может вызывать лямбда-форму основной логики. С таким дизайном вы сможете достичь своей цели. Более того, вы можете определить лямбды как часть одного пакета cfn и кода, что упростит обслуживание.
Надеюсь, это ответит на ваши вопросы.
Спасибо
В приведенном выше предложении лямбда-функция не знает вызывающего. В основном есть 2 лямбда-функции X и Y, X -> X содержит базовую логику, принимает параметры и выполняет свою функциональность и возвращает результат Y -> Функция Wrapper поверх X (следуя стандартному шаблону декоратора), переводит ввод, полученный от API Шлюз к входу, принятому Lambda X. [1]
Но если в вашем случае использования есть возможность избавиться от лямбды Y, либо путем сопоставления полей непосредственно из шлюза API вместо интеграции с прокси, либо полностью удалив шлюз API из изображения и просто полагаясь на прямую интеграцию SFn с Lambda. Согласен, это было бы правильно :)
Интересное предложение. Итак, вы говорите, что функция Lambda должна иметь дело как с интеграцией с API Gateway, так и с прямой интеграцией в нечто вроде Step Functions? Думаю, с точки зрения кода это выполнимо. Просто не кажется на 100% правильным, что лямбда-функция должна знать, как она вызывается. Похоже, я должен больше не заниматься интеграцией Lambda-прокси на API-шлюзе и вместо этого смотреть на правила перезаписи и сопоставления параметров, чтобы правильно пересылать запросы из API-шлюза в Lambda-функции ...