Rozszerzenie przeglądarki operujące na DLL - drukowanie na drukarce fiskalnej

Po pierwsze sorry, ale nie wiedziałem do jakiego działu to wsadzić, więc piszę tutaj, jeżeli zły - proszę moderatora o przeniesienie.

Aktualnie mój klient ma sklep internetowy, gdzie z poziomu starej przeglądarki IE, przy pomocy kontrolki ActiveX drukuje sobie wygodnie paragony na drukarce fiskalnej.

Problem polega na tym, że IE coraz bardziej odstaje od standardów, oraz, od czerwca 2022 Microsoft planuje prawdopodobnie wyłączenie tej przeglądarki.

Klient musi mieć możliwość wygodnego drukowania paragonów z poziomu przeglądarki, najlepiej w Chrome, albo Firefox-ie

Czy jest w takim razie możliwość stworzenia własnego rozszerzenia do chrome lub firefoxa, tak, żeby komunikowało się z windowsową biblioteką DLL odpowiedzialną za drukowanie?

Jeżeli to możliwe to w jaki sposób to robić - gdzie o tym poczytać?

Ewentualnie jeszcze inaczej / lepiej:

Przeglądarka <- własny protokół wymiany danych -> aplikacja lokalna działająca na jakimś porcie <-> DLL drukujące na drukarce fiskalnej

Znam w miarę Java, gorzej z C/C++....

Zdecydowanie drugie rozwiązanie - czyli aplikacja zewnętrzna, komunikująca się jakimś AJAX'em czy czymkolwiek z przeglądarką.

Jak możesz to unikaj łączenia przeglądarki z urządzeniami po stronie klienta, bo to proszenie się o kłopoty. Drukarka - urządzenie lokalne, komunikacja z aplikacją desktopową/jakąś usługą działającą w tle. Przeglądarka siedzi sobie w swoim sandboksie i nie ma pojęcia, na czym jest odpalona, jedynie daje znać, że coś ma się wydrukować, ale szczegóły takiej akcji jej nie interesują.

Plusem zrobienia dodatkowej usługi pośredniczącej jest to, że możesz wtedy z kilku przeglądarek/komputerów korzystać z jednej drukarki. Po prostu - do jednego kompa podłączasz drukarkę, wystawiasz jakiegoś webservice'a i mogą z niego korzystać zarówno użytkownicy tej konkretnej maszyny, jak i np. komputer biurko obok.

Czyli mam:

1. Zrobiony extension np. do Chrome
2. Aplikacje zrobioną lokalnie na komputerze działającą np. na porcie 9888
3. Osoba ma otwarty panel administracyjny sklepu, i robi to na komputerze na którym działa aplikacja z pkt 2). Zaznacza sobie np. 300 zamówień do wydruku, klika drukuj, rozszerzenie z pkt 1) zaczyna pompować na port 9888 dane, a aplikacja z pkt 2) te dane wysyła do DLL które drukuje na drukarce fiskalnej, po czym zwraca sukces z powrotem do pluginu z pkt 1). Idzie informacja zwrotna (przez JS) do panelu administracyjnego, że się wydrukowało, a system sklepu sobie oznacza zamówienia jako wydrukowane.

Ma to sens?

Można na tej maszynie z drukarką postawić też Webservice jak sugerujesz, i to dobry pomysł, ale na razie wystarczyłoby tak jak to opisałem wyżej.

https://bigdotsoftware.pl/posnetserver-restful-service-dla-drukarek-posnet/

A po co ci to rozszerzenie do przeglądarki. Robisz (kupujesz) jakieś API w czymś, co jest w stanie obsłużyć tego DLLa. Wystawiasz end pointa, do którego strzelasz z frontu np z id zamówień, pozycjami itp itd i tam robisz pobranie danych z bazy i wysłanie do drukarki.

No dobrze ale jak "strzelać" do endpointa z poziomu javascript? Ja to muszę obsługiwać javascriptem. Teraz mam activex które obługuję sobie z javascripta,

TomRZ napisał(a):

No dobrze ale jak "strzelać" do endpointa z poziomu javascript? Ja to muszę obsługiwać javascriptem. Teraz mam activex które obługuję sobie z javascripta,

