Czego potrzebujesz, by łatwiej przejść na REST API Allegro

[TomekKaczmarek]

Jak wiecie wygaszamy WebAPI, tym samym wszystkie rozwiązania, które z niego korzystają muszą przejść na REST API Allegro.

Zastanawiamy się, czy i jak możemy Was w tym temacie wesprzeć. W komentarzach do tego posta podzielcie się swoimi pomysłami. Co możemy Wam dostarczyć, by ułatwić przejścia na nowe API - poradników, narzędzi, czegokolwiek, co ułatwi Wam ten proces.

Jeśli widzicie pomysł, który Wam się podoba - dajcie łapkę w górę.

Listę Waszych pomysłów przeanalizujemy i na jej podstawie podejmiemy decyzję, co i w jakiej formie możemy Wam dodatkowo dostarczyć.

Zachęcamy do komentowania!

[rtnet-pl]

• Zasoby odpowiadające metodom doGetUserLogin i doGetUserID
• Zasób podobny do GET /sale/offers pozwalający odczytać publiczne informacje z oferty należącej do innego użytkownika
• Zasób do wyszukiwania kategorii po nazwe (działający podobnie jak "podpowiadacz" kategorii przy wystawianiu oferty przez WWW)

[Onixarts]

W zasadzie na chwilę obecną potrzebujemy jedynie... czasu. Nie samym API żyją programy i mamy też sporo innej pracy na głowie.

[mtumtu]

Odpowiednik doGetItemsInfo (czyli de facto punkt 2 zgłoszony przez rtnet-pl)

[neldh]

Przede wszystkim brakuje mapowań id związanych z transakcjami między starym i nowym api. lineItemId <=> dealId jest niewystarczające. Trzeba się mocno natrudzić, żeby dokopać się z tego do powiązań id całych płatności (patrz niżej). Rozumiem, że w nowym systemie nie jest to jeden do jeden ze starym, ale mimo wszystko mapowania brak, a jest niezbędne do przejścia ze starego api na nowe w przypadku systemów obsługujących transakcje.

Brakuje przede wszystkim mapowań: postBuyFormId <=> payment.id postBuyFormId <=>surcharges.*.id Co jest o tyle dziwne, że w panelu allegro na "karcie płatności" obie wersje id (stara i nowa) są wyświetlane obok siebie bezproblemowo. Dodatkowo, w przypadku gdy klient wykona kilka dopłat, spięcie id dopłaty z webapi z restowym id dopłaty jest w tej chwili niemożliwe do zrealizowania jednoznacznie. Trzeba posługiwać się kolejnością/wartościami kwot (da się zrobić, ale trochę zgadywania jest).

Przydałoby sie też takie cudo, bo wasze nowe api w wielu miejscach wykorzystuje checkoutFormId, ale da się żyć bez tego (wiem, że nie będzie to mapowanie jeden do jeden, ale zawsze byłoby pomocne): postBuyFormId <=> checkoutFormId

Idealnie byłoby mieć podane te stare idki na tacy we wszystkich odpowiedziach, np w bloku "deprecatedIds" (w środku wyszczegolnione stare odpowiedniki, np "postBuyFormId": []), a blok ten mógłby zniknąć np po całkowitym wyrzuceniu przez was starego api, albo metod starego api, które te id wykorzystują. Wtedy płynne przejście na działającym systemie byłoby dużo prostsze.

[lewekleonek]

1. Sfinalizowane zasoby w order management (są nadal w [BETA])
2. Brak zasobu który zwracałby dane użytkownika (patrz: Web API doGetMyData); ten temat był już tutaj poruszony. Konkretnie, potrzebne są dane zwracane w węźle userData
3. To co już było wspomniane powyżej przez @neldh : "Przede wszystkim brakuje mapowań id związanych z transakcjami między starym i nowym api. lineItemId <=> dealId jest niewystarczające.":
   WebAPI: doGetPostBuyFormsIdsRequest - formsId (long)<=> REST API /order/checkout-forms - checkoutForms.id (UUID) WebAPI: doGetPostBuyFormsDataForSellersRequest - postBuyFormShipmentId (long)<=> REST API /order/checkout-forms - checkoutForms.delivery.method.id (UUID)

[pijablonski]

1. Wysyłka trackingu (odpowiednik doAddPackageInfoToPostBuyForm) - w tej chwili jej brak to jedyne, co powstrzymuje nas przed wdrożeniem obsługi zamówień przez REST API do wersji testowej naszej aplikacji.

2. Brak możliwości pobrania szczegółów aukcji innych użytkowników przez REST API oznacza konieczność ciągłego utrzymywania WebAPI.

[jkb32]

