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