• Проекты 42
  • Оценка 5.0
  • Рейтинг 6 104

Бюджет: 2000 UAH Срок: 1 день

Привет! Готов взять Ваш проект, выполню в срочном порядке. Опыт работы с подобными заданиями огромный, трудностей не возникнет. Если я Вас заинтересовал, пишите, рад сотрудничать!

⭐⭐⭐⭐⭐
  • Проекты 3
  • Оценка 5.0
  • Рейтинг 1 130

Бюджет: 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 (можно тестовый), чтобы я протестировал фикс на живых данных, а не наослеп — это самый быстрый путь к рабочему результату.

  • Проекты 30
  • Оценка 5.0
  • Рейтинг 5 747

Бюджет: 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 - пример с интеграциями и автоматизацией, где важна надежность обмена данными

Похожий проект: Рефаткоринг приложения
  • Проекты -
  • Оценка -
  • Рейтинг 278

Бюджет: 1000 UAH Срок: 2 дня

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

  • Проекты 77
  • Оценка 4.7
  • Рейтинг 2 926

Бюджет: 1000 UAH Срок: 1 день

Доброго дня! Готова исправить данную ошибку!! Сделать смогу завтра!!!

  • Проекты 104
  • Оценка 5.0
  • Рейтинг 4 461

Бюджет: 1111 UAH Срок: 1 день

Добрый день!

У меня есть опыт работы с Power BI, Power Query (M) и интеграциями REST API. Понимаю проблему: из-за полного загрузки истории API упирается в лимит запросов, поэтому оптимальным решением является переход на инкрементальное обновление.

После ознакомления с текущим Power Query и API смогу оценить сроки и предложить фиксированную стоимость.

  • Проекты -
  • Оценка -
  • Рейтинг 196

Бюджет: 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, чтобы после изменения запроса не сломалась модель
> Коротко опишу, что изменилось и как это поддерживать дальше

Ставки скрыты

В списке не показаны ставки, скрытые заказчиком или фрилансером c профилем Plus, а также ставки, нарушающие правила