Torna a Webservices

Mirth

Spread the love

Indice

Mirth Connect

Generalità

Una piattaforma per l’installazione e l’esecuzione di web services, e il collegamento con basi dati in lettura/scrittura, che parla nativamente il linguaggio HL7.

Installazione di Mirth Connect

Prerequisito: installazione della JVM

L’installazione non partirà nemmeno se l’installer non avvertirà la presenza di Sun JDK. Ho provato anche con OpenJDK, ma non c’è verso.

Nel nuovo OS Ubuntu 12.04 ho installato la Java Virtual Machine come descritto in Java#Nuovo_OS Quando si avvia l’interfaccia di comunicazione con Mirth, selezionare:

 Altro > immettere /usr/local/lib/jre1.7.0_04/bin/javaws

e dare INVIO

Prerequisito: installazione del driver JDBC Oracle

Scaricare un driver jdbc che si vuole dal sito dell’Oracle. Io ad esempio ho scaricato l’Oracle Thin Client per Oracle 10.2 e all’interno c’era già il file ojdbc14.jar.

Nella mia installazione il file con la libreria Java jdbc l’ho messo in

 /opt/oracle/instantclient_10_2

dove si trovano anche i tnsnames; questo percorso va inserito nella variabile di ambiente CLASSPATH:

  $ CLASSPATH=/opt/oracle/instantclient_10_2

Nota bene

Il client Oracle serve affinché i servizi possano interagire con un DB relazionale.

Anche Mirth stesso scrive le sue configurazioni in un database, e si può configurare una serie di db relazionali molto usati: MySQL, PostGRES, Oracle affiché esso salvi tutti i parametri per il suo funzionamento.

Mirth “out-of-the-box” utilizza un Db con poche pretese, giusto per valutare il prodotto: Apache Derby.

Istruzioni per l’installazione di Mirth

Scaricare il paccozzo mirth-1.8.2.4472.1351-linux-installer.bin dal sito Mirth Corporation. è la versione 1.8.2.

Il download può durare un pochino, sono 85 MB. Al termine portarsi nella direcory di download e

 $ sudo -s
 # chmod +x mirth-1.8.2.4472.1351-linux-installer.bin
 # mkdir /opt/Mirth
 # chown marcob:marcob /opt/Mirth
 # ^D
 $ ./mirth-1.8.2.4472.1351-linux-installer.bin [INVIO]

L’installazione ci mette un pochino. Alla fine, punto il browser su http://localhost:8080/, compare la pagina seguente:

Schermata-Launch_Mirth_Connect_Administrator_2.1.0.5389-Mozilla_Firefox

Cliccare sul pulsante verde. A questo punto potrebbe presentarsi un problema: è descritto qui assieme alla sua soluzione.

Attenzione!

Questo dopo l’installazione. Ma nelle volte successive, occorre

  1. lanciare Mirth a mano
     $ cd /opt/Mirth
     $ mirth<invio>
  2. puntare il browser nella Mirth Home Page
  3. cliccare sul pulsante verde, compare la login

Login

Se il problema non c’è o è stato risolto, appare la maschera di login:

Schermata-Mirth_Connect_Administrator_-_Logindigitare user = pass = admin

Mirth all’opera

Primo accesso

Viene subito chiesto di cambiare (si è obbligati!) la password di amministratore (di default è sempre admin/admin)

Dashboard (cruscotto)

Il cruscotto raccoglie informazioni e controlli sui principali oggetti di Mirth che sono i Canali.

Un canale è un insieme di funzioni che generalmente costituiscono una applicazione completa.

Una canale è un’operazione composta. Ad esempio

  • lettura database
  • costruzione busta XML con il messaggio
  • invio della busta al web service in ascolto
  • processo del messaggio ritorno (update database con il risultato della invocazione del WS remoto)

Ma il processo può anche essere rovesciato e cominicare con l’ascolto da un servizio per poi scrivere su database.

Channels (Canali)

Cominciamo subito a creare un canale. Si tenga a mente che si fa sempre prima una lettura e poi una scrittura. In realtà accanto alla lettura ci può essere qualche scrittura di contorno ma il canale inizia sempre con un input e finisce con un output.

Cliccare sulla sinistra Channels nel menu Mirth Connect, in alto. Poi cliccare su New Channel nel menu Channel Tasks.

