Explorar a replicação no B2C Commerce

Objetivos de aprendizagem

Após concluir esta unidade, você estará apto a:

• Listar as três instâncias afetadas por uma replicação.
  
• Listar as três maneiras pelas quais você pode executar uma replicação.
  
• Listar três tipos de replicação de dados que acionam automaticamente uma atualização de cache.
  
• Descrever uma reversão de replicação.
  

O Commerce Cloud passou a se chamar Agentforce Commerce, e o B2C Commerce passou a se chamar Agentforce Commerce for B2C. Você poderá ver referências ao Commerce Cloud e ao B2C Commerce em nossos aplicativos e documentação.

Administradores e desenvolvedores do B2C Commerce replicam regularmente dados e código da instância de preparação para as instâncias de produção e desenvolvimento.

Por exemplo, um desenvolvedor acabou de criar um processo de checkout mais rápido e adicionou um recurso extra de desconto de produto que exigia alterações nas definições de configuração do Business Manager. Além disso, o administrador do B2C importou dados de produtos de um sistema externo para preparar o terreno para uma nova linha de primavera. O processo de mover o código, as definições de configuração e os dados entre as instâncias do B2C Commerce é chamado de replicação.

Um processo de replicação é uma coleção de tarefas para mover dados ou códigos definidos de uma instância de origem para uma instância de destino. A instância da fonte tem o código ou os dados que você deseja mover. A instância de destino é onde os dados vão parar. Na replicação, a preparação é a fonte e o desenvolvimento e a produção são os destinos.

Como diferenciar entre PIGs e SIGs

Os sites do B2C Commerce geralmente têm estas instâncias.

• Three instances on the primary instance group (PIG):
  
  • Preparação
    
  • Desenvolvimento para testes
    
  • Produção para implantação
    
• Uma instância de demonstração
  
• Instâncias de sandbox sob demanda para desenvolvimento de código, preparação de sites, testes e implantação
  

A replicação é executada somente em um PIG, tanto para dados quanto para código.

A replicação de dados copia dados, metadados e arquivos da instância de preparação para a instância de desenvolvimento ou produção. Ela funciona em dois níveis.

• A replicação global inclui informações de configuração e dados para a toda a organização.
  
• A replicação do site inclui dados de um ou mais sites específicos (como dados de produtos e catálogos, conteúdo baseado em XML e arquivos de imagem).
  

A replicação de código transfere versões do código da instância de preparação para uma instância de desenvolvimento ou produção e as ativa.

Normalmente, os desenvolvedores são responsáveis por mover código de um SIG para um PIG. Quando o desenvolvedor termina a codificação em sua máquina local, ele carrega seu código para uma sandbox ou para a instância de preparação. Ele usa o Visual Studio Code para carregá-lo ou pode usar um repositório de código (como o Git) para sincronizar o trabalho entre vários desenvolvedores. O repositório de código é, então, a origem para uma liberação para uma instância de preparação. Esse tipo de ambiente de desenvolvimento pode ter seu próprio processo de criação com um carregamento automatizado.

O processo de replicação

Uma replicação envolve estas etapas.

• Executar uma replicação da instância de preparação para a instância de desenvolvimento para testá-la.
  
• Testar a instância de desenvolvimento e visualizar os registros.
  
• Verificar se a pesquisa funciona e se os dados estão corretos no sistema de desenvolvimento.
  
• Fazer alterações na instância de preparação.
  
• Replicar da instância de preparação para a instância de desenvolvimento e testar novamente até que tudo funcione.
  
• Replicar da instância de preparação para instância de produção.
  
• Testar tudo em produção, mesmo que a replicação tenha funcionado corretamente para a instância de desenvolvimento.
  

Quando você configura um processo de replicação de dados ou código, pode optar por executá-lo imediatamente, agendá-lo para executá-lo mais tarde ou atribuí-lo a um trabalho.

Uma replicação de dados é um processo de longa duração com duas fases.

• Copy (Copiar): os dados são transferidos para o sistema de destino, mas ainda não estão visíveis lá.
  
• Publish (Publicar): esta etapa é rápida e disponibiliza todas as alterações ao mesmo tempo.
  

Configure processos de replicação de dados para serem repetidos diariamente, semanalmente ou mensalmente em uma hora específica. Um processo programado replica o estado do sistema na hora de execução; não no momento em que você criou o processo.

