Application industrielle
Migration d’une solution spécialisée
Migration d’une application de bureau VFP 6 reposant sur des calculs propriétaires très complexes pour un usage industriel spécialisé. Toute la logique a été validée en 1:1 puis transférée dans une application web moderne afin d’en préserver la précision.
Les questions qui reviennent précisément dans ce type de projet
Les points suivants sont régulièrement décisifs pour ce type de système ancien - et la raison pour laquelle une migration échoue rarement à cause du langage de programmation.
Et les spécificités VFP comme `SET ANSI`/`EXACT` ?
Ces commandes modifient en profondeur la manière dont VFP compare les données, par exemple `SET EXACT` pour les comparaisons de chaînes. Nous en maîtrisons la sémantique en détail. Pendant l’audit, nous identifions ces commandes `SET` et en préservons le comportement grâce à des tests « Golden Master », c’est-à-dire des cas automatisés qui valident le comportement historique en 1:1 afin que le nouveau système reste fonctionnellement identique.
Notre application utilise le "buffering optimiste" de VFP. Comment le gérer sur le web ?
Excellente question. C’est l’un des enjeux majeurs d’une migration web. La gestion de conflits de `TABLEUPDATE()` dans VFP, lorsqu’un autre utilisateur a modifié l’enregistrement, doit être modélisée explicitement dans le nouveau système. Sur le web, cela se traite généralement via un contrôle de concurrence : au chargement, l’enregistrement reçoit un jeton invisible (ETag). Lors de l’enregistrement, le serveur vérifie si ce jeton est toujours identique. Si ce n’est plus le cas, parce qu’un autre utilisateur a enregistré avant, l’opération est bloquée et l’utilisateur est informé. Cela crée un processus sûr et transparent pour éviter les conflits de données.
Nous utilisons `xCase`, `Stonefield Query`, `FoxBarcode`. Cela vous parle ?
Oui, tout à fait. Nous connaissons très bien l’écosystème VFP. Les modèles de base issus de `xCase` constituent une source précieuse pour la rétro-ingénierie. Nous sommes familiers des outils de reporting comme `Stonefield Query`, des générateurs de codes-barres comme `FoxBarcode` et des stratégies de traitement des DBF chiffrés avec `Cryptor`. Nous connaissons aussi les contrôles ActiveX courants d’éditeurs comme `DBITech` ou `Codejock`, ainsi que leurs équivalents web modernes.
Comment garantissez-vous les performances sur le web ? VFP est très rapide en local.
C’est une préoccupation légitime. L’écart entre des DBF locales et la latence web est bien réel. Nous traitons la performance via (1) une architecture API propre plutôt qu’un accès direct à la base, (2) une mise en cache intelligente des données de référence et (3) l’optimisation des requêtes et des index. Avec vous, nous définissons des objectifs de performance (KPI) pour les écrans et les processus métier les plus critiques.
Cela ressemble à votre système ?
Alors accordons-y 45 minutes. Sans engagement, sans frais, et avec une évaluation honnête à la fin - y compris si celle-ci consiste à d’abord sécuriser l’exploitation existante.
Demander un entretien stratégique