Abbiamo in pochissimi casi il problema che Lo SDI ci invia le fatture sul nostro canale accreditato, ma senza successo anche dopo 4 tentativi, in orari diversi. Nello stesso tempo riceviamo invece con successo altre fatture dallo SDI.
Secondo Servizio di assistenza Sogei queste singole poche fatture hanno l’errore da parte loro di tipo “org.apache.axis2.AxisFault: WSWS7089I: The connection wait has timed out.”
Da parte nostra invece non vediamo nessun tentativo negativo/postivo sul log della firewall per i timestamp indicati dallo SDI.
Qualcuno ha un idea come riusciamo a migliorare questo per permettere di ricevere tutte le fatture in ingresso con sucesso?
Sembra plausibile che l’errore org.apache.axis2.AxisFault: WSWS7089I: The connection wait has timed out è dovuto dalla connessione del server Apache (timed out).
Prova a controllare la versione di Apache (aggiornamento);
Prova a verificare le impostazioni PHP (8.1 opp se lo supporta 8.2)
Grazie per la risposta, ma forse mi sono espresso male.
L’errore " org.apache.axis2.AxisFault: WSWS7089I: The connection wait has timed out" riceve lo SDI quando fa i tentativi al nostro canale accreditato SDI Coop.
Noi stessi non abbiamo niente in uso di Apache…
Ciao @Lukas_Hofer, Axis2 termina la connessione con Apache. Ciò potrebbe verificarsi a causa del HTTPSender. In questo caso chi riceve non ha errore.
Questo problema deve essere verificato da un esperto informatico che conosce bene il linguaggio di programmazione lato server.
Ciao Cristian, grazie per il tuo feedback.
“lato server” intendi da parte dello SDI?
La nostra dificoltà con l’assistenza Sogei é che ci dicono solo questo errore con la spiegazione “puó capitare”. Ma questo per noi non è sufficiente, vorremmo poter essere sicuri di ricevere tutte le fatture dallo SDI, altrimenti serve sempre la controverifica nel cassetto fiscale.
Che potremmo fare da parte nostra?
La prima domanda è: come avete fatto ad accorgervene se sui vostri server non c’è traccia di questi tentativi di consegnare le fatture?
Secondo: da una breve ricerca mi pare di capire che l’errore sta tutto sul lato loro, nel senso che non viene mai fatto un tentativo di connessione. Per come funziona il loro application server, il numero delle connessioni in uscita è limitato (c’è un pool di connessioni). Se questo pool si esaurisce, le connessioni in uscita aspettano che si liberi uno “slot” e vanno in timeout dopo un po’ (che è la cosa che genera il messaggio di errore in questione).
Almeno questo è quello che ho capito io, ma potrei sbagliarmi.
Un consiglio
è abbastanza evidente che il problema è legato all’ HTTPSender questo significa che il problema è dovuto da lato mittente ma non destinatario. Quindi, come ti dicevo in una precedente risposta, il problema non si verifica in entrata.
Le cause possono essere molteplici ma non sono certamente causate da te ma di chi invia.
In ogni caso, oltre che far verificare il tuo pc da un esperto informatico, ti consiglio in qualche modo, di verificare le porte FIREWALL E SE OCCORRE CREARE UNA REGOLA.
Considerando che se l’errore è interno a SDI, non rimane traccia nei log di chi dovrebbe ricevere le fatture, questo problema potenzialmente ce l’hanno tutti. Noi fino ad ora non abbiamo avuto segnalazioni di fatture non ricevute, ma c’è un modo per vedere se SDI ogni tanto ha problemi a consegnarle.
Quando una fattura viene consegnata, il file metadati contiene nel campo TentativiInvio il numero di tentativi fatti. Si può confrontare questo dato con i propri log per vedere se ci sono tentativi falliti di cui non si ha traccia.
Nel nostro caso abbiamo i log del load balancer, e le richieste fallite sono molto rare (di solito succede quando facciamo manutenzione sugli application server) mentre invece ci sono parecchie fatture con TentativiInvio pari a 2 e in un paio di casi pari a 3. Non ho trovato fatture consegnate al quarto (e ultimo) tentativo, il che mi fa sperare che non siano mai andati oltre i quattro tentativi.
Dico “parecchie” perché mi sembrano tante, ma si tratta dello 0,3% delle fatture ricevute (dall’inizio di quest’anno).
Aggiungo che, da quello che mi risulta, il nostro load balancer non ha mai avuto problemi di connessione e tutte le connessioni in arrivo finiscono nel log, quindi è plausibile che questi tentativi falliti da parte di SdI si siano bloccati all’interno dei loro sistemi e non per colpa nostra (o per problemi di rete nostri).
Quindi la conclusione è che ogni tanto l’invio delle fatture da parte di SdI fallisce per colpa loro e in rarissimi casi può capitare quattro volte di fila, per cui la fattura va in mancata consegna. E non c’è niente che si possa fare.
come avete fatto ad accorgervene se sui vostri server non c’è traccia di questi tentativi di consegnare le fatture?
Con i Timestamp ricevuti dallo SDI abbiamo verificato sul log della Firewall se ci sono dei tentativi falliti. Ma li abbiamo visto nessun errore o indicativio di un tentativio da parte dello SDI.
da una breve ricerca mi pare di capire che l’errore sta tutto sul lato loro, nel senso che non viene mai fatto un tentativo di connessione. Per come funziona il loro application server, il numero delle connessioni in uscita è limitato (c’è un pool di connessioni). Se questo pool si esaurisce, le connessioni in uscita aspettano che si liberi uno “slot” e vanno in timeout dopo un po’ (che è la cosa che genera il messaggio di errore in questione).
Almeno questo è quello che ho capito io, ma potrei sbagliarmi
Sembra anche a noi che é cosi, ma se chiedo maggiori dettagli da parte loro mi dicono sempre le stesse cose. Come potrei comportarmi?
Anche da noi sono pochissimi i file che mancano. Ma già uno mancante é un impegno per il proprietario del file a prenderlo a mano dal casseto fiscale.
Mi pare strano, che non si riesce a capire assieme al supporto dello SDI che cosa si possa migliorare. Se farebbero solo un singolo tentativo ok, quello può anche fallire. Ma non ricevere il file dopo 4 tentativi mi pare più che strano.
Mi è sfuggito che tecnologia avete voi lato server.
Se (e solo se) “lato vostro” c’è un server in windows con IIS che fa partire un webservice in .net prova a vedere questo articolo che mi ha aiutato molto: (non era lo stesso problema ma dava errori random)