Je vais tenter de répondre à vos diverses remarques.
Tout d'abord, concernant l'ergonomie de l'éditeur de workflows, il est vrai qu'elle peut être améliorée. Nous prendrons en compte vos remarques, même si en l'état passé 2H de travail, vous verrez que vous ne rencontrerez plus de problèmes.
Le produit étant maintenant assez complexe, je pense qu'il faut effectivement lire la documentation, tout du moins les différents concepts, si vous souhaitez utiliser pleinement les enchaînements de tâches et pas simplement exécuter une commande. La plupart de vos remarques viennent à mon avis d'une mauvaise compréhension des concepts.
Lorsque vous déclarez une tâche, il est tout à fait possible de passer directement des arguments comme vous le souhaitez si ces arguments sont statiques. L'ajout d'argument via l'édition permet d'ajouter des arguments dynamiques qui proviennent par exemple de sorties de tâches précédentes (très utile avec les boucles).
La notion de tâche et de job est elle aussi expliquée dans la documentation. Ces deux entités servent à la gestion de la parallélisation et au contrôle de flux. Un job peut contenir plusieurs tâches. Il se termine quand l'ensemble des tâches est terminé. Il assure donc un rôle de barrière de synchronisation. Par ailleurs, vous pouvez également mettre une condition sur un job, ce qui va permettre de ne pas exécuter l'ensemble des tâches qu'il contient au lieu de dupliquer la condition autant de fois que le job contient de tâches. Il en va de même pour les boucles qui peuvent être positionnées sur les jobs ou les tâches. Une boucle sur un job va dupliquer l'ensemble de ses tâches.
Supprimer une tâche utilisée dans un workflow est une erreur de développement. Les tâches n'ont pas vocation à être supprimées si elles sont utilisées. Il est vrai par contre que nous pourrions ajouter un avertissement pour éviter des erreurs de manipulation. La définition des tâches permet avant tout de contrôler les paramètres d'entrée sortie (mode XML ou texte par exemple).
evQueue ne fonctionne pas par plan d'exécution. Un workflow n'est pas un plan, c'est un enchainement de tâches simples qui a vocation à effectuer un traitement. Par exemple, récupérer un fichier sur un serveur FTP, puis traiter ses données et enfin les insérer en base. Ceci peut être réalisé par 3 tâches. L'intérêt est d'apporter de la visibilité aux administrateurs et développeurs en cas de problème (au lieu d'avoir un grand code monolithique). Autre exemple : redimentionner des images. C'est un cas très fréquent sur le web et très consommateur de ressources. C'est ici que les boucles et la parallélisation prennent tout leur sens. C'est bien pour cette raison que les files sont globales : si 100 personnes uploadent des photos sur notre site, nous ne souhaitons pas que tous les traitement démarrent en même temps. C'est donc evQueue qui va gérer la cadence en fonction du paramétrage des files pour ne pas surcharger la machine qui effectue les traitements.
Les sauvegardes sont déjà possibles via Git au niveau des workflows et des tâches.
Les conditions sont libres, elles utilisent le langage XPath.
La gestion des jours fériés est effectivement une bonne idée, de même que l'inclusion ou exclusion de jours.
Enfin, et de manière générale, notre solution propose une approche différente des solutions du marché. Ce n'est donc pas très étonnant que vous trouviez cela déroutant. L'orientation est résolument tournée Web avec des déclenchements dynamiques, via des actions des utilisateurs par exemple (upload d'un contenu, prise d'une commande etc). Le but est de clarifier les traitements en les subdivisant en sous parties visibles pour un non développeur tout en assurrant une gestion des ressources de la (des) mâchine(s) hôte(s).
[^] # Re: Impatient de tester
Posté par coldsource . En réponse à la dépêche La version 2.0 d’evQueue est disponible. Évalué à 1. Dernière modification le 22 novembre 2017 à 14:18.
Bonjour et merci pour votre retour.
Je vais tenter de répondre à vos diverses remarques.
Tout d'abord, concernant l'ergonomie de l'éditeur de workflows, il est vrai qu'elle peut être améliorée. Nous prendrons en compte vos remarques, même si en l'état passé 2H de travail, vous verrez que vous ne rencontrerez plus de problèmes.
Le produit étant maintenant assez complexe, je pense qu'il faut effectivement lire la documentation, tout du moins les différents concepts, si vous souhaitez utiliser pleinement les enchaînements de tâches et pas simplement exécuter une commande. La plupart de vos remarques viennent à mon avis d'une mauvaise compréhension des concepts.
Lorsque vous déclarez une tâche, il est tout à fait possible de passer directement des arguments comme vous le souhaitez si ces arguments sont statiques. L'ajout d'argument via l'édition permet d'ajouter des arguments dynamiques qui proviennent par exemple de sorties de tâches précédentes (très utile avec les boucles).
La notion de tâche et de job est elle aussi expliquée dans la documentation. Ces deux entités servent à la gestion de la parallélisation et au contrôle de flux. Un job peut contenir plusieurs tâches. Il se termine quand l'ensemble des tâches est terminé. Il assure donc un rôle de barrière de synchronisation. Par ailleurs, vous pouvez également mettre une condition sur un job, ce qui va permettre de ne pas exécuter l'ensemble des tâches qu'il contient au lieu de dupliquer la condition autant de fois que le job contient de tâches. Il en va de même pour les boucles qui peuvent être positionnées sur les jobs ou les tâches. Une boucle sur un job va dupliquer l'ensemble de ses tâches.
Supprimer une tâche utilisée dans un workflow est une erreur de développement. Les tâches n'ont pas vocation à être supprimées si elles sont utilisées. Il est vrai par contre que nous pourrions ajouter un avertissement pour éviter des erreurs de manipulation. La définition des tâches permet avant tout de contrôler les paramètres d'entrée sortie (mode XML ou texte par exemple).
evQueue ne fonctionne pas par plan d'exécution. Un workflow n'est pas un plan, c'est un enchainement de tâches simples qui a vocation à effectuer un traitement. Par exemple, récupérer un fichier sur un serveur FTP, puis traiter ses données et enfin les insérer en base. Ceci peut être réalisé par 3 tâches. L'intérêt est d'apporter de la visibilité aux administrateurs et développeurs en cas de problème (au lieu d'avoir un grand code monolithique). Autre exemple : redimentionner des images. C'est un cas très fréquent sur le web et très consommateur de ressources. C'est ici que les boucles et la parallélisation prennent tout leur sens. C'est bien pour cette raison que les files sont globales : si 100 personnes uploadent des photos sur notre site, nous ne souhaitons pas que tous les traitement démarrent en même temps. C'est donc evQueue qui va gérer la cadence en fonction du paramétrage des files pour ne pas surcharger la machine qui effectue les traitements.
Les sauvegardes sont déjà possibles via Git au niveau des workflows et des tâches.
Les conditions sont libres, elles utilisent le langage XPath.
La gestion des jours fériés est effectivement une bonne idée, de même que l'inclusion ou exclusion de jours.
Enfin, et de manière générale, notre solution propose une approche différente des solutions du marché. Ce n'est donc pas très étonnant que vous trouviez cela déroutant. L'orientation est résolument tournée Web avec des déclenchements dynamiques, via des actions des utilisateurs par exemple (upload d'un contenu, prise d'une commande etc). Le but est de clarifier les traitements en les subdivisant en sous parties visibles pour un non développeur tout en assurrant une gestion des ressources de la (des) mâchine(s) hôte(s).
Cordialement,