Уведомления Windows 8: Push-уведомления через веб-сайты Windows Azure (часть 3)

Последний флажок на странице подтверждает согласие с правовой политикой и политикой конфиденциальности ClearDB, поскольку они управляют экземплярами базы данных MySQL.

После ввода необходимых данных для предоставления сайта и базы данных требуется всего одна или две минуты, в течение которых статус отражается на портале. Когда сайт доступен, его можно выбрать из списка веб-сайтов на портале Azure, чтобы открыть экран «Начало работы» ниже:

На данный момент сайт (с контентом по умолчанию) фактически активен, что можно подтвердить, нажав кнопку BROWSE в строке меню в нижней части экрана.

Чтобы получить информацию, необходимую для разработки и развертывания службы, я в следующий раз посещаю опцию DASHBOARD, которая предоставляет доступ к параметрам конфигурации номера. Мне особенно нужны первые два, перечисленные в боковой панели быстрого просмотра в правой части страницы панели инструментов:

1. Я буду использовать строку подключения MySQL для создания таблиц, необходимых для хранения URI уведомлений для различных клиентов, и
2. Я сохраню профиль публикации (как локальный файл) для последующего импорта в Visual Studio 2012. Это позволит мне развернуть приложение ASP.NET непосредственно в Windows Azure. Помните, что этот файл содержит конфиденциальную информацию, позволяющую развертывание в облаке, поэтому будьте осторожны с файлом настроек публикации.

На этом этапе мне даже не нужно повторно заходить на портал Windows Azure, но, конечно, есть ряд замечательных функций мониторинга и масштабирования, с которыми я, возможно, захочу ознакомиться, когда мой сайт заработает.

Шаг 3. Настройте базу данных MySQL

В реализации службы Web API я использую Code First Entity Framework (EF) вместе с базовым шаблоном репозитория на ОЧЕНЬ простой модели данных, которая абстрагирует две таблицы с определениями столбцов, показанными ниже.

Я использовал MySQL Workbench с открытым исходным кодом (с данными строки подключения на портале Windows Azure) для создания таблиц и заполнения данных в таблице команд . Есть также очень простая хранимая процедура, которая вызывается одним из сервисных методов, о которых я расскажу чуть позже в этом посте:

CREATE PROCEDURE updatechanneluri 
          (IN olduri VARCHAR(2048), IN newuri VARCHAR(1024))
BEGIN
   UPDATE registrations SET Uri = newuri WHERE Uri = olduri;
END

Поскольку я выбрал MySQL, мне нужно было установить поставщика, и, в частности, я установил Connector / Net 6.6.4, который поддерживает Entity Framework и Visual Studio 2012. На момент написания этой статьи версия Connector / Net, доступная через NuGet, не поддерживалась. ,

Шаг 4. Создайте API для облачной службы

Существует множество вариантов создания облачной службы на веб-сайтах Windows Azure — .NET, PHP, Node.js — и нескольких инструментов, таких как Visual Studio и Web Matrix . Я решил использовать ASP.NET MVC и веб-API в .NET 4.5 в Visual Studio 2012 (как вы можете видеть ниже).

Если вы новичок в веб-API ASP.NET MVC , я настоятельно рекомендую ознакомиться с короткой заставкой Джона Гэллоуэя, посвященной веб-API ASP.NET, часть 1: ваш первый веб-API, чтобы дать вам обзор компонентов проекта и общего архитектурного подхода.

Мой сервис включает в себя три контроллера : контроллер по умолчанию, контроллер регистрации и контроллер команд. Home Controller предоставляет веб-страницу по умолчанию для отправки уведомлений о тостах; Я посмотрю на это в шаге 6.

Два других контроллера специально расширяют ApiController и используются для реализации различных вызовов службы RESTful. Неудивительно, что каждый из них напрямую соответствует одному из двух классов модели данных Entity Framework (и, соответственно, таблицам MySQL). Эти контроллеры более или менее выполняют CRUD-операции над этими двумя таблицами.

