Finora ho realizzato applicazioni Mirth che leggevano da servizi web. E’ interessante anche sapere che i web service si possono fare con Mirth. Il contesto è questo: un’azienda “periferica” produce una informazione (ad esempio: un laboratorio che produce l’analisi di un campione di sangue) e il dato deve essere trasmesso all’azienda “madre” perché lo registri nel suo gestionale. L’azienda madre realizza un servizio web che verrà chiamato dal laboratorio il quale spedirà al servizio il referto con un messaggio HL7. All’arrivo del messaggio l’azienda madre esegue il parsing del messaggio e salva i dati nel gestionale (un database relazionale).

Nella fattispecie il messaggio viene “affettato” a righe e viene salvata una intestazione e una serie di dettagli collegati, uno per ogni riga del messaggio.

L’impianto è questo:

Il source

Il source è un SOAP listener che risponde con un WDSL che Mirth stesso genera e che mette a disposizione un metodo standard detto acceptMessage() (teniamo d’occhio ma per il momento soprassediamo sulla casella di selezione Respond from)

Le destination

Le destination sono parecchie perché la lavorazione del messaggio è piuttosto laboriosa: devo capire il tipo di messaggio (che leggo nell’intestazione del messaggio stesso) e a seconda di questo compiere diverse operazioni: per messaggi di un tipo estraggo dal file HL7 un file PDF che salvo nel NAS, e poi, in ogni caso, devo salvare in una tabella Oracle una intestazione e in una tabella figlia tutte le righe del messaggio numerandole e collegandole alla testata con un vincolo di chiave esterna:

Un passetto in più: lo script

Per questo tipo di applicazione devo personalizzare lo script che viene eseguito una volta eseguita l’applicazione del canale: con questo personalizzo la risposta del web service al programma che lo ha chiamato. Nelle figure precedenti si possono vedere questi punti in ciascuna delle 4 tab superiori.

Anche se ci sono diversi prodotti già attivi all’interno di Mirth per eseguire ognuna di queste operazioni atomiche, per convenienza o per forza alcune cose me le sono dovute scrivere a mano in JavaScript utilizzando classi embedded di Mirth, come la classe DatabaseConnectionFactory. Per esempio mi serviva eseguire una lettura di Oracle in una delle destinazioni, ma nelle destination non si può selezionare il tipo di connettore DatabaseReader che invece si può richiamare dal source. Quindi me lo sono fatto a mano. Inoltre, pur essendo possibile selezionare dei tipi di connettori standard che sono anche semplici da usare (ad esempio: FileWriter: gli passo la directory, il nome del file e il contenuto e lui me lo scrive dentro il filesystem), alcuni tipi di connettori dovevano comportarsi in modo non standard, ma Mirth è programmabile! per cui ho potuto estendere le funzionalità scrivendo i programmi a mano.

Per me, che non sono tanto in confidenza con il Java, scrivere in JavaScript (che è un po’ meno rigido del Java) in modo così approfondito è stata comunque un’esperienza formativa.

Alla fine di questo lavoro – salvare i dati – bisogna rispondere al software che ha chiamato il servizio e: come si fa? Non lo so.

Ho usato per la prima volta la quarta TAB (Scripts). Ho selezionato “Postprocessor” nella select Script in alto (vedi figura), ho definito una serie di variabili e una istruzione di scrittura nel log, e poi se la variabile di canale error è valorizzata (e, se succede qualcosa, la valorizzo nelle destinazioni precedenti – esse vengono eseguite nell’ordine una alla volta), istanzio un tipo di risposta altrimenti un’altra.

Il cuore di tutto è l’oggetto di Mirth responseMap che mi permette di modificare quel messaggio di risposta del metodo di default acceptMessageResponse che avevamo lasciato in sospeso nel primo punto. Il valore che questa variabile può assumere non è una stringa ma un oggetto che viene inizializzato dal metodo ResponseFactory.getSuccessResponse(ack) in caso di OK, oppure dal metodo ResponseFactory.getFailureResponse(ko) in caso di KO (ack e ko invece sono due stringhe che definisco io all’inizio dello script). La presenza dell’istruzione responseMap.put() in questo script mi fa comparire la voce acceptMessageResponse nella tendina di selezione Respond from del source! Il tutto è riportato in figura:

Come ultimo passaggio ecco come si presenta la chiamata al WS fatta da soapUI (a sinistra) e la response del servizio (a destra):

Di soapUI ne parlo più avanti. Buona questa risposta nel forum di Mirth