Definizione di azioni condizionali

  • Articolo

Data aggiornamento: 17 luglio 2006

Un'azione è un gruppo di istruzioni Transact-SQL eseguite da Notification Services ogni volta che viene attivata una regola di sottoscrizione. Ogni regola di sottoscrizione può contenere una sola azione, che può essere un'azione di base, ovvero una query predefinita, o un'azione condizionale, che consente ai sottoscrittori di definire l'equivalente di una clausola WHERE per la query di generazione delle notifiche. In questo argomento vengono descritte le azioni condizionali e viene illustrato come scriverle.

ms172509.note(it-it,SQL.90).gifImportante:
Utilizzare le azioni condizionali solo se è necessario consentire ai sottoscrittori di creare condizioni complesse personalizzate per la generazione delle notifiche. In caso contrario, utilizzare le azioni predefinite che consentono all'utente di immettere i valori per una query con parametri, decisamente più efficiente. Per ulteriori informazioni, vedere Definizione di azioni.

Azioni condizionali

Le azioni condizionali consentono l'uso di regole flessibili create dai sottoscrittori. Mentre un'azione predefinita permette ai sottoscrittori semplicemente di specificare i valori dei parametri per query definite dallo sviluppatore, un'azione condizionale consente di creare l'equivalente di una clausola WHERE per le query, tramite operatori booleani (AND, OR e NOT) per combinare le singole condizioni.

Ad esempio, un'applicazione relativa alle previsioni del tempo può includere una classe di eventi contenente due campi: City e Forecast. Lo sviluppatore può definire una query di base per creare notifiche simile alla seguente:

INSERT INTO dbo.WeatherNotifications(SubscriberId, DeviceName, 
    SubscriberLocale, City, Forecast) 
SELECT [Subscription.SubscriberId], [Subscription.DeviceName], 
    [Subscription.SubscriberLocale], [Input.City], [Input.Forecast])
FROM dbo.FlightEventRule

Si noti che questa query seleziona dati da una vista con lo stesso nome della regola, in questo caso FlightEventRule. I nomi dei campi di tale vista sono Subscription.SubscriptionFieldName e Input.EventFieldName, pertanto devono essere racchiusi tra parentesi quadre.

Attraverso un'interfaccia per la gestione delle sottoscrizioni, un sottoscrittore può definire condizioni che equivalgono a una clausola WHERE. Ad esempio, un utente può specificare due condizioni: City deve corrispondere a 'Seattle' e Forecast deve contenere 'snow', quindi unire queste condizioni con un operatore AND. Questa operazione equivale alla clausola WHERE seguente:

WHERE City = 'Seattle' AND Forecast LIKE '%snow%'

Quando Notification Services esegue la regola di sottoscrizione, elabora tutte le condizioni simili insieme, migliorando le prestazioni. Notification Services popola quindi la vista della regola con le coppie corrispondenti di input e sottoscrizione.

Considerazioni sulle prestazioni

Anche se Notification Services elabora tutte le condizioni simili insieme, l'utilizzo delle azioni condizionali comporta un overhead. Notification Services deve ottenere un insieme di tutte le condizioni, organizzare la condizioni per un'efficiente valutazione, valutarle e quindi generare le notifiche risultanti per tutte le sottoscrizioni. A causa di tale overhead, è in genere necessaria una maggiore quantità di tempo per valutare le regole che utilizzano le azioni condizionali rispetto a quelle con azioni predefinite.

Protezione

Tutte le azioni condizionali vengono eseguite nel contesto di un utente del database specificato appositamente. L'utilizzo di un utente con privilegi di basso livello riduce al minimo il rischio di protezione nel caso in cui l'interfaccia per la gestione delle sottoscrizioni venga compromessa inserendo condizioni che tentano di accedere ad altre tabelle o di eseguire altre azioni.

L'utente del database deve disporre di autorizzazioni limitate che consentono esclusivamente la selezione dei dati dalle origini di eventi e l'esecuzione di funzioni definite dall'utente utilizzate dalle condizioni.

L'account di accesso di SQL Server associato a questo utente deve essere esistente quando Notification Services crea gli oggetti dell'applicazione nel database dell'applicazione.

Transazioni

