Planejar a criação de fluxos de trabalho (SharePoint Server 2010)

 

Aplica-se a: SharePoint Foundation 2010, SharePoint Server 2010

Tópico modificado em: 2016-11-30

O que é um fluxo de trabalho? Fundamentalmente, ele consiste em duas coisas: os formulários que um fluxo de trabalho usa para interagir com seus usuários e a lógica que define o comportamento desse fluxo de trabalho. Entender como os fluxos de trabalho são criados exige um certo conhecimento sobre esses dois conceitos.

Por se comunicar com os usuários por meio de um navegador da Web, um fluxo de trabalho depende do ASP.NET para exibir seus formulários. Da mesma forma, esses formulários são definidos como páginas .aspx. Um fluxo de trabalho pode exibir seus próprios formulários em quatro pontos do seu ciclo de vida:

• Associação: quando um administrador associa um modelo de fluxo de trabalho a uma determinada lista ou biblioteca de documentos, ele pode definir as opções que aplicará a cada instância do fluxo de trabalho criada a partir dessa associação. Se um autor de fluxo de trabalho decidir permitir isso, ele deverá fornecer um formulário que permita ao administrador especificar essas informações.

• Iniciação: o iniciador de um fluxo de trabalho pode ter permissão para especificar opções quando iniciar uma instância de execução. No cenário de aprovação descrito, por exemplo, as opções incluíram a especificação da lista de participantes do fluxo de trabalho e a definição do tempo de cada um deles para concluir sua tarefa. Se um fluxo de trabalho permitir isso, seu autor deverá fornecer um formulário para permitir que o iniciador defina essas opções.

• Conclusão da Tarefa: a instância de fluxo de trabalho em execução deve exibir um formulário aos participantes do fluxo de trabalho para permitir que eles concluam sua tarefa. Esse formulário permitiu aos aprovadores do cenário anterior comentar o documento e indicar sua aprovação ou rejeição.

• Modificação: o criador de um fluxo de trabalho pode permitir que ele seja modificado durante a execução. Por exemplo, um fluxo de trabalho pode permitir a adição de novos participantes depois do início da execução ou a prorrogação da data de conclusão das tarefas. Se essa opção for usada, o fluxo de trabalho deverá exibir um formulário nesse ponto para permitir que um participante especifique quais alterações devem ser feitas.

Os fluxos de trabalho produzidos com o Microsoft SharePoint Server 2010 podem usar formulários criados com o InfoPath. A lógica de um fluxo de trabalho é sempre definida como um grupo de atividades, como acontece com qualquer fluxo de trabalho baseado no Windows Workflow Foundation (WF). Para especificar a lógica e os formulários para um fluxo de trabalho, a Microsoft oferece duas ferramentas diferentes, cada uma delas com um público-alvo diferente. Os desenvolvedores de software podem usar o recurso Designer de Fluxo de Trabalho do Windows Workflow Foundation. Essa ferramenta é executada dentro do Visual Studio 2010 Professional Edition e oferece uma ambiente gráfico para organizar as atividades nos fluxos de trabalho. Operadores de informações, um grupo menos técnico, podem usar o Microsoft SharePoint Designer 2010 para criar fluxos de trabalho sem gravar códigos. As duas seções a seguir analisam como criar fluxos de trabalho com cada uma destas ferramentas.

Criando fluxos de trabalho com o Visual Studio 2010 e o Designer de Fluxo de Trabalho do WF

Os fluxos de trabalho que usam o SharePoint Server podem empregar os formulários de fluxo de trabalho do Microsoft InfoPath 2010 em vez de apenas formulários .aspx. Para criar esses formulários, um autor de fluxo de trabalho usa o Microsoft InfoPath. Essa ferramenta fornece um editor gráfico que permite ao autor definir o conteúdo do formulário. Os desenvolvedores que preferem trabalhar totalmente no ambiente do Visual Studio podem usar o Visual Studio 2010 Professional Edition.

Depois que são criados, os formulários de fluxo de trabalho do InfoPath são anexados a um fluxo de trabalho através de um arquivo workflow.xml, assim como ocorre com os formulários do ASP.NET. Diferentemente dos formulários do ASP.NET, X, entretanto, os desenvolvedores não precisam escrever código personalizado para mover informações entre os formulários de fluxo de trabalho do InfoPath e um fluxo de trabalho. Em vez disso, o SharePoint Server e o InfoPath oferecem esse vínculo, simplificando a vida de quem cria fluxos de trabalho.

