Migre sua loja virtual acelerada para o Compo

Visão geral

Migre sua loja baseada em acelerador para Composable Storefront

Se você leu os artigos «Cinco motivos para migrar para uma loja de javascript do projeto Spartacus» e «Começando com o Projeto Spartacus do SAP Commerce Cloud», pode estar querendo migrar para uma arquitetura de alto desempenho sem estado e agora se perguntando como se preparar para a migração. Neste artigo, discutiremos uma abordagem adequada para pequenas lojas, mas com um processo que também pode ajudar em migrações maiores, onde uma re-implementação completa é recomendada.

Migrar ou não?

Embora a recomendação seja usar a migração para Composable Storefront (também conhecida como Spartacus) como uma oportunidade para começar do zero e repensar a experiência da sua loja, você pode ter requisitos para migrar para Composable Storefront e manter a mesma experiência. Dependendo do número e do método de personalização da sua loja baseada em acelerador, você pode achar que tentar migrar sua experiência existente para Composable Storefront pode ser algo simples ou difícil. Se não tiver certeza, pode seguir os passos abaixo para fazer um exercício e identificar o número de mudanças sem necessariamente gastar tempo para implementá-las. Isso pode lhe dar uma ideia de quanto trabalho pode ser necessário para migrar em comparação com começar com uma abordagem do zero.

Como mencionado em «Começando com o Projeto Spartacus do SAP Commerce Cloud», você pode executar seus aceleradores e Composable Storefronts ao mesmo tempo para reduzir o risco, embora seja recomendado não fazer isso por um período prolongado. Manter duas lojas em duas pilhas tecnológicas diferentes pode tornar o desenvolvimento e os testes bastante difíceis, sem mencionar que você pode dar aos seus clientes uma experiência de usuário inconsistente dependendo da página da loja em que estão acessando.

Pré-requisitos

É recomendável que você inicie sua migração para um Composable Storefront após atualizar para o SAP Commerce 1905 ou posterior, pois a forma como as interfaces de programação de aplicativos (APIs) do Omni Commerce Connect (OCC) são instaladas foi simplificada (agora estão disponíveis como extensões em vez de AddOns).

Para começar, você também precisará do seguinte:

Configuração inicial

Revise o «O que há de novo no SAP Commerce Cloud, loja composable e roteiro para Composable Storefront» para garantir que você esteja ciente de quais recursos têm paridade, quais podem ter mudado e quais podem estar faltando.

Atualize sua loja existente para usar pelo menos o SAP Commerce 2011.

Quaisquer Addons OCC existentes foram convertidos em extensões regulares (se estiver usando o SAP Commerce 2005 ou posterior).

Você passou pelas etapas de «Construa e implemente seu primeiro projeto SAP Commerce Cloud». Você também pode revisar o conteúdo abordado na configuração do SAP Commerce Cloud para uso com Composable Storefront e garantir que tenha configurado e executado a construção do Composable Storefront a partir das bibliotecas.

Equipe de Front-End

A equipe de front-end construirá a interface do usuário da loja composta por layout e módulos Angular. As habilidades principais dos desenvolvedores serão:

Equipe de Back-End

A equipe de back-end construirá as APIs do OCC necessárias pela equipe de front-end. As habilidades principais dos desenvolvedores necessárias são:

Anatomia de um Composable Storefront

Antes de começar sua migração, você deve estar familiarizado com como um Composable Storefront funciona. Comece visitando a documentação do Composable Storefront e dê uma olhada no diretório de Módulos e Componentes. Ele se parecerá com isso:

Navegue pelos Módulos e Componentes e se familiarize com a funcionalidade oferecida pelo Composable Storefront. Preste atenção especial aos Módulos que fornecem uma estrutura padrão que define o mapeamento entre Componentes CMS padrão e Componentes Composable Storefront. No exemplo abaixo, o BannerComponent fornece mapeamentos para SimpleResponsiveBannerComponent, BannerComponent e SimpleBannerComponent.

Módulo de Banner

@NgModule({



imports: [CommonModule, RouterModule, GenericLinkModule, MediaModule],



providers: [



provideDefaultConfig({



cmsComponents: {



SimpleResponsiveBannerComponent: {



component: BannerComponent,



},



BannerComponent: {



component: BannerComponent,



},



SimpleBannerComponent: {



component: BannerComponent,



},



},



}),



],



declarations: [BannerComponent],



entryComponents: [BannerComponent],



exports: [BannerComponent],



})



