Documentação Campaign Notas técnicas do Campaign

v7 v8

Alterações no Canal de notificação por push

Última atualização: 5 de maio de 2025

Aplica-se a:
Campaign v8 Client Console

Tópicos:

Criado para:

Experiente
Administrador

Você pode usar o Campaign para enviar notificações por push em dispositivos iOs e Android. Para fazer isso, o Campaign depende dos serviços de assinatura de aplicativo móvel.

Algumas alterações importantes no serviço Android Firebase Cloud Messaging (FCM) foram lançadas em 2024 e podem afetar sua implementação do Adobe Campaign. A configuração dos serviços de assinatura para mensagens por push do Android pode precisar ser atualizada para dar suporte a essa alteração.

Além disso, o Adobe recomenda mudar para a conexão baseada em token para APNs em vez de uma conexão baseada em certificado, que é mais segura e escalável.

Serviço Google Android Firebase Cloud Messaging (FCM)

O que mudou?

Como parte do esforço contínuo do Google para melhorar seus serviços, as APIs herdadas do FCM serão descontinuadas em terça-feira, 22 de julho de 2024. Saiba mais sobre o protocolo HTTP do Firebase Cloud Messaging em documentação do Google Firebase.

O Adobe Campaign Classic v7 e o Adobe Campaign v8 já oferecem suporte às APIs mais recentes para enviar mensagens de notificação por push. No entanto, algumas implementações antigas ainda dependem das APIs herdadas. Essas implementações devem ser atualizadas.

Você será afetado?

Se sua implementação atual suportar serviços de assinatura conectados ao FCM usando as APIs herdadas, você será afetado. A transição para as APIs mais recentes é obrigatória para evitar qualquer perturbação do serviço. Nesse caso, as equipes do Adobe entrarão em contato com você.

Para verificar se você foi afetado, você pode filtrar seus Serviços e Assinaturas de acordo com o filtro abaixo:

Se qualquer um dos seus serviços de notificação por push ativos usar a API HTTP (herdada), sua configuração será diretamente afetada por essa alteração. Você deve revisar suas configurações atuais e migrar para as APIs mais recentes conforme descrito abaixo.
Se a configuração usar exclusivamente a API HTTP v1 para notificações por push do Android, você já estará em conformidade e nenhuma outra ação será necessária da sua parte.

Como atualizar?

Pré-requisitos

O arquivo JSON da conta do serviço SDK do administrador do Android Firebase é necessário para mover o aplicativo móvel para HTTP v1. Saiba como obter este arquivo na documentação do Google Firebase.
Para o Campaign Classic v7, o suporte de HTTP v1 foi adicionado na versão 20.3.1. Se seu ambiente estiver sendo executado em uma versão mais antiga, um pré-requisito para a transição para HTTP v1 é atualizar seu ambiente para a compilação mais recente de Campaign Classic. Para o Campaign v8, o HTTP v1 é compatível com todas as versões, e nenhuma atualização é necessária.
Como usuário local do Campaign Classic v7, você deve atualizar os servidores de execução Marketing e Tempo real.
Para implantações de Cloud Service híbridas, hospedadas e gerenciadas, além do procedimento de transição abaixo, entre em contato com o Adobe para atualizar o servidor de execução em tempo real (RT).
Sobre a conta externa Android routing:
- Como usuário local ou híbrido do Campaign Classic v7, verifique se a conta externa do Android Routing está configurada com androidPushConnectorV2.js. Saiba mais na documentação do Campaign Classic v7.
- Para implantações híbridas, hospedadas e gerenciadas de Cloud Service, você também deve se conectar com a equipe de Atendimento ao cliente do Adobe para validar se o conector androidPushConnectorV2.js (nms) está selecionado na conta externa de roteamento Android do seu servidor Mid-sourcing.

Procedimento de transição

Para mover seu ambiente para HTTP v1, siga estas etapas:

Navegue até a sua lista de Serviços e Assinaturas.
Liste todos os aplicativos móveis usando a versão da API HTTP (herdada).
Para cada um desses aplicativos móveis, defina a versão da API como HTTP v1.
Clique no link Load project json file to extract project details… para carregar diretamente seu arquivo de chave JSON.

