Jakub ***

Przeprowadziliśmy jeszcze raz testy tym razem na 3 stanowiskach klienckich. Do testu zostało wybranych 10 transakcji i mierzony czas od momentu kliknięcia zarejestruj wpłatę do czasu zakończenia synchronizacji z Allegro. laptop i5-7200u / 20GB RAM - czas około 33 sekundy laptop i5-2520m / 8GB RAM - czas około 33 sekundy desktop e3-1246 v3 / 16GB RAM - czas około 23 sekundy Podczas testu sama rejestracja wpłaty trwała na wszystkich stanowiskach do 10 sekund, reszta czasu to synchronizacja z Allegro i oczekiwanie na odwieszenie komputera . Zużycie procesora było na niskim poziomie (~1%). Wszystkie komputery były podłączone na zasadzie komputer->switch->router->serwer. Żeby wyeliminować możliwość opóźnień na tej ścieżce, podłączyliśmy laptopa z pozycji 1 w ten sposób laptop->router->serwer, ale nie zmniejszyło to czasu wykonywania. Z bardziej istotnych rzeczy do odnotowania: pracujemy na SQL Server Express 2017 (sam serwer to E3-1225 v3 / 20GB RAM / 240GB SATA SSD) połączenie między komputerami a serwerem jest na kablu, porty 1Gb baza zawiera dużo transakcji (wszystkie ~290k), nie była zmieniana od początku istnienia, ale raczej wszystko poza synchronizacją działa zadowalająco W mojej ocenie istnieją tylko trzy możliwości dlaczego u nas się takie coś dzieje, a inni użytkownicy Sello nie zauważają tego problemu: ograniczenia SQL Server Express - z pewnością jest wielu użytkowników z większą bazą od naszej, ale bardzo możliwe, że mają oni wersję płatną, natomiast na mniejszych bazach nie jest to odczuwalne i dlatego nie ma wielu zgłoszeń możliwość wysyłania jakiś dodatkowych danych podczas synchronizacji (nie wiem, jakieś "zaległe") - dlatego u nas zamiast 10 wysyła się np. 70, co powoduje znaczne wydłużenie czasu synchronizacji oczekiwanie na zakończenie jakiegoś zadania - zastanawia bardzo niskie zużycie CPU, a mimo to program się zawiesza (wygląda jakby Sello na coś czekało, a te dane nie nadchodzą - np. nie otrzymało danych do odświeżenia grida, bo select jest w jakiejś kolejce dopiero po wykonaniu synchronizacji z Allegro) Pewnie by pomogło, ale musiałbym dostać takie pozwolenie. Jeżeli już wszyscy nie wytrzymają, to pewnie wtedy P.S. Byłoby fajnie, gdyby ktoś jeszcze się wypowiedział ile czasu mu schodzi na oczekiwanie na zakończenie synchronizacji przy rejestracji wpłat dla 10 transakcji.

Ok, testy zostały przeprowadzone i sytuacja wygląda następująco: Odświeżanie zakładek w transakcjach (F5) bez żadnych filtrów: oczekujące na płatność, do paczek - 1 do 3 sekund wszystkie - 10-15 sekund (przejście na zakładkę wszystkie po zatwierdzeniu wpłat i wydrukach trwa nieco dłużej, ale jest to 20-25 sekund) Rejestrowanie wpłat przy wyłączonej synchronizacji z Allegro trwa znacznie krócej i jest to około 10 sekund, co prawda program się zawiesza, ale maksymalnie na 2-3 sekundy z tego czasu 10 sekund. Różnica jest kolosalna w porównaniu do tego, gdy przy włączonej synchronizacji jest zawieszony na około 60 sekund. Wyłączenie synchronizacji raczej nie wchodzi w grę, ponieważ jest ona wymagana. Najlepiej byłoby tak zrobić, żeby ten proces nie miał wpływu na responsywność systemu ? Dziwię się, że nikt na forum tego nie zgłasza, ale współpracownicy bardzo narzekają w ostatnim czasie właśnie na tą przypadłość. Sam nie miałem świadomości, dopóki się temu nie przyglądnąłem. Jedna minuta tzw. "freeza" wygląda okropnie...

