E se um fluxo de trabalho que leva quase uma hora hoje pudesse se tornar um processo controlado e repetível dentro da Experience Cloud, com um único clique? Este guia mostra como o Adobe App Builder transforma o esforço operacional manual em automação escalável e aborda as etapas exatas para passar do conceito para um aplicativo corporativo publicado.

Não faz muito tempo, eu estava ajudando uma grande organização de tecnologia financeira a simplificar seus fluxos de trabalho no Adobe Target. Sua equipe gastava quase 45 minutos configurando a lógica de limitação de impressão para cada atividade: uma dança cuidadosa de configurações, públicos-alvo, regras e validações. Ao ver isso acontecer, fiquei pensando que tinha que haver um jeito melhor. E se tudo isso pudesse acontecer em apenas alguns minutos, ou até mesmo com um clique?

Isso me levou diretamente ao Adobe App Builder.

Em grandes ambientes corporativos, as equipes geralmente dependem de uma combinação de ferramentas, scripts e conhecimento informal para realizar o trabalho de rotina. Nada está realmente “com problema”, mas tudo parece exigir mais etapas do que deveria. O App Builder oferece um caminho diferente: em vez de trabalhar restrito à plataforma, você incorpora o fluxo de trabalho a ela.

Uma interface personalizada. Dentro da Adobe Experience Cloud. Alimentado pela sua lógica, pelas suas APIs e pela sua automação.

Foi exatamente isso que criei: um aplicativo interno leve que lida automaticamente com toda a configuração de limitação de impressão. O que antes eram dezenas de ações manuais se tornou um painel limpo incorporado diretamente à interface da Adobe.

Neste artigo, falo como o App Builder funciona, por que ele é uma ferramenta tão valiosa para equipes corporativas e abordo os comandos e as configurações necessárias para colocar seu próprio aplicativo em funcionamento. Esteja você automatizando um fluxo de trabalho de nicho ou criando um produto interno completo, este guia deve fornecer um bom ponto de partida.

O que é o Adobe App Builder?

O Adobe App Builder é um aplicativo completo e uma estrutura de tempo de execução para criar aplicativos nativos em nuvem personalizados executados na infraestrutura da Adobe. Ele permite que os desenvolvedores estendam a funcionalidade da Adobe Experience Cloud, da Adobe Experience Platform e de outros produtos da Adobe. Com o App Builder, as equipes podem criar integrações personalizadas entre a Adobe e sistemas de terceiros para simplificar as operações e melhorar a eficiência do fluxo de trabalho.

O App Builder fornece vários modelos que servem como pontos de partida para diferentes tipos de integrações. Neste artigo, eu me concentro na extensão excshell, que permite que seu aplicativo seja executado diretamente dentro do shell da Adobe Experience Cloud.

Cada aplicativo é:

• Autenticado com o Adobe IMS

• Implantado sem servidor com o Adobe I/O Runtime

• Integrado ao ambiente da Adobe Experience Cloud da sua organização

• Gerenciado com um Developer Console unificado e um modelo de espaço de trabalho do projeto

Em resumo: é uma estrutura de extensão personalizada da Adobe Experience Cloud.

Perspectiva de consultoria

Como consultor, geralmente encontro equipes corporativas que desejam:

• Simplificar fluxos de trabalho internos de marketing ou de revisão de conteúdo

• Fornecer visibilidade controlada em configurações complexas do Target ou do AEM

• Automatizar tarefas de API repetitivas, como sincronização de campanha ou criação de público-alvo

O App Builder resolve isso com eficiência. Ele combina ações de tempo de execução seguro, componentes de interface baseados no Spectrum e controle de acesso regulado, permitindo um desenvolvimento rápido sem gerenciar infraestrutura ou credenciais.

Visão geral do exemplo real

Um dos meus clientes estava enfrentando uma configuração de atividade complexa no Adobe Target que envolvia várias etapas de natureza técnica e era demorada. Eu me ofereci para criar um aplicativo que lida com uma complexa configuração de 45 minutos com apenas um clique. Este aplicativo seria integrado à API de administração do Adobe Target para gerenciar atividades, ofertas e públicos-alvo. Recursos principais:

• Lista pesquisável e classificável de atividades do Target

• Filtro do Workspace que persiste na seleção de usuário

• Modal de detalhes com ações por experiência

• Atualização de oferta com um único clique (injeta metadados)

