Gelöst Performance WMS-Mobile local VS server

[baskete]

Hallo zusammen,

wir haben früher unseren WMS-mobile Server auf unserem Cloud-Server ausgeführt. Die Performance war super gut, nach einen Scan kam direkt der nächste zu Pickende Artikel ohne wirkliche verzögerung.

Da wir nun einen Workflow haben der bei Abschluss einer Pickliste (nur bei bestimmten Artikeln) ein Label erzeugt, müssen wir den WMS-mobile Server nun auf den Packtisch-PC ausführen, um den Druckbefehl ins lokale Netzwerk zu bekommen. Das Problem: Nach jedem Picken braucht es 1-2 gedenk-Sekunden bis der nächste Arikel auf dem mobile Device angezeigt wird. Es muss an der Performance vom Server liegen, das dieser einfach schneller die Daten aufbereitet als der normale Pack-Pc.

Gibt es eine Möglichkeit den WMS-Mobile Server in der Cloud auszuführen und trotzdem lokale Druckbefehle ausführen zu können?

 

[MaxWe]

Gibt es eine Möglichkeit den WMS-Mobile Server in der Cloud auszuführen und trotzdem lokale Druckbefehle ausführen zu können?

Moin,
theoretisch ja. Ich wüsste den Weg über eine VPN Verbindung vom Cloud Server in euer lokales Netz. Damit könnte der Cloud Server den freigegebenen Drucker im Netzwerk finden und nutzen.
Falls ihr mit Remote Desktop arbeitet, lassen sich darüber direkt lokale Drucker verwenden. Oder man könnte lokal einen Druckserver einrichten und dann über DynDns versuchen eine Verbindung vom Cloud-Server zu dem lokalen Druckserver einzurichten.
So oder so: Bei Windows habe ich die Erfahrung gemacht, dass die Druckertreiber auf dem Server und die lokalen identisch sein müssen. Ich habe hierzu die Druckertreiber direkt vom Hersteller geladen und auf beiden Geräten nochmal installiert.

Nach jedem Picken braucht es 1-2 gedenk-Sekunden bis der nächste Arikel auf dem mobile Device angezeigt wird.

Ich glaube das wird an dem Workflow selbst liegen. Dieser muss erst den Druckbefehl triggern, was kurz dauert und verzögert damit den Ablauf.

 

[MaxWe]

Ich glaube nicht. Wenn ich den Mobile-Server auf den Coudserver laufen lassen, geht es ultra schnell. Dieser müsste dann ja das selbe Problem haben!?

Da habt ihr aber auch noch keinen Workflow zum Drucken drin gehabt oder verstehe ich das falsch?

 

[baskete]

sorry Irgendetwas hat mit dem Kommentar nicht funktioniert

 

[baskete]

Da habt ihr aber auch noch keinen Workflow zum Drucken drin gehabt oder verstehe ich das falsch?

Doch, der Workflow ist dauerhat drinnen. Ich merke einen Unterschied jenachdem wo ich den Mobile Server ausführe.

Ich stelle mir das so vor:

Wenn der Mobile Server lokal läuft:

Handy/Taplet -> Pack-PC
Pack-PC -> Server (via odbc)
Server -> Pack-PC (via odbc)
Pack-PC -> Handy/Taplet

Wenn der Mobile Server in der Cloud läuft:

Handy/Taplet -> Server
Server -> Handy/Taplet

Ist das nicht ein Unterschied bezüglich Geschwindigkeit?

 

[MaxWe]

Wenn deine Wawi Datenbank ebenfalls auf dem Cloud-Server läuft ist das natürlich ein immenser Unterschied.
Deine zweite Darstellung müsste man dann quasi so aufstellen:
Handy/Tablet -> Server
Server -> local DB (via odbc)
local DB -> Server (via odbc)
Server -> Handy/Tablet

Dann bleibt nur die Anbindung des lokalen Druckers an den Cloudserver mittels einer ausgesuchten Methode. Umgesetzt habe ich so etwas auch noch nicht, da müsste man dann einfach google nochmal bemühen.
Solltet ihr von außen bereits auf euer Firmennetzwerk zugreifen können, könnte ich mir die Lösung mittels einem lokalen Druckserver gut vorstellen.

 

[baskete]

Da hast du Recht mit deiner zweiten Aufstellung:

Wobei man dies doch dann nochmal Unterscheiden müsste.


Wenn der Mobile Server in der Cloud läuft und kein Workflow angesprochen wird:

Handy/Taplet -> Server
Server -> Handy/Taplet


Wenn der Mobile Server in der Cloud läuft und ein Workflow angesprochen wird:

Handy/Tablet -> Server
Server -> local DB (via odbc)
local DB -> Server (via odbc)
Server -> Handy/Tablet

bzw. ist es hier nicht eher warscheinlich so das Handy/tablet-Anzeige und Drückauftrag parallel abläuft. Also so:

Handy/Tablet -> Server | Server -> Handy/Tablet
Server -> local DB (via odbc)
local DB -> Server (via odbc)


