Il significato di correlation in Biztalk è la possibilità di vincolare un determinato processo di business ad una informazione univoca e di conseguenza, al processo stesso.

Ecco alcuni esempi:

• Inviare un messaggio e ricevere il rispettivo responso in asincrono, anche dopo molto tempo, sulla base del valore di un campo del messaggio

• Eseguire dei processi di business single thread di tipo FIFO (First In First Out)

• Per controllare la concorrenza tra i processi di business

In questo articolo prenderemo in esame queste tre possibilità per capire come funziona la correlation e i suoi fondamenti; io sono sempre del parere che l’ importante sia capire il principio delle cose, la fantasia e la buona volontà farà il resto.

Simple Correlation

Facciamo un’ esempio pratico, la società X invia i nuovi ordini ricevuti alla società Y, la società Y si prende carico dell’ ordine e invia la merce all' acquirente.

La società X vuole ricevere una conferma sulla corretta presa in carico dell' ordine in questione.

Teniamo presente che la società X non può sapere quando la società Y prenderà effettivamente in carico l' ordine.

Questo è il classico caso in cui la correlation si dimostra la migliore delle soluzioni, vediamo come.

In figura 1 possiamo vedere come potrebbe essere la parte di orchestration che si prende carico di questo processo di business, vediamo ora di capire come funziona la correlation.
.

Fig. 1

Per maggiore chiarezza ho utilizzato l’ormai famosissimo file InputPO.xml che potete trovare sotto la directory ROOT:\Program Files\Microsoft BizTalk Server 2006\SDK\Samples\Orchestrations\CallOrchestration\InputPO.xml

Il file XML è così composto:

<ns0:PO xmlns:ns0="http://CallExec.PO">
  <PO_Num>PO12345</PO_Num> 
  <Weight>20</Weight> 
  <shipmentPrice>10</shipmentPrice> 
  </ns0:PO>

La cosa importante è definire quale sia l’ informazione che Biztalk deve utilizzare per creare la correlation, in questo caso ho deciso di utilizzare il campo PO_Num, di conseguenza bisogna effettuare una promotion di questo campo.

Passiamo ora a creare la nostra correlation, per fare questo dobbiamo andare nella Orchestration View e creare una nuova Correlation Type, questa definisce quale sia l’ informazione utilizzata per effettuare la correlation, questa la chiameremo CorrelationType_PONum(Fig 2)

Fig 2

Successivamente dobbiamo impostare la proprietà Correlation Properties della nuova Correlation Type e selezioniamo il campo del messaggio che abbiamo precedentemente promosso e che deve essere membro della correlation, nel nostro caso sarò PO_Num (Fig 3)

Fig 3

A questo punto definiamo una Correlation Set che imposterà la policy di correlazione nella nostra orchestration, per fare questo dobbiamo passare sempre dalla nostra Orchestration View, la chiameremo Correlation_PONum.(Fig 4)

Fig 4

Impostiamo la proprietà Correlation Type a CorrelationType_PONum.(Fig 5)

Fig 5

Adesso selezioniamo il nostro shape di send, in questo caso Send_To_CompY e impostiamo la proprietà Initializing Correlation Sets su Correlation_PONum.(Fig 6)

Fig 6

Dobbiamo ora impostare lo shape di receive che si prenderà carico di ricevere il responso dalla compagnia Y.

Selezioniamo lo shape di receive e impostiamo la propietà Following Correlation su Correlation_PONum.(Fig 7)

Fig 7

Abbiamo terminato, vediamo ora in dettaglio come funziona.

Il messaggio viene ricevuto dalla nostra orchestration e inviato alla compagnia Y mediante lo shape Send_To_CompY.

A questo punto l’ orchestration entra in listening (attesa), e attende di ricevere il messaggio che rispetta la correlation impostata e cioè quello che ha lo stesso PO_Num del messaggio inviato.

Successivamente viene inviato un messaggio di conferma all’ amministrazione.

Lo shape di delay a sinistra è una sorta di timeout, è impostato a quattro giorni:

new System.TimeSpan(4,0,0)

La mancata ricezione del responso per più di quattro giorni provoca l’ invio di un messaggio di tipo “ordine non evaso”.

Sequential Convoy

Altro esempio pratico, desideriamo ricevere ed elaborare i messaggi in ordine sequenziale di arrivo e tutti devono essere elaborati dalla stessa orchestration.

Ecco un’ altro aspetto molto interessante sull’ utilizzo delle correlations, il Sequential Convoy.

Prendiamo come esempio l’orchestration in figura 8

Fig 8

Per creare un Sequential Convoy occorrono due cose, una correlation e una sorgente in grado di gestire l’ ordered delivery.

I receive adapters in grado di gestire l’ ordered delivery sono SQL, MSMQ, MSMQT e MQ Series, perciò supponiamo di aver utilizzato uno di questi.