1. Brak możliwości filtrowania zamówień po konkretnym numerze aukcji. Nasze oprogramowanie można "dopiąć" do aukcji w czasie jej trwania, przez co program musi przeszukać cały dziennik zamówień od początku by pobrać zamówienia. Do opcji filtrowania po dacie zamówienia przydało by się dodać filtrowanie po numerze aukcji.

[pietrach]

3 czerwca to trochę za szybko niestety, jeszcze z 2 miesiące dłużej by się przydało (3 wrzesień byłby ok)

[kfijalko]

1) Pobieranie "opinii o produkcie". 2) Pobieranie historii opłat (wystawienie, promowanie, utrzymanie) w powiązaniu z ofertą oraz opłat nie związanych z ofertą (logo, abonament ...). 3) Pobieranie historii wpłat od klientów. 4) Pobieranie zestawień wypłat z konta allegro. 5) Zarządzanie cross-sellem przez resta. Podobny mechanizm do obecnego w Nowym MS. 6) Metody typu "google trends" - badanie słów kluczowych. 7) Obsługa zwrotów przez resta. 8) Obsługa wysyłki:

• dodawanie numerów przesyłek
• pobieranie trackingu dla przesyłek (wiem, że można od kuriera ale chcę widzieć to samo co widzi klient) 9) Obsługa "Czarnej Listy" przez resta.

[kfijalko]

Mechanizm przyrostowy informujący o zmianie w drzewie kategorii lub w parametrach konkretnej kategorii. Teraz ściągam drzewo + parametry i sprawdzam co się zmieniło od ostatniego pobrania. Jeżeli tak robi x tysięcy sprzedawców/developerów to efektywniejsze jest zrobienie tego po Waszej stronie i wystawienie przyrostu do pobrania.

[kfijalko]

No i najważniejsza rzecz, od której powinienem zacząć: 1) Zwiększenie limitów 2) Poprawa stabilności/zwiększenie mocy Mam około 100k ofert w aplikacji, przetwarzanie zajmuje bardzo dużo czasu. Pobieranie danych i aktualizacje ofert puszczam w kolejkach i muszę bardzo ograniczać liczbę workerów + mechanizm pilnowania limitów. A i tak trafiam na przekroczenie limitów + 503 "UpstreamServiceFailedException - Service unavailable. Please try again later." + TimeOut'y przy połączeniu.

W sumie to ten punkt jest dla mnie najważniejszy.

[deneb-k]

Brakuje informacji o powodzie zakończenia oferty - czy skończył się czas, czy się wyprzedało, czy została zamknięta ręcznie przez sprzedającego, czy została zamknięta przez administrację. Zwłaszcza to ostatnie jest konieczne, by nie próbować już takiej wystawiać ponownie w niezmienionej postaci.

Brakuje zasobu, którym można by odpytać, czy daną ofertę da się wznowić i jak nie, to dlaczego nie. Trzeba próbować, by się dowiedzieć.

Przydałby się zasób, którym mogę sprawdzić, czy zdjęcie nadal znajduje się na serwerze. Wiadomo, że data wygaśnięcia zdjęcia otrzymana przy wysyłaniu nie ma specjalnego znaczenia - zdjęcie może być gdzieś użyte, więc będzie nadal dostępne, aż nagle przestanie być dostępne, bo oferta z nim zostanie przeniesiona do archiwum. Teraz po prostu pobieram curlem zdjęcie i sprawdzam czy dostałem 200 czy 404, ale to marnowanie zasobów.

Bardzo niejednolite są komunikaty błędów. Część zasobów nie zwraca w ogóle userMessage, brakuje wielu tłumaczeń mimo zadeklarowania polskiej wersji językowej w nagłówkach.

[neldh]

Bardzo ważne: Brakuje danych kupującego w końcówkach checkout-forms. Przede wszystkim imienia. Do kupującego wolalbym zwracać się po imieniu w korespondencji (teraz mogę tylko po loginie). Nazwisko i dane adresowe też by było dobrze znać. Dane adresowe umożliwiałyby zwiększenie automatyzacji (oczywiście po wcześniejszej korespondencji z kupującym).

Tak czy siak, brak imienia jest po prostu nie do zaakceptowania.

[pietrach]

Powinny być jeszcze filtry data rozpoczęcia oferty od do oraz data zakończenia oferty od do. Pozwolilo by to zastąpić dziennik zmian.

[pijablonski]

Możliwość pobrania np. na zasobie [GET] /sale/offers/{offerId} sposobów dostaw wypełnionych ręcznie (poza cennikiem dostawy) ułatwiłaby masową migrację na cenniki dostaw.

[pskz]

