Gestione di messaggi di grandi dimensioni negli adapter

Il motore di messaggistica BizTalk è in grado di elaborare messaggi di dimensioni notevoli e non pone limiti alla dimensione massima di un messaggio. È tuttavia consigliabile limitare la dimensione dei messaggi allo scopo di mantenere livelli ottimali di prestazioni e gestione delle risorse. Il numero dei messaggi elaborati al secondo diminuisce proporzionalmente all'aumentare della dimensione dei messaggi. Prendere in considerazione le dimensioni medie dei messaggi, il tipo di messaggio e il numero di messaggi elaborati da BizTalk Server durante la progettazione dello scenario e della pianificazione della capacità.

Elaborazione basata sul flusso

Durante lo sviluppo degli adapter è importante tenere presente la gestione dei messaggi di grandi dimensioni. È vivamente sconsigliato caricare l'intero flusso di dati in memoria senza tenere conto delle dimensioni, dal momento che tale operazione potrebbe arrestare il processo di BizTalk Server. Il livello basso della memoria virtuale potrebbe diventare un problema in funzione delle dimensioni e del numero dei messaggi elaborati dal motore in un determinato momento. È invece preferibile che i messaggi vengano elaborati rispettando un flusso, come illustrato di seguito:

• Messaggi in ingresso. Per i messaggi in ingresso il flusso di rete è associato al messaggio BizTalk dall'adapter di ricezione lasciando l'operazione di pull del flusso al motore di messaggistica BizTalk.

• Messaggi in uscita. Per i messaggi in uscita l'adapter è responsabile dell'operazione pull del flusso. Il flusso viene effettivamente estratto dal database MessageBox e inoltrato alla pipeline di trasmissione. L'adapter deve trasmettere i dati in rete rispettando un flusso.

  Nella seguente figura viene illustrata l'elaborazione basata sul flusso sul lato ricezione del motore di messaggistica.

  

  Quando un adapter inoltra un messaggio al motore, deve associare il relativo flusso di dati al messaggio BizTalk. Per alcuni adapter ciò implica l'implementazione di un flusso di rete. Quando il messaggio viene inoltrato, il motore esegue la pipeline di ricezione. Durante l'esecuzione della pipeline, i componenti della pipeline che desiderano modificare i dati duplicano il messaggio, associando il flusso dal nuovo messaggio al flusso del messaggio precedente. Dopo l'esecuzione della pipeline, il motore di messaggistica estrae un messaggio dalla pipeline ed esegue un ciclo per la lettura del flusso in tale messaggio. Questa lettura del flusso richiama una lettura del flusso precedente, il quale a sua volta richiama una lettura del flusso precedente e così via fino al flusso di rete. Il motore scarica periodicamente i dati nel MessageBox per gestire un modello di memoria lineare.

  Suggerimento per la risoluzione dei problemi: Sul lato invio, l'adapter è responsabile della lettura del flusso. Se l'adapter di trasmissione desidera leggere proprietà di contesto del messaggio alzate di livello o scritte nella pipeline di trasmissione, queste proprietà potranno essere scritte solo dopo la lettura dell'intero flusso. Solo dopo la lettura di tutto il flusso si avrà la certezza che l'esecuzione di tutti i componenti della pipeline è terminata.

Individuazione di un byte specifico nel flusso

In alcuni scenari può essere necessario che l'adapter ricostruisca il flusso fino alle origini per gestire messaggi non riusciti che occorre sospendere. Ne è un esempio un adapter HTTP che riceve i dati con la codifica Chunked per inoltrare il messaggio di risposta in una coppia sollecitazione-risposta.

In molti scenari, tuttavia, potrebbe non essere possibile rilevare il flusso di dati. Si consideri, ad esempio, un adapter HTTP che riceve dati con la codifica Chunked. Per delineare un flusso di dati tale da consentire l'individuazione dei messaggi non riusciti, sarebbe necessario che l'adapter memorizzasse i dati nella cache, in memoria o su disco, man mano che vengono letti. Non è una soluzione ottimale che tra l'altro richiede risorse aggiuntive. Molti componenti della pipeline immediatamente pronti all'uso, inoltre, utilizzano solo il flusso in avanti. Per questi scenari, baseadapter nell'SDK usa una classe helper denominata VirtualStream. Il file che contiene questa funzionalità è denominato VirtualStream.cs.

Nota

Il file VirtualStream.cs si trova in due percorsi in Pipelines SDK Samples— SDK\Samples\Pipelines\ArbitraryXPathPropertyHandler e SDK\Samples\Pipelines\SchemaResolverComponent\SchemaResolverFlatFileDasm.

L'idea alla base di un flusso virtuale consiste nel fatto che i dati del flusso vengono inseriti in un flusso di memoria fino al raggiungimento di una soglia, al di là della quale si verifica l'overflow dei dati in una posizione protetta su disco. Alla chiusura del flusso il file su disco viene eliminato automaticamente. I flussi solo in avanti possono essere progettati in questo modo.