Compare la scheda Edit Channel nella quale compaiono 4 sotto schede:

  • Summary (nella quale scriviamo subito il nome del canale)
  • Source in cui descriveremo da dove e come il servizio legge i dati da spedire
  • Destinations in cui descriveremo dove deve andare il messaggio e
  • Scripts che è speciale (mi sembra serva a scrive il codice Java che incorpora i dati letti dalla Source dentro l’XML da sparare, in sostanza elaborazioni in itinere lungo il canale).
Source

Nel tab Source possiamo definire ad esempio che i dati da spedire vengano letti da una tabella Oracle (ma nativamente possiamo farlo anche da MySQL, Postgres e SQL Server, o da un altro webservice).

Scelgo Oracle 10g Release 2 nel Driver. Poi per suggerire cosa devo scrivere, premo su Insert URL Template e scrivo

 jdbc:oracle:thin:@192.168.0.2:1521:XE

ho sostituito

  • host con 192.168.0.2 (ma in /etc/hosts avevo la riga
 192.168.0.2   bach

per cui ho sostituito host con bach)

  • port con 1521
  • database con XE
Errata

per sapere cosa scrivere qui, fare riferimento al file $ORACLE_HOME/tns/tnsnames.ora in cui c’è il nome del database e la porta ed il nome del server. Nel mio caso

 BACH =
 (DESCRIPTION =
   (ADDRESS_LIST =
     (ADDRESS = (PROTOCOL = TCP)(HOST = bach)(PORT = 1521))
   )
   (CONNECT_DATA =
     (SID = XE)
   )
 )
Corrige

NON si deve fare riferimento al TNS se si usa il thin client! Si usano le informazioni scritte dentro al tnsnames.ora ma in un altro modo. Esempio che calza meglio

 SVIL.MASTER.DOMAIN.IT =
 (DESCRIPTION =
   (ADDRESS = (PROTOCOL = TCP)(HOST = dbsvila.mydomain.it)(PORT = 1521))
   (CONNECT_DATA =
     (SID = svil)
   )
 )

Qui il nome del TNS è diverso dal nome fisico della macchina (questa particolarità nel precedente esempio mi aveva indotto in errore)

  • nome fisico: dbsvila.mydomain.it
  • nome TNS: SVIL.MASTER.DOMAIN.IT

se si usassero i client OCI la stringa di connessione sarebbe

 jdbc:oracle:oci:username/password@SVIL.MASTER.DOMAIN.IT

ma dovendo usare il client THIN la stringa di connessione è

 jdbc:oracle:thin:@dbsvila.mydomain.it:1521:svil

Il risultato è il seguente (premere il tasto Select):

Schermata-SQL_Creation

Questa finestra serve per costruire le query di selezione; ad esempio se scelgo AMMORTAMENTI (e il check si propasga di default a tutti i campi della tabella AMMORTAMENTI) la query che viene scritta è questa:

  SELECT
     AMMORTAMENTI.ID AS AMMORTAMENTI_ID,
     AMMORTAMENTI.DESCRIZ AS AMMORTAMENTI_DESCRIZ,
     AMMORTAMENTI.AMMORTAMENTO AS AMMORTAMENTI_AMMORTAMENTO,
     AMMORTAMENTI.ANNI AS AMMORTAMENTI_ANNI,
     AMMORTAMENTI.FLAG_INV AS AMMORTAMENTI_FLAG_INV
  FROM
     AMMORTAMENTI;
In caso di errore

Se premo sul pulsante Select mi esce l’errore

Schermata-Error

Nota che nel caso bach (in cui host fisico e tns hannno lo stesso nome) esce questo errore ma il connettore invece funziona…

Ora, sempre nella tab Source vado nella casella di testo SQL e digito la query che estrarrà i dati da incartare nell’XML e spedire (o salvare); nel mio esempio:

  select * from ricevute.ricevute

nello schema ricevute, c’è una tabella ricevute: le leggo tutte.

Non è finita! Occorre sempre definire un Transformer per ogni connettore. Nel Transformer si dice come si presentano i dati uscendo dal DB (Inbound) e come li consegno al servizio (Outbound).

L’XML di Outbound della Source diventa l’XML di inbound della Destination

Destinations

