Conditions préexistantes: Modèles SharePoint Alert à la rescousse (?)

Un de mes clients travaille avec un fournisseur précédent à construire une application RH petite mais utile pour l'entreprise. Que l'entrepreneur a utilisé SharePoint Designer pour implémenter la partie de flux de travail de la solution. C'est un peu un mess. Par exemple, Il y a neuf des workflows SPD à l'appui d'un processus de workflow logique unique et jusqu'à cinq d'entre eux peut-être se déclencher simultanément à un moment donné, étant donné les bonnes conditions. It’s not easy to debug 🙂

Mon client a un certain nombre d'exigences toujours exceptionnelles, dont doit généralement fournir plus de contexte lorsque le système envoie des alertes par e-mail – aussi bien dans le courriel lui-même, mais aussi les formulaires de tâche associée. Comme le SPD sais les implémenteurs de flux de travail, l'action du SPD « collecte de données de l'utilisateur » crée en fait une tâche avec un type de contenu personnalisé. Quand nous utilisons cette action, Nous n'avons pas de spécifier une grande partie. Nous pouvons demander certaines valeurs (e.g. « approuver » ou « refuser ») et on peut spécifier une valeur codée en dur dans le titre et la description. C'est tout.

Exigence de mon client est que double:

Lorsque SharePoint envoie un courriel sur une affectation de tâche, comprend beaucoup d'informations sur la tâche dans le corps du Courriel.
Plus important encore, de loin – Lorsque l'utilisateur clique sur le lien dans le courriel de tâche, le formulaire de tâche devrait avoir toutes les informations que l'approbateur a besoin pour faire son approuver ou refuser la décision. Tout de suite, le gestionnaire a besoin de cliquer sur le lien de l'élément lui-même de creuser dans les détails sous-jacents et personne n'aime que. Vous devez cliquer dans l'email. Ensuite, vous devrez cliquer sur un lien peu obscur sur l'élément de tâche. Vous pouvez alors consulter les données sous-jacentes (un InfoPath constituent dans ce cas). Puis vous cliquez sur dos/dos, etc.. Tout le monde déteste.

J'ai hérité de cette solution technique quelque peu désordonnée et je veux changer la manière la moins intrusive possible.

L'approche que je prend en ce moment est de créer un modèle d'alerte personnalisé. Vous pouvez lire à ce sujet ici. Le flux fonctionne comme ceci:

SPD workflow s'exécute.
À un certain moment, Il assigne une tâche à un gestionnaire.
Système SharePoint envoie automatiquement une alerte à ce gestionnaire de. Cela ne fait pas partie des flux de travail SPD mais plutôt « que SharePoint fait. » (Le service du minuteur SharePoint, Je crois que).
Un gestionnaire d'alert personnalisé est invoqué en faveur de la procédure d'alerte standard (suivant les règles de la magie comme décrit ci-dessus référence article).
Lorsque mon gestionnaire d'alerte personnalisé s'exécute, il génère une belle email. Plus important encore, Depuis il a la tâche dans la main, Il décore aussi la tâche réelle avec toutes les informations de contexte nécessaires pour satisfaire à l'exigence de l'entreprise.
L'utilisateur reçoit le message et c'est plein d'informations de contexte utiles.
Utilisateur clique sur le lien de travail et de la tâche elle-même est pleine d'informations de contexte utiles.
Tout le monde va Accueil de melon d'eau et de crème glacée.

J'ai fait un rapide POC et il fonctionne bien dans un environnement de laboratoire. Je reçois mon alerte e-mail personnalisée comme prévu. J'ai également mettre à jour la description de la tâche et le titre lui-même.

Le bit seulement tricky, pour l'instant, est d'éviter une situation où l'alerte met à jour l'élément, déclencher une autre alerte. Cela ne m'inquiète pas.

Semble prometteuse si far…

La grande chose au sujet de ceci est que je ne dois pas muck sur avec tous les workflows existants de SPD. Ils sont parfaitement inconscients qu'un gestionnaire d'alerte est"EGAUT RUNNIN IN DA BAKGROUND, LISTE DE LA TÂCHE DE TEH DECORATIN WIF MOAR CONTEXTE”.

</fin>

S'abonner à mon blog.