odpowiednik doGetSiteJournal obecnie odpytywanie po /sale/offers przy większej ilości ofert jest uciążliwe i trwa za długo

[grzegorzjj]

Nas nie trzeba bardzo wspierać, a dostarczać do REST API to, co już jest w webAPI. Mnie głównie chodzi o to, co napisał [rtnet-pl] - Zasób podobny do GET /sale/offers pozwalający odczytać publiczne informacje z oferty należącej do innego użytkownika. Czasem mam wrażenie, że ktoś Wam każe wyłączyć jakąś metodę bez względu na to, czy jest jej zastępstwo. Mój request w tej sprawie poza "przekażemy do odpowiedniego działu" nie sprawił nic. Wesprzyjcie mnie proszę w tym temacie.

[grojanteam]

To jeszcze powiedzcie mi jak pobrać wszystkie dostępne metody płatności? Chciałbym sobie np. zmapować metody z metodami w swojej aplikacji... I nigdzie nie mogę znaleźć na REST odpowiednika do doGetPaymentMethods

[pietrach]

Ewidentnie brakuje odpowiednika doGetSiteJournal bo jak na bieżąco pobierać informacje np. o ostatnio zakończonych aukcjach ? Brakuje metody z filtrem changeDateFrom, changeDateTo gdzie było by odpowiednikiem daty ostatniej zmiany w aukcji a zmiana mogła być taka:

• rozpoczęcie oferty,

• zakończenie oferty,

• złożenie oferty kupna,

• zmiana w ofercie,

• odwołanie oferty kupna,

[TomekKaczmarek]

Dziękujemy Wam bardzo za pomysły i uwagi. Przeanalizujemy je i w ciągu tygodnia poinformujemy w tym poście czy, co i kiedy na ich podstawie zrobimy.

[qls-api]

Dołączam się do prośby o dołączenie odpowiednika doGetSiteJournal

[ghost]

Potwierdzam problem braku doGetSiteJournals. Operujemy na rozwiązaniu multitenant a naszym oprogramowaniu, dzienniki pozwalały na pobieranie danych różnicowo, operujemy na ponad 350k aukcji, przez brak takiego rozwiązania w restAPI moim zdaniem dyskwalifikuje go, działanie będzie mało wydajne i nasi Klienci nie będą zadowoleni jeśli proces ten spowolni

[FromAnyHole]

Waiting-State...

[ghost]

• Zasoby odpowiadające metodom doGetUserLogin i doGetUserID

@TomekKaczmarek @MartaNowaczyk kiedy planowane są dodanie w RestAPI takich metod? Obecnie prezentujemy informacje o kontach w naszych aplikacjach, teraz nic nie wiadomo :)

[lukaszzborek]

1309

[sw69]

@TomekKaczmarek Witam, załóżmy sytuację, w której klient wybrał dostawę paczkomatem. Api zwraca tylko adres dostawy i pickup pointu, nie mam danych klienta. Jak ja mam wystawić mu fakturę na osobę fizyczną? Nie mam nawet jego imienia i nazwiska. W dokumentacji nie widzę żadnej metody, która by mogła jakoś mi to zwrócić.

[MartaNowaczyk]

Dziękujemy Wam za zaangażowanie i cierpliwość. Dokładnie przyjrzeliśmy się Waszym uwagom i uwzględniliśmy je w planie prac nad REST API na dwa najbliższe kwartały. Ustalenie zakresu pracy zajęło nam więcej czasu, niż początkowo przewidywaliśmy - dlatego dłużej czekaliście na naszą odpowiedź. Przepraszamy!

Poniżej znajdziecie cytaty z Waszych wypowiedzi i nasze odpowiedzi. Wiele proponowanych przez Was zmian planujemy wprowadzić - dziękujemy Wam za feedback.

---

1/

Zasób podobny do GET /sale/offers pozwalający odczytać publiczne informacje z oferty należącej do innego użytkownika Odpowiednik doGetItemsInfo Brak możliwości pobrania szczegółów aukcji innych użytkowników przez REST API oznacza konieczność ciągłego utrzymywania WebAPI

Będziemy pracować nad zasobem, który zwróci publiczne dane o ofercie. Udostępnimy go w ciągu najbliższych dwóch kwartałów.

2/

odpowiednik doGetSiteJournal Ewidentnie brakuje odpowiednika doGetSiteJournal Dołączam się do prośby o dołączenie odpowiednika doGetSiteJournal Potwierdzam problem braku doGetSiteJournals Brakuje metody z filtrem changeDateFrom, changeDateTo gdzie było by odpowiednikiem daty ostatniej zmiany w aukcji...

Będziemy pracować nad zasobami, które zwrócą eventy ofertowe i zakupowe. Udostępnimy je w ciągu najbliższych dwóch kwartałów.