Jest tego typu problem, że przy rejestrowaniu wpłat w zakładce Transakcje->Oczekujące na płatność program zawiesza się na około jedną minutę. Liczba rejestrowanych jednocześnie wpłat to mniej więcej 20, ale przy mniejszej ich liczbie (1-10) tylko nieznacznie skraca się czas zawieszenia. Oczywiście od pewnego czasu (już nie pamiętam, która to była wersja Sello) następuje synchronizacja z Allegro podczas tego procesu. Pytanie jest takie, czy to właśnie przez nią następuje zawieszenie Sello? Osoby obsługujące transakcje, zgłaszają że bardzo utrudnia im to pracę, gdyż w tym czasie nie mogą wykonać żadnej innej czynności do czasu "odwieszenia" programu.

Czyli na tą chwilę jesteśmy skazani na pobieranie aukcji trwających przynajmniej raz na jakiś czas. W każdym razie jestem za opcją konfiguracji godzin automatycznego pobierania (którą można też wykorzystać w innych/przyszłościowych opcjach dla Sello). Bez tego mechanizmu robimy to nieregularnie i od czasu do czasu pojawiają się zgubione aukcje

Rozumiem i zakładam takie dwa warianty: aukcja została zmieniona/wystawiona/usunięta przez serwis Allegro - tutaj jak najbardziej dziennik zdarzeń się sprawdzi, ponieważ Sello przeanalizuje zdarzenia dla aukcji od ostatniej synchronizacji z dziennikiem i na wypadek braku takiej aukcji w bazie Sello, ją doda aukcja została usunięta w Sello (np. przyciskiem delete) - jeżeli taka aukcja będzie z przed ostatniej synchronizacji z dziennikiem zdarzeń, to już nigdy się nie pojawi w Sello, chyba że mamy włączone "Pobieraj oferty trwające" Chyba, że jesteście Bartek przygotowani i na taką okoliczność jak w pkt. 2?

Pytanie do Bartka. Czy jest możliwość dodania do ustawień (Parametry -> Parametry wysyłania i odbierania -> Aukcje) opcji pobierania aukcji w konkretnym przedziale czasowym? Tak jak na poniższym obrazie: Wydaje mi się, że jest to bardzo przydatna funkcja, ponieważ przy dużej ilości aukcji lepiej takie rzeczy wykonywać poza godzinami pracy. Natomiast samo "Pobieraj oferty trwające" co np. 1440 minut nie wystarczy, gdyż przypadkowy restart serwera burzy "harmonogram". Wszystkie dotychczasowe opcje bym zostawił, ale jeżeli zaznaczona byłaby opcja "Pobieraj w godzinach", to wtedy byłby to główny warunek do sprawdzenia na samym początku, przed wszystkimi innymi.

Problem jest trochę innej natury. Jeśli ustawimy wydruk poziomo to wszystko na etykiecie się mieści, ale kod kreskowy staje się nieczytelny. Wtedy jest on prostopadły do głowicy drukarki termicznej i efekt drukowania jest taki, że się rozmywa i czytnik go nie łapie. To powód dlaczego wszystkie etykiety kurierskie są pionowe. Tę etykietę odnośnie przesyłek poleconych też należałoby tworzyć w takim formacie (portretowym). Pytanie czy to Sello tworzy wzorzec i możecie to Bartku poprawić, czy Sello dostaje go tylko z Allegro i tam niestety trzeba w tej spra Ok znalazłem to ustawienie. Teraz druga paczka chce się tworzyć, ale pojawia się błąd przy jej tworzeniu w Sello: "Nieprawidłowy rozmiar paczki dla danego typu dostawy". Ostatecznie tworzy się tylko 1 paczka zamiast dwóch.

OK. To rozwiązanie działa. Dzięki. Sugeruję zmienić nazwę w Sello tej usługi zgodnie z tym co jest w Allegro w WzA, gdyż obecna nazwa nie jest precyzyjna i moim zdaniem jest mocno myląca. Kolejne sprawy: 1) Niestety pojawił się nowy problem. Wszystkie etykiety mamy w formacie pionowym, a te z AllegroPrzesyłkaPolecona są w formacie poziomym. Drukarka etykiet A6 drukuje je pionowo i niestety sporo informacji jest uciętych włącznie z kodem kreskowym. Czy jest na to jakiś sposób? 2) Etykiety tworzone przez mechanizm WzA drukują się pojedynczo - po każdej wydrukowanej etykiecie jest moment przerwy. Podejrzewam, że np. idzie 20 zleceń wydruku po 1 etykiecie zamiast 1 zlecenia na 20 etykiet. Jest to mocne spowolnienie względem Shipx, gdzie wszystko drukuje się płynnie. Czy Bartku będzie to poprawione? 3) W sytuacji kiedy ktoś zakupi więcej produktów i w kolumnie L. paczek pojawia nam się "2" to niestety Sello wraz z WzA generuje nam tylko 1 etykietę. Czy jest jakieś rozwiązanie?

