Esta entrada de blog é mais um "no Reino do possível" entrada vs. informação concreta.

Nós temos um projeto técnico que chama por nós criar um site em um conjunto de sites através de um processo de fluxo de trabalho manualmente lançado. Basicamente, usuários inserir dados em um "novo cliente" lista personalizada e, em seguida, quando eles têm terminado e validado o processo de entrada de dados, Precisamos criar um site para que o cliente.

Eu sou um grande fã de fluxo de trabalho declarativo, bem como um programador de fluxo de trabalho do studio visual fraco, Então eu queria cumprir a exigência usando o SharePoint Designer.

Eu pretendo escrever sobre isso mais detalhadamente (e esperemos que apresentar para um grupo de usuários ou duas no ano que vem), Mas aqui está a solução global:

• Criar uma ação personalizada que se integra com o SPD.
• A ação personalizada permite SPD para invocar um serviço web e passá-lo uma seqüência de caracteres de XML.
• Serviço Web localiza a linha na lista personalizada e cria um novo site de acordo com os dados para esse novo cliente usando uma definição de site personalizada.
• Serviço da Web, em seguida, atualiza a lista personalizada com algumas informações, como um link para o novo site.

Consideramos outras abordagens, como manipuladores de eventos e fluxo de trabalho do visual studio com base. A abordagem do SPD dá nossos usuários finais um pouco mais controle sobre o processo de. Concedida, Há um monte de código c# nesta solução, Mas ele é encapsulado dentro de um fluxo de trabalho declarativo, Então pegamos alguns dos benefícios do fluxo de trabalho declarativo enquanto enganchando para o serviço de criação de site.

All we need now is an easy tool to automatically migrate SPD workflows around as easily as we can for visual studio workflows and we’ll really be cooking with gas 🙂 I understand that some folk are out there working on this problem and I hope they have some good success with it soon.

</fim>

Subscreva ao meu blog.

Eu fui brincar com ações personalizadas para SharePoint Designer há algum tempo (Consulte aqui para algumas coisas detalhadas, Se isso lhe interessa.).

No meu projeto atual, Precisamos fazer um trabalho bastante pesado e queremos usar o fluxo de trabalho declarativo SPD para gerenciar o processo de negócios associados.

Longa história curta, Isso é inteiramente possível.. Eu estendi o meu projeto do Codeplex para invocar um serviço de auxiliar"" e agora podemos invocar um serviço web diretamente a partir de um fluxo de trabalho do SPD.

Aqui está a assinatura:

 público Cadeia de caracteres Despachante(
        GUID WebID, // Passou pelo ambiente de tempo de execução
        GUID SiteID, // Passou pelo ambiente de tempo de execução
        Cadeia de caracteres ListID, // Passado pelo RTE (Não sei por que isso é uma seqüência de caracteres, Não um GUID.)
        int ListItemID, // Passado pelo RTE.
        Cadeia de caracteres XmlMessage) // Passado pelo usuário conforme declarado no SPD.

Este aproveita o facto de conseguirmos a informação importante de fluxo de trabalho, como o site, ID da lista, etc. Isto está bem documentado em vários lugares para aqueles interessados na criação de suas próprias ações personalizadas. A idéia é extrair a cadeia de caracteres XML conforme fornecido pelo usuário para despachar um processo adequado. Coisas divertidas!

Infelizmente, Esta é obviamente uma passagem só de ida para baixo para "Loosey Goosey." anti-pattern terra, but it’s better than hitting a brick wall 🙂

Se você fizer isso, mesmo sabendo que é um antipadrão é um antipadrão?

Espero resolver isto dentro Codeplex em um futuro próximo. Se você está interessado em mim fazê-lo, me dê um puxão (Email ou deixe um comentário) and I’ll be that more enthusiastic about doing it 🙂

</fim>

Subscreva ao meu blog.

Eu estou trabalhando em um projeto que usa cinco diferentes fluxos de trabalho do SharePoint Designer para lidar com algumas aprovações de documento. SPD fornece os "coletar dados de um usuário" ação para que nós pode solicitar ao usuário para diferentes bits de informação, como se eles aprovarem isso, alguns comentários e talvez perguntar o que eles tinham para jantar naquela noite.

As formas são perfeitamente funcionais. Eles estão ligados a uma lista de tarefas como um tipo de conteúdo. Eles são 100% gerados pelo sistema. Esta é sua força e fraqueza. Se podemos viver com o formulário padrão, Então estamos prontos para ir. No entanto, Não temos mais controle sobre como o SPD cria o formulário. Se não gostamos que o comportamento padrão, Precisamos de recorrer a vários truques para contorná-la (por exemplo, definindo a prioridade em uma tarefa).