3/

Zasoby odpowiadające metodom doGetUserLogin i doGetUserID

Będziemy pracować nad zasobem, który zwróci publiczne dane o użytkowniku. Udostępnimy go w ciągu najbliższych dwóch kwartałów.

4/

Brak zasobu który zwracałby dane użytkownika (patrz: WebAPI doGetMyData)

Będziemy pracować nad zasobem, który zwróci niepubliczne dane o użytkowniku, tak jak metoda doGetMyData. Udostępnimy go w ciągu najbliższych dwóch kwartałów.

5/

Przede wszystkim brakuje mapowań id związanych z transakcjami między starym i nowym api (...) Pobieranie historii wpłat od klientów Pobieranie zestawień wypłat z konta allegro

Pracujemy na odpowiednikiem Historii operacji w REST API, która operuje na tych samych identyfikatorach wpłat, które zwracamy w zamówieniach. Dzięki temu proces związany z obsługą zamówień będzie można w pełni realizować przez REST API. Rozważamy też wystawienie mappera stary-nowy id płatności.

6/

Wysyłka trackingu (odpowiednik doAddPackageInfoToPostBuyForm) dodawanie numerów przesyłek

Udostępniliśmy dwa zasoby, które pozwolą dodać i pobrać numer przesyłki.

7/

Brak możliwości filtrowania zamówień po konkretnym numerze aukcji. Nasze oprogramowanie można "dopiąć" do aukcji w czasie jej trwania, przez co program musi przeszukać cały dziennik zamówień od początku by pobrać zamówienia. Do opcji filtrowania po dacie zamówienia przydało by się dodać filtrowanie po numerze aukcji.

Będziemy pracować nad taką opcją filtrowania zamówień. Najprawdopodobniej udostępnimy ją w drugim kwartale tego roku.

8/

Pobieranie historii opłat (wystawienie, promowanie, utrzymanie) w powiązaniu z ofertą

Będziemy pracować nad zasobem, który zwróci podobne dane jak doMyBillingItem. Udostępnimy go w ciągu najbliższych dwóch kwartałów.

9/

Brakuje informacji o powodzie zakończenia oferty - czy skończył się czas, czy się wyprzedało, czy została zamknięta ręcznie przez sprzedającego, czy została zamknięta przez administrację. Zwłaszcza to ostatnie jest konieczne, by nie próbować już takiej wystawiać ponownie w niezmienionej postaci.

Planujemy dodać takie informacje w odpowiedzi dla GET /sale/offers/{id} w ciągu najbliższych kilku tygodni.

10/

Możliwość pobrania np. na zasobie [GET] /sale/offers/{offerId} sposobów dostaw wypełnionych ręcznie (poza cennikiem dostawy) ułatwiłaby masową migrację na cenniki dostaw.

Podobnie jak bezpośrednio w serwisie, tak i w API odchodzimy od dodawania “luzem” metod dostawy do oferty. Nie planujemy udostępnić takiej opcji w REST API. Użytkowników warto zachęcić, by przypisali cennik dostawy do swoich oferty - mogą to zrobić dla wielu ofert na raz, dzięki tym zasobom.

11/

Obsługa "Czarnej Listy" przez resta.

Będziemy pracować nad zasobami, które pozwolą zarządzać czarną listą. Udostępnimy je w ciągu najbliższych dwóch kwartałów.

12/

Brakuje danych kupującego w końcówkach checkout-forms. Przede wszystkim imienia. Do kupującego wolalbym zwracać się po imieniu w korespondencji (teraz mogę tylko po loginie). Nazwisko i dane adresowe też by było dobrze znać. Dane adresowe umożliwiałyby zwiększenie automatyzacji (oczywiście po wcześniejszej korespondencji z kupującym).

Nie planujemy podawać adresu z konta kupującego. Zwracamy tylko ten adres, który kupujący faktycznie podał w zamówieniu. Dzięki temu przesyłka na pewno będzie wysłana, tam gdzie chce tego klient. Imię i nazwisko kupującego dodamy w kolejnym kwartale.

13/

Bardzo niejednolite są komunikaty błędów. Część zasobów nie zwraca w ogóle userMessage, brakuje wielu tłumaczeń mimo zadeklarowania polskiej wersji językowej w nagłówkach.

Z tym problemem pracujemy na bieżąco - jeśli widzisz taki komunikat, zgłoś to nam. Postaramy się poprawić komunikat błędu.

14/