Шаг 4.1. Программирование TeamsController

Приложение не изменяет какую-либо информацию о команде, поэтому необходимо выполнить только две операции чтения:

public Team Get(String id) 

извлекает информацию о данной команде по ее идентификатору: класс Team является одним из двух классов сущностей в моей модели Entity Framework.

Этот метод вызывается с помощью HTTP GET запроса , совпадающего с маршрутом http://boysofsummer.azurewebsites.net/api/teams/{id}, где идентификатор является коротким именем для команды, как RedSox или иволги .

public HttpResponseMessage GetLogo(String id, String fmt)

извлекает необработанные байты файла изображения для логотипа команды. Возврат значения HttpResponseMessage (в сравнении с фактическими данными) позволяет установить заголовки ответа (например, Content-type на «image / png»). Реализация этого метода в конечном счете достигает таблицы команд в MySQL, чтобы получить логотип, а затем записывает необработанные байты этого логотипа в виде StreamContent в возвращенном HttpResponseMessage . Если у команды нет файла логотипа, возвращается код состояния HTTP 404 .

Этот метод отвечает на запрос HTTP GET, соответствующий маршруту http://boysofsummer.azurewebsites.net/api/logos/ averageid broadcast/png, где id снова является коротким именем для данной команды.

Почему я не использовал MediaTypeFormatter? Если вы работали с веб-API, вы знаете, что он использует концепцию
согласования содержимого для возврата различных представлений одного и того же ресурса с помощью
заголовка Accept: в запросе, чтобы определить тип содержимого, которое следует отправлять в ответ. Например, ресурс
http://boysofsummer.azurewebsites.net/api/teams/redsox, безусловно, ссылается на Red Sox, но возвращает ли он информацию об этой команде в виде XML? как JSON? или что-то другое?

Подход, на который я надеялся, заключался в создании MediaTypeFormatter , который работает в сочетании с согласованием содержимого, чтобы определить, как форматировать результат. Поэтому я создал средство форматирования, которое будет возвращать необработанные байты изображения и тип содержимого image / png всякий раз, когда поступает запрос для команды с заголовком Accept, указывающим image / png. Любой другой запрошенный тип будет просто по умолчанию в JSON-представлении полей этой команды.

Однако, чтобы это работало, входящий запрос GET для URI должен соответствующим образом установить заголовок Accept. К сожалению, при создании запроса шаблона тоста (в XML) вы можете указать только сам URI, а запрос, который выдается для изображения (внутренним механизмом уведомлений Windows 8), включает в себя универсальный заголовок Accept : * / *

Моим выбранным путем наименьшего сопротивления было создание отдельного метода GET ( GetLogo выше) с дополнительным параметром пути, который якобы указывает желаемый формат представления (хотя в моем упрощенном случае формат всегда PNG).

Шаг 4.2. Кодирование регистраций контроллера

Контроллер Registrations включает три метода, которые управляют регистрациями уведомлений канала, которые связывают устройства пользователей приложения с командами, которые они заинтересованы в отслеживании. Как и следовало ожидать, эти методы манипулируют таблицей регистрации в MySQL через мою модель EF и реализацию репозитория.

public HttpResponseMessage Post(Registration newReg)

вставляет новую регистрационную запись в базу данных. Каждая запись регистрации отражает тот факт, что клиент (в настоящее время идентифицируемый данным URI канала уведомлений) заинтересован в отслеживании данной команды, идентифицировал идентификатор команды (или короткое имя). Комбинация канала URI и команды должна быть уникальной, поэтому при попытке вставить дубликат возвращается HTTP-код 409 (конфликт) ; успешная вставка дает 201 (Создано).

Этот метод POST вызывается приложением Магазина Windows каждый раз, когда пользователь перемещает тумблер уведомлений данной команды в положение «Вкл». Соответствующий шаблон URI: http://boysofsummer.azurewebsites.net/api/registrations, а тело запроса содержит URI канала и имя команды в формате JSON.

