Drucken / Druckserver

[OnDemand]

Hallo zusammen,

haben eine interessante Anforderung. Ich versuche es mal kurz zu erklären, vielleicht hat jemand eine bessere Idee.

Wir haben eine Vaadin App welche online auf einem Server läuft. Jeder user hat seine eigene App über eine eigene Domain. Nun soll die App im Hintergrund automatisiert drucken, auch wenn der User nicht eingelogged ist oder den Browser offen hat. Meine Idee ist daher:

Wir bauen eine Printapp, welche sich der User lokal installieren muss. Zb auf dem Rechner, Raspberry oder wo auch immer. Dort muss er seinen Drucker angeben auf dem gedruckt werden soll. Wenn die "CloudApp" nun was drucken muss, sendet sie das an die lokale "DruckApp". Entweder über einen Messagebroker auf den die "DruckApp" lauscht oder die "DruckApp" holt sich über einen Api Call an die "CloudApp" minütlich ihre Druckaufträge.

Hat jemand eine andere Idee, Erfahrungen, sieht Vorteile/Nachteile? Edit: noch eine Frage; hab mit Drucken noch nie etwas zu tun gehabt. Ich denke mal es wird auf Reports hinauslaufen?! Gibts ein Framework welches ich mir unbedingt ansehen muss? Jasper?

 

[Robert Zenz]

Jeder user hat seine eigene App über eine eigene Domain.

Also ihr verwaltet die Server, und stellt jedem Kunden eine eigene Adresse zur Verfuegung? Wo lebt der Drucker, im Netzwerk vom Kunden?

 

[OnDemand]

Ganz genau, die Server liegen bei uns im Rechenzentrum. Die Drucker ist eine gute Frage. Ich weiss, dass es welche gibt die die Drucker im Netzwerk haben (in ihrem eigenen). Es gibt aber auch welche die haben sie per USB am Rechner. Wir haben keinen Zugriff auf die Drucker

 

[Robert Zenz]

Dann bleibt dir nur noch ein eigener Druckdienst, wie du schon sagtest, welcher sich an deiner Vaadin Applikation/dem Server anmeldet und nach Druckauftraegen fragt. "Pull" quasi.

Aktiv kannst du den Dienst nicht ansprechen ("Push") weil du dann ein Loch in das Netzwerk von deinem Kunden schieszen muesstest, also bleibt nur dass sich der Dienst meldet. Der Kunde kann sich den Dienst dann auf einem beliebigen Rechner starten, waehlt dann dort den Drucker (mit eventuellen Druckeinstellungen) aus, und dieser fragt dann regelmaeszig (alle 5 Minuten?) den Server ob es Auftraege gibt welche ausgedruckt werden muessen. Am besten merkt sich der Server wenn Auftraege abgeholt wurden, und der Dienst gibt Bescheid was das Ergebnis war. So dass du dann dem Kunden eine Uebersicht ueber die Druckauftraege anzeigen kannst (und dieser dann auch die Moeglichkeit hat Auftraege erneut auszudrucken wenn es Probleme gab):

AuftragX     12.04.2021 03:00   Gedruckt auf BlaBlaMaschine
AuftragX22   13.04.2021 13:00   Gedruckt auf BlaBlaMaschine
AuftragYY    14.04.2021 14:14   Fehler auf BlablaMaschine: Idiot hat Drucker ausgeschalten
AuftragZZZZ  15.04.2021 16:27   Abgeholt fuer Druck auf BlaBlaMaschine
AuftragNeu   15.04.2021 17:30   Offen

 

[OnDemand]

Yes danke! Was hälst du von einem Messagebroker? Wenn die CloudApp eine Message senden an den Broker "Drucker xyz" (Kann man da auch Dokumente hinsenden?) und der Printservice lautscht auf den Messagebroker?

Dazu muss ich aber sagen, dass der Messagebroker auf der selben VM laufen müsste wie die CloudApp. Könnte vielleicht sein, dass die VM dann mehr Leistung brauchen um den Broker auch noch zu versorgen. Da wäre die API Lösung eine einfachere Alternative, zumal unsere CloudApp sowieso eine API bekommen wird, da wir eine AndroidApp bauen wollen, welche dann die Daten von der Cloudapp braucht

 

[Robert Zenz]

Was hälst du von einem Messagebroker? Wenn die CloudApp eine Message senden an den Broker "Drucker xyz" (Kann man da auch Dokumente hinsenden?) und der Printservice lautscht auf den Messagebroker?