Przydałby się zasób, którym mogę sprawdzić, czy zdjęcie nadal znajduje się na serwerze. Wiadomo, że data wygaśnięcia zdjęcia otrzymana przy wysyłaniu nie ma specjalnego znaczenia - zdjęcie może być gdzieś użyte, więc będzie nadal dostępne, aż nagle przestanie być dostępne, bo oferta z nim zostanie przeniesiona do archiwum. Teraz po prostu pobieram curlem zdjęcie i sprawdzam czy dostałem 200 czy 404, ale to marnowanie zasobów.

W tej sytuacji możesz zrobić request na HEAD {adres zdjęcia}. W odpowiedzi otrzymasz informacje, czy zdjęcie nadal znajduje się na serwerze.

Np. Request: curl -X HEAD -i https://1.allegroimg.com/original/110843/cd7d40b84968ab8d79ab8a2e47a1 Response: HTTP/2 200 - zdjęcie nadal znajduje się na serwerze HTTP/2 404 - zdjęcie nie jest już dostępne.

15/

WebAPI: doGetPostBuyFormsDataForSellersRequest - postBuyFormShipmentId (long)<=> REST API /order/checkout-forms - checkoutForms.delivery.method.id (UUID)

Nie rozumiemy celu takiego mapowania. W REST API otrzymujesz identyfikator i nazwę wybranej metody dostawy, dlatego taka opcja nie powinna być potrzebna.

16/

Poprawa stabilności/zwiększenie mocy. Mam około 100k ofert w aplikacji, przetwarzanie zajmuje bardzo dużo czasu. Pobieranie danych i aktualizacje ofert puszczam w kolejkach i muszę bardzo ograniczać liczbę workerów + mechanizm pilnowania limitów. A i tak trafiam na przekroczenie limitów + 503 "UpstreamServiceFailedException - Service unavailable. Please try again later." + TimeOut'y przy połączeniu.

Wygląda to na konkretny problem. Zgłoś go proszę w ramach osobnego wątku, opisz kiedy i w jakich sytuacjach na niego natrafiasz, załącz przykładowy request, response, trace-Id requestów, które kończą się błędem. Przyjrzymy się tematowi.

17/

Brakuje zasobu, którym można by odpytać, czy daną ofertę da się wznowić i jak nie, to dlaczego nie. Trzeba próbować, by się dowiedzieć.

Wystarczy, że odpytasz GET /sale/offers/{id} - jeśli w odpowiedzi otrzymasz błędy walidacji, nie możesz wznowić oferty.

18/

To jeszcze powiedzcie mi jak pobrać wszystkie dostępne metody płatności? Chciałbym sobie np. zmapować metody z metodami w swojej aplikacji... I nigdzie nie mogę znaleźć na REST odpowiednika do doGetPaymentMethods

Nie planujemy odpowiednika takiej opcji. W danych o zamówieniu zdecydowaliśmy się zwracać tylko informacje o tym, czy płatność jest elektroniczna czy przy odbiorze. Dodatkowo wskazujemy operatora płatności. W naszej ocenie jest to wystarczająca ilość informacji, które pozwolą na skuteczną realizację zamówienia.

19/

Zasób do wyszukiwania kategorii po nazwe Pobieranie "opinii o produkcie" [Pobieranie historii] opłat nie związanych z ofertą (logo, abonament ...) Zarządzanie cross-sellem przez resta Metody typu "google trends" - badanie słów kluczowych Obsługa zwrotów przez resta Mechanizm przyrostowy informujący o zmianie w drzewie kategorii lub w parametrach konkretnej kategorii pobieranie trackingu dla przesyłek (wiem, że można od kuriera ale chcę widzieć to samo co widzi klient) [W moich ofertach] Powinny być jeszcze filtry data rozpoczęcia oferty od do oraz data zakończenia oferty od do. Pozwolilo by to zastąpić dziennik zmian.

Dziękujemy za Wasze pomysły. Żaden nie zginie, wszystkie zapisaliśmy. Przeanalizujemy je i podejmiemy decyzję, które, kiedy i w jaki sposób udostępnić. W tym momencie skupiamy się na zasobach, które realizują procesy dostępne w WebAPI.

[TimothyKoval]

Mam rozumieć, że dziennika zmian nie będzie w rest api?

[MartaNowaczyk]

@TimothyKoval w drugim punkcie jest na ten temat :)

Będziemy pracować nad zasobami, które zwrócą eventy ofertowe i zakupowe. Udostępnimy je w ciągu najbliższych dwóch kwartałów.

[TimothyKoval]

A jak już jesteśmy w temacie, to może byście zrobili do zamówień coś à la webhooks - adekwatnie jak np. w PayU. Raz że byłoby to wydajniejsze niż odpytywanie przez dziesiątki tysięcy klientów dziennika transakcji, a dwa, że taki webhook mógłby przekazywać ujednolicone i jasne informacje na temat zamówienia.

