Бюджет: 2000 UAH Срок: 1 день
Привет! Готов взять Ваш проект, выполню в срочном порядке. Опыт работы с подобными заданиями огромный, трудностей не возникнет. Если я Вас заинтересовал, пишите, рад сотрудничать!
⭐⭐⭐⭐⭐Описание:Мы ведем систему отчетности по тренингам/курсам, где для каждого клиента есть отдельный отчет Power BI, который получает данные о прохождении курсов через Tovuti LMS API с помощью Power Query (M). Один из этих отчетов начал выдавать ошибку 429 Too Many Requests, поскольку запрос каждый раз заново загружает всю историю данных, а объем этой истории уже превысил лимит запросов Tovuti API.
Необходимо:
Контекст модели данных: Отчет состоит из 4 связанных таблиц: Teams, Courses, Users и AssigmentsProgress (факт-таблица, которая тянется из эндпоинта courseProgresses Tovuti, связанная через teamId, courseId, userId). Именно таблица AssigmentsProgress упирается в лимит запросов, поскольку она растет каждый раз, когда кто-то начинает, проходит или завершает курс.
Требования:
Результат: Рабочее, протестированное исправление Power Query, интегрированное в существующий отчет, с кратким письменным объяснением изменений.
Бюджет: Фиксированная цена за эту задачу (сумма обсуждается на основе предложения)
Бюджет: 2000 UAH Срок: 1 день
Привет! Готов взять Ваш проект, выполню в срочном порядке. Опыт работы с подобными заданиями огромный, трудностей не возникнет. Если я Вас заинтересовал, пишите, рад сотрудничать!
⭐⭐⭐⭐⭐Бюджет: 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, поэтому делаю выгодно. Готов показать наш подход на звонке/в переписке до решения.
Петр Панкoв, 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 делает бизнес-системы, интеграции, CRM, автоматизацию и отчетность, где ошибка в данных стоит дороже, чем нормальная архитектура. Основной лендинг для биржи - https://systems-fl.ingello.com/ua
Для старта нужен текущий Power BI файл или M-код проблемной таблицы, пример ответа courseProgresses, параметры авторизации к Tovuti API и короткое объяснение, как сейчас запускается обновление. Смотрите, тут нюанс - если исторический массив уже большой, возможно, лучше сделать один контрольный полный срез, а дальше вести только инкрементальные изменения. Так меньше риска, что исправим 429, но оставим медленную модель на будущее.
Бюджет: 1000 UAH Срок: 2 дня
Доброго дня! Столкнулся именно с таким — 429 вылазит, потому что Power Query каждый раз тянет всю историю заново. Перепишу M-запрос на инкрементальную загрузку через timestampModifiedAfter и добавлю retry с backoff, чтобы на 429 не падало, а подождало и продолжило. Один вопрос: доступ к вашему Tovuti (ключ + тестовый отчет) дадите здесь, чтобы я проверил фикс на реальных данных? Сделаю быстро.
Бюджет: 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, а с причиной - полное перезагрузку истории в AssignmentsProgress.
> Вынесу загрузку courseProgresses на инкрементальную модель через timestampModifiedAfter
> Добавлю контроль пагинации, ограничений API и retry/backoff при 429
> Проверю связи с Teams, Courses, Users и AssignmentsProgress, чтобы после изменения запроса не сломалась модель
> Коротко опишу, что изменилось и как это поддерживать дальше
Смотрите, тут нюанс - надо согласовать, где именно хранить последний 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.