Risolto il problema adapter dobbiamo creare la correlation. Ma in base a quale criterio impostiamo la nostra correlazione? La Receive Port !

Per fare questo aggiungiamo una nuova Correlation Type, e impostiamo come properties correlate BTS.ReceivePortName e come Indentifier CorrelationTypeSeqConvoy. (Fig 9)

Seguendo la strada dell’ esempio precedente creiamo una nuova Correlation Set e impostiamo la sua Correlation Type a CorrelationTypeSeqConvoy e come Indentifier CorrelationSetSeqConvoy.

Associamo la CorrelationSetSeqConvoy alla proprietà Initalizing Correlation Sets dello shape Receive_PO e di conseguenza alla proprietà Following Correlation Sets dello shape di receive Receive Next

E’ importante capire come funziona un sequential convoy, il messaggio viene ricevuto dalla nostra orchestration, il fatto che i due shapes di receive facciano parte della stessa correlation fa sì che venga istanziata un’ unica orchestration per l’ elaborazione dei nostri messaggi.

Questo è di primaria importanza se le nostra intenzione è quella di delegare ad un’ unico processo l’ elaborazione dei nostri messaggi.

Lo shape di delay serve semplicemente per controllare se tutti i messaggi della coda sono stati elaborati. Il suo valore di timeout sarà impostato sulla base delle nostre reali esigenze elaborative di processo, in questo caso usciremo dal loop.

Parallel Convoy

Ecco un’ altro di quei casi ne quali una correletion può essere la soluzione ottimale.

Vogliamo creare un processo Biztalk che elabora due differenti messaggi da due differenti partner e fino a qui non sembra esserci alcun problema, a parte il fatto, che questo processo deve avviarsi solo quando arrivano entrambi i messaggi dai due partner.

Esempio lampante è quello di un’ ordine che può essere elaborato solo dopo che il pagamento è stato confermato, chiaramente sulla base di una informazione correttamente correlata, esempio il numero d’ordine.

Una semplice ma chiara orchestration, che rifletta questo caso, la vediamo in figura 10.

Fig 10

Qui abbiamo due diversi schema, quello dell’ ordine e quello di pagamento, ma in entrambi abbiamo il campo PO_Num.

Per prima cosa dobbiamo promuovere il campo PO_Num in entrambi gli schema e successivamente creare una Correlation Type basata proprio su questo campo.

Creiamo successivamente una Correlation Set basata sulla precedente Correlation Type, associamola ad entrambi gli shapes di receive ed il gioco e fatto, vediamo come funziona.

Il primo dei due shape che riceve il messaggio attiva l’ orchestration e di conseguenza la correlation.

Biztalk indirizza tutti i messaggi che rispettano la correlation creata e perciò sulla base dello stesso PO_Num verso l’ istanza dell’ orchestration ad essa associata .

Entrambi gli shapes di receive sono attivi e la proprietà Initialing Correlation Set punta logicamente alla stessa Correlation Set.

Vediamo infine due aspetti molto importanti, il Troubleshooting e lePerformance.

Troubleshooting

Nel caso delle correlations, spesso capire se i messaggi sono stati correttamente elaborati dalla stessa istanza, piuttosto che in sequenza corretta, può rivelarsi un problema molto complicato.

Per questo vi consiglio l’ utilizzo del subscription viewer che potete trovare sotto la directory ROOT:\Program Files\Microsoft BizTalk Server 2006\SDK\Utilities

Il file si chiama BTSSubscriptionViewer.btq, nella versione Biztalk 2004 ha estensione .EXE

Aprite la HUB Page, e mediante la voce di menu Action\Query Tasks\Open... aprite il file ed eseguite la query, il risultato è l’ insieme di tutte le sottoscrizioni effettuate, esistono tanti modi per ottenere questo risultato ma questa è la strada più semplice per chi non ha molta famigliarità con Biztalk Server.

Consiglio da addetto ai lavori per trovare possibili problemi di correlation in poco tempo, filtrate la query anche per Service Name e impostate le corrispettive porte associate alla correlation in esame.

Performance

Considero la correlation uno strumento potentissimo ma allo stesso tempo va utilizzato con molta cura e attenzione.

Nella maggior parte dei casi forziamo Biztalk a lavorare su singolo thread per orchestration e questo può risultare penalizzante per il nostro throughput.

Il single threading in Biztalk può rivelarsi molto utile in processi denominati FIFO (First In First Out) , ma allo stesso tempo devono essere trattati con il dovuto rispetto, perchè possono rivelarsi pesanti e onerosi, se utilizzati male.

Nei prossimi articoli tratteremo due aspetti estremamente interessanti, il Business Rules Framework e gli Adapters.

Inizio pagina