[MartaNowaczyk]

@TimothyKoval dzięki za sugestię, dopiszemy do pomysłów.

[ghost]

@MartaNowaczyk Ad 2 Taka metoda jest KRYTYCZNA do zarządzania aukcjami w rozwiązaniu multitenancy! 3.06.2019 chcecie byśmy przeszli na RestAPI, które w tej chwili tego nie wspiera

Nasi użytkownicy mają w sumie wystawione 845 671 aukcji (status na dzień dzisiejszy), obecnie korzystając z dzienników pobieramy tylko nowopowstałe transakcje i dzieje się to w trybie automatycznym, od pojawienia się transakcji w API Allegro do faktury w systemie klienta mija od 15-30 minut. Jak wydajnie zrobić to samo w restAPI bez dzienników?

[MartaNowaczyk]

@SebastianOzdoba nie wystarczy ci do tego ten dziennik zdarzeń?

[alekskuc]

@SebastianOzdoba nie wystarczy ci do tego ten dziennik zdarzeń?

Witam, powyższy dziennik to odpowiednik doGetSiteJournalDeals, który nie zapewnia obsługi listy aukcji.

Do pełnej obsługi wystawionych 845 671 aukcji niezbędny jest brakujący w REST API dziennik listy aukcji czyli odpowiednik WebAPI doGetSiteJournal.

Wszystkie 845 671 aukcje i transakcje posiadają swoje rekordy w lokalnej bazie danych aplikacji, w celu zapewnienia wewnętrznej obsługi sprzedaży wystawianych towarów. Oba dzienniki WebApi doGetSiteJournalDeals doGetSiteJournal pozwalają na zapewnienie szybkiego działania i eliminacji niepotrzebnego ruchu sieciowego obciążającego serwery. Pobierane z WebApi i aktualizowane w lokalnej bazie są wyłącznie rzeczywiście zmienione rekordy aukcji i transakcji.

Nadmiarowy ruch na liście aukcji przez REST API już powoduje problemy opisane w tym wątku.

Scenariusz (multitenency) jest używany w różnych integracjach.

[ghost]

@MartaNowaczyk Punkt 18 Przy procesach automatyzacji oraz integracji z zewnętrznymi systemami ERP taka informacja będzie przydatna (lista form płatności + lista form dostaw). Klient chce zmapować tak zamówienia u siebie by mieć to ustandaryzowane. Na tej podstawie mogą w systemach ERP uruchamiać się automatyczne procesy. Zgadzam się ze to co zwracacie teraz jest wystarczające do samej realizacji, musicie jednak popatrzyć szerzej.

[MartaNowaczyk]

@alekskuc jeśli chodzi o odpowiednik doGetSiteJournal to tak jak napisaliśmy w pkt 2 będzie w ciągu dwóch kwartałów.

[MartaNowaczyk]

@SebastianOzdoba opisz mi konkretnie na przykładzie dlaczego automatyczne procesy mogą uruchamiać się tylko wtedy, gdy mają szczegółowe dane dotyczące metod dostawy?

[ghost]

@MartaNowaczyk Ad 18 Jeśli zamówienie ma formę płatności online to sprawdź rozliczenia i rozlicz Jeśli zamówienie ma inpost, wygeneruj paczkę, wydrukuj etykietę Jeśli zamówienie jest kurierem, przekaż proces do logistyki do pakowania Z uwagi na to że w systemach naszych jest procesowość i ich modelowanie można sobie to dowolnie konfigurować Nikt tego nie opiera o nazwy płatności / dostawy z poszczególnych zamówień, tylko w swoich systemach mapuje że przysłowiowy inpost w allegro to dostawa o ID = 64 w moim systemie Druga sprawa że Klienci korzystają nie tylko z Allegro i takich mapowań robią więcej, Klient mają listę dostaw/płatności Allegro i swoją listę płatności a następnie sobie to mapują jak potrzeba w zależności od firmy.

p.s. w osobnym wątku poruszę temat doGetSiteJournal, 2 kwartały to zbyt długo, jest to naprawdę krytyczna rzecz do realizacji na JUŻ, by można było optymalnie podejść do implementacji tego

[MartaNowaczyk]

@SebastianOzdoba przepraszam, chodziło mi o formy płatności, bo metody dostawy są zrozumiałe.

[ghost]

@SebastianOzdoba przepraszam, chodziło mi o formy płatności, bo metody dostawy są zrozumiałe.