De várias formas, os fluxos de trabalho se parecem com fluxogramas. Sendo assim, faz sentido fornecer uma ferramenta gráfica que permita que os desenvolvedores especifiquem as ações dos fluxos de trabalho. Trata-se de uma ferramenta de Fluxo de Trabalho do SharePoint Workflow no Visual Studio 2010 Professional, que é um tipo de projeto que usa o Designer de Fluxo de Trabalho do Windows Workflow Foundation (WF), e adiciona suporte de implantação e formulários aos Fluxos de Trabalho. Os desenvolvedores usam o Designer de Fluxo de Trabalho do WF para definir graficamente as atividades de um fluxo de trabalho e a ordem em que essas atividades serão executadas. A tela abaixo mostra um exemplo simples de qual será a aparência disso no Microsoft Visual Studio.

Fluxo de trabalho Coletar Comentários

As atividades disponíveis para uso aparecem na Caixa de Ferramentas no lado esquerdo da tela. Um desenvolvedor pode arrastar essas atividades para a superfície de design, para definir as etapas de um fluxo de trabalho. As propriedades de cada atividade, em seguida, podem ser definidas na janela Propriedades que aparece no canto inferior direito.

A Biblioteca de Atividades Base do Windows Workflow Foundation fornece um grupo de atividades fundamentais, conforme descrito anteriormente. O SharePoint Server também fornece um conjunto de atividades projetado expressamente para criar fluxos de trabalho. Entre eles, os mais importantes são:

• OnWorkflowActivated: fornece um ponto de partida padrão para um fluxo de trabalho. Entre outras coisas, essa atividade pode aceitar informações fornecidas por um administrador do SharePoint com o uso do formulário Associação quando o fluxo de trabalho está associado a uma biblioteca de documentos, uma lista, um tipo de conteúdo ou um site. Ela também pode aceitar informações fornecidas pelo formulário Iniciação quando o fluxo de trabalho é iniciado. Cada fluxo de trabalho deve começar com essa atividade.

• CreateTask: cria uma tarefa atribuída a um usuário específico em uma lista de tarefas. Por exemplo, o fluxo de trabalho de aprovação no cenário descrito anteriormente usou essa atividade para adicionar uma tarefa à lista de tarefas usada por cada participante. Essa atividade também tem uma propriedade SendEmailNotification que, quando definida como verdadeira, envia automaticamente um email à pessoa para quem a tarefa foi criada.

• OnTaskChanged: aceita informações do formulário Conclusão da Tarefa. O fluxo de trabalho de aprovação no cenário anterior usou essa atividade para aceitar a entrada de cada participante quando o documento foi aprovado.

• CompleteTask: marca uma tarefa como concluída.

• DeleteTask: remove uma tarefa de uma lista de tarefas.

• OnWorkflowModified: aceita informações do formulário Modificação, que podem então ser usadas para alterar o comportamento dessa instância do fluxo de trabalho. Se o criador do fluxo de trabalho optar por não incluir instâncias dessa atividade no fluxo de trabalho, esse fluxo não poderá ser modificado durante a execução.

• SendEmail: envia email a uma pessoa ou a um grupo de pessoas especificado.

• LogToHistoryList: grava informações sobre a execução do fluxo de trabalho em uma lista de histórico. As informações nessa lista são usadas para permitir que os usuários vejam em que ponto um fluxo de trabalho se encontra na sua execução, examinem o histórico do fluxo de trabalho após a sua conclusão e muito mais. Para permitir esse tipo de monitoramento, o autor do fluxo de trabalho deve gravar informações em uma lista de Histórico em pontos apropriados da execução do fluxo de trabalho. Como ele fornece o seu próprio mecanismo de acompanhamento de fluxos de trabalho, o SharePoint Server não oferece suporte ao serviço de acompanhamento padrão do WF.

Um padrão típico para um fluxo de trabalho simples começa com uma atividade OnWorkflowActivated e, em seguida, usa uma atividade CreateTask para atribuir uma tarefa a um participante desse fluxo de trabalho. A atividade While padrão da BAL pode ser usada em seguida para aguardar até que o usuário conclua a tarefa. Para saber quando isso ocorreu (talvez um usuário faça várias alterações na tarefa e marque uma caixa de seleção no formulário Conclusão da Tarefa quando terminar), uma atividade OnTaskChanged é executada dentro da atividade While, extraindo todas as informações que o usuário inseriu nesse formulário. Quando o usuário tiver concluído a tarefa, uma atividade CompleteTask poderá ser executada, seguida por DeleteTask. Depois disso, o fluxo de trabalho pode passar ao próximo participante, usando CreateTask para lhe atribuir uma tarefa, e assim por diante. Naturalmente, outras coisas podem ocorrer, como o envio de um email, o registro de informações na lista de histórico ou até mesmo a inclusão da atividade Código da BAL, que permite a execução de um código arbitrário.

