Differenze tra le versioni di "Pubblicazione messaggio ESB"
imported>Root |
imported>Root |
||
(Una versione intermedia di uno stesso utente non è mostrata) | |||
Riga 13: | Riga 13: | ||
=== source-guid === | === source-guid === | ||
Individua in modo univoco il mittente del messaggio. Per non limitare la flessibilità si evita di calcolare in modo automatico | Individua in modo univoco il mittente del messaggio. Per non limitare la flessibilità si evita di calcolare in modo automatico questo parametro, anche se si consiglia di utilizzare una dot-notation che inizia con "wkf.class." seguito dall'identificativo della classe di workflow che sta utilizzando l'attività. Ad esempio "wkf.class.ana.apr_ini" per indicare la pratica Anagrafica di Iscrizione in APR. | ||
=== source-des === | === source-des === |
Versione attuale delle 13:35, 2 ott 2013
Questa attività permette di inviare un messaggio sul Bus di comunicazione interno. La ricezione è possibile usando l'attività duale Attesa messaggio ESB.
Introduzione
Il Bus di comunicazione interno è parte dell'infrastruttura e rappresenta un meccanismo trasversale di comunicazione tra tutte le applicazioni della suite. Molte applicazioni pubblicano messaggi quando si verificano determinati eventi. Questi messaggi possono essere intercettati da chi si registra come "ascoltatore" (o listener) sul canale di comunicazione. Se non sono presenti listener i messaggi vengono semplicemente eliminati.
Ogni messaggo è caratterizzato da un insieme di attributi:
- source_guid: individua in modo univoco il mittente
- source_des: descrive in modo human-readable il mittente
- message_class: caratterizza la tipologia di messaggio
- value: contiene i dati da trasmettere
Trattandosi di un canale di comunicazione "aperto" a tutte le applicazioni è necessario inserire messaggi con un certo criterio, in modo che siano distinguibili dai messaggi delle altre applicazioni. Anche se è possibile inserire messaggi che "mimano" quelli di altre applicazioni si sconsiglia tale pratica per evitare possibili malfunzionamenti degli ascoltatori.
source-guid
Individua in modo univoco il mittente del messaggio. Per non limitare la flessibilità si evita di calcolare in modo automatico questo parametro, anche se si consiglia di utilizzare una dot-notation che inizia con "wkf.class." seguito dall'identificativo della classe di workflow che sta utilizzando l'attività. Ad esempio "wkf.class.ana.apr_ini" per indicare la pratica Anagrafica di Iscrizione in APR.
source-des
Una qualsiasi descrizione interpretabile da essere umano. Serve per riconoscere i messaggi qualora si presentino dei problemi nella loro gestione.
message-class
E' un array di stringhe che definiscono il tipo di messaggio. Questa informazione è basilare per il buon funzionamento del canale di comunicazione. Senza voler entrare in una trattazione dettagliata di come definire queste stringhe, si suggerisce di utilizzare stringhe (anche una sola) che inizino con "wkf.class.message.". E' importante tenere a mente che queste stringhe sono la chiave per la ricezione dei listener, quindi e' bene progettarle in modo da non creare ricezioni indesiderate.
value
Un array di stringhe a piacere.
Uso
E' possibile utilizzare la comunicazione su Bus per sincronizzare processi di workflow che non è possibile sincronizzare in altro modo, dove ad esempio non esiste un rapporto chiamante-chiamato oppure quando il processo principale genera dei sotto-processi asincroni che sono suddivisi in fasi ed il processo principale deve bloccarsi in attesa del completamento delle singole fasi. In questo caso i sotto processi invieranno messaggi e il processo principale li attenderà con Attesa messaggio ESB. Ma è possibile anche il contrario oppure altre soluzioni a seconda delle necessità.