Bêta · expérience en cours
IFlow Assistant génère des Integration Flows pour SAP Integration Suite avec un modèle Ollama qui tourne sur votre PC et apprend des template et des solutions que vous lui enseignez. De la demande en langage naturel au paquet prêt à déployer, avec lint, Security Check et deploy sur le tenant.
Windows 10/11 64 bits · gratuit et open source · se met à jour tout seul · tout reste sur votre PC
C'est un projet un peu audacieux : je voulais commencer à entraîner un modèle avec Ollama en local et disposer d'un outil qui accélère la création d'iFlows à partir des template et des solutions que je lui ai enseignés. Ce n'est pas un produit fini : c'est une expérience que j'utilise vraiment dans mon travail quotidien, et que je partage telle quelle.
Concrètement, le modèle n'est pas ré-entraîné : il "apprend" grâce à une knowledge base locale (RAG) qui recueille vos exports, les template que vous classez et les paquets générés que vous approuvez. Chaque nouvelle demande est enrichie des fragments les plus proches et transmise à un modèle Ollama sur votre PC. Si le résultat est bon, vous le dites à l'application et, à partir de là, il pèse sur les générations suivantes.
Tout tourne en local : pas de cloud, pas de compte, pas de télémétrie. C'est une bêta et elle a des limites claires, présentées plus bas sans détour.
Un outil de bureau pour ceux qui construisent des iFlows tous les jours : il part de la description et va jusqu'au tenant.
Décrivez le flux en langage naturel et obtenez un .zip importable dans Integration Suite. En mode Spec, le modèle produit une spécification JSON et un builder déterministe assemble le XML BPMN2 à partir de blocs validés : correct par construction, pas "probablement juste".
Affinez le flux dans la même conversation : "ajoute la nouvelle tentative", "envoie aussi un e-mail", "sépare le mapping dans un local process". Chaque tour régénère le paquet.
Chaque export que vous ajoutez, à la main ou en l'important depuis le tenant, est indexé dans la knowledge base locale et guide les générations suivantes. Le bouton "Buono" (bon) ajoute aussi les paquets générés que vous approuvez.
Chaque paquet passe par un lint qui contrôle les références croisées, les sequenceFlow, les processRef et les paramètres {{...}} déclarés. Le Security Check recherche les mots de passe en clair et les données personnelles (PII) codées en dur, en masquant toujours la valeur trouvée.
Enregistrement dans le package du Design workspace, deploy, attente de l'état runtime et smoke test sur les derniers Message Processing Logs. Plusieurs profils de tenant (dev, test, prod) directement depuis l'interface graphique.
Parcourez les zip sans les extraire, lisez le XML avec coloration syntaxique, ouvrez le canvas BPMN avec une disposition hiérarchique et les propriétés de chaque étape. Sur chaque projet : View, Edit, Lint, Ripacchetta (réempaqueter), Deploy.
Classez une source de la KB comme template (par exemple SuccessFactors ou SFTP) : ses conventions deviennent des contraintes explicites. Les "questions guides" recueillent les exigences manquantes avant la génération : mapping, volumes, nouvelles tentatives, idempotence, sécurité.
Associez la documentation produit à SuccessFactors, S/4HANA OData, LDAP, Zucchetti ou SOAP. Pour chaque client, conservez mappings, règles et workflows dans une KB séparée, que le modèle n'utilise que lorsque vous sélectionnez ce client et le déverrouillez avec son mot de passe.
À partir d'un iFlow, générez la documentation en Markdown et en HTML imprimable en PDF : celle à remettre au client et celle destinée à qui en assurera la maintenance.
Le modèle n'écrit que la spécification. Le XML est construit par du code déterministe : une erreur du modèle se voit tout de suite et n'arrive jamais sur le tenant.
Décrivez le flux en langage naturel, avec template, profil produit et KB client en option.
SQLite + nomic-embed-text : les fragments les plus proches de vos iFlows entrent dans le contexte.
qwen2.5-coder avec un system prompt CPI, exécuté sur votre PC.
Étapes, adapters, paramètres, local process et gestion des erreurs dans une structure validée.
Assemble le XML BPMN2 à partir de blocs connus : pas de XML "inventé".
Références croisées, scripts présents, paramètres déclarés, validité du XML.
Paquet importable dans Integration Suite, consultable dans le canvas BPMN.
Enregistrement, deploy, état runtime et smoke test sur les logs.
Il suffit de Windows 10 ou 11 64 bits et d'un peu d'espace disque pour le modèle.
Téléchargez-le depuis ollama.com et installez-le. C'est le moteur qui exécute le modèle en local.
L'installeur copie l'application dans votre dossier utilisateur, sans droits d'administrateur. Vous pouvez aussi décompresser la version portable où vous voulez.
Dans l'application : menu Modello (Modèle) → Prepara o aggiorna il modello Ollama... (préparer ou mettre à jour le modèle Ollama). Il télécharge qwen2.5-coder (7B sur CPU, environ 5 Go ; 14B avec un GPU NVIDIA de 12 Go, environ 9 Go) et nomic-embed-text, puis indexe la knowledge base.
L'application consulte les GitHub Releases, télécharge le nouvel installeur, vérifie son SHA-256 et l'exécute en silence. Vos données (knowledge base, profils, iFlows générés) ne sont pas touchées.
Version portable : vous recevez un avis avec le lien vers le nouveau paquet et vous décidez quand le remplacer.
Réponse courte : sur votre PC, et nulle part ailleurs.
Le modèle tourne dans Ollama sur votre machine. Les demandes, les iFlows et la knowledge base ne sont envoyés à aucun service.
Les seules connexions externes vont vers GitHub Releases pour vérifier les mises à jour, et vers votre tenant quand vous le demandez.
Un mot de passe principal chiffre les configurations et les profils locaux. Sans lui, les fichiers restent illisibles.
Les client secret et les mots de passe des tenants sont stockés dans le Credential Manager de Windows, jamais dans des fichiers.
Les sources de chaque client sont exclues de la recherche générale et ne sont transmises au modèle que lorsque ce client est sélectionné et déverrouillé avec son mot de passe. Le mot de passe permet d'utiliser la KB, mais ne chiffre pas les fichiers sur le disque : pour les protéger, utilisez le chiffrement du disque, par exemple BitLocker.
Honnêteté sur le produit : c'est une bêta, et mieux vaut savoir ces choses avant de télécharger.
Démarrage par Timer et HTTPS, Content Modifier, XSLT, Groovy, Process Call et local process linéaires, Request-Reply HTTP/ProcessDirect/SuccessFactors, Send Mail et SFTP, un router OK/KO, Exception Subprocess. Splitter/Gather, Data Store ou plusieurs routers basculent en mode Markdown : le paquet doit être vérifié dans la Web UI avant le deploy.
Il implémente les OData API publiques d'Integration Suite, mais n'a été essayé que sur peu de tenants. À la première connexion, utilisez "Test connessione" (tester la connexion) et signalez les différences.
Avec le modèle 7B sur CPU, une génération prend quelques minutes. Avec un GPU NVIDIA et le modèle 14B, elle est beaucoup plus rapide et de meilleure qualité.
Sous Linux et macOS, l'application démarre depuis les sources, mais les secrets des tenants ne sont pas enregistrés : le deploy demande de saisir le secret à chaque session. L'installeur et la mise à jour automatique n'existent que pour Windows.
IFlow Assistant est gratuit et le restera. S'il vous fait gagner un après-midi, un café est la façon la plus simple de me le dire et de garder allumé le GPU qui essaie les nouveaux modèles.
Offrez-moi un café sur PayPalUn signalement bien rédigé sur GitHub compte beaucoup aussi.
Celles qui reviennent le plus souvent.
Non. Avec un CPU et au moins 16 Go de RAM, le modèle 7B fonctionne, mais une génération prend des minutes. Avec un GPU NVIDIA de 12 Go ou plus, le modèle 14B répond en quelques dizaines de secondes et produit des specs plus précises.
Non. La knowledge base est un fichier SQLite local, le modèle tourne dans Ollama sur votre machine et il n'y a pas de télémétrie. L'application ne contacte que GitHub Releases pour les mises à jour et votre tenant quand vous lancez un enregistrement, un deploy ou un import.
Oui. Le modèle cpi-iflow-builder est construit à partir d'un Modelfile inclus dans le paquet : vous pouvez changer le modèle de base (par exemple un autre coder disponible dans Ollama) et le régénérer depuis le menu Modello (Modèle) → Ricrea il modello dal Modelfile (ollama create). Le system prompt CPI reste le même.
Ajoutez les exports .zip à la knowledge base depuis l'onglet Knowledge base, ou importez-les directement depuis le tenant. Sélectionnez ensuite la source et utilisez "Template" pour la classer : à partir de là, elle apparaît dans le menu Template KB de la génération et ses conventions deviennent des contraintes explicites.
"Censisci + Deploy" (enregistrer et déployer) charge le paquet dans le package du Design workspace du tenant actif, lance le deploy, attend l'état runtime (STARTED ou ERROR), puis lit les derniers Message Processing Logs en guise de smoke test. Il ne touche à aucun autre artefact et ne supprime rien.
En partie. Le code est en Python et tkinter, il démarre donc depuis les sources avec les scripts du dossier install/. Il manque en revanche l'installeur, la mise à jour automatique et l'enregistrement des secrets des tenants, qui utilise aujourd'hui le Credential Manager de Windows.
Non. C'est un projet indépendant et open source (licence MIT), né pour un usage personnel, et il n'est ni affilié à SAP SE, ni sponsorisé, ni approuvé par elle. Il n'utilise que les API publiques documentées d'Integration Suite.