Explorar a replicação no B2C Commerce

Linda Rosenberg é uma nova administradora da Cloud Kicks, uma empresa de tênis de alta qualidade. Ultimamente, ela aprendeu a executar algumas tarefas essenciais de gerenciamento de dados no Salesforce B2C Commerce. Agora, ela quer se tornar uma especialista em implementar alterações de dados e de código da instância de preparação de comércio eletrônico de sua empresa para suas instâncias de produção e desenvolvimento.

Por exemplo, seu desenvolvedor acabou de criar um processo de checkout mais simplificado e adicionou um recurso extra de desconto de produto que exigia alterações nas definições de configuração no Business Manager. Além disso, Linda acabou de importar dados de produto de um sistema externo para preparar o terreno para uma nova linha de primavera. O processo que ela pode usar para 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 que você executa para mover dados ou códigos definidos de uma instância de origem para uma instância de destino. A instância de origem é onde o código ou os dados residem atualmente. A instância de destino é onde você quer que ele acabe. Na replicação, a instância de origem é a preparação e as instâncias de destino são o desenvolvimento e a produção.

Se você completou o módulo Funções e autorizações do Salesforce B2C Commerce, você aprendeu sobre a arquitetura do B2C Commerce. Vamos nos aprofundar um pouco mais sobre as instâncias. Quando um comerciante implementa um site pela primeira vez, o site normalmente recebe nove instâncias por realm. Isso inclui o seguinte:

• Três instâncias no grupo de instâncias primárias (PIG):
  • Preparação
  • Desenvolvimento para testes
  • Produção para implantação
• Cinco instâncias de sandbox para desenvolvimento de código no grupo de instâncias secundárias (SIG). Para escalabilidade, os comerciantes podem ter até 47 sandboxes por realm.
• Uma instância de demonstração.

Você executa a replicação apenas em um PIG. Isso é verdade tanto para a replicação de dados como para a replicação de 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.

• Replicação global, que inclui informações de configuração e dados que se aplicam a toda a organização.
• Replicação do site, que inclui dados pertencentes a um ou mais sites especificados (como dados de produtos e catálogos, componentes de conteúdo baseados em XML e arquivos de imagem).

A replicação de código transfere versões de 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. Os desenvolvedores podem usar o Visual Studio Code para carregá-lo, ou podem 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 construção com um upload automatizado.

Linda aprende que uma replicação envolve as etapas abaixo.

1. Executar uma replicação da instância de preparação para a instância de desenvolvimento para testá-la.
2. Testar a instância de desenvolvimento e visualizar os registros.
3. Certificar-se de que a pesquisa funciona e que os dados estão corretos no sistema de desenvolvimento.
4. Fazer as alterações necessárias na instância de preparação.
5. Replicar da instância de preparação para a instância de desenvolvimento e testar novamente até que tudo funcione bem.
6. Replicar da instância de preparação para instância de produção.
7. Testar tudo em produção, mesmo que a replicação tenha funcionado corretamente para a instância de desenvolvimento.

Quando Linda configura um processo de replicação de dados ou código, ela pode optar por executá-lo imediatamente, agendá-lo para executá-lo mais tarde ou atribuí-lo a um trabalho. O que é um trabalho? Um trabalho do B2C Commerce é um conjunto de etapas que realizam operações de longa duração, como baixar um arquivo de importação ou reconstruir um índice de pesquisa. Falamos sobre trabalhos no módulo Trabalhos agendados do Salesforce B2C Commerce.

Uma replicação de dados é um processo de longa duração que consiste em duas fases.

1. Copiar os dados para o sistema de destino: os dados ainda não estão visíveis no sistema de destino.
2. Publicar: isso é rápido e disponibiliza todas as alterações ao mesmo tempo.

Ela pode configurar processos de replicação de dados para serem repetidos diariamente, semanalmente ou mensalmente em uma hora específica. Se você agendar um processo de replicação para ser executado posteriormente, o processo replica o estado do sistema no momento da execução e não quando 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.

Durante uma replicação, Linda deve evitar fazer outras atualizações. Ela aprende rapidamente que não é uma boa ideia fazer edições manuais no Business Manager na instância de origem ou na instância de destino enquanto uma replicação está em execução. A edição durante esse processo pode afetar a consistência dos dados.

Ela também verifica se nenhum trabalho está sendo executado na instância de destino durante a replicação e evita 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 não será executado novamente automaticamente.

Tanto a replicação de códigos quanto a de dados têm implicações no cache da página. Algumas tarefas de replicação invalidam e atualizam o cache automaticamente. Algumas tarefas não fazem isso automaticamente, então Linda deve sempre limpar o cache manualmente depois de executá-las. Vamos ver os passos que ela segue para limpar manualmente o cache.

Para acessar o Business Manager, você tem de ter uma implementação do B2C Commerce. Neste módulo, pressupomos que você seja 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 executaria essas etapas em uma instância de preparação. Não tente seguir nossas etapas em seu Trailhead Playground. O B2C Commerce não está disponível no Trailhead Playground. Se você tem uma instância de preparação do B2C Commerce, pode experimentar essas etapas em sua instância. Se você não tem uma instância de preparação, pergunte ao seu gerente se existe alguma que possa usar.

Para acessar e invalidar o cache:

1. Abra o Business Manager.
2. Selecione Administração > Sites > Gerenciar sites > nome do site.
3. Clique na guia Cache.
4. Selecione a instância Preparação.
5. Na seção Invalidação do cache, clique em Invalidar para invalidar o Cache de conteúdo estático e o cache da página inteira para o site ou o Cache da página inteira para o site. As alterações são feitas imediatamente. 

