Quand le frontend ne passe pas de machine_id explicite, le backend VWB auto-sélectionne une machine Windows en interrogeant /api/v1/traces/ stream/machines. Le code prenait la première de la liste sans tri, donc l'ordre dépendait de l'ordre arbitraire renvoyé par le streaming server. Conséquence reproduite ce 2026-05-06 : un replay du workflow Urgence a été dispatché vers DESKTOP-ST3VBSD_windows alors que l'agent V1 actif polait depuis DESKTOP-58D5CAC_windows. /replay/next ne dispatchait aucune action puisque state.machine_id != polling_machine_id. Symptôme côté Dom : "rien ne se passe sur Windows". Correction : tri explicite par last_activity desc avant sélection. La machine retenue est désormais celle qui a heartbeaté le plus récemment (= celle qui POLLE actuellement le serveur). Le workflow.machine_id (machine d'origine d'enregistrement) reste distinct de la cible d'exécution : un workflow enregistré sur PC A peut être rejoué sur PC B grâce au pipeline 100% visuel qui recalcule anchors et coordonnées selon la résolution courante. C'était la vraie intention architecturale, masquée par le bug de tri.
Visual Workflow Builder
Interface graphique pour créer des workflows RPA par glisser-déposer, sans écrire de code.
État actuel (avril 2026) : la version active est
frontend_v4/(Vite + React, port 3002), lancée par./run_v4.shou./launch.sh(wrapper). Le dossierfrontend/est conservé pour référence legacy (Create React App, port 3000), lancé par./run.sh. Les sectionslaunch.sh setup/stop/restart/logsci-dessous sont historiques : seules./launch.sh(=./run_v4.sh) et./launch.sh legacy(=./run.sh) sont effectivement implémentées.
🚀 Démarrage Ultra-Rapide
Méthode Simple (Recommandée)
# Démarrer l'application complète (frontend_v4, port 3002)
./launch.sh
# Ouvrir http://localhost:3002 dans votre navigateur
Sur Windows :
# Configuration initiale (une seule fois)
launch.bat setup
# Démarrer l'application complète
launch.bat start
Prérequis
- Python 3.8+
- Node.js 16+
- npm
🎮 Commandes Principales
Script de Lancement Unifié
Le script launch.sh (ou launch.bat sur Windows) simplifie toutes les opérations :
# Démarrer en mode développement (avec hot reload)
./launch.sh start --dev
# Démarrer en mode production
./launch.sh start --prod
# Arrêter l'application
./launch.sh stop
# Redémarrer
./launch.sh restart
# Voir le statut
./launch.sh status
# Voir les logs en temps réel
./launch.sh logs
# Lancer tous les tests
./launch.sh test
# Configuration initiale
./launch.sh setup
# Nettoyer les fichiers temporaires
./launch.sh clean
# Aide complète
./launch.sh --help
Ports Personnalisés
# Frontend sur port 3001, backend sur port 5002
./launch.sh start --port 3001 --backend-port 5002
🧪 Tests
Tests Automatisés
# Tous les tests
./launch.sh test
# Tests spécifiques
./test_import_export.sh # Test import/export
./test_zoom_pan.sh # Test zoom et panoramique
Tests Manuels
- Interface utilisateur : http://localhost:3000
- API Health Check : http://localhost:5001/health
- Import/Export : Utilisez les boutons dans l'interface
- Zoom/Pan : Molette de souris + Ctrl+Drag
Architecture
Le projet est divisé en deux parties principales :
Frontend (React + TypeScript)
- Framework: React 18 avec TypeScript
- Canvas: react-flow-renderer pour le rendu des graphes avec zoom/pan personnalisé
- State Management: Hooks personnalisés avec Undo/Redo
- UI Components: Composants personnalisés + Material-UI
- Real-time: Socket.IO client pour synchronisation d'exécution
- Import/Export: Support JSON/YAML avec validation
- Build: Create React App avec TypeScript
Backend (Flask + Python)
- Framework: Flask avec Flask-SocketIO
- Database: SQLAlchemy (SQLite pour dev, PostgreSQL pour prod)
- Validation: JSON Schema + validation personnalisée
- Import/Export: API REST avec support multi-formats
- Cache: Redis (optionnel)
- Testing: Pytest + tests d'intégration
Structure du Projet
visual_workflow_builder/
├── launch.sh # 🚀 Script de lancement principal (Linux/Mac)
├── launch.bat # 🚀 Script de lancement principal (Windows)
├── backend/ # API Flask
│ ├── api/
│ │ ├── workflows.py # CRUD workflows
│ │ ├── import_export.py # Import/Export
│ │ ├── templates.py # Templates
│ │ └── websocket_handlers.py # WebSocket
│ ├── models/ # Modèles de données
│ ├── services/ # Logique métier
│ └── app.py # Point d'entrée
├── frontend/ # Interface React + TypeScript
│ ├── src/
│ │ ├── components/
│ │ │ ├── Canvas/ # Canvas principal avec zoom/pan
│ │ │ ├── ZoomControls/ # Contrôles de zoom
│ │ │ ├── ImportExport/ # Import/Export UI
│ │ │ └── UndoRedoToolbar/ # Undo/Redo
│ │ ├── hooks/
│ │ │ ├── useZoomPan.ts # Hook zoom/panoramique
│ │ │ ├── useWorkflowWithUndo.ts # Workflow + Undo
│ │ │ └── useExecutionSync.ts # Sync exécution
│ │ ├── utils/
│ │ │ ├── ImportExport.ts # Logique import/export
│ │ │ └── UndoManager.ts # Gestionnaire Undo/Redo
│ │ └── types/ # Types TypeScript
│ └── public/
├── test_import_export.sh # Tests import/export
├── test_zoom_pan.sh # Tests zoom/panoramique
└── docs/ # Documentation
Installation
Prérequis
- Node.js 18+ et npm
- Python 3.10+
- Redis (optionnel pour dev, requis pour prod)
Frontend
cd frontend
npm install
npm start # Démarre le serveur de développement sur http://localhost:3000
Backend
cd backend
python -m venv venv
source venv/bin/activate # Sur Windows: venv\Scripts\activate
pip install -r requirements.txt
cp .env.example .env # Configurer les variables d'environnement
python app.py # Démarre le serveur Flask sur http://localhost:5001
Développement
Frontend
npm start # Serveur de développement avec hot reload
npm run build # Build de production
npm test # Exécuter les tests
npm run lint # Vérifier le code avec ESLint
npm run type-check # Vérifier les types TypeScript
Backend
python app.py # Démarrer le serveur
pytest # Exécuter tous les tests
pytest tests/unit # Tests unitaires seulement
pytest -m property # Tests property-based seulement
pytest --cov # Tests avec couverture de code
black . # Formater le code
flake8 . # Vérifier le style
mypy . # Vérifier les types
Tests
Frontend
- Tests unitaires: Jest + React Testing Library
- Coverage: Minimum 70% requis
Backend
- Tests unitaires: Pytest
- Tests d'intégration: Pytest avec fixtures
- Tests property-based: Hypothesis
- Coverage: Minimum 70% requis
Configuration
Variables d'Environnement Backend
Voir .env.example pour la liste complète. Les principales :
FLASK_ENV: development ou productionSECRET_KEY: Clé secrète pour les sessionsDATABASE_URL: URL de la base de donnéesREDIS_URL: URL Redis pour le cacheCORS_ORIGINS: Origines autorisées pour CORS
Configuration Frontend
Le frontend se configure via webpack.config.js et les variables d'environnement peuvent être passées au build.
Déploiement
Production
-
Frontend: Build et déploiement sur CDN ou serveur web
npm run build # Les fichiers sont dans dist/ -
Backend: Déploiement avec Gunicorn + Nginx
gunicorn -k geventwebsocket.gunicorn.workers.GeventWebSocketWorker -w 1 app:app -
Base de données: Migrer vers PostgreSQL
-
Cache: Configurer Redis
-
Monitoring: Configurer logs et métriques
Roadmap
Phase 1: MVP (4-6 semaines)
- ✅ Structure du projet configurée
- ⏳ API REST de base
- ⏳ Canvas avec drag & drop
- ⏳ Nodes essentiels
- ⏳ Exécution simple
Phase 2: Fonctionnalités Avancées (4-6 semaines)
- ⏳ WebSocket temps réel
- ⏳ Templates avancés
- ⏳ Undo/Redo
- ⏳ Zoom/Pan optimisé
- ⏳ Variables management
Phase 3: Production (2-4 semaines)
- ⏳ Optimisations performance
- ⏳ Sécurité renforcée
- ⏳ Documentation complète
- ⏳ Déploiement production
Contribution
Voir le document de design complet dans .kiro/specs/visual-workflow-builder/design.md pour les détails d'architecture et les propriétés de correction à respecter.
License
MIT