Введение в службы Notification Services

Определение класса подписки.Введите или вставьте следующий XML-фрагмент ниже комментария <!— Subscription Classes —>:

<!— Subscription Classes —> 
<SubscriptionClasses> 
  <SubscriptionClass>
    <SubscriptionClassName>SightRegionSubs</SubscriptionClassName> 
    <Schema> 
      <Field> 
        <FieldName>DeviceName</FieldName> 
        <FieldType>nvarchar(255)</FieldType> 
        <FieldTypeMods>not null</FieldTypeMods> 
      </Field> 
      <Field>
        <FieldName>SubscriberLocale</FieldName> 
        <FieldType>nvarchar(10)</FieldType> 
        <FieldTypeMods>not null</FieldTypeMods> 
      </Field> 
      <Field>
        <FieldName>RegionID</FieldName> 
        <FieldType>varchar(5)</FieldType> 
        <FieldTypeMods>not null</FieldTypeMods> 
      </Field> 
    </Schema> 
    <EventRules> 
      <EventRule>
        <RuleName>SightRegionEventRule</RuleName>
        <EventClassName>SightData</EventClassName> 
        <Action>
          INSERT INTO SightAlerts(SubscriberId, DeviceName, SubscriberLocale, 
             Region, Date, Observation, Category) 
          SELECT s.SubscriberId, s.DeviceName, s.SubscriberLocale,
                 e.RegionID, e.Date, e.Observation, e.Category 
             FROM SightData e, SightRegionSubs s 
             WHERE e.RegionID = s.RegionID; 
        </Action> 
      </EventRule> 
    </EventRules> 
  </SubscriptionClass> 
</SubscriptionClasses>

Объявление схем подписки аналогично объявлению классов событий в предыдущем разделе. Как и в предыдущем случае, мы указываем вместо имени таблицы имя класса подписки, затем имена полей и т. д.

Определение подписки включает один важный объект: правило сопоставления событий. В правиле после класса событий указывается имя, к которому оно относится, а затем инструкция T-SQL, которая задает действующее правило.

Для понимания этого правила нам придется немного забежать вперед. Задача инструкции RULE – вставка записей в таблицу, или класс, уведомлений, который мы еще не определили. Следовательно, ни имя таблицы назначения, ни поля, которые она содержит, нам не известны. Они будут определены ниже при определении класса уведомлений.

Инструкция RULE собирает необходимые столбцы из двух исходных классов: класса событий и класса подписки, а также, что еще более важно, включает ключ для понимания отношения между этими двумя классами. В приведенном выше коде правило сопоставления сопоставляет идентификатор RegionID из класса событий идентификатору RegionID из класса подписки. Таким образом, подписчики получат уведомления, когда будет выполнено наблюдение в регионе, хранящемся в записи о подписке каждого подписчика.

Определение класса уведомлений.Введите или вставьте следующий XML-фрагмент ниже комментария <!— Notification Classes —>:

<!— Notification Classes —> 
  <NotificationClasses> 
    <NotificationClass>
      <NotificationClassName> SightAlerts </NotificationClassName> 
      <Schema> 
        <Fields> 
          <Field>
            <FieldName>Region</FieldName> 
            <FieldType>nvarchar(35)</FieldType> 
          </Field> 
          <Field>
            <FieldName>Date</FieldName> 
            <FieldType>datetime</FieldType> 
          </Field> 
          <Field>
            <FieldName>Observation</FieldName> 
            <FieldType>nvarchar(500)</FieldType> 
          </Field> 
          <Field>
            <FieldName>Category</FieldName> 
            <FieldType>char(1)</FieldType> 
          </Field> 
        </Fields> 
      </Schema> 
      <ContentFormatter>
        <ClassName>XsltFormatter</ClassName> 
        <Arguments> 
          <Argument>
            <Name>XsltBaseDirectoryPath</Name> 
            <Value>%_AppPath_%</Value> 
          </Argument> 
          <Argument>
            <Name>XsltFileName</Name> 
            <Value>BirdingTransform.xslt</Value> 
          </Argument> 
        </Arguments> 
      </ContentFormatter> 
      <Protocols> 
        <Protocol>
          <ProtocolName>File</ProtocolName> 
        </Protocol> 
      </Protocols> 
    </NotificationClass> 
  </NotificationClasses>

