Architettura di pubblicazione e sottoscrizione

  • Articolo

Una progettazione di pubblicazione/sottoscrizione prevede tre componenti:

  • Autori

  • Sottoscrittori

  • evento

    I server di pubblicazione comprendono porte di ricezione che pubblicano i messaggi che arrivano nei relativi indirizzi di ricezione, orchestrazioni che pubblicano i messaggi durante la trasmissione dei messaggio o l'avvio di un'altra orchestrazione in modalità asincrona e porte di trasmissione sollecitazione-risposta che pubblicano i messaggi quando ricevono una risposta dal trasporto o dall'applicazione di destinazione.

    In BizTalk Server esistono due tipi principali di sottoscrizioni: attivazione e istanza. Una sottoscrizione di attivazione specifica che un messaggio che soddisfa la sottoscrizione deve attivare o creare una nuova istanza del sottoscrittore al momento della ricezione. Le sottoscrizioni di attivazione vengono in genere create dalle porte di trasmissione con filtri o dalle porte di trasmissione associate a orchestrazioni e dalle forme Ricezione dell'orchestrazione con la proprietà Attiva impostata su true. Una sottoscrizione di istanza indica che i messaggi che soddisfano la sottoscrizione devono essere indirizzati a un'istanza già in esecuzione del sottoscrittore. Le sottoscrizioni di istanza vengono in genere create da orchestrazioni con ricezioni e porte di ricezione richiesta/risposta correlate in attesa di una risposta da BizTalk Server.

    La differenza tra i due tipi di sottoscrizioni a livello di informazioni è rappresentata dal fatto che una sottoscrizione di istanza include l'ID univoco dell'istanza, archiviato nella tabella delle sottoscrizioni all'interno del database MessageBox master. Quando un'istanza di orchestrazione o una porta di ricezione completa l'elaborazione, le sottoscrizioni di istanza vengono rimosse dal database MessageBox mentre le sottoscrizioni di attivazione restano attive purché l'orchestrazione o la porta di trasmissione sia integrata.

Creazione di sottoscrizioni

Le sottoscrizioni vengono create dalle classi di servizio in BizTalk Server, che sono elencate nella tabella adm_ServiceClass del database di gestione di BizTalk Server. I servizi includono la memorizzazione nella cache, la messaggistica di tipo In-Process e Isolato, ospitata da Gestione endpoint, e le orchestrazioni/XLANG ospitate dal servizio secondario XLANG. Ciascuna di queste classi di servizio è in grado di creare sottoscrizioni e ricevere messaggi pubblicati.

Una sottoscrizione è un insieme di istruzioni di confronto, note come predicati, che coinvolgono le proprietà di contesto del messaggio e i valori specifici della sottoscrizione. Tipo messaggio è ad esempio una proprietà di contesto dei messaggi e molte sottoscrizioni specificano il tipo di messaggio nella relativa sottoscrizione. Le informazioni generali sulla sottoscrizione vengono inserite nella tabella delle sottoscrizioni da Agente messaggi, mentre i predicati specifici vengono inseriti in una delle tabelle dei predicati seguenti, a seconda del tipo di operazione specificato per la sottoscrizione:

  • BitwiseANDPredicates

  • EqualsPredicates

  • EqualsPredicates2ndPass

  • ExistsPredicates

  • FirstPassPredicates

  • GreaterThanOrEqualsPredicates

  • GreaterThanPredicates

  • LessThenOrEqualsPredicates

  • LessThenPredicates

  • NotEqualsPredicates

    A tale scopo, è possibile chiamare le stored procedure Bts_CreateSubscription_<application name> e Bts_InsertPredicate_<application name> nel database MessageBox in cui <il nome> dell'applicazione è il nome dell'host BizTalk che sta creando la sottoscrizione.

    Quando una porta di trasmissione viene integrata, la porta crea almeno una sottoscrizione per qualsiasi messaggio contenente l'ID di trasporto della porta di trasmissione in questione nel contesto. Questo consente alla porta di trasmissione di ricevere sempre i messaggi a essa indirizzati. Quando una porta dell'orchestrazione è sottoposta a binding con una specifica porta di trasmissione, le informazioni su tale binding vengono memorizzate nel database di gestione BizTalk. Quando vengono inviati messaggi dall'orchestrazione tramite la porta associata alla porta di trasmissione fisica, l'ID del trasporto viene incluso nel contesto in modo che i messaggi vengano instradati alla porta di trasmissione in questione. È importante tuttavia tenere presente che questa porta di trasmissione non è l'unica porta di trasmissione in grado di ricevere i messaggi inviati dall'orchestrazione. Quando un'orchestrazione invia un messaggio, quest'ultimo viene pubblicato nel database MessageBox con tutte le proprietà innalzate di livello pertinenti. Viene garantito che la porta di trasmissione associata riceva una copia del messaggio in quanto l'ID del trasporto si trova nel contesto, ma qualsiasi altra porta di trasmissione o orchestrazione può disporre di una sottoscrizione corrispondente alle proprietà del messaggio. È importante tenere presente che ogni volta che un messaggio viene pubblicato direttamente nel database MessageBox, tutti i sottoscrittori con sottoscrizioni corrispondenti riceveranno una copia del messaggio.

Pubblicazione e routing

Una volta creata e attivata una sottoscrizione, è necessario pubblicare un messaggio prima di eseguire qualsiasi elaborazione. I messaggi vengono pubblicati quando vengono ricevuti in BizTalk Server da uno dei servizi indicati in precedenza. Questa descrizione del routing è incentrata principalmente sui messaggi ricevuti in BizTalk Server tramite un adapter.

