Condições pré-existentes: Modelos de alerta do SharePoint para o resgate (?)

Um dos meus clientes trabalhou com um empreiteiro anterior para construir uma aplicação de HR pequeno, mas útil para a empresa. O empreiteiro usado SharePoint Designer para implementar a parte de fluxo de trabalho da solução. É um pouco de bagunça. Por exemplo, são nove os fluxos de trabalho do SPD para apoiar um processo de fluxo de trabalho lógico único e até cinco deles pode disparar simultaneamente em um determinado momento, dado as condições certas. It’s not easy to debug 🙂

Meu cliente tem um número de requisitos ainda pendentes, um dos quais é geralmente fornecer mais contexto quando o sistema envia alertas por e-mail – tanto o e-mail em si, bem como formas de tarefa associada. Como SPD sabem implementadores de fluxo de trabalho, a ação do SPD "coleta dados do usuário", na verdade, cria uma tarefa com um tipo de conteúdo personalizado. Quando usamos essa ação, Não podemos especificar muito. Nós pode alertar para alguns valores (EG. "aprovar" ou "negar") e podemos especificar um valor codificado no título e descrição. Isso é tudo.

Exigência de meu cliente é que duas vezes:

Quando o SharePoint envia um email sobre uma atribuição de tarefa, incluir um monte de informações sobre a tarefa do corpo do e-mail.
Mais importante, de longe – Quando o usuário clica no link no e-mail de tarefa, o formulário de tarefas deve ter todas as informações que o aprovador precisa para fazer sua aprovar ou negar a decisão. Agora, o gerente precisa clicar sobre o link de item próprio para detalhar os detalhes subjacentes e ninguém gosta disso. Você tem que clicar no e-mail. Então você precisa clicar em um link ou menos obscuro sobre o item de tarefa. Então você pode olhar para os dados subjacentes (um InfoPath formar neste caso). Você clique em costas /, etc. Todo mundo odeia ele.

Eu herdei esta solução técnica um pouco confusa e quero fazer alterações da forma menos intrusiva possível.

A abordagem que eu estou levando agora é criar um modelo personalizado de alerta. Você pode ler sobre isso aqui. O fluxo funciona assim:

Fluxo de trabalho do SPD é executado.
Em algum momento, Ele atribui uma tarefa para um gerente.
SharePoint sistema automaticamente envia um alerta para que o Gerenciador de. Isto não é parte do fluxo de trabalho do SPD, mas prefiro "o SharePoint que." (O serviço de timer do SharePoint, Eu acredito).
Um manipulador personalizado de alerta é invocado em favor do processo de alerta padrão (seguir regras mágicas conforme descrito no exemplo acima referenciado artigo).
Quando o meu manipulador de alerta personalizado é executado, Ele gera um e-mail lindo. Mais importante, uma vez que tem a tarefa na mão, Ele também decora a tarefa real com todas as informações de contexto necessárias para cumprir a exigência do negócio.
O usuário recebe o e-mail e está cheio de informações úteis de contexto.
Usuário clica no link de tarefa e a tarefa em si é cheia de informações úteis de contexto.
Todos vão para casa para ter melancia e sorvete.

Fiz um rápida POC e funciona bem em um ambiente de laboratório. Recebo o meu alerta de e-mail personalizado como esperado. Eu também vou atualizar a descrição da tarefa e o título em si.

O bit apenas complicado, até agora, é para evitar uma situação onde o alerta atualiza o item, desencadear outro alerta. Isso não me preocupa..

Até agora, parece promissor...

A grande coisa sobre isso é que não precisa ficar rindo com qualquer um dos fluxos de trabalho existentes do SPD. Eles são alegremente inconscientes de que um manipulador de alerta é"IIZ RUNNIN EM BAKGROUND DA, DECORATIN TEH TAREFA LISTA WIF MOAR CONTEXTO”.

</fim>

Subscreva ao meu blog.