Qui, dopo aver detto come leggere. diciamo come scrivere. La cosa più semplice è scrivere in un file i dati letti. Mirth li scriverà in un formato XML di default. Ad esempio potrà scrivere un testo del tipo:

 <?xml version="1.0" encoding="UTF-8" standalone="no"?>
  <result>
   <id>103500</id>
   <iddipartimento>11</iddipartimento>
   <pagante>Giuseppe Garibaldi</pagante>
   <data>2011-06-03</data>
   <importo>12</importo>
   <idtipopagamento>1</idtipopagamento>
   <idstorno/>
   <idutente>285</idutente>
   <flag_storno>0</flag_storno>
   <numero>1</numero>
  </result>

Per fare questo dobbiamo

  • scegliere il Connector Type che in questo caso sarà File Writer;
  • poi scriviamo la Directory (es. /tmp/) e controlliamo se Mirth ci può scrivere dentro cliccando su Test Write;
  • scriviamo il file name (es. file.txt)
  • cosa dobbiamo scrivere dentro al file? abbiamo molte scelte sulla destra (Destination Mappings), io ho scelto Transformed Data (si fa Drag & Drop dentro la casellina Template) che in sostanza scrive i dati letti dalla tabella Oracle trasformati in XML.

Ora che ci penso, vado a vedere cosa c’è dentro a /tmp/file.txt:

 -rw-r--r-- 1 marcob marcob 500544 2011-06-16 16:59 /tmp/file.txt

Opssss… il file cresce è già a mezzo mega.

Ci credo! Ogni 5 secondi fa una scansione della tabella e scrive nel file (in append). Posso regolare l’intervallo di tempo tornando nella scheda Source e impostando Polling Frequency (ms) ad un valore più alto (c’è scritto 5000, metto 50000: sono millisecondi, quindi 5000 = 5 s).

Possiamo anche riscrivere ogni volta il file ex novo (invece di andare in append): scheda Destinations, radio button Append to File.

Destinazioni diverse da file locali

La parte più interessante è la comunicazione con end point sul web.

  • Cliccare su New Destination
  • scegliere Connector Type = HTTP Sender
  • scrivere l’url dell’end-point (vedi articolo sui web services): sarà per me http://PROVAX00X00X000Y:Salve123@jsbach/inps/
  • sulla destra in basso, sulle Destination Mappings, si troveranno anche i campi estratti dalla Query SQL impostata nel Reader
  • Per tutti i campi che interessano, cliccare su New delle Reqeust Variables, scrivere il nome concordato nel WSDL dell’end point, e trascinare il nome dalla lista di sinistra dentro alla colonna di destra (Value).
  • se il campo è composto, usare i Transformed Data.

Insomma qui c’è ancora molto da imparare.

Usare SOAP sender

Non so che differenza ci sia, ma con SOAP sembrerebbe più semplice. Bisogna caricare il file WSDL con la descrizione del servizio; caricato il file e premendo il pulsante Import Functions si ottiene l’elenco delle funzioni incluse nel servizio. A me non funziona, ma sembra così.

Esempio

La Source ha la connessione jdbc, la query: tutto a posto, fin qui ci ero arrivato da solo

Nelle Destinations sono indicate tre destinazioni:

  • file: è la destinazione che per ogni invocazione del canale scrive i dati da spedire nel FS locale, come log
  • http: è l’invocazione del ws remoto: avviene con il metodo http_sender (non SOAP sender) ma ha questi dati:
<soapenv:Envelope
	xmlns:inv="http://inviocertificatorequest.xsd.cert.appsrv.remotedomain.it"
	xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
	xmlns:tip="http://tipicert.xsd.cert.appsrv.remotedomain.it">
