Budżet: 1000 UAH Termin: 2 dni
Dzień dobry! Spotkałem się z tym — 429 się pojawia, ponieważ Power Query za każdym razem pobiera całą historię na nowo. Przepisałem zapytanie M na inkrementalne doładowanie przez timestampModifiedAfter i dodam retry z backoff, aby na 429 nie padało, a poczekało i kontynuowało. Jedno pytanie: czy udostępnisz dostęp do waszego Tovuti (klucz + raport testowy) tutaj, żebym mógł sprawdzić poprawkę na rzeczywistych danych? Zrobię to szybko.
Budżet: 2000 UAH Termin: 1 dzień
Cześć!
Jestem gotów zająć się Twoim projektem, wykonam go w trybie pilnym.
Mam ogromne doświadczenie w pracy z podobnymi zadaniami, nie będzie żadnych trudności.
Jeśli Cię zainteresowałem, pisz, chętnie nawiążę współpracę!
Budżet: 2500 UAH Termin: 3 dni
Dzień dobry! Robimy właśnie takie remonty integracji z REST API — wasz 429 to klasyka: zapytanie za każdym razem ciągnie całą historię courseProgresses, a ona przekroczyła limit Tovuti.
Co zrobię:
1) Przepiszę Power Query (M) na inkrementalne ładowanie — ciągniemy tylko nowe/zmienione rekordy przez timestampModifiedAfter, a nie całą historię. Model z 4 tabelami (Teams, Courses, Users, AssigmentsProgress) i powiązania teamId/courseId/userId pozostają bez zmian.
2) Dodam retry/backoff na 429 (try...otherwise + Function.InvokeAfter z narastającą pauzą), aby aktualizacja nie padała, a łagodnie czekała na limit i kontynuowała.
3) Sprawdzę na waszym rzeczywistym Tovuti API, że refresh przechodzi, i krótko udokumentuję co i dlaczego zmieniłem — abyście mogli dalej to wspierać.
Mam doświadczenie z M/inkrementalnym refresh'em, REST API (paginacja, filtry według daty, limity, backoff) i czytaniem schematu OpenAPI — jest. Po angielsku komunikuję się swobodnie, więc komunikacja nie jest problemem.
Jedno wyjaśnienie co do sedna: courseProgresses zwraca dane z kursorową paginacją czy tylko filtrem daty + offset? I czy będziecie mogli dać dostęp do .pbix oraz klucz do Tovuti (może testowy), żebym mógł przetestować fix na żywych danych, a nie na ślepo — to najszybsza droga do roboczego wyniku.
Cena 2500 zł, orientacyjnie 3 dni od momentu dostępu. Biorę za startową — zbieram pierwsze opinie na Freelancehunt, więc robię korzystnie. Jestem gotów pokazać nasze podejście na rozmowie/ w korespondencji do rozwiązania.
Piotr Pankow, BotCraft Group
Budżet: 18000 UAH Termin: 4 dni
Możemy to traktować jako stałe zadanie - orientacyjnie 4 dni robocze i 18000 UAH. W zasadzie trzeba nie tylko zlikwidować 429, ale przerobić ładowanie AssigmentsProgress tak, aby Power BI nie przetwarzał całej historii w kółko. Tak, limity API lubią przypominać o sobie w najmniej poetyckim momencie =)
Zrobiłbym to tak - osobno wydzieliłbym funkcję zapytania do courseProgresses z paginacją, dodał timestampModifiedAfter, normalny retry/backoff dla 429, kontrolę pustych stron i krótki opis logiki w kodzie M. Po tym sprawdziłbym aktualizacje na rzeczywistym API Tovuti i przeszedłbym przez powiązania teamId, courseId, userId, aby nie złamać modelu Teams, Courses, Users oraz AssigmentsProgress.
Wyjaśnienie, aby nie strzelać z armaty do wróbli - macie Power BI Pro czy Premium, i czy używacie standardowego inkrementalnego odświeżania przez RangeStart/RangeEnd, czy wszystko jest teraz zrobione tylko wewnątrz Power Query? Drugie - w Tovuti timestampModifiedAfter zwraca wszystkie zmienione rekordy stabilnie w UTC, czy tam jest lokalny czas konta?
> https://business.ingello.com/platforma - blisko logiki korporacyjnej platformy, gdzie ważna jest stabilna struktura danych i wsparcie procesów
> https://business.ingello.com/forma-bpm - podobne podejście do procesów biznesowych, powiązań między bytami i kontrolowanej automatyzacji
> https://business.ingello.com/vorfahr - przykład z integracjami i automatyzacją, gdzie ważna jest niezawodność wymiany danych
Krótko o nas - Ingello Systems tworzy systemy biznesowe, integracje, CRM, automatyzację i raportowanie, gdzie błąd w danych kosztuje więcej niż normalna architektura. Główny landing dla giełdy - https://systems-fl.ingello.com/ua
Na początek potrzebny jest aktualny plik Power BI lub kod M problematycznej tabeli, przykład odpowiedzi courseProgresses, parametry autoryzacji do API Tovuti i krótkie wyjaśnienie, jak obecnie uruchamiane jest odświeżanie. Zobaczcie, tu jest niuans - jeśli historyczna tablica już jest duża, być może lepiej zrobić jeden kontrolny pełny zrzut, a potem prowadzić tylko inkrementalne zmiany. Tak mniej ryzyka, że naprawimy 429, ale zostawimy wolny model na przyszłość.
Budżet: 8000 UAH Termin: 3 dni
Mamy doświadczenie w optymalizacji zapytań do API w Power Query w celu obejścia limitów. Realizujemy to poprzez wdrożenie mechanizmów buforowania i logiki przetwarzania wsadowego danych, aby uniknąć błędu 429. To zapewni stabilne działanie Twoich raportów bez przekraczania limitów Tovuti LMS. Jesteśmy gotowi do rozpoczęcia konfiguracji integracji w najbliższym czasie.
Budżet: 5000 UAH Termin: 4 dni
Cześć, Olgo!
Zadanie zrozumiane: raport za każdym razem przeładowuje całą historię courseProgresses, objętość przekroczyła limit Tovuti — stąd 429. Trzeba przekształcić tabelę faktów AssigmentsProgress na inkrementalne doładowanie i nauczyć zapytanie przeżywać limit, a nie upadać.
Jak to zrobię:
• Przepiszę zapytanie w Power Query (M) tak, aby courseProgresses ciągnęło się z timestampModifiedAfter — tylko nowe/zmienione rekordy od ostatniej aktualizacji zamiast pełnego backfill.
• Dodam opakowanie retry/backoff: na 429 zapytanie robi pauzę z narastaniem i powtarza (z limitem prób), plus poprawna paginacja.
• Sprawdzę na waszym rzeczywistym API Tovuti, że odświeżenie przechodzi do końca i powiązania Teams/Courses/Users pozostają całe.
• Krótko udokumentuję, co i dlaczego zmieniono, abyście mogli sami to wspierać.
Dwa wyjaśnienia:
Gdzie przechowywać „punkt odniesienia” dla timestampModifiedAfter — osobny parametr, czy raz robimy pełny backfill, a potem tylko inkrement?
Odświeżenie idzie przez Power BI Service (zgodnie z harmonogramem) czy Desktop? Od tego zależy, jak zrobić datę stabilną między aktualizacjami.
Termin — 3–4 dni robocze razem z testem na waszym API. Cena stała, orientacyjnie 5 000 zł; sfinalizuję po odpowiedziach powyżej.
Budżet: 1000 UAH Termin: 1 dzień
Dzień dobry! Jestem gotowa poprawić ten błąd!! Mogę to zrobić jutro!!!
Budżet: 1111 UAH Termin: 1 dzień
Dzień dobry!
Mam doświadczenie w pracy z Power BI, Power Query (M) oraz integracjami REST API. Rozumiem problem: przez pełne ładowanie historii API napotyka na limit zapytań, dlatego optymalnym rozwiązaniem jest przejście na inkrementalne aktualizacje.
Po zapoznaniu się z aktualnym Power Query i API będę mógł ocenić terminy i zaproponować stałą cenę.
Budżet: 27000 UAH Termin: 5 dni
mamy już praktycznie gotowe podobne rozwiązanie do inkrementalnej aktualizacji danych przez API, można je szybko dostosować do Tovuti LMS i Power BI ))
w ocenie - 28000 UAH i orientacyjnie 5 dni roboczych po uzyskaniu dostępu do raportu, testowego API i obecnej logiki Power Query.
Będę pracować nie tylko z błędem 429, ale z przyczyną - pełne przeładowanie historii w AssigmentsProgress.
> przeniosę ładowanie courseProgresses na inkrementalny model przez timestampModifiedAfter
> dodam kontrolę paginacji, ograniczeń API oraz retry/backoff przy 429
> sprawdzę powiązania z Teams, Courses, Users oraz AssigmentsProgress, aby po zmianie zapytania model nie został uszkodzony
> krótko opiszę, co się zmieniło i jak to wspierać dalej
Zobacz, tu jest niuans - trzeba uzgodnić, gdzie dokładnie przechowywać ostatni timestamp do aktualizacji.
w Power BI można to zrobić na kilka sposobów, lepiej wybrać ten, który nie stworzy niespodzianek przy publikacji i planowej aktualizacji w serwisie.
proszę o wyjaśnienie
> raport aktualizuje się w Power BI Desktop czy już przez Power BI Service
> czy w Tovuti jest stabilne pole modified/updated dla courseProgresses, które dokładnie odpowiada timestampModifiedAfter
relewantne przykłady naszej pracy
> https://business.ingello.com/forma-bpm - automatyzacja procesów biznesowych i danych, blisko zgodnie z logiką wspieranej systemu
> https://business.ingello.com/iks - system korporacyjny z księgowością, rolami i analizą
> https://business.ingello.com/vorfahr - przykład bardziej złożonej automatyzacji z integracjami i danymi
główny profil Ingello dla giełdy - https://systems-fl.ingello.com/ua
możemy omówić szczegóły tutaj, jestem w kontakcie =)
ogólnie zadanie w porządku, ale diabeł, jak zawsze, tkwi w datach aktualizacji i cache Power BI.
