Nie podano
10 ofert
Opis: Prowadzimy system raportowania szkoleń/kursów, w którym dla każdego klienta istnieje osobny raport Power BI, który otrzymuje dane o ukończeniu kursów przez Tovuti LMS API za pomocą Power Query (M). Jeden z tych raportów zaczął zgłaszać błąd 429 Too Many Requests, ponieważ zapytanie za każdym razem ponownie ładowało całą historię danych, a objętość tej historii już przekroczyła limit zapytań Tovuti API.
Potrzebne: Przepisać Power Query tak, aby przy każdym aktualizowaniu ładowane były tylko nowe/zmienione rekordy, używając parametru timestampModifiedAfter w punkcie końcowym courseProgresses (ten parametr potwierdzono, że istnieje i działa), zamiast ponownego ładowania całej historii. Dodaj logikę retry/backoff, aby w przypadku błędu 429 zapytanie było wstrzymywane i kontynuowało działanie, a nie kończyło się błędem. Sprawdzić poprawki na naszym rzeczywistym Tovuti API i potwierdzić, że aktualizacja przebiega pomyślnie. Krótko udokumentować zmiany (co i dlaczego zostało zmienione), abyśmy mogli to wspierać w przyszłości. Kontekst modelu danych: Raport składa się z 4 powiązanych tabel: Teams, Courses, Users oraz AssigmentsProgress (tabela faktów, która pochodzi z punktu końcowego courseProgresses Tovuti, powiązana przez teamId, courseId, userId). To właśnie tabela AssigmentsProgress napotyka limit zapytań, ponieważ rośnie za każdym razem, gdy ktoś zaczyna, przechodzi lub kończy kurs.
Wymagania: Znajomość praktyczna Power Query (język M) oraz wzorców inkrementalnej aktualizacji danych w Power BI Doświadczenie w pracy z REST API (paginacja, filtry według daty, limity zapytań, obsługa retry/backoff) Umiejętność czytania dokumentacji OpenAPI/schema Jasna komunikacja w języku angielskim Wynik: Działająca, przetestowana poprawka Power Query, zintegrowana z istniejącym raportem, z krótkim pisemnym wyjaśnieniem zmian.
Budżet: Stała cena za to zadanie (kwota do omówienia na podstawie oferty)
