Qu’est-ce qui a motivé cette demande de liste de souhaits ? Des difficultés rencontrées avec le générateur de flux de travail lors de modifications de tables/colonnes (table introuvable, colonne introuvable, etc.).
Quelle amélioration souhaiteriez-vous voir ? J’aimerais que le générateur de flux de travail utilise davantage les variables de manière native, aussi bien côté serveur JMP que dans l’interface utilisateur.
Lorsque j'exécute ou partage un workflow et qu'un élément comme le nom d'une table change, JMP offre généralement à l'utilisateur la possibilité de corriger l'erreur. Cependant, il est souvent difficile de déterminer à quelle étape du processus la modification doit être effectuée. De ce fait, les utilisateurs, moi y compris, peuvent être tentés d'interrompre le workflow pour explorer une autre piste (Attendez, qu'est-ce que JMP attendait qui n'était pas là ? Comment puis-je résoudre le problème ? etc.).
Et quand je vais vérifier ce qui se passe, je risque de trouver une erreur ou un comportement qui devrait être dynamique. Du coup, je dois corriger TOUS les endroits où une référence à une colonne ou à une table de données était codée en dur. Si JMP l'avait simplement définie comme une variable dès le départ, j'aurais juste eu à la modifier une seule fois.
De plus, je peux savoir, avant même de commencer un flux de travail, que des éléments comme les noms des tables de données ou les colonnes peuvent varier. Faciliter l'ajout de variables au flux de travail, afin de les définir par défaut ou d'inviter l'utilisateur, devient alors extrêmement précieux.
Pourquoi cette idée est-elle importante ? Le générateur de workflow est extrêmement performant et permet d'automatiser des tâches sans connaissances approfondies en programmation. Tant qu'il reste inchangé, il fonctionne à merveille. JMP gère déjà bien les éventuelles différences, et une meilleure gestion des variables permettrait d'aller encore plus loin. De plus, l'intégration native de la gestion des variables au processus facilitera la prise en main des scripts : au lieu de voir des valeurs codées en dur partout, il sera clair que vous définissez et utilisez des variables tout au long du processus. Le seul bémol ? Les exportations JSL du générateur de workflow pourraient nécessiter la création d'un espace de travail dédié (il est essentiel d'éviter un wrapper local volumineux pour prévenir les conflits de variables).
Je suis d'accord, il faudrait trouver un moyen de rendre le journal amélioré et le WFB plus génériques. Une solution simple serait peut-être d'ajouter une option permettant au journal amélioré d'utiliser la fonction Current Data Table() au lieu d'une référence explicite à la table. Je constate que cela représente environ 90 % des modifications que je dois apporter au JSL généré dans le journal amélioré et le WFB.
Merci d'avoir soumis cette demande !
