leggendo la documentazione sto avendo difficoltà nel discernere quali siano i wsdl corretti da utilizzare per il servizio soap e gli xsd giusti. Provo a ricapitolare quel che ho capito:
Intanto dico che sto facendo riferimento all’ Allegato A - Specifiche tecniche vers 1.7.1.pdf ed il Istruzioni-per-il-servizio-SDICoop-Trasmissione-versione3.2.pdf per l’invio della fattura.
I wsdl da gestire sono
SdIRiceviFile_v1.0.wsdl (servizio soap da chiamare)
TrasmissioneFatture_v1.1.wsdl (servizio soap da esporre)
la notifica ricevuta per una fattura ha la property file di tipo base64binary. Decodificando, il messaggio sarà un xml di quale formato?
MessaggiTypes_v1.1.xsd o MessaggiTypes_v1.0.xsd oppure MessaggiFatturaTypes_v1.0.xsd (che mi sembra essere un sottinsieme del primo).
in fase di invio di una fattura .xml, quest’ultima dovrà essere encodata base64binary visto che è quello che vuole la soap action? sbaglio se dico che gli attachments sono passati in base64binary nell’xml della fattura e poi tutta la fattura viene convertita di nuovo in base64binary?
Gli allegati alla fattura stanno nell’XML della fattura stessa e sono codificati in base64.
La fattura e i messaggi sarebbero codificati in base64 nelle richieste SOAP, non fosse per il fatto che SdI usa MTOM e quindi in realtà sono binari. Mi pare (ma non ne sono sicuro) che se invii le fatture senza usare MTOM, funziona comunque, ma le richieste che fa il SdI al tuo endpoint useranno MTOM e quindi devi essere in grado di gestirle. Potrebbe essere una rogna se le librerie SOAP che usi non lo supportano (vedi per esempio .NET Core).
I wsdl da implementare sono quelli. Tutti i metodi con cui ricevi le notifiche hanno un parametro di tipo fileSdI_Type che contiene l’IdentificativoSdI della fattura a cui si riferisce il messaggio, il nome del file, e il messaggio stesso.
Fa eccezione il metodo AttestazioneTrasmissioneFattura, dove il file è uno zip, contenente il messaggio e la fattura trasmessa.
Gli xsd per i messaggi da usare sono MessaggiTypes_v1.1.xsd e MessaggiFatturaTypes_v1.0.xsd e non sono uno un sottoinsieme dell’altro. Anch’io sono stato tratto in inganno inizialmente, ma il primo contiene i messaggi relativi alle fatture PA, mentre il secondo i messaggi relativi alle fatture tra privati (motivo per cui ce ne sono di meno, perché non c’è la parte relativa alla gestione dell’accettazione e rifiuto da parte della PA).
Da notare anche che solo il messaggio RicevutaConsegna_Type ha lo stesso nome in entrambi i file, ma il namespace è diverso, quindi sono proprio due tipi diversi e come tali vanno gestiti.
Questo vuol dire che, per esempio, il metodo SOAP NotificaMancataConsegna potrebbe ricevere sia un messaggio del tipo NotificaMancataConsegna (relativo a fattura PA), che RicevutaImpossibilitaRecapito (relativo a fattura tra privati).
Mi pare il contrario.
Ad inviare serve MTOM, a ricevere no.
Su NET CORE avevo messo un pezzo di codice per aggirare l’ostacolo, ma credo che con l’unificazione in .NET sia possibile scrivere codice più pulito stile .NET 4.
Hai ragione, mi ricordavo male.
Per la trasmissione delle fatture è possibile fare la richiesta senza MTOM, ma la risposta lo usa, quindi bisogna essere in grado di gestirla.
Invece le richieste di SdI fatte al servizio TrasmissioneFatture in effetti non usano MTOM.
Non so le richieste al servizio di ricezione fatture (RicezioneFatture).