In un progetto su cui sto lavorando mi trovo in una situazione un po' anomala i cui risvolti però sono molto comuni. La mia applicazione è composta da una UI che invoca dei servizi WCF i quali a loro volta invocano dei servizi JAVA. Dei servizi JAVA in realtà ho solo il WSDL esposto e non un vero servizio. In fase di sviluppo, i servizi WCF simulano la chiamata ai servizi JAVA e restituiscono semplicemente dei fake.

Come si può immaginare, quando andiamo a integrare i servizi WCF con quelli JAVA, possono sorgere problemi dovuti non al colloquio tra i due mondi, bensì dal fatto che da dati fake si passa a dati reali e quindi possono sorgere casistiche non previste. Poichè l'integrazione avviene su macchine di staging su cui non ho accesso, quando si verifica un'eccezione l'unica cosa che posso fare è prendere l'envelope SOAP che genera l'eccezione (attraverso il log di WCF), scrivere lato WCF il codice che genera lo stesso messaggio e poi fare il debug sulla mia macchina. Finchè i messaggi sono di piccole dimensioni, scrivere questo codice è semplice, ma quando abbiamo liste di oggetti con proprietà complesse annidate, il compito diventa molto arduo.

In questi casi, esiste santo Fiddler che ci può venire incontro con la sua fantastica feature "AutoResponder". Tramite questa feature possiamo dire a fiddler che a fronte di una chiamata a un determinato url o dove il body della richiesta contiene una determinata chiave, lui deve rispondere direttamente con il contenuto di un file senza invocare realmente l'url richiesto. Tornando al mio caso, io posso dire a Fiddler che a fronte di una chiamata a una specifica SOAPAction del mio servizio WCF, lui non deve invocare il servizio, bensì rispondere con il messaggio con cui si genera l'eccezione. In questo modo, per me debuggare le eccezioni sul client diventa semplice e non devo scrivere codice per creare i fake lato WCF ogni volta.

Ora però basta chiacchiere e vediamo velocemente come fare quanto esposto.

1. Selezionare il ta AutoResponder nella parte destra dell'applicazione;
2. Abilitare i check "Enable automatic responses" e "Unmatched requests passthrough" (il primo abilita le risposte automatiche e il secondo specifica che se l'autoresponder non può fornire una risposta automatica, allora fiddler deve invocare l'url);
   
3. In basso nella prima textbox della sezione Rule Editor specificare il parametro in base a cui si vuole fornire una risposta automatica. Nel mio caso io dovevo intercettare una SOAP Action quindi ho inserito questa regola: Header:SOAPAction="http://myapp.com/mt/v1/mta/searchData";
4. Nella seconda textbox inseriamo il nome del file che contiene la risposta che vogliamo restituire al client. il file deve contenere sia le intestazioni HTTP che il body che nel mio caso è l'envelop SOAP);
5. Cliccare il tasto Save.

A questo punto, a ogni chiamata fiddler verifica se nelle header della richiesta sia persente l'intestazione "Header:SOAPAction" e se il suo valore è "http://myapp.com/mt/v1/mta/searchData". In caso positivo apre il file che abbiamo impostato, e ne restituisce il contenuto al client, in caso negativo manda avanti normalmente la richiesta.

Il bello di questa tecnica è che è applicabile a qualunque tipo di chiamata HTTP, sia questa verso un servizio WCF, una WebApi o un qualunque sito o altro ancora. Ovviamente anche il client può essere di qualunque tipo (WebServer, Browser, App Windows 8 o Windows Phone 8 o altro ancora). Bello no?

Stay Tuned...