Tak, przydałoby się, aby taka opcja została dodana. Z pewnością by to pomogło.

Niestety brak takiej opcji:

Aktualnie w konfiguracji sposobu wysyłki dla WzA możliwe jest ustawienie wymiarów ręcznie lub poprzez tagi jak poniżej. [Towar::RozmiarPaczki::Wysokosc | is=`0` | then=`25`] Większość naszych towarów nie ma podanej wagi ani wymiarów, dlatego użycie tagów jest dobrym rozwiązaniem w tej sytuacji. Problem pojawia się z wagą, która posiada jedynie wybór z listy rozwijanej i nie ma możliwości użycia tagów jak w przypadku wymiarów. Rozumiem, że przewoźnik, może przyjmować wyłącznie przedziały, ale chyba byłaby możliwość aby na podstawie wpisanej wagi program sam przyporządkował ją do odpowiedniego przedziału? Czy jest szansa, że tagi pojawią się również dla wagi/masy?

Myślę, że takie szybkie pytanie. Aukcja trwająca w Sello jest połączona z produktem w Allegro. Nie widzę opcji odłączenia produktu z poziomu zmian zbiorczych, dlatego chciałem to zrobić inaczej. Usuwam połączenie w Allegro, a następnie poprzez Sello pobieram pełne dane dla tej aukcji trwającej, niestety połączenie z produktem nadal widnieje w Sello, chociaż w Allegro już go nie ma. Czy jest jakaś sprawdzona metoda, aby przeprowadzić takie odłączenie?

Mamy identyczny problem. Niestety Sello tworzy przesyłki Kurier48 zamiast poleconych. Gdzie w Sello mamy dodać informację o usłudze dodatkowej: “Przesyłka polecona firmowa”? Opcję tę mamy zaznaczoną w szablonach i z poziomu samej platformy WzA etykiety tworzą się poprawnie.

Ok, teraz dużo się wyjaśniło. Dzięki. Dla samych "wiadomości" zapętla się za każdym razem, natomiast dla innych działa różnie, raz szybciej, raz wolniej, ale generalnie nie dłużej niż kilka sekund. Ok, postaram się na bieżąco przy aktualizacjach to weryfikować, jeżeli błąd się nie pojawi, to być może i zapętlenie też nie wystąpi. W sumie trochę dziwna sytuacja, ale przy grzebaniu w programie serwisowym (jeszcze przed założeniem tematu) program sam z siebie wyświetlił komunikat, że do wykonania tej operacji (o ile dobrze pamiętam, chodziło o "zdjęcia niepowiązane") konieczne jest wykonanie kompaktowania bazy i jestem pewien, że się zgodziłem. Dlatego uznałem, że wielkość bazy jest już uwzględniona po kompaktowaniu. Teraz natomiast sprawdziłem, ile faktycznie miejsca zajmują poszczególne tabele w bazie i ich wielkość bardzo różniła się od wielkości pliku bazy. Wykonałem jeszcze raz kompaktowanie z programu serwisowego, ale tym razem "ręcznie" i taki rezultat: Chciałbym jeszcze przetestować program serwisowy jak wyczyści te opisy, bo są aukcje jeszcze ze starymi opisami allegro (ale to przy okazji, skoro nie ma takiej potrzeby). Natomiast z samą aktualizacją się wstrzymam do wersji 1.38, w końcu to za trzy dni .

