Italian Consiglio su lettura dati in realtime

[udg]

Non solo costi, ma anche disponibilità..non è scontato che la software house accolga l'idea di aggiungere questo tipo di funzionalità al suo sw, anche se dietro lauto compenso.
Dovendo agire "dietro le quinte", le due possibilità che mi vengono in mente sono:
- accesso al DB (autorizzato o meno)
- intercettazione dei messaggi dalle casse al server che ospita al DB

Ad ogni modo, mi era sembrato di capire che l'unico dato che interessi sia l'incasso totale e non le singole transazioni. Una possibilità potrebbe essere quella di monitorare costantemente gli incassi e, a fine giornata, riversare tutte le transazioni (molto utile per statistiche che abbiano un senso).

 

[amorosik]

Non solo: così magari il produttore del sw (ammesso che faccia queste personalizzazioni) magari fa pure il resto, fregando il cliente a @Xfood.

Ma di che 'personalizzazioni' stai parlando?
Si tratta di un script da 10 righe da inserire nel db
L'amico siculo puo' fare gia' le prove su un db gemello di test e fornire esattamente lo script da inserire
Diciamo che se avesse utente/password potrebbe farlo pure lui, di sicuro nessuno se ne accorgerebbe
Ma per correttezza lo chiedera' a chi fa l'assistenza al gestionale
La parte del programma che riceve il comando, il 'subscriber' per capirci, sara' interamente a carico di Xfood, che gli fara' fare le capriole del caso

 

[amorosik]

Non solo costi, ma anche disponibilità..non è scontato che la software house accolga l'idea di aggiungere questo tipo di funzionalità al suo sw, anche se dietro lauto compenso.
Dovendo agire "dietro le quinte", le due possibilità che mi vengono in mente sono:
- accesso al DB (autorizzato o meno)
- intercettazione dei messaggi dalle casse al server che ospita al DB

Ad ogni modo, mi era sembrato di capire che l'unico dato che interessi sia l'incasso totale e non le singole transazioni. Una possibilità potrebbe essere quella di monitorare costantemente gli incassi e, a fine giornata, riversare tutte le transazioni (molto utile per statistiche che abbiano un senso).

Ma costi de che?
Per l'inserimento di uno script gia' pronto e collaudato che costi vuoi ci siano?
Ci vorrebbe un bel coraggio a chiedere qualcosa, a mio parere, per un lavoro che portera' via mezzora a farla stragrande

 

[LucaMs]

Ma costi de che?
Per l'inserimento di uno script gia' pronto e collaudato che costi vuoi ci siano?
Ci vorrebbe un bel coraggio a chiedere qualcosa, a mio parere, per un lavoro che portera' via mezzora a farla stragrande

Per un lavoretto così, nei primi anni 2000, la "mia" azienda si faceva pagare minimo 60€ / ora.

 

[LucaMs]

Ad ogni modo, mi era sembrato di capire che l'unico dato che interessi sia l'incasso totale e non le singole transazioni. Una possibilità potrebbe essere quella di monitorare costantemente gli incassi e, a fine giornata, riversare tutte le transazioni (molto utile per statistiche che abbiano un senso).

Infatti non mi è molto chiaro; perché ogni 10/15 secondi per avere i soli totali degli incassi? Mah.

 

[amorosik]

Per un lavoretto così, nei primi anni 2000, la "mia" azienda si faceva pagare minimo 60€ / ora.

Ok, vediamo quanto ci mettono ad inserire lo script, gia' pronto e collaudato intendo
Avendo utente/password del db, tra login, avvio script, attesa creazione oggetto, verifica che l'oggetto sia stato creato, io ci metto 2 minuti
Metti che non tutti siano scarsotti come me, siano piu' bravini, ci impiegheranno 10 minuti ?
La 'tua' azienda cosa avrebbe richiesto?

 

[amorosik]