Tak jak pisał szczurek. Najlepiej Ajaxe i niech już tam się dzieje na serwerze co ma się dziać.

Ja wiem, że AJAXem, ale JAK TECHNICZNIE? Na co ja wysyłam te dane?

Musiałbym z poziomu javascripta pisać coś na localhost do określonego portu - chyba tak?

Czyli piszę sobie aplikacje np. w Javie która komunikuje się z DLL i otwiera port, ten powiedzmy 9888 na localhoście.

Javascript kontaktuje się z http://127.0.0.1:9888/ i tak przebiega komunikacja?

Tyle, że wtedy ta aplikacja w Javie musiałaby obsługiwać protokół HTTP - to jest problem, chociaż już nie taki duży.

Czyli mam: 1) Zrobiony extension np. do Chrome

Powtórzę - nie twórz i nie instaluj żadnych rozszerzeń do przeglądarki. Nie tędy droga. Poza tym - bez tego możesz się połączyć z usługą drukowania z dowolnego kompa w sieci, a nie tylko z tych, które mają to coś doinstalowane. Zwyczajna komunikacja typu REST/AJAX i mamy to ogarnięte. Zwłaszcza, że jeśli to ma działać tylko w ramach firmowego LAN to wiele kwestii związanych z zabezpieczeniami odpada.

Javie musiałaby obsługiwać protokół HTTP - to jest problem, chociaż już nie taki duży.

No tak, musiałaby. Aczkolwiek nie jest to jakaś przeszkoda nie do przeskoczenia. Sam Javy unikam, nie lubię, nie znam, nie używam, ale podejrzewam (w oparciu o to, co widze w innych językach) że jest pewnie jakaś gotowa biblioteka/rozwiązanie/moduł/komponent, które po prostu dodajesz do projektu, odpalasz i przy minimalnej konfiguracji używasz.

Ewentualnie, jakby ta komunikacja przez sieć była problemem, to możesz postawić lokalnie jakiś sewer WWW, JS z przeglądarki klienta niech do niego się łączy. A ten serwer WWW niech zapisuje zlecenia w bazie. Potem piszesz w tej swojej Java apkę/workera odpowiedzialnego za wydruki. Niech ta usługa co powiedzmy 5 sekund sprawdza, czy są nowe zlecenia druku w bazie. W ten sposób masz może trochę więcej pracy, ale jest to sensownie rozbite, do tego ładnie zapewnia wielodostęp i masz niezłe możliwości skalowania.

TomRZ napisał(a):

Ja wiem, że AJAXem, ale JAK TECHNICZNIE? Na co ja wysyłam te dane?

Musiałbym z poziomu javascripta pisać coś na localhost do określonego portu - chyba tak?

No jak wszystko będziesz miał na jednym komputerze to po lokal hoście. Ale ja bym się nie ograniczał i założył, że może zacząć używać tego ktoś z innego komputera i po prostu miał tam odpowiedni adres.

Czyli piszę sobie aplikacje np. w Javie która komunikuje się z DLL i otwiera port, ten powiedzmy 9888 na localhoście.

Tak,

Javascript kontaktuje się z http://127.0.0.1:9888/ i tak przebiega komunikacja?

Tak.

Tyle, że wtedy ta aplikacja w Javie musiałaby obsługiwać protokół HTTP - to jest problem, chociaż już nie taki duży.

No nie do końca musi obsługiwać HTTP ale będzie najłatwiej to tego z JS strzelić.

@cerrato - raczej w aplikacji Javy wykorzystam jakiś komponent żeby zrobić z niej mini-serwer www, żeby tych warstw nie było tak dużo. Plus oczywiście zabezpieczenie, że można się do tego dostać tylko z localhosta.

@S4t - żeby nie komplikować sprawy w samym JS-sie to zrobię jak napisałem wyżej - czyli komunikacja przez HTTP.

Zrobienie później z tego jakiegoś webserwisu, gdyby była taka potrzeba, to już będzie prosta sprawa. Jednak raczej będzie tylko jedno stanowisko do drukowania paragonów - mniejsza możliwośc pomyłki i wchodzenia sobie w drogę, bo to generalnei wykonuje się raz dziennie przed wysyłką zamówień hurtowo na wielu zamówieniach na raz.