Todas as atividades oferecidas pelo SharePoint Server destinam-se a permitir que os fluxos de trabalho operem no ambiente do SharePoint. A lógica de negócios implementada por um fluxo de trabalho é critério exclusivo do criador desse fluxo de trabalho. Na verdade, um desenvolvedor que gera um fluxo de trabalho tem a liberdade de criar e usar suas próprias atividades personalizadas, pois não é obrigatório o uso exclusivo das atividades fornecidas pelo SharePoint Server e pelo WF.

Conforme descrito anteriormente, o Windows Workflow Foundation oferece suporte a fluxos de trabalho sequenciais, paralelos e de máquina de estado. Um fluxo de trabalho criado com o Designer de Fluxo de Trabalho do WF também pode usar qualquer uma dessas opções. Para permitir isso, o SharePoint Server adiciona tipos de projeto ao Visual Studio, um para cada um desses estilos de fluxo de trabalho.

Qualquer que seja o estilo escolhido, o desenvolvedor deve definir mais do que apenas a lógica do fluxo de trabalho; deve também especificar os formulários .aspx ou do InfoPath a serem usados. Para fazer isso, o desenvolvedor depende de um arquivo chamado element.xml. Esse arquivo fornece um modelo que o desenvolvedor preenche para especificar qual formulário, se for o caso, deverá ser exibido em cada um dos quatro pontos em que o fluxo de trabalho poderá fazer isso.

Um desenvolvedor deve realizar certas operações para transmitir informações entre um fluxo de trabalho e o formulário .aspx que ele utiliza. O namespace Microsoft.Windows.SharePoint.Workflow expõe um modelo de objeto para desenvolvedores. Usando os tipos desse namespace, o criador de um fluxo de trabalho pode transmitir informações de um formulário .aspx para o fluxo de trabalho e vice-versa.

Após a criação de um fluxo de trabalho e seus formulários, o desenvolvedor deve empacotá-los naquilo que chamamos de Recurso. Um administrador do SharePoint deve então instalar esse Recurso, o que inclui a instalação de assemblies do fluxo de trabalho no cache global de assemblies do sistema de destino. Agora, o novo fluxo de trabalho estará visível ao administrador como um modelo de fluxo de trabalho que pode ser associado a uma biblioteca de documentos, uma lista, um tipo de conteúdo ou um site.

Para um desenvolvedor de software, criar um fluxo de trabalho usando o Visual Studio e o Designer de Fluxo de Trabalho do WF não é muito difícil. É preciso entender as particularidades de trabalhar nesse ambiente, mas grande parte do trabalho envolvido já será do seu conhecimento. Porém, desenvolvedores de software não são os únicos que gostariam de criar fluxos de trabalho. Conforme descrito a seguir, pessoas que não são desenvolvedores profissionais também podem criar fluxos de trabalho com a ajuda do Microsoft SharePoint Designer 2010.

Criando fluxos de trabalho com o Microsoft SharePoint Designer 2010

O Microsoft SharePoint Designer 2010 é um aplicativo separado disponível para download gratuito. O Microsoft SharePoint Designer permite que operadores de informações e outros adicionem a lógica do aplicativo (implementada como um fluxo de trabalho) aos sites do SharePoint. Esta é certamente uma meta útil, mas o Microsoft SharePoint Designer também se volta para outro problema importante. Se um desenvolvedor cria um fluxo de trabalho com o Visual Studio, esse fluxo de trabalho deve ser implantado em um servidor que esteja executando o SharePoint Server como qualquer outro recurso. Porém, muitos administradores do SharePoint não permitem a implantação de código arbitrários em seus servidores por acreditar que há um risco muito grande de desestabilizar o sistema por conta disso. No entanto, ser capaz de criar uma lógica de negócios objetiva atrelada a documentos e itens de lista é muito útil, além de ser algo de que muitos usuários do SharePoint precisam. Além de permitir que pessoas sem muito conhecimento técnico criem fluxos de trabalho, o Microsoft SharePoint Designer também resolve esse problema fornecendo uma maneira mais segura de definir e implantar lógicas de negócios em servidores que estejam executando o SharePoint Server.

