Condividi tramite


Architettura dell'elaborazione delle sottoscrizioni

In seguito alla raccolta degli eventi, Notification Services può elaborare le sottoscrizioni per generare le notifiche. Il confronto tra le sottoscrizioni e gli eventi viene eseguito dal generatore.

Per generare le notifiche, lo sviluppatore crea una o più regole per l'applicazione. Queste regole vengono scritte sotto forma di query Transact-SQL che specificano le modalità di correlazione tra eventi e sottoscrizioni, nonché qualsiasi altra condizione che deve essere soddisfatta perché possa essere generata una notifica.

In un'applicazione semplice, quando il generatore esegue una regola, l'applicazione confronta tutte le sottoscrizioni disponibili con il batch di eventi corrente visibile in una vista di eventi. Quando viene rilevata la corrispondenza tra un determinato evento e una determinata sottoscrizione, il generatore di notifiche crea una notifica. Questa notifica contiene dati relativi all'evento. Include inoltre riferimenti ai dati relativi al sottoscrittore e al dispositivo del sottoscrittore e, in alcuni casi, le impostazioni internazionali del sottoscrittore, nonché altre informazioni necessarie per la distribuzione.

Architettura di base dell'elaborazione delle sottoscrizioni

La notifica non viene inviata appena dopo la creazione, ma viene inserita dal generatore in una tabella delle notifiche interna. Quando è pronto un batch di notifiche, queste vengono formattate e distribuite dal distributore.

Se un'applicazione supporta le sottoscrizioni pianificate, quando il generatore elabora questo tipo di sottoscrizioni valuta solo quelle previste dalla pianificazione in un determinato momento. Ad esempio, se il generatore viene eseguito ogni 15 minuti, alle 8.00 valuta tutte le sottoscrizioni pianificate tra le 7.45 e le 8.00.

Se un'applicazione utilizza dati della cronologia, può memorizzare tali dati insieme alle informazioni sugli eventi e le sottoscrizioni in una tabella supplementare, denominata cronologia, e utilizzarli per generare le notifiche.

Elaborazione delle sottoscrizioni con cronologie

Il generatore viene eseguito in base a una pianificazione definita dal periodo di quantum specificato nella definizione dell'applicazione. Il quantum determina la frequenza in base alla quale il generatore viene attivato ed esegue regole. Se si imposta un periodo di quantum breve, il generatore viene eseguito più spesso e viene occupata una quantità maggiore di risorse del sistema. Se invece si imposta un periodo di quantum lungo, aumenta l'intervallo tra la ricezione degli eventi e la generazione di notifiche.

Tipi di regole

Il funzionamento del generatore è determinato dalle regole definite per l'applicazione. È possibile creare i tipi di regole seguenti:

  • Le regole della cronologia degli eventi archiviano o aggiornano i dati relativi alla cronologia degli eventi in tabelle di cronologia definite dallo sviluppatore dell'applicazione. Ogni volta che viene eseguito, il generatore esegue per prime le regole di questo tipo.
  • Le regole degli eventi generano notifiche per le sottoscrizioni basate su eventi. Le regole di questo tipo vengono eseguite dopo le regole della cronologia degli eventi se è disponibile un batch di eventi correlato. Consentono inoltre di gestire tabelle di cronologia.
  • Le regole pianificate generano notifiche per sottoscrizioni pianificate. Le regole di questo tipo vengono eseguite dopo le regole della cronologia degli eventi per le sottoscrizioni correlate che devono essere elaborate in base a una pianificazione. Consentono inoltre di gestire tabelle di cronologia.

Tipi di azione delle regole

Le regole degli eventi e pianificate specificano l'azione da eseguire quando viene eseguita la regola. Ogni azione corrisponde a una query Transact-SQL che definisce un'unità di lavoro per il generatore. Queste query possono generare notifiche, ma anche eseguire altre operazioni, ad esempio aggiornare i dati della cronologia.

Le regole degli eventi e pianificate possono utilizzare azioni semplici basate su parametri oppure azioni condizionali più flessibili:

  • Le azioni semplici sono query Transact-SQL che definiscono in modo completo la query di generazione delle notifiche, incluse tutte le clausole WHERE. Le azioni semplici ottengono l'espressione delle clausole WHERE dai dati delle sottoscrizioni e degli eventi. Ad esempio, un'applicazione per le previsioni meteorologiche può consentire ai sottoscrittori di specificare una città per le notifiche relative alle previsioni. La query con azione semplice utilizza quindi una clausola WHERE, quale WHERE subscription.city = event.city, per unire i dati degli eventi e delle sottoscrizioni ai nomi delle città.
    Quando una regola utilizza un'azione semplice, i sottoscrittori specificano i parametri per la query, ad esempio il nome della città.
  • Le azioni condizionali consentono ai sottoscrittori di definire in modo completo le condizioni di ricerca della query. È ad esempio possibile esporre lo schema dei dati degli eventi nell'interfaccia di gestione delle sottoscrizioni per consentire ai sottoscrittori di creare condizioni di ricerca personalizzate per tali dati, come WHERE event.State = Washington AND event.LowTemperature < 0. L'interfaccia di gestione delle sottoscrizioni può consentire di impostare le condizioni di ricerca selezionando colonne e operatori da caselle di riepilogo e immettendo valori in caselle di testo.

Le azioni semplici generano un insieme limitato di condizioni di ricerca per il generatore, pertanto offrono normalmente prestazioni migliori rispetto alle azioni condizionali. Le azioni condizionali sono più potenti, ma implicano la valutazione di un maggior numero di condizioni di ricerca per la regola degli eventi o pianificata.

Vedere anche

Concetti

Specificazione della durata dei quantum del generatore
Definizione delle regole di sottoscrizione
Architettura della raccolta degli eventi
Architettura della gestione delle sottoscrizioni
Architettura della formattazione e del recapito delle notifiche

Guida in linea e informazioni

Assistenza su SQL Server 2005