<soapenv:Header>
	<wsse:Security soapenv:mustUnderstand="0" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
          <wsu:Timestamp wsu:Id="Timestamp-1" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
             <wsu:Created>2011-06-15T10:32:18.681Z</wsu:Created>
             <wsu:Expires>2011-06-15T10:33:18.681Z</wsu:Expires>
          </wsu:Timestamp>
       </wsse:Security>
    </soapenv:Header>
    <soapenv:Body>
       <inv:InvioCertificato>
          <inv:medico>
             <!--Optional:
             <tip:codiceFiscale/>-->
             <!--Optional:-->
             <tip:pincode>1234567890</tip:pincode>
             <tip:codiceRegione>100</tip:codiceRegione>
             <tip:codiceAsl>102</tip:codiceAsl>
          </inv:medico>
          <inv:lavoratore>
             <tip:codiceFiscale>AAXAAA00A50H5L1O</tip:codiceFiscale>
          </inv:lavoratore>
          <inv:residenzaODomicilioAbituale>
             <tip:via>VIA DEI MULINI 12</tip:via>
             <tip:cap>36070</tip:cap>
             <!--Optional:-->
             <tip:codiceCatastale/>
             <!--Optional:-->
             <tip:comune/>
            <!--Optional:-->
             <tip:provincia/>
          </inv:residenzaODomicilioAbituale>
          <!--Optional:-->
          <inv:indirizzoDiReperibilita>
             <!--Optional:-->
             <tip:cognome/>
             <!--Optional:-->
             <tip:indirizzo>
                <tip:via>VIA DEI MULINI 12</tip:via>
                <tip:cap>36070</tip:cap>
                <!--Optional:-->
                <tip:codiceCatastale/>
                <!--Optional:-->
                <tip:comune/>
                <!--Optional:-->
                <tip:provincia/>
             </tip:indirizzo>
          </inv:indirizzoDiReperibilita>
          <inv:certificato>
             <tip:dataRilascio>2011-06-15</tip:dataRilascio>
             <tip:dataInizio>2011-06-15</tip:dataInizio>
             <tip:dataFine>2012-06-15</tip:dataFine>
             <tip:visita>A</tip:visita>
             <tip:tipoCertificato>I</tip:tipoCertificato>
             <!--Optional:-->
             <tip:codiceDiagnosi></tip:codiceDiagnosi>
             <!--Optional:-->
             <tip:noteDiagnosi></tip:noteDiagnosi>
          </inv:certificato>
       </inv:InvioCertificato>
    </soapenv:Body>
 </soapenv:Envelope>

Come generare questo tracciato XML? usando [1].

Per poter inserire i valori letti dal database all’interno dei segnaposto nel file xml di cui sopra è necessario che per ogni canale sia creato un Transformer:

    • da SoapUI chiamare il servizio a cui ci si vuole rivolgere
    • SoapUI ritornerà l’XML: copiarlo e incollarlo
    • Recuperare l’XML con cui viene prodotta la lettura del database (Source > Edit Transformer > Message Templates (nella scheda sulla destra))
  <?xml version="1.0" encoding="UTF-8" standalone="no"?>
   <result>
     <codfisc>value</codfisc>
     <pincode>value</pincode>
   </result>
    • incollarlo dentro a Destinations > Edit Transformer > Message Templates (nella scheda sulla destra)
    • cliccare su Add New Step, in variable scrivere codfisc
    • cliccare su Messag Tree sulla scheda destra, aprire l’albero e trascinare il valore dentro la casella Mapping
    • ripetere per tutte le altre variabili
    • Così facendo appariranno i nomi delle variabili sulla tab Destination Mappings nella pagina elenco delle Destinations
    • Trascinare le variabili dentro al valore del $payload come evidenziato nel frammento che segue (è il valore della variabile $payload):
 <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:int="http://interrogazionelavoratorerequest.xsd.cert.appsrv.remotedomain.it">
   <soapenv:Header/>
   <soapenv:Body>
      <int:InterrogazioneLavoratore>
         <int:pincodeMedico>${pincode}</int:pincodeMedico>
         <int:codiceFiscale>${codfisc}</int:codiceFiscale>
      </int:InterrogazioneLavoratore>
   </soapenv:Body>
 </soapenv:Envelope>
  • la terza destinazione (file_risultato) è la scrittura dei risultati della response in un file.

E alla fine: installazione del canale

Ora, per “deployare” il servizio occorre

  • salvare (Channel Tasks > Save Changes)
  • Validare il connettore (Channel Tasks > Validate Connector)
  • cliccare su Mirth COnnect > Channels
  • Cliccare su Channel Tasks > Deploy All

il servizio parte! Se si torna al cruscotto, in basso sulla tab Server Log si dovrebbe leggere

  [2011-06-16 16:37:47,949]  INFO  (com.webreach.mirth.connectors.jdbc.JdbcMessageReceiver:356):
Successfully connected to: jdbc://query

e se si clicca sulla tab Dashboard Status Panel si dovrebbe leggere un elenco di eventi che testimonia, ad esempio nel mio caso, la successione di eventi Source: Database reader (XML -> XML) e Destination: File writer -> Destination 1 con la data e l’ora dell’evento e le informazioni accessorie (ad esempio: Result written to: /tmp/file.txt)

