Utilisation module Workflow

[DavidP-certam]

Bonjour,

J’ai installé sur un serveur Debian Lenny la version d’Egroupware 1.4 packagée de debian
apache2 2.2.8-4~lenny1
mysql-server 5.0.51a-9+lenny2
php5 5.2.5-3+lenny2

J’ai récupéré la version svn de workflow sur http://svn.egroupware.org/egroupware/trunk/workflow et installé l’application dans egroupware.
Afin de me familiariser avec le module, j’ai recréé l’exemple CD loans selon les instructions de création de processus trouvé dans le manuel de Galaxy ( Galaxy_manual.pdf)
et le code des activités selon le wiki (CD_loans workflow example) )

Après avoir mappé le rôle user à l’utilisateur demo et le rôle admin à l’utilisateur admin, j’ai tenté d’utiliser le process.

Quand, en tant que demo, je lance une nouvelle instance “request loan”, j’obtiens bien le formulaire correspondant au code/template mais lorsque je valide, j’obtiens le message suivant (j’ai positionné le flag php display_errors à On) :
sync: Echec de l’obtention d’un verrou sur la table instances

Une instance est pourtant bien créée puisque que dans l’Ecran “Mes Processus” le compteur d’instance est passé de 0 à 1. Lorsque je clique sur ce chiffre pour afficher l’écran “Mes Instances”, cela m’inscrit “Il n’y a aucune instance disponible”

Dans l’écran “Mes activités” : Il n’y a aucune activité utilisateur disponible

Maintenant, en tant qu’admin:
Le superviseur d’instances m’indique bien qu’une instance de l’utilisateur Demo est en cours
L’écran Mes Processus m’indique 4 activités et 1 instance
et je n’arrive pas à accéder à l’activité “approve loan” puisqu’elle n’apparait nulle part:
l’écran “Mes activités” indique "Il n’y a aucune activité utilisateur disponible"
l’écran “Mes instances” indique “Il n’y a aucune instance disponible”

et là je suis paumé
les tables créées sont en MyISAM, le fait qu’elles ne soient pas en InnoDB peut-il produire ce phénomène?

Je joins le processus que j’ai créé à partir de la documentation, des fois que l’erreur provienne de ma recopie: Cd_loans_10.xml (7.02 KB)

Merci d’avance si vous pouvez me donner des pistes de résolution.
DavidP

[DavidP-certam]

Re-bonjour,

juste pour apporter une précision et après lecture des bugs egroupware-Bugs-1323602 et [ 1328769 ] MySQL is not working with the workflow,
j’ai modifié toutes les tables egw_wf* de MyISAM en InnoDB, réimporté le processus XML et j’obtiens toujours la même erreur.
(idem avec testJoin)

En fait, quel SGBD est préconisé pour faire tourner workflow si MySQL ne fonctionne vraiment pas?
Merci

[Regis_Leroy]

au niveau sgbd postgresql ou MySQl en mode innodb et pas Misam (pou les
transactions)
Sinon les exemples fournis avec le workflow, dans workflow/doc/examples sont
plu sà jour qu ele cd loan.

Régis,

[DavidP-certam]

Bonjour et merci de votre réponse,

j’ai donc installé postgresql-8.3 sur mon serveur et refait une install de zero d’Egroupware.
Lorsque j’installe workflow via le gestionnaire d’applications (via setup): j’obtiens ce message
Create Table egw_wf_agent_mail_smtp
app_registered(): checking workflow, table: egw_applications… app not registered
register_app(): workflow, version: 1.3.00.000, table:

Cela ne me semblait pas trop grave, j’ai donc continué dans l’application Workflow: importation du XML, mapping des rôles, compilation et activation du processus => pas de message d’erreur

Quand je vais dans Nouvelle Instance, j’obtiens ce message d’erreur pour le moins sybillin et ne me permettant pas de trouver le problème:
they were some SQL errors in the database, please warn your sysadmin.

et le processus CD_loans n’est pas présent dans la liste…

Si vous aviez une petite piste de résolution de problème sous la main, je suis preneur

[Regis_Leroy]

C’est effectivement léger comme message d’erreur, mais c’est une sécurité,
tu peux avoir plus d’infos sur l’erreur SQL via les logs PHP ou directmenet
-mieux) via les logs postgresql, regarde le fichier de conf de postgresql
pour activer les logs.

Régis,

[DavidP-certam]

voici le message d’erreur que j’obtiens dans le log de postgresql

