Aanpak: Native of web?

[robbietjuh]

Ik start dit topic omdat ik met een groot project bezig ga en alles toch even op een rijtje wil hebben. Ik zit over een paar dingen te twijfelen wat betreft best practices en dan is wat feedback of input van buitenaf wel gewenst.

Mijn ouders hebben een grote online winkel waar lego verkocht wordt (per blokje). Dit alles moet administratief vastgelegd worden in een grote database. Ze maken gebruik van dozen, die gemarkeerd worden met een nummer, waar vervolgens zakjes in komen te liggen die wederom gemarkeerd zijn met een nummer. Elk zakje is gevuld met een bepaalde lego blokje.

Een doos en een zakje moet je zien als een model in de database. Door op de doos en het zakje een labeltje te plakken met het nummer dat correspondeert met het object in de database kunnen orders gepikt worden en kan de voorraad bijgewerkt worden. Dat orders pikken gebeurd met behulp van een iPad.

Het concept betreft het administratief bijhouden van de voorraad ligt er dus - alleen nu moet de implementatie nog van de grond komen. Naast het bijhouden van de voorraad willen we ook de orders en andere zaken bijhouden in hetzelfde systeem, maar dat is een gedeelte waar ik mij later op wil richten. Ik zit nu eerst te denken bij de basics: is het verstandig dit native te ontwerpen, of toch als een web app.

Ik zie een aantal kansen, voordelen en nadelen. Ten eerste lijkt het me verstandig nog even toe te voegen dat we gebruik maken van een Brother label-printer (USB) zodat de labels voor de dozen en zakjes automatisch uitgeprint kunnen worden. Op dit moment loopt er al een basic invoersysteem, waarbij er op de client computer een simpel programma draait dat HTTP requests opvangt en parsed om ze door te sturen naar de label printer. Dat is op zich een werkende methode maar voelt niet heel stable aan, vooral omdat je bepaalde flags aan Chrome dient door te geven om via het invoersysteem, dat op een interne website staat, toestemming te geven requests naar localhost te sturen om labels uit te printen. Het voelt allemaal wat hacky aan en dat is het eigenlijk ook.

Het alternatief is dus om dan native te gaan: een applicatie ontwerpen in C# die communiceert met een API op de server om de database te manipuleren en data weer te geven. Een voordeel hiervan is natuurlijk dat het native is, geen hacks en wellicht logischer dan het draaien van een webbrowser en vage programmaatjes om de label printer werkend te krijgen. Door native te gaan kan je bepaalde onderdelen van het systeem, zoals dus bijvoorbeeld een label printer, simpelweg veel makkelijker aanspreken. Een nadeel is echter wel dat het een stuk minder flexibel is. Updates zijn lastiger uit te rollen, bijvoorbeeld. Alle client computers draaien wel in Active Directory waardoor de applicatie bij te werken is doormiddel van een Group Policy, maar een web app even refreshen is natuurlijk stukken simpeler. Daarnaast vind ik het persoonlijk fijner een interface in HTML e.d. te schrijven dan deze te moeten ontwerpen in (het toch wel wat striktere en wellicht beperktere) WinForms. Laat ik daar wel bij zeggen dat het voor mij alweer zo'n 5 jaar terug is dat ik op die manier een uitgebreide UI heb ontworpen, dus wellicht dat het allemaal wat flexibeler is nu.

Mijn laatste concern is dan nog of het slim is om ons te binden aan 1 platform. Het is een enorm project en als er eenmaal gekozen is om het native of web-based te doen, dan is dat bepaald en is er weinig meer aan te veranderen. Mochten we in de toekomst ervoor kiezen over te stappen naar Linux of OS X, dan zal de applicatie volledig moeten worden gepord als deze niet web-based geschreven is. Als we kiezen voor een web-based oplossing, hoeft enkel het printgedeelte native te worden geschreven. Dat is een stuk minder om te porten, mocht dat ooit nodig zijn.

Bij beide oplossingen zijn zowel voordelen als nadelen te noemen en ik heb dus graag jullie visie op dit probleem. Op het moment draaien alle client computers op Windows 8.1 en zitten ze in een domein, mocht dat een factor zijn.

[Kalentum]

Dus ik begrijp dat de printer een bepalende factor is. Wat je zou kunnen onderzoeken is of het haalbaar is om een client-server model te ontwikkelen waarbij de server een API heeft waar de clients tegen aan praten. En een webapplicatie zou dan een client kunnen zijn, maar ook een desktopapplicatie of een iPad applicatie.

Het aansturen van de labelprinter doe je dan vanaf de applicatieserver. Die kan dan Windows zijn of Linux, als die printer maar aangestuurd kan worden. Het printen van de labels gebeurt dan vanuit de server: daar hangt die printer aan of eventueel gebruik je een Raspberry PI om de printer aan te hangen.