Eu precisava para fornecer um link sobre estes formulários de tarefa que abriu as propriedades de exibição (DispForm.asxp) do "item relacionado" em uma nova janela. Isso fornece acesso de um clique para os meta dados do item relacionado. Isto é o que quero dizer:

Graças a Deus, Podemos fazer isso e não é muito difícil. Em termos gerais, fogo até o SPD, Navegue até o diretório que abriga os arquivos de fluxo de trabalho e abra o arquivo ASPX que deseja modificar. Estas são instruções de transformação XSL só clássicas, e se você já com mucked ItemStyle, pesquisa ou outros cenários XSL, Isto vai ser fácil para você. Na verdade, Eu achei a ser geralmente mais fácil, uma vez que o formulário gerado é um pouco mais fácil de seguir em comparação com uma web part de pesquisa principais resultados (ou o um pesadelo CWQP).

É claro, Há uma grande armadilha. Editor de fluxo de trabalho do SPD espera total controle sobre esse arquivo. Se você modificá-lo, SPD alegremente substituirá suas dão alterações o direito conjunto de circunstâncias. Eu fiz dois testes rápidos para ver o quão ruim isso pode ficar. Ambos pressupõem que você tenha criado um fluxo de trabalho SPD válido que usa os "coletar dados de um usuário" etapa.

Teste 1:

• Modificar o arquivo ASPX com a mão.
• Testá-lo (Verifique se as alterações foram salvas corretamente e não quebrou nada).
• Abrir o fluxo de trabalho e adicionar uma ação independente (como "log de histórico").
• Salvar o fluxo de trabalho.

Resultado: Neste caso, SPD não re-criar o formulário.

Teste 2:

• Faça o mesmo que #1 exceto diretamente modificar os "coletar dados de um usuário" ação.

Resultado: Este re-cria a forma do zero, excesso, escrevendo suas alterações.

Notas finais:

• Pelo menos duas ações de SPD criar formulários como este: "Coletar dados de um usuário" e "Atribuir a ver Item". Ambas estas ações’ formulários podem ser modificados manualmente.
• Eu era capaz de gerar o meu link para DispForm. aspx porque, Neste caso, o item de relacionar sempre tem seu ID incorporado no URL do item relacionado. Eu era capaz de extraí-lo e construir uma <a href> com base nele para fornecer o recurso de acesso de dados de meta de um clique. É improvável que seu URL segue essa regra. Pode haver outras maneiras de obter o ID do item relacionado, mas não tive que atravessar aquela ponte, Então eu não sei se fica para o outro lado do abismo.
• Eu não investigo, Mas eu não ficaria surpreso se houver algum tipo de arquivo de modelo na 12 colméia que eu poderia modificar para afetar como SPD gera os formulários padrão (assim como podemos modificar modelos de alerta).

</fim>

Subscreva ao meu blog!

Eu tenho um cenário de negócios como este:

• Um usuário carregue um documento em uma biblioteca de documentos.
• Ela seleciona um tipo de conteúdo e insere meta dados, conforme necessário. Um dos campos de dados de meta é uma bandeira, "Urgente".
• Isso desencadeia um fluxo de trabalho do SharePoint Designer que, entre outras coisas, usa o "coletar dados de um usuário" ação.

"Coletar dados de um usuário" Cria um item em uma lista de tarefa solicitando aprovação para esse documento.

Eu precisava criar uma exibição de lista de tarefas que mostrou os pedidos urgentes para aprovação.

Solução: Colocar a palavra "urgente:" para o título dessas tarefas.

Eu teria preferido especificar o campo de prioridade diretamente. No entanto, Eu era incapaz de fazer isso por várias razões:

1. A ação de coletar dados não fornece um mecanismo para atualizar qualquer campo que não seja o título (e esses campos adicionais, para o qual você deseja coletar dados).
2. O "atribuir ao item" ação tem o mesmo problema.
3. É possível inserir um item em uma lista (ou seja. inserir um item na lista de tarefas diretamente) Mas isto não é uma ação bloqueio. Isso significa que o fluxo de trabalho não vai esperar para que o usuário completar essa tarefa.

Eu considerei algumas abordagens antes (Graças a Deus) perceber que nós pudéssemos colocar "urgente" no título.

