Share via

Planejar um aplicativo orientado a formulários

  • Artigo

 

Aplica-se a: SharePoint Server 2010

Tópico modificado em: 2016-11-30

Muitos aplicativos do SharePoint Server contêm formulários do InfoPath. Um subconjunto desses aplicativos é, na verdade, orientado por um formulário. Esses aplicativos orientados a formulário normalmente compartilham as seguintes características:

  • Eles automatizam um processo empresarial, como a criação de um pedido ou a conclusão de avaliações de desempenho de funcionário.

  • Existe uma informação estruturada fundamental, e suas instâncias fluem por diferentes atividades para concluir o processo empresarial.

Embora cada aplicativo orientado a formulário seja exclusivo, a estrutura encontrada em aplicativos orientados a formulário quase sempre tem um design comum. Se o seu aplicativo se ajustar a esse design comum, você poderá usar o design apresentado neste artigo e modificá-lo para o seu caso específico.

Este artigo descreve um design para um tipo particular de aplicativo do Microsoft SharePoint Server 2010 que usa formulários. Ele não aborda como projetar outros tipos de aplicativos do SharePoint Server ou como projetar os próprios formulários. Para obter mais informações sobre como projetar formulários do Microsoft InfoPath 2010, consulte Office.com (https://go.microsoft.com/fwlink/?linkid=187550&clcid=0x416).

Neste artigo:

  • Estrutura de um aplicativo orientado a formulário

  • Sobre o planejamento de um aplicativo orientado a formulário

  • Identificando a informação-chave

  • Usando uma lista ou uma biblioteca de formulários

  • Fluxo de trabalho

  • Fontes de dados adicionais

  • Portais

  • Resumo

Estrutura de um aplicativo orientado a formulário

Um aplicativo complexo orientado a formulário do SharePoint Server pode conter os seguintes componentes:

  • Um site do SharePoint no qual hospedará o aplicativo.

  • Um modelo de formulário que captura a informação principal. O modelo de formulário pode ter modos de exibição diferentes para grupos de usuários diferentes ou para estágios diferentes do ciclo de vida da informação.

  • Uma lista ou biblioteca do SharePoint na qual armazenar instâncias do modelo de formulário concluído (conhecido como formulários).

  • Um fluxo de trabalho que roteia um item por um processo empresarial. O fluxo de trabalho começa quando um novo formulário é criado.

  • As listas do SharePoint que contêm informações auxiliares usadas para preencher campos no modelo de formulário. Os formulários e fluxos de trabalho podem estar associados a essas lis tas para gerenciamento das informações na lista.

  • Bancos de dados externos ou aplicativos LOB (linha de negócios) que oferecem dados para o modelo de formulário ou fluxo de trabalho.

  • Lógica comercial representada como regras de validação no modelo de formulário ou como parte do fluxo de trabalho.

  • Uma página da Web que serve como um portal e permite que os usuários criem uma nova instância do modelo de formulário e exibam outras informações sobre os formulários. Pode haver vários portais para audiências diferentes.

O seu aplicativo não precisa coincidir exatamente com essa estrutura. Alguns aplicativos orientados a formulário do SharePoint Server não contêm esses componentes, e outros adicionam pequenas variações, como ter mais de um fluxo de trabalho.

Sobre o planejamento de um aplicativo orientado a formulário comum

Para projetar um tipo comum de aplicativo orientado a formulário, primeiro é preciso determinar a informação-chave que orienta o processo empresarial. Em seguida, você decidirá onde as informações serão armazenadas, em uma lista ou biblioteca do SharePoint, e definirá o fluxo de trabalho usado para processar as informações. Depois você determinará qualquer fonte de dados adicional necessária. Por fim, projete os portais pelos quais os usuários acessarão o aplicativo.

Identificando a informação-chave

A primeira etapa do planejamento de um aplicativo orientado a formulário é determinar a informação-chave em torno da qual o aplicativo revolverá. Em muitas situações, ela é óbvia. Em um aplicativo de helpdesk, por exemplo, a informação principal provavelmente será uma solicitação de serviço. Em um processo de avaliação de desempenho de funcionário, a informação-chave provavelmente será o formulário de avaliação de desempenho. Em um sistema de compras, a informação fundamental será, provavelmente, um pedido.

Identifique a informação-chave que orienta o processo. Se ela não for óbvia, considere as seguintes sugestões:

  • Se o aplicativo automatizará um processo existente, há um documento ou arquivo entregue de uma pessoa para outra à medida que o processo avança? Esse documento ou arquivo provavelmente será a informação-chave.

  • Um processo inicia quando um item é criado ou quando um item aparece em determinado local? Esse item poderia ser a informação-chave.

  • A informação-chave provavelmente tem alguma estrutura e pode aumentar ou ser alterada à medida que é processada. Por exemplo, um pedido contém o nome e o endereço do cliente, uma lista de itens completa com quantidade e preço e outros detalhes. Mais informações, como o número para rastreamento, serão adicionadas ao pedido à medida que ele for processado.

  • Provavelmente, a informação principal tem um status associado a ela, e esse status é alterado com o tempo.

Se você não puder determinar a informação-chave que orienta o processo, o design apresentado neste artigo provavelmente não se ajustará ao seu aplicativo.

Quando implementar o aplicativo, você criará um modelo de formulário para essa informação-chave. Esse modelo de formulário será chamado de "formulário principal" neste artigo.

Usando uma lista ou biblioteca de formulários

Determine se você armazenará instâncias do formulário principal em uma lista do SharePoint ou em uma biblioteca de formulários do SharePoint Server.

Se possível, use uma lista. Uma solução baseada em lista é mais simples e mais eficiente. No entanto, existem determinadas situações nas quais uma lista não funcionará. Se qualquer uma das condições a seguir for verdadeira, use uma biblioteca de formulários:

  • Você precisa manter um histórico de alterações feitas em instâncias de formulário.

  • O formulário principal contém seções repetidas, como um número arbitrário de realizações em um formulário de avaliação de um funcionário.

  • O formulário principal tem dados aninhados, como um formulário de pedido que contém um item, onde o item pode conter um código de produto, uma quantidade, um tamanho e um preço.

  • O formulário principal conterá código.

    A seguir, algumas situações nas quais um formulário pode conter código:

    • O formulário inclui botões que executam ações personalizadas.

    • O valor de um campo do formulário se baseia em uma combinação complexa de outros valores no formulário.

  • Instâncias do formulário principal serão digitalmente assinadas.

  • Você precisa armazenar dados sobre cada instância do formulário principal em XML.

Se você armazenar instâncias do formulário principal em uma lista, cada campo do formulário principal se tornará uma coluna na lista e cada instância do formulário principal se tornará um item de lista. Se você armazenar instâncias do formulário principal em uma biblioteca de formulários, cada instância será transformada em um documento XML e os documentos serão armazenados na biblioteca.

Fluxo de trabalho

O processo empresarial começa quando algo acontece a uma instância do formulário principal. Com frequência, a criação de uma nova instância do próprio formulário principal inicia o processo empresarial, mas outros eventos, como a modificação de uma instância do formulário principal ou sua atribuição a uma pessoa também podem iniciar um processo.

O processo empresarial roteia a instância do formulário principal pelas pessoas e sistemas que precisam executar ações. Se o formulário principal for uma solicitação de serviço, por exemplo, a criação de uma nova solicitação de serviço poderia iniciar um processo que a atribui a um representante de serviço que irá interagir com a pessoa que originou a solicitação. O representante de serviço pode tomar várias ações, dependendo do resultado da discussão com o originador: por exemplo, escalar a solicitação para um representante sênior, marcar a solicitação como resolvida, encaminhar a solicitação para o departamento de pedidos caso o o originador tenha solicitado uma substituição e assim por diante.

Identifique as etapas e pontos de decisão envolvidos no processamento de uma instância do formulário principal. Essa sequência de etapas será representada no SharePoint Server como um fluxo de trabalho. Para obter mais informações sobre fluxos de trabalho, consulte Planejar fluxos de trabalho (SharePoint Server 2010)

Fontes de dados adicionais

Um modelo de formulário pode recuperar dados de fontes externas como um banco de dados, um serviço Web ou uma lista do SharePoint. Um uso comum para dados externos é preencher uma lista de valores válidos para um campo no modelo de formulário, como uma lista de centros de custo. Você também poderia usar uma regra para calcular o valor de um campo com base em uma combinação de dados externos e os valores de outros campos. Por exemplo, o valor de um campo "aprovador" pode ser obtido usando uma fonte de dados externa para pesquisar o gerente do funcionário cujo nome foi inserido no campo "enviado por".

Identifique os dados externos que serão acessados pelo formulário principal. Para cada fonte de dados externos, indique a origem dos dados. Por exemplo, os dados vêm de uma lista do SharePoint, de um sistema LOB como o SAP ou de alguma outra fonte?

Observação

É possível acessar alguns dados LOB diretamente de listas do SharePoint Server criando um tipo de conteúdo externo. Para obter mais informações sobre como criar tipos de conteúdo externos, consulte Visão geral dos Serviços Corporativos de Conectividade (SharePoint Server 2010)

Para qualquer lista do SharePoint que forneça dados ao formulário principal, considere como você irá gerenciar os dados. Você criará um formulário para inserir novos dados na lista? Serão necessários fluxos de trabalho para o gerenciamento de itens da lista? Por exemplo, se o formulário principal usar uma lista de centros de custo, é possível adicionar um fluxo de trabalho de Aprovação à lista.

Portais

Quem usará o aplicativo? Existem funções de usuário diferentes, com membros de uma função executando ações diferentes ou exibindo informações diferentes do que usuários de outras funções? Se usuários em funções diferentes usarão o aplicativo de formas diferentes, considere a criação de um portal para cada função. Ajuste as ações e informações disponíveis em cada porta à função de usuários que estejam usando o portal.

Por exemplo, em um aplicativo de avaliação de desempenho de funcionário, provavelmente existem pelo menos três funções:

  • Funcionários, que preenchem formulários de avaliação.

  • Gerentes, que adicionam informações a formulários de avaliação de desempenho e aprovam avaliações de desempenho.

  • Profissionais de recursos humanos, que criam relatórios e agregam informações de avaliações de desempenho.

Os funcionários acessariam o aplicativo de avaliação de desempenho por meio de um portal de funcionário que possibilitaria a criação de um novo formulário de avaliação de desempenho e o rastreamento para saber se sua própria avaliação de desempenho foi aprovada pelo gerente. Os gerentes poderiam acessar o aplicativo por meio de um portal de gerente que poderia mostrar uma lista de funcionários com uma indicação de que o funcionário já enviou um formulário de avaliação de desempenho e um link para abri-lo. Os profissionais de recursos humanos acessariam o aplicativo por meio de um portal de RH que poderia mostrar estatísticas resumidas de quantos formulários de avaliação de desempenho foram aprovados, enviados mas ainda não aprovados ou ainda não enviados.

O tipo mais simples de portal a ser criado é simplesmente um modo de exibição da lista ou biblioteca do SharePoint, no qual instâncias do formulário principal são armazenadas. É possível usar um filtro ou aplicar formatação condicional para personalizar o modo de exibição para o usuário específico.

Você também pode projetar uma página da Web personalizada para cada função de usuário e oferecer a cada usuário a URL apropriada à sua função para acesso ao aplicativo. Nas páginas da Web do portal, é possível incluir alguns dos seguintes elementos:

Resumo

Se você pôde determinar características do seu aplicativo que correspondessem à maioria das seções anteriores, é provável que possa implementar o aplicativo seguindo o paradigma de um aplicativo orientado a formulários. Crie um site do SharePoint para hospedar o aplicativo. Crie um modelo de formulário para o formulário principal; crie uma lista ou biblioteca para armazenar instâncias do formulário principal e associe o modelo de formulário à lista ou biblioteca. Adicione um fluxo de trabalho que seja disparado quando um novo formulário for adicionado à lista ou biblioteca. Crie e preencha qualquer lista adicional necessária para fornecer dados para o modelo de formulário. Crie um ou mais portais pelos quais os usuários irão interagir com o aplicativo.

See Also

Concepts

Sobre formulários no SharePoint Server 2010
Administração de formulários do InfoPath (SharePoint Server 2010)