Sehe ich nicht wozu, ist doch nur mehr Komplexitaet. Der Kunde wird doch sicher nur hoechstens einen Auftrag die Stunde brauchen, dass kannst du doch ueber deinen ganz normalen Server und API abhandeln, da braucht es doch keinen eigenen Verwalter dafuer. Auch sollte der Dienst nur einmal beim Kunden laufen, wenn der einen zweiten am laufen hat, kommen die halt eventuell doppelt raus. Oder du baust dir ganz einfache Sperren fuer die Auftraege damit der Kunde mehrere Dienste gleichzeitig haben kann.

Wenn ein Dienst die Liste an Druckauftraegen holst, uebergibt dieser einen eindeutigen Namen. Diese Liste welche du ihm gerade gegeben hast, markierst du mit diesem Namen und Zeitstempel.

AuftragX     12.04.2021 03:00   Gedruckt auf BlaBlaMaschine
AuftragX22   13.04.2021 13:00   Gedruckt auf BlaBlaMaschine
AuftragYY    14.04.2021 14:14   Fehler auf BlablaMaschine: Idiot hat Drucker ausgeschalten
AuftragZZZZ  15.04.2021 16:27   Vorbeitet fuer Druck auf BlaBlaMaschine
AuftragNeu   15.04.2021 17:30   Vorbeitet fuer Druck auf BlaBlaMaschine

Wenn jetzt der zweite Dienst ankommt, bekommt er nur noch nicht gesperrte Auftraege, und sperrt diese wiederum. Wenn Dienst 1 sich dann die "richtigen" Dokumente zum drucken holt, setzt du wieder den Status entsprechend. Wenn die Dokumente laenger als X nicht geholt werden, werden sie weider freigegeben und der naechste Dienst der ankommt kann sie verarbeiten.

Also quasi:

public enum Auftragsstatus {
    OFFEN,
    VORBEREITET,
    IM_DRUCK,
    GEDRUCKT_ERFOLGREICH,
    FEHLER
}

public List<Auftrag> getOffeneAuftraege(String dienstName) {
    List<Auftrag> offeneAuftraege = backend.getOffeneAuftraege():
    
    for (Auftrag offenerAuftrag : offeneAuftraege) {
        offenerAuftrag.setVorbereitetFuer(dienstname);
        save(offenderAuftrag);
    }
    
    return offeneAuftraege;
}

public Dokument getDokument(String dienstName, String auftragsNummer) {
    Auftrag auftrag = backend.getAuftrag(auftragsNummer);
    
    auftrag.setImDruckAuf(dienstName);
    save(auftrag);
    
    return backend.getDokument(auftrag);
}

public void onAllePaarMinuten() {
    List<Auftrag> vorbereiteteAuftraege = backend.getVorbereiteteAuftraege():
    
    for (Auftrag vorbereiteterAuftrag : vorbereiteteAuftraege) {
        if (vorbereiterAuftrag.istLaengerAlsXInVorbereitung()) {
            vorbereiterAuftrag.setOffen();
            save(vorbereiterAuftrag);
        }
    }
}

 

[OnDemand]

Vielen Dank, hast Recht - ein Broker wäre nur noch komplizierter.

Überlege grad wie ich den Printservice bauen könnte. Eine Swinganwendung kommt mir da in den Sinn, mit wenigen Funktionen wie "Wähle Standarddrucker" als GUI. Die Einstellungen würde ich in einer .config Datei speichern im User-Verzeichnis des Gerätes zb.

Mit dem ganzen Druckthema muss ich mich erstmal beschäftigen, hab noch nie einen Drucker direkt angesprochen.

 

[Robert Zenz]

Überlege grad wie ich den Printservice bauen könnte. Eine Swinganwendung kommt mir da in den Sinn, mit wenigen Funktionen wie "Wähle Standarddrucker" als GUI. Die Einstellungen würde ich in einer .config Datei speichern im User-Verzeichnis des Gerätes zb.

Ja, waere auch mein Gedanke, hat als Loesung am wenigsten Reibung.

Mit dem ganzen Druckthema muss ich mich erstmal beschäftigen, hab noch nie einen Drucker direkt angesprochen.

Drucken sollte relativ simpel sein, was auch immer vom Server geholt wird sollte 1:1 in den Drucker schiebbar sein. Mach' dann dort lokal keine Verarbietung mehr, nur fertige Dokumente, am besten PDFs. Die fallen fuer gewoehnlich fix und fertig aus der Berichtsloesung heraus.

Was sich da an Loesungen anbietet muss dir aber jemand anderes sagen, ich hatte mit Berichten immer nur in Verbindung mit dem JVx Framework zutun, und da hatten wir unserere eigene (Microsoft Office und PDF basierende) Loesung.

 

[Robert Zenz]

Was dir noch passieren kann, ist dass ein Kunde sagt "Ich will die Auftraege auf diesem Drucker drucken, auszer wenn der nicht geht, dann auf dem, und wenn das auch nicht geht, dann auf dieser anderen Maschine.", das ist zwar mehr Logik, aber auch machbar. Aber das wuerde ich erst umsetzen wenn wirklich ein Kunde damit ankommt.

 