1. Iniciar um fluxo de trabalho na lista de tarefas em si, de modo que quando uma nova tarefa é criada, de alguma forma de cruzar referências de volta para o documento que começou o primeiro fluxo de trabalho, Puxe para fora o valor de sinalizador urgente e atualizar a prioridade conforme necessário.
2. Fazer algo semelhante com um receptor de eventos. Criar diante da tarefa, Localize o documento associado e prioridade de atualização conforme necessário.
3. Use o "Criar item de lista" ação em conjunto com a "espera para mudança de campo" ação e um receptor de eventos. Se podemos criar um item de lista, podemos especificar todos os campos que queremos. Usar um receptor de eventos para atualizar o item original quando o usuário conclui a tarefa e a "espera para mudança de campo" condição da ação seria atendida e o fluxo de trabalho prosseguiria. (Por alguma razão, Eu tinha mais ou menos estabeleceu-se nesta abordagem antes de decidir sabiamente se afastar por um tempo).

Há um inconveniente a minha solução (Além do fato óbvio de que apenas o texto do título indica urgência). Desde "coletar feedback" Só aceita nomes de título codificado, Eu preciso usar duas ações de gabarito coletar diferentes, cuja única diferença é que esse título difícil codificado.

Mas, pelo menos, há uma solução que não exige receptores de eventos ou ações personalizadas do SPD.

Se alguém tiver resolvido isso de forma mais inteligente, por favor me avise.

</fim>

ATUALIZAÇÃO: Madjur Ahuja assinala este link de um discussão de grupo de notícias: http://msdn2.microsoft.com/en-us/library/ms772417.aspx. É bastante definitiva.

===

Muitas vezes queremos Inserir hiperlinks para os formulários do InfoPath em e-mails enviados de fluxos de trabalho do SharePoint Designer. Quando os usuários receber esses e-mails, eles podem clicar no link do e-mail e ir diretamente ao formulário do InfoPath.

Esta construção de URL de monstro funciona para mim:

http://server/sites/departments/Technical Services/InformationTechnology/HelpDesk/_layouts/FormServer.aspx?XmlLocation=/sites/departments/Technical Services/InformationTechnology/HelpDesk/REC REM RED Forms/REC2007-12-18T11_33_48.XML&Fonte = http % 3A % 2F % 2Fserver % 2Ecorp % 2Edomain % 2Ecom % 2Fsites % 2Fdepartments % 2FTechnical % 2520Services % 2FInformationTechnology % 2FHelpDesk % 2FREC % 2520REM % 2520RED % 2520Forms % 2FForms % 2FAllItems % 2Easpx&DefaultItemOpen = 1

Substitua o texto em negrito vermelho com o nome do formulário, como mostrado na imagem abaixo:

Note que há um monte de caminho codificadas em URL, assim como um componente de URL-codificado. Se isto é muito difícil de traduzir para sua situação específica, tentar transformar-se em alertas para a biblioteca de forma. Postar um formulário e quando você receber o e-mail, Ver a fonte do e-mail e você vai ver tudo o que você precisa incluir.

Leitores astutos podem notar que o corpo de e-mail acima também mostra um link que acessa diretamente a tarefa através de uma exibição filtrada. Eu pretendo explicar isso mais detalhadamente em um post futuro.

</fim>

Implementei um fluxo de trabalho usando o SharePoint Designer em um site que é principalmente somente leitura para usuários de NT_AUTHORITYAuthenticated"" (ou seja. todos os). Há uma biblioteca de formas para um formulário do InfoPath. Há uma lista de tarefas de fluxo de trabalho associado também, para que quando o fluxo de trabalho Opera, Ele pode atribuir tarefas a pessoas.

Eu quebro a permissão para a lista de biblioteca e tarefa de formulários para que qualquer usuário autenticado pode criar formulários e atualizar suas tarefas.

Testar com a minha conta de teste de baixo-privilégios.

Pode eu preencha e salve um formulário para a biblioteca? –> SIM

Pode acessar a tarefa a partir de um link de e-mail? –> SIM

Posso ver um vínculo de tarefa de fluxo de trabalho de edição –> SIM

Pode clicar no link? –> NÃO … Permissão negada.

Por que posso ver um link Editar que me nega permissão, quando clico nele? Isso é que não foi assim que tem que trabalhar…

Eu atravesso novamente a configuração de segurança, muito de perto. Fazê-lo. Considero-me apagar este post porque, obviamente, não sei nada sobre segurança.

Finalmente, Pesquisar a Internet. Acho este tópico do fórum MSDN altamente improvável: http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=1838253&SiteID=17

Os cartazes parecem sugerir que o simples ato de exportar o fluxo de trabalho para uma travessa de unidade irá corrigir um problema de segurança de musgo? Mal posso acreditar que eu digitei isso. Lembro-me do episódio de South Park sobre o 9/11 conspiração onde Stan está pedindo nossa Preznit, "Realmente?" e outra vez.

