Виправити помилку оновлення Power BI (429) при отриманні даних з Tovuti LMS API

Бюджет: 3500 UAH Термін: 3 дні

Розумію задачу: типова помилка накопичення історії при full-reload у Power Query проти API з rate-limit. Підхід:

1) Incremental refresh — переписую джерело courseProgresses так, щоб timestampModifiedAfter брався як MAX(lastModified) з поточного факт-набору AssigmentsProgress (через Table.Buffer + query folding, де можливо), а не жорстко захардкоджена дата — щоб і ручний повний рефреш, і інкрементальний працювали з одного M-скрипта.
2) Retry/backoff на 429 — обгортка над Web.Contents з try...otherwise, читанням Retry-After (якщо є в заголовках) і експоненційною паузою через List.Generate/Function.InvokeAfter, з лічильником спроб, щоб один випадковий 429 не валив весь рефреш.
3) Перевірю на вашому реальному Tovuti API (потрібен буде тимчасовий доступ до звіту/креденшлів), підтверджу коректність зв'язків Teams/Courses/Users/AssigmentsProgress після зміни.
4) Здам короткий MD/Word з поясненням: що саме змінено в M-коді, де тепер живе timestamp-параметр, як тестувати руками.

Маю практичний досвід з REST API пагінацією/лімітами і Python-автоматизацією обробки даних (приклад пайплайна моніторингу: guardlabs.online/demo/olx-monitor/). Готовий почати відразу, англійською комунікація не проблема.

Бюджет: 1000 UAH Термін: 2 дні

Доброго дня! Стикався саме з таким — 429 вилазить, бо Power Query щоразу тягне всю історію наново. Перепишу M-запит на інкрементальне довантаження через timestampModifiedAfter і додам retry з backoff, щоб на 429 не падало, а перечекало й продовжило. Одне питання: доступ до вашого Tovuti (ключ + тестовий звіт) дасте тут, щоб я перевірив фікс на реальних даних? Зроблю швидко.

Бюджет: 2000 UAH Термін: 1 день

Привіт!
Готовий взяти Ваш проект, виконаю у терміновому порядку.
Досвід роботи з подібними завданнями величезний, труднощів не виникне.
Якщо я Вас зацікавив, пишiть, радий співпрацювати!

Бюджет: 2500 UAH Термін: 3 дні

Доброго дня! Робимо саме такі ремонти інтеграцій з REST API — ваша 429 це класика: запит щоразу тягне всю історію courseProgresses, а вона переросла ліміт Tovuti.

Що зроблю:
1) Перепишу Power Query (M) на інкрементальне завантаження — тягнемо лише нові/змінені записи через timestampModifiedAfter, а не всю історію. Модель із 4 таблиць (Teams, Courses, Users, AssigmentsProgress) і звʼязки teamId/courseId/userId лишаються без змін.
2) Додам retry/backoff на 429 (try...otherwise + Function.InvokeAfter з наростаючою паузою), щоб оновлення не падало, а м'яко перечікувало ліміт і продовжувало.
3) Перевірю на вашому реальному Tovuti API, що рефреш проходить, і коротко задокументую що і чому змінив — щоб ви могли підтримувати далі.

Досвід з M/інкрементальним рефрешем, REST API (пагінація, фільтри за датою, ліміти, backoff) і читанням OpenAPI-схеми — є. Англійською спілкуюся вільно, тож комунікація не проблема.

Одне уточнення по суті: courseProgresses віддає дані з курсорною пагінацією чи лише датовим фільтром + offset? І чи зможете дати доступ до .pbix та ключ до Tovuti (можна тестовий), щоб я протестував фікс на живих даних, а не наосліп — це найшвидший шлях до робочого результату.

Ціна 2500 грн, орієнтовно 3 дні від моменту доступу. Беру за стартовою — набираю перші відгуки на Freelancehunt, тому роблю вигідно. Готовий показати наш підхід на дзвінку/у переписці до рішення.

Петро Панков, BotCraft Group Розгорнути

Бюджет: 18000 UAH Термін: 4 дні

