J'ai testé votre solution et je dois vous avouer que je suis très partagé par cette première utilisation. Veuillez garder en tête que ce qui suit sera très subjectif et comparé à ce que je connais. Avant toutes choses, je dois dire que le travail accompli est déja remarquable et je suis certains que pour une utilisation simple et restreinte, cette solution est tout à fait envisageable.
L'installation s'est correctement passé et il vrai que la simplicité est de rigueur. Je suis donc tombé sur une interface claire qui va à l'essentiel. Certainement un peu trop car je constate tout de suite que le développement du produit est clairement tourné pour avoir un résultat fonctionnel/efficace mais pas très pratique.
Je vous avoue également que mon premier réflexe n'était pas de lire la documentation utilisateur et j'ai eu tord car sans elle, le logiciel n'est clairement pas utilisable et c'est un vrai problème.
Sur la création d'un Workflow, lorsque je vois un icone de poubelle, ma première réaction est de sélectionner le Job et cliquer sur la poubelle et pas forcement glisser/déplacer l'objet sur la poubelle.
Toujours sur le Workflow, L'icone de sauvegarde ne sert à rien en l'état. Car lorsque je quitte la fenêtre, on m'oblige à sauvegarder.
Enfin, quand on supprime le dernier job d'un Workflow, on ne peut plus en rajouter et j'étais obligé de quitter la page. Vous allez me dire que c'est du détail mais on se sent vite frustré et en toute sincérité, si vous souhaitez que les gens utilisent votre produit, rendez le plus accessible en ajoutant beaucoup plus d'aide et en accompagnant l'utilisateur en commençant par avoir une vrai gestion des erreurs et pas simplement une petite fenêtre qui indique une erreur incompréhensible.
Pour l'aspect fonctionnel, j'ai eu du mal à comprendre qu'un tache n'est juste que la déclaration du binaire à utiliser pour réaliser l'action. Pourquoi je ne peux pas définir une tache avec !/bin/echo 'Première tache' ? Obliger de passer par un argument au niveau du Job qui se trouve dans le Workflow.
A mon sens, le niveau de 'tache' n'a pas lieu d’être et n'apporte aucun avantage vis à vis du job. Cet objet doit être fusionné avec le Job.
Le Job est la définition de l'action à réaliser avec ou sans ses différents paramètres/arguments (input/output, Condition OK/KO, connexion distante, etc ..). Le job doit pouvoir être mutualisé sur plusieurs Workflow. (1 seule définition, plusieurs manière de l'utiliser)
La tache rajoute de la complexité au processus et certainement beaucoup de dépendance.
Enfin, les deux solutions que je connais (Control-M et TWS) utilisent deux paradigmes que j'ai du mal à retrouver dans evQueue.
- La définition unique des objets en base : Elle représente l'ordonnancement attendu
- La gestion de l'ordonnancement par plan d’exécution : Elle représente l’exécution de l'ordonnancement attendu entre deux dates définit. (7J, 24H, ...)
Que ce passe-t-il sur evQueue si je supprime une tache qui est en cours d’exécution ou qui peut prendre du temps à s’exécuter, ou qui est prévu de s’exécuter ? : Task execution : Unknown object name.
J'ai l'impression que la définition c'est le Workflow et le plan d’exécution c'est une fusion entre la Queue et le Scheduled Workflow.
Peux être que ces deux règles sont à remettre en cause mais s'ils ont fait ça, je suppose qu'il y a de multitude de bonne raison.
Par ailleurs, si vous suivez ces deux règles, la gestion de la concurrence prend tous son sens au chargement du plan. Ce n'est pas un objet de la Queue, c'est une ressource liée au Job.
Si aujourd'hui vous avez plus de 5000 jobs qui sont ordonnancés par evQueue, c'est que votre modèle fonctionne assez bien. Cependant, je peux vous dire qu'il ne ressemble pas au deux que je connais.
Pour finir, je peux également vous proposer des idées d'améliorations si çe stade de la lecture vous ne me detestez pas encore.
- Calendrier d’exécution (Inclusion/Exclusion de jour, Jour fériés ?)
- Utilisateurs partagés (1 objets user/mdp qui peut être utilisé dans plusieurs Jobs)
- Améliorer la gestion des conditions (Laisser libre : Cela peut être le statut du Job précédant mais aussi une simple chaîne de caractère attaché au Job précédant de type FIRSTJOB_FORCEOK)
- Modèle de Job (Job de transfert, Job de Webservice, Job de type Script: Objectif, faciliter la définition en ne saisissant que des paramètres tout en gardant la possibilité d'avoir un niveau avancé laissant libre la définition du Job)
- Sauvegarde / Restauration des objets
- ...
J’espère que mes remarques ne seront pas mal interprétées et/ou mal perçues, je ne donnais qu'un premier avis. Actuellement, j'ai beaucoup de mal à utiliser votre solution mais peut être que je suis trop formaté à ce que je connais.
Je surveillerai les futures mises à jour avec beaucoup d'attention.
[^] # Re: Impatient de tester
Posté par Binou . En réponse à la dépêche La version 2.0 d’evQueue est disponible. Évalué à 8.
Bonjour,
J'ai testé votre solution et je dois vous avouer que je suis très partagé par cette première utilisation. Veuillez garder en tête que ce qui suit sera très subjectif et comparé à ce que je connais. Avant toutes choses, je dois dire que le travail accompli est déja remarquable et je suis certains que pour une utilisation simple et restreinte, cette solution est tout à fait envisageable.
L'installation s'est correctement passé et il vrai que la simplicité est de rigueur. Je suis donc tombé sur une interface claire qui va à l'essentiel. Certainement un peu trop car je constate tout de suite que le développement du produit est clairement tourné pour avoir un résultat fonctionnel/efficace mais pas très pratique.
Je vous avoue également que mon premier réflexe n'était pas de lire la documentation utilisateur et j'ai eu tord car sans elle, le logiciel n'est clairement pas utilisable et c'est un vrai problème.
Sur la création d'un Workflow, lorsque je vois un icone de poubelle, ma première réaction est de sélectionner le Job et cliquer sur la poubelle et pas forcement glisser/déplacer l'objet sur la poubelle.
Toujours sur le Workflow, L'icone de sauvegarde ne sert à rien en l'état. Car lorsque je quitte la fenêtre, on m'oblige à sauvegarder.
Enfin, quand on supprime le dernier job d'un Workflow, on ne peut plus en rajouter et j'étais obligé de quitter la page. Vous allez me dire que c'est du détail mais on se sent vite frustré et en toute sincérité, si vous souhaitez que les gens utilisent votre produit, rendez le plus accessible en ajoutant beaucoup plus d'aide et en accompagnant l'utilisateur en commençant par avoir une vrai gestion des erreurs et pas simplement une petite fenêtre qui indique une erreur incompréhensible.
Pour l'aspect fonctionnel, j'ai eu du mal à comprendre qu'un tache n'est juste que la déclaration du binaire à utiliser pour réaliser l'action. Pourquoi je ne peux pas définir une tache avec !/bin/echo 'Première tache' ? Obliger de passer par un argument au niveau du Job qui se trouve dans le Workflow.
A mon sens, le niveau de 'tache' n'a pas lieu d’être et n'apporte aucun avantage vis à vis du job. Cet objet doit être fusionné avec le Job.
Le Job est la définition de l'action à réaliser avec ou sans ses différents paramètres/arguments (input/output, Condition OK/KO, connexion distante, etc ..). Le job doit pouvoir être mutualisé sur plusieurs Workflow. (1 seule définition, plusieurs manière de l'utiliser)
La tache rajoute de la complexité au processus et certainement beaucoup de dépendance.
Enfin, les deux solutions que je connais (Control-M et TWS) utilisent deux paradigmes que j'ai du mal à retrouver dans evQueue.
- La définition unique des objets en base : Elle représente l'ordonnancement attendu
- La gestion de l'ordonnancement par plan d’exécution : Elle représente l’exécution de l'ordonnancement attendu entre deux dates définit. (7J, 24H, ...)
Que ce passe-t-il sur evQueue si je supprime une tache qui est en cours d’exécution ou qui peut prendre du temps à s’exécuter, ou qui est prévu de s’exécuter ? : Task execution : Unknown object name.
J'ai l'impression que la définition c'est le Workflow et le plan d’exécution c'est une fusion entre la Queue et le Scheduled Workflow.
Peux être que ces deux règles sont à remettre en cause mais s'ils ont fait ça, je suppose qu'il y a de multitude de bonne raison.
Par ailleurs, si vous suivez ces deux règles, la gestion de la concurrence prend tous son sens au chargement du plan. Ce n'est pas un objet de la Queue, c'est une ressource liée au Job.
Si aujourd'hui vous avez plus de 5000 jobs qui sont ordonnancés par evQueue, c'est que votre modèle fonctionne assez bien. Cependant, je peux vous dire qu'il ne ressemble pas au deux que je connais.
Pour finir, je peux également vous proposer des idées d'améliorations si çe stade de la lecture vous ne me detestez pas encore.
- Calendrier d’exécution (Inclusion/Exclusion de jour, Jour fériés ?)
- Utilisateurs partagés (1 objets user/mdp qui peut être utilisé dans plusieurs Jobs)
- Améliorer la gestion des conditions (Laisser libre : Cela peut être le statut du Job précédant mais aussi une simple chaîne de caractère attaché au Job précédant de type FIRSTJOB_FORCEOK)
- Modèle de Job (Job de transfert, Job de Webservice, Job de type Script: Objectif, faciliter la définition en ne saisissant que des paramètres tout en gardant la possibilité d'avoir un niveau avancé laissant libre la définition du Job)
- Sauvegarde / Restauration des objets
- ...
J’espère que mes remarques ne seront pas mal interprétées et/ou mal perçues, je ne donnais qu'un premier avis. Actuellement, j'ai beaucoup de mal à utiliser votre solution mais peut être que je suis trop formaté à ce que je connais.
Je surveillerai les futures mises à jour avec beaucoup d'attention.
Merci de m'avoir lu.
Binou