Os cenários de fluxo de trabalho alvo do Microsoft SharePoint Designer são de algum modo diferentes daqueles abordados pelo Visual Studio e pelo Designer de Fluxo de Trabalho do WF. Embora certamente seja possível criar aplicativos complexos, o objetivo do Microsoft SharePoint Designer é permitir que os usuários adicionem lógica de negócios a sites do SharePoint. Por exemplo, suponha que um site contenha uma lista que permita que seus usuários enviem solicitações de alteração. O Microsoft SharePoint Designer pode ser usado para criar um fluxo de trabalho que informe automaticamente o solicitante quando sua solicitação de alteração for aceita ou rejeitada. Da mesma forma, um fluxo de trabalho personalizado pode informar um grupo específico de usuários sempre que um novo documento for adicionado a uma biblioteca de documentos específica. Executar esse tipo de notificação personalizada não é complicado já que a criação de fluxos de trabalho é fácil, mas é um desafio nas versões anteriores do SharePoint Server devido à relutância dos administradores em instalar códigos escritos pelo usuário.

Há uma pergunta óbvia aqui: por que a lógica criada com o Microsoft SharePoint Designer deve ser tratada de modo diferente? O que faz com que os administradores do SharePoint se disponham a permitir que fluxos de trabalho compilados com essa ferramenta sejam implantados nos sistemas pelos quais são responsáveis? A resposta é que os fluxos de trabalho compilados com o Microsoft SharePoint Designer só podem usar as atividades de uma lista controlada por administrador. Além das atividades fornecidas pelo SharePoint Server, um administrador de site pode escolher se deseja ou não incluir nessa lista atividades personalizadas criadas por um desenvolvedor. Ao definir exatamente quais fluxos de trabalho têm permissão para isso, um administrador do SharePoint pode ter mais confiança de que a implantação da lógica criada com o uso do Microsoft SharePoint Designer não desestabilizará o sistema.

Por ser destinado a operadores de informações e não a desenvolvedores e também porque enfatiza cenários mais simples, o Microsoft SharePoint Designer usa para criação de fluxos de trabalho um modelo diferente do Designer de Fluxo de Trabalho do WF hospedado no Visual Studio. Em vez de uma abordagem gráfica, o Microsoft SharePoint Designer usa uma abordagem baseada em regras. Há alguma semelhança com o Assistente de Regras do Microsoft Outlook, uma ferramenta familiar para muitas pessoas. A tela a seguir ilustra como um usuário do Microsoft SharePoint Designer define uma etapa em um fluxo de trabalho. Observe que esse fluxo de trabalho executa algumas ações em paralelo, enquanto outras ações são executadas em série. As versões anteriores do SharePoint Server ofereciam suporte apenas para a execução de ações em série: elas só eram executadas sucessivamente.

Fluxo de Trabalho Processar Pedido

Cada etapa pode ter uma condição e uma ação. A condição determina se a ação dessa etapa deverá ser executada, como na instrução If mostrada abaixo. As escolhas de ações incluem itens como atribuir um animador para um evento, coletar aprovações e muito mais. Na verdade, cada uma dessas ações é executada por alguma atividade do SharePoint Server. Além disso, as atividades usadas aqui são as mesmas do Visual Studio e do Designer de Fluxo de Trabalho do WF. A lista de ações também pode incluir qualquer outra atividade permitida pelo administrador do SharePoint neste site, inclusive atividades personalizadas e criadas por desenvolvedores. No SharePoint Server também há um conjunto de atividades com o qual os usuários podem personalizar o paradigma comum de aprovação ou coleta de comentários de “criar um conjunto de tarefas e aguardar a sua conclusão” em um designer especial no Microsoft SharePoint Designer.