Tutte le istruzioni di un'azione condizionale fanno parte della stessa transazione, pertanto vengono completate oppure annullate tutte. Se la transazione non viene eseguita correttamente, Notification Services scriverà un messaggio di errore nel registro applicazioni di Windows.

Definizione di un'azione condizionale

Se si desidera definire un'applicazione tramite XML, definire le azioni condizionali nel file di definizione dell'applicazione (ADF). Se l'applicazione viene definita a livello di programmazione, utilizzare gli oggetti NMO (Notification Services Management Objects) per definire le azioni condizionali.

Per definire un'azione condizionale

Account di accesso di SQL Server

Poiché Notification Services esegue tutte le azioni condizionali nel contesto di un utente specificato del database, è necessario specificare l'account di accesso associato all'utente. Questo account deve esistere prima che Notification Services crei l'applicazione. In caso contrario, Notification Services non riesce a creare l'applicazione e annulla la creazione o l'aggiornamento dell'istanza.

Assicurarsi che l'account di accesso disponga di autorizzazioni limitate per il server. È consigliabile non concedere all'account autorizzazioni valide per tutto il server e non associarlo ad alcun ruolo del server.

Per definire l'account di accesso di SQL Server

Utente del database

L'utente del database è l'account con cui vengono eseguite tutte le azioni condizionali. Notification Services concede alcune delle autorizzazioni necessarie per eseguire le azioni condizionali a questo utente del database. Se l'utente del database non esiste quando Notification Services crea l'applicazione, Notification Services lo crea.

Notification Services concede le autorizzazioni necessarie per gli oggetti di Notification Services, ma non per le tabelle o le viste di input e neppure per eventuali funzioni definite dall'utente utilizzate dalle azioni condizionali. È necessario concedere queste autorizzazioni durante la distribuzione dell'applicazione. I comandi Transact-SQL per la concessione di queste autorizzazioni hanno il formato seguente:

-- grant permissions on the view for an input event class
GRANT SELECT ON ApplicationSchema.EventClassName TO SqlUserAccount
-- grant permissions on an input event chronicle table
GRANT SELECT ON ChronicleSchema.ChronicleName TO SqlUserAccount
-- grant execute permissions on a user-defined function 
-- used in Subscription.Conditions
GRANT EXEC ON UDFSchema.MyUserDefinedFunction TO SqlUserAccount
Per definire l'utente del database

Nome di input

Quando si utilizza un'azione condizionale, è necessario specificare quale vista o tabella contiene i dati dell'evento.

  • Se l'azione condizionale è una regola di evento, l'input proviene in genere dalla vista degli eventi con lo stesso nome della classe di evento.
    Attenzione   Non utilizzare come input la tabella degli eventi, denominata NSEventClassNameEvents. Tale tabella contiene tutti gli eventi non rimossi dal sistema e determinerà la generazione di notifiche duplicate.
  • Se l'azione condizionale è destinata a una regola pianificata, l'input proviene in genere da una cronologia di eventi.
    Attenzione   Per le regole pianificate non utilizzare come input la vista degli eventi, denominata EventClassName. Tale vista contiene soltanto il batch di eventi corrente e risulterà spesso vuota o incompleta per le regole pianificate.
Per definire il nome di input

Schema di input

Lo schema di input è il nome dello schema del database per l'input.

  • Se l'input è la vista degli eventi, lo schema è lo schema dell'applicazione. È possibile definire lo schema dell'applicazione durante la definizione del database dell'applicazione oppure può corrispondere al valore predefinito di dbo. Per ulteriori informazioni, vedere Definizione del database dell'applicazione.
  • Se l'input è una cronologia di eventi, lo schema viene definito nell'istruzione CREATE TABLE che crea la cronologia. In genere corrisponde allo schema dell'applicazione. Per ulteriori informazioni, vedere Definizione delle cronologie per una classe di evento.
Per definire lo schema di input

Espressione Transact-SQL

Ogni azione della cronologia specifica la query principale per la generazione delle notifiche. La query definisce la query che seleziona i campi della sottoscrizione e di input e li aggiunge alla tabella delle notifiche.

La query deve selezionare i campi della sottoscrizione e di input da una vista che unisce i dati delle sottoscrizioni e degli eventi. Il formato dei nomi dei campi delle sottoscrizioni presenti nella vista è [Subscription.SubscriptionFieldName]. Il formato dei nomi dei campi di input (eventi) è [Input.EventFieldName].

