Notificações por push com os Hubs de Notificação do Azure: perguntas frequentes

Os Hubs de Notificação do Azure têm dois níveis de recursos: hubs e namespaces. Um hub é um recurso de envio por push único que pode conter as informações de push de plataforma cruzada de um aplicativo. Um namespace é uma coleção de hubs em uma região. Mapeamento recomendado corresponde a um namespace com um único aplicativo. Dentro do namespace, você pode ter um hub de produção que funciona com o seu aplicativo de produção, um hub de teste que funciona com o seu aplicativo de teste e assim por diante.

Os detalhes de preços mais recentes podem ser encontrados na página Preços dos Hubs de Notificação. Os Hubs de Notificação são cobrados no nível de namespace. (Para a definição de um namespace, veja "Qual é a estrutura de recursos dos Hubs de Notificação?") Os Hubs de Notificação oferecem três camadas:

• Livre: esta camada é um bom ponto de partida para explorar os recursos de envio. Não é recomendável para aplicativos de produção. Você obterá 500 dispositivos e 1 milhão de pushes incluídos por assinatura por mês, sem garantia de contrato de nível de serviço (SLA).
• Básico: essa camada (ou a Standard) é recomendável para aplicativos de produção menores. Você obterá 200.000 dispositivos e 10 milhões de pushes incluídos por assinatura por mês como uma linha de base.
• Padrão:essa camada é recomendada para aplicativos de produção médios a grandes. Você obterá 10 milhões de dispositivos e 10 milhões de pushes incluídos por assinatura por mês como uma linha de base. Inclui telemetria avançada (dados adicionais sobre status de push fornecido).

Recursos de camada padrão:

• Telemetria avançada: você pode usar os Hubs de Notificação por Telemetria de Mensagem para rastrear quaisquer solicitações de envio por push e Comentários do Sistema de Notificação de Plataforma para depuração.
• Multilocação: você pode trabalhar com as credenciais do Sistema de Notificação de Plataforma em um nível de namespace. Esta opção permite que você dividida locatários facilmente em hubs no mesmo namespace.
• Push agendado: você pode agendar que notificações sejam enviadas a qualquer momento.
• Operações em massa: habilita a funcionalidade de exportação/importação de registros, conforme descrito no documento Importação/Exportação de Registros.

Para camadas Basic e Standard dos Hubs de Notificação, os aplicativos configurados corretamente podem enviar notificações por push ou executar operações de gerenciamento de registro pelo menos 99,9% do tempo. Para saber mais sobre o SLA, vá para a página SLA de Hubs de Notificação.

Vá para o portal do Azure>Namespaces de Hubs de Notificação ou Hubs de Notificação. Selecione o recurso que você deseja atualizar e vá para Tipo de Preço. Observe os seguintes requisitos:

• O tipo de preço atualizado se aplica a todos os hubs no namespace com o qual você está trabalhando.
• Se a contagem de dispositivos exceder o limite da camada que você estiver fazendo downgrade para, você precisa excluir dispositivos antes de você fazer o downgrade.

Os SDKs do servidor estão disponíveis para .NET, Java, Node. js, PHP e Python. As APIs de Hubs de Notificação baseiam-se em interfaces REST, portanto, você pode trabalhar diretamente com as APIs REST se você estiver usando diferentes plataformas ou não desejar dependência extra. Para saber mais, vá para a página APIs REST de Hubs de Notificação.

As notificações por push têm suporte para plataformas iOS, Android, Windows Universal, Windows Phone, Android China (via Baidu), Xamarin iOS e Android e Safari. Para saber mais, consulte a página tutoriais de Introdução aos Hubs de Notificação.

Os Hubs de Notificações enviam notificações para dispositivos que executam aplicativos móveis. Ele não fornece email ou texto recursos de mensagem. Os Hubs de Notificação também não oferecem um serviço de entrega de notificações por push no navegador pronto para uso. Os clientes podem implementar esse recurso usando o SignalR sobre as plataformas com suporte do lado do servidor.

Veja a página Preços dos Hubs de Notificação para obter detalhes sobre o número de dispositivos com suporte.