Un po' piu' complesso e' realizzare quello che Microsoft chiama il 'broker'
Che sostanzialmente e' il 'consumatore' degli eventi generati dal db server
Ma quello e' completamente un aggeggio esterno al gestionale e Xfood potrebbe realizzarlo con tutta la calma e le funzioni necessarie e l'ambiente di sviluppo che meglio crede
Fatto sta che appena l'azione descritta nell'evento del db avviene (l'incasso su postazione vendita), un messaggio viene inviato al programma esterno, che a sua volta aggiornera' il db centralizzato incassi
Tutto senza muovere un dito e tutto in real-time
Piu' figo di cosi' nin zo

 

[Elric]

Se lo schema di LucaMs è corretto e l'app di lettura che devi creare l'avranno in pochi, perché l'aggiornamento non lo fai fare in apertura dell'app stessa? Ci metterà un po' di più ma amen.

 

[LucaMs]

L'app, all'avvio, si connetterà come client al websocket server centrale, il quale gli invierà gli ulltimi dati aggiornati. Mantenendo l'app connessa al server, riceverà costantemente gli aggiornamenti, senza necessità di timer/polling.

 

[LucaMs]

Ok, vediamo quanto ci mettono ad inserire lo script

Che tipo di script? Non dovresti aggiungere dei trigger al db?
[All'epoca personalmente non mi occupavo di MS SQLServer, c'erano altri colleghi per questo, benché l'azienda si occupasse principalmente di AS/400-iSeries]

 

[Xfood]

Un po' piu' complesso e' realizzare quello che Microsoft chiama il 'broker'
Che sostanzialmente e' il 'consumatore' degli eventi generati dal db server
Ma quello e' completamente un aggeggio esterno al gestionale e Xfood potrebbe realizzarlo con tutta la calma e le funzioni necessarie e l'ambiente di sviluppo che meglio crede
Fatto sta che appena l'azione descritta nell'evento del db avviene (l'incasso su postazione vendita), un messaggio viene inviato al programma esterno, che a sua volta aggiornera' il db centralizzato incassi
Tutto senza muovere un dito e tutto in real-time
Piu' figo di cosi' nin zo

E'molto figo, potresti farmi un esempio ? Cioe un script di esempio che poi scatena un evento, che poi intercetto "immaggino" in b4j che poi fa qualcosa.???

 

[amorosik]

Che tipo di script? Non dovresti aggiungere dei trigger al db?
[All'epoca personalmente non mi occupavo di MS SQLServer, c'erano altri colleghi per questo, benché l'azienda si occupasse principalmente di AS/400-iSeries]

Ho parlato di 'script' intendendo genericamente il file da lanciare per fare le modifiche opportune nel db
Quel che realmente c'e' da inserire nel db sara' da capire seguendo la documentazione Microsoft

 

[amorosik]

E'molto figo, potresti farmi un esempio ? Cioe un script di esempio che poi scatena un evento, che poi intercetto "immaggino" in b4j che poi fa qualcosa.???

E certo che e' figo, l'ho consigliato io ?
Non saprei farti un esempio concreto, so per sicuro che si possa fare
Per il dettaglio dell'implementazione basta seguire la documentazione Microsoft e ravanare un po' in rete

 

[LucaMs]

Ho parlato di 'script' intendendo genericamente il file da lanciare per fare le modifiche opportune nel db
Quel che realmente c'e' da inserire nel db sara' da capire seguendo la documentazione Microsoft

Meno male che lo avresti fatto in 2 minuti; forse in 2 minuti speravi di riuscire a trovare la documentazione ?

 

[LucaMs]

75 post per una cosa che nessuno realizzerà mai ?

 

[amorosik]

Meno male che lo avresti fatto in 2 minuti; forse in 2 minuti speravi di riuscire a trovare la documentazione ?

Se vuoi mi dai un qualsiasi script, e cronometriamo quanto ci metto a lanciarlo su un qualsiasi Sql Server
Se ci metto meno di 2 minuti paghi pizza e birra, se invece ci metto di piu' allora pago io
Ovviamente il tempo di esecuzione dell script non puo' venir considerato, perche' se mi dai ua roba che ci mette un'ora ehhhh allora non vale
Che dici?

 

[amorosik]

75 post per una cosa che nessuno realizzerà mai ?

Veramente io l'ho gia' realizzata, con altro db server ?

 

[sirjo66]

si, non vedo altre soluzioni più semplici

il programma in B4J (o altri linguaggi non ha importanza) con timer che interroga il database ogni X secondi e si calcola i totali.
Se i totali sono diversi dai precedenti calcolati invio questi dati ad un server centrale.

 

[amorosik]

si, non vedo altre soluzioni più semplici

il programma in B4J (o altri linguaggi non ha importanza) con timer che interroga il database ogni X secondi e si calcola i totali.
Se i totali sono diversi dai precedenti calcolati invio questi dati ad un server centrale.

Scelta personale
Tu preferisci la semplicita' del codice, a scapito dell'efficienza e reattivita' sistema
Io preferisco scegliere la strada piu' lunga e sicuramente piu' efficace sia in termini di occupazione risorse che di reattivita'

 

[amorosik]

Meno male che lo avresti fatto in 2 minuti; forse in 2 minuti speravi di riuscire a trovare la documentazione ?

Ah forse ho capito, tu hai inteso che in 2 minuti avrei potuto realizzare lo script per attivare l'evento nel db
Ma se rileggi il post, non c'e' scritto questo, c'e' scritto
".. Ok, vediamo quanto ci mettono ad INSERIRE lo script, gia' pronto e collaudato intendo .."