public HttpResponseMessage Delete(String id, String uri)

удаляет существующую запись из базы данных регистраций в ответ на отключение пользователем уведомлений для данной команды через интерфейс приложения Магазина Windows. Успешное удаление приводит к HTTP-коду 204 (без содержимого), в то время как попытка удалить несуществующую запись возвращает 404 (не найдено).

HTTP-метод DELETE здесь использует шаблон URI http://boysofsummer.azurewebsites.net/api/registrations/ndomid‹/ enjuri}, где id — это короткое имя команды, а uri — URI канала уведомления, закодированный в моей модификации Base64 .

public HttpResponseMessage Put(String id, [FromBody] UriWrapper u)

изменяет все существующие записи, соответствующие URI канала уведомлений, записанные в базе данных, с новым URI канала, предоставленным через тело сообщения. Это используется, когда указанный URI канала уведомлений клиента «истекает», и предоставляется новый, так что клиент может продолжать получать уведомления для групп, на которые он ранее подписался. Кстати, этот метод использует упомянутую ранее хранимую процедуру MySQL для более эффективного обновления потенциально нескольких строк.

Этот метод PUT соответствует шаблону URI http://boysofsummer.azurewebsites.net/api/registrations/ averageid}, где id — это предыдущий URI канала уведомлений, записанный в базе данных MySQL. Заменяющий URI передается через тело сообщения как простой объект JSON. Оба URI имеют кодировку Base64 (ish). Обновление возвращает 204 (без содержимого) независимо от того, совпадают ли какие-либо строки в таблице регистрации .

Шаг 5. Реализация ASP.NET MVC Page, которая выдает уведомления

Для примера, который я представляю здесь, я адаптировал домашнюю страницу ASP.NET MVC по умолчанию, чтобы обеспечить способ запуска уведомлений для конечных пользователей приложения Boys of Summer Windows Store. На данный момент это довольно ручной процесс, предполагающий, что кто-то сидит перед браузером — возможно, сканирует спортивные новостные издания на предмет интересных деталей для отправки. Это не невероятно масштабируемый сценарий, поэтому «в реальной жизни» может быть (полу) автоматизированный процесс, который подключается к различным RSS или другим каналам и автоматически генерирует соответствующие уведомления.

Контроллер здесь имеет два метода, GET и POST. GET — это простая однострочная строка, которая возвращает представление со списком команд, заполненных из модели через реализацию репозитория моей команды.

POST, который срабатывает при нажатии кнопки « Отправить уведомление» , является более интересным из двух методов и полностью представлен ниже со строковым комментарием.

[HttpPost]
public async Task<ActionResult> Index
       (String notificationHeader, String notificationBody, String teamName)
{
   // set XML for toast
    String toast = SetToastTemplate(notificationHeader, notificationBody,             
        String.Format("{0}api/logos/{1}", Request.Url, teamName));

    // send notifications to subscribers for given team
  List<NotificationResult> results = new List<NotificationResult>();
   foreach (Registration reg in RegistrationRepository.GetRegistrations(teamName))
   {
       NotificationResult result = 
                       await WNSHelper.PushNotificationAsync(reg.Uri, toast);
       results.Add(result);

       if (result.RequiresChannelUpdate())
           RegistrationRepository.RemoveRegistration(teamName, reg.Uri);
   }

   // show results of sending 0, 1 or multiple notifications
   ViewBag.Message = FormatNotificationResults(results);
 
   return View(TeamRepository.GetTeams().ToList());
}

Шаг 6. Внедрите интерфейс со службой уведомлений Windows (WNS)

Это забавная часть: обмен между моим облачным сервисом и WNS, который выполняет всю тяжелую работу с точки зрения фактической доставки тостов на устройства — с помощью реализации, стоящей за линией 14 выше:

await WNSHelper.PushNotificationAsync(reg.Uri, toast)

