Пошаговые функции с лямбда-выражениями с использованием интеграции с лямбда-прокси

Я написал несколько функций 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 при использовании пошаговых функций. Самый первый ввод, конечно же, легко сделать с помощью консоли. Но как мне создать следующий ввод и смешать его с частью предыдущего вывода? Некоторые проблемы в маркированном списке:

  • Используя InputPath, ResultPath и OutputPath, я могу использовать только «весь» вывод предыдущего шага как ввод или часть как ввод для следующего шага. Но я не могу использовать только часть вывода, в моем случае элемент «тело» ответа.
  • Этот элемент "body" в любом случае экранирован, так что я предполагаю, что мне нужно будет убрать его, прежде чем использовать его как-то для следующего ввода? Но как?
  • Входной JSON должен состоять из таких элементов, как «заголовки», «тело» или «параметры запроса», которые вообще не отображаются в предыдущем выходном файле. Как мне их создать?

Мне интересно, действительно ли пошаговые функции не работают с лямбда-выражениями, созданными для интеграции с лямбда-прокси. Так ли это? Как люди, использующие Step Functions, не сталкиваются с этими проблемами?

Доступ AWS Java Lambda к экземпляру AWS RDS MySQL с помощью CDK
Доступ AWS Java Lambda к экземпляру AWS RDS MySQL с помощью CDK
В этой статье мы рассмотрим, как включить доступ Java Lambda к экземпляру AWS RDS MySQL.
3
0
937
1

Ответы 1

Функция Step разработана для прямой интеграции с лямбда-выражением, а не через шлюз api, поэтому пошаговые функции не обрабатывают ее, ускользнув от Jain естественным образом.

Если вы хотите, чтобы ваш лямбда-код был доступен как через шлюз api, так и через пошаговую функцию, я бы рекомендовал следующее: Разделите логику лямбда-кода на 2 части, т.е. основная логика и оболочка над базовой логикой, которая в основном выполняет функции извлечения полей из тела и отмены их экранирования. Таким образом, ваш шлюз api может вызывать лямбду-оболочку, а функция step может вызывать лямбда-форму основной логики. С таким дизайном вы сможете достичь своей цели. Более того, вы можете определить лямбды как часть одного пакета cfn и кода, что упростит обслуживание.

Надеюсь, это ответит на ваши вопросы.

Спасибо

Интересное предложение. Итак, вы говорите, что функция Lambda должна иметь дело как с интеграцией с API Gateway, так и с прямой интеграцией в нечто вроде Step Functions? Думаю, с точки зрения кода это выполнимо. Просто не кажется на 100% правильным, что лямбда-функция должна знать, как она вызывается. Похоже, я должен больше не заниматься интеграцией Lambda-прокси на API-шлюзе и вместо этого смотреть на правила перезаписи и сопоставления параметров, чтобы правильно пересылать запросы из API-шлюза в Lambda-функции ...

hendrikbeck 18.09.2018 10:46

В приведенном выше предложении лямбда-функция не знает вызывающего. В основном есть 2 лямбда-функции X и Y, X -> X содержит базовую логику, принимает параметры и выполняет свою функциональность и возвращает результат Y -> Функция Wrapper поверх X (следуя стандартному шаблону декоратора), переводит ввод, полученный от API Шлюз к входу, принятому Lambda X. [1]

Udit Bhatia 18.09.2018 14:43

Но если в вашем случае использования есть возможность избавиться от лямбды Y, либо путем сопоставления полей непосредственно из шлюза API вместо интеграции с прокси, либо полностью удалив шлюз API из изображения и просто полагаясь на прямую интеграцию SFn с Lambda. Согласен, это было бы правильно :)

Udit Bhatia 18.09.2018 14:48

Другие вопросы по теме