Uma replicação de código transfere versões de código de uma instância de preparação para uma instância de desenvolvimento ou produção e, em seguida, as ativa.

Evitar conflitos durante a replicação

Durante uma replicação, evite outras atualizações. Fazer edições manuais no Business Manager na instância de origem ou de destino enquanto uma replicação está sendo executada pode levar a erros críticos e inconsistência de dados.

Verifique se nenhum trabalho está sendo executado na instância de destino durante a replicação e evite replicações de dados durante uma janela de manutenção padrão do B2C Commerce. Se um processo de replicação de dados recorrente falhar, ele deixará de ser repetido.

Avaliar o impacto no cache da página

Uma invalidação do cache da página remove ou atualiza dados obsoletos no cache de uma página. Quando você replica dados ou código, o B2C Commerce inicia uma invalidação de cache automaticamente. Quando você inicia uma invalidação de cache manualmente, o sistema começa a invalidar os dados em cache. Para reduzir o impacto no desempenho e minimizar as interrupções, o sistema realiza a remoção do cache ao longo de um período de 15 minutos (o “Período de limpeza”).

Neste módulo, pressupomos que você é um administrador do B2C Commerce com as devidas autorizações para executar essas tarefas. Se você não for um administrador do B2C Commerce, tudo bem. Continue lendo para saber como seu administrador executa essas etapas. Não tente seguir as etapas no Trailhead Playground. Essa funcionalidade não está disponível no Trailhead Playground.

Para acessar e invalidar o cache:

1. No Business Manager, clique em App Launcher (Iniciador de aplicativos) e selecione Administration (Administração) | Sites | Manage Sites (Gerenciar sites).
   
2. Selecione o nome do seu site.
   
3. Clique na guia Cache.
   
4. Selecione a instância de preparação.
   
5. Na seção Cache Invalidation (Invalidação do cache), clique em Invalidate (Invalidar) para invalidar o Static Content Cache (Cache de conteúdo estático) e o Entire Page Cache for Site (Cache da página inteira para o site), ou o Entire Page Cache for Site (Cache da página inteira para o site).
   

A limpeza do cache da página cria uma carga pesada nos servidores do aplicativo. Limpe o cache da página manualmente apenas se for necessário e evite limpá-lo durante as horas de muito tráfego. Por exemplo, para atualizações secundárias, aguarde a limpeza do cache programada para a noite em vez de limpar imediatamente.

Um comando para limpar o cache pode levar até 15 segundos para chegar ao servidor web. A atualização não aparece imediatamente. Para garantir o sucesso das replicações, avalie o escopo das alterações e mantenha-as o mais reduzidas possível.

Tanto para atualizações de cache automáticas quanto manuais, o B2C Commerce atrasa a atualização de todas as páginas em uma instância de produção por 15 minutos para distribuir a carga entre os servidores de aplicativos.

Resumir o comportamento de cache da replicação de código

Por padrão, a etapa final de um processo de replicação de dados também invalida e atualiza o cache automaticamente. Embora você possa configurar o processo para ignorar essa etapa, faça isso com cautela: ignorá-la poderá causar dados inconsistentes na sua loja (virtual), o que é difícil de solucionar.

Veja aqui um exemplo. O B2C Commerce armazena as páginas de descrição do produto em cache por 24 horas. Você agenda a limpeza do cache da página do produto para a noite seguinte e, em seguida, nota que vários preços de produtos estão incorretos na instância de produção. Você pede a um anunciante para corrigir os preços no Business Manager na instância de preparação e, em seguida, você replica as alterações para a instância de produção usando um processo que ignora a limpeza do cache da página porque ela já foi agendada.

Fazer a limpeza desta forma mantém os dados de preços sincronizados entre as instâncias de preparação e de produção e garante que os preços corretos apareçam no cesto (que não é armazenado em cache). As páginas de descrição do produto da loja (virtual) mostram os preços antigos e incorretos até que ocorra a limpeza agendada do cache da página.

Cesto é o termo usado dentro das APIs do B2C Commerce para o carrinho de compras.

Ao ignorar a atualização automática do cache, você corre o risco de exibir preços incorretos nas páginas de descrição de produtos. Você aceita esse compromisso para evitar o impacto no desempenho de uma atualização do cache de produção. O mais importante é que os cestos na instância de produção reflitam os preços corretos e sincronizados com a instância de preparação.

Estas são algumas outras considerações de caching da página.