export class BannerModule {}

Para ver quais endpoints de API estão disponíveis em sua instalação local, acesse a documentação do Swagger do OCC. Você pode precisar instalar extensões adicionais se um determinado endpoint estiver faltando.

Acelerador Storefront vs Composable Storefront

Você pode estar familiarizado com o acelerador padrão baseado em Spring-MVC no lado esquerdo da imagem abaixo, mas observe cuidadosamente a descrição do Composable Storefront no lado direito para entender as principais diferenças.

 

Acelerador Storefront Na loja tradicional, o navegador faz solicitações ao servidor que recuperam a estrutura da página e executam controladores, fachadas e serviços para processar e recuperar as informações necessárias para renderizar a visualização. A maioria do estado é mantida no lado do servidor, dentro da HttpSession, que pode ser replicada entre contêineres.

Composable Storefront Na loja sem cabeça (headless), o front-end é carregado no navegador, e a estrutura da página e o layout são recuperados do servidor (a menos que tenha um layout estático). Os Componentes Composable Storefront (veja Módulos e Componentes acima) são usados para construir a página no lado do cliente, e eles executam Chamadas do OCC para o servidor (veja APIs do OCC acima) para recuperar os dados necessários para a renderização. A página inicial pode ser construída inicialmente no Servidor (usando uma tecnologia conhecida como Renderização do Lado do Servidor – SSR), para fins de desempenho e SEO. O estado é mantido no lado do Cliente, dentro do Armazenamento Local / de Sessão do Navegador.

Durante a migração, você dividirá a funcionalidade do controlador do acelerador existente em Componentes Angular individuais do Composable Storefront (incluindo a lógica de visualização/modelo) e APIs do OCC, conforme indicado pelas linhas pontilhadas.

Em alguns casos, pode ser necessário modificar também os Facades e Serviços existentes.

Mudanças no Catálogo de Conteúdo também serão necessárias, a documentação do Composable Storefront dá uma boa visão geral das diferenças entre os dados de exemplo do acelerador e do Composable Storefront.

Por fim, você pode analisar uma chamada de exemplo para a página de Detalhes do Produto com a ajuda das Ferramentas de Desenvolvedor do Chrome, para ver como tudo se encaixa. Use a guia de Rede para ver as requisições geradas pelo Composable Storefront.

Ao analisar as chamadas acima com mais detalhes, utilizando a documentação da API Swagger como referência, você pode ver:

Usando o Plugin do Chrome Augury, você pode ver a hierarquia de componentes resultante após a página ser construída no navegador.

Iniciando a Migração

Agora que você entende como o Composable Storefront funciona em um nível técnico, está pronto para prosseguir com a migração.

Passo 1 – Faça um Inventário dos seus Componentes e Páginas do CMS

É importante fazer um inventário das páginas e componentes usados em sua loja atual, como na tabela abaixo. Para cada página, liste os controladores e Componentes do CMS personalizados que são usados, e para cada componente, descubra quais dados ele precisa exibir ou processar. Algumas informações necessárias podem não ser visíveis à primeira vista, como caixas de seleção ou janelas pop-up.

Você pode filtrar as requisições para /pagescontentslotscomponents no SmartEdit enquanto edita uma página específica em sua loja existente para recuperar os detalhes do componente.

Componentes usados na Página de Detalhes do Produto do Acelerador

0: {componentId: "SiteLogoComponent",…}



1: {componentId: "HomepageNavLink",…}



2: {componentId: "OrderComponent",…}



3: {componentId: "MiniCart",…}



4: {componentId: "ElectronicsCategoryNavComponent",…}



5: {componentId: "breadcrumbComponent",…}



6: {componentId: "TabPanelContainer",…}



7: {componentId: "FooterNavigationComponent",…}



8: {componentId: "MyAccountComponent",…}



9: {componentId: "MyCompanyComponent",…}



10: {componentId: "SearchBox",…}



11: {componentId: "VariantSelector",…}



12: {componentId: "AddToCart",…}



13: {componentId: "Similar",…}



14: {componentId: "CookieNotificationComponent",…}



15: {componentId: "AnonymousConsentManagementComponent",…}



16: {componentId: "AssistedServiceComponent",…}



17: {componentId: "ProfileTagScriptComponent",…}



18: {componentId: "PersonalizationScriptComponent",…}



19: {componentId: "BundleCarouselComponent",…}

Pode ser útil fazer capturas de tela de sua loja e anotar os componentes, como abaixo:

O Composable Storefront suporta quase todos os componentes responsivos de CMS B2C out-of-the-box, então você só precisará se concentrar em seus componentes personalizados, bem como aqueles provenientes de complementos de terceiros ou extensões de marketplace não cobertas na biblioteca padrão. Agrupe e classifique-os de acordo com a área funcional, utilizando um inventário de componentes como o abaixo. Esteja ciente de que, ao contrário da abordagem da Página do Acelerador, tudo precisa ser um componente no Composable Storefront, então talvez seja necessário componentizar partes de um layout de Página de Servidor Jakarta (JSP) existente.

As consultas a seguir fornecem uma visão geral dos Componentes, Modelos de Página e Páginas usados em sua loja:

Consultas Úteis de Pesquisa Flexível

// Lista de Componentes



selecione



    {ct.code},



    {c.id},



    {ct.extensionName},



    count(*) as cnt



de {



    AbstractCMSComponent como acc



    junte-se ao ComposedType como ct em {ct.pk} = {acc.itemtype}



    junte-se ao CatalogVersion como cv em {cv.pk} = {acc.catalogversion}



    junte-se a um catálogo como c em {cv.catalog} = {c.pk}



}



onde {c.id} LIKE '%ContentCatalog' e {cv.version} = 'Online'



agrupar por {ct.code}, {cv.version}, {c.id},{ct.extensionName}



ordenar por cnt desc



// Modelos de Página



selecione



    {ct.code},



    {c.id},



    {pt.name},



    {pt.frontendTemplateName}



de {



    PageTemplate como pt



    junte-se ao ComposedType como ct em {ct.pk} = {pt.itemtype}



    junte-se ao CatalogVersion como cv em {cv.pk} = {pt.catalogversion}



    junte-se a um catálogo como c em {cv.catalog} = {c.pk}



}



onde {c.id} LIKE '%ContentCatalog' e {cv.version} = 'Online'



ordenar por {ct.code}



// Páginas



selecione



    {ct:code},



    {c:id},



    {ap:name[de]},



    {ap:uid}



de {



    AbstractPage  como ap



    junte-se ao ComposedType como ct em {ct.pk} = {ap.itemtype}



    junte-se ao CatalogVersion como cv em {cv.pk} = {ap.catalogversion}



    junte-se a um catálogo como c em {cv.catalog} = {c.pk}



}



onde {c.id} LIKE '%ContentCatalog' e {cv.version} = 'Online'



ordenar por {ct.code}



// Páginas, Componentes e Slots



selecione



    {c.id},



    {cv.version},



    {p.uid}              as "Página",



    {pt.uid}             as "Modelo",



    {s4p.position}       as "Posição atribuída ao modelo",



    {st.uid}             as "id do slot de conteúdo 4t",



    {st.active}          as "slot de conteúdo 4t ativo",



    {sn.templatePOS}     as "pos",



    {sn.name}            as "posição disponível no modelo",



    {comp.uid},



    {compt.code},



    {comp.visible}



de {



    AbstractPage como p



    junte-se ao CatalogVersion como cv em {cv.pk} = {p.catalogVersion}



    junte-se a um catálogo como c em {c.pk} = {cv.catalog}



    junte-se ao PageTemplate como pt em {pt.pk} = {p.masterTemplate}



    junte-se a ContentSlotForPage como s4p em {s4p.page} = {p.pk}



    junte-se a ContentSlot como st em {st.pk} = {s4p.contentSlot}



    à esquerda junte-se a ContentSlotName como sn em {sn.template} = {pt.pk} e {sn.name} = {s4p.position}



    junte-se a ElementsForSlot como e2s em {st.pk} = {e2s.source}



    junte-se a AbstractCMSComponent como comp em {comp.pk} = {e2s.target}



    junte-se ao ComposedType como compt em {compt.pk} = {comp.itemtype}



} onde



{cv.version} = 'Online' e {c.id} like '%ContentCatalog'



ordenar por {cv.version},{c.id},{p.uid},{sn.templatePOS},{comp.uid}





// Modelos, componentes e slots



selecione



    {c.id},



    {cv.version},



    {p.uid},



    {pt.uid},



    {s4t.position}       as "posição atribuída ao modelo",



    {st.uid}             as "id do slot de conteúdo 4t",



    {st.active}          as "slot de conteúdo 4t ativo",



    {s4t.allowOverwrite} as "permitir sobrescrita do modelo",



    {sn.templatePOS}     as "pos",



    {sn.name}            as "posição disponível no modelo",



    {comp.uid},



    {compt.code},



    {comp.visible}



