Biztalk Pipelines e dintorni

Da Nino Crudele - Microsoft MVP BizTalk Server

Questo articolo è rivolto non solo a chi gia lavora con biztalk, ma soprattutto a tutti quei professionisti, architetti, analisti, sistemisti e sviluppatori che spesso si ritrovano a dover convivere con un’ architettura biztalk e desiderano approfondire alcuni suoi importanti aspetti

Le Pipelines in Biztalk sono una delle principali componenti.

Il loro utilizzo è mirato a:

• Spacchettare messaggi in entrata in più messaggi individuali

• Verificare i documenti mediante firma digitale

• Processare la codifica dei documenti (MIME/SMIME)

• Trasformare da flat file a XML e vice versa

• Incrementare i messaggi con ulteriori informazioni derivate da database o altro

Dare la risposta a questa domanda è ciò che di meglio si possa fare per far capire come funziona Biztalk, ed è per questa ragione che ho voluto iniziare da questo importantissimo componente, personalmente lo considero il più importante e allo stesso tempo il più critico .

In questa figura ho rappresentato in modo schematico l’architettura interna di Biztalk, usiamola come punto di riferimento per le nostre riflessioni.

Dovete sapere che per chi lavora su Biztalk esiste un enunciato fondamentale e indiscutibile, non conoscerlo significa non aver ancora compreso come Biztalk lavora.

Questo enunciato dice:

Ho incontrato spesso persone che lavorano da tanto tempo su Biztak e che non hanno ancora compreso questa importantissima cosa.
I messaggi in Biztalk vengono considerati pubblicati quando entrano in Messagebox, la Messagebox è il database SQL utilizzato da Biztalk per le operazioni di interchange ecc.., parleremo di interchange più avanti

Se desidero o devo lavorare sulla struttura dei messaggi e sul loro contesto devo farlo prima o dopo la sua pubblicazione, cioè nella pipeline, il principio fondamentale è questo. 

In questa figura vediamo i due tipi di pipeline e come sono composte.

Le pipeline sono composte da vari stages:

E’ utilizzato per effettuare operazioni nelle quali è richiesto leggere il messaggio in entrata.
Alcune di queste operazioni potrebbero essere decriptare, decomprimere e così via.

E’ solitamente utilizzato per suddividere in più parti un messaggio.

Questo stage è utilizzato per controllare che il messaggio prodotto dal Disassembler rispetti le rules di pipeline.

Esempi pratici posso essere, controllare che lo schema del messaggio sia di un determinato tipo, oppure utilizzare della custom validation, esempio per controllare che un determinato ordine di acquisto sia presente sul database prima di pubblicare il messaggio.

Utilizzato per controllare che il certificato digitale di un messaggio e per verificare la validità del party sorgente.

E’ utilizzato per inserire e modificare delle informazioni del messaggio prima dell’ operazione di assemblaggio.

Per ricombinare più messaggi in uno o in un batch, è utilizzato anche per la conversione in flat-file e in scenari EDI per aggregare più flat-file in un batch.

Spesso utilizzato per controllare che i dati usino un determinato character set, compressione del messaggio, MIME encoding o agganciare un determinato certificato.

Ma credo che la cosa più importante sia capire  come funzionano e come usarle al meglio.
Dobbiamo tenere presente due principali aspetti:

1. L’ esecuzione delle pipeline non può avvenire su più server, mi spiego meglio, la pipeline viene eseguita esclusivamente dall’ host istance di biztalk.

2. Il messaggio viene eseguito sulla server nel momento in cui viene processato da biztalk, e non quando viene ricevuto.

Tutto questo comporta che se nella sua esecuzione, la pipeline utilizza molte risorse di sistema a livello di CPU, il nostro server risulterà non disponibile finche la pipe non termina.
Molti sviluppatori Biztalk scrivono codice custom nelle pipeline ma trascurano questo fatto.
Non solo, quando il messaggio entra in pipeline, questo viene allocato totalmente in memoria e li rimane fino al termine della pipe,
Possiamo anche utilizzare più istanze di una pipeline, ma dobbiamo ricordarci che non possiamo distribuirle su più macchine, provate ad immaginare cosa succederebbe in caso di messaggi di grandi dimensioni.
Ecco perché nelle architetture a livello enterprise è preferibile avere dei server biztalk di send e receive completamente separati da quello di orchestration.
Le pipelines sono oggetti di tipo statefull, cioè una volta che la pipe viene istanziata non si ferma finche non ha terminato tutti gli stages, di conseguenza i l controllo di errore
è sicuramente più difficoltoso, cioè nel caso di processi sincroni, se un messaggio alza un’ eccezione, risulta molto complicato inviare una notifica alla applicazione chiamante.
Durante lo studio della nostra architettura dobbiamo tenere ben presente tutti questi fattori.     

 Ecco un’ altro aspetto importantissimo di Biztalk che spesso rimane oscuro agli addetti ai lavori.