Esempio più completo

  1. Creo un canale InterrogaLavoratore che legge da Source=DB e scrive su Destination=HTTP Sender.
  2. Creo un secondo canale che dovrà ospitare la response (INPSResponse):
  • Source: Channel Reader
  • Destination: File writer: decidere un file su cui scrivere (es. /tmp/lavoratore_response.txt): Sulla destra (Destination Mappings) vedo le variabili
    • rispostaKO
    • tipoErrore
    • sezioneErrata
    • descrizione

che mi arrivano dal transformer: Se edito il Transformer non vedo nessun XML, nessuno step, come se le variabili fossero ereditate da qualche altra parte… Probabilmente, a posteriori, arrivano dal canale InterrogaLavoratore che scrive sul canale presente.
Nell’impostazione di Chiama WS INPS (che è una destinazione del canale) definisco che la Response debba essere inviata al canale (da creare) INPSResponse.

Canale INPSResponse

Sta tutto a scrivere bene il Transformer con gli XML giusti. In particolare, in questo caso, usavo il messaggio XML

 <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <soapenv:Header/>
  <soapenv:Body>
     <p600:RicevutaLavoratore xmlns:p600="http://interrogazionelavoratoreresponse.xsd.cert.appsrv.remotedomain.it">
        <p600:ricevutaNonOk>
           <p706:errore xmlns:p706="http://tipicert.xsd.cert.appsrv.remotedomain.it">
              <p706:tipoErrore>111</p706:tipoErrore>
              <p706:sezioneErrata>S111</p706:sezioneErrata>
              <p706:descrizione>Pincode assente o errato</p706:descrizione>
           </p706:errore>
        </p600:ricevutaNonOk>
     </p600:RicevutaLavoratore>
  </soapenv:Body>
 </soapenv:Envelope>

come Inbound, che è lo stesso ritornatomi dal SoapUI. Ma i prefissi per i nomi dei tag non piacciono a Mirth: la soluzione è: stripparli! Ottengo questo XML che metto in Inbound del Transformer:

 <Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
   xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
   xmlns:xsd="http://www.w3.org/2001/XMLSchema"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <Header/>
  <Body>
     <RicevutaLavoratore xmlns="http://interrogazionelavoratoreresponse.xsd.cert.appsrv.remotedomain.it">
        <ricevutaNonOk>
           <errore xmlns="http://tipicert.xsd.cert.appsrv.remotedomain.it">
              <tipoErrore>?</tipoErrore>
              <sezioneErrata>?</sezioneErrata>
              <descrizione>?</descrizione>
           </errore>
        </ricevutaNonOk>
     </RicevutaLavoratore>
  </Body>
 </Envelope>

Realizzare un web service con Mirth

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 realizza un prodotto (ad esempio: un laboratorio che produce l’analisi di un campione di sangue) e il dato deve essere trasmesso all’azienda sanitaria perché lo registri nel suo gestionale clinico. L’azienda sanitaria 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 sanitaria esegue il parsing del messaggio e salva nel gestionale (un database relazionale) i dati.

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)

Mirth1_source

 

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:

Mirth2_destination

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 distination non si può selezionare il tipo di connettore DatabaseReader che invece si può richiamare dal source. Quindi me lo sono fatto a mano. Ciò significa che, 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 in modo così approfondito (che è un po’ meno rigido del Java) è stata comunque un’esperienza formativa.

Alla fine di questo lavoro, salvare i dati, bisognava 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:

Mirth3_script

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

SoapUImsg

 

Di soapUI ne parlo a parte.

FAQ

[2012-03-13 11:53:08,938] FATAL (org.mule.impl.DefaultComponentExceptionStrategy:84): The error is: Closed Connection Query:

Se compare questo errore si deve rieseguire il deploy dei canali.

Pulizia e riavvio

Mi è capitato questa settimana (3/4/12) di avere Mirth di test a cui non riuscivo ad accedere con la password di prima.

Il problema non era che era cambiata la password ma che la partizione /opt era piena.

Occorreva fare pulizia dei logs e riavviare

1) per fare la pulizia dei log: accedere a nettomcattest02 con l’utente mirth

 $ rm /opt/Mirth/logs/[quello che serve]

2) per riavviare

  $ kill -9 [pid-di-Mirth]
  $ /opt/Mirth/mirth[Invio]

Documentazione sulle API java e javascript per Mirth

 svn/tags/1.8.1/server/src/com/webreach/mirth/server/util/DatabaseConnectionFactory.java

 

Lascia un commento

Your email address will not be published.