У меня есть несколько расписаний событий, привязанных к одной лямбде:
Events:
1minute:
Type: Schedule
Properties:
Schedule: rate(1 minute)
2minute:
Type: Schedule
Properties:
Schedule: rate(2 minutes)
etc...
Лямбда делает разные вещи в зависимости от расписания. Logi c очень прост, поэтому гораздо проще прикрепить несколько расписаний к одной и той же функции вместо создания нескольких отдельных функций.
Я могу проанализировать имя события из события и использовать его, чтобы определить, какое расписание is
Создание их с помощью шаблона sam, хотя означает, что в итоге они получат такие имена, как:
myapp-myfunction2minutes-ABC123XDJXKDF
Я по-прежнему хочу, чтобы они создавались динамически. Я не хочу устанавливать имена stati c, потому что это предотвратит одновременное существование нескольких стеков, и я хочу, чтобы они были полностью изолированы в пространстве имен и изолированы.
Я определенно могу проанализировать myapp-myfunction2minutes-ABC123XDJXKDF, потому что он достаточно предсказуем, но было бы еще лучше, если бы я мог добавить какое-то другое поле с произвольными метаданными, чтобы мне не приходилось выполнять синтаксический анализ строк. Поддерживается ли это?
РЕДАКТИРОВАТЬ: Настройка этого в шаблоне выглядит так:
Events:
1minute:
Type: Schedule
Input: '{"Key": "Value1"}'
Properties:
Schedule: rate(1 minute)
2minute:
Type: Schedule
Input: '{"Key": "Value2"}'
Properties:
Schedule: rate(2 minutes)
etc...
Затем «Ввод» заменяет все событие, отправленное в лямбда. Итак, в функции (если python) можно получить доступ, например, event["Key"]
.
Еще одна вещь, которая меня сбила с толку, заключалась в том, что Input, похоже, напрямую связан с указанной c лямбдой, созданной под ней. При тестировании я развернул стек с этими событиями, настроенными с входными данными, а затем, чтобы провести быстрый тест, я привязал одно из событий (правило облачного наблюдения) к другой лямбде, чтобы попытаться прочитать созданное им событие. Это не сработало, другая лямбда сработала по расписанию, но отправленный ему объект события не имел Входных данных - это был обычный объект события расписания облачных наблюдений.