Warning: postgres7 error: ERREUR: l’opérateur n’existe pas : character varying = integer at character 716 HINT: Aucun opérateur ne correspond au nom donné et aux types d’arguments. Vous devez ajouter des conversions explicites de type. in query:
select distinct(gp.wf_p_id), gp.wf_is_active, gp.wf_name as wf_procname, gp.wf_normalized_name as normalized_name, gp.wf_version as wf_version, gp.wf_version as version from egw_wf_processes gp INNER JOIN egw_wf_activities ga ON gp.wf_p_id=ga.wf_p_id INNER JOIN egw_wf_activity_roles gar ON gar.wf_activity_id=ga.wf_activity_id INNER JOIN egw_wf_roles gr ON gr.wf_role_id=gar.wf_role_id INNER JOIN egw_wf_user_roles gur ON gur.wf_role_id=gr.wf_role_id where gp.wf_is_active=? and ((gur.wf_user=? and gur.wf_account_type=‘u’) or (gur.wf_user in (-1,-2) and gur. in /usr/share/egroupware/workflow/inc/engine/src/common/Base.php on line 185

Warning: postgres7 error: ERREUR: l’opérateur n’existe pas : character varying = integer at character 454 HINT: Aucun opérateur ne correspond au nom donné et aux types d’arguments. Vous devez ajouter des conversions explicites de type. in query:
select count(distinct(gp.wf_p_id)) from egw_wf_processes gp INNER JOIN egw_wf_activities ga ON gp.wf_p_id=ga.wf_p_id INNER JOIN egw_wf_activity_roles gar ON gar.wf_activity_id=ga.wf_activity_id INNER JOIN egw_wf_roles gr ON gr.wf_role_id=gar.wf_role_id INNER JOIN egw_wf_user_roles gur ON gur.wf_role_id=gr.wf_role_id where gp.wf_is_active=? and ((gur.wf_user=? and gur.wf_account_type=‘u’) or (gur.wf_user in (-1,-2) and gur.wf_account_type=‘g’))
in /usr/share/egroupware/workflow/inc/engine/src/common/Base.php on line 185

c’est grave docteur?

[Regis_Leroy]

On dirait que le support de cette version de postgres doit mal marcher avec
le connecteur adodb. Celui-ci n’a pas fait le remplacement des caractères
’?’ par les valeurs attendues.
Il va effectivement fallori débugger ça. Et là comme ça sans prendre pas mal
de temps c’est un peu dur.

Régis,

[DavidP-certam]

Bonjour,

Je suis reparti de zero à partir du svn.egroupware.org et non des paquets pré-packagés de Debian (des fois que)

Résultat même chose.
Je suis repassé sous Mysql5 comme moteur de SGBD et j’ai forcé la création des tables de workflow en INNODB en éditant egroupware/phpgwapi/inc/class.schema_proc.inc.php et rajoutant .’ ENGINE=INNODB ’ juste après la définition du charset.

les tables sont effectivement créées en InnoDB, l’utilisateur egroupware peut locker/délocker les tables via le client mysql mais j’obtiens toujours l’erreur sync: Echec de l’obtention d’un verrou sur la table instances.

bref je tourne en rond

[DavidP-certam]

J’avance doucement:

la fonction qui me pose problème est la fonction sync() du fichier workflow/inc/engine/src/API/instance.php, plus particulièrement cette partie là (ligne 224-228):

if (!($this->db->RowLock(GALAXIA_TABLE_PREFIX.'instances', $where)))
{
  $this->error[] = 'sync: '.tra('failed to obtain lock on %1 table', 'instances');
  $this->db->FailTrans();
}

les paramètres passés à la fonction RowLock m’ont l’air correct:
GALAXIA_TABLE_PREFIX.‘instances’ = egw_wf_instances
$where = wf_instance_id=23

Je cherche maintenant le prototype de la fonction RowLock() afin de déterminer la requête SQL passée au SGBD pour l’exécuter directement via le client.

//Si je passe outre la condition VRAI de la boucle if, l’instance est activée et je peux sélectionner l’activité suivante (approve loan) qui génère des messages d’erreurs.

La fonction RowLock appelée est celle de phpgwapi/inc/adodb/adodb.inc.php
son prototype est
function RowLock($table,$where)
{
return false;
}

donc c’est normal que le lock ne fonctionne pas

Si je remplace le prototype de fonction Rowlock() par celui de phpgwapi/inc/adodb/drivers/adodb-mysqlt.inc.php, le processus fonctionne.

Pourquoi ce n’est pas adodb-mysqltqui est appelé?

[DavidP-certam]

Suite et fin de mes pérégrinations,

l’inclusion du fichier adodb-*.inc.php s’effectue via phpgwapi/inc/class.egw_db.inc.php suivant le db_type configuré dans header.inc.php

En modifiant manuellement le db_type de mysql à mysqlt, tout fonctionne correctement (enfin au moins le processus exemple).

Comme j’ai l’impression que ça ne doit pas être aussi simple que cela, ce réglage global de db_type ne va-t-il pas impacter les autres applications egroupware?
Si oui, est-il possible de redéfinir le db_type uniquement pour l’application workflow?