de {



    AbstractPage como p



    junte-se ao CatalogVersion como cv em {cv.pk} = {p.catalogVersion}



    junte-se a um catálogo como c em {c.pk} = {cv.catalog}



    junte-se ao PageTemplate como pt em {pt.pk} = {p.masterTemplate}



    junte-se a ContentSlotForTemplate como s4t em {s4t.pageTemplate} = {pt.pk}



    junte-se a ContentSlot como st em {st.pk} = {s4t.contentSlot}



    à esquerda junte-se a ContentSlotName como sn em {sn.template} = {pt.pk} e {sn.name} = {s4t.position}



    junte-se a ElementsForSlot como e2s em {st.pk} = {e2s.source}



    junte-se a AbstractCMSComponent como comp em {comp.pk} = {e2s.target}



    junte-se ao ComposedType como compt em {compt.pk} = {comp.itemtype}



} onde



{cv.version} = 'Online' e {c.id} like '%ContentCatalog'



ordenar por {cv.version},{c.id},{p.uid},{sn.templatePOS},{comp.uid}

Inventário de Componentes

No acelerador padrão, um PageController (baseado em AbstractPageController) prepara o contexto necessário para renderizar uma página. No Composable Storefront, a maior parte desse trabalho já é realizado pelo framework, mas é uma boa ideia verificar manualmente a lógica que pode precisar ser movida para uma extensão personalizada do OCC ou um componente individual.

Passo 2 – Realizar uma Análise de Lacunas

Para cada componente, identifique se existe uma API correspondente do OCC que forneça os dados necessários (e o Serviço Injetável correspondente), caso contrário, descreva as Extensões do OCC que serão necessárias. Além disso, defina uma prioridade de desenvolvimento (ou importância) para cada componente.

Análise de Lacunas do Componente

Passo 3 – Iniciar a Implementação da API

Usando uma abordagem API First, crie Extensões do OCC ausentes e defina as interfaces com base na semântica dos serviços do OCC existentes. Comece com implementações vazias (ou simuladas) pois isso permitirá que a equipe de front-end comece a trabalhar em paralelo no próximo passo.

Utilize o Swagger CodeGen para gerar automaticamente o código do cliente Typescript Angular necessário no front-end. Acrescente campos faltantes nos DTOs conforme necessário.

Passo 4 – Implemente as Páginas e Componentes do CMS

Crie uma estrutura básica de sistema de gerenciamento de conteúdo da web (WCMS) que duplique a sua loja atual e lance a sua aplicação Composable Storefront. Abra a guia Console nas Ferramentas de Desenvolvedor do Chrome e você verá um aviso para cada Componente do CMS que não tem um Componente Angular correspondente, também haverá um aviso para os Slots do CMS disponíveis.

Verifique se essa informação corresponde ao seu Inventário de Componentes do CMS.

Storefront Componível

No storefront sem cabeçalho, o front-end é carregado no navegador, e a estrutura e layout da página são recuperados do servidor (a menos que tenha um layout estático). Os Componentes do Composable Storefront (veja Módulos e Componentes acima) são usados para construir a página no lado do cliente, e eles executam Chamadas OCC para o servidor (veja APIs OCC acima) para recuperar os dados necessários para renderização. A página inicial pode, no entanto, ser construída inicialmente no Servidor (usando uma tecnologia conhecida como Renderização do Lado do Servidor – SSR), por questões de desempenho e SEO. O estado é mantido no lado do Cliente.

Prossiga para reimplementar os novos componentes e páginas do CMS em Angular. Use o comando de esquema de Componente do CMS add-cms-component para gerar classes esqueleto (veja também: Criando Páginas e Componentes e Criando uma nova página no Spartacus) e adicione sua lógica personalizada.

Conclusão

Este artigo forneceu uma introdução mais técnica ao Composable Storefront e às técnicas necessárias para migrar um storefront de acelerador existente. Uma migração pode envolver uma quantidade significativa de reengenharia, mas existem benefícios tangíveis de desempenho e manutenção que o tornam valioso. A preparação cuidadosa é fundamental para uma migração bem-sucedida.

Se tiver alguma dúvida, não hesite em entrar em contato pelo e-mail sapcx-services@sap.com. Se tiver dúvidas técnicas enquanto desenvolve no Composable Storefront, encorajamos você a postar sua pergunta no StackOverflow com a tag spartacus-storefront.

FONTE