[sascha-sphw]

Sehe ich nicht wozu, ist doch nur mehr Komplexitaet.

Wenn ein Dienst die Liste an Druckauftraegen holst, uebergibt dieser einen eindeutigen Namen. Diese Liste welche du ihm gerade gegeben hast, markierst du mit diesem Namen und Zeitstempel.

Wenn jetzt der zweite Dienst ankommt, bekommt er nur noch nicht gesperrte Auftraege, und sperrt diese wiederum. Wenn Dienst 1 sich dann die "richtigen" Dokumente zum drucken holt, setzt du wieder den Status entsprechend. Wenn die Dokumente laenger als X nicht geholt werden, werden sie weider freigegeben und der naechste Dienst der ankommt kann sie verarbeiten.

Wo genau siehst Du zu Deinem Skizzierten Vorgehen weniger Komplexität zu einem Messagebroker/Queue?

Vielen Dank, hast Recht - ein Broker wäre nur noch komplizierter.

Vielleicht verstehe ich es gerade nicht, aber wo genau seht Ihr diese Komplexität in einem Service, dem man einfach nur eine Nachricht schreibt oder abholt? Wenn man eh schon in der Cloud ist (ggf. AWS) startet man einfach einen SQS und SNS und gut ist. Da fällt nicht mal großartig administrativer Aufwand an.

Hier schicke ich die Aufträge im "fire and forget" Modus und warte auf die Antwort.

 

[Robert Zenz]

Wo genau siehst Du zu Deinem Skizzierten Vorgehen weniger Komplexität zu einem Messagebroker/Queue?

Im Moment haben die alles in einem Server, so wie ich das verstanden habe. An dem Server muss man sich auch anmelden koennen. Wenn du jetzt noch irgendeinen Service dazwischen setzt, muss dieser ebenfalls die Anmeldeschicht koennen, es muss ebenfalls in die Datenbank greifen (mit den gleichen Objekten wie der Haupt-Server), und es gibt keine nennenswerte Last die einen eigenen Server oder Dienst rechtfertigen wuerde. Also man muss Ablaeufe duplizieren, gewinnt aber nichts dadurch. Also, angenommen dass der Verwalter in einem eigenen Dienst laeuft, ist doch komplett unnoetig. Dann hast du die Server-Logik zerlegt in irgendwelche Module, und musst dich dann um zwei Dienste kuemmern, die direkt nebeneinander am gleichen Blech laufen.

Zwecks reinziehen einer fertigen Bibliothek, sehe ich jetzt nicht die Komplexitaet welche es rechtfertigen wuerde sich solche, teilweise sehr groszen und und fuer komplett andere Szenarien ausgelegten, Konstrukte mit ins Projekt zu klatschen. Vielleicht sehe ich das aber auch nur zu blauaeugig, aber die Server-Seite fuer diese Abfragen ist schnell implementiert mit Bordmitteln (vermutlich).

Ich sehe hier jetzt keinen Gewinn entweder einen eigenen Dienst dafuer aufzumachen, oder sich eine komplexe Bibliothek einzutreten.

 

[OnDemand]

Jupp, ich bin schneller einen API endpoint einzubauen im die Druckaufträge auszugeben, als einen Broker zu installieren, konfigurieren und den Druckservice zu bauen der dann mit dem Broker arbeitet usw.
Der Messagebroker wäre nur wieder ein Service mehr der ausfallen könnte

 

[OnDemand]

Mir kam grad noch Cloudprint in den Sinn. Wenn auf dem Raspberry eine Anbindung an Google Cloudprint hängt, könnt man aus der Serverapp nicht die zu druckenden PDF an die Cloudmail senden sodass der PI dann druckt? Was haltet ihr davon?

Edit: doofe idee. so kann ich nicht wählen wo gedruckt wird.
Die Printapp könnte Etiketten zum drucken bekommen oder auch A4PDF welche auf verschiedenen Geräten gedruckt werden sollen

 

[OnDemand]

Hab doch noch etwas, das gegen das Polling spricht, aber pro Messagebroker wäre. Wenn ein User eingelogged ist und einen Lieferschein drucken möchte, muss er warten bis der Raspberry den Auftrag geholt hat. Alternativ könnte man über den Browser > Druckerpopup drucken.

Wenn man nun aber sagt, wir drucken grundsätzlich alles über den Raspberry, dann wäre die Lösung mit dem Messagebroker die bessere. Wie ich sehe kann man das auch direkt in die SpringBoot App auf dem Server embedden? Man müsste also ActiveMQ zb nicht noch separat laufen lassen