Tak samo, Klient mapuje przykładowo PayU-mTransfer to swojej formy płatności jaką pokazuje potem na zamówieniach, fakturach zarówno wewnętrz i na zewnąrz. Nazwy z API Allegro są tylko pomocnicze.
W większości systemów ERP opierane jest to nie o "tekst" ale o powiązanie po identyfikatorach, przez co system odporny jest na zmiany nazwy a co z a tym idzie zaburzenia w raportach W zależności od płatności mogą następować automatyczne księgowania raportów kasowo-bankowych, rozliczeń, zapisu tych danych w innych rejestrach kasowo-bankowych. Np jeśli online to rejestr A a jeśli pobranie to rejestr B, a jeśli płatność w punkcie to rejestr C

[MartaNowaczyk]

Co do metod płatności to ok: przy odbiorze w punkcie, za pobraniem, płatność z góry... ale nadal nie widzę konieczności w przekazywaniu informacji jaki bank przy przelewie ktoś wybrał.

[neldh]

Wszystkie wspomniane mapowania powinny być wdrożone na START, jeśli chcecie, żebyśmy wszyscy przeszli na REST API jak najszybciej. Brak mapowania skutecznie uniemożliwia lub bardzo utrudnia migrowanie systemu, który działa na żywo. Każdy istniejący już system, obsługujący zamówienia, który do tej pory korzystał z WEBAPI wymaga wielu spośród wymienionych mapowań. Niektóre wymagają wszystkich. Jeśli zmieniacie id czegokolwiek, to mapowanie jest po prostu czymś co powinno być dostępne od początku w REST API. Wszędzie tam, gdzie taka zmiana nastąpiła, powinniśmy mieć dostępne pola w odpowiedziach w stylu oldXXXId/deprecatedXXXId. To są podstawowe informacje przy tego typu migracjach. My nawet nie powinniśmy wam tych braków zgłaszać. Takich braków nie powinno po prostu być. Brak tego typu pól skutkuje po prostu tym, że wiele aplikacji implementuje je na własną rękę. Jest to podejście nieekonomiczne i generujące nieraz masę dodatkowych zapytań. Co więcej, jest podatne na wszelkiego rodzaju błędy i niespójności. Dodatkowo, jak już wcześniej wspomniano, nie mapuje się niczego po nazwie tekstowej, która jest czynnikiem zmiennym.

[ghost]

@MartaNowaczyk dlaczego nie, jeśli chce ktoś robić dodatkowe analizy w swoich aplikacjach to w jaki sposób je będzie wykonywał, noe przecież nie będzie pisał "porównywania tekstu", nie mając tego w sposób rozsądny zesłownikowanego? Musicie popatrzyć szerzej na cały proces, on nie kończy się tylko wysłaniem paczki do Klienta. Poza Wami dzieje się obsługa posprzedażna (reklamacje, zwroty), Klient chce takie rzeczy analizować w oparciu o różne czynniki, między innymi dostawy, płatności, geografię. Zesłownikowanie tych rzeczy i dodanie do API umożliwi nam przygotowanie normalnych konfiguracji dla Klientów.

Zgadzam się z @neldh , że takie rzeczy potem są implementowane już bezpośednio w tych systemach jako workaroundy i pilnowane u producentów danych aplikacji (tak robimy też sami). Sami mamy kilkatysięcy klientów używających Allegro, jeśli restAPI to krok wstecz to musicie nas zrozumieć że wszystkie "gromy" spadną na nas.

[ghost]

@MartaNowaczyk @TomekKaczmarek Ad 2 Wracając do tematu braku doGetSiteJournal Nieprzeniesienie tej metody nastręcza wiele problemów z obsługą offlinową aukcji. Opisuję działanie poniżej na przykładzie większości naszych Klientów

1. Klient X posiada/prowadzi
   • rozbudowany system do zarządzania sprzedażą
   • sprzedaż przez punkty własne, Allegro, Amazon, Ebay, w sklepach internetowych
   • posiada centralną bazę ze stanami magazynowymi która jest na bieżąco aktualizowana
   • w tejże bazie lokalnej ma wszystkie dane, także wszystkie oferty Allegro
2. Klient X uruchamia automat który:
   • aktualizuje oferty w lokalnej bazie na podstawie zadanych parametrów i przesyła do Allegro do aktualizacji
   • aktualizuje oferty bo klient wszedł np. do Menadżera sprzedaży i tam coś zrobił
   • zamyka oferty m.in gdy stan =0
   • sprawdza czy są nowe zamówienia
   • pobiera je i tworzy zamówienia, faktury, dokumenty magazynowe, listy przewozowe w lokalnej bazie danych i przesyła do odpowiednich zewnętrznych systemów

Założenia dalsze do rozważań wydajnościowych

• 5000 ofert aktywnych
• dla losowych 100 coś się zmieniło + pojawiły się transakcje jednopozycyjne, czyli 1 klient kupił 1 sztukę towaru z 1 oferty

