Я задавал этот вопрос на форуме Azure Logi c Apps (LA), так как я использовал LA для реализации этого процесса, но я также могу получить ценный вклад здесь.
Описание высокого уровня : в одном конкретном c клиенте нам необходимо ежедневно загружать десятки файлов из SFTP-местоположения на наши серверы для обработки их данных. В прошлом этот рабочий процесс создавался с использованием инструментов, отличных от Azure, но мы стремились получить общий процесс, который можно было использовать для разных исходных систем, разных файлов и т. Д. c. Имея это в виду, наш процесс вначале извлекает из базы данных различные переменные, которые будут применяться к каждому выполнению процесса, такие как:
- Рабочая дата
- Удаленное местоположение путь - расположение sftp
- Путь локального расположения - расположение внутреннего сервера
- Расширение файла - .csv, .zip, et c
- Количество итераций
- Время ожидания между итерациями
- Датированные файлы - есть ли у файлов бизнес-дата в названии или нет
Как только все это определено в начале процесса (есть некоторые дополнительные логики c к нему, не так просто, как просто получение переменных, но давайте предположим это для примера), применяется следующая логика c (изображение ниже может помочь понять поток LA):
- Поиск файла в SFTP-местоположении
- Если файл есть, получите размер файла, подождите X раз и проверьте размер снова.
Если файла нет, попробуйте еще раз до достижения максимальное количество итераций или файл найден
Если размер файла совпадает, перейдите к загрузке файла
- Если размер файла не совпадает, попробуйте еще раз, пока достижение максимального количества итераций или файл найден
LA Flow
В нашем LA этот процесс реализован и работает нормально, у нас есть 2 параметра в LA Это имя файла и исходная система, и на основе этих параметров все переменные извлекаются в начале процесса. Эти 2 параметра можно изменить с LA на LA, и с помощью сценариев мы можем автоматически развернуть несколько LA (по одному для каждого файла, который нам нужно загрузить). Процесс использует триггер расписания, так как мы хотим запускать его в определенное время c каждый день, мы не хотим использовать триггер, когда файл находится в удаленном местоположении, так как несколько файлов могут быть размещены в удаленном местоположение, в котором мы не заинтересованы.
Одно ограничение, которое я вижу по сравнению с нашим текущим процессом, состоит в том, что несколько LA сгруппированы по одному типу конвейера, где мы можем сгруппировать несколько выполнений и проверить их состояние. без необходимости проверки нескольких LA. Мне известно, что мы можем осуществлять мониторинг LA с помощью OMS и, возможно, вызывать несколько LA из конвейера фабрики данных, но я не совсем уверен, как это будет работать в этом случае.
В любом случае, вот откуда приходит мой ВОПРОС : что было бы лучшим в Azure для реализации этого типа процесса? LA работают с тех пор, как я их построил, я собираюсь взглянуть на репликацию того же процесса в фабрике данных, но боюсь, что может быть немного сложнее настроить такой тип логики c. Что еще потенциально может быть использовано? Действительно открыт для всех видов предложений, просто хочу убедиться, что я рассмотрю все допустимые варианты, что сложно, учитывая, сколько различных функций предлагает Azure, и трудно отслеживать их все.
Цените любые вход, ура