Flujo de trabajo Sharepoint frente al flujo de trabajo de Windows

Question

Estamos en el proceso de implementación de la aplicación Sharepoint, nos gustaría saber las ventajas y desventajas del flujo de trabajo de SharePoint versus el flujo de trabajo de Windows.

Answer 1

Son lo mismo. El Windows Workflow Engine actual se creó para SharePoint.

Ahora se debe tener en cuenta que el motor Workflow se revisará con el lanzamiento de .Net 4.0. No sé los detalles, pero me han dicho que las diferencias son importantes. Supongo que esto se va a utilizar en Sharepoint 2010, pero no tengo información sobre eso.

Aquí hay un link que describe la actualización en 4.0.

Answer 2

SharePoint simplemente usa Windows Workflow Foundation (WF) como su motor de flujo de trabajo. WF en sí mismo es solo un motor de flujo de trabajo genérico.

Para utilizar WF debe implementar un proceso de host para la ejecución de flujos de trabajo, y configurarlo para que persiste instancias de base de datos, etc (en estos días la mayoría de la gente utiliza un servicio WCF como una serie de flujo de trabajo, consulte here o here) .

SharePoint viene con todo lo que ya está configurado e implementa su propio host de flujo de trabajo, por lo que puede comenzar a usar flujos de trabajo listos para usar. Aparte de eso, viene con actividades personalizadas y otras ventajas específicas de SharePoint.

Answer 3

Los flujos de trabajo en SharePoint se implementan con Windows Workflow Foundation, por lo que no son tan diferentes, pero todavía hay algunos aspectos que deben tenerse en cuenta con respecto a esa implementación.

SharePoint es un host de Windows Workflow, por lo que no tiene que implementar su propio anfitrión que está bien si usted está de acuerdo con las decisiones tomadas por el equipo de SharePoint:

• instancias de flujo de trabajo se conservan en el contenido base de datos de
• la comunicación con el usuario es a través de tareas de SharePoint
• Cada instancia de flujo de trabajo está ligado a un elemento de lista/biblioteca
• el seguimiento no se implementa

Si estas elecciones son de su agrado, utilice los flujos de trabajo de SharePoint.

Si no, implemente su propio host y tome sus propias decisiones.

Answer 4

Como se indica en otras respuestas, son las mismas, ya que utilizan Windows WOrkflow Foundation. Dicho esto, hay algo importante a tener en cuenta cuando se trata de Workflows creados a través de SharePOint Designer: no son "portátiles" de fábrica, lo que significa que puede crear uno para listar a, luego guardar la lista como una plantilla y luego crear otra lista basada en esa plantilla, el flujo de trabajo NO funcionará (lo ha vuelto a vincular ya que aún está haciendo referencia al ID de la lista original (guid).

Answer 5

No ha especificado si está creando un aplicación codificado personalizada en SharePoint o la configuración de un fuera de la solución de caja a través del navegador. de cualquier manera, aquí hay algunas opciones para los flujos de trabajo en SharePoint.

1. uso los flujos de trabajo nativos integrados en SharePoint y fácilmente accesible desde cualquier lista.Son muy básicos (en su mayoría, aprobaciones simples con uno o dos pasos), pero lo pondrán en funcionamiento rápidamente y todo puede hacerse a través del navegador.
2. Use SharePoint Designer para crear flujos de trabajo un poco más complejos. Esto le dará acceso a la lógica condicional (es decir, enrutar un flujo de trabajo en función de un valor de lista) y pasos ilimitados y una cantidad de otras características que le permiten introducir más lógica en el proceso. La desventaja es que tiene que trabajar con SharePoint Designer que, para ser franco, puede ser un verdadero dolor.
3. Código personalizado de sus flujos de trabajo en WF. Windows Workflow subyace a las dos primeras opciones, que son esencialmente abstracciones en la parte superior del marco subyacente. La principal diferencia con este enfoque es que no está limitado a las funciones que surgen en el navegador o el SPD. La desventaja es que esto se convierte en un proceso más complejo (aunque es cierto que los flujos de trabajo probablemente será más complejo) y usted tiene que pasar por el galimatías de codificación en contra de SharePoint, los despliegues de embalaje, publicación, etc.

encuentro la El mejor equilibrio en términos de facilidad de desarrollo y funcionalidad es intentar trabajar a través de la lista anterior en el orden que les proporcioné y avanzar solo a la siguiente opción si definitivamente no puede implementar el requisito con el punto actual.

Answer 6

Básicamente es la misma tecnología. Si conoce uno, puede trabajar fácilmente con/cambiar al otro.

Cuando agrega el dll de SharePoint a su solución, obtiene algunas 'actividades' específicas de SharePoint que puede usar en su flujo de trabajo. (create task, ...)

Su servidor de SharePoint actuará como host para sus flujos de trabajo.

La mejor forma de implementar un flujo de trabajo en SharePoint es mediante el uso de una función de SharePoint. Esto le dice a SharePoint qué dll (ensambles) usar y qué páginas (de entrada) mostrar.

Como páginas de entrada puede utilizar páginas .net aspx simples o formularios infopath. Ambos requieren un poco de prueba y error para entenderlo.