SAP Build Apps

Um projeto do SAP Build Apps passa por quatro etapas:

1. Criar. Os projetos são criados no lobby do SAP Build, como app web e mobile ou como back-end de aplicação.
2. Projetar. O construtor posiciona componentes em páginas num editor visual e os estiliza livremente. O comportamento é definido no Logic Canvas como fluxos lógicos: um evento, como o clique em um botão, seguido de flow functions.
3. Conectar. Os dados vêm de destinations do SAP BTP do tipo OData ou REST, que um administrador precisa habilitar para o SAP Build Apps no SAP BTP cockpit, ou de um back-end construído com visual cloud functions.
4. Entregar. Os apps web são gerados e implantados no SAP BTP e podem ser expostos no SAP Build Work Zone; os apps mobile são gerados como binários iOS para publicação na App Store ou testes locais, e como pacotes Android em formato APK ou AAB.

O resultado é um aplicativo independente que lê e grava dados SAP por meio de APIs. O SAP Build Apps é, portanto, um cliente do SAP S/4HANA, nunca uma modificação dele.

Em abril de 2025, a SAP lançou uma oferta unificada SAP Build que reúne desenvolvimento de aplicativos, automação de processos e business sites para usuários low-code e code-first. Nesse contexto, a SAP descontinuou o SAP Build Apps como produto avulso, a partir de 23 de março de 2026. A documentação da SAP afirma que:

• novos projetos devem começar no SAP Build;
• clientes existentes mantêm acesso ao SAP Build Apps até o fim do contrato vigente;
• uma ferramenta de migração transforma o arquivo .mtar de projetos de front-end web em código React ou SAPUI5 para o SAP Business Application Studio, cobrindo apenas a UI;
• os dados de projetos de back-end são exportados em CSV e importados manualmente em um projeto CAP.

A ferramenta se aplica apenas a front-ends de aplicativos web; a página de path forward da SAP não descreve migração para builds mobile nativos. Qualquer novo investimento no SAP Build Apps deve começar pela verificação da data de término do contrato e do roadmap atual do SAP Build.

• Liberdade visual: a UI não fica presa aos floorplans do SAP Fiori, o que atende apps com identidade visual própria, específicos de uma tarefa ou com cara de app de consumo.
• Web e mobile nativo a partir de um projeto: o mesmo projeto visual pode ter como alvo um navegador e dispositivos mobile nativos.
• Protótipos rápidos: um business technologist consegue produzir em dias um protótipo clicável e conectado a dados, o que encurta as discussões de requisitos.
• Conectividade SAP pela plataforma: as destinations reutilizam a conectividade e a autenticação já configuradas no SAP BTP.
• Aderência ao clean core: os apps rodam side-by-side e conversam com o SAP S/4HANA por APIs, então não adicionam código ao núcleo do ERP.

Para apps pequenos, bem delimitados e com um responsável claro, o SAP Build Apps entrega um front-end funcional com pouco código.

• Não é SAP Fiori elements. Layout, navegação e acessibilidade são responsabilidade de quem constrói; não há floorplan orientado por anotações que mantenha os apps consistentes automaticamente.
• Regras de negócio pertencem ao back-end. Validações, preços ou lançamentos ainda precisam vir das APIs do SAP S/4HANA. Reconstruí-los em lógica visual cria uma segunda versão da regra, não sincronizada.
• Lógica visual é mais difícil de revisar em escala. Fluxos grandes são difíceis de comparar, testar e repassar, uma reclamação frequente em comunidades de profissionais quando o app cresce além do seu primeiro responsável.
• Limites de ciclo de vida. A documentação da SAP observa que o versionamento ainda não é suportado para projetos de back-end, o que afeta transporte e rollback.
• Ciclo de vida do produto. A descontinuação como produto avulso transforma cada app existente do SAP Build Apps em um item de migração com prazo definido pelo contrato.

Esses limites vêm do próprio modelo low-code: o SAP Build Apps acelera o front-end, enquanto a responsabilidade pelo app e a lógica de negócio continuam sendo decisões de design fora da ferramenta.

Use estes critérios de decisão para um app como um check-in de entregas para motoristas da Bright Freight na Alder Manufacturing:

Um erro comum é escolher a ferramenta por quem está disponível, e não por quem vai manter o app daqui a três anos. O SAP Build Apps atende apps restritos, com responsável definido e específicos para um grupo de usuários; apps transacionais consistentes se encaixam melhor no SAP Fiori elements.