SAP Business Workflow

SAP Business Workflow sépare la définition d'un processus de son exécution :

1. Un développeur crée une définition de workflow dans le Workflow Builder. La définition est une suite d'étapes : certaines pilotent le déroulement (conditions, boucles, branches parallèles, attentes), d'autres font référence à des tâches.
2. Chaque tâche pointe vers une méthode d'un type d'objet, comme un objet du Business Object Repository (BOR) ou une classe ABAP qui implémente l'interface IF_WORKFLOW, et s'exécute soit en arrière-plan, soit comme étape de dialogue pour une personne.
3. L'activation de la définition génère une version d'exécution. Les instances déjà en cours conservent la version avec laquelle elles ont démarré.
4. Un événement déclencheur, comme la création ou la modification d'un document métier, démarre automatiquement le workflow ; les utilisateurs peuvent aussi démarrer des workflows manuellement.
5. À l'exécution, le gestionnaire de work items crée les work items, détermine les agents à partir de l'organisation, de rôles ou de règles, et surveille les délais.
6. Les agents exécutent leurs work items dans leur boîte de réception, et chaque étape est enregistrée dans le journal du workflow.

SAP Business Workflow est un moteur piloté par les événements qui combine des transactions SAP existantes en un processus sans modifier ces transactions.

Le développement et l'administration quotidiens de SAP Business Workflow se font dans ces transactions SAP GUI plutôt que dans des applications SAP Fiori.

• Profondeur de modélisation : conditions, boucles, branches parallèles, délais, escalades et données de conteneur couvrent une logique d'approbation et de coordination complexe.
• Natif à l'objet métier : les workflows réagissent aux événements des documents SAP et appellent directement les transactions et méthodes SAP, sans couche d'intégration entre le workflow et les données.
• Outils d'exploitation intégrés : traces d'événements, journaux de workflow, sélection des work items, traitement administrateur et analyse de la charge de travail sont livrés avec le moteur.
• Modèles livrés par SAP : SAP livre des modèles de workflow pour de nombreux processus, qui demandent un effort de mise en œuvre limité.
• Socle des outils plus récents : le flexible workflow étend le moteur, et My Inbox comme SAP Task Center peuvent consommer ses tâches.

Pour les processus qui résident dans un seul système ABAP, SAP Business Workflow reste l'option de modélisation la plus poussée que SAP propose sur la pile ABAP.

• Entre les mains des développeurs. Les définitions sont construites dans SAP GUI par des développeurs de workflows et déplacées par transports. Les responsables de processus dépendent de la DSI pour chaque modification de règle.
• Un seul système ABAP. Un workflow orchestre des objets au sein du système dans lequel il s'exécute. Les étapes dans d'autres systèmes nécessitent du RFC, des services web ou une intégration avec un service comme SAP Build Process Automation.
• Concentration des connaissances. Les workflows spécifiques s'accumulent au fil des années. Lorsque leurs auteurs partent, la logique n'est lisible que dans le Workflow Builder et dans le code derrière les tâches et les règles.
• Du code spécifique à porter. Les définitions, tâches et règles d'agent spécifiques sont des objets de développement que chaque mise à niveau et chaque conversion doivent évaluer.
• Une visibilité au niveau de l'instance. Le journal du workflow explique une instance ; une vue métier couvrant de nombreuses instances et les systèmes adjacents se reconstitue à partir de reports.

Ces limites découlent de la conception : SAP Business Workflow est un moteur back-end pour les processus internes à un seul système ABAP, construit et exploité par la DSI.

SAP Business Workflow fait partie de la plateforme ABAP ; il s'exécute donc dans SAP ERP, SAP S/4HANA on-premise et SAP S/4HANA Cloud Private Edition, où les clients peuvent toujours modéliser leurs propres workflows dans le Workflow Builder. Dans SAP S/4HANA Cloud Public Edition, les clients n'ont pas d'accès SAP GUI au Workflow Builder ; les approbations livrées par SAP se configurent dans les applications de flexible workflow. SAP documente le flexible workflow comme moteur de workflow par défaut de SAP S/4HANA pour un ensemble de scénarios d'approbation. La plateforme ABAP s'intègre aussi à SAP Build Process Automation et à SAP Task Center sur SAP BTP. L'option de déploiement détermine si SAP Business Workflow est un outil de modélisation pour le client ou un moteur qui s'exécute sous les scénarios livrés.

Procédez de la configuration à l'événement, puis au work item, puis à l'agent :

1. Exécutez SWU3 et confirmez que la zone d'exécution ne présente aucune erreur. Un utilisateur WF-BATCH manquant ou une destination RFC défaillante bloque les étapes en arrière-plan.
2. Activez la trace des événements avec SWE4, répétez l'action métier et lisez la trace dans SWEL. Aucun événement signifie que l'application n'en a pas déclenché ; un événement sans workflow démarré renvoie à un couplage de types inactif ou erroné dans SWE2.
3. Retrouvez le work item dans SWI1 par tâche, date ou statut, et lisez le journal du workflow pour voir la dernière étape terminée.
4. Si le work item n'a pas d'agent, vérifiez les agents possibles de la tâche, l'organisation et toute règle de détermination des agents.
5. Ensuite seulement, laissez un administrateur de workflow intervenir sur le work item, par exemple depuis SWIA, avec les fonctions d'administration disponibles dans la release.

Suivre cet ordre résout la plupart des incidents SAP Business Workflow sans toucher à la définition du workflow.