Voici une histoire générique pour un problème qui m'intéresse:
Un site Web sécurisé pour la société ACME a un
tableau de milliers de commandes de widgets dans un état "initial" qui doivent être traitées en ligne.
Des dizaines d'employés de la société ACME accéderont au site Web en même temps pour saisir les commandes de widgets et les traiter. En tant que tel, une fois qu'une personne saisit un ordre de travail, elle est la seule personne qui peut exécuter l'ordre "extrait".
Bien qu'ils aient extrait l'ordre des widgets, ils peuvent modifier le statut de l'ordre, auquel cas l'ordre des widgets passe à un nouveau statut en dehors de la file d'attente "initiale", ou ils peuvent laisser l'ordre ensemble (pour une raison quelconque) à obtenir la prochaine commande disponible, ou s'ils restent sur la page trop longtemps, leur session utilisateur peut expirer avec leur article toujours extrait, mais rien d'autre n'a changé.
Du point de vue d'un utilisateur parcourant la file d'attente des éléments, quelles fonctionnalités peuvent être ajoutées pour rendre ce processus de flux de travail aussi convivial que possible?
Par exemple: que feriez-vous dans le cas où l'utilisateur a extrait un élément et que sa session expire? Doivent-ils être contraints de travailler sur cet élément ensuite? Comment passeriez-vous d'un ordre extrait à l'autre: leur donneriez-vous des filtres pour découper leurs options de compartiments à récupérer par la suite? etc...
Tout pointeur vers des ressources sur ce sujet serait utile, car ma recherche sur ce point n'a pas donné de résultats significatifs.
Mes suggestions:
Délégué lots à un nombre limité d'utilisateurs (groupe) par lot. Il s'agit de réduire le risque de collisions lorsqu'un utilisateur "prend" un article.
Lorsque l'utilisateur prend un élément, vérifiez auprès de la base de données et, si disponible, définissez l'état dans la base de données pour cet utilisateur avec un horodatage. Si non disponible, voir le point de collision.
Vérifiez occasionnellement les temps morts - si aucune activité sur un élément pendant x minutes ne le déverrouille. Ce délai doit être raisonnable pour éviter de déverrouiller accidentellement un élément en cours d'utilisation même lorsqu'un délai de session s'est produit. Les délais d'expiration de session ne devraient pas avoir d'importance, mais pour les autres délais d'expiration, reprenez automatiquement l'élément si possible, ou informez l'utilisateur qu'en raison du délai d'expiration, il a été transféré vers un nouvel élément.
Lorsqu'un lot est terminé, affectez un nouveau lot au groupe
Lorsque l'utilisateur passe à l'élément suivant, déverrouille automatiquement l'élément précédent (les utilisateurs oublient de le déverrouiller, faites-le automatiquement).
En cas de collision (avec de nombreux utilisateurs, cela est probable), transférez l'utilisateur vers l'élément suivant et montrez à l'utilisateur que celui qu'il a sélectionné a été pris et qu'un nouvel élément lui a été attribué.
Les éléments dont les statuts nécessitent une nouvelle mise en file d'attente sont simplement transférés vers un nouveau lot.
Les lots sont créés en arrière-plan à tout moment. Au lieu de créer un que avec tous les éléments, créez un repère avec des lots.
En utilisant l'approche par lots, vous pouvez réduire le risque de collisions, mais également regrouper des éléments similaires pour améliorer le rythme de traitement. Vous pouvez également créer des lots sur un certain nombre d'autres facteurs selon le scénario, y compris l'attribution d'articles dans un lot en fonction de la provenance de l'utilisateur, de la société, des catégories, du statut et de ce que vous avez d'autre.
Mes 2 cents.