Persistenza e durevolezza del motore

In questa sezione viene illustrata la capacità di BizTalk Server di integrare in modo affidabile i processi di business a regime di controllo libero rendendo persistente lo stato dei processi su disco tramite SQL Server. Rendendo persistente lo stato nel momento appropriato, tramite le transazioni, il sistema garantisce che lo stato dei processi non vada perso anche in caso di interruzione di componenti hardware o software. Questa situazione viene definita durevolezza del sistema.

Gestione di processi di business a regime di controllo libero

L'integrazione dei sistemi esistenti per l'esecuzione di un singolo processo di business logico richiede la gestione dello stato del processo all'esterno dei sistemi esistenti. Indipendentemente dal tipo di processo, a esecuzione prolungata o di breve durata, per evitare l'esplosione di percorsi di comunicazione personalizzati in conseguenza dell'utilizzo di sistemi fortemente accoppiati, è necessario che lo stato del processo sia gestito in modo indipendente.

Se il processo di business riveste un'importanza critica, lo stato dell'istanza del processo di business deve essere ovviamente affidabile. Per assicurare che i processi di business garantiscano affidabilità e durevolezza, BizTalk prevede l'utilizzo delle transazioni SQL Server per rendere persistente lo stato del processo e i dati di business su disco in un database noto come database MessageBox. Per altre informazioni sul database MessageBox, vedere Database MessageBox.

Ogni messaggio e tutte le istanze del processo aziendale più semplici ,ad esempio istanze di orchestrazione, in BizTalk Server vengono rese persistenti nel database MessageBox almeno una volta durante l'elaborazione.

Persistenza e sostenibilità

Il fatto che BizTalk Server persista tutti i messaggi e la maggior parte delle orchestrazioni ha un impatto diretto sulla sostenibilità, come indicato in What Is Sustainable Performance? Quando i messaggi arrivano nel database MessageBox, vengono instradati ai sottoscrittori in attesa (ad esempio, orchestrazioni e porte di trasmissione) e en-queued, o pubblicati, nelle tabelle SQL della finestra di messaggio per attendere che i sottoscrittori li rilevino ed elaborarli. Alcuni dei messaggi in arrivo attivano nuove istanze dei sottoscrittori. Altri messaggi arrivano e vengono instradati, tramite correlazione, a un'istanza in attesa di un sottoscrittore già in esecuzione, quale un'orchestrazione correlata.

Perché le orchestrazioni correlate possano continuare l'elaborazione, è necessario che i messaggi correlati in arrivo rimangano sbloccati. Per semplificare questa operazione, BizTalk garantisce che i messaggi (sia i messaggi di attivazione che quelli correlati) continuino a essere ricevuti, anche in condizioni di carico elevato, in modo da consentire il completamento dell'esecuzione dei sottoscrittori in attesa dei messaggi correlati e da allocare lo spazio necessario per l'esecuzione di ulteriori processi. Ne consegue che la velocità di ricezione dei messaggi sarà superiore alla velocità di elaborazione e di rimozione dei messaggi dal database MessageBox, creando pertanto un backlog dei messaggi. Essendo una tecnologia di archiviazione e inoltro, è naturale che BizTalk fornisca questo tipo di memorizzazione nel buffer. Questa funzionalità può tuttavia creare problemi nel caso in cui la velocità di ricezione risulti costantemente superiore alla velocità di elaborazione per un tempo illimitato, causando un backlog elevato.

Ogni messaggio ricevuto da o creato all'interno di BizTalk Server è immutabile, ovvero, dopo che il messaggio è stato ricevuto o creato, non è possibile modificarne il contenuto. I messaggi ricevuti possono inoltre avere più sottoscrittori. Ciascun sottoscrittore di uno specifico messaggio fa riferimento alla stessa singola copia del messaggio. Sebbene questo approccio riduca al minimo l'archiviazione, è necessario conservare per ciascun messaggio un conteggio di riferimenti ed eseguire periodicamente la manutenzione in modo da eliminare tutti i messaggi con conteggio di riferimenti pari a 0.

Se viene consentita la generazione all'interno del database MessageBox di un backlog sufficientemente elevato, i processi di manutenzione del database (implementati come set di processi SQL per ciascun database MessageBox) accumuleranno un certo ritardo e, se non hanno la possibilità di recuperare il ritardo, causeranno problemi specifici, ad esempio l'esaurimento dello spazio disponibile su disco. Per evitare una situazione di questo tipo, BizTalk Server fornisce un meccanismo di limitazione delle richieste che consente di rallentare la velocità di ricezione dei messaggi quando il backlog del database MessageBox giunge a un livello configurabile dall'utente. Per altre informazioni sulla limitazione delle richieste, vedere Ottimizzazione dell'utilizzo delle risorse tramite la limitazione dell'host.

Considerati tutti i processi e le attività che contribuiscono alla sostenibilità, la principale misura in grado di garantire una adeguata sostenibilità nel tempo è che non è consentita la crescita illimitata del backlog. In altri termini, è necessario che, nel tempo, venga raggiunto un giusto equilibrio tra i livelli di velocità effettiva di picco bassi ed elevati in modo che il database MessageBox sia in grado di garantire un backlog medio costante e gestibile. La misura principale del backlog è la profondità della tabella di spooling, esposta come contatore delle prestazioni BizTalk Server denominato BizTalk:Message Box:General Counters:Spool Size. Per altre informazioni su questo contatore delle prestazioni, vedere Contatori delle prestazioni di Message Box.

Per altre informazioni su come usare le dimensioni dello spooling e altri contatori per determinare la velocità effettiva massima che un sistema può sostenere, vedere Misurazione della velocità effettiva massima sostenibile del motore.

Raccomandazioni

BizTalk Server rende persistenti tutti i messaggi e la maggior parte delle orchestrazioni e può, lasciato non selezionato, sviluppare un backlog di messaggi che possono causare problemi come l'esaurimento dello spazio su disco. La misura principale del backlog è la profondità della tabella di spooling messagebox, esposta come contatore delle prestazioni denominato BizTalk:Message Box:General Counters:Spool Size.

Quando si pensa a un sistema in termini di velocità effettiva sostenibile, è necessario che la dimensione dello spooler sia in grado di sostenere una media stabile nel tempo, ovvero lo spooler non può continuare a crescere senza controllo all'infinito. In Misurazione della velocità effettiva massima sostenibile del motore, questo comportamento viene descritto in modo più dettagliato e viene fornito un metodo per determinare la velocità effettiva massima che un sistema può sostenere, sfruttando le dimensioni dello spooling e altri indicatori di prestazioni.

Vedere anche

Misurazione della velocità effettiva massima sostenibile del motore
Informazioni sulle prestazioni sostenibili
Suggerimenti per il miglioramento delle prestazioni
Contatori delle prestazioni del MessageBox