Quando i messaggi vengono sottoposti all'elaborazione delle pipeline di ricezione, le proprietà vengono innalzate di livello nel contesto del messaggio. Quando un messaggio è pronto per la pubblicazione nel database MessageBox dopo essere stato elaborato dall'adapter e dalla pipeline di ricezione, la prima operazione eseguita prevede l'inserimento da parte di Agente messaggi dei valori delle proprietà innalzate di livello e dei valori dei predicati dal contesto del messaggio nel database MessageBox master di SQL Server. La memorizzazione di questi valori nel database consente ad Agente messaggi di prendere decisioni relative al routing.

La fase successiva prevede che Agente messaggi richieda al database MessageBox master di trovare le sottoscrizioni per il batch di messaggi corrente in corso di pubblicazione. Tenere presente che nel database non sono stati ancora scritti i messaggi, solo le proprietà di contesto. La stored procedure bts_FindSubscriptions nel database MessageBox esegue una query sulle tabelle delle sottoscrizioni e dei predicati sopra illustrate, collegandole alle proprietà dei messaggi memorizzate per il batch di messaggi corrente.

Con queste informazioni, Agente messaggi inserisce il messaggio una sola volta in ciascun database MessageBox che disponga di una sottoscrizione chiamando la stored procedure bts_InsertMessage. La stored procedure bts_InsertMessage viene prima chiamata con un ID sottoscrizione. In questo primo passaggio, la stored procedure chiama la stored procedure int_EvaluateSubscriptions responsabile della ricerca delle informazioni dettagliate della sottoscrizione, verificando che il messaggio soddisfi i requisiti di sicurezza per l'applicazione controllando che i predicati di messaggio corrispondano alle proprietà dell'applicazione per l'host e inserendo un riferimento al messaggio nella coda specifica dell'applicazione o nella coda sospesa specifica dell'applicazione a seconda dello stato. L'ID del messaggio, l'ID della sottoscrizione, l'ID del servizio e altre informazioni sulle sottoscrizioni vengono inseriti nella tabella della coda specifica dell'applicazione per ciascuna sottoscrizione rilevata per l'applicazione. Dopo che i messaggi sono stati inseriti, nelle tabelle dei predicati e delle proprietà dei messaggi vengono cancellati i valori correlati al batch.

La stored procedure bts_InsertMessage viene chiamata successivamente per ciascuna parte del messaggio. Nella prima chiamata viene passato il contesto del messaggio e quindi viene inserito nella tabella SPOOL insieme ai metadati relativi al messaggio, ad esempio il numero di parti, il nome della parte del corpo e l'ID. Inoltre, la parte del corpo del messaggio viene inserita nella tabella PARTS utilizzando la stored procedure int_InsertPart. La stored procedure bts_InsertMessage viene quindi chiamata per ciascuna delle rimanenti parti del messaggio, che vengono semplicemente passate alla stored procedure int_InsertPart in modo che vengano rese persistenti nella tabella PARTS.

Quando i messaggi vengono instradati, vengono aggiunti riferimenti per ciascun servizio che riceve l'istanza specifica del messaggio e delle relative parti mediante l'inserimento di record nelle tabelle seguenti:

  • MessageRefCountLog1

  • MessageRefCountLog2

  • PartRefCountLog1

  • PartRefCountLog2

    Questi riferimenti impediscono che i messaggi e le parti vengano eliminati dai processi di pulitura eseguiti periodicamente per evitare che il database MessageBox si riempia di dati di messaggi che non sono più presenti nel sistema. Per ridurre eventuali problemi di blocco e di contesa, vengono utilizzate due tabelle.

    Dopo aver instradato il messaggio alla coda appropriata, averlo memorizzato nelle tabelle Spool e Parts e avervi aggiunto riferimenti nelle code specifiche dell'applicazione, è necessario estrarre i messaggi dalle code in base alle istanze dell'applicazione. Ciascuna istanza di host dispone di un numero di thread di annullamento dell'accodamento che eseguono continuamente il polling del database in un intervallo configurato nella tabella adm_ServiceClass del database di gestione BizTalk. Questa stessa tabella include una colonna che indica il numero di thread di annullamento dell'accodamento da utilizzare. Ogni thread chiama il database MessageBox e chiama la stored procedure bts_DequeueMessages_<application name> appropriata per l'applicazione host in cui è in esecuzione. Questa stored procedure usa la semantica di blocco per assicurarsi che solo un'istanza e un thread di dequeuing siano in grado di operare su un messaggio nella coda in un determinato momento. Dopo aver ricevuto il messaggio, l'istanza di host a cui viene applicato il blocco passa tale messaggio al sottoservizio a cui è destinato.

    Se il servizio che riceve il messaggio è Gestione endpoint, verrà richiamata la porta di trasmissione (o il lato risposta di una porta di ricezione di richiesta/risposta). Se si tratta del sottoservizio XLANG/s, verrà creata o inserita un'orchestrazione che dovrà gestire la sottoscrizione a seconda che nella sottoscrizione sia presente un ID di istanza. Il servizio quindi rilascia il riferimento al messaggio e alla relativa parte in modo da consentire l'eliminazione dei dati del messaggio nel caso in cui nessun altro servizio disponga di riferimenti.

Vedere anche

Motore di messaggistica