Intégrer Formio et Camunda sans code d'intégration

Deux bons outils, et un fossé entre eux

Formio est un excellent constructeur de formulaires : des schémas JSON, affichables partout, avec validation, logique conditionnelle et envoi de fichiers. Camunda est un excellent moteur de workflow : processus BPMN, tâches utilisateur, décisions et minuteries. La plupart des projets qui utilisent les deux doivent les relier, et c'est là que le temps part.

Ce que fait le code d'intégration

Sur un projet typique, quelqu'un écrit un petit service entre les deux. Quand un formulaire est soumis, Formio l'appelle (par exemple par une action webhook). Le service doit alors :

1. Recevoir et authentifier la soumission.
2. Choisir le processus : quel processus BPMN, quelle version, démarrer une instance ou terminer une tâche en attente.
3. Associer les champs : un champ Formio applicantEmail devient la variable email ; une grille de données imbriquée devient une liste.
4. Convertir les types : dates, nombres stockés en texte, cases à cocher, références de fichiers.
5. Gérer les erreurs : réessayer quand le moteur est injoignable, signaler une soumission rejetée.
6. Faire le chemin inverse : charger le bon formulaire, prérempli avec les données du processus, à l'ouverture d'une tâche.

Rien de tout cela n'est difficile en soi. Cela prend deux à cinq jours par projet, et c'est réécrit au projet suivant, un peu différemment.

Où cela casse

• Des champs renommés. Un concepteur renomme un champ ; le mapping cesse en silence de remplir une variable, et une passerelle prend la mauvaise branche.
• Des versions qui divergent. Une nouvelle version du processus est déployée, mais le service démarre toujours l'ancienne, ou l'inverse.
• Des échecs silencieux. Le moteur rejette une requête la nuit ; le webhook renvoie une erreur que personne ne lit ; un client appelle trois jours plus tard.
• Une seule personne sait. Le mapping vit dans le code et dans la tête d'un ingénieur, sans piste d'audit quand quelque chose tourne mal.

À quoi ressemble une intégration saine

Que vous la construisiez ou l'achetiez, cherchez ces propriétés :

• Des mappings en configuration, visibles et relisibles, pas enfouis dans le code.
• Un mapping automatique quand champs et variables portent le même nom, pour ne traiter que les exceptions.
• Des versions figées : chaque formulaire est lié à une version connue du processus.
• Un moyen de tester un mapping avec des données d'exemple avant que de vrais utilisateurs soumettent.
• Des échecs visibles : une erreur apparaît là où le processus s'est arrêté, avec un moyen de relancer.
• Une trace des données entrées dans chaque dossier, et de leur date.

Un mot sur Camunda Forms

Camunda 8 a ses propres formulaires, conçus avec l'éditeur de formulaires de Camunda. Ils conviennent bien aux formulaires de tâche simples. Les équipes gardent souvent Formio quand elles ont déjà une bibliothèque de formulaires Formio, ont besoin de formulaires publics hors de Camunda, ou s'appuient sur les composants et la validation de Formio. La question de l'intégration reste alors entière.

Dans Bridge

Le mappeur de variables de Bridge associe visuellement les champs Formio aux variables Camunda, automatiquement quand les noms concordent, et vous testez un mapping sans écrire de webhook. Chaque formulaire et processus est figé sur une version : un nouveau déploiement ne change pas en silence ce que démarre un formulaire.

Quand quelque chose échoue, l'incident apparaît sur le diagramme BPMN en direct, avec son contexte d'erreur et une relance en un clic. Chaque variable de chaque soumission est capturée au moment de son entrée : le parcours de Formio à Camunda et retour se retrace pour chaque dossier.