Planeación de una aplicación basada en formularios

Artículo
12/13/2016

Se aplica a: SharePoint Server 2010

Última modificación del tema: 2016-11-30

Muchas aplicaciones de SharePoint Server contienen formularios de InfoPath. De hecho, un subconjunto de estas aplicaciones está basado en formularios. Normalmente, las aplicaciones basadas en formularios comparten las siguientes características:

Automatizan un proceso de negocio, como realizar un pedido o completar las evaluaciones de rendimiento del empleado.
Existe información estructurada clave, las instancias de la cual circulan a través de distintas actividades para completar el proceso de negocio.

Aunque cada aplicación basada en formularios es única, la estructura de las aplicaciones basadas en formularios tiene, a menudo, un diseño común. Si su aplicación se ajusta a este diseño común, es posible que pueda utilizar el diseño presentado en este artículo y adaptarlo para su caso concreto.

En este artículo se describe un diseño para un tipo determinado de aplicación de Microsoft SharePoint Server 2010 que utiliza formularios. No se trata el diseño de otros tipos de aplicaciones de SharePoint Server o de los formularios. Para obtener más información sobre el diseño de formularios de Microsoft InfoPath 2010, vea Office.com (https://go.microsoft.com/fwlink/?linkid=187550&clcid=0xC0A).

En este artículo:

Estructura de una aplicación basada en formularios
Planeación de una aplicación basada en formularios normal
Identificación de información clave
Uso de una lista o biblioteca de formularios
Flujo de trabajo
Orígenes de datos adicionales
Portales
Resumen

Estructura de una aplicación basada en formularios

Una aplicación de SharePoint Server basada en formularios compleja puede contener los siguientes componentes:

Un sitio de SharePoint para hospedar la aplicación.
Una plantilla de formulario que captura la parte principal de la información. La plantilla de formulario podría tener diferentes vistas para diferentes grupos de usuarios o para diferentes fases del ciclo de vida de la información.
Una lista o biblioteca de SharePoint para almacenar las instancias de la plantilla de formulario completadas (conocidas como formularios).
Un flujo de trabajo que redirige un elemento a través de un proceso de negocio. El flujo de trabajo se inicia cuando se crea un nuevo formulario.
Listas de SharePoint que contienen información secundaria que se utiliza para rellenar los campos en la plantilla de formulario. Los formularios y flujos de trabajo pueden estar asociados con estas listas para administrar la información de la lista.
Bases de datos externas o aplicaciones de línea de negocio (LOB) que proporcionan datos para la plantilla de formulario o el flujo de trabajo.
Lógica de negocios representada como reglas de validación en la plantilla de formulario o como parte del flujo de trabajo.
Una página web que sirve como un portal y permite a los usuarios crear una nueva instancia de la plantilla de formulario y ver otra información sobre los formularios. Puede haber varios portales para distintas audiencias.

Su aplicación no tiene que coincidir exactamente con esta estructura. Algunas aplicaciones de SharePoint Server basadas en formularios no contienen todos estos componentes, mientras que otras agregan pequeñas variaciones, como tener más de un flujo de trabajo.

Planeación de una aplicación basada en formularios normal

Para diseñar un tipo común de aplicación basada en formularios, primero determine cuál es la información clave que impulsa el proceso de negocio. A continuación, decida si desea almacenar la información en una lista o biblioteca de SharePoint y defina el flujo de trabajo que se utiliza para procesar la información. Luego, determine los orígenes de datos adicionales que se necesitarán. Finalmente, diseñe los portales a través del cual los usuarios tendrán acceso a la aplicación.

Identificación de la información clave

El primer paso para planear una aplicación basada en formularios es determinar cuál es la información clave en torno a la cual gira la aplicación. En muchas situaciones, esta información es obvia. En una aplicación del departamento de soporte técnico, por ejemplo, la información clave es probablemente una solicitud de servicio. En un proceso de evaluación del rendimiento del empleado, la información clave es, probablemente, un formulario de evaluación del rendimiento. En un sistema de compra, la información clave es, probablemente, un pedido.

Identificar la información clave que impulsa el proceso. Si la información clave no es evidente, tenga en cuenta las siguientes sugerencias:

Si la aplicación automatizará un proceso existente, ¿hay un documento o un archivo que se pase de una persona a otra a medida que avanza el proceso? Es probable que dicho documento o archivo sea la información clave.
¿Se inicia un proceso cuando se crea un elemento o cuando un elemento se encuentra en una ubicación determinada? Ese elemento podría ser la información clave.
Probablemente, la información clave tiene alguna estructura y puede crecer o cambiar a medida que se procesa. Por ejemplo, un pedido tiene el nombre y la dirección del cliente, una lista de artículos con cantidad y precio y otros detalles. A medida que el pedido se procesa, se agrega más información, tal como un número de seguimiento.
Es posible que la información clave tenga un estado asociado y que este cambie a lo largo del tiempo.

Si no puede determinar cuál es la información clave que impulsa el proceso, probablemente el diseño presentado en este artículo no se adapte a su aplicación.

Cuando implemente la aplicación, creará una plantilla de formulario para esta información clave. En este artículo, dicha plantilla se denominará "formulario principal".

Uso de una lista o biblioteca de formularios

Determine si almacenará las instancias del formulario principal en una lista de SharePoint o en una biblioteca de formularios de SharePoint Server.

Si es posible, use una lista. Una solución basada en listas es más sencilla y eficaz. Sin embargo, hay determinadas situaciones en las que una lista no funcionará. Si se cumple alguna de las siguientes condiciones, utilice una biblioteca de formularios:

Debe mantener un historial de cambios de las instancias de formulario.
El formulario principal contiene las secciones extensibles, como un número arbitrario de logros en el formulario de evaluación de un empleado.
El formulario principal tiene datos anidados, como un formulario de pedido que contiene un elemento, el cual puede contener un código de producto, una cantidad, un tamaño y un precio.
El formulario principal contiene código.

Las siguientes son algunas situaciones en las que un formulario puede contener código:
- El formulario incluye botones que realizan acciones personalizadas.
- El valor de un campo en el formulario se basa en una combinación compleja de otros valores del formulario.
Las instancias del formulario principal se firmarán digitalmente.
Debe almacenar datos sobre cada instancia del formulario principal en XML.

Si almacena instancias del formulario principal en una lista, cada campo del formulario se convertirá en una columna en la lista y cada instancia se convertirá en un elemento de lista. Si almacena instancias del formulario principal en una biblioteca de formulario, cada instancia se convertirá en un documento XML y los documentos se almacenarán en la biblioteca.

Flujo de trabajo

El proceso de negocio se inicia cuando ocurre algo con una instancia del formulario principal. A menudo, la creación de una nueva instancia del formulario principal da inicio al proceso de negocio, pero otros eventos, como la modificación de una instancia del formulario principal o su asignación a una persona también puede iniciar un proceso.

El proceso de negocio redirige la instancia del formulario principal por las personas y los sistemas que tienen que realizar acciones. Si el formulario principal fuera una solicitud de servicio, por ejemplo, la creación de una nueva solicitud de servicio podría iniciar un proceso que asigne la solicitud de servicio a un representante del servicio para interactuar con la persona que originó la solicitud. El representante de servicio podría llevar a cabo varias acciones en función del resultado de la conversación con el autor: por ejemplo, enviar la solicitud a un representante principal, marcar la solicitud como resuelta, reenviar la solicitud al departamento de pedidos si se debe enviar un reemplazo al autor, etc.

Identifique los pasos y puntos de decisión que forman parte del procesamiento de una instancia del formulario principal. Esta secuencia de pasos se representarán como un flujo de trabajo en SharePoint Server . Para obtener más información sobre los flujos de trabajo, vea Planeación de flujos de trabajo (SharePoint Server 2010).

Orígenes de datos adicionales

Una plantilla de formulario puede recuperar datos de orígenes externos, como una base de datos, un servicio web o una lista de SharePoint. Un uso común de los datos externos es rellenar una lista de valores válidos para un campo en la plantilla de formulario, como una lista de centros de costo. También podría utilizar una regla para calcular el valor de un campo basándose en una combinación de datos externos y los valores de otros campos. Por ejemplo, se podría obtener el valor de un campo "aprobador" mediante el uso de un origen de datos externos para buscar al jefe del empleado cuyo nombre se especificó en el campo "enviado por".

Identifique los datos externos a los que tendrá acceso el formulario principal. Para cada origen de datos externo, indique el origen de los datos. Por ejemplo, ¿los datos proceden de una lista de SharePoint, una base de datos SQL, un sistema LOB (como SAP) o de algún otro origen?

Nota

Para obtener acceso a algunos datos de LOB directamente desde las listas de SharePoint Server mediante la creación de un tipo de contenido externo. Para obtener más información sobre la creación de tipos de contenido externo, vea Información general de Servicios de conectividad empresarial (SharePoint Server 2010).

Para las listas de SharePoint que proporcionan datos al formulario principal, considere cómo administrará los datos de la lista. ¿Creará un formulario para escribir nuevos datos en la lista?¿Se necesitan flujos de trabajo para administrar los elementos de la lista? Por ejemplo, si el formulario principal utiliza una lista de los centros de costo, puede agregar un flujo de trabajo de aprobación a la lista.

Portales

¿Quién utilizará la aplicación?¿Existen roles de usuario diferentes: los miembros de un rol realizan diferentes acciones o ven información diferente en comparación con los usuarios de otros roles? Si los usuarios con roles diferentes realizarán tareas diferentes con la aplicación, considere la posibilidad de crear un portal para cada rol. Adapte las acciones y la información que están disponibles en cada portal para el rol de los usuarios que utilizan el portal.

Por ejemplo, una aplicación de evaluación del rendimiento de un empleado, probablemente cuente con al menos tres roles:

Empleados: quienes completan los formularios de evaluación del rendimiento.
Jefes: quienes agregan información a un formulario de evaluación del rendimiento y aprueban las evaluaciones del rendimiento.
Profesionales de recursos humanos: quienes crean informes y agregar información del las evaluaciones del rendimiento.

Los empleados tendrían acceso a la aplicación de evaluación del rendimiento a través de un portal para empleados que podría permitirles crear un nuevo formulario de evaluación del rendimiento y realizar un seguimiento de si su jefe aprobó la evaluación. Los jefes tendrían acceso a la aplicación mediante un portal para jefes que podría mostrarles una lista de sus empleados con una indicación de si el empleado ya envío un formulario de evaluación del rendimiento y un vínculo para abrir el formulario de evaluación del rendimiento de un empleado. Los profesionales de recursos humanos tendrían acceso a la aplicación a través de un portal para personal de recursos humanos que podría mostrar estadísticas de resumen de la cantidad de formularios de evaluación del rendimiento que se aprobaron, enviaron pero aún no se aprobaron o aún no se enviaron.

El tipo de portal más sencillo de crear es simplemente una vista de la lista o la biblioteca de SharePoint en la que se almacenan las instancias del formulario principal. Puede usar un filtro o aplicar formato condicional para personalizar la vista para el usuario concreto.

También puede diseñar una página web personalizada para cada rol de usuario y dar a cada usuario la dirección URL correspondiente a su rol para tener acceso a la aplicación. En las páginas web del portal, podría incluir algunos de los siguientes elementos:

Un botón Nuevo para crear una nueva instancia del formulario principal.
Una vista de resumen o detalles de instancias del formulario principal. La vista de resumen presentaría una lista de instancias de formulario, filtradas por algunos criterios, y la vista de detalles mostraría los detalles de la instancia de formulario seleccionada en el resumen. Puede crear la vista de resumen mediante el uso de un elemento web Vista de lista o un elemento web Consulta de contenido. Puede crear la vista de detalles al hospedar el formulario principal en el elemento web Formulario de InfoPath. Para obtener más información sobre el elemento web Vista de lista, vea el blog del equipo de Microsoft SharePoint (https://go.microsoft.com/fwlink/?linkid=187653&clcid=0xC0A). Para obtener más información sobre el elemento web Consulta de contenido, vea el tema sobre el procedimiento para personalizar el elemento web Contenido por consulta mediante propiedades personalizadas (https://go.microsoft.com/fwlink/?linkid=187635&clcid=0xC0A). Para obtener más información sobre el elemento web Formulario de InfoPath, vea el procedimiento para hospedar un formulario de InfoPath en el elemento web Formulario de InfoPath (https://go.microsoft.com/fwlink/?linkid=187637&clcid=0xC0A). Puede utilizar un filtro distinto en los portales para roles distintos. Por ejemplo, en el portal para los usuarios que crean nuevas instancias de formulario, podría filtrar por las instancias creadas por el mismo usuario. En un portal para aprobadores, podría filtrar por las instancias pendientes de la evaluación y aprobación del usuario.
Estadísticas sobre el proceso, como la cantidad de instancias de formulario procesadas por día, o medidas relacionadas con el área específica de la aplicación.

Resumen

Si pudo determinar que las características de su aplicación corresponden a la mayoría de las secciones anteriores, es probable que pueda implementar la aplicación siguiendo el paradigma de una aplicación basada en formularios, crear un sitio de SharePoint para hospedar la aplicación, crear una plantilla de formulario para el formulario principal, crear una lista o biblioteca para almacenar instancias del formulario principal y asociar la plantilla de formulario a la lista o biblioteca, agregar un flujo de trabajo que se desencadena cuando se agrega un nuevo formulario a la lista o biblioteca, crear y rellenar las listas adicionales necesarias para proporcionar datos para la plantilla de formulario y crear uno o varios portales a través del cual los usuarios interactúan con la aplicación.