Questions? Feedback? powered by Olark live chat software
Ignorar Navegação

Updates from Notification Hubs: Independent NuGet, Installation model, PMT, and more

Publicado em 10 novembro, 2015

Program Manager, Azure App Service

We strive to deliver a smooth developing experience and some handy features to our customers. Check out what we’ve been working on for the past few months:

  • Notification Hubs is officially an independent service, separated from Azure Service Bus, with its independent NuGet.
  • We introduced a new push model, the Installation model, in handling your devices and notifications. The model aligns with Platform Notification Systems and is enhanced to eliminate redundant or stale registrations.
  • Per Message Telemetry gives detailed outcomes of your send requests to Notification Hubs.
  • Multi-tenancy is easier than ever now that you can work with credentials at the namespace level.
  • Push variables simplifies sending individually customized broadcast notifications.
  • Direct Send lets you push without registering devices with Notification Hubs.

Notification Hubs' independent Nuget

Notification Hubs is now officially split from Service Bus. We want to point you to our independent NuGet that communicates with the Notification Hubs gateway and works with "Notification Hub" typed namespace, along with its SDK reference.

Our independent NuGet will also be introduced in an upcoming Azure SDK release.

Remember to convert your Mixed Namespace!

The Mixed Notification Update is almost complete! If you have mixed namespaces utilizing both Notification Hubs and Service Bus features, we need your help to complete this conversion to facilitate better user experience for the future. You will need to find your “Mixed” namespace and move any Queues/Topics/Relays/Event Hubs to a new “Messaging” typed namespace. The “Mixed" namespace, once contains only Notification Hubs, will be converted to "Notification Hub" type automatically.

Converting namespaces utilizing Notification Hubs features to their designated type is crucial for customers to continue to benefit from any new feature rollouts and bug fixes.

The new, shiny Installation model

[REST, NuGet, Node.js, Java]

We want to introduce you to the Installation model, a new way to use Notification Hubs and manage your devices and notifications. An Installation is a JSON bag that carries all properties you need for a specific Installation on a device (push channel, tags, templates, etc.). This model is designed to make working with Notification Hubs easier and more intuitive. A few reasons why we love Installations and think you will too:

  • Installation aligns with the device-based model used by major Platform Notification Systems, including APNs, GCM, WNS, etc.
  • Installation organizes and consolidates push related information. This simplifies the complexity in maintaining a list of registrations for each device.
  • Installation provides a stronger protection against duplicated notifications.
  • Installation adds single device targeting as a first-class functionality, allowing sends to individual Installation IDs.
  • Installation allows patching.
  • Installation ID is user-specified, and you can link up your device/user GUID with the Installation.

A typical work flow with Installation looks like this:

  • Create an Installation object in client
  • Register the Installation object with Notification Hubs
  • Store Installation ID in device on success for future access
  • Send notifications (to give you an easy start, the push interface is identical to that for the previous Registration model)

Many of you might have already played with our SDKs (.NET, Node.js, Java), and here are our REST documentations:

Per Message Telemetry

[REST]

In an effort to provide the best monitoring and diagnostic experience, we are very excited to introduce Per Message Telemetry. Given a send request’s Notification ID, you can now retrieve the status of your request and its push outcomes. We track when your request is processed, amongst other platform-specific results such as:

  • # of success sends
  • # of invalid credentials
  • # of PNS unreachable
  • # of bad channels
  • # of PNS server error
  • # of channel throttled
  • # of skipped (duplicate registrations)

You can see the complete list of outcomes for each platform in the documentation here. We are confident that this will greatly improve your development experience working with notifications.

Multi-tenancy

[REST]

Multi-tenancy is easier than ever before, now that you can work with push system credentials at the namespace level. The Namespace Push Notification Services (PNS) APIs are designed for large apps that span across multiple hubs. They enable developers to easily read and update unified PNS settings for multiple hubs under the same namespace at once. Set push credentials and certificates at the namespace level and see them automatically applied to all hubs within the namespace.

Push Variables

[REST, currently available with Registration model]

The new Push Variables feature provides you the convenience of associating up to 60 string key-value pairs with each device registration, both native and template. On send, users are able to use registered keys as placeholders while Notification Hubs substitutes in the corresponding value for each send at runtime. This is very useful because:

  • The push variables feature consumes JSON key-value paired dictionary, making it easy to use and customize.
  • Developers can store user or device information per registration and use them in any messages. This strips the formatting restrictions of template push notifications and allows more message variations.
  • Push variables can be used with default values on send in case a paired value does not exist for certain registrations.

The feature is an extension of the existing registration design on api-version=2015-04 and later versions:

<{Platform}RegistrationDescription xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://schemas.microsoft.com/netservices/2010/10/servicebus/connect">
    <Tags>myTag, myOtherTag</Tags>
    <ChannelUri>{ChannelUri}</ChannelUri>
    ...
    <PushVariables>{"key1":"value1","key2":"value2"}</PushVariables>
</{Platform}RegistrationDescription>

The push variables parameter is essentially a dictionary:

PushVariables = new Dictionary<string, string> {{"deviceUser", "Jane"}, {"deviceLocation", "London"}}

On top of compatibility with templates and support for all expressions accepted by templates, Push Variables also supports default values. When using send with push variables and/or with templates, users can specify the default value a key should take on if it is not found in individual registrations or template registrations with $(key:{defaultValue}). "Good morning, $(firstName:{friend})" will push "Good morning, friend" to registrations without a firstName key specified.

Direct Send

[REST, NuGet]

With Direct Send, you are able to send a notification directly to a PNS handle. This feature is great for customers who choose to manage their own devices or use Notification Hubs to deliver to unregistered devices.

What’s next?

If you are a mixed namespace user, make sure you follow the above to convert your mixed namespaces. Otherwise, have fun with our updates and drop us a note in the comments below or nhtalk@microsoft.com if you have any questions or feedback!