WNSHelper — это класс, который я написал, чтобы абстрагировать поток сообщений между службой и WNS, и, как таковая, является более простой (но менее надежной) версией кода рецепта WNS для Windows 8, доступной в Windows Azure Toolkit для Windows 8 (источником которой является находится в / библиотеки / WnsRecipe извлеченного инструментария). Код для WNSHelper доступен в Gist (если вы хотите погрузиться глубже), но здесь это в картинках:

Во-первых, мой сервис (через метод RefreshTokenAsync ) инициирует запрос токена доступа по протоколу OAuth 2.0 . Он использует Live Services для аутентификации SID пакета и секрета клиента, которые я получил в Магазине Windows при регистрации моего приложения. SID пакета и секрет клиента должны храниться в защищенном виде как часть облачной службы, поскольку они являются учетными данными, которые позволяют любому агенту отправлять push-уведомления в соответствующее приложение.

HTTP-запрос выглядит примерно так: Обратите внимание, что SID и секрет клиента являются частью параметров формы в кодировке URL, а также grant_type и scope, которые всегда устанавливаются в значения, которые вы видите здесь.

POST https://login.live.com/accesstoken.srf HTTP / 1.1 Тип содержимого: application / x-www-form-urlencoded Хост: login.live.com Длина содержимого: 210 grant_type = client_credentials & scope = notify.windows. com & client_id = REDACTED_SID & client_secret = REDACTED_SECRET

Предполагая, что аутентификация прошла успешно, ответное сообщение будет включать в себя токен доступа, в частности токен канала- носителя , который предоставляет презентатору (или «носителю») этого токена привилегии для выполнения некоторой операции в будущих HTTP-запросах. Ответное сообщение HTTP, предоставляющее этот токен, имеет вид:

HTTP/1.1 200 OK
Content-Type: application/json;charset=UTF-8
Cache-Control: no-store
Pragma: no-cache
{
  "access_token" : "mF_9.B5f-4.1JqM",
  "token_type" : "Bearer",
  "expires_in" : 86400
}

Токен доступа — это не более чем трудно угадываемая строка, но обратите внимание, что есть также параметр expires_in , который означает, что этот токен можно использовать только в течение дня (86400 секунд), после чего дополнительные запросы с использованием этого токена будут в результате код состояния HTTP 401 (неавторизованный). Это важно, и я вернусь к этому в ближайшее время.

После того как облачная служба получила токен-носитель, она теперь может отправлять несколько push-уведомлений в WNS, представляя этот токен в заголовке авторизации HTTP-запросов push-уведомлений. Фактический запрос отправляется на URI канала уведомлений, а тело сообщения представляет собой шаблон XML-тоста.

Ряд дополнительных заголовков HTTP также поддерживается в том числе X-WNS-Type , который используется для указания типа уведомления (тост, плитки, значок, или сырья) и X-WNS-RequestForStatus , который я использую , чтобы получить дополнительную информацию о распоряжение уведомлением.

POST https://bn1.notify.windows.com/?token=AgYAAADCM0ruyKK… HTTP/1.1
Content-Type: application/xml
Host: bn1.notify.windows.com
Authorization: Bearer mF_9.B5f-4.1JqM
X-WNS-Type: wns/toast
X-WNS-RequestForStatus: true
Content-Length: 311

<toast>
   <visual>
      <binding template="ToastImageAndText02">
          <image id="1" src="http://boysofsummer.azurewebsites.net/api/logos/tigers/png" />
          <text id="1">Breaking News!!!</text>
          <text id="2">The Detroit Tigers have won the ALCS!</text>
      </binding>
   </visual>
</toast>

  <system.data>
    <DbProviderFactories>
      <add name="MySQL Data Provider" invariant="MySql.Data.MySqlClient" 
            description=".Net Framework Data Provider for MySQL" 
            type="MySql.Data.MySqlClient.MySqlClientFactory, MySql.Data" />
    </DbProviderFactories>
  </system.data>

<x:String x:Key="ServiceUri">http://boysofsummer.azurewebsites.net:12072</x:String>