SAP Build Process Automation

O trabalho no SAP Build Process Automation é organizado em projetos:

1. Um builder cria um projeto de processo de negócio no SAP Build lobby.
2. Dentro do projeto, o builder modela um processo e adiciona artefatos: formulários e formulários de aprovação para pessoas, tabelas de decisão para regras, automações para trabalho repetitivo no desktop ou em sistemas, actions que chamam APIs e subprocessos.
3. Um gatilho inicia o processo: um formulário, uma chamada de API, um evento de negócio, um agendamento ou uma fila.
4. O builder faz o release do projeto, o que cria uma versão numerada, e implanta essa versão para executá-la produtivamente. As versões podem ser transportadas entre tenants com o SAP Cloud Transport Management.
5. Em tempo de execução, as pessoas recebem suas tarefas no My Inbox no SAP Build Work Zone ou no SAP Task Center, e as automações rodam em um desktop agent, em modo attended ou unattended.
6. Ferramentas de monitoramento e cenários de visibilidade mostram o estado das instâncias de processo.

O SAP Build Process Automation transforma um processo em um artefato versionado e implantável no SAP BTP.

O SAP Build Process Automation consolidou dois serviços anteriores do SAP BTP em 2022: o SAP Workflow Management e o SAP Intelligent Robotic Process Automation. Desde então, a SAP descontinuou o SAP Intelligent RPA, e ambos os motores continuam dentro do novo serviço, com uma experiência de usuário reformulada. Workflows construídos com a workflow capability anterior podem continuar em execução e ser reutilizados como subprocessos, de modo que os clientes existentes podem migrar no seu próprio ritmo. Alguns documentos da SAP ainda usam o nome anterior SAP Process Automation. Desde abril de 2025, o SAP Build Process Automation também é oferecido como parte do SAP Build, no service plan build-default. Materiais mais antigos descrevem os mesmos conceitos sob o SAP Workflow Management e sua "workflow capability", nome que ainda aparece na documentação de integração do SAP Build Process Automation.

• Vários estilos de automação em uma só ferramenta: workflows humanos, formulários, tabelas de decisão, bots e visibilidade de processos compartilham um projeto e um ciclo de vida.
• Low-code para equipes mistas: business technologists iniciam um processo, e desenvolvedores profissionais podem adicionar actions e lógica avançada ao mesmo projeto.
• Feito para integração com SAP: conteúdo pré-construído, actions baseadas em APIs SAP, gatilhos por eventos e conectividade nativa a partir do SAP S/4HANA reduzem o esforço de integração.
• Alinhado ao clean core: os processos rodam side-by-side no SAP BTP, de modo que o ERP fica livre da lógica da extensão.
• Gestão de ciclo de vida de fato: estados editável, liberado e implantado, versões semânticas e transportes dão aos processos construídos por citizen developers o mesmo controle de mudanças de qualquer outro software implantado.

Para processos que abrangem vários sistemas ou estendem o padrão SAP no SAP BTP, o SAP Build Process Automation é a opção low-code da própria SAP.

• Um runtime separado. Os processos rodam no SAP BTP, não dentro do SAP S/4HANA. Toda interação com documentos de negócio passa por destinations, communication arrangements, APIs ou eventos que alguém precisa configurar e manter.
• O licenciamento molda o desenho. Participantes e designers precisam de entitlements de usuário diferentes, e cenários com uso intenso de APIs ou alto volume podem exigir cota adicional de chamadas de API ou de armazenamento.
• Bots seguem a tela. As automações de desktop dependem das interfaces de usuário que operam, então mudanças de UI exigem manutenção dos bots.
• A visibilidade cobre o que é instrumentado. Os cenários de visibilidade mostram os eventos que os sistemas participantes enviam; etapas que não enviam nada ficam no escuro.
• A governança é tarefa do cliente. O low-code reduz a barreira de entrada; propriedade, nomenclatura, reutilização e desativação de projetos continuam exigindo regras.
• Cobertura de data centers. O serviço roda nos data centers que a SAP lista para ele, e os recursos de IA generativa em um subconjunto menor; por isso, verifique a lista antes de escolher a região de um subaccount.

Esses limites decorrem do desenho: o SAP Build Process Automation é um serviço de plataforma que estende os sistemas SAP a partir de fora.

A SAP documenta vários caminhos de integração:

• Iniciar e controlar a partir do lado ABAP: o SAP S/4HANA, inclusive o Cloud Public Edition por meio de um communication arrangement, pode chamar uma API para iniciar e controlar instâncias de processo no SAP BTP.
• Embutir no SAP Business Workflow: na plataforma ABAP, uma tarefa padrão genérica entrega uma etapa ao SAP Build Process Automation e aguarda a conclusão.
• Eventos de negócio: o assistente de extensibilidade do SAP S/4HANA Cloud vincula um evento de negócio de um app padrão a um processo, que passa a iniciar sempre que o evento ocorre.
• Actions: projetos de action chamam APIs do SAP S/4HANA, por exemplo serviços OData, a partir das etapas do processo.

Escolher o caminho de integração do SAP Build Process Automation é uma decisão de desenho em si, porque determina onde o processo começa e qual sistema detém a verdade sobre o seu estado.

Use um teste simples: onde o processo vive?

Um erro comum é reconstruir no SAP BTP uma aprovação já entregue pela SAP: o status do documento, a lógica de lançamento e a trilha de auditoria passam a viver em dois lugares. O erro oposto é forçar um processo entre sistemas em um único workflow de back-end. O SAP Build Process Automation se encaixa melhor onde nenhum sistema SAP isolado é dono do processo inteiro.