Apesar de sua interface de usuário ser bem diferente visualmente da abordagem gráfica usada com o Visual Studio e o Designer de Fluxo de Trabalho do WF, o Microsoft SharePoint Designer cria um fluxo de trabalho do WF padrão. O resultado final será um fluxo de trabalho sequencial, paralelo ou uma combinação dos dois, com condições expressas com a ajuda do mecanismo de regras do WF. Entretanto, os fluxos de trabalho criados com essa ferramenta possuem algumas limitações. Por exemplo, eles não podem ser modificados enquanto estão sendo executados, diferentemente daqueles produzidos com o Visual Studio e com o Designer de Fluxo de Trabalho, e apenas fluxos de trabalho sequenciais e paralelos podem ser criados; não há suporte para máquinas de estado. Além disso, fluxos de trabalho produzidos com essa ferramenta podem ser criados a partir de uma biblioteca de documentos, lista ou site específico durante sua concepção. Os autores de fluxos de trabalho também podem criar um modelo de um fluxo de trabalho geral que pode ser associado futuramente a qualquer biblioteca, lista ou tipo de conteúdo. Embora isso limite o modo de criação de um fluxo de trabalho, também facilita muito sua implantação. Na verdade, quando um usuário termina de criar um fluxo de trabalho com o Microsoft SharePoint Designer, a ferramenta fornece uma implantação com apenas um clique do fluxo de trabalho no site de destino, o que inclui sua ativação. Isso é muito menos complicado do que o processo de implantação em várias etapas exigido para os fluxos de trabalho criados com o uso do Visual Studio e do Designer de Fluxo de Trabalho do WF.

Os fluxos de trabalho criados no Microsoft SharePoint Designer também podem exibir formulários personalizados. No entanto, em vez de exigir que autores de fluxo de trabalho criem páginas .aspx diretamente, a ferramenta gera essas páginas. O autor especifica os detalhes sobre como deve ser a aparência das páginas geradas, como que campos elas devem conter, e o Microsoft SharePoint Designer cuida do resto. Entretanto, dos quatro pontos do ciclo de vida de um fluxo de trabalho onde é possível usar formulários, apenas dois podem ser usados em fluxos de trabalho criados no Microsoft SharePoint Designer: Iniciação e Conclusão da Tarefa. Como cada fluxo de trabalho criado com essa ferramenta deve ser associado a uma biblioteca de documentos, lista, tipo de conteúdo ou site em particular, não há necessidade de uma etapa de associação e, consequentemente de um formulário de Associação. Como esses fluxos de trabalho não podem ser modificados durante a execução, não há necessidade de um formulário Modificação.

O Microsoft SharePoint Designer também permite importar fluxos de trabalho que foram criados com o uso do Microsoft Visio 2010. Isso possibilita que um gerente comercial ou um autor de fluxo de trabalho crie a lógica de fluxo de trabalho usando um ambiente gráfico bastante conhecido. Em seguida, o autor pode importar essa lógica para o Microsoft SharePoint Designer, modificá-la se necessário e então publicá-la em um site do SharePoint.

O SharePoint Server oferece várias funcionalidades para a criação de fluxos de trabalho orientados por documentos. Mesmo assim, no final das contas, trata-se de uma plataforma de desenvolvimento e execução. Ele não oferece funcionalidades de fluxo de trabalho diretamente utilizáveis pelos usuários finais. Os fluxos de trabalho em execução no SharePoint Server também apresentam outras restrições, como a incapacidade de interagir com os participantes usando aplicativos clientes do Office.

Comparação de ferramentas de criação

A tabela a seguir mostra as diferenças importantes entre as ferramentas para as quais a Microsoft oferece suporte na criação de fluxos de trabalho no SharePoint Server, usando o SharePoint Designer e o Designer de Fluxo de Trabalho do WF no Visual Studio 2010 Professional Edition.

Capacidade/Requisito	SharePoint Designer	Designer de Fluxo de Trabalho do WF no Visual Studio
Os fluxos de trabalho podem ser criados apenas com o uso de ações aprovadas pelos administradores de sites?	Sim	Não
Os fluxos de trabalho podem ser acessados em aplicativos clientes (além do navegador)?	Sim	Sim
É possível usar o Microsoft Visio Professional para criar a lógica de fluxo de trabalho?	Sim	Não
É necessário escrever código?	Não	Sim
São fornecidas atividades adicionais (além daquelas fornecidas pelo SharePoint Server)?	Não	Sim
É possível criar atividades personalizadas?	Não	Sim
Os formulários do InfoPath podem ser usados no fluxo de trabalho?	Sim	Sim
Os fluxos de trabalho podem ser modificados enquanto são executados?	Não	Sim
É possível a publicação de fluxos de trabalho com apenas um clique?	Sim	Sim
Os fluxos de trabalho podem ser implantados remotamente?	Sim	Não
É possível torná-los disponíveis no farm?	Não	Sim
É possível definir o escopo para um conjunto de sites?	Sim	Sim