Un’ interchange  può essere un messaggio o una serie di messaggi, generalmente:

1 messaggio = 1 interchange.

Tutti i messaggi sono legati tra loro dall’ attributo InterchangeID, chiaramente ognuno di loro ha un MessageID univoco.
In definitiva, io posso ricevere un file contenente la lista delle anagrafiche e spacchettarlo in più messaggi di tipo anagrafica, questa funzionalità delle pipeline può essere
utilizzata per effettuare anche della correlation nelle orchestration, qui potrebbe tranquillamente scapparci il tip , ma non è questa la sede.
In Biztalk 2004 esisteva un problema, se uno dei messaggi andava in errore, l’intero interchange veniva annullato, nella versione 2006 viene scartato solo il messaggio errato
che possiamo successivamente rielaborare, o nel caso, e con le dovute sottoscrizioni, dirottarlo verso una diversa destinazione.

Tutto questo è fornito dal Recoverable Interchange Processing (RIP) che troviamo all’ interno del componente Disassembler.
Se si utilizza il RIP Biztalk prende il messaggio in errore e lo mette nella coda dei sospesi, questo per permetterci di riesumarlo in un secondo tempo.
Ci sono però delle situazioni nelle quali un’ intero interchange viene sospeso comunque, ed è nel caso fallisca una successiva operazione di mapping, in tal caso l’ intero processo interchange termina.

Questi interchanges sospesi possono essere riesumati dalla console amministrativa di Biztalk.

I tipi di errore invece che non precludono un’ intero interchange sono: 

• Schema non trovato

• Schema ambiguo (solitamente causato dalla presenza dello stesso tipo di schema)

• Validazione XML fallita

• Parsing FLAT-File fallito 

Attenzione, l’adapter MSMQT non supporta il meccanismo di RIP

Facciamo un’ esempio pratico con questo file XML.

<Rootbatch>
  <Anag1>Data1</< FONT>Anag1>  //nessun errore
  <Anag2>Data2</< FONT>Anag2>  //Errore di routing
  <Anag3>Data3</< FONT>Anag3> //nessun errore
  <Anag4>Data4</< FONT>Anag4> //Errore a livello di pipeline
  <Anag5>Data5</< FONT>Anag5> //nessun errore
</Rootbatch>

Prima ipotesi, processiamo il messaggio senza utilizzare RIP, cioè lo Standard Interchange Processing

I nodi 1 2 e 3 sono pronti per la pubblicazione in messagebox ma il 4 causa un errore a livello di pipeline.
In tal caso l’intero interchange entra in rollback e messo nella coda sospesi.

Seconda ipotesi, p rocessiamo il messaggio utilizzando RIP, cioè il recoverable Interchange Processing. 

I nodi 1 2 e 3 vengono processati, il 4 causa l’ errore ma il processo non si interrompe,  la pipe prosegue e viene processato il 5 correttamente.
Risultato, i nodi 1 2 3 e 5 entrano in messagebox, il 4 viene messo nella coda sospesi, il 2 viene successivamente inviato alla coda sospesi per l’errore di routing.

 Possiamo impostare il RIP in due posti, uno è nella receive pipeline

L’altro è nella receive location

Sono pipelines che comprendono gia dei componenti:

La XMLReceive contiene i componenti quali XMLDisassembler e Party Resolution, la XMLTrasmit il componente Assemlber.
Si utilizzano queste pipeline se non si ha necessità di eseguire del pre-processing sui documenti ma si desidera solo utilizzare le features base di Biztalk, esempio del promoting, effettuare routine e sottoscrizioni con orchestration, validazione degli schemas ecc…. 

Grazie a queste due pipelines è possibile trattare i dati in binario , queste non esaminano il messaggio e di conseguenza non effettuano alcuna validazione.

Spero di essere riuscito a fornirvi delle informazioni utili e soprattutto chiare.
In un prossimo articolo approfondirò le pipeline da un punto di vista puramente tecnico e di sviluppo.