Konfigurowanie i zarządzanie działaniem aplikacji okienkowych/usług Windows z poziomu aplikacji webowej

Witam.
Czy jest w ogóle jakakolwiek szansa na ogarnięcie takiego systemu? Potrzebuje zaktualizować pewien projekt do powiadomień i e-faktur. Na tę chwilę aplikacja jest okienkowa (WinForms + DevExpress). Składa się z aplikacji konfiguracyjnej oraz usługi Windows, która w tle za pomocą Quartz .NET wykonuje swoje zadanie w odpowiednim czasie.

Chciałbym teraz aspekt konfiguracyjny i licencyjny wyciągnąć do www. Klient loguje się na swoje konto i konfiguruje "usługę" w ten sam sposób jak to robiło się w oknie "lokalnie". Oczywiście, jak już część z was może się domyślać, dane do powiadomień i e-faktur pochodzą z bazy Comarch Optima klienta.

Myślałem, aby usługę w tle zamienić na okno w tray'u i dalej konfigurować działanie po stronie klienta, ale wtedy www nie ma kompletnie sensu, bo można to wyklikać w oknie. Dodatkowo, o ile dobrze pamiętam, to aplikacje w tray'u potrzebują być zalogowanym do systemu, a często program jest instalowany na serwerach gdzie ludzie rzadko się logują.

Największym problemem jest połączenie tego wszystkiego ze sobą. Aplikacja webowa byłaby jedna, klientów "końcowych" było by wiele. Po zalogowaniu do panelu zarządzalibyśmy tylko swoją "końcówką". Z rzeczy, które znam odpadają - dla API po stronie usługi/końcówki musiałbym robić przekierowanie na routerze na http, dla socketów to może być jakiś overkill, a dla obu rozwiązań i tak byłoby konieczne stałe IP. Jedyne rozwiązanie to końcówką łączyć do API w aplikacji webowej, ale...

1. Potrzebuje wyciągnąć listę operatorów, wydruków z bazy
2. Potrzebuje przygotować/sprawdzić zapytanie, które wyciąga dane do powiadomień
3. Końcówka musi sobie konfiguracje jakoś pobierać, bo wysłać nie mam jak
4. Najważniejsze to mieć możliwość skonfigurować połączenie do odpowiedniej instancji i bazy SQL, aby w ogóle móc te dane wyciągać

Mam wrażenie, że to mało realne, a przede wszystkim za duże ryzyko bezpieczeństwa

PS.
Wydaje mi się, że już pisałem w podobnej sprawie, ale nie potrafię tego wątku znaleźć.

Serwer odczytuje zapytanie. W swojej bazie ma dane klientów. Klient klika log i serwer tworzy nowy formularz do wypełnienia (serwer może odesłać mu to zgodnie z jego charakterystyką z bazy danych).
Ta aplikacja webowa to serwer.
Wydaje mi się to banalne do zrobienia po ogarnięciu specyfikacji danych z tego comach optima

Comarch Optima tutaj nie jest problemem, bo to najmniej ważne akurat. I jak przekazać teraz z serwera tą konfigurację do końcówki? Jak pobrać listę operatorów, zapytać o liste dokumentów? Zaznaczam, że aplikacja webowa to osobny twór, taka centrala do konfigurowania wszystkich końcówek. Aplikacja webowa nie leży w miejscu gdzie będzie końcówka.

PS.
Końcówka tutaj oznacza klienta, a klient to nie komputer w jednej firmie, tylko masa firm, która może być na terenie całej Polski.

Doszło do mnie, że jest jeszcze SignalR

Wszystko wskazuje na to, że nie jest możliwe to co chce uzyskać, albo to będzie tak niestabilny wytrych, że aż szkoda tracić czas.

SignalR
Komunikacja jest dwukierunkowa (bidirectional). Byłem w stanie wstrzyknąć hub do kontrolera i wysłać zapytanie do klienta, ale SendAsync() nie czeka na odpowiedź.

SSE - Server-Side Events
To by było fajne, ale niestety to działa tylko między frontem, a serwerem (API), nie mogę sobie niczego z zewnątrz połączyć.

Chyba nawet TCP się nie nadaje.

Zrobiłem małą ilustracje co chciałem uzyskać

