Buongiorno,
Qualcuno ha utilizzato wcf per ricevere le notifiche dell’SDI per il ws trasmissione fatture?
Il servicecontract come lo avete generato? Ho provato varie soluzioni ma visto che l’sdi non è un client WCF e le richieste SOAP (che mi arrivano correttamente) delle notifiche non vengono gestite dal mio svc.
Se qualcuno ha già avuto a che fare con questa problematica, potrebbe aiutarmi a capire come venirne a capo? Grazie mille
ciao, anch’io sono bloccato nella ricezione delle notifiche è ho implementato il webservice con WCF,
esattamente che errore rilevi?
per “service contract” intendi la configurazione del tuo svc all’interno del Web.config?
io per generare i mie sorgenti mi sono rifatto a questo: https://stackoverflow.com/questions/950150/how-to-use-a-wsdl-file-to-create-a-wcf-service-not-make-a-call
Ciao, @MarcoB4, il mio problema riguarda nella generazione proprio dell’interfaccia (ovvero il serviceContract) che ora chiamerò ITrasmissioneFatture.
Ora ho finalmente risolto. Scrivo come sono riuscito magari è utile a qualcun’altro.
In pratica generando il file ITrasmissioneFatture utilizzando il tool wsdl.exe viene generata un’interfaccia che utilizzata come service contract su un progetto WCF NON è compatibile con le chiamate SOAP dell’SDI.
Per generare il il file interfaccia corretto era necessario invece utilizzare, come hai fatto tu, svcutil.exe
svcutil TrasmissioneFatture_v1.1.wsdl TrasmissioneTypes_v1.1.xsd /language:C# /serviceContract /out:ITrasmissioneFatture.cs
All’interno di questo file ho rinominato l’interfaccia in ITrasmissioneFatture.
Una volta fatto questo nel mio progetto WCF ho fatto “Aggiungi->WCF Service” nominandolo TrasmissioneFatture.svc. A questo punto visual studio crea tre file TrasmissioneFatture.svc, TrasmissioneFatture.svc.cs e ITrasmissioneFatture.cs.
Ho poi sovrascritto interamente il file ITrasmissioneFatture.cs del progetto con quello generato precedentemente con svcutil. Quindi all’interno del file TrasmissioneFatture.svc.cs ho dato il comando “Implementa Interfaccia” che genera tutti i metodi necessari per la gestione delle richieste dell’SDI.
Fatto questo bisogna modificare il Web.config. Tutto all’interno del tag <system.serviceModel> ho modificato tutto così
<behaviors>
<serviceBehaviors>
<behavior name="SDIServiceBehavior">
<serviceMetadata httpGetEnabled="true" httpsGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="true" />
</behavior>
</serviceBehaviors>
</behaviors>
<protocolMapping>
<add binding="basicHttpBinding" scheme="https" />
</protocolMapping>
<bindings>
<basicHttpBinding>
<binding name="SDIBasicHttpBinding" messageEncoding="Text" maxBufferPoolSize="2147483647" maxReceivedMessageSize="2147483647">
<security mode="Transport">
<transport clientCredentialType="Certificate"></transport>
</security>
</binding>
</basicHttpBinding>
</bindings>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true" />
<services>
<service behaviorConfiguration="SDIServiceBehavior" name="SdiWcfService.TrasmissioneFatture">
<endpoint address="" binding="basicHttpBinding" bindingConfiguration="SDIBasicHttpBinding" contract="SdiWcfService.ITrasmissioneFatture" />
</service>
</services>
come messageEncoding ho impostato "Text"perchè pare che le notifiche dell’SDI non siano codificate con Mtom.
Ora il servizio è raggiungibile da https://tuo.dominio.ext/TrasmissioneFatture.svc
2 Mi Piace
si, esatto… come ho fatto anch’io… ora però credo sia necessario configurare i certificati, io ho aggiunto questo nel behavior
<serviceCredentials>
<clientCertificate>
<!-- SDI-Client -->
<certificate findValue="XXXZZZZZ"
storeLocation="CurrentUser"
storeName="My"
x509FindType="FindBySerialNumber"/>
</clientCertificate>
<!-- SDI-Server -->
<serviceCertificate findValue="AAABBCCCC"
storeLocation="LocalMachine"
storeName="TrustedPeople"
x509FindType="FindBySerialNumber" />
</serviceCredentials>
Però non funziona… ancora SOGEI non riesce a contattarmi correttamente, e dal suo lato ha l’eccezione: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
a te ora funziona?
Io nel Web.config del servizio WCF non ho inserito quella configurazione dei certificati. A mio avviso non serve. Per farti raggiungere da SOGEI devi installare tutti i certificati del Kit nella LocalMachine.
Poi se hosti il tuo servizio su IIS devi andare sul sito corrispondente e poi su “Impostazioni SSL” imposta il check su “Richiedi SSL” e su Certificati client “Richiedi”.
Credo…, mi corregga qualcuno se sbaglio, che la sicurezza sia rispettata, perchè provando a chiamare da browser il mio servizio da un’altra macchina con un certificato che NON ho istallato nel server di test IIS mi da correttamente 403
si, io li ho messi perchè non mi fuzionava la comunicazione da sogei, nonostante abbia installato tutti i certificati in tutti i repository possibili, ed anche configurato dentro iis con “Richiedi SSL” e Certificati Client su “Richiedi”.
Ho anche provato, dentro iis, ad abilitare il iisClientCertificateMappingAuthentication e impostarla a oneToOneMappings e poi aggiungere li i vari certificati, ma nulla.
Ma hai già creato il pfx da installare come tuo certificato server per fare andare il tuo servizio su https?
No, purtroppo coi .pfx ho avuto parecchi problemi, non sono riuscito a creare il .pfx client come spiegato qui: Installazione certificati canale SDICOOP
perchè alla fine mi generava l’errore: “No certificate matches private key”
quindi ho dovuto usare la procedura che ho descritto qui: CSR e private key - installazione certificati client/server
Il .pfx server non sono proprio riuscito a generarlo (sempre seguendo la procedura Installazione certificati canale SDICOOP)
però pensavo non fosse necessario essendoci già tutti gli altri certificati ed essendoci il certificato server SDI_XXXXX_Server.cer inviatomi da sogei,
oppure sbaglio?
No in realtà avere il giusto certificato installato su iiS, è una condizione imprescindibile perché tutto funzioni. Devi avere le chiavi private corrette con cui hai generato i csr e crearti i pfx come spiegato nella procedura qui sul forum
Confermo quel che scrive Andrea: inserire i clientCertificate e serviceCertificate nella sezione serviceCredentials non serve a niente. Va bene il web.config postato da lui poco sopra (ne abbiamo usato uno praticamente uguale anche noi).
Il “General SSLEngine problem” che Marco riscontra ha sicuramente a che fare con il certificato installato sul server che riceve le chiamate.
Perché l’autenticazione tramite certificato funzioni, è necessario procedere creando il pfx che riconcilia csr, private key e certificati forniti da Sogei in fase di accreditamento, come spiegato in altro post su questo forum (qui: Installazione certificati canale SDICOOP), e installare questo pfx sul server. Non basta installare sul server i certificati ricevuti in fase di accreditamento.
Inoltre - questo non mi sembra di averlo letto altrove nel forum, magari si dà per scontato - è necessario impostare in IIS un binding sul sito che utilizzi (di norma è il il Default Web Site), sulla porta 443, selezionando come “SSL certificate” il certificato installato (tramite pfx) sul server (dopo averlo installato, apparirà fra quelli presenti nel menu a tendina della configurazione del binding). Se utilizzi un altro certificato SSL (pur valido), o provi a impostarne due utilizzando lo SNI (Server Name Indication), non riuscirai a ricevere i messaggi dallo SDI.
O per lo meno così ha funzionato per noi.
1 Mi Piace
grazie dei chiarimenti IMITESD,
solo una cosa… il certificato (installato tramite pfx) da usare per fare il binding alla porta 443 è il certificato server, dico bene?
Ho anche il problema che ho già configurato un binding ssl al dominio impostato sul mio IIS ed è ad un differente certificato ssl che non è quello di sogei, quindi non credo di poterne impostare un’altro ,
avete per caso affrontato una situazione simile? è anche per questo che, come ho detto più sopra, volevo configurare i certificati del wcf TrasmettiFatture a livello di file Web.config.
Temo che questo sia un problema. Noi (e altri nel forum, ho letto) siamo riusciti a far funzionare la ricezione soltanto impostando nel binding ssl del sito il certificato di sogei (che appare nel menu a tendina dopo aver installato il pfx server sul server).
Potresti potenzialmente avere più binding sulla stessa porta (443) con diversi certificati, configurando l’opzione SNI (server name indication), ma per quanto riguarda la ricezione da sogei per noi non ha funzionato, e qualcuno nel forum ha scritto di aver ricevuto conferma da sogei che SNI non è supportato.
Questo in sostanza significa che devi avere un server IIS con porta 443 “libera” da dedicare al servizio di ricezione fatture/notifiche.
Se poi qualcuno riuscisse a far funzionare il servizio di ricezione con un binding differente lo faccia sapere, che può tornare utile!
Confermo… con SNI da sempre errore 500…
Siamo in test per migliorare i log interni. Ieri mattina abbiamo rigenerato alcune casistiche. Tutto il flusso ok. Dal pomeriggio, continuando coi test, non ci raggiungono più. Errore 403 sui log del SDI (e pure su IIS).
Noi non abbiamo toccato nulla ( solo parti core, stiamo migliorando i log appunto) e questa notte la notifica decorrenza dei termini, verosimilmente, non passerà.
Qualcuno ha notato disservizi simili nei giorni 20 e 21 ottobre? Cosa ci consigliate di fare?
@Andrea_Lobina grazie per questa guida, che trovo interessante. Ho fatto tutti i passi come indicato ma mi trovo con questo problema: queste due righe del web.config
<service behaviorConfiguration="SDIServiceBehavior" name="TrasmissioneFattureWcf.TrasmissioneFatture">
<endpoint address="" binding="basicHttpBinding" bindingConfiguration="SDIBasicHttpBinding" contract="TrasmissioneFattureWcf.ITrasmissioneFatture" />
mi segnalano errore in name e contract. In name mi da questo opzioni
mentre in contract mi da una lista di opzioni solo dei NS :
system.servicemodel
system.web.applicationservices
Hai un’idea di cosa possa essere visto che ne sei venuto a capo e ti complimento, io è da un mese che mi ci scorno. Grazie dell’aiuto.
Ho risolto e grazie ancora della tua guida, è stata la svolta.
come hai risolto? che valori hai messo?
Ho configurato il namespace così:
[System.ServiceModel.ServiceContract(Namespace = “http://www.fatturapa.gov.it/sdi/ws/trasmissione/v1.0”, ConfigurationName = “ITrasmissioneFatture”)]
e poi nel web.config
dove SdiWcfService è il mio namespace sotto cui ho inserito l’interfaccia
Spero ti sia utile. Io così oggi ho passato tutte i test e sono pronto ad andare in produzione. Ho ancora un po’ di codice da scrivere lato mie applicazioni ma vero SdI ci sono.
Posso chiederti come hai simulato le notifiche sei?