• Criação opcional de público-alvo com valores configuráveis

• Interface com estilo do Spectrum (Spectrum CSS) para uma aparência nativa da Adobe

Início rápido (novo ambiente)

1) Pré-requisitos

• Acesso ao Adobe Developer Console (projeto com o App Builder)

• Node.js 18+ e npm

• CLI do Adobe I/O: npm install -g @adobe/aio-cli

• Logon na Adobe: logon do aio

2) Inicialização

Se estiver começando do zero:

3) Configurar app.config.yaml

O arquivo app.config.yaml define como seu aplicativo se integra à Adobe Experience Cloud. Ele informa ao App Builder que tipo de extensão você está criando, onde seus arquivos de front-end estão localizados e quais ações de back-end devem ser executadas no Adobe I/O Runtime.

Em termos gerais, você especifica:

• Tipo de extensão: nesse caso, a extensão Shell da Experience Cloud (dx/excshell/1), que permite que o aplicativo apareça diretamente dentro da interface da Adobe Experience Cloud.

• Implementação de front-end: uma referência ao seu principal ponto de entrada do HTML (por exemplo, index.html) juntamente com metadados como nome, descrição e ícone do aplicativo.

• Pasta de ativos da Web: normalmente um diretório src da Web que contém seu front-end estilizado como Spectrum.

• Ações de tempo de execução: um conjunto de funções Node.js (por exemplo, “getTargetActivities”, “updateOffer” etc.) implantadas na infraestrutura sem servidor da Adobe. Cada ação inclui detalhes como:

  • O caminho para o arquivo da função JavaScript

  • Se é acessível pela Web

  • A versão de tempo de execução do Node.js

  • Qualquer anotação (como exigir autenticação da Adobe)

Em resumo, essa configuração conecta a interface à lógica de backend e torna o aplicativo detectável na Experience Cloud depois de implantado.

4) Desenvolvimento local

O aplicativo funciona em http://localhost:9080 com recarregamento ao vivo e autenticação IMS (quando iniciado no shell da Experience Cloud).

5) Implantar em um Espaço de trabalho

Alterne o espaço de trabalho quando necessário (por exemplo, Preparo, Produção):

6) Publicar no Catálogo (Produção)

Após a aprovação do Exchange, o aplicativo aparece no Catálogo do App Builder da sua organização.

Ações (APIs sem servidor)

Exemplos usados neste aplicativo (Node.js, @adobe/aio-sdk + node-fetch):

• getTargetActivities: lista as atividades do Target para a organização/locatário

• getActivity: busca detalhes de uma atividade específica (/target/activities/{type}/{id})

• getOffer: lê uma oferta JSON (/target/offers/json/{offerId})

• updateOffer: atualiza uma oferta (PUT /target/offers/content/{offerId})

• createAudience: cria um público-alvo do Target com lógica de regra

Cada ação recupera um token de acesso IMS do armazenamento de Estado em cache (preenchido pela ação getAccessToken) e chama as APIs do Adobe Target com cabeçalhos Authorization: Bearer <token> e X-Api-Key: <clientId>.

Front-end (Interface do Spectrum)

A interface é HTML/JS simples usando Spectrum CSS:

• Pesquisar entrada com o botão Limpar

• Seletor de espaço de trabalho (seletor silencioso)

• Tabela com fichas de status e carimbos de data e hora formatados

• Caixa de diálogo modal com os controles Atualizar oferta e o opcional Criar público-alvo

A interface armazena o espaço de trabalho selecionado em localStorage para que o filtro persista entre sessões.

Referência de comando

Práticas recomendadas e observações

• Use runtime.done() (via @adobe/exc-app Runtime) ao executar no shell da Experience Cloud para evitar a interface do shell de tempo limite (para configurações de SPA).

• Evite ações de longa duração; retorne rapidamente e faça stream ou enquete, se necessário.

• Prefira componentes silenciosos do Spectrum para consistência do shell.

• Mantenha a lógica de autenticação em ações; o front-end chama suas ações, não as APIs da Adobe diretamente.

• Mantenha os filtros de usuário (por exemplo, espaço de trabalho) no localStorage para melhorar a experiência do usuário.

• Para publicação no Exchange, certifique-se dos metadados corretos (nome, ícone) e inclua o bloco de extensão em app.config.yaml.

Documentação

• Adobe App Builder — Introdução

• Console do desenvolvedor