I sottoscrittori creano l'equivalente della clausola WHERE per la query tramite un'interfaccia per la gestione delle sottoscrizioni. Notification Services valuta le azioni condizionali per individuare tutte le sottoscrizioni rilevanti e quindi genera le notifiche.

Modello

Il modello Transact-SQL seguente illustra come scrivere un'espressione Transact-SQL per un'azione condizionale.

INSERT INTO schema.NotificationClassName(SubscriberId, 
    DeviceName, SubscriberLocale, NotificationFields) 
SELECT [Subscription.SubscriberId], DeviceName, SubscriberLocale, 
    [Input.EventFieldName], ...
FROM schema.RuleName

Nell'istruzione SELECT è possibile selezionare i valori di DeviceName e SubscriberLocale da un'origine dei dati, quale la vista denominata in base alla regola, oppure specificare valori letterali, quali 'File' e 'en-US'.

La query può contenere altre istruzioni e non è necessaria per la generazione delle notifiche. La query può svolgere tutte le operazioni necessarie, ad esempio aggiornare una cronologia. Tuttavia, almeno una regola di sottoscrizione deve generare le notifiche. In caso contrario, l'applicazione non genera né distribuisce le notifiche ai sottoscrittori.

Clausola INSERT

Come illustrato nel modello, è necessario specificare i campi seguenti, con l'ordine indicato, nell'istruzione INSERT:

  • SubscriberId
  • DeviceName
  • SubscriberLocale

Tutti i campi non calcolati vengono definiti nello schema di notifica. Se si utilizzano campi calcolati, non aggiungervi valori. I valori verranno calcolati dopo l'inserimento dei dati della notifica.

Si noti che i valori di SubscriberId e DeviceName devono corrispondere a un record nella tabella SubscriberDevices.

Eseguire aggiunte alla tabella delle notifiche solo in una regola di sottoscrizione. Quando si elaborano le regole di sottoscrizione, Notification Services prepara l'esecuzione di ogni regola, esegue la regola e quindi elimina i dati dopo l'esecuzione. Se si tenta di inserire notifiche all'esterno di una regola di sottoscrizione, le operazioni di preparazione ed eliminazione non vengono eseguite, provocando un errore.

Utilizzo di stored procedure

Anziché incorporare le istruzioni Transact-SQL nell'azione di creazione, è possibile chiamare una stored procedure. È necessario creare la stored procedure nel database dell'applicazione. È possibile definire la stored procedure in uno script di distribuzione. La stored procedure va creata dopo che Notification Services ha creato l'istanza o ha aggiunto l'applicazione, ma prima di attivare l'istanza o l'applicazione.

Per utilizzare una stored procedure, sostituire il testo della query con una chiamata alla stored procedure. Nell'esempio riportato di seguito viene illustrato come chiamare una stored procedure:

EXECUTE dbo.WeatherConditionActionSP;
Per definire l'espressione Transact-SQL

Scrittura di interfacce per la gestione delle sottoscrizioni

Quando si scrivono interfacce per la gestione delle sottoscrizioni, è necessario considerare i tipi di sottoscrizioni supportati dall'applicazione. Per sottoscrizioni basate su condizioni, è necessario che l'interfaccia per la gestione delle sottoscrizioni consenta al sottoscrittore di immettere condizioni, ad esempio selezionando un campo in una casella di riepilogo a discesa, immettendo un operatore e specificando un valore.

Per il codice di esempio in grado di illustrare come aggiungere una sottoscrizione basata su condizioni, vedere Aggiunta di una sottoscrizione.

Vedere anche

Riferimento

Microsoft.SqlServer.NotificationServices.Rules

Concetti

Definizione di azioni
Definizione delle regole eventi
Definizione delle regole pianificate

Altre risorse

INSERT (Transact-SQL)
SELECT (Transact-SQL)
Definizione delle classi di sottoscrizione
Sviluppo di interfacce di gestione delle sottoscrizioni

Guida in linea e informazioni

Assistenza su SQL Server 2005

Cronologia modifiche

Versione Cronologia

17 luglio 2006
Contenuto modificato:
  • Aggiunta di una sezione relativa alle interfacce per la gestione delle sottoscrizioni.