Mir geht es darum das es am Handy/tablet wieder schnell weitergeht. Wenn der Druckauftrag 1-2 sekunden verzögert wird ist das ja überhaupt kein Problem.

Ist es denn nicht generell immer besser wenn WMS-Mobile auf den DB-Server direkt läut. Das Thema Druckerweiterleitung z.B. über VPN ins lokale Netz müsste man dann halt gelöst bekommen.

 

[MaxWe]

Ist es denn nicht generell immer besser wenn WMS-Mobile auf den DB-Server direkt läut.

Von "besser" kann man nicht direkt sprechen, es ist eben performanter. So werden alle Datenbankanfragen lokal erledigt und lediglich das Ergebnis via Web-App angezeigt.
Sollte es immer noch stocken, selbst wenn der mobile Server auf dem Cloud-Server läuft, dann kannst du den Workflow noch zeitverzögert mit zbsp. 1 Minute Verzögerung anlegen. So wird dieser Asynchron ausgeführt => Im Hintergrund.
Damit dauert es natürlich länger bis der Druckauftrag getriggert wird.

Am Ende musst du dir also eigentlich nur noch überlegen wie du den lokalen Drucker dem Cloud-Server zur Verfügung stellen möchtest.
- VPN ins Firmennetz
- Druckserver im Firmennetz, der von außen erreichbar ist

- RemoteDesktop => Man könnte versuchen, ob eine im Hintergrund ausgeführte RDP Sitzung mit freigegebenen Drucker funktioniert. Also zbsp. morgens die Sitzung zum Server aufbauen und im Hintergrund einfach laufen lassen. Der Workflow muss dann mit dem geteilten Drucker arbeiten.

Sicherheitsrisiken bringen alle 3 Lösungen mit sich. Ich möchte aber behaupten, dass der Druckserver das kleinste Risiko wäre, da hier gezielt nur der Druckserver erreichbar gemacht wird.

 

[Stetto]

Ab Version 1.6 bekommt JTL- WMS Mobile eine richtige Druckerverwaltung. Damit wird es neue Möglichkeiten geben, bspw. Artikeletiketten statt über Workflows mit richtigen Druckfunktionen zu erstellen.
https://issues.jtl-software.de/issues/WAWI-27647

"Bis dahin führen viele Wege nach Rom".

Die Performance ist langsamer, da ihr durch den lokalen Server das Cloud- Hosting wie ein gewöhnliches SQL-Datenbankhosting betreibt. Es entsteht ein technisch bedingter Flaschenhals. Mit einem Performance-Problem hat das nichts zu tun und liegt einfach in der Sache selbst begründet.

Ihr könntet den Mobile Server wieder auf der Cloud starten und den Drucker so konfigurieren und verbinden, dass dieser vom Cloud-Gerät aus gefunden und angesprochen werden kann - Möglichkeiten gibt es da sicher, Experte auf dem Gebiet bin ich aber nicht.

 

[baskete]

Ab Version 1.6 bekommt JTL- WMS Mobile eine richtige Druckerverwaltung. Damit wird es neue Möglichkeiten geben, bspw. Artikeletiketten statt über Workflows mit richtigen Druckfunktionen zu erstellen.
https://issues.jtl-software.de/issues/WAWI-27647

"Bis dahin führen viele Wege nach Rom".

Die Performance ist langsamer, da ihr durch den lokalen Server das Cloud- Hosting wie ein gewöhnliches SQL-Datenbankhosting betreibt. Es entsteht ein technisch bedingter Flaschenhals. Mit einem Performance-Problem hat das nichts zu tun und liegt einfach in der Sache selbst begründet.

Ihr könntet den Mobile Server wieder auf der Cloud starten und den Drucker so konfigurieren und verbinden, dass dieser vom Cloud-Gerät aus gefunden und angesprochen werden kann - Möglichkeiten gibt es da sicher, Experte auf dem Gebiet bin ich aber nicht.

Hallo Stephan,
danke für deine Antwort.
Ich verstehe das so das diese neue Druckerverwaltung dann noch feinere Einstellungen (wann welches Etikett auf welchen Drucker gedruckt wird bzw. welches Device hat den Druckauftrag gesendet) unterscheiden kann.
Kann diese neue Druckerverwaltung dann aber auch genau die Sache mit dem Drucken über Fernzugriff. Also WMS-Mobile auf Cloud-Hosting ausführen und Druckaufträge weiterleiten an lokales Netzwerk im Lager?

 

[Stetto]

Das mit dem Cloud- Hosting wird in den selben Abhängigkeiten stehen. Bspw. ein VPN wird vermutlich nötig sein, um dem Mobile Server die Drucker bekannt zu machen.

Es können natürlich nur Drucker verwendet werden, die auch dem Server bekannt sind. Lösungen gibt es da sicherlich viele, aber wie ich schon schrieb, bin ich bei diesen Netzwerk-Tricks kein Experte. Da hilft sicher Google oder das erfahrene Netzwerk unserer JTL- Servicepartner.