2015-10-27 15:02 GMT+01:00 Marco Soldavini <magyar1...@gmail.com>:
>
>
> 2015-10-27 11:00 GMT+01:00 Andrea D'Amore <and.dam...@gmail.com>:
>>
>> 2015-10-27 0:38 GMT+01:00 Marco Soldavini <magyar1...@gmail.com>:
>> > I dati in ingresso provengono dai file CSV (in maniera diciamo discreta
>> > ogni
>> > tot tempo
>>
>> Sincrona o asincrona?
>>
>
> Il funzionamento spiegato meglio, magari apro un thread a parte, è il
> seguente:
>
> nell'architettura ci sono due entità
> A è la macchina che genera i file CSV, e i tag OPC (generalmente un sistema
> windows embedded)
> B è la macchina dove gira il mio applicativo in background
>
> A è collegata ad una macchina comandata da operatore che lavora a lotti
> discreti di produzione.
> per esempio l'operatore preme START BATCH e questo è un trigger OPC per
> iniziare la registrazione in OPC dei tag
> generati da A.
>
Questo dovrebbe essere facile, se hai il supporto per OPC pronto.
> Quando l'operatore preme STOP BATCH la mia applicazione smette di leggere e
> memorizzare i dati OPC.
> Successivamente la macchina A ha generato due file csv che provvede a
> spostare su B (oppure in base al trigger STOP BATCH la mia applicazione
> sposta i file da A con un metodo da decidere)
>
Questo non mi sembra banalissimo.
Se A sposta i files csv su B, allora è facile.
Altrimenti potresti avere una race condition, con A che accede ai
files prima che vengano generati completamente.
Per il trasporto io userei un protocollo custom su TLS, magari usando
ZeroMQ (ma la moda del momento è abusare di HTTP).
> Successivamente l'app deve
>
> prendere i dati registrati e inserirli in un database di qualche tipo
> prendere i 2 file CSV, fare parsing e inserirli nellio stesso db di cui
> sopra.
> generare un file PDF contenente come già detto i dati registrati dai file
> CSV e da OPC
>
Io farei in questo modo.
Applicazione principale con eventuale UI che lancia N sotto processi
(con multiprocess).
1) Un processo lancia il server OPC e resta in ascolto dei dati, li
riceve e li scrive su database; quindi notifica il processo padre che
ha terminato
(magari terminando, se applicabile).
2) Un processo lancia il server TLS o HTTPS per ricevere i file CSV,
li legge ed invia il contenuto su database.
Quando ha finito notifica il padre.
3) Quando il padre vede che i due processi hanno finito, ne lancia un
terzo che preleva i dati dal database e genera il PDF
Non mi viene in mente soluzione più semplice.
Non hai bisogno di programmazione asincrona, dato che i server in
pratica servono una sola richiesta alla volta.
Il punto più critico è vedere se puoi disaccoppiare la scrittura su
database da una lettura successiva.
Perchè complicarsi la vita introducendo una componente aggiuntiva come
celery se hai già il database?
Ciao Manlio
_______________________________________________
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
