Devo implementare un Web Service per trasmettere (e ricevere) le fatture elettroniche dal nostro gestionale verso l’SDI, potete darmi qualche dritta? Il nostro software è stato sviluppato con tecnologie .NET quindi pensavo di utilizzare C# oppure VB.NET. Ho provato ad esaminare la documentazione e a compilare il form per la richiesta di accreditamento del canale, ma non sono riuscito a completare la domanda in quanto occorre aver già predisposto gli indirizzi degli endpoint.
Dal 2019 tutti i software gestionali dovranno trasmettere e ricevere le fatture in questo modo quindi penso che questo thread sarà utile a molti soggetti.
Ho notato che è richesta la creazione di un Web Service con alcuni requisiti fra cui utilizzo del protocollo HTTPS, SOAP, MTOM, WSDL.
Il link alla pagina per la richiesta di accerditamento del canale è la seguente:
La prima domanda è: visto che per la comunicazione fra i due servizi Web è richiesta l’autenticazione ed autorizzazione basata sull’utilizzo di certificati, occorre disporre di un server (nel mio caso di tipo IIS) che permetta di caricare dei certificati personalizzati. Conoscete un provider che consenta di gestire in autonomia i certificati associati ai siti in hosting? Probabilmente l’unica soluzione è noleggiare un “server dedicato” oppure attrezzarsi con un server interno dedicato allo scopo. Che ne pensate?
Chi ha già risolto lo scoglio della scelta del server e dell’autenticazione può dare qualche consiglio?
Le istruzioni per l’implementazione del Web Service sono raggiungibili da questo link:
Non ho molta esperienza con l’utilizzo dei Web Service e quindi vi richiedo se disponete di qualche stralcio di codice C# oppure VB.NET da utilizzare come punto di partenza.
Ringrazio anticipatamente chiunque voglia dare il suo prezioso contributo.
gestire in proprio la comunicazione con i web service del sistema di interscambio è sicuramente una possibilità, ma potresti voler prendere in considerazione di utilizzare un intermediario che si occupi della trasmissione e della ricezione delle fatture elettroniche mediante un sistema specializzato che poi espone delle API più semplici da utilizzare verso il tuo software.
Normalmente questi intermediari si occupano anche di alcuni servizi accessori necessari per il trattamento delle fatture elettroniche, come la firma digitale sulla fattura o, ancora più importante, la conservazione a norma dei documenti scambiati.
Disclaimer: gestisco uno di questi servizi e non voglio usare il forum per farmi (troppa) promozione. Ti suggerisco di fare una ricerca per confrontare le varie opportunità che ci sono sul mercato e le relative caratteristiche tecniche.
Dal punto di vista tecnico dovresti poter generare facilmente il client e lo stub del server per i web service del sistema di interscambio in .NET usando WSDL Tool. Io ho fatto una cosa analoga, ma in Java.
I servizi, di per se, sono molto semplici perché le chiamate servono in pratica solo per inviare un file allegato (perciò il requisito MTOM).
Riguardo alla mutua autenticazione TLS, ti può essere utile sapere che da alcuni mesi SOGEI ha attivato il protocollo SNI nelle chiamate verso i servizi per cui puoi configurare l’indirizzo del web service anche su un server che condivide la porta 443 con altri indirizzi. Non è ammesso, invece, usare porte diverse dalla 443.
@digital.solutions per caso hai risolto il problema? io ora mi trovo nella tua stessa situazione di gennaio? avresti per favore delle dritte da darmi??
Anche noi stiamo cercando di accreditare il canale per integrare il nostro gestionale sviluppato con .net e abbiamo delle difficoltà, qualcuno che ha del codice vb.net, c# da usare come base di partenza?
In particolare non è chiaro come usare i certificati contenuti nel kitditest.zip
Provando a chiamare il web service RiceviFile otteniamo:
System.ServiceModel.Security.SecurityNegotiationException: Impossibile stabilire un canale sicuro per SSL/TLS con l’autorità ‘testservizi.fatturapa.it’. —> System.Net.WebException: Richiesta annullata: Impossibile creare un canale sicuro SSL/TLS…
in System.Net.HttpWebRequest.GetResponse()
in System.ServiceModel.Channels.HttpChannelFactory`1.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)
— Fine della traccia dello stack dell’eccezione interna —
Buongiorno a tutti,
ho accreditato il canale usando .net con un webservice .asmx . Per usare al meglio la comunicazione tramite mtom vorrei cancellarlo e rifare l’accreditamento per un service wcf, in attesa di cancellare il primo. Questa situazione potrebbe creare problemi di compatibilità tra i certificati? Qualcuno ha attivato più di due webservice in contemporanea?
Ciao Stefano,
ma siamo veramente sicuri che Sogei abbia attivato l’SNI?C’e’ una documentazione ufficiale a riguardo che tu sappia?
Per quanto mi riguarda, ho testato settimana scorsa durante i test di accreditamento e l’SNI non era supportato. Forse lo è solo per l’ambiente di produzione?
Avere la certezza di questa cosa è importante, un conto è un hosting web condiviso, un altro è dedicare un IP ad un solo utente.
Grazie mille.
Saluti.
quando ho scritto la risposta in cui faccio riferimento a SNI era da poco capitato un problema con il mio canale (con IP dedicato) per cui arrivavano degli header SNI errati che facevano fallire la comunicazione.
In seguito alla segnalazione al supporto il problema è stato corretto e l’assistenza mi ha confermato di aver corretto gli header SNI.
Da qui la mia supposizione che SNI fosse stato abilitato. Tuttavia in seguito ho tentato di spostare il canale su un indirizzo condiviso e non ha funzionato finché non ho ripristinato l’IP dedicato.
Perciò credo tu abbia ragione: probabilmente SNI non è ancora attivo per le chiamate che arrivano dal sistema di interscambio.
Non ho notizie recenti su eventuali modifiche al riguardo.
Ciao,
ho chiesto all’assistenza ed ecco la risposta (che poi è da interpretare):
Gentile utente,
se nella ricezione delle notifiche dal Sistema di Interscambio prende errore: RC107: Endpoint is not connected, le suggeriamo di verificare di non aver impostato lo SNI sul proprio server in quanto nonsupportato dal Sistema di Interscambio. Se l’errore fosse diverso la preghiamo di fornirci ulteriori dettagli per poterla aiutare.
Francamente io non ricordo che tipo di errore ottengo sul pannello di gestione canale in questi casi, dovrei riprovare.
Saluti.
Strano che abbiano risposto così perché l’sni è un impostazione del web server per ‘hostare’ multipli certificati con lo stesso ip e permette così l’handshake con il certificato corretto. Sdi comunica con l’endpoint indicato nella sottoscrizione quindi se nell’sni è indicato correttamente l’handshake non dovrebbe avere problemi. Confermo che in ambiente di test non funziona
precisi che non lo supporta il server di “test”: fai questo perchè non sai nulla di quello ufficiale o perchè invece sai che quello di produzione al contrario lo supporta?
Non ho ancora avuto modo di verificare con il server di produzione, perché per provare dovrei impostare i certificati, aspettare una fattura o una notifica e vedere se arriva.
Alcuni utenti sul forum sostengono che Sogei gli abbia comunicato che il server di produzione supporta SNI, ma non ci sono informazioni ufficiali in merito.
Infatti, io non rischierei di perdere fatture o messaggi solo per fare questa verifica. Avendo dovuto comunque configurare le cose in un certo modo per i test, tanto vale usare la stessa configurazione in produzione.
Che poi, se usano dei client diversi in test e in produzione, a che servono i test? Lo scopo dei test è verificare di essere in grado di comunicare col SdI. I due sistemi dovrebbero essere il più possibile simili.
[quote=“stefanotravelli, post:2, topic:2026, full:false”]
…potresti voler prendere in considerazione di utilizzare un intermediario che si occupi della trasmissione e della ricezione delle fatture elettroniche mediante un sistema specializzato che poi espone delle API più semplici da utilizzare verso il tuo software…[/quote]
Buongiorno Stefano, potresti per cortesia darmi qualche indicazione in merito (senza fare nomi)? Se ho ben capito ci sono dei servizi che espongono API alle quali posso accedere dal mio codice sorgente per gestire tutto il processo di fatturazione?
Grazie.
Per esempio noi forniamo un servizio che espone tutti i servizi del Sistema di Interscambio tramite API REST, cioè semplici URL da chiamare in HTTP POST, dal proprio codice o dalla linea di comando.
I nostri clienti non hanno avuto bisogno di accreditarsi, di attendere i tempi del sito FatturaPA o di installare i certificati, sono diventati operativi immediatamente.
Quando i clienti l’hanno chiesto, siamo stati in grado di intervenire direttamente sul codice del loro gestionale per effettuare l’integrazione del servizio.