Assim, nada a perder, Eu acender SPD, botão direito do mouse sobre o fluxo de trabalho e salve-o em meu c:\ Dirigir. Isso seria o c:\ unidade no meu laptop. Estou olhando por cima do ombro o tempo todo para que ninguém vai me perguntar., "por que você está salvando esse fluxo de trabalho para seu laptop?"

Incrivelmente, Isso resolve meu problema. Eu posso editar a tarefa.

Pelo presente nomeio este ser mais bizarra solução de fluxo de trabalho de 2007.

</fim>

Muitas vezes queremos enviar um email que inclui um hiperlink para o item ou documento que disparou o fluxo de trabalho. Podemos usar "codificado URL do item atual absoluto" para esta finalidade.. No entanto, parece sempre usar http"" para o protocolo URL. Se seu site funciona em HTTPS, então não vai funcionar para você.

Tanto quanto eu sei, Não há nenhuma solução out of the caixa para este problema. Se você precisar usar HTTPS, você não fora a opção de caixa tem.

Para resolvê-lo, criar uma ação personalizada que fornece a função de substituir uma seqüência de caracteres para usar em seu fluxo de trabalho. Como alternativa, Use uma ferramenta de terceira partido como o excelente pacote aqui: http://www.codeplex.com/spdwfextensions 🙂

</fim>

Os usuários do fórum, ocasionalmente, perguntar: Por que põe o SharePoint Designer ???? em meu email em vez de um valor do campo?

Uma razão pela qual que isso acontece é porque a variável à qual você se refere é nula.

Isto pode acontecer porque você está tentando fazer referência a um campo de item atual"" Mas o usuário nunca inseriu um valor nesse campo de formulário.

<final />

Cenário: Em um fluxo de trabalho do SharePoint Designer, Você precisa determinar se um campo de data é em branco.

Problema: SPD não fornece um método direto para comparar datas para algo diferente de um encontro. Você não pode criar uma condição assim: "Se [DateField] é igual em branco".

Solução: Converter a data para uma cadeia de caracteres. Usar a comparação de seqüência de caracteres para determinar se a data estiver em branco.

Capturas de tela:

As capturas de tela a seguir mostram como fazer isso. Neste cenário, um campo em um item, "Licenças ambientais:Primeiro título de data de lembrete", é enviado e o fluxo de trabalho é acionado em resposta.

Notas:

Quando eu tentei isso, Fiquei agradavelmente surpreso ao saber que ele funciona. Eu estava preocupado que SharePoint Designer pode não permitir a atribuição de seqüência de caracteres (Variável:StringReminderDateDate) Mas permite.

Também fiquei preocupado que permitindo que ele, o valor pode ser nulo e também explodir o WF em tempo de execução ou talvez elevar a temperatura global 1/2 um grau, Mas essas preocupações eram infundadas.

</fim>

Apenas uma rápida observação que há uma diferença muito importante entre estas duas definições:

<Campo FieldBind = "InParam1" DesignerType = "StringBuilder" ID = "2" Texto = "Parâmetro de entrada # 1" />

comparação:

<Campo FieldBind = "InParam1" ID = "2" Texto = "Parâmetro de entrada # 1" />

O primeiro mostra como este em SPD:

enquanto a segunda mostra como este:

I’m not sure how helpful these screen shots are but I put in the effort to make them so you have to view them 🙂

A observação é isso: StringBuilder permite que você construa uma seqüência de caracteres (Obviamente) pela mistura de literais de cadeia de caracteres e dados de fluxo de trabalho (através do "Adicionar pesquisa" botão no canto inferior esquerdo). Quando você usar o botão Adicionar pesquisa, ele insere um símbolo no formulário"[%sinal %]". Quando o SharePoint invoca sua ação personalizada, (No meu caso o código c#), SharePoint passa o token em si, Não o valor do token. Se você usar o tipo de designer padrão (o segundo tipo), SharePoint expande o token e passa o real valor do token para sua ação.

StringBuilder = ruim, padrão tipo designer = bom.

É claro, Isso é não o que realmente quero dizer. Só não tentem passar um parâmetro para sua ação personalizada quando o designer digite = StringBuilder. Usar o tipo de designer padrão e cadeia um StringBuilder para ele na frente, se você precisar criar seqüências de caracteres complexas em seu fluxo de trabalho (que aliás é exatamente o que se faz para criar um tema dinâmico para a ação de e-mail, mas isso é um assunto para outro blog, har har).

<final />