[KoudeAardbei]

Wij hebben het hier als volgt opgelost:

Barcode scannen in een textfield, welke via ajax wordt verwerkt. Deze genereert een MySQL veld welke kan worden opgehaald door een HTTP GET request. Een programma poll't elke seconde of er data beschikbaar is op die webpagina, en zoja; print het uit. Klinkt stukken minder hacky dan wat jij daar hebt draaien volgens mij.

Ik zou overigens echt webbased gaan kijken, ik zou niet afhankelijk willen zijn van native applicaties in deze tijd. Het polling systeem zul je wellicht wel in C# moeten gaan schrijven.

[Cor453]

Ik denk persoonlijk dat de implementatie niet echt heel vast ligt, tot het moment dat je dus bij de printer komt (wat rutgerw ook al zegt). Waarom zou je er dan niet voor kiezen een headless applicatie te schrijven voor de afhandeling van die printjes?

TelefoniQ zegt dat zijn oplossing een goede is (and I agree) maar waarom zou je niet werken met bijvoorbeeld een Node.js server die dmv Faye (http://faye.jcoglan.com/) naar die headless client pushen dat ie iets moet printen? Zo zou ik dat doen denk ik. Heb je alleen requests als het moet (dus niet elke seconde, wat misschien niet zo erg is, maar alle beetjes helpen).

[KoudeAardbei]

Cor453 schreef op woensdag 02 juli 2014 @ 14:12:
Ik denk persoonlijk dat de implementatie niet echt heel vast ligt, tot het moment dat je dus bij de printer komt (wat rutgerw ook al zegt). Waarom zou je er dan niet voor kiezen een headless applicatie te schrijven voor de afhandeling van die printjes?

TelefoniQ zegt dat zijn oplossing een goede is (and I agree) maar waarom zou je niet werken met bijvoorbeeld een Node.js server die dmv Faye (http://faye.jcoglan.com/) naar die headless client pushen dat ie iets moet printen? Zo zou ik dat doen denk ik. Heb je alleen requests als het moet (dus niet elke seconde, wat misschien niet zo erg is, maar alle beetjes helpen).

Hij pakt ook meer queries als het nodig is, hij maakt zeg maar een printopdracht aan met wat er in de database staat. Zijn een paar velden:

ID
DATETIME >> Datum aanmaak
STATUS >> geprint of niet?
CONTENT >> wat moet er geprint worden, een locatiecode, verzendparcel
PRINTER >> Dymo 4XL, 450 Turbo etc etc.
QTY >> Hoeveel keer? Honderden requests achter elkaar sturen is niet zo'n best idee.

Wat betreft NODE JS, ik heb er echt 0 verstand van dus kan ik geen advies over geven

[Siebsel]

Ik zou toch echt voor een webapp gaan. De voordelen zijn enorm t.o.v. een native app en de nadelen die er zijn, zijn in dit geval niet echt van toepassing. Het enige "probleem" is dus het printen van labels. Hierbij quote ik mezelf even vanuit dit topic:

Siebsel schreef op woensdag 25 juni 2014 @ 17:14:
Hoe ik zoiets onlangs afgevangen heb:

Vanuit onze webapplicatie wou ik on-the-fly labels kunnen printen via onze zelfgeschreven software. Probleem: die web-app draait extern, dus directe communicatie wordt al heel lastig (zelfde probleem als jij hebt).

Nu heb ik de software, welke verantwoordelijk is voor het afdrukken van de verschillende soorten labels, voorzien van een websocket-server (via deze package). In de webapp check ik nu of er een websocket connectie opgezet kan worden met ws://localhost:8801 en zo ja, activeer ik specifieke linkjes/functies in de webapp die vervolgens heel simpel websocket "messages" stuurt naar de label software. Deze kan die commandos weer interpreteren en vervolgens verwerken. Uiteraard heb je de volledige mogelijkheden van websockets ter beschikking en indien gewenst zou je zelfs nog met certificaten etc. kunnen werken.

Je gebruikt hierbij geen "hacks" maar gewoon "standaard" dingen. Crossbrowser compatible (ook iPad) en je kan direct vanuit de browser een label afdrukken. Geen "ingewikkeld" gedoe met aparte servers, polling, Chrome flags, etc. De genoemde library kun je zo in je reeds bestaande label-print app (die je geschreven hebt in C# als ik het goed begrepen heb?) integreren. Uiteraard hoeft de websocketserver niet op localhost te draaien, maar dit kan ook ws://192.168.x.x:8801 bijvoorbeeld zijn.

[ Voor 8% gewijzigd door Siebsel op 02-07-2014 14:50 ]

[robbietjuh]

De printer is in deze inderdaad wel de bepalende factor. Het is een onderdeel dat bijna een centrale rol in het geheel speelt. Het hele invoersysteem staat of valt op basis van de label printer. Het probleem is dat je dat niet even via Javascript APIs kan aansturen, en dus op een native oplossing zult moeten bouwen. De vraag is dan dus of het slim is om de front-end dan maar meteen compleet native te maken of web-based te maken met een klein native component wat op de achtergrond meedraait.

Het printen van de labels vanuit de server gaat niet lukken (als in, de job compleet voorbereiden en processen op de server). De printers hangen aan de workstations zelf en niet aan een centrale server. Het is natuurlijk wel mogelijk om die printers dan te share met bijvoorbeeld SMB, vervolgens op een centrale server te mounten en dan server-based te printen maar dat klinkt me niet echt geweldig in de oren, laat staan de problemen die je wellicht kan creëren als een bepaald workstation offline gaat. Het afhandelen van de printjes lijkt mij dus liever lokaal te gebeuren.

De huidige oplossing is hacky omdat het niet werkt zonder de benodigde flags toe te voegen aan Chrome. Het lijkt in elk geval alsof iedereen hier aanraad de front-end als webapp aan te bieden, dus daar ben ik dan over uit. Het print gedeelte is echter nog wel even de vraag. Ik heb geen zin weer met cmd flags te gaan werken, dus iets in de richting van wat er nu draait maar beter, is het uitgangspunt.

De optie die mij het meest aanspreekt is dan toch eigenlijk die van Cor/Siebsel (zelfde principe).

De andere optie is om te pollen, maar dat lijkt me persoonlijk een wat mindere oplossing.

Om alles een beetje netjes, onderhoudbaar en compatible te houden lijkt het me persoonlijk het beste om een Windows Service te schrijven in C# dat bij het starten een verbinding legt met de server zoals Cor/Siebsel aangeeft met Faye in Node.js of met een websocket. Op die manier kan de app makkelijk opdrachten pushen naar de clients. Die Service kan vervolgens gepusht worden naar de clients met behulp van een Group Policy regel. Any thoughts?

[ Voor 13% gewijzigd door robbietjuh op 02-07-2014 14:58 ]

[royduin]

Is het niet een idee om over te stappen op een Dymo label printer? Die kunnen aangestuurd worden via Javascript:

HTML:

<script type="text/javascript" src="http://labelwriter.com/software/dls/sdk/js/DYMO.Label.Framework.latest.js"></script>
<script>
var template = 'De label XML hier';
var label = dymo.label.framework.openLabelXml(template);
label.setObjectText("PRIJS", '10,00');
label.setObjectText("STREEPJESCODE", '123456790');
label.print("DYMO LabelWriter 400 Turbo");
</script>

In de variable template de XML stoppen die gemaakt kan worden met de Dymo software.

[robbietjuh]

Ik denk niet dat ze daar hier heel blij van zullen worden, gezien de grote hoeveelheid voorraad aan papier voor die Brother label printers Voor de rest natuurlijk een super goed idee, maar helaas niet toepasbaar hier ben ik bang.

[farlane]

robbietjuh schreef op woensdag 02 juli 2014 @ 14:56:
De andere optie is om te pollen, maar dat lijkt me persoonlijk een wat mindere oplossing.

Waarom? Pollen is een zeer eenvoudige constructie en zolang je het niet vanaf honderden workstations doet lijkt me performance geen issue.

[robbietjuh]

Omdat ik dan met een buffer zal moeten werken waar alle opdrachten in komen te staan totdat ze gepolled worden. Daarnaast heb ik de keuze om elke seconde een server te gaan zitten pollen, of te wachten tot er gepusht wordt. Dan is voor mij de keuze eigenlijk best simpel.

Pollen is opzich geen probleem maar in vergelijking met push, zou ik voor push gaan.

[farlane]

robbietjuh schreef op woensdag 02 juli 2014 @ 15:14:
Omdat ik dan met een buffer zal moeten werken waar alle opdrachten in komen te staan totdat ze gepolled worden. Daarnaast heb ik de keuze om elke seconde een server te gaan zitten pollen, of te wachten tot er gepusht wordt. Dan is voor mij de keuze eigenlijk best simpel.

Pollen is opzich geen probleem maar in vergelijking met push, zou ik voor push gaan.

En als de data die je pushed niet opgevangen wordt? Je hebt daar net zo goed een buffer nodig.

[royduin]

robbietjuh schreef op woensdag 02 juli 2014 @ 15:12:
Ik denk niet dat ze daar hier heel blij van zullen worden, gezien de grote hoeveelheid voorraad aan papier voor die Brother label printers Voor de rest natuurlijk een super goed idee, maar helaas niet toepasbaar hier ben ik bang.

Even gekeken voor Brother maar het lijkt dat men dit ook ondersteund, ik kwam bijvoorbeeld dit tegen: http://forum.winbatch.com/index.php?topic=724.0 of werken met een Java applet vanaf de webapplicatie?

[robbietjuh]

royduin schreef op woensdag 02 juli 2014 @ 15:24:
[...]


Even gekeken voor Brother maar het lijkt dat men dit ook ondersteund, ik kwam bijvoorbeeld dit tegen: http://forum.winbatch.com/index.php?topic=724.0 of werken met een Java applet vanaf de webapplicatie?

Helaas zit je met een Javascript oplossing icm b-pac vast aan IE. Als je later wel van platform of browser wisselt, dan zul je dus weer een enorme hoeveelheid code moeten herschrijven. Een zo light-weight mogelijke oplossing die de opdrachten domweg doorgeeft naar b-pac is dan een stuk makkelijker te porten.

[-Klimaks-]

Wij sturen hier alle labelprinters aan met Bartender, is aan te sturen met zo ongeveer alles wat je kan bedenken (sockets, emails, files, native sdk's, ...).
Op die manier kan je het printen helemaal loskoppelen van je applicatie.
supportteam is trouwens

[kwaakvaak_v2]

ik zou het webbased doen, en een messaging systeem introduceren in je server stack ala http://activemq.apache.org/

En dan een kleine native applicatie op diezelfde server die gewoon een listener heeft op je message queue en op die manier de messages vanzelf via een push krijgt.

[HMS]

kwaakvaak_v2 schreef op woensdag 02 juli 2014 @ 16:09:
ik zou het webbased doen, en een messaging systeem introduceren in je server stack ala http://activemq.apache.org/

En dan een kleine native applicatie op diezelfde server die gewoon een listener heeft op je message queue en op die manier de messages vanzelf via een push krijgt.

Dit zou ook mijn suggestie zijn. Ben wel meer gecharmeerd van RabbitMQ dan ActiveMQ, maar dat is een detail.

[leuk_he]

robbietjuh schreef op woensdag 02 juli 2014 @ 13:12:
Een nadeel is echter wel dat het een stuk minder flexibel is. Updates zijn lastiger uit te rollen, bijvoorbeeld. Alle client computers draaien wel in Active Directory waardoor de applicatie bij te werken is doormiddel van een Group Policy, maar een web app even refreshen is natuurlijk stukken simpeler.

Nou, wepp apps die langer leven ( wat niet ongebruikelijk is voor bedrijfsapplicaties) hebben een soortgelijk probleem. Http is immers niet een stilstaande omgeving. Over een paar jaar is chrome nieuwer blitzer, en veiliger. Dan wordt je opeens gedwongen door je browser een server app te updaten, terwijl jij je dan met heel andere dingen bezig houdt. Native heeft dat probleem minder, omdat je die omgeving zelf beter in de hand hebt.

Waarom denk je dat internet explorer 6 nog steeds een klein aandeel heeft? Juist, omdat er een paar bedrijfsapplicaties zijn die niet / te duur geupdate kunnen worden omdat er hacks gebruikt zijn.

Zolang je applicatie vol in onderhoud is is dit geen issue, als die stabiel is en jaren zonder teveel onderhoud moet draaien heeft native ook zekere voordelen.

[Siebsel]

leuk_he schreef op woensdag 02 juli 2014 @ 16:51:
[...]


Nou, wepp apps die langer leven ( wat niet ongebruikelijk is voor bedrijfsapplicaties) hebben een soortgelijk probleem. Http is immers niet een stilstaande omgeving. Over een paar jaar is chrome nieuwer blitzer, en veiliger. Dan wordt je opeens gedwongen door je browser een server app te updaten, terwijl jij je dan met heel andere dingen bezig houdt. Native heeft dat probleem minder, omdat je die omgeving zelf beter in de hand hebt.

Waarom denk je dat internet explorer 6 nog steeds een klein aandeel heeft? Juist, omdat er een paar bedrijfsapplicaties zijn die niet / te duur geupdate kunnen worden omdat er hacks gebruikt zijn.

Zolang je applicatie vol in onderhoud is is dit geen issue, als die stabiel is en jaren zonder teveel onderhoud moet draaien heeft native ook zekere voordelen.

Dit geldt natuurlijk ook voor native apps. Als jij een of andere specifieke Windows 7 functie gebruikt werkt je app niet meer op Windows 8. Of je maakt nu iets wat goed werkt onder Windows 8, maar je gaat naar Linux migreren. Of in Windows 9 zit een security verandering waardoor je app niet meer werkt. Of... you get my point. Élke app heeft onderhoud nodig, native of web maakt geen verschil. Alle omgevingen veranderen. Waarom zou je een native omgeving beter onder controle hebben dan een browser?

[ Voor 10% gewijzigd door Siebsel op 02-07-2014 17:15 ]

[adis]

leuk_he schreef op woensdag 02 juli 2014 @ 16:51:
[...]


Nou, wepp apps die langer leven ( wat niet ongebruikelijk is voor bedrijfsapplicaties) hebben een soortgelijk probleem. Http is immers niet een stilstaande omgeving. Over een paar jaar is chrome nieuwer blitzer, en veiliger. Dan wordt je opeens gedwongen door je browser een server app te updaten, terwijl jij je dan met heel andere dingen bezig houdt. Native heeft dat probleem minder, omdat je die omgeving zelf beter in de hand hebt.

Waarom denk je dat internet explorer 6 nog steeds een klein aandeel heeft? Juist, omdat er een paar bedrijfsapplicaties zijn die niet / te duur geupdate kunnen worden omdat er hacks gebruikt zijn.

Zolang je applicatie vol in onderhoud is is dit geen issue, als die stabiel is en jaren zonder teveel onderhoud moet draaien heeft native ook zekere voordelen.

Nou, http verandert echt niet zo snel, wij gebruiken nog steeds http 1.1, en die stamt toch echt nog (ruim) uit de gulden tijdperk: http://www.w3.org/Protocols/rfc2616/rfc2616.html

Het klopt wel dat men druk bezig met de opvolger van HTTP 1.1, dat moet HTTP 2.0 zijn. Sommige zeggen zelfs om 2.0 over te slaan en meteen door te gaan op 3.0. Echter, een van de een goals (let op: hoeft niet gehaald te worden!) is om backwards compatible te zijn met HTTP 1.1. Zie Wikipedia

IE6 heeft nog steeds een aandeel omdat met in die tijd de fout maakte om te ontwikkelen, testen en op te leveren in IE6. Terwijl IE6 de HTTP protocol aan hun laars lapt!

Jij moet (advies) gewoon een REST API aanhouden en testen vanuit cUrl of met een Chrome Extensie (bijvoorbeeld Postmen).

Ik ben voor Web Apps mocht dat niet duidelijk zijn!

[adis]

Siebsel schreef op woensdag 02 juli 2014 @ 17:12:
[...]


Dit geldt natuurlijk ook voor native apps. Als jij een of andere specifieke Windows 7 functie gebruikt werkt je app niet meer op Windows 8. Of je maakt nu iets wat goed werkt onder Windows 8, maar je gaat naar Linux migreren. Of in Windows 9 zit een security verandering waardoor je app niet meer werkt. Of... you get my point. Élke app heeft onderhoud nodig, native of web maakt geen verschil. Alle omgevingen veranderen. Waarom zou je een native omgeving beter onder controle hebben dan een browser?

Inderdaad, helemaal mee eens.

[robbietjuh]

leuk_he schreef op woensdag 02 juli 2014 @ 16:51:
[...]


Nou, wepp apps die langer leven ( wat niet ongebruikelijk is voor bedrijfsapplicaties) hebben een soortgelijk probleem. Http is immers niet een stilstaande omgeving. Over een paar jaar is chrome nieuwer blitzer, en veiliger. Dan wordt je opeens gedwongen door je browser een server app te updaten, terwijl jij je dan met heel andere dingen bezig houdt. Native heeft dat probleem minder, omdat je die omgeving zelf beter in de hand hebt.

Waarom denk je dat internet explorer 6 nog steeds een klein aandeel heeft? Juist, omdat er een paar bedrijfsapplicaties zijn die niet / te duur geupdate kunnen worden omdat er hacks gebruikt zijn.

Zolang je applicatie vol in onderhoud is is dit geen issue, als die stabiel is en jaren zonder teveel onderhoud moet draaien heeft native ook zekere voordelen.

Daar heb je natuurlijk een heel goed punt, maar met HTML5 en door je gewoon goed en strikt aan de standaarden te houden denk ik dat het aanpassen van de server app een stuk minder aan bod zal komen dan dat nodig is geweest in de afgelopen jaren met bijvoorbeeld IE6. De protocollen die achter de web app liggen kan je buiten de app over het algemeen relatief eenvoudig updaten. Dat je HTTP op de achtergrond gebruikt om die web app naar je clients te krijgen, is voor de app op zichzelf natuurlijk niet echt belangrijk. Dat handelt Apache af, gelukkig hoef je die stack niet helemaal zelf te schrijven. Daarnaast moet je natuurlijk gewoon in het achterhoofd houden dat alle applicaties gewoon onderhoud nodig hebben van tijd tot tijd. Daar ontkom je niet aan. Native of web.

Ik doelde echter meer op het updaten van de app zelf. Nieuwe functionaliteit toevoegen of bugs pletten. Server-sided kan je 't meteen doorvoeren en een aanpassing in een web app heb je over het algemeen sneller doorgevoerd naar alle clients dan wanneer je een native applicatie hebt draaien.

Het aantal gebruikers van de app op zichzelf, wat bijdraagt aan hoe snel je een nieuwe app zou kunnen deployen, even daargelaten natuurlijk.

[Siebsel]

robbietjuh schreef op woensdag 02 juli 2014 @ 17:14:
[...]
Ik doelde echter meer op het updaten van de app zelf. Nieuwe functionaliteit toevoegen of bugs pletten. Server-sided kan je 't meteen doorvoeren en een aanpassing in een web app heb je over het algemeen sneller doorgevoerd naar alle clients dan wanneer je een native applicatie hebt draaien.

En vergeet niet dat, wanneer je redelijk strict werkt, je minder platform specifieke issues hebt. (Jantje gebruikt browser X op Win7, Pietje browser Y op Linux, etc. - met weinig moeite werkt het overal hetzelfde)

[GlowMouse]

Printen kan ook automatisch vanuit pdf. Je site opent die pdf, waarna hij zonder tussenkomst van de gebruiker wordt geprint. Je moet dan Adobe Reader geïnstalleerd hebben staan, en het domein in Adobe Reader op een groene lijst zetten. Aangezien Adobe Reader op veel platforms draait, lijkt me dat een robuuste oplossing.

[ Voor 17% gewijzigd door GlowMouse op 02-07-2014 17:23 ]

[Siebsel]

GlowMouse schreef op woensdag 02 juli 2014 @ 17:22:
Printen kan ook automatisch vanuit pdf. Je site opent die pdf, waarna hij zonder tussenkomst van de gebruiker wordt geprint. Je moet dan Adobe Reader geïnstalleerd hebben staan, en het domein in Adobe Reader op een groene lijst zetten. Aangezien Adobe Reader op veel platforms draait, lijkt me dat een robuuste oplossing.

Maar je moet wel weer per werkstation speciale instellingen hebben, en dát wou TS juist voorkomen

[Captain Slow]

robbietjuh schreef op woensdag 02 juli 2014 @ 13:12:
... Updates zijn lastiger uit te rollen, bijvoorbeeld. ...

Misschien is ClickOnce hiervoor in jouw situatie een goede oplossing?

[robbietjuh]

GlowMouse schreef op woensdag 02 juli 2014 @ 17:22:
Printen kan ook automatisch vanuit pdf. Je site opent die pdf, waarna hij zonder tussenkomst van de gebruiker wordt geprint. Je moet dan Adobe Reader geïnstalleerd hebben staan, en het domein in Adobe Reader op een groene lijst zetten. Aangezien Adobe Reader op veel platforms draait, lijkt me dat een robuuste oplossing.

Wanneer er nieuwe voorraad ingevoerd wordt gebeurd dat door een 5-cijferig lego-nummer in te voeren tezamen met de kleur van het lego blokje en het aantal dat er in het zakje zitten. Al-met-al zo'n 10 tot 15 aanslagen op het toetsenbord. Dat betekend dat er vaak elke 2 seconden, soms 1 seconde, een nieuwe label uit de printer komt rollen.

Elke 1/2 seconden een op maat gemaakte pdf genereren, die downloaden, openen en preparen om te printen... Ik heb zo het gevoel dat dat niet heel soepel zal verlopen. Daarnaast kom ik inderdaad ook nog met het probleem dat ik dan elk werkstation zal moeten configureren om de web app op de groene lijst te zetten...

Sorry, ik denk dat een Service die luistert tot er een nieuwe opdracht gepusht wordt en die direct doorgeeft aan de drivers van de labelprinter, een stuk smoother zal werken.

[Ramon]

Ik heb bij een webshop gewerkt (waar nu ruim reclame voor wordt gemaakt op TV) en zij hadden toendertijd gekozen voor een C# winforms applicatie gekoppeld aan een web service om orders te verwerken mbv een handscanner en een printer. Dit betekende dat wanneer er in de client-applicatie iets aangepast moest worden (ongeveer 2x per week) we naar het magazijn toe moesten om de app per computer up te daten, waarbij het betreffende station ongeveer 20 minuten down was en betreffende medewerker dus niets aan het doen was.

Needless to say, kutwerk dus. Ik zou kijken of je een native app kan maken die zich puur en alleen bezig houdt met het verwerken van de print-opdrachten. Het verwerken van orders zou ik met een web-app doen in combinatie met een goede releasestrategie (versiebeheer, continuous integration, deployment tooling) zodat je met één druk op de knop terug kan naar een werkende versie mocht het nodig zijn.

Een strikte scheiding van verantwoordelijkheden maakt je minder afhankelijk. Wil je browser updaten, dan test/update je alleen de web-app. Wil je het onderliggende OS updaten, dan kan je de browser hetzelfde laten en de print-applicatie updaten/testen. Zo kan je geleidelijk bij blijven.

[ Voor 13% gewijzigd door Ramon op 02-07-2014 18:32 ]

[farlane]

Ramon schreef op woensdag 02 juli 2014 @ 17:57:
Dit betekende dat wanneer er in de client-applicatie iets aangepast moest worden (ongeveer 2x per week) we naar het magazijn toe moesten om de app per computer up te daten, waarbij het betreffende station ongeveer 20 minuten down was en betreffende medewerker dus niets aan het doen was.

- Automatische updateprocedure?
- Als je 2x per week een website moet aanpassen is ie dan wel gewoon te gebruiken?

Same difference

[Kobus Post]

Is het geen idee om NodeJS te gebruiken i.c.m. deze NPM package https://github.com/tojocky/node-printer

[Ramon]

farlane schreef op woensdag 02 juli 2014 @ 20:54:
[...]

- Automatische updateprocedure?
- Als je 2x per week een website moet aanpassen is ie dan wel gewoon te gebruiken?

Same difference

Een webapp updaten naar een nieuwe versie kost <1 seconde. Ik ken geen desktop app waar dat zo snel kan. Bovendien zijn er altijd handelingen van de client nodig met desktop-apps (op z'n minst "sluit de app, start de app, opnieuw inloggen", maar meestal meer....). En no offence, maar magazijnmedewerkers wil je zo min mogelijk lastig vallen met overbodige handelingen, want echt heel slim zijn ze niet.

Een update aan een webapp kan onzichtbaar gebeuren. En zo een snelle deployment stelt je in staat om in plaats van 2x per week een update, iedere dag een paar updates te doen indien nodig.

[kwaakvaak_v2]

nou updates van 1 seconden op een systeem met realtime data.. Tuurlijk, als er geen DB wijzigingen zijn.. Maar ik zou het toch eerder in de minuten gaan rekenen dan in de secondes

[Kridri]

Is het geen idee op edge.js te gebruiken. Is een koppeling tussen node.js en c#. Dus js voor de frontend (webbased) en c# op de server met de brother aansturing.

[BramV]

Nodejs kan juist makkelijk iets naar socket sturen van C# programma lijkt me, extra laag onnodig?
Met de huidige printerserver programma zou het al werken, die weet ook niks van de client, alleen de response code zou misschien wat anders kunnen zijn met alleen maar goed of fout...

Je krijgt alleen op de server zelf te maken met bijv queue systeem en waar het naar toe moet... (client moet aangeven naar welke printer, maar meestal heb je toch al een inlogsysteem, en koppel je aan de user een standaard printer) Ook als de printer offline is etc... moet je meer afhandelen. Maar dan nog is het niet nodig dat het printerserver programma zelf daar iets over weet.

Mooiste zou zijn als de printer onafhankelijk is van werkstation. Nu heb je toch windows + bpac installatie voor nodig (alhoewel dat ook werkt) i Out of the box, bijv Rapsberry Pi, usb of serial en dan direct aansturen. Je hebt immers geen bpac meer. Labels hebben op zich toch niet zoveel graphics nodig meeste is tekst.

[kwaakvaak_v2]

grappig om te zien dat het blijkbaar iets des developers is om een taal als oplossing te geven, terwijl het eigenlijk geen reet uitmaakt wat de taal is en de kern van het antwoord is, kies een techniek.

Dit soort (semi) realtime systemen vragen om transacties en messages. Het in/uitboeken van artikelen is een soort van realtime, alle handelingen daarom heen zoals het uit printen van een labeltje en evt. bestelbon via een message afgehandeld kunnen worden. En het implementeren van transactie based database koppeling en afhandelen van messages in principe door elke taal gedaan kunnen worden.

Dat dit soort applicaties prima in een browser kunnen voor de data entry lijkt mij een no-brainer. Maar het is een misverstand dat alles wat in binnen een browser gebeurd ook in realtime binnen het request afgehandeld dient te worden.

Mijn tip, kijk naar wat je nodig hebt, kies daar de technieken bij en maak het lekker in de taal/talen die je liggen.

[BramV]

robbietjuh schreef op woensdag 02 juli 2014 @ 14:56:
Om alles een beetje netjes, onderhoudbaar en compatible te houden lijkt het me persoonlijk het beste om een Windows Service te schrijven in C# dat bij het starten een verbinding legt met de server zoals Cor/Siebsel aangeeft met Faye in Node.js of met een websocket. Op die manier kan de app makkelijk opdrachten pushen naar de clients. Die Service kan vervolgens gepusht worden naar de clients met behulp van een Group Policy regel. Any thoughts?

Als je van de printerserver ipv een socket server (zoals nu) een websocketserver maakt dan kun je vanuit een
browser aanroepen met javascript...

var ws = new WebSocket("ws://localhost:8000/echo");
ws.onopen = function()
{
ws.send("Message to send");
};

Op die manier heb je geen problemen met crossdomain XHR toestanden, wat volgens mij de reden is dat je een
hack moet uitvoeren in de browser?

[Verwijderd]

Een WebSocket server is een Socket server die daya serveert over het WebSocket protocol.. Niks bijzonders..

[BikkelZ]

Ik vind het een prima idee om de server te laten printen in plaats van de client. In een Microsoft-omgeving en gezien het feit dat je redelijk wat business rules zult hebben is een Microsoft stack met een sterke OO taal zoals C# natuurlijk geen gek idee. Ik denk dat niet-native Windows talen zoals Node.js iets lastiger te integreren zijn met het printen naar een printer op het netwerk maar niet onmogelijk.

De horrorverhalen hier over het updaten van native clientsoftware is natuurlijk ook een beetje afhankelijk van hoe je het inricht. Updates van applicaties zijn redelijk makkelijk te distribueren als je er vanaf het begin redelijk mee houdt dat je dat regelmatig wil doen.

Een native app voelt wel beter aan voor de gebruiker (mits indien tenzij....) en gaat wat beter overweg met bi-directionele communicatie met een server. Hoef je in ieder geval niet steeds te pollen.

[ Voor 12% gewijzigd door BikkelZ op 03-07-2014 16:58 ]

[Verwijderd]

Ik zie een duidelijke usecase voor NodeJS + bijkomende technieken en NPM Modules.
Bovenop NodeJS een WebServer en Database etc etc. En daar boven op zoals vele zeggen https://github.com/tojocky/node-printer om te printen.

Hedendaags worden complete ERP pakketen omgezet naar webbased systemen. Raad eens waarom? Omdat het gewoon de toekomst is. Native is moeilijk te onderhouden omdat je allerlei platformen moet onderhouden en moeilijker updates uit te rollen. Tevens als er een nieuwe platform bij komt is WebBased al direct klaar voor gebruik. Bij Native moet je weer een nieuwe applicatie maken + bijhouden.

WebApplicaties hebben gewoon zoveel voordelen tegenover Native. En mensen maar roepen dat het sloom is. Het is idd niet 100% zoals Native maar komt wel aardig in de buurt en je ziet door de "maanden" heen dat het steeds sneller en sneller gaat worden.

[epic007]

robbietjuh schreef op woensdag 02 juli 2014 @ 17:41:
Sorry, ik denk dat een Service die luistert tot er een nieuwe opdracht gepusht wordt en die direct doorgeeft aan de drivers van de labelprinter, een stuk smoother zal werken.

Dit klinkt als een printspooler, die al native in Windows zit. Ik weet niet of je beslist platform onafhankelijk wil zijn maar als je alleen onder windows werkt zou je eerdere idee via SMB mounts naar een centrale (print)server precies hetzelfde werken.

Dat printers/workstations offline kunnen zijn vang je ook niet af met deze Service, die is dan ook offline.

[HuHu]

Ik heb ooit een vergelijkbaar probleem gehad. De applicatie was volledig web-based. Alle printers waren (ook) geïnstalleerd op de server. Medewerkers konden in hun profiel een printer kiezen uit de lijst van geïnstalleerde printers op de server. Als er een printopdracht was (orderformulier, factuur, verzendlabel, etc) werd op de server een PDF gegenereerd (middels de web-based app), in een temp-mapje gezet en met gsprint afgedrukt.

De oplossing was dus volledig web-based. Alleen de aller-allerlaatste stap, het daadwerkelijke afdrukken, werd geregeld door een native applicatie. Voor elk OS zijn wel goede command-line apps beschikbaar die PDFs kunnen afdrukken.

Verwijderd schreef op zaterdag 05 juli 2014 @ 09:57:
Ik zie een duidelijke usecase voor NodeJS + bijkomende technieken en NPM Modules.

Blablabla... ik zie een duidelijke usecase voor elke willekeurige programmeertaal met welke willekeurige techniek en willekeurige module/library/framework dan ook. Zoals kwaakvaak_v2 ook al zei: het is echt totaal oninteressant om een bepaalde taal of techniek aan te raden als "oplossing". Dat soort reacties zijn net zo dom als iemand een probleem heeft en je reageert met "koop een Mac". Dit voegt niets toe, tenzij TS zelf al had aangegeven met node.js te werken en daarin een oplossing zocht, maar niet bij een generieke vraag betreffende een concept.

[ Voor 36% gewijzigd door HuHu op 07-07-2014 10:07 ]