Definizione di azioni

Un'azione è un gruppo di istruzioni Transact-SQL eseguito da Notification Services ogni volta che viene attivata una regola di sottoscrizione. Ogni regola di sottoscrizione può includere un'azione, semplice, ovvero una query predefinita, oppure condizionale, che consente ai sottoscrittori di definire l'equivalente di una clausola WHERE per la query di generazione di notifiche. In questo argomento vengono illustrate le azioni semplici e la procedura per scriverle.

Azioni

Le istruzioni Transact-SQL in un'azione eseguono parte del lavoro della regola. Tale lavoro in genere consiste nel generare notifiche basate su un join tra campi sottoscrizione e campi evento. Nell'esempio seguente viene illustrata un'azione che genera notifiche per un'applicazione meteo:

INSERT INTO WeatherNotifications (SubscriberId, DeviceName, 
    SubscriberLocale, City, Forecast)
SELECT s.SubscriberId, s.DeviceName, 
   s.SubscriberLocale, e.City, e.Forecast
FROM WeatherEvents e 
JOIN WeatherSubscriptions s
ON s.City = e.City;

In questo esempio vengono selezionati il sottoscrittore, il dispositivo, le impostazioni internazionali, la città, e il testo della previsione da un join tra la vista di eventi WeatherEvents e la tabella di sottoscrizione WeatherSubscriptions, e quindi aggiunti i risultati alla tabella delle notifiche WeatherNotifications. Notification Services crea automaticamente la vista WeatherEvents per la classe di evento WeatherEvents. Tale vista include solo il set di eventi corrente che deve essere elaborato dal generatore.

Le azioni non devono necessariamente utilizzare la vista eventi e la tabella delle sottoscrizioni. Ad esempio, è possibile eseguire query sulle tabelle in altri database.

Inoltre, le azioni non devono necessariamente generare notifiche. Tuttavia, è consigliabile che almeno una regola di sottoscrizione includa un'azione che generi notifiche. In caso contrario, nell'applicazione non verranno generate e inviate notifiche ai sottoscrittori.

Per ulteriori informazioni sulla scrittura di query Transact-SQL, vedere Nozioni fondamentali sulle query.

Istruzione INSERT

[!NOTA] L'istruzione INSERT sostituisce la funzione di notifica utilizzata per creare le notifiche in Notification Services 2.0.

Come illustrato nell'esempio di codice, è necessario specificare i seguenti campi, nell'ordine indicato, nell'istruzione INSERT:

• SubscriberId
• DeviceName
• SubscriberLocale
• Tutti i campi non calcolati definiti nello schema di notifica. Se si utilizzano i campi calcolati, non inserire valori nei campi stessi. I valori relativi vengono infatti calcolati al momento nell'inserimento dei dati di notifica.

Eseguire aggiunte alla tabella di notifica solo all'interno di una regola di sottoscrizione. Durante l'elaborazione di regole di sottoscrizione, Notification Services prepara ogni esecuzione di regole, attiva le regole e quindi esegue le necessarie operazioni di pulitura dopo l'esecuzione. Se si tenta di inserire notifiche all'esterno dell'esecuzione di una regola di sottoscrizione, la preparazione e la pulitura non avverranno, con conseguente generazione di errori.

Utilizzo di una clausola WHERE per condizioni aggiuntive

Se lo schema di sottoscrizione include più di un campo personalizzato, è possibile aggiungere una clausola WHERE per specificare condizioni aggiuntive. Ad esempio, se l'applicazione per i dati metereologici consente ai sottoscrittori di immettere un intervallo di temperature, è possibile aggiungere la clausola seguente all'esempio di codice precedente:

WHERE  e.HighTemp > s.High 
    OR e.LowTemp < s.Low

A causa di questa clausola WHERE, l'azione genererà notifiche solo se il valore HighTemp nell'evento è superiore all'intervallo immesso dal sottoscrittore oppure se il valore LowTemp nell'evento è inferiore all'intervallo immesso dal sottoscrittore.

[!NOTA] Se si definisce un'applicazione in un file XML, è necessario sostituire i caratteri XML riservati, ad esempio "<", con i relativi riferimenti a entità. Per ulteriori informazioni, vedere XML Reserved Characters.

Altre clausole

Transact-SQL supporta molte altre clausole per l'istruzione SELECT. Tuttavia, la maggioranza di esse non è rilevante per Notification Services. Ad esempio, la clausola ORDER BY ordina i risultati della query SELECT, ma tale ordine non influenza il modo o il momento in cui Notification Services formatta e recapita le notifiche. La clausola UNION può essere utilizzata per combinare i risultati di due query, ma viene raramente utilizzata per le regole di sottoscrizione.

Utilizzo di stored procedure

Anzichè incorporare istruzioni Transact-SQL nell'azione, è possibile che quest'ultima chiami una stored procedure. È necessario creare la stored procedure nel database dell'applicazione. È possibile definire la stored procedure in uno script di distribuzione. È consigliabile creare la stored procedure dopo la creazione dell'istanza o l'aggiunta dell'applicazione da parte di Notification Services, ma prima di attivare l'istanza o l'applicazione.

Per utilizzare una stored procedure, eseguirla dall'azione. Nell'esempio seguente viene illustrata un'azione che esegue una stored procedure:

EXECUTE dbo.WeatherActionSP;

Transazioni

Tutte le istruzioni in un'azione sono parte della stessa transazione, quindi vengono tutte completate correttamente oppure di tutte viene eseguito il rollback. Se la transazione non riesce, Notification Services scriverà un errore nel registro delle applicazioni di Windows.

