Особенности выборки в Power Automate из источников данных SharePoint с большим количеством записей

В этой публикации мы рассмотрим особенности выборки в Power Automate из источников данных SharePoint. Отмечу, что такая особенность есть не для всех выборок. Например, если у вас в списке SharePoint менее 100 элементов, то вы не столкнетесь с такой особенностью. Вы можете даже относительно легко справиться с такой особенность для списка с 500 элементами. Однако, если в вашем списке, например, более 200 тысяч элементов, то тут уже необходимо оптимизировать запрос.

Описание источника данных и запросам к нему

Рассмотрим пример. У нас есть лист SharePoint, который хранит дополнительную информацию по заявке. Пусть это будет список комментариев. У каждого элементам списка есть следующие поля:

  • ID – генерируется SharePoint автоматически.
  • Title – текст комментария.
  • RequestID – ID заявки, для которой этот комментарий был создан.
  • CategoryID – ID категории, для которой был добавлен комментарий.

Схематично содержимое нашего листа SharePoint выглядит следующим образом:

IDTitleRequestIDCategoryID
1Printer Not Work2512
2Printer Not Work Again2512
3PC not starting315
200000Server Fault1754567

т.е. в нашем источнике данных порядка 200 тысяч элементов.

Например, мы хотим сделать выборку комментариев для заявки с ID 2575, но не всех комментариев, а только для проблем с принтером (CategoryID = 12).

Запросы в Power Automate к листам SharePoint используют запросы в формате ODATA. Более подробно про этот формат запросов можно почитать вот тут.

Логически наш запрос может выглядеть следующим образом:

Если CategoryID = 12 И RequestID = 2575

То же самое, но уже в формате ODATA:

CategoryID eq 12 and RequestID eq 2575

Например, мы точно знаем, что запрос должен вернуть нам две записи. Однако, на большом дата сете мы можем получить немного не тот результат, на который рассчитываем. Например, запрос может вернуть пустой результат…

Собственно, про особенность работы с запросами на большом дата сете мы поговорим ниже.

Особенности запроса и формирование правильного запроса

По умолчанию шаг Power Automate с типом Get Items для SharePoint возвращает только первые 100 элементов.

И казалось бы, что этого достаточно, т.к. у нас всего два элемента. Вспомним наш запрос:

CategoryID eq 12 and RequestID eq 2575

Так вот. Power Automate сначала выполняет левую часть запроса (CategoryID eq 12) и возвращает первые 100 элементов, а лишь затем на этих 100 элементах Power Automate выполняет вторую часть запроса (RequestID eq 2575). Соответственно, если у вас было более ста комментариев с CategoryID равной 12, то велики шансы, что наш запрос вернет пустой результат.

Как быть?

Есть несколько вариантов. Все они зависят от количества элементов в списке. Если у вас не более 1000 элементов, то вы можете просто увеличить количество возвращаемых элементов. Это немного замедлит работы Flow, но вы получите именно то, что вам нужно.

Но нам этот случай не подойдет, т.к. возвращать более 200 тысяч элементов – крайне небыстрая операция.

В нашем случае гораздо лучше оптимизировать запрос таким образом, чтобы сначала осуществлялась выборка всех элементов по ID заявки (поле RequestID), а затем уже осуществлять выборку по категории (CategoryID):

RequestID eq 2575 and CategoryID eq 12

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

Итого

В этом примере мы рассмотрели особенности выборки в Power Automate, с которой вы можете столкнуться для листов SharePoint с большим количеством элементов. Я постарался детальнее описать особенность при использовании запросов ODATA и показать на примере что может быть в том случае, когда наш лист SharePoint содержит большое количество элементов.

В вашем случае, вероятнее всего, запрос нужно будет немного иначе оптимизировать запрос, но, думаю, общая суть должна быть понятна – сначала нужно выполнять более “фильтрующую” часть запроса, а затем уже остальную часть запроса.

Добавить комментарий

Ваш адрес email не будет опубликован.