Можемо взяти це як фіксовану задачу - орієнтир 4 робочі дні і 18000 грн. По суті тут треба не просто погасити 429, а переробити завантаження AssigmentsProgress так, щоб Power BI не ганяв всю історію по колу. Ну да, API-ліміти люблять нагадувати про себе в найменш поетичний момент =)

Я би зробив так - окремо виніс функцію запиту до courseProgresses з пагінацією, додав timestampModifiedAfter, нормальний retry/backoff для 429, контроль порожніх сторінок і короткий опис логіки в M-коді. Після цього перевірив би оновлення на реальному Tovuti API і пройшовся по зв'язках teamId, courseId, userId, щоб не зламати модель Teams, Courses, Users та AssigmentsProgress.

Уточнення, щоб не стріляти з гармати по горобцях - у вас Power BI Pro чи Premium, і чи використовується стандартний інкрементальний refresh через RangeStart/RangeEnd, чи все зараз зроблено тільки всередині Power Query? Друге - у Tovuti timestampModifiedAfter повертає всі змінені записи стабільно по UTC, чи там локальний час акаунта?

> https://business.ingello.com/platforma - близько за логікою корпоративної платформи, де важлива стабільна структура даних і підтримка процесів
> https://business.ingello.com/forma-bpm - схоже по підходу до бізнес-процесів, зв'язків між сутностями та контрольованої автоматизації
> https://business.ingello.com/vorfahr - приклад з інтеграціями та автоматизацією, де важлива надійність обміну даними

КОротко про нас - Ingello Systems робить бізнес-системи, інтеграції, ЦРМ, автоматизацію і звітність, де помилка в даних коштує дорожче, ніж нормальна архітектура. Основний лендинг для біржі - https://systems-fl.ingello.com/ua

Для старту потрібен поточний Power BI файл або M-код проблемної таблиці, приклад відповіді courseProgresses, параметри авторизації до Tovuti API і коротке пояснення, як зараз запускається оновлення. Смотрите, тут нюанс - якщо історичний масив уже великий, можливо, краще зробити один контрольний повний зріз, а далі вести тільки інкрементальні зміни. Так менше ризику, що виправимо 429, але залишимо повільну модель на майбутнє. Розгорнути

Бюджет: 1500 UAH Термін: 2 дні

Отримав завдання: виклик Power Query для AssigmentsProgress наразі отримує всю історію при кожному оновленні та досягає ліміту 429 Tovuti, і його потрібно переключити на інкрементальне оновлення з використанням timestampModifiedAfter, плюс повторна спроба та затримка при 429.

Чесна нотатка на початку: я раніше не працював з Power Query M конкретно. Мій досвід — це Python бекенд з великим досвідом роботи з REST API, пагінацією, обмеженнями швидкості, патернами повторних спроб і затримки — це те, з чим я щодня маю справу, тому логіка тут дуже знайома, навіть якщо синтаксис M мені новий. M — це маленька, добре задокументована мова, і патерн, який вам потрібен, параметризоване інкрементальне отримання плюс обгортка для затримки, є зрозумілим, як тільки я подивлюсь на ваш поточний запит.

Що я б зробив: додав би збережений параметр для останнього успішного часу оновлення, який передає timestampModifiedAfter у виклик courseProgresses, обгорнув би виклик API в функцію повторної спроби, яка ловить 429, чекає і повторює спробу замість того, щоб зупиняти все оновлення, і протестував би це на ваших живих даних Tovuti, перш ніж повернути з коротким описом того, що змінилося і чому.

Якщо ви відкриті до цього, я також запропонував би зберігати час останнього оновлення поза Power BI, щоб він зберігався навіть якщо оновлення частково зазнає невдачі, а не отримувати його виключно з існуючих даних — радий обговорити, як тільки я побачу поточний запит.

Оскільки це один запит з визначеним патерном, це реально завдання на 2-3 дні, включаючи тестування на вашому реальному API.

Бюджет: 8000 UAH Термін: 3 дні