obecne działanie (webAPI)

1. pobieramy GetSiteJournal - 1 req do API
2. dostajemy informację, że 100 aukcji zostało zmienionych
3. pobieramy te 100 ofert: 100 / 25 = 4 req do API
4. zapisujemy tak zmodyfikowane oferty u siebie (nie wnikamy skąd została przeprowadzona modyfikacja, Klienci robią je z różnych aplikacji, także z MS) Suma requestów: 5 działamy dalej
5. na podstawie doGetSiteJournalsDeals pobieramy transakcje – 1 req
6. pobieramy transakcje 100 / 25 = 4 req do API
7. realizujemy dalsze procesy, zamówienia, faktury itd Suma: requestów: 5 Suma całej operacji obecnie: 10 requestów Suma dla wszystkich Klientów: 2000 * 10 = 20 000 req do API

nowe działanie (restAPI)

1. nie ma GetSiteJournal - więc nie wiemy co i jak się stało na ofertach
2. zatem pobieramy wszystko co mamy: 5000 / 100 = 50 req do API**
3. aktualizujemy u siebie dane o aukcjach – mocno obciążając lokalną bazę, bo nie wiemy co się zmieniło Suma requestów: 50 - brak GetSiteJournal w tym miejscu działamy dalej
4. pobieramy zamówienia orders/events – 1 req do API
5. następnie dla każdego event pobieramy dane o zamówieniach– 100 req Suma requestów: 101 Suma dla całej operacji: 151 requestów Suma dla wszystkich Klientów: 2000 * 151 = 302.000 requestów

WebAPI vs RestAPI 20.000 vs 302.000 requestów

Oczywiście możemy zrezygnować z zapisywania ofert offline u siebie i tylko pobierać je online (metoda GET /sale/offers), ale to powoduje że:

• Klient nie bedzie mógł zarządzać efektywnie sprzedażą, np. zapinać procesów w postaci: "jeśli coś to coś", np. jeśli stan=0 to, jeśli cena < od cena to itd...
• praca tylko online gdzie dane pobieramy zawsze z API spowoduje że będą one zwracane długo (nie sądzę, że restAPI zwróci 1000 ofert w ciągu < 1 sek)
• ciągle będziemy przekraczać limity bo działamy z jednego IP (limit: 120 req / s)

Dlatego też tak ważne jest by doGetSiteJournal powstało nie w ciągu 2 kwartałów, ale w ciągu 2 tygodni :), alternatywą jest wydłużenie czasu usunięcia starego WebAPI o czas kiedy nie będzie zamiennika

[lukaszzborek]

@SebastianOzdoba co do pobierania zamówień to można lekko ograniczyć ilość req poprzez pobranie nie eventów a listy zamówień, a potem dodatkowo jeszcze dla pewności że wszystkie zamówienia są pobrane, pobrać eventy i sprawdzić czy już taki mamy. Z Web api nie pracowałem więc nie wiem jak to jest tam rozwiązane. Teoretycznie samo pobranie listy zamówień powinno wystarczyć, ale ten dziennik jest taki sobie i raczej powinno się dodatkowo pobrać eventy

[neldh]

@AssAssIn1909 Pamiętaj, że pobierając listę zamówień np z ostatnich dwu dni możesz pominąć dopłaty które zostały wtedy wykonane (a samo zamówienie np zostało wykonane 3 dni temu).

[lukaszzborek]

@neldh Nawet nie mówiąc o dopłatach, a o samym dokończeniu zakupu po tych 3 dniach. Bez dodatkowego pobrania eventów nie ma co pobierać samej listy zamówień. W kolejności wypadnie poza te 2 dni. Na szczęście w eventach trafi na swoje miejsce.

[ghost]

@neldh @AssAssIn1909 nas nawet nie boli ilość requestów dla metod /order. Tak jest i tyle, chociaż cały czas twierdzę że można to ograniczyć. Natomiast aktualizacja ofert w lokalnej bazie jest i będzie masakrą, Klienci nie zrozumieją dlaczego od teraz jest wolniej :) Mam nieodparte wrażenie że restAPI jest trochę pod MS zrobione, gdzie wszystko jest online :)

@MartaNowaczyk @TomekKaczmarek prośba o komentarz jak rozwiązać temat szybciej :)

[marcinja2]

pasowało by zeby GET /offers/listing miał informacje o czasie do końca aukcji /wyczerpania przedmiotów

[ghost]

Podbijam wątek, niecierpliwie czekamy na to co z odpowiednikiem doGetSiteJournal w restAPI szybciej niż za 2 kwartały :) @MartaNowaczyk @TomekKaczmarek