Non so cosa sia il codice invio sdi, utilizzo sdiftp, ho il file EO. come riferimento ma per un determinato supporto e non sulla singola fattura. Quindi l’unico modo per accertarmi se il file è stato letto è quello di controllare su F&C. E poi chiedere chiarimenti a Sogei.
Ma se non distinguono una fattura, tra l’altro con estensione .xml (oltre a contenere anche il nome del supporto) da una partita iva… non sono messi bene… ma per niente!
Scusami, ho travisato, pensando alla mia casistica (SdiCoop) , chiaramente a voi che usate SdiFtp il giro del fumo è più complicato , e come avri già letto sul forum:
puoi ritenerti fortunato perchè hai ricevuto gli EO.
Forse si sono accorti di aver dimenticato uno sleep di debug da qualche parte nel codice o magari hanno creato gli indici del db
(cose a me successe, fortunatamente non ci ho mai messo due mesi ad accorgermene)
2 Mi Piace
@avb2b
Per quanto la programmazione sia nata, per lo più, da matematici ed ingegneri (quindi persone), chi scrive codice a sua volta è umano ed alterna giorni allegri a giorni di mer*a… Quindi gli errori, le distrazioni, le sottovalutazioni, variabili non previste etc… possono sempre accadere. L’importante è essere onesti ed ammettere quando si sbaglia. Non è facile e non si accetta molto volentieri… ma se si è seri, bisogna ammetterlo.
Personalmente (è quasi un anno che sono accreditato), mi sono accorto di diverse eccezioni e variabili sottovalutate nella progettazione del mio software. Ai miei clienti, non ho detto che la colpa fosse dello SDI, ho detto semplicemente che il software non aveva previsto una determinata casistica e che avrei risolto il prima possibile.
Quando un cliente chiama Sogei, per chiedere spiegazione sul come mai in F&C la notifica è presente, mente al software ancora non è stata recapitata, Sogei risponde che è colpa del fornitore del software e di provvedere a sistemarlo o cambiare software. Un operatore si è addirittura permesso di dire che ne esistono tanti!!!
Ovvio che poi uno si incazza! Invii i log per chiedere spiegazioni di alcune anomalie e non sanno distinguere una partita iva da una fattura… 
2 Mi Piace
Io mi riferivo al backlog zero eh non alle tue domande (giusto per chiarezza)
Anche oggi spettacolo, mai visto così veloce , yahooo 
Anche qua oggi siamo a zero…
Chi usa FTP ha avuto dei miglioramenti ?
Io vado per deduzione in base alle notifiche di ricezione, direi che sono tutti migliorati, noto che 5RUO82D Passepartout è la mia attuale maglia nera… ma decisamente più veloce di settimana scorsa.
AdE se mi ascolti: dirottate i sequestri di cocaina a favore dei criceti
Backlog 0 anche su FTP e E0 che arrivano nel giro di ore e non giorni…
Hanno dopato i criceti…
1 Mi Piace
ma non potrebbe dipendere dal fatto che il congestionamento è finito perchè la scadenza del 18 febbraio è alle spalle ?
1 Mi Piace
Ciao @Paolo_Del_Romano, così veloce MAI la differenza è troppa, anche perhè (elmeno per me) il surplus del fine mese è stato del 40% rispetto alla media giornaliera.
O hanno aumentato le macchine / banda… oppure avevano davvero un collo di bottiglia software che hanno risolto…
1 Mi Piace
Ho parlato telefonicamente con un tecnico Sogei il quale mi ha confermato il recente aggiornamento software (“qualche giorno fa”).
Secondo me l’intoppo era a livello sw, d’altra parte si è iniziato a manifestare in modo importante a partire dall’Armageddon dell’8/1.
Direi questa, sicuramente non è HW o architettura sw
io non sono un tifoso ne di java ne di IBM websphere ,
ma senza strafare con 2 armadi 80u …
ci stanno circa 5000 core e 250 tera di ram, 2500 tera netti di dischi SSD 160 schede 40 gigabit
ora pur supponendo che il java è piu’ lento del C++, è plausibile elaborare una fattura in 5 10 secondi per singolo core.
0.1 fatture al secondo = 5000 * 3600 * 0.1 = 1.8 ML di fatture ogni ora = 30 ML di fatture al gg all’incirca
che e’ effettivamente quello che fanno,
in quanto se ci pensate “by design” il giro del fumo del polling SDIFtp non secnderà mai sotto le 2 / 3 ore
solo sdicoop “teoricamente” potrebbe girare realtime
Realtime ftp no, ma neanche a giorni, tieni presente che in ftp si collegano ogni 10 minuti…
anche ammesso che prendano 1000 fatture ogni dieci minuti da ogni singolo nodo, considerando che con la mia modesta infrastruttura HW processo 30000 fatture al minuto (quindi circa 300 volte il mio carico attuale), con la loro non dovrebbe essere un problema smaltire il traffico che gli genero (la tua stima di 5/10 secondi a fattura per core mi sembra abbondantemente pessimistica, a meno di non considerare il giro completo compreso di tempi di trasferimento).
Il problema è che per qualche cavolo di ragione, le fatture che gli metto nella cartella le prelevano solo dopo il quinto giro che fanno da me… (???) quindi in media dopo 45 minuti da quando gliele ho messe a disposizione, e gli E0 li davano in tempi random e con ordine casuale (la famosa gestione FICO delle code…) mentre almeno per gli E0 mi sarei aspettato una risposta almeno al giro successivo.
Quindi qualcosa a livello di gestione delle code di sicuro avevano…
1 Mi Piace
10 secondi di elaborazione mi sembrano spropositati… Oppure stampano le fatture xml poi le riaquisiscono con uno scanner ed alla fine usano OCR !!! 
Se ci metti anche i tempi di trasferimento alla destinazione finale forse 10sec non sono poi così spropositati… Se poi ci metti anche gli endpoint SDICOOP implementati a cavolo che rimbalzano le fatture maggiori di 25K… (per IIS + PHP Fastcgi sembra la regola) le code gli si allungano…
Certo su un modem a 14.4 è probabile
1 Mi Piace
Non è solo questione di banda ma di risposta dell’endpoint…
Vedi edit del messaggio precedente…
Dal punto di vista di SDI FTP potrebbe essere addirittura più reattivo di SDICOOP, dato che le tempistiche le definiscono loro e non devono attendere i timeout dei webserver (15 minuti) vedi:
Diciamo che SDI durante l’accreditamento su SDICOOP non ha verificato proprio tutto…
la mia stima era basata sui J2ee IBM websphere:
- ricevo una richiesta sui Javoni di front-end
- dispatch sui javoni di backend
- elaboro sui backend
- doppio salvataggio su 2 shard
- il backend notofica il frontend
- Il frontend schedula la notifica
metteteci i vari kafka rabbitmq spring struts etc…
in java 10 secondi fai presto a consumarli …
1 Mi Piace