SAP Build Process Automation

Le travail dans SAP Build Process Automation est organisé en projets :

1. Un concepteur crée un projet de processus métier dans le SAP Build lobby.
2. Dans le projet, le concepteur modélise un processus et ajoute des artefacts : formulaires et formulaires d'approbation pour les personnes, tables de décision pour les règles, automatisations pour les tâches répétitives sur poste de travail ou dans les systèmes, actions qui appellent des API, et sous-processus.
3. Un déclencheur démarre le processus : un formulaire, un appel d'API, un événement métier, une planification ou une file d'attente.
4. Le concepteur publie le projet, ce qui crée une version numérotée, et déploie cette version pour l'exécuter en production. Les versions peuvent être transportées entre tenants avec SAP Cloud Transport Management.
5. À l'exécution, les personnes reçoivent leurs tâches dans My Inbox, dans SAP Build Work Zone, ou dans SAP Task Center, et les automatisations s'exécutent sur un agent desktop en mode attended ou unattended.
6. Les outils de supervision et les scénarios de visibilité affichent l'état des instances de processus.

SAP Build Process Automation fait d'un processus un artefact versionné et déployable sur SAP BTP.

SAP Build Process Automation a regroupé en 2022 deux services SAP BTP antérieurs : SAP Workflow Management et SAP Intelligent Robotic Process Automation. SAP a depuis déprécié SAP Intelligent RPA, et les deux moteurs perdurent au sein du nouveau service avec une expérience utilisateur repensée. Les workflows construits avec l'ancienne capacité de workflow peuvent continuer à s'exécuter et être réutilisés comme sous-processus, si bien que les clients existants peuvent migrer à leur rythme. Certains documents SAP utilisent encore l'ancien nom SAP Process Automation. Depuis avril 2025, SAP Build Process Automation est également proposé dans le cadre de SAP Build sous le plan de service build-default. Les documents plus anciens décrivent les mêmes concepts sous SAP Workflow Management et sa « workflow capability », un nom qui apparaît encore dans la documentation d'intégration de SAP Build Process Automation.

• Plusieurs styles d'automatisation dans un même outil : workflows humains, formulaires, tables de décision, bots et visibilité des processus partagent un même projet et un même cycle de vie.
• Du low-code pour des équipes mixtes : les business technologists amorcent un processus, et les développeurs professionnels peuvent ajouter des actions et une logique avancée au même projet.
• Conçu pour l'intégration SAP : contenu prédéfini, actions fondées sur les API SAP, déclencheurs par événement et connectivité native depuis SAP S/4HANA réduisent l'effort d'intégration.
• Compatible avec le clean core : les processus s'exécutent en side-by-side sur SAP BTP, si bien que l'ERP reste exempt de la logique de l'extension.
• Une véritable gestion du cycle de vie : états modifiable, publié et déployé, versions sémantiques et transports appliquent aux processus construits par les citizen developers le même contrôle des changements qu'aux autres logiciels déployés.

Pour les processus qui couvrent plusieurs systèmes ou étendent le standard SAP sur SAP BTP, SAP Build Process Automation est l'option low-code propre à SAP.

• Un moteur d'exécution distinct. Les processus s'exécutent sur SAP BTP, et non dans SAP S/4HANA. Toute interaction avec des documents métier passe par des destinations, des communication arrangements, des API ou des événements que quelqu'un doit mettre en place et maintenir.
• Les licences influencent la conception. Les participants et les concepteurs nécessitent des droits utilisateur différents, et les scénarios à forte intensité d'API ou à fort volume peuvent exiger un quota supplémentaire d'appels d'API ou de stockage.
• Les bots suivent l'écran. Les automatisations desktop dépendent des interfaces utilisateur qu'elles pilotent, si bien que les changements d'interface imposent une maintenance des bots.
• La visibilité couvre ce qui est instrumenté. Les scénarios de visibilité affichent les événements envoyés par les systèmes participants ; les étapes qui n'envoient rien restent invisibles.
• La gouvernance incombe au client. Le low-code abaisse la barrière d'entrée ; la responsabilité, le nommage, la réutilisation et le retrait des projets exigent toujours des règles.
• Couverture des data centers. Le service s'exécute dans les data centers que SAP indique pour lui, et les fonctionnalités d'IA générative dans un sous-ensemble plus restreint ; consultez donc la liste avant de choisir la région d'un subaccount.

Ces limites découlent de la conception : SAP Build Process Automation est un service de plateforme qui étend les systèmes SAP depuis l'extérieur.

SAP documente plusieurs voies d'intégration :

• Démarrer et piloter depuis le côté ABAP : SAP S/4HANA, y compris la Cloud Public Edition via un communication arrangement, peut appeler une API pour démarrer et piloter des instances de processus sur SAP BTP.
• Intégrer dans SAP Business Workflow : sur la plateforme ABAP, une tâche standard générique confie une étape à SAP Build Process Automation et attend son achèvement.
• Événements métier : l'assistant d'extensibilité de SAP S/4HANA Cloud relie un événement métier d'une application standard à un processus, qui démarre alors chaque fois que l'événement se produit.
• Actions : les projets d'actions appellent des API SAP S/4HANA, par exemple des services OData, depuis les étapes du processus.

Le choix de la voie d'intégration de SAP Build Process Automation est une décision de conception à part entière, car il détermine où le processus démarre et quel système fait foi sur son état.

Appliquez un test simple : où réside le processus ?

Une erreur courante consiste à reconstruire sur SAP BTP une approbation livrée : le statut du document, la logique de comptabilisation et la piste d'audit résident alors à deux endroits. L'erreur inverse consiste à forcer un processus multisystème dans un seul workflow back-end. SAP Build Process Automation convient le mieux lorsqu'aucun système SAP ne porte à lui seul l'ensemble du processus.