Azioni per le regole eventi

Le azioni delle regole eventi in genere selezionano dati degli eventi da una vista denominata in base alla classe di evento. Questa vista di eventi include solo il set di eventi corrente, assicurando che l'azione non utilizzi eventi precedenti dalla tabella degli eventi.

Attenzione:

Non utilizzare la tabella degli eventi, il cui nome è NSEventClassNameEvents, come origine degli eventi. Le tabelle degli eventi includono tutti gli eventi non rimossi dall'applicazione e determineranno la generazione nell'applicazione di notifiche duplicate. Inoltre, non inserire mai notifiche direttamente nella tabella delle notifiche. Inserire invece le notifiche nella vista denominata in base alla classe di notifica.

Modello

Il modello seguente mostra la struttura di base di un'azione per una regola di eventi. Questo modello di azione mostra come unire in join eventi dalla vista di eventi e sottoscrizioni dalla vista delle sottoscrizioni e come inserire i risultati nella vista delle notifiche.

INSERT INTO schema.notificationClassName (SubscriberId, DeviceName, 
    SubscriberLocale, NotificationFields)
SELECT s.SubscriberId, DeviceName, SubscriberLocale, Fields
FROM schema.subscriptionClassName s 
JOIN schema.eventClassName e
ON s.columnName = e.columnName
[WHERE...][;]

È possibile selezionare i valori DeviceName e SubscriberLocale da un'origine dei dati, ad esempio la vista di sottoscrizione, oppure specificare valori letterali, ad esempio "File" e "en-US".

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

Manutenzione della cronologia degli eventi

È inoltre possibile utilizzare le regole di eventi per la manutenzione delle cronologie degli eventi. Questo consente alla regola di eventi di utilizzare la cronologia degli eventi precedente per verificare i valori di evento precedenti prima di generare le notifiche. È possibile creare una nuova regola di eventi per la manutenzione della cronologia oppure aggiungere il codice per la manutenzione alle istruzioni per una regola eventi esistente.

[!NOTA] In presenza di più regole di eventi, Notification Services può attivare le regole in qualsiasi ordine.

La regola seguente anzitutto elimina tutti i dati dalla cronologia degli eventi. Quindi, la regola seleziona il batch di eventi corrente dalla vista WeatherEvents e aggiunge gli eventi alla cronologia degli eventi.

DELETE FROM dbo.WeatherEventsChron;
INSERT INTO dbo.WeatherEventsChron(City, Date, Low, High, Forecast)
SELECT e.City, e.Date, e.Low, e.High, e.Forecast
FROM dbo.WeatherEvents e;

Per aggiornare la cronologia degli eventi prima di generare le notifiche, definire la regola della cronologia degli eventi nella classe di evento. Per ulteriori informazioni, vedere Definizione delle regole di cronologia degli eventi.

Per definire un'azione per una regola eventi

Se si definisce un'applicazione tramite XML, le azioni vengono definite nel file di definizione dell'applicazione (ADF). Se si definisce un'applicazione a livello di programmazione, utilizzare Notification Services Management Objects (NMO) per definire le azioni.

• Action Element for EventRule (ADF)
• Proprietà Action (NMO)

Azioni per le regole pianificate

Le azioni delle regole pianificate in genere selezionano i dati degli eventi da una cronologia degli eventi, non dalla vista degli eventi. La vista degli eventi include solo il batch di eventi correnti e può essere vuota quando viene eseguita la regola pianificata.

Modello

Il modello seguente mostra la struttura di base di un'azione per una regola pianificata. Questo modello di azione mostra come unire in join eventi da una cronologia degli eventi e sottoscrizioni dalla vista delle sottoscrizioni e come inserire i risultati nella vista delle notifiche.

INSERT INTO schema.notificationClassName (SubscriberId, DeviceName, 
    SubscriberLocale, NotificationFields)
SELECT s.SubscriberId, DeviceName, SubscriberLocale, Fields
FROM schema.subscriptionClassName s 
JOIN schema.eventChronicleName ec
ON s.columnName = ec.columnName
[WHERE...][;]

Nell'istruzione SELECT è possibile selezionare i valori DeviceName e SubscriberLocale da un'origine dei dati, ad esempio la vista di sottoscrizione, oppure specificare valori letterali, ad esempio "File" e "en-US".

Manutenzione della cronologia delle sottoscrizioni

È inoltre possibile utilizzare le regole pianificate per la manutenzione delle cronologie delle sottoscrizioni. Per ulteriori informazioni sulle cronologie delle sottoscrizioni, vedere Definizione di cronologie per una classe di sottoscrizione. È possibile creare una nuova regola pianificata per la manutenzione della cronologia oppure aggiungere il codice per la manutenzione alle istruzioni per una regola pianificata esistente.

[!NOTA] In presenza di più regole pianificate, Notification Services può attivare le regole in qualsiasi ordine.

Per definire un'azione per una regola pianificata

Se si definisce un'applicazione tramite XML, le azioni vengono definite nel file di definizione dell'applicazione (ADF). Se si definisce un'applicazione a livello di programmazione, utilizzare NMO per definire le azioni.

• Action Element for ScheduledRule (ADF)
• Proprietà Action (NMO)

Vedere anche

Concetti

Definizione di azioni condizionali
Definizione delle regole eventi
Definizione delle regole pianificate

Altre risorse

WHERE (Transact-SQL)
INSERT (Transact-SQL)
SELECT (Transact-SQL)
Definizione delle classi di sottoscrizione

Guida in linea e informazioni

Assistenza su SQL Server 2005