Temat już kiedyś był przeze mnie poruszany, ale pojawia się ponownie. Tym razem jest już działający dodatek czyszczący do programu serwisowego, dlatego chciałbym najpierw od niego zacząć. Mamy problem z wielkością bazy i konieczne jest jej zmniejszenie, aby przeprowadzić aktualizację do (1.37.x / 1.38.0) dlatego będę miał kilka pytań. Wielkość bazy w programie serwisowym oraz na dysku wygląda jak na obrazach poniżej. 1. Skąd wynika różnica w wielkości bazy pomiędzy informacją w programie i informacją z systemu? Czy to jest prawidłowa wartość, gdyż ~1000MB różnicy jest dosyć znaczące? Wydaje mi się, że najlepszym rozwiązaniem byłoby wyczyszczenie "niepowiązanych zdjęć" oraz "aukcji zakończonych", ale bez sprzedaży (tj. bez utworzonego i powiązanego z nimi dokumentu). W programie serwisowym wygląda to następująco: 2. Zdjęcia niepowiązane zajmują aż 1795,28 MB i nie jest możliwe ich usunięcie z programu serwisowego. Czy jest ustawiony jakiś termin dla zakończonej aukcji, kiedy takie zdjęcia mogą być usuwane? Jeżeli nie, to dlaczego tak się dzieje? 3. Aukcje zakończone zajmują u nas ~3000 MB i tutaj czyszczenie jest możliwe, ale tylko o ~450 MB. To jest niewiele. W naszym przypadku najlepsze byłoby kompletne usunięcie aukcji bez sprzedaży, natomiast pozostawienie tych ze sprzedażą i powiązaniami z dokumentami. A i tak w tych pozostawionych wyczyszczenie opisów byłoby bardzo wskazane. Dlatego tutaj pojawia się moje pytanie, czy przy aukcjach zakończonych istnieje również jakaś blokada, która uniemożliwia czyszczenie przy pewnych warunkach? Jeżeli chodzi o wiadomości, to nie jest ich wiele, ponieważ używamy ich wyłącznie do wysyłania powiadomień. Na ten moment jest tego 287,96 MB. Natomiast chciałbym zaznaczyć tutaj, że pojawia się błąd w programie serwisowym i przy kontynuacji "status bar" się zapętla i nic więcej nie można zrobić, jak na obrazie poniżej. Główna treść błędu jest następująca: System.ArgumentOutOfRangeException: Wartość '-1' nie jest prawidłową wartością dla 'Value'. Wartość 'Value' powinna znajdować się w zakresie od 'minimum' do 'maximum'. Nazwa parametru: Value w System.Windows.Forms.ProgressBar.set_Value(Int32 value) w Serwisant.UserObjectAttrControl.calculateAttrPercentage(Double objectSizeMB, DateTime data) w Serwisant.UserObjectControl.estimateTakenSpace(Double databaseSizeMB) w System.Threading.Tasks.Task.Execute() --- Koniec śladu stosu z poprzedniej lokalizacji, w której wystąpił wyjątek --- w System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() w System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) w Serwisant.UserObjectControl.<linkLabelRefresh_LinkClicked>d__23.MoveNext() --- Koniec śladu stosu z poprzedniej lokalizacji, w której wystąpił wyjątek --- w System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()

Tak, jest ustawiony na 4 dni.

Rzeczywiście wcześniej były problemy z tabelami au_Picture oraz au_CategorySpecyfic, zostały naprawione. Aktualnie przy odświeżaniu sekcji ważnych informacji pojawia się tylko coś takiego: W sumie zauważyłem 3 problematyczne aukcje, z czego (chyba) po pełnej synchronizacji parametrów z serwisu 2 się "naprawiły". Pozostała jeszcze tylko jedna ? --- Po zrestartowaniu całego serwera ostatnia problematyczna aukcja pobrała pełne dane prawidłowo (musiała być zablokowana przez któryś z procesów).

Od pewnego czasu zauważyłem dziwny problem z niektórymi ofertami. Objawia się tym, że nie można pobrać pełnych danych. Zwracany komunikat jest niejasny: Podgląd oferty jest wyświetlany i dane w podglądzie są raczej prawidłowe, patrzyłem też pobieżnie do bazy i tam też nic nie zauważyłem niewłaściwego. Gdzie mógłbym szukać przyczyny takiego problemu? Serwera jeszcze nie resetowałem, ale po wyłączeniu wszystkich klientów i zresetowaniu samego Sello na serwerze, sytuacja się nie zmienia i problem nadal występuje dla tych samych ofert.

Opis problemu jest ogólny, ponieważ nie ma żadnych innych błędów. Czy może Subiekt ma gdzieś jakieś logi, o których nie wiem? Jeśli chodzi o zasugerowane problemy: Do konwersji nawet nie dochodzi. Baza ma się skonwertować po aktualizacji Subiekta, ale właśnie pojawia się opisany we wcześniejszym poście błąd. Niestety nie wiem jak to sprawdzić, choć byłby to dziwne, że serwer pracuje od dłuższego czasu poprawnie i teraz miałby się okazać, że coś jest błędnie zainstalowane j/w do konwersji w ogóle nie dochodzi. W logach nic nie ma. Jest tylko podłączenie do bazy i rozłączenie - nie wykonują się żadne operacje.

Po aktualizacji Subiekta GT do 1.63 SP2 HF1 (z wersji 1.60) należy przeprowadzić konwersję bazy danych i w tym momencie pojawia się poniższy błąd: "błąd podczas przetwarzania bazy danych upewnij się że zainstalowany jest pakiet sql 2005 backward compatibility" Oczywiście pakiet jest zainstalowany, był również przeinstalowywany - bezskutecznie. Próbowaliśmy aktualizacji z 2 komputerów klienckich jak i serwera (Windows server 2012). Co ciekawe nawet przy próbie stworzenia nowej bazy instalacja się wykrzacza (Subiekt się zamyka bez jakichkolwiek błędów). Do momentu aktualizacji wszystko działało prawidłowo. Baza jest postawiona na SQL Server 2017 Express. Dla testów sprawdziliśmy czy uda się postawić nową bazę na SQL Server 2014 i o dziwo zadziałało bez problemów. Sello (aktualizowane w zeszłym tygodniu) w dalszym ciągu łączy się z bazą i działa prawidłowo. Wygląda to jakby był problem z komunikacją między Subiektem na SQL Serverem 2017 Express. Czy ktoś spotkał się z podobnym problemem? Czy ktoś ma najnowszą wersję Subiekta i działa ona na SQL Server 2017 Express? Może ma ktoś jakiś pomysł co może być przyczyną całej sytuacji?

Dzisiaj aktualizowaliśmy Sello 1.35 -> 1.36 i sytuacja jest dosyć podobna, z tym że oprócz braku niektórych transakcji nie pobierało również statusów zamówienia oraz statusów płatności. Nie wiem, czy nie jest to problem z Allegro, ponieważ pojedyncze transakcje powoli się pojawiają.

Bartku, proszę o potwierdzenie, że w nowej wersji 1.35 planowanej na maj, będzie ta opcja gabarytu dla przesyłek paczkomatowych. Myślę, że z wiadomej przyczyny każdy ma wzrost ilości paczek z tą formy wysyłki, a ta funkcja byłaby dla nas nieocenioną pomocą :)

Mamy ten sam problem. Niestety od jakiegoś czasu DPD przepuszcza takie paczki. Kiedyś pojawiał się błąd kodu pocztowego co dawało możliwość wychwycenia takich przesyłek. Najlepszy rozwiązanie jakie mogłoby pojawić się w Sello to właśnie podświetlanie takich transakcji lub chociaż notatka. My akurat nie korzystamy z list magazynowych. Najgorsze jest to, że Allegro nie ma zamiaru nic z tym zrobić i problem na pewno pozostanie. Wg nich nie musimy takich przesyłek wysyłać. Niestety nie da się sprawdzać adresu do każdej transakcji...

Pamiętam, że na forum był już poruszany ten temat i miało coś ruszyć po skończeniu synchronizacji transakcji z REST API. Czy jest w końcu szansa na przypisanie gabarytu Paczkomatów (A,B lub C) do konkretnego towaru? I jednocześnie przy zakupach łączonych aby był brany automatycznie pod uwagę gabaryt największego towaru? Przykład: Zapałki - przypisujemy na stałe gabaryt A Piłka do koszykówki - przypisujemy gabaryt C. Jeśli ktoś kupi zapałki to przy tworzeniu paczki automatycznie wskoczy jej rozmiar jako gabaryt A, jeśli zakupi piłkę to analogicznie wskoczy gabaryt C. Jeśli natomiast zakupi oba przedmioty to automatycznie ustawi się gabaryt z największego przedmiotu, czyli w tym wypadku C. Wiem, że czasami i tak ręcznie trzeba będzie ten gabaryt dalej zmieniać, bo ktoś kupi 10 przedmiotów o wielkości A, ale razem wejdą one dopiero do skrytki B. Nie ukrywam, że przy zróżnicowanym asortymencie pilnowanie tego aspektu dla każdej transakcji jest uciążliwe. Jeśli się uda to wprowadzić to do sprawdzania zostaną nam tylko grupy transakcji.

Bartek, nam wcześniej nigdy nie zdarzyły się duble przy grupowaniu. Z tego co udało mi się ustalić, to w takiej sytuacji, którą opisałem wyżej na 1.32 program się na krótko zwieszał i pojawiał się komunikat o błędzie (brak dostępu?). Nie odpowiem, bo sam tego nie grupowałem, ale możecie sprawdzić tą sytuację na 1.32 i na 1.33 jak to wygląda.