Ciao a tutti, stiamo verificando parecchi casi di chiamate SOAP verso il servizio RiceviFile che vanno in timeout (dopo oltre 2 minuti di attesa!).
Oltretutto dopo varie verifiche al telefono con la segreteria tecnica di Sogei pare che a volte i file risultano acquisiti (ma non abbiamo ricevuto risposta quindi niente SDI ID), altre volte invece come se non ci fossero mai stati quindi possiamo riemettere tranquillamente la fattura.
Qualcuno di voi ha riscontrato le stesse problematiche?
Anche noi abbiamo dei timeout ieri verso le 21.00 poi “risolti” nel senso che i tentativi successivi sono andati a buon fine.
Sta diventando sempre più frequente nei momenti di carico. Il sistema che dialoga con il webservice deve essere configurato per attendere la risposta almeno un paio di minuti (noi ne attendiamo 5), diversamente si rischiano di generare invii multipli e conseguente scarto per duplicato.
5 minuti di timeout? 
E ancora risponde dopo alcuni minuti di attesa?
già, noi ora stiamo a 3 minuti, oltre mi sembra troppo. soprattutto perché stiamo parlando di web service…
Ciao, scusa, una domanda: anche noi abbiamo un problema simile, nel senso che a volte, quando i nostri clienti inviano una fattura xml, sembra che il sistema faccia due invii in simultanea, perché il SDI genera due id diversi per ciascun invio: ovviamente il secondo invio va in scarto perché documento duplicato. Sono assolutamente certo che non si tratta di un problema del mio software.
E’ questo anche il tuo caso? Come lo hai risolto?
Però non capisco cosa c’entra il timeout, nel senso che il mio programma chiama prima il metodo RiceviFile e poi il metodo getLastResponse. Non c’è niente, però, nel mio codice che tenti “in automatico” un altro invio: se non c’è una risposta positiva, il programma riporta un messaggio di errore all’utente e gli permette di effettuare un altro invio, ma non è questo il caso, sia perché gli utenti negano che sia successa una cosa del genere e sia perché, come orario, gli invii sembrano quasi in simultanea…
Il nostro caso credo sia diverso, perché non si tratta di invii in simultanea:
primo invio allo SDI non otteniamo risposta, il nostro client va in timeout dopo X tempo. Non sappiamo se la fattura sia stata accettata o no.
Secondo invio allo SDI della stessa fattura scopriamo se la fattura precedente era stata presa in carico dallo SDI.
Mi sembra che nel tuo caso gli invii avvengano in simultanea, quindi azzarderei un problema lato software.
primo invio allo SDI non otteniamo risposta, il nostro client va in timeout dopo X tempo. Non sappiamo se la fattura sia stata accettata o no.
Secondo invio allo SDI della stessa fattura scopriamo se la fattura precedente era stata presa in carico dallo SDI
Anche io mi trovo in questo caso, posto che il “scopriamo se la fattura precedente era stata presa in carico da SdI o no” non è così banale da capire, nel senso che lo si scopre solo in modo asincrono sulla base dei messaggi di ritorno che si ricevono. Poi tra l’altro è capitato più di una volta che arrivi prima lo scarto del secondo invio che la ricevuta di consegna/mancata consegna del primo, cosicché il nostro software interpreta la fattura come scartata e sistemare le cose a posteriori (quando arriva il messaggio “giusto”) è un casino, anche perché tra l’altro gli identificativi SdI sono diversi…
Se poi Roberto è sicuro che il suo software effettui un unico invio e non due tentativi di invio, e nonostante questo l’SdI consideri un doppio invio, la situazione è ancora più complicata…
Se il dialogo con SDI avviene in modo sincrono con la pressione del bottone di invio nel browser, potrebbe trattarsi banalmente di doppi click sul bottone, o considerato che può impiegare minuti, timeout del browser, webserver, linguaggio di scripting, socket, …
Senza vedere il codice è impossibile essere più precisi.
Nel nostro caso utilizziamo delle code DLQ per disaccoppiare l’invio dall’interfaccia ed il problema era dovuto al timeout delle stesse, che infatti abbiamo aumentato, risolvendo il problema.
Importante capire in quale momento il codice decide il nome file da usare.
SDI non ha un metodo getLastResponse, immagino sia un tuo metodo
Noi leggiamo le risposte del web service dello SDI e ci creiamo dei metadati es: <?xml version="1.0" encoding="utf-8"?> <root> <DataOraRicezione>2019-01-11T17:15:58.345+01:00</DataOraRicezione> <IdentificativoSdI>158716529</IdentificativoSdI> </root>
Se il web service non ci fornisce questi dati all’'invio del documento, lasciamo lo stesso nella coda per un successivo invio.
Come timeout non usiamo impostazioni particolari, ma gestiamo tutte con le code.
Il dialogo del nostro software con SDI avviene in maniera sincrona, l’utente preme il pulsante per l’invio e questo sparisce subito, venendo sostituito da una barra di scorrimento che indica lo svolgersi di una elaborazione.
A questo punto il controllo passa ad un codice PHP che, sempre in maniera sincrona, richiama il metodo RiceviFile del web server SDI e poi attende la risposta con il metodo __getLastResponse(), che è un metodo standard PHP per il soap client (https://www.php.net/manual/en/soapclient.getlastresponse.php)
E niente, a volte succede che il programma effettua due invii in contemporanea, ricevendo due id diversi da SDI, quindi si tratta di invii leciti e gestiti da SDI, ma uno ovviamente va in scarto per fattura duplicata.
Aumenta default_socket_timeout ad almeno 5 minuti.
Ti conviene includere un controllo lato server per impedire il doppio invio, non fidarti solo del fatto che il bottone sparisce una volta premuto.
Noi abbiamo timeout di connessione e anche di lettura impostati a 60 secondi, zero problemi finora, cioè quelle rare volte che è fallito, non ha proprio connesso quindi niente duplicati.
Spediamo con tre thread dallo stesso IP senza pause tra una fattura e l’altra.
Circa 500-600 fatture al giorno, invio concentrato in pochi minuti verso le 20.00.
Tocco ferro… ma magari è il timeout di read da aumentare ? Che è quello che in effetti darebbe problemi per leggere l’id in risposta.
Sicuramente è più critico il “read timeout” (detto anche “socket timeout”) piuttosto che il “connect timeout”, perché se scatta il secondo la connessione neppure parte e quindi basta riprovare, se scatta il primo significa che la comunicazione è già partita ma non riceviamo alcuna risposta da SdI nei tempi previsti, il che però non significa necessariamente che SdI non abbia elaborato la nostra richiesta, semplicemente potrebbe essersi attardato a rispondere (per problemi di lentezza suoi ma anche potenzialmente di comunicazione nel mezzo). Anche qui, un meccanismo per poter avere un riscontro a posteriori qualora una precedente richiesta sia stata o meno elaborata da SdI, per evitare un secondo tentativo di invio “a vuoto” (e potenzialmente fonte di problemi), farebbe molto comodo.
Sarebbe altrimenti auspicabile che l’SdI andasse in rollback qualora la comunicazione non finisca completamente (ivi compresa la corretta trasmissione della sua risposta), ma tant’è… non è così.
Concordo pienamente su entrambi i punti, non abbiamo un minimo di strumenti di verifica delle operazioni, tanto meno dello stato dei servizi. Dopodiché sarebbe il minimo un rollback delle operazioni in questi casi.
Per avere un riscontro a posteriori si può sempre verificare la presenza dell’invio sul portale Fatture&Corrispettivi, sezione Monitoraggio ricevute file trasmessi. Noi abbiamo realizzato uno script, accessibile anche sotto forma di Web Service, per effettuare tali controlli in modo automatizzato.
L’arte di arrangiarsi… 
Il problema principale che vedo è che le credenziali per accedere a “Fatture e corrispettivi” sono quelle dell’azienda che si propone come trasmittente (smart card, FiscoOnline, SPiD): oltre alla difficoltà di gestione di queste credenziali in forma automatizzata, si pone anche un problema non da poco di riservatezza di queste credenziali (che il datore di lavoro potrebbe non voler dare agli sviluppatori…), senza contare che basta che cambino un qualcosa sul sito e lo script “si rompe”.
Comunque grazie per lo spunto.
Chiaramente se il rapporto tra il canale accreditato e il fruitore è uno a uno ha senso. Per chi fa il mestiere del “postino” su n canali non è un approcio percorribile a mio modo di vedere, non credo siano credenziali che si possano maneggiare a cuor leggero.
Se un azienda fornisce un software di fatturazione ai propri clienti, quindi è il trasmittente, le uniche credenziali che deve usare sono le sue.
Mi pareva che le credenziali fossero sempre di una persona fisica, che dopo il login può scegliere se operare con i suoi dati personali oppure con quelli dell’azienda (se è autorizzata).
È possibile avere delle credenziali per F&C con cui si può accedere esclusivamente ai dati di un’azienda?