Processus transactionnels de l’opérateur en BPMN, compilés en une application versionnée

MEF.DEV BPMN Low-code transforme un processus modélisé avec le métier en un processus qui s’exécute. Le modèle en BPMN 2.0 est le même artefact pour le responsable métier, l’analyste et le développeur, et c’est lui qui s’exécute.

Ce qui change

• Le modèle d’abord Le processus est modélisé du macro-processus jusqu’aux actions individuelles : périmètre, participants, propriétaire et rôles.
• Le modèle s’exécute Gateways, service tasks et script tasks, sous-processus et call activities sont compilés en une application versionnée, et non interprétés comme un script.
• Les personnes là où elles décident Les étapes humaines font partie du processus : contrôles, approbations et exceptions sont confiés à une personne avec piste d’audit ; la routine s’exécute seule.
• Les échecs gérés par le processus Reprises, compensation et reprise après redémarrage relèvent du comportement du processus, et non de scripts ad hoc.
• Jusque dans le BSS et l’OSS Le processus atteint les systèmes client, catalogue, commande et service via les TM Forum Open API sur Enablement & Monetization Platform.
• Livraison en un clic Versions, déploiement et rollback sont intégrés à la plateforme.

Compilé ou interprété

Là où un processus transactionnel perd du temps, c’est la manière dont ses étapes s’exécutent qui le détermine, et non l’ensemble de composants prêts à l’emploi.

	Script interprété par un moteur	BPMN compilé en application
Construire	une erreur dans le script apparaît pendant l’exécution du processus	le modèle est compilé en une classe .NET : un nom de champ mal orthographié ou une branche sans valeur de retour arrête le build avant toute exécution
À chaque étape	le moteur lit le texte du script et le traduit en actions pendant l’exécution du processus	les nœuds sont des méthodes et les sequence flows des appels d’une même classe compilée
Logique d’étape	le langage de script du moteur	C# dans le nœud ; transitions, branchements et gestion des échecs découlent du diagramme
Interface	publiée séparément	la frontière du processus est typée des deux côtés ; la description d’opération OpenAPI en est dérivée

Mesure de référence. Un processus de rating limité par le CPU (500 enregistrements) à 20 exécutions par seconde : médiane de 16 ms pour un plugin compilé sur la génération d’exécution v2, 19 ms pour un service Python de comparaison (FastAPI, 16 processus, authentification Basic avec cache). Le plugin passait en outre par l’autorisation et le pipeline de la plateforme.

Configuration

Configuration : une machine virtuelle de 32 vCPU et 64 GiB (Proxmox VE, Windows Server 2019) pour la plateforme et le service Python, une de 12 vCPU et 32 GiB pour MS SQL Server ; une exécution par configuration. La génération v3, un hôte dédié avec routage direct du trafic et sans démarrage à froid, est conçue pour les services à forte charge et ne faisait pas partie de ce test.

Estimation indicative. Nous estimons le débit de la génération v3 à plusieurs fois celui de la v2. Les valeurs réelles dépendent du profil de votre infrastructure.

Cas d’application

• Onboarding B2B de produits partenaires : extraits de registres, contrôles de sanctions et AML (Anti-Money Laundering), signataires et contrats dans un seul processus, avec validation des documents par l’opérateur.
• Multi File Transfer entre portails SaaS d’entreprise et SFTPGo sur BPMN Low-code : logique de synchronisation spécifique, reprise après redémarrage et basculement vers un second hôte.
• La réflexion qui sous-tend l’approche est sur le blog : BPMN compilé plutôt que scripts interprétés, BPMN comme langage commun aux analystes et aux développeurs, et souveraineté numérique sur le processus.

Use case