Oui dans la solution initiale il fallait le serveur evQueue et un serveur web avec PHP pour faire le pont. Maintenant le javascript se connecte directement au serveur websockets intégré à evqueue.
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).
Nous recevrons votre retour avec grand plaisir, et particulièrement si vous êtes connaisseur d'autres solutions du marché.
Concernant nos motivations, nous avions fait à l'époque un état des lieux et nos contraintes étaient les suivantes :
Système Open Source
Gestion native de la parallélisation
Gestion de ré-essai sur les tâches en erreur
Accès aisé via une API pour une intégration avec le serveur Web
Légèreté et de préférence gestion en interface Web
Nous n'avions pas trouvé de solution satisfaisante sur l'ensemble de ces critères. Nous avons donc commencé à développer une solution relativement simple. Avec le temps nous avons ajouté pas mal de nouvelles fonctionnalités et travaillé l'interface graphique… et sommes parvenus à la version actuelle !
Pour supprimer une tâche il faut faire un clic droit dessus. Effectivement ce n'est pas dans la documentation je vais la mettre à jour.
Concernant la touche ENTER je n'ai pas été confronté à ce problème mais je vais faire des tests.
Si vous travaillez pas mal avec le moteur, vous verrez que la parallélisation est très pratique pour accélérer les traitements. Par ailleurs avec les files dynamiques, il est possible d'avoir une parallélisation par marchine (si les tâches s'exécutent en distant).
Les conditions font partie d'une utilisation qui est déjà un peu avancée. Elles fonctionnent en XPath donc si vous ne connaissez pas ce langage c'est un peu plus délicat au début. Ceci étant, nous sommes preneurs de vos retour pour améliorer la documentation : lorsqu'on a développé un outil, c'est parfois difficile de se mettre à la place d'un utilisateur débutant !
N'hésitez donc pas si avez d'autres retour, l'adresse email de contact est sur le site.
Oui c'est une utilisation que nous avons, des utilisateurs peuvent déclencher des traitements depuis l'interface directement ou depuis une interface ad-hoc qui utilise alors l'API evQueue pour déclencher le traitement.
Nous avons une gestion des utilisateurs :
le profil admin est essentiellement réservé aux développeurs (ou admins) qui vont créer les workflows.
le profil utilisateur a des droits par workflow, par exemple il ne peut que lancer un workflow donné.
La gestion des ressources est gérée nativement par le système de files qui est global à toutes les tâches. Si vous créez une file 'lecteur de cartouche' avec une concurrence de 1, il vous suffira ensuite d'assigner toutes les tâches qui utilisent le dit lecteur à cette file. Ceci vous garantit une utilisation exclusive de la ressource.
Vous avez un exemple ici
Il s'agit de files d'execution (de l'anglais queue). Ce système permet de gérer la parallélisation et de limiter le nombre maximum de tâches parallèles via la concurrence de ces mêmes files.
Concernant la reprise, vous pouvez regardez le "Retry Schedule", il permet de relancer automatiquement une tâche en erreur un certain nombre de fois et à des intervalles variables (réglables par niveaux).
La mise en pause des tâches est possible dans les workflow planifiés (qui sont l'équivalent des crons). Vous pouvez ainsi suspendre une tâche.
Le déclanchement sur calendrier est possible via les "Scheduled Workflows", vous avez une option heure fixe ou calendrier avec possibilité de sélectionner des dates multiples.
Le déclenchement sur événement est possible via l'API réseau. Il est également possible (et c'est ce que nous faisons) d'utiliser le retry schedule : un tâche est lancée et vérifie l'existence du fichier. Si il est absent, une erreur est retournée et le retry schedule va se charger de la relancer. Quand le fichier apparaît, la tâche s'exécute correctement et le workflow enchaine la tâche suivante qui effectue le traitement.
[^] # Re: Questions
Posté par coldsource . En réponse à la dépêche La version 3.0 d’evQueue est disponible. Évalué à 3.
Oui dans la solution initiale il fallait le serveur evQueue et un serveur web avec PHP pour faire le pont. Maintenant le javascript se connecte directement au serveur websockets intégré à evqueue.
[^] # 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,
[^] # Re: Impatient de tester
Posté par coldsource . En réponse à la dépêche La version 2.0 d’evQueue est disponible. Évalué à 1.
Bonjour,
Nous recevrons votre retour avec grand plaisir, et particulièrement si vous êtes connaisseur d'autres solutions du marché.
Concernant nos motivations, nous avions fait à l'époque un état des lieux et nos contraintes étaient les suivantes :
Nous n'avions pas trouvé de solution satisfaisante sur l'ensemble de ces critères. Nous avons donc commencé à développer une solution relativement simple. Avec le temps nous avons ajouté pas mal de nouvelles fonctionnalités et travaillé l'interface graphique… et sommes parvenus à la version actuelle !
[^] # Re: En cours de test ...
Posté par coldsource . En réponse à la dépêche La version 2.0 d’evQueue est disponible. Évalué à 1.
Bonjour et merci de ce retour !
Quelques réponses aux points soulevés :
Pour supprimer une tâche il faut faire un clic droit dessus. Effectivement ce n'est pas dans la documentation je vais la mettre à jour.
Concernant la touche ENTER je n'ai pas été confronté à ce problème mais je vais faire des tests.
Si vous travaillez pas mal avec le moteur, vous verrez que la parallélisation est très pratique pour accélérer les traitements. Par ailleurs avec les files dynamiques, il est possible d'avoir une parallélisation par marchine (si les tâches s'exécutent en distant).
Les conditions font partie d'une utilisation qui est déjà un peu avancée. Elles fonctionnent en XPath donc si vous ne connaissez pas ce langage c'est un peu plus délicat au début. Ceci étant, nous sommes preneurs de vos retour pour améliorer la documentation : lorsqu'on a développé un outil, c'est parfois difficile de se mettre à la place d'un utilisateur débutant !
N'hésitez donc pas si avez d'autres retour, l'adresse email de contact est sur le site.
Bonne soirée,
[^] # Re: En cours de test ...
Posté par coldsource . En réponse à la dépêche La version 2.0 d’evQueue est disponible. Évalué à 1.
Bonjour Christophe,
Oui c'est une utilisation que nous avons, des utilisateurs peuvent déclencher des traitements depuis l'interface directement ou depuis une interface ad-hoc qui utilise alors l'API evQueue pour déclencher le traitement.
Nous avons une gestion des utilisateurs :
La gestion des ressources est gérée nativement par le système de files qui est global à toutes les tâches. Si vous créez une file 'lecteur de cartouche' avec une concurrence de 1, il vous suffira ensuite d'assigner toutes les tâches qui utilisent le dit lecteur à cette file. Ceci vous garantit une utilisation exclusive de la ressource.
Vous avez un exemple ici
[^] # Re: Translation
Posté par coldsource . En réponse à la dépêche La version 2.0 d’evQueue est disponible. Évalué à 4.
Bonjour,
Il s'agit de files d'execution (de l'anglais queue). Ce système permet de gérer la parallélisation et de limiter le nombre maximum de tâches parallèles via la concurrence de ces mêmes files.
[^] # Re: Envoi de jobs sur plusieurs machines ?
Posté par coldsource . En réponse à la dépêche Publication d'evQueue sous licence libre. Évalué à 1.
Bonjour,
Oui c'est exactement l'objectif !
[^] # Re: ordonnancement
Posté par coldsource . En réponse à la dépêche Publication d'evQueue sous licence libre. Évalué à 7.
Bonjour,
Ce que vous demandez est possible :
Concernant la reprise, vous pouvez regardez le "Retry Schedule", il permet de relancer automatiquement une tâche en erreur un certain nombre de fois et à des intervalles variables (réglables par niveaux).
La mise en pause des tâches est possible dans les workflow planifiés (qui sont l'équivalent des crons). Vous pouvez ainsi suspendre une tâche.
Le déclanchement sur calendrier est possible via les "Scheduled Workflows", vous avez une option heure fixe ou calendrier avec possibilité de sélectionner des dates multiples.
Le déclenchement sur événement est possible via l'API réseau. Il est également possible (et c'est ce que nous faisons) d'utiliser le retry schedule : un tâche est lancée et vérifie l'existence du fichier. Si il est absent, une erreur est retournée et le retry schedule va se charger de la relancer. Quand le fichier apparaît, la tâche s'exécute correctement et le workflow enchaine la tâche suivante qui effectue le traitement.