Limpar o cache da página pode criar uma carga pesada nos servidores do aplicativo. Isso significa que Linda deve limpar o cache da página manualmente apenas se for necessário, e evitar limpá-lo durante as horas de muito tráfego. Por exemplo, se Linda fizer algumas pequenas atualizações, em vez de limpar o cache imediatamente, ela pode esperar por sua limpeza de cache agendada para a noite. Se as alterações envolverem um recurso de segurança importante ou uma atualização crítica de produto ou promoção, sua decisão é diferente.

Não importa quando ela limpa o cache, um comando para limpar o cache pode levar até 15 segundos para chegar ao servidor web. Ela provavelmente não verá a atualização do cache imediatamente. Para garantir a realização bem-sucedida das replicações, ela avalia o escopo de alterações e tenta fazer apenas pequenas alterações.

Para atualizações automáticas e manuais do cache, o B2C Commerce atrasa a atualização de todas as páginas em uma instância de produção em 15 minutos. Isso garante a distribuição de carga entre os servidores de aplicativos. Em instâncias que não são de produção, o cache da página é atualizado imediatamente.

Replicação de dados

A última etapa do processo de replicação de dados invalida e atualiza automaticamente o cache por padrão, exceto em certos casos. Linda pode configurar um processo de replicação para pular a limpeza automática do cache. No entanto, ela deve fazer isso com cautela, porque pode levar a dados inconsistentes na loja, um problema difícil de resolver.

Vamos olhar para um exemplo no qual Linda escolheria pular a limpeza automática do cache. O B2C Commerce armazena as páginas de descrição do produto em cache por 24 horas. Linda agenda a limpeza do cache para a página do produto para a noite seguinte e, em seguida, nota que vários preços de produto estão incorretos na instância de produção. Ela pede a um comerciante para corrigir os preços no Business Manager na instância de preparação, e então ela 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á a agendou.

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 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.

Pular a atualização automática de cache significa que ela aceita a alternativa de ter preços incorretos nas páginas de descrição do produto em troca de evitar o impacto de uma atualização de cache em 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 armazenamento de páginas em cache.

Quando você replica...	O B2C Commerce...
Dados específicos do site	Limpa o cache da página para o site afetado, a menos que você esteja apenas replicando cupons, códigos-fonte, configurações da Open Commerce API ou feeds de dados ativos.
Dados globais	Limpa o cache da página para todos os sites afetados, a menos que você esteja apenas replicando geolocalizações ou listas de clientes.
Catálogos, sites ou catálogos de preços	Limpa automaticamente o cache.
Promoções ou conteúdo estático	Não limpa automaticamente o cache.
Catálogos	Limpa seletivamente o cache de página dos sites afetados, usando as regras descritas na tabela a seguir.

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

Quando você replica...	O B2C Commerce limpa o cache de...
Todos os catálogos para todos os sites de uma organização	Todos os sites da organização.
Um único catálogo que é atribuído a um ou mais sites	Os sites para os quais o catálogo é atribuído.
Um catálogo de produtos que não é diretamente atribuído a um site, mas serve como um repositório de produtos para um ou mais catálogos de site ou navegação	Os sites, determinados por meio de programação, que oferecem produtos do catálogo de produtos.

Linda tem um bom controle sobre a replicação agora. Mas antes de criar qualquer processo de replicação para a Cloud Kicks, ela estuda cuidadosamente as melhores práticas a seguir.

• Identificar dependências entre diferentes grupos de replicação de dados. Por exemplo, se você tiver campanhas que usam códigos-fonte e códigos de cupons, replicar códigos-fonte e cupons junto com ou antes de replicar campanhas.
• Sempre reconstruir os índices de pesquisa e certificar-se de que o processo tenha sido concluído antes de replicá-los. Ao replicar índices de pesquisa, desabilitar a indexação incremental e agendada e parar outros trabalhos. A replicação falha quando um índice está sendo reconstruído ou modificado.
• Não executar vários processos de replicação ao mesmo tempo.
• Limitar o número de usuários que têm privilégios de realizar a replicação de dados.
• Armazenar conteúdo estático em estruturas de pastas que não permitam mais de 1.000 arquivos na mesma pasta. Se você armazenar mais de 1.000 arquivos em uma pasta, os tempos de acesso e replicação aumentarão significativamente, mesmo que nenhum arquivo seja alterado.
• Copiar um processo de replicação existente quando possível, em vez de criar um novo processo do zero.
• Não editar código ou caminhos de acesso do cartridge diretamente em uma instância de produção. Isso pode causar comportamentos inesperados, como várias versões de páginas. Sempre replicar código e preferências da instância de preparação para a instância de produção.

Algumas vezes, você tem que desfazer uma replicação. Você pode fazer isso executando a mesma replicação novamente com o tipo de replicação definido como Desfazer. Isso restaura a instância de destino ao seu estado anterior. No entanto, 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 pode desfazer ambas as replicações.

Nesta unidade, Linda aprendeu quais instâncias são usadas para replicação de código e de dados. Ela aprendeu sobre as implicações no cache de página, melhores práticas e como reverter uma replicação. Em seguida, ela vai configurar e executar uma replicação de dados.

• Trailhead: Salesforce B2C Commerce para comerciantes
• Trailhead: Arquitetura do Salesforce B2C Commerce
• Trailhead: Trabalhos agendados do Salesforce B2C Commerce
• Ajuda: Replicação