Здесь содержимое схемы класса уведомлений также достаточно понятно, но содержит кое-что неожиданное. В данном случае схеме сопутствует элемент ContentFormatter. Элемент ContentFormatter указывает, какой компонент будет отвечать за формирование уведомления в окончательном виде. Подробнее об этом элементе будет рассказано ниже в разделе "Как скомпоновать сообщение уведомления?"

Определение поставщиков.Введите или вставьте следующий XML-фрагмент ниже комментария <!— Replace with Providers —>:

<!- Providers XML -> 
<Providers>
  <NonHostedProvider>
    <ProviderName>BirdingSPEventProvider</ProviderName>
  </NonHostedProvider> 
</Providers>

Этот XML-фрагмент показывает, что поступит по маршруту, который находится не под управлением служб Notification Services. Нажмите кнопку Save (Сохранить) на панели инструментов, чтобы сохранить файл BirdingADF.xml, не потеряв изменений.

Изменяем конфигурацию экземпляра

На следующем этапе необходимо отредактировать ICF-файл. Этот файл представляет собой исходную точку, через которую службы Notification Services будут выполнять синтаксический анализ конфигурационных файлов и осуществлять все необходимые действия. Следовательно, он содержит некоторую основную информацию и данные, специфичные для экземпляра.

Откройте для редактирования файл SQL2005StepByStepICF.xml, выполнив двойной щелчок на файле в окне Solution Explorer (Обозреватель решений). Нужно будет изменить его содержимое так, чтобы оно соответствовало действующей конфигурации компьютера.

• В начале ICF-файла определяются параметры, которые будут использоваться в различных частях этого файла. Параметры _ DBEngineInstance_ и _ServerName_ будут использоваться многократно при определении ядра базы данных и сервера, поддерживающего экземпляр служб Notification Services. Если ваша конфигурация не отличается от указанной, оставьте значения без изменения.
• Параметр _InstancePath_ показывает, в какой папке службы Notification Services будут искать файлы ICF. Измените его значение так, чтобы он указывал на папку, в которой мы сохранили проект служб Notification Services.
• Обратите внимание на значение элемента InstanceName, которое в данном примере равно SQL2005StepByStep.
• SqlServerSystem - это используемый сервер. Обратите внимание на то, что он просто уточняет параметр, определенный выше.
• Элемент Applications содержит список и детали всех приложений, которые зависят от определяемого экземпляра.
• Каждый элемент Application содержит имя приложения, каталог, в котором размещен соответствующий файл ADF, и имя ADF-файла. Обратите внимание на то, что текущий файл использует параметры, которые определены в начале этого файла.
• Элемент DeliveryChannels объявляет доступные каналы и их свойства. В данном сценарии для облегчения восприятия указан только один канал file. Этот канал file требует аргумента в виде физического пути к файлу. Измените путь так, чтобы он соответствовал размещению папки Notifications, которая была создана в действии 6 ранее описанной процедуры "Создаем проект и решение SQL Server 2005 Management Studio"..
  Предупреждение. Не забудьте отредактировать параметр _InstancePath_ и аргумент FileName канала доставки, чтобы они соответствовали путям к файлам в вашей системе. Если вы этого не сделаете, экземпляр служб Notification Services не будет функционировать должным образом.

  Нажмите кнопку Save (Сохранить), чтобы сохранить файл ICF и не потерять изменения.

  Дополнительная информация Для определения объектов в файле ICF можно указать дополнительные параметры. Информацию о доступных элементах можно найти в Электронной документации по SQL Server 2005 в теме "Справочник по файлам определения экземпляра".