Você também pode inserir manualmente os seguintes detalhes:
- Project Id
- Private Key
- Client Email
Clique em Test the connection para verificar se a configuração está correta e se o servidor de marketing tem acesso ao FCM. Observe que, para implantações de Mid-Sourcing, o botão Test connection não pode verificar se o servidor tem acesso ao serviço Android Firebase Cloud Messaging (FCM).
Como opção, você pode enriquecer um conteúdo de mensagem de push com alguns Application variables se necessário. Eles são totalmente personalizáveis e uma parte da carga da mensagem é enviada para o dispositivo móvel.

Clique em Finish e em Save.

Abaixo estão os nomes de payload do FCM para personalizar ainda mais sua notificação por push. Estas opções estão detalhadas aqui.

Tipo de mensagem	Elemento de mensagem configurável (nome da carga FCM)	Opções configuráveis (nome da carga do FCM)
mensagem de dados	N/D	validate_only
mensagem de notificação	title, body, android_channel_id, icon, sound, tag, color, click_action, image, ticker, sticky, visibility, notification_priority, notification_count	validate_only

NOTE

Depois que essas alterações forem aplicadas em todo o servidor, todos os novos deliveries de notificação por push para dispositivos Android usarão a API HTTP v1. Os deliveries de push existentes em repetição, em andamento e em uso ainda usam a API HTTP (herdada). Saiba como atualizá-los na seção abaixo.

Atualizar modelos existentes

Quando a transição HTTP v1 estiver concluída, você deverá atualizar seus modelos de entrega para as notificações por push do Android para aumentar o número de mensagens em lote. Para fazer isso, navegue até as propriedades do modelo de entrega do Android e, na guia Entrega, defina a Quantidade do lote de mensagens como 256. Aplique essa alteração a todos os templates de delivery usados para seus deliveries do Android e a todos os deliveries existentes do Android.

Você também pode atualizar deliveries e templates de delivery existentes criados antes da atualização para uma versão compatível com HTTP v1. Para fazer isso:

Cloud Service Como um cliente Gerenciado ou Hospedado, entre em contato com a Adobe para atualizar seus modelos de entrega existentes do Android.

Para ambientes locais, baixe o script fcm-httpv1-migration.js e execute-o conforme detalhado abaixo.

Baixe fcm-httpv1-migration.zip.

CAUTION

O script deve ser executado na instância de marketing local.

Etapas para atualizar deliveries e modelos existentes (somente no local)

Para corrigir todos os deliveries e templates de deliveries criados antes da atualização para uma versão compatível com HTTP v1, siga estas etapas:

Exporte seus deliveries e templates de delivery existentes em um pacote para poder restaurá-los caso ocorra um problema inesperado durante a aplicação de patches.

Execute o seguinte comando no Posgresql:

pg_dump -Fp -f /sftp/<db_name>-nmsdelivery-before_rd_script.sql -t nmsdelivery -d <db_name>

Por padrão, o script está no modo dryrun. Você pode iniciá-lo nesse modo para verificar se alguma entrega precisa ser corrigida.

Comando

nlserver javascript -instance:<instance_name> -file fcm-httpv1-migration.js

Output

...
HH:MM:SS >   Processing delivery (id:123456,  label:'Deliver on Android - New', name:'DM1234')
HH:MM:SS >   Dry run: Would update androidCheckParams for delivery (id:123456,  label:'Deliver on Android - New', name:'DM1234')
HH:MM:SS >   Processing delivery (id:567890,  label:'Deliver on Android - New', name:'DM5678')
HH:MM:SS >   Dry run: Would update androidCheckParams for delivery (id:567890,  label:'Deliver on Android - New', name:'DM5678')
...
HH:MM:SS >   Summary (XYZ processed deliverie(s) or delivery template(s)):
HH:MM:SS >>  - X had not patchable androidCheckParams formula!
HH:MM:SS >   - Y had androidCheckParams formula patched.
HH:MM:SS >   - Z ignored as alreading having androidCheckParams formula patched.

NOTE

As entregas not patchable precisam ser atualizadas manualmente. A ID pode ser encontrada no log de.

Execute o script no modo de execução da seguinte maneira para atualizar deliveries:

nlserver javascript -instance:<instance_name> -file fcm-httpv1-migration.js -arg:run

Qual é o impacto para meus aplicativos do Android?

Não são necessárias alterações específicas no código dos aplicativos Android Mobile e o comportamento da notificação não deve ser alterado.

No entanto, com HTTP v1, você pode personalizar ainda mais sua notificação por push com HTTPV1 additional options.

Você pode:

Use o campo Ticker para definir o texto do ticker da sua notificação.
Use o campo Image para definir a URL da imagem a ser exibida na sua notificação.
Use o campo Notification Count para definir o número de novas informações não lidas a serem exibidas diretamente no ícone do aplicativo.
Defina a opção Sticky como false para que a notificação seja automaticamente descartada quando o usuário clicar nela. Se definida como verdadeiro, a notificação ainda será exibida mesmo quando o usuário clicar nela.
Defina o nível Notification Priority da sua notificação como padrão, mínimo, baixo ou alto.
Defina o nível Visibility da sua notificação como público, privado ou secreto.

Para saber mais sobre HTTP v1 additional options e como preencher esses campos, consulte a documentação do FCM.

Serviço de notificação por push (APNs) do Apple iOS

O que mudou?

Conforme recomendado pela Apple, você deve proteger suas comunicações com o serviço de notificação por push (APNs) da Apple usando tokens de autenticação sem estado.

A autenticação baseada em token oferece uma maneira sem estado de se comunicar com APNs. A comunicação sem estado é mais rápida do que a comunicação baseada em certificado porque não requer que APNs consultem o certificado ou outras informações relacionadas ao servidor do provedor. Há outras vantagens em usar a autenticação baseada em token:

Você pode usar o mesmo token de vários servidores de provedores.
Você pode usar um token para distribuir notificações para todos os aplicativos de sua empresa.

Saiba mais sobre conexões baseadas em token com APNs em Documentação para desenvolvedores do Apple.

O Adobe Campaign Classic v7 e o Adobe Campaign v8 oferecem suporte a conexões baseadas em token e em certificado. Se sua implementação depende de uma conexão baseada em certificado, o Adobe recomenda que você atualize-a para uma conexão baseada em token.

Você será afetado?

Se sua implementação atual depender de solicitações baseadas em certificado para se conectar a APNs, você será afetado. Recomenda-se a transição para uma conexão baseada em token.

Para verificar se você foi afetado, você pode filtrar seus Serviços e Assinaturas de acordo com o filtro abaixo:

Se qualquer um dos seus serviços de notificação por push ativos usar o modo de autenticação baseada em certificado (.p12), suas implementações atuais deverão ser revisadas e movidas para um modo de autenticação baseada em token (.p8) conforme descrito abaixo.
Se sua configuração usar exclusivamente o modo de autenticação baseada em token para notificações por push do iOS, sua implementação já estará atualizada e nenhuma outra ação será necessária da sua parte.

Como atualizar?

Pré-requisitos

Para o Campaign Classic v7, o suporte ao modo Autenticação baseada em token foi adicionado na versão 20.2. Se seu ambiente estiver sendo executado em uma versão mais antiga, um pré-requisito para essa alteração é atualizar seu ambiente para a compilação mais recente de Campaign Classic. Para o Campaign v8, o modo de autenticação baseada em token é compatível com todas as versões, e nenhuma atualização é necessária.
Você precisa de uma chave de assinatura de token de autenticação APNs para gerar os tokens que seu servidor usa. Você solicita essa chave da sua conta de desenvolvedor do Apple, conforme explicado na Documentação do desenvolvedor do Apple.
Para implantações híbridas, hospedadas e Managed Services, além do procedimento de transição abaixo, entre em contato com o Adobe para atualizar o servidor de execução em tempo real (RT). O servidor Mid-Sourcing não é afetado.
Como usuário local do Campaign Classic v7, você deve atualizar os servidores de execução Marketing e Tempo real. O servidor Mid-Sourcing não é afetado.

Procedimento de transição

Para mover seus aplicativos móveis da iOS para o modo de autenticação baseada em token, siga estas etapas:

Navegue até a sua lista de Serviços e Assinaturas.
Liste todos os aplicativos móveis usando o Modo de autenticação baseada em certificado (.p12).
Edite cada um desses aplicativos móveis e navegue até a guia Chave de certificado/privada.
No menu suspenso Modo de Autenticação, selecione o modo Autenticação baseada em token (.p8).
Preencha as configurações de conexão APNs Key Id, Team Id e Bundle Id e selecione seu certificado p8 clicando em Enter the private key….
Clique em Test the connection para verificar se a configuração está correta e se o servidor tem acesso a APNs. Observe que, para implantações de Mid-Sourcing, o botão Test connection não pode verificar se o servidor tem acesso a APNs.
Clique em Next para configurar o aplicativo de produção e siga as mesmas etapas descritas acima.
Clique em Finish e em Save.

Seu aplicativo iOS agora está sendo movido para o modo de autenticação baseado em token.

recommendation-more-help