Appli web - interaction entre différents utilisateurs

Version imprimable

30/07/2008, 14h03
xufux

Appli web - interaction entre différents utilisateurs
Bonjour,

je suis en train de concevoir une application web qui sera bien sur utilisée par plusieurs personnes simultanément.

chacun pouvant afficher les mêmes données, je veux que ces données soient rafraichies sur chacun des utilisateurs pour eviter plusieurs traitements de la meme donnée.

Avez-vous deja rencontré ce problème?
Comment vous en etes vous sortis sans trop galérer ?

technologies serveur: PHP, MySQL
technologies clients: AJAX

--------------------------------------------------------------------
pour illustrer tout ca, voici en gros ce que fait mon appli:
(la solution que j'envisage est tout en bas)
1. afficher une liste de client non traités
2. appel d'un client
3. si appel about -> traitement fiche client -> retour à la liste (- client traité)
4. sinon on passe a la ligne suivante (sans traitement de la fiche client)
Seulement voila le problème:
si 2 utilisateurs affichent une meme liste, il ne faut pas que l'utilisateur U2 appelle un client qui déjà été appelé par U1.

-> il faut donc mettre a jour la recherche U2 (et u3 et u4, ....) lorsque U1 effectue un traitement.

Voici la solution que j'ai envisagée:

utilisation du javascript avec un settimeout() pour relancer la requete de la recherche.

OK c'est lourd surtout si le delai est court ! (meme si on utilise ajax, pour recharcher uniquement la liste)

pour eviter de recharger toutes les données (plusieurs centaines de clients)

on peut faire ceci:
lorsqu'un client modifie un client, une table ClientsTraitésRecemment qui contient la liste des clients qu'un utilisateur a modifié est mise a jour.
périodiquement, cette table est consultée et on cherche si ses clients de sa liste actuelle sont dedans. si oui, on met a jour la recherche.

(quel courage d'être arrivé jusqu'ici !!!)

Que pensez-vous de mon approche ?
30/07/2008, 14h50
wiztricks
A l'use case:
1. afficher une liste de client non traités
2. appel d'un client
3. si appel about -> traitement fiche client -> retour à la liste (- client traité)
4. sinon on passe a la ligne suivante (sans traitement de la fiche client)
Je préfèrerais:
1. afficher la liste des clients à appeler,
2. sélectionner un client,
3. appeler le client : il passe "en cours de traitement"
4. si l'appel aboutit, le client n'est plus à appeler
Questions:
- combien dure la séquence appeler le client, l'appel aboutit, traitement de...
- pourquoi ne pas automatiser l'appel du client et passer le client au bout du fil à un interlocuteur libre?
-W
30/07/2008, 15h04
xufux
le use case est imposé par le client: il ne veut pas ouvrir la fiche d'un client tant que ce client ne lui a pas dit qu'il était dispo pour discuter !
(en 1ere approche, j'avais proposé la même séquence d'utilisation que toi au client)

la sequence appeler un client dure ... un certain temps:
- qq secondes si personne ne décroche
- qq disaines de sec si qqun décroche mais que personne pas dispo
- jusqu'a plusieurs minutes si la personne est disponible.
c'est seulement dans le 3eme cas que la fiche client est ouverte.

je n'ai pas compris ta question:

Citation:

pourquoi ne pas automatiser l'appel du client et passer le client au bout du fil à un interlocuteur libre?

c'est une appli web qui n'accede à aucune ressource du poste de travail (standard telephonique, etc).
les utilisateurs peuvent se trouver sur des sites différents
30/07/2008, 15h19
wiztricks
Citation:

a sequence appeler un client dure ... un certain temps:

* qq secondes si personne ne décroche
* qq disaines de sec si qqun décroche mais que personne pas dispo
* jusqu'a plusieurs minutes si la personne est disponible.

c'est seulement dans le 3eme cas que la fiche client est ouverte.

Certes mais si l'évènement "j'essaie d'appeler le client" n'est pas signalé comment éviter que plusieurs essaient pour rien ou trouver la ligne occupée.
Par ailleurs, si un client ne répond pas il n'est peut être pas utile de le rappeler dans les 10 minutes.

Je dirais que:
1. Il n'est pas utile d'avoir l'ensemble de la liste des clients à appeler sur chaque poste: seulement ceux que l'utilisateur doit/peut appeler dans l'heure (ou plus) à venir.
2. En fonction du retour des appels ou avec une certaine fréquence on met à jour la base de donnée centrale pour signaler le résultat des appels.
3. Cela met à jour la liste des clients à appeler et permet de raffraichir la liste personnelle de chaque utilisateur.
En segmentant la liste des clients à appeler par utilisateurs, on évite les soucis de mise à jour de la liste globale et du rafraichissment du poste utilisateur.
- W
30/07/2008, 15h48
xufux

Citation:

Par ailleurs, si un client ne répond pas il n'est peut être pas utile de le rappeler dans les 10 minutes.

et bien si justement ! ce sont des bourrins ! :king: ils peuvent essayer d'appeler un client plus de 10fois sur une journée !!! (non mais vraiment les commerciaux sont TROP TROP agressifs)

Citation:

Il n'est pas utile d'avoir l'ensemble de la liste des clients à appeler sur chaque poste: seulement ceux que l'utilisateur doit/peut appeler dans l'heure (ou plus) à venir.

-> chaque utilisateur DOIT pouvoir appeler n'importe lequel des clients. chaque utilisateur appele un peu "au feeling" tel ou tel client (ils peuvent trier la liste de resultats a la façon d'un excel pour appeler dans l'ordre d'un critère précis qui interesse l'utilisateur)

cela dit, je pense qu'on s'éloigne un peu du sujet: je ne peux pas forcer un use case (j'ai deja fait du forcing la dessus, le client ne lache rien ! lol)

je suis à la recherche de méthodes me permettant de forcer la mise a jour des données affichées sur un client lorsque ces memes données sont modifiées par un autre client.
Helas, je suis d'accord avec wiztricks, il serrait tellement plus simple d'empecher la modification de la meme donnée par plusieurs clients (lors de l'ouverture du fichier client par exemple)
30/07/2008, 16h48
wiztricks
Je ne sais pas combien de temps vous avez pour faire ce projet mais au plus c'est compliqué et au plus ce sera long et difficile à mettre au point.

Il ne vous reste qu'à
1. avoir une copie de la base de données client sur chaque poste (risque de sécurité évident),
2. maintenir cette base de données à jour (toutes les nuits? de façon incrémentale?)
Propager à l'ensemble des utilisateurs le status des clients appelés. On peut éviter que cette liste n'augmente au fur et à mesure en faisant des mises à jour incrémentales.
Dans ce cas comment s'assurer qu'une mise à jour n'a pas été ratée?

On peut faire les mises à jour de la base locale:
- a chaque mise à jour par l'utilisateur (j'ai appelé le client X)
- toutes les X secondes, quelle est la valeur idéale de X pour que les informations restent "à jour"?
- à la demande de l'utilisateur?
Les autres aspects facheux (pour l'instant) de cette solution sont:
- Suivant la taille de la base, il sera peut être nécessaire d'équiper les postes clients d'un SGDB pour maintenir ces données en local. La gestion du poste client n'est donc plus "light".
- Le serveur central devient un point faible: panne = impossibilité de savoir quels clients ont déjà été appelés... (dans le cas, liste dédiée à chaque utilisateurs, pas besoin de communiquer avec le serveur central avant la fin de la journée...)
- W
30/07/2008, 17h42
xufux

OULA OULA OULA ! mais pourquoi se compliquer la vie ? j'ai déjà fait une proposition de solution dans mon post initial.

(d'ailleurs, en quoi une copie locale de la base, va empecher 2 utilisteurs d'acceder a la meme ressource ? On peut aussi mettre un google gears...)

Je cherche juste d'autres idées simples ou des améliorations de ma proposition de base pour avoir plusieurs pistes de départ.

As-tu bien saisi le concept d'application web ? Ca tourne dans un navigateur (IE, Firefox, etc).
ce n'est pas une appli client (en C# par exemple) qui maintient une connexion au serveur et qui réagit a des evénements envoyés par le serveur .

le serveur ne peut pas envoyer d'info au client. C'est au client d'aller se renseigner sur la validité des données.
30/07/2008, 19h21
wiztricks
Je vous cite:

Citation:

pour eviter de recharger toutes les données (plusieurs centaines de clients)
1. on a chargé ces informations au moins une fois,
2. vous n'avez pas envie de les recharger plusieurs fois
3. néanmoins, il se peut que la liste des clients à appeler soit mise à jour
Posez ces informations comme vous voulez sur le poste client (dans le browser par exemple), il va quand même falloir les gérer.
Note: Si le boulot des utilisateurs est d'appeler des clients, avec un taux de succès de 50%, en une heure ils auront traité 3 réponses clients + 20 non réponses.

Pour un utilisateur qui bosse 10 heures, ça fait une liste de 230 clients
x5 jours = 1000 clients en base.
Multipliez par le nombre d'utilisateurs et "à priori" ca fait une base client plutôt importante.

Je vous cite encore:

Citation:

on peut faire ceci:
lorsqu'un client modifie un client, une table ClientsTraitésRecemment qui contient la liste des clients qu'un utilisateur a modifié est mise a jour.
périodiquement, cette table est consultée et on cherche si ses clients de sa liste actuelle sont dedans. si oui, on met a jour la recherche.

Outre que nous allons avoir autant de tables "ClientsTraitésRecemment" que d'utilisateurs (une seule suffirait peut être), vous allez utiliser ces informations pour mettre à jour la longue liste précédente.
Est ce que cette liste sera incrémentale et comment allez vous traiter les loupés?
Dans le cas contraire quand allez vous la remettre à zero?

Note: en reprenant les calculs ci dessus, 1 heure = 3 réponses * 10 heures = liste de 30 clients à mettre à jours. Si vous avez 10 utilisateurs, à la fin de la journée votre liste sera de 300 clients.

Après que vous réalisiez cela avec AJAX, client / serveur ou avec des pigeons voyageurs, il y aura des informations sur le poste client qu'il faudra mettre à jour... et donc:
1. un état initial
2. des flux de mises à jour
3. des procédures de reprises pour resynchroniser cela,
tant que vous n'aurez pas clarifié cela, difficile de dire que çà va marcher.
- W