Do komunikacji miedzy API i klientami możesz użyć protokołu HTTP w stylu long polling tzn. klient wysyła zapytanie do API, a API trzyma request po swojej stronie i zwraca odpowiedź dopiero kiedy zajdzie taka potrzeba (czyli na żądanie użytkownika) i wtedy klient na podstawie tej odpowiedzi wykonuje potrzebne operacje i wysyła nowe dane do API, a API może je przesłać do frontendu.

Albo druga opcja jak już wymieniłeś - TCP. Klient nasłuchuje żądań z API i wysyła dane do API na jego żądanie, a API zwraca do frontendu.

Schemat działania zawsze podobny tylko obsługa protokołu inna.

Wygląda jak gra nie warta świeczki. Najlepszym wyjściem będzie zrobić self-hosted/windows service i projekt WebAPI + Angular na maszynie klienta. Zainstalować, zrobić skrót na pulpit do localhost z aplikacją i jak ktoś będzie chciał mieć panel na zewnątrz to sobie będzie musiał zrobić domene, przekierowanie i inne tego typu głupoty.

AdamWox napisał(a):

Wygląda jak gra nie warta świeczki. Najlepszym wyjściem będzie zrobić self-hosted/windows service i projekt WebAPI + Angular na maszynie klienta. Zainstalować, zrobić skrót na pulpit do localhost z aplikacją i jak ktoś będzie chciał mieć panel na zewnątrz to sobie będzie musiał zrobić domene, przekierowanie i inne tego typu głupoty.

O to chodzi?

Nie, nie o to chodzi. Twoje rozwiązanie by "działało" u mnie jeśli ten serwer FTP byłby na maszynie klienta, czyli z diagramu wyżej klient1, klient2, klient3, a ja chce uniknąć jakiegokolwiek "serwerowania" po stronie klienta i robić przekierowania, aby się do niego dostać. To co ja chce uzyskać może zostać rozwiązane tylko serwerem TCP. Ja już widzę jak jakiś nod32, albo inne badziewie blokuje mi wyjście TCP. Kompletnie nie warto.

Nie wiem, na ile to będzie pasować do Twojego problemu, ale od siebie zaproponuję gotowca, który teoretycznie umożliwia sterowanie całym systemem z poziomu "aplikacji" przeglądarkowej.

https://github.com/andrzejlisek/WebApiServer
To działa w ten sposób, że ta aplikacja jest serwerem WebSocket, może być uruchomiona na komputerze, na którym pracuje aplikacja przeglądarkowa, ale równie dobrze może być na innym komputerze, byle przeglądarka może się z tym serwerem połączyć jako WebSocket.

Póki co, istnieje tylko jeden projekt, który z tego korzysta:
https://github.com/andrzejlisek/TextPaintWeb

Poprzez wysyłanie poleceń po WebSocket (zrobiłem gotową klasę JavaScript, która to robi) możesz wykonać następujące rzeczy:

1. Wykonać połączenie sieciowe z dowolnym adresem bez protokołu (przesyła się komunikaty jako ciągi bajtowe), to serwer robi to połączenie i pośredniczy między przeglądarką a właściwym serwerem. Właśnie w ten sposób możliwa jest implementacja klienta telnet w przeglądarce, co robi własnie TextpaintWeb. W parametrze podaje się wyrażenie regularne określające, jakie adresy połączeń są możliwe.
2. Wykonać dowolne polecenie systemowe z przekierowaniem strumieni wejścia i wyjścia. W parametrze podaje się wyrażenie regularne określające, jakie polecenia są możliwe.
3. Operować na plikach, czyli dostać listę plików z danego folderu, wczytać treść pliku, zapisać treść do pliku, usunąć plik. Dla zachowania bezpieczeństwa, w parametrach określa się, jakie katalogi mogą być obsługiwane.

Jeżeli to, co chcesz zrobić, da się zrobić w ramach trzech wyżej wymienionych funkcjonalności, to w swojej aplikacji webowej wykorzystasz skrypt JS z projektu, zrobisz połączenie, wysterujesz systemem jak potrzebujesz i tyle.

Tutaj dyskutowałem analogiczny problem i zaproponowany WebApiServer jest skutecznym jego ominięciem:
Kontakt przeglądarki web z systemem
Jakoś przede mną nikt tego nie zrobił lub ja o tym nie wiem.