Azure: создание событий O365 из базы данных MySQL

#azure #microsoft-graph-api #azure-functions #azure-data-factory

#azure #microsoft-graph-api #azure-функции #azure-data-factory

Вопрос:

Я хочу создать события календаря Office 365, которые находятся в таблице MySQL (локальный сервер).

В настоящее время я планирую сделать это с помощью Azure Data Factory и приложения Functions. Я копирую данные MySQL из таблицы MySQL в хранилище таблиц Azure (это отлично работает).

После этого я хочу создать записи событий с помощью функции Azure (HTTP-триггер, зацикливание всех объектов хранилища и создание события календаря с помощью Graph API), но в этой таблице более 10 000 событий. Функция, вероятно, будет выполняться слишком долго.

Есть ли лучший способ создать эти события? O365 может использоваться только в качестве источника на фабрике данных Azure. Может быть, пакет в Azure Data Factory лучше, чем функция? Должен ли я запускать функцию не для всех событий? Для каждого отдельного события (триггер вставки таблицы)? Есть ли другие / лучшие варианты для этого в Azure?

Ответ №1:

Если вы уже выполняете запись в хранилище таблиц, создайте табличный триггер и обрабатывайте по одной записи за раз. Таким образом, все ваши 10000 событий будут обработаны в нескольких потоках. Но тогда вам, вероятно, нужно будет подумать об ограничениях на запись в календарь.

Комментарии:

1. Ok звучит неплохо. Существуют ли ограничения для календаря? 10000 событий предназначены для разных пользователей. Не для одного пользователя.

2. @Shmukko Я не могу найти ограничения, но, похоже, они должны быть возвращены как часть заголовков developer.microsoft.com/en-us/graph/blogs /…

3. Ограничение составляет 10 000 запросов на пользователя, на приложение в течение 10-минутного окна. Для простоты я обычно определяю это в своем коде как «1000 в минуту». Это немного проще для понимания. Технически это немного меньше фактического предела (т. Е. вы могли бы сделать 9000 вызовов в первую минуту и 1000 вызовов в 5-ю), но, честно говоря, практические задачи оптимизации для 10k / 10, как правило, не стоят того и часто требуют большего масштаба на стороне вашего приложения, чем оно того стоит.

4. @MarcLaFleur где ты это нашел? или научиться трудному пути?:)

5. Это сочетание того, что я сам столкнулся с этой проблемой несколько лет назад, приставал к автору упомянутого вами поста в блоге и был по уши в Graph в течение примерно половины десятилетия. Так что да, трудный путь. 😉