Salta la navigazione
Nell´Azienda Ospedaliera di Desenzano del Garda durante la fase di consolidamento prevista dal progetto SISS è stato richiesto di integrare l´applicazione di Pronto Soccorso con l´applicazione RIS per le richieste di prestazioni in regime di urgenza.
In questo caso reale il progetto di integrazione prevedeva l´integrazione delle due applicazioni, realizzando due adattatori uno per ogni applicazione da e verso il middleware di integrazione.
Figura 4: Progetto di integrazione
Con questo tipo di soluzione è molto importante decidere fin da subito la metodologia di integrazione tra l´applicazione il middleware, se web service, data base o altro, oltre che al formato dei dati e dei messaggi da scambiare.
L´adattatore in questo modo si limita a "passare" i dati da e verso il middleware di integrazione aggiungendo eventualmente delle funzioni di conversione da un formato ad un altro , ovviamente tutto questo si riflette pesantemente sulla applicazione in quanto è proprio quest´ultima che deve gestire i dati e gli eventi da e verso l´adattatore.
Dettaglio
Con questo tipo di integrazione , l´applicazione si deve integrare con l´adattatore intervenendo pesantemente sul codice e sugli eventi .
Figura 5: Integrazione tra applicativo e middleware
L´adattatore si limita a prendere in carico il messaggio ( in formato XML o HL7 ) per inoltrarlo alla applicazione destinataria. La costruzione del messaggio è compito della applicazione inviante.
Figura 6: Funzionamento dell´adattatore
Ad un messaggio inviato deve corrispondere un messaggio di risposta per accettazione o rifiuto della transazione.
In molti scenari l´applicazione inviante può diventare anche ricevente e quindi è necessario che l´integrazione con l´adattatore preveda anche la ricezione dei messaggi con tutta la complessità che ne consegue ( aggiornamento tabelle nel database , messaggio di risposta , ecc.).
Figura 7: Invio di un messaggio
Figura 8: Messaggio di risposta
Aumento della complessità
A livello dell´applicativo le cose sono ancora più complesse, per ogni evento locale a cui deve corrispondere l´invio di uno o più messaggi HL7 è necessario implementare la logica di costruzione di ogni messaggio XML oltre che quella di integrazione con l´adattatore ( in funzione della metodologia adottata per lo scambio di messaggi , Web services , file system , data base , ecc.).
Figura 9: Flusso e conversione dei dati
L´alternativa è progettare un adattatore molto complesso in grado di gestire diversi messaggi sia in ingresso che in uscita con le opportune logiche di conversione ( XML verso HL7 e viceversa) , questo comporta per l´applicativo dover gestire strutture XML molto complesse.
I numerosi tag XML conterranno tutti i campi che verranno interpretati e mappati nei corrispondenti campi HL7 dall´adattatore.
Figura 10: Mappatura dei campi
In pratica questo tipo di soluzione consente di integrare applicazioni affrontando la problematica in modo che lo scenario, i messaggi da scambiare, l´applicazione, la metodologia di integrazione, l´adattatore siano tutti visti come un unico oggetto, inscindibile.
Una variazione nello scenario , come l´uso di un nuovo messaggio in alternativa ad uno deprecato, un nuovo campo non previsto, una diversa metodologia di integrazione dovuta alla sostituzione della applicazione , comporta sicuramente pesanti modifiche sull´adattatore oltre che nell´applicazione.
Figura 4: Progetto di integrazione
