SharePoint Workflow vs Windows Workflow

Ils sont la même chose. Le moteur de Workflow Windows actuel a été créé pour SharePoint.

Il convient de noter que le moteur de flux de travail va être révisé avec la libération de .NET 4.0. Je ne connais pas les détails, mais on m'a dit que les différences sont importantes. Je suppose que cela va être utilisé dans SharePoint 2010, mais je n'ai aucune information à ce sujet.

voici un Lien décrivant la mise à niveau dans 4.0.

SharePoint utilise simplement Windows Workflow Foundation (WF) comme moteur de flux de travail. WF en soi est juste un moteur de flux de travail générique.

Pour utiliser WF, vous devez implémenter un processus d'hôte pour l'exécution des flux de travail et la configurer, de sorte qu'il persiste les instances à la base de données, etc. (ces jours-ci, la plupart des gens utilisent un service WCF en tant qu'hôte de flux de travail, voir ici ou ici ).

SharePoint est livré avec tout déjà configuré et implémente son propre hôte de flux de travail. Vous pouvez donc commencer à utiliser des flux de travail hors de la boîte. En dehors de cela, il est livré avec des activités personnalisées et d'autres goodies spécifiques à SharePoint.

Les flux de travail dans SharePoint sont implémentés à l'aide de la Fondation Windows Workflow, de sorte qu'elles ne sont pas si différentes, mais il y a toujours des choses à prendre conscience de cette mise en œuvre.

SharePoint est un hôte de flux de travail Windows, vous n'avez donc pas à mettre en œuvre votre propre hôte qui va bien si vous êtes d'accord avec les décisions prises par l'équipe SharePoint:

• Les instances de flux de travail sont persistées dans la base de données de contenu
• La communication avec l'utilisateur concerne les tâches SharePoint
• Chaque instance de flux de travail est liée à une liste / de la bibliothèque
• Le suivi n'est pas implémenté

  Si ces choix sont à votre goût, alors par tous les moyens, utilisez les flux de travail SharePoint.

  S'il ne s'agit pas ensuite de votre propre hôte et de prendre vos propres décisions.

Comme indiqué dans d'autres réponses, ils sont les mêmes, car ils utilisent la Fondation Windows Workflow. Cela étant dit, il y a une chose importante à garder à l'esprit lorsqu'il s'agit de flux de travail créés via SharePoint Designer: ils ne sont pas «portables» hors de la boîte, ce qui signifie que vous pouvez créer une liaison à la liste A, puis enregistrer la liste comme Un modèle, puis créez une autre liste sur la base de ce modèle, le flux de travail ne fonctionnera pas (vous l'avez reculer car il fait toujours référence à l'ID de la liste d'origine (GUID).

Vous n'avez pas précisé que vous construisiez une application codée personnalisée dans SharePoint ou configurez une solution hors de la boîte via le navigateur. De toute façon, voici quelques options pour les flux de travail dans SharePoint.

1. Utilisez les flux de travail natifs intégrés à SharePoint et facilement accessibles depuis n'importe quelle liste. Ils sont très basiques (principalement des approbations simples avec une ou deux étapes), mais elles vous mèneront très rapidement et elles peuvent toutes être faites via le navigateur.
2. Utilisez SharePoint Designer pour construire des flux de travail légèrement plus complexes. Cela vous donnera accès à la logique conditionnelle (c'est-à-dire une route d'un flux de travail basé sur une valeur de liste) et des étapes illimitées et un certain nombre d'autres fonctionnalités qui vous permettent d'introduire plus de logique dans le processus. L'inconvénient est que vous devez travailler avec SharePoint Designer qui, pour être franc, peut être une vraie douleur.
3. Code personnalisé vos flux de travail dans WF. Windows Workflow sous-tend les deux premières options qui sont essentiellement des abstractions au-dessus du cadre sous-jacent. La principale différence avec cette approche est que vous n'êtes pas limité aux fonctions que la surface du navigateur ou du SPD. L'inconvénient est que cela devient un processus plus complexe (bien que certes les flux de travail soient probablement plus complexes) et vous devez passer par le rigueur du codage contre SharePoint, les déploiements d'emballage, la publication, etc.

   Je trouve le meilleur équilibre en termes de facilité de développement et de fonctionnalité consiste à essayer de travailler via la liste ci-dessus dans l'ordre que j'ai fourni et ne progressez que dans la prochaine option si vous ne pouvez certainement pas mettre en œuvre l'exigence avec le courant. point.

C'est fondamentalement la même technologie. Si vous en connaissez un, vous pouvez facilement travailler avec / passer à l'autre.

Lorsque vous ajoutez la DLL SharePoint à votre solution, vous obtenez des «activités» SharePoint spécifiques que vous pouvez utiliser dans votre flux de travail. (Créer une tâche, ...)

Votre serveur SharePoint agira en tant qu'hôte pour vos flux de travail.

Le meilleur moyen de déployer un flux de travail dans SharePoint consiste à utiliser une fonctionnalité SharePoint. Cela indique SharePoint ce que DLL (assemblages) à utiliser et quelles pages (saisies) à afficher.

En tant que pages d'entrée, vous pouvez utiliser des pages simples .NET ASPX ou des formes Infopath. Les deux nécessitent un essai et une erreur pour obtenir le suspendre.