Ми маємо досвід оптимізації запитів до API в Power Query для обходу лімітів. Реалізуємо це через впровадження механізмів кешування та логіки пакетної обробки даних, щоб уникнути помилки 429. Це забезпечить стабільну роботу Ваших звітів без перевищення лімітів Tovuti LMS. Готові розпочати налаштування інтеграції найближчим часом.

Бюджет: 5000 UAH Термін: 4 дні

Вітаю, Ольго!

Задача зрозуміла: звіт щоразу перевантажує всю історію courseProgresses, обсяг переріс ліміт Tovuti — звідси 429. Треба перевести факт-таблицю AssigmentsProgress на інкрементальне довантаження й навчити запит переживати ліміт, а не падати.

Як зроблю:
• Перепишу запит у Power Query (M) так, щоб courseProgresses тягнувся з timestampModifiedAfter — лише нові/змінені записи від останнього оновлення замість повного backfill.
• Додам обгортку retry/backoff: на 429 запит робить паузу з наростанням і повторює (з лімітом спроб), плюс коректна пагінація.
• Перевірю на вашому реальному Tovuti API, що рефреш проходить до кінця і зв'язки Teams/Courses/Users лишаються цілими.
• Коротко задокументую, що і чому змінено, щоб ви могли підтримувати самі.

Два уточнення:

Де зберігати «точку відліку» для timestampModifiedAfter — окремий параметр, чи один раз робимо повний backfill, далі тільки інкремент?
Рефреш іде через Power BI Service (за розкладом) чи Desktop? Від цього залежить, як зробити дату стійкою між оновленнями.
Строк — 3–4 робочі дні разом із тестом на вашому API. Ціна фіксована, орієнтовно 5 000 грн; фіналізую після відповідей вище. Розгорнути

Бюджет: 1000 UAH Термін: 1 день

Доброго дня! Готова виправити дану помилку!! Зробити зможу завтра!!!

Бюджет: 1111 UAH Термін: 1 день

Добрий день!

Маю досвід роботи з Power BI, Power Query (M) та інтеграціями REST API. Розумію проблему: через повне завантаження історії API впирається в ліміт запитів, тому оптимальним рішенням є перехід на інкрементальне оновлення.

Після ознайомлення з поточним Power Query та API зможу оцінити строки й запропонувати фіксовану вартість.

Бюджет: 27000 UAH Термін: 5 днів

у нас вже є практично готове схоже рішення для інкрементального оновлення даних через API, його можна швидко адаптувати під Tovuti LMS і Power BI ))

по оцінці - 28000 грн і орієнтовно 5 робочих днів після доступів до звіту, тестового API та поточної Power Query логіки.

ПРацюватиму не просто з помилкою 429, а з причиною - повне перезавантаження історії в AssigmentsProgress.

> винесу завантаження courseProgresses на інкрементальну модель через timestampModifiedAfter
> додам контроль пагінації, обмежень API і retry/backoff при 429
> перевірю зв'язки з Teams, Courses, Users та AssigmentsProgress, щоб після зміни запиту не зламалась модель
> коротко опишу що змінилось і як це підтриувати далі

Смотрите, тут нюанс - треба погодити, де саме зберігати останній timestamp для оновлення.
у Power BI це можна зробити кількома шляхами, і краще обрати той, який не створить сюрпризів при публікації та плановому оновленні в сервісі.

уточніть, будь ласка
> звіт оновлюється в Power BI Desktop чи вже через Power BI Service
> чи є в Tovuti стабільне поле modified/updated для courseProgresses, яке точно відповідає timestampModifiedAfter

релевантні приклади нашої роботи
> https://business.ingello.com/forma-bpm - автоматизація бізнес-процесів і даних, близько за логікою підтримуваної системи
> https://business.ingello.com/iks - корпоративна система з обліком, ролями й аналітикою
> https://business.ingello.com/vorfahr - приклад складнішої автоматизації з інтеграціями та даними

головний профіль Ingello для біржі - https://systems-fl.ingello.com/ua

можемо обговорити деталі тут, я на зв'язку =)
в цілому норм задача, але диявол, як завжди, сидить у датах оновлення і кеші Power BI. Розгорнути