Catálogos são um caso especial, conforme a seguir indicado.

Aplicar melhores práticas para replicação focada

Para garantir que suas replicações direcionadas ocorram sem problemas e não apresentem erros, siga estas melhores práticas para transferências de dados focadas e granulares:

Identifique suas dependências

As dependências são a fonte mais comum de falha em replicações. Antes de selecionar uma tarefa para uma replicação granular, identifique as dependências e planeje como resolvê-las.

Por exemplo, se você tiver campanhas que usam códigos-fonte e cupons, replique dados de código-fonte e de cupom antes ou juntamente com dados de campanhas. Replicar as campanhas primeiro poderá resultar na corrupção de dados na instância de destino. Esse erro ocorre porque as campanhas dependem dos dados de código-fonte e de cupom.

Evite processos simultâneos

Não executar vários processos de replicação ao mesmo tempo. A replicação é um processo que consome muitos recursos e executar processos simultaneamente poderá causar problemas de desempenho e resultados imprevisíveis.

Replique as dependências primeiro

Se você modificar o tipo de um objeto do sistema (por exemplo, adicionando um atributo personalizado ao objeto Product [Produto]), replique a definição global do tipo de objeto do sistema antes de replicar qualquer objeto desse tipo.

Sempre teste antes da produção

Antes de replicar qualquer alteração para sua instância de produção ativa, execute primeiro o mesmo processo de replicação a partir da instância de preparação para uma instância de desenvolvimento. Essa prática testa as alterações e verifica se tudo está correto, incluindo funções da loja (virtual) como a pesquisa, sem nenhum risco para seu ambiente de produção.

Execute durante períodos de pouco tráfego

Os processos de replicação exigem recursos significativos do sistema. Agende todas as grandes replicações para serem executadas durante períodos de pouco tráfego, como no final da noite ou nas primeiras horas da manhã. O agendamento de replicações para períodos com pouco tráfego minimiza o impacto no desempenho da sua loja (virtual) e oferece a melhor experiência para seus compradores.

Examine os logs

Ao replicar para uma instância de produção, primeiro transfira os dados ou o código para verificar o processo de transferência. Examine os logs antes de publicar os dados ou ativar o código.

Recrie índices de pesquisa

Sempre recrie os índices de pesquisa e verifique se o processo foi concluído antes de replicá-los. Ao replicar índices de pesquisa, desabilite a indexação incremental e agendada, e interrompa outros trabalhos. A replicação falha quando é executada durante a recriação ou modificação de um índice.

Limite o acesso do usuário

Limite os privilégios de usuários para executar a replicação de dados e distribua a responsabilidade entre várias funções. Por exemplo:

• Um gerente de produto define os processos de replicação, mas não tem autorização para agendá-los ou executá-los.
  
• Um gerente de replicação administra e executa os processos de replicação.
  

Evite replicar conteúdo estático

Evite modificar ou mover arquivos de conteúdo estático sempre que possível. Essas alterações levam muito tempo para serem replicadas.

Utilize processos existentes

Copie um processo de replicação existente quando possível, em vez de criar um novo processo do zero.

Reverter uma replicação

Para reverter uma replicação e restaurar a instância de destino ao estado anterior, execute outro processo de replicação com o tipo de replicação definido como Undo (Desfazer). Você só pode reverter a replicação de dados ou código mais recente.

As replicações de dados e código não afetam as reversões um do outro. Por exemplo, se você executar uma replicação de dados e, em seguida, uma replicação de código, você ainda poderá desfazer cada replicação de forma independente.

A ação Undo (Desfazer) está indisponível para processos de replicação de dados executados antes de uma versão GA, disponível ao público em geral. Por exemplo, um processo na versão 24.7 não pode ser desfeito após o sistema atualizar para a versão 24.8. Isso não se aplica a Atualizações GA, por exemplo, de 24.8.1 para 24.8.2.

Próximas etapas

Nesta unidade, você aprendeu quais instâncias usar para replicação de código e de dados. Você conheceu as implicações no cache da página, melhores práticas e como reverter uma replicação. Em seguida, saiba como configurar e executar uma replicação de dados.

Recursos

• Trailhead: anunciantes do Agentforce Commerce for B2C
• Trailhead: Arquitetura do Salesforce B2C Commerce
• Trailhead: Trabalhos agendados do Salesforce B2C Commerce
• Ajuda do Salesforce: Replicação