Web service SOAP-MTOM in PHP. Con allegati binari da centinaia di megabyte, codice nativo, no dipendenze.
SOAP non è più di moda, ma banche, assicurazioni e pubblica amministrazione lo usano ancora ovunque. E quando qualcosa si rompe, pochi sanno dove mettere le mani.
File grandi in base64 dentro l'XML saturano la memoria, superano i limiti del parser e mandano in timeout le chiamate.
Il committente invia messaggi multipart MTOM/XOP, ma il SoapServer nativo di PHP non li sa leggere.
Campi a lunghezza fissa, codifiche obbligate, validazioni imposte dall'altra parte: un errore e il messaggio viene rifiutato.
Il servizio funziona da anni, chi l'ha scritto non c'è più e ora va modificato o ha smesso di rispondere.
Implemento il servizio che il committente si aspetta, partendo dal suo WSDL e dai messaggi di esempio, oppure il client che chiama il suo.
Ricezione di allegati binari pesanti senza caricarli in memoria: il messaggio viene letto a blocchi e ogni file finisce direttamente su disco.
Conversione tra i tracciati del committente e il tuo database, con validazione e cast dei campi prima che i dati entrino nel sistema.
Analisi di integrazioni esistenti che danno errori, rallentano o vanno estese: capisco cosa fanno e le rimetto in carreggiata.
Ho progettato e scritto una piattaforma di gestione delle perizie immobiliari, in uso presso società di valutazione che lavorano per conto degli istituti di credito.
memory_limit e senza incappare nei limiti del parser XML.// Il SoapServer di PHP non gestisce multipart/related (MTOM):
// il body si legge a blocchi e in RAM resta solo l'envelope XML.
$in = fopen('php://input', 'rb');
while (!feof($in)) {
$chunk = fread($in, 1024 * 1024); // 1 MB alla volta
// riconosce i boundary MIME:
// - la parte XML (envelope) resta in memoria
// - ogni parte binaria va dritta su un file temporaneo
}
// Ogni <xop:Include href="cid:..."/> diventa un riferimento al file:
// il servizio riceve un percorso, non 150 MB di base64 in un nodo XML.WSDL, documentazione del committente e, se li hai, messaggi di esempio o log degli errori.
Ti dico cosa serve, quanto tempo richiede e quanto costa, prima di iniziare.
Il servizio viene provato con messaggi reali, allegati pesanti compresi, prima di andare in produzione.
Codice tuo, documentato, con le istruzioni per gestirlo. Se serve, resto disponibile per la manutenzione.
No. SOAP nasce proprio per far parlare sistemi diversi. Io lavoro sul lato PHP; il committente può usare qualunque tecnologia, purché rispetti il contratto definito dal WSDL.
Sì. Spesso basta capire cosa non torna tra il messaggio inviato e quello atteso. Si parte dai log e da un paio di messaggi reali.
Con la lettura in streaming la memoria usata non dipende dalla dimensione del file: il limite diventa lo spazio su disco e la durata massima della richiesta impostata sul server.
Sì, ma questa pagina parla di SOAP perché è lì che di solito le aziende restano senza qualcuno che sappia mettere le mani sul codice.
Con chi devi parlare, cosa si scambia e dove si blocca. Ti rispondo con una prima valutazione.