core/printer

Wymienny dostawca wydruku dla core/shipping, korzystający z lokalnej aplikacji Windows OrbitoPrinter.exe. Moduł jest niezależny od core/printnode.

Jak działa

1. core/shipping zawsze wywołuje wspólną metodę shipments.printLabel.
2. Aktywny moduł rejestruje się przez hook core.printing.getProvider.
3. Ten moduł zapisuje PDF jako zadanie przypisane do użytkownika.
4. Niewidoczny most dostarczany przez moduł do widoków core/shipping odbiera

zadanie i wysyła PDF do http://localhost:17777/print z tokenem lokalnej aplikacji. Nie wymaga zmian w kodzie frontendu Orbito.

1. Panel potwierdza wynik w module. Automatyzacja czeka na potwierdzenie, więc brak

uruchomionego programu nie daje fałszywego sukcesu.

Dla Orbito Printer 1.2.1 lub nowszego moduł rozwiązuje numer zamówienia przez core/orders i przekazuje go do lokalnego programu w polu name, np. Zamówienie ORD-123. Numer jest dzięki temu widoczny w historii wydruków oraz w kolejce drukarki Windows.

Most utrzymuje jedno oczekujące połączenie jobs.waitNext. Nie odpytuje pustej kolejki co 2 sekundy: moduł budzi połączenie natychmiast, gdy przycisk lub automatyzacja doda zadanie. Połączenie jest odnawiane co 20 sekund wyłącznie jako heartbeat mieszczący się w 30-sekundowym limicie transportu modułów. Ukończone zadanie nie jest zwracane ponownie. Od wersji modułu 1.3.1 błąd zapisu potwierdzenia w Orbito ponawia wyłącznie potwierdzenie, bez ponownego wysłania PDF do lokalnej aplikacji. Utrata odpowiedzi z programu, timeout, HTTP 408/5xx albo wygaśnięcie rezerwacji niepotwierdzonego zadania oznaczają niepewny wynik (uncertain), który nie jest automatycznie drukowany ponownie. Przed ręcznym ponowieniem sprawdź historię Orbito Printer. Spóźnione potwierdzenie może zakończyć takie zadanie. Automatyczna kolejna próba jest dozwolona tylko po pewnym odrzuceniu bez wydruku (HTTP 429). Aktywne ręczne zlecenie jest unikalne dla pary użytkownik–przesyłka: powtórne wywołanie przed potwierdzeniem zostaje scalone, a kolejne kliknięcie po zakończeniu tworzy dokładnie jeden nowy wydruk. Przy aktualizacji moduł automatycznie wygasza stare, oczekujące duplikaty utworzone przez wcześniejsze wersje.

Konfiguracja użytkownika

W Ustawienia → Moduły → Orbito Printer → Konfiguruj każdy użytkownik zapisuje:

• token skopiowany z aplikacji Orbito Printer;
• port (domyślnie 17777);
• opcjonalną dokładną nazwę drukarki Windows; puste pole używa drukarki wybranej

w aplikacji;

• domyślną liczbę kopii.

W ustawieniach aplikacji Windows trzeba dodać dokładny origin panelu, np. https://v2.orbito.pl.

Aktywny może być tylko jeden dostawca: core/printnode albo core/printer. Przyciski w zamówieniach i przesyłkach pozostają takie same.

Automatyzacje

Moduł rejestruje własną akcję Wyślij etykiety zamówienia do Printer na tych samych zasadach co PrintNode. Akcja działa z triggerem Nowa przesyłka (Shipping) i z triggerem pakowania, wybiera konfigurację użytkownika ze zdarzenia (albo ostatniej osoby pakującej), obsługuje liczbę kopii, idempotencję oraz oczekiwanie na potwierdzenie lokalnego programu.

Akcja wymaga klucza zdarzenia core/orders:ORDER_ID (od SDK 4.0.0 klucze innych modułów występują wyłącznie z prefiksem). Opcjonalnie czyta core/shipping:SHIPMENT_ID, aby wydrukować tylko nową przesyłkę, oraz core/shipping:USER_ID jako użytkownika wydruku; bez niego pobiera ostatnią osobę pakującą z zamówienia.

Można też użyć neutralnej akcji core/shipping Wydrukuj etykiety zamówienia, jeżeli automatyzacja ma pozostać bez zmian przy przełączaniu dostawcy wydruku.

Diagnostyka

Most przeglądarkowy zapisuje czytelne komunikaty w konsoli przeglądarki z prefiksem [Orbito Printer]. Błędy rozróżniają API Orbito od lokalnego programu i zawierają metodę HTTP, bezpieczny URL, status oraz skróconą treść odpowiedzi. Token i zawartość etykiety nigdy nie są logowane.

Ostatnie 50 zdarzeń można odczytać w konsoli:

window.__orbitoPrinterClientBridgeV5.getDiagnostics()

Adres API używany przez most można sprawdzić przez:

window.__orbitoPrinterClientBridgeV5.getApiBase()