Se você precisar de suporte para mais de 10 milhões de dispositivos registrados, deverá particionar seus dispositivos em vários namespaces.

Dependendo da camada selecionada, o Hubs de Notificação do Azure escalará verticalmente de forma automática, com base no número de notificações fluindo pelo sistema.

Nossos clientes usam os Hubs de Notificação para enviar milhões de notificações por push por dia. Você não precisa fazer nada especial para dimensionar o alcance de suas notificações por push, desde que esteja usando os Hubs de Notificação do Azure.

Em um cenário de uso normal, onde a carga de entrada é consistente e uniforme, os Hubs de Notificação do Azure conseguem processar pelo menos um milhão envios por push em um minuto. Essa taxa pode variar dependendo do número de marcas, da natureza dos envios de entrada e outros fatores externos.

Durante o tempo de entrega estimado, o serviço calcula os destinos por plataforma e encaminhar mensagens para o PNS (Serviço de Notificação por Push) com base em expressões de marca/marcas registradas. É responsabilidade do PNS para enviar notificações para o dispositivo.

O PNS não garante qualquer SLA para entregar notificações. No entanto, a maioria das notificações de push é entregue aos dispositivos de destino em poucos minutos (normalmente em 10 minutos) desde o momento em que eles são enviados para os Hubs de Notificação. Algumas notificações podem levar mais tempo.

Devido à natureza das notificações por push (entregues por uma plataforma PNS externa específica), não há nenhuma garantia de latência. Normalmente, a maioria das notificações por push é entregue em alguns minutos.

Os Hubs de Notificação do Azure armazenam dados de registro do cliente na região selecionada pelo cliente. Os Hubs de Notificação fornecem uma cobertura de recuperação de desastre de metadados (o nome de Hubs de Notificação, a cadeia de conexão e outras informações fundamentais). Para todas as regiões, exceto o Sul do Brasil e o Sudeste da Ásia, o backup de metadados é hospedado em uma região diferente (geralmente a região emparelhada do Azure). Apenas para as regiões Sul do Brasil e Sudeste da Ásia, os backups são armazenados na mesma região para acomodar os requisitos de residência de dados dessas regiões.

Ambiente/aplicativo móvel

• Use um hub de notificação por aplicativo móvel, por ambiente.
• Em um cenário multilocatário, cada locatário deve ter um hub separado.
• Nunca compartilham o mesmo hub de notificação para produção e ambientes de teste. Essa prática pode causar problemas ao enviar notificações. (A Apple oferece pontos de extremidade de área restrita e push de produção, cada qual com credenciais separadas).
• Por padrão, você pode enviar notificações de teste para seus dispositivos registrados por meio do portal do Azure ou do componente integrado do Azure no Visual Studio. O limite é definido como 10 dispositivos selecionados aleatoriamente do pool de registro.

Credenciais PNS

Quando um aplicativo móvel é registrado com o portal do desenvolvedor da plataforma (por exemplo, Apple ou Google), um aplicativo identificador e tokens de segurança são enviadas. O back-end do aplicativo fornece esses tokens para o PNS da plataforma para que as notificações por push possam ser enviadas aos dispositivos. Tokens de segurança podem ser na forma de certificados (por exemplo, Apple iOS ou Windows Phone) ou chaves de segurança (por exemplo, Google Android ou Windows). Eles devem ser configurados em hubs de notificação. A configuração normalmente é feita no nível do hub de notificação, mas também pode ser feita no nível do namespace em um cenário de multilocatário.

Namespaces

Os namespaces podem ser usados para o agrupamento de implantação. Eles também podem ser usados para representar todos os hubs de notificação para todos os locatários do mesmo aplicativo em um cenário de multilocatário.

Distribuição geográfica

A distribuição geográfica nem sempre é crítica em cenários de notificações por push. Vários PNSes (por exemplo, APNs ou FCM) que fornecem notificações por push a dispositivos não são distribuídos uniformemente.

Se você tiver um aplicativo que é usado globalmente, poderá criar hubs em namespaces diferentes usando o serviço de Hubs de Notificação em diferentes regiões do Azure em todo o mundo.

Registros de back-end do aplicativo são úteis quando você precisa autenticar clientes antes de criar o registro. Eles também são úteis quando há marcas que devem ser criadas ou modificadas pelo back-end do aplicativo com base na lógica do aplicativo. Para saber mais, vá até as páginas Diretrizes de registro de back-end e Diretrizes de registro de back-end 2.

Os Hubs de Notificação do Azure usam um modelo de segurança baseado em assinatura de acesso compartilhado. Você pode usar os tokens de assinatura de acesso compartilhado no nível do namespace raiz ou no nível granular de hubs de notificação. Os tokens de Assinatura de Acesso Compartilhado podem ser definidos a seguir diferentes regras de autorização, por exemplo, para enviar as permissões de mensagens ou para escutar permissões de notificação de assinatura de acesso. Para saber mais, veja o documento modelo de segurança de Hubs de Notificação.

Todas as notificações são entregues aos dispositivos de destino pelos PNS da plataforma. Quando uma notificação é enviada para Hubs de Notificação do Azure, é processada e passada para o respectivo PNS.

Todas as conexões do remetente para os Hubs de Notificações do Azure e para o PNS usam HTTPS.

Para enviar cargas confidenciais, é recomendável usar um padrão Push seguro. O remetente fornece uma notificação de ping com um identificador de mensagem para o dispositivo sem a carga confidencial. Quando o aplicativo no dispositivo recebe a carga, o aplicativo chama uma API segura diretamente para buscar os detalhes da mensagem. Para obter um guia sobre como implementar esse padrão, vá para a página tutorial de Push Seguro de Hubs de Notificação.

Consulte Alta disponibilidade para Hubs de Notificação do Microsoft Azure.

Os Hubs de Notificação do Azure criptografam todos os dados inativos do cliente com exceção das marcas de registro. Por esse motivo, você não deve armazenar dados pessoais ou confidenciais usando marcas.

Sim. Todas as operações de Gerenciamento de Hubs de Notificação atualizam o Log de Atividades do Azure para o qual está exposto no portal do Azure. O Log de Atividades do Azure fornece análises das operações executadas nos recursos em sua assinatura. Usando o Log de Atividades, você pode determinar o quê, quem e quando de qualquer operação de gravação (PUT, POST, DELETE) feita para os recursos em sua assinatura. Também é possível compreender o status da operação e outras propriedades relevantes. No entanto, o Log de Atividades não inclui as operações de leitura (GET).

Se você armazenou o dispositivo como um Registration, na primeira vez que enviar para esse registro e o PNS responder com um código de status de erro que indica que o dispositivo não é válido, o dispositivo será excluído do seu hub de notificação.

Se você armazenou seus dispositivos usando as APIs Installation, eles não serão excluídos no cenário acima. Essa decisão foi tomada para preservar marcas e outros metadados sobre um usuário específico que podem ser relevantes se o usuário reinstalar.

Para registros e instalações, você pode definir uma expiração para que o dispositivo seja limpo automaticamente em um determinado momento. Um padrão comum é fazer com que o aplicativo cliente atualize essa data de validade uma vez por dia para prorrogá-la enquanto o usuário estiver usando sua aplicação.

Os Hubs de Notificação do Azure fornecem vários recursos para a solução de problemas, principalmente no cenário de notificações removidas. Para obter detalhes, veja o white paper Solução de problemas de Hubs de Notificação.

Os Hubs de Notificação do Azure permitem a exibição de dados de telemetria no portal do Azure. Os detalhes das métricas estão disponíveis na página Métricas de Hubs de Notificação.

Você também pode acessar métricas programaticamente. Para obter mais informações, confira os seguintes artigos:

• Por exemplo, consulte Recuperar métricas do Azure Monitor com .NET. Este exemplo usa o nome de usuário e a senha. Para usar um certificado, sobrecarregue o método FromServicePrincipal para fornecer um certificado, conforme mostrado neste exemplo.
• Obter métricas e logs de atividade para um recurso
• Passo a passo da API REST de Monitoramento do Azure