Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

The Mit's Blog

En plus d'intégrer et skier, il sait même écrire !
(Blog de Renaud Comte)

Actualités


  • Ancien MVP SharePoint 8 ans ...
    Des projets .Net, SharePoint 2013 ou Office 365 ??

    Contactez-nous :

Archives

Des activités métiers pour vos Workflows SharePoint Designer : une bonne technique

La conception et le développement de workflow sous SharePoint peut des fois donner le sentiment d'un bon match de lutte greco romaine (j'essaye d'être en phase avec l'actualité smile_regular )

Quelque soit la difficulté des WF qui nécessite de bien comprendre la notion de custom list/form/feature et content type ainsi que les spécificités de WF, il faut accepter qu'un Workflow reste et sera toujours une véritable application métier. Pas un simple traitement de données landa.
==> il faut l'envisager dans son ensemble !

...

Mais tous les besoins de workflow ne sont pas tous complexes et fondamentales. Vous pouvez avoir besoin de traitement automatisé comme :

  • annonce des validations
  • remonté et fédération d'information
  • déploiement de document sur création
  • suivi fin des taches
  • ...
  • ...

Je dirais des workflows plus ciblés utilisateurs que méthodologies et processus entreprises. Des enchaînements plus simple et souvent changeant (disons évolutif).  Des cas ou même les utilisateurs aimeraient être plus autonomes et indépendant d'une équipe de Dev

Plutôt que sortir votre VS.Net le Nabaztag qui suit (demandé à Phil, il expliquera smile_tongue), SharePoint Designer peut très bien répondre aisément et rapidement

 Workflow Screen 1

On est d'accord mais il faut bien accepter que SPD est limité à un petit choix d'options :

  • séquentiel
  • action locale
  • paramétrage léger

Cependant, conception, réalisation et déploiement sont d'une simplicité enfantine !
>>> Un formidable générateur de XOML (XAML mais dédié WF)

Il existe une technique bien pratique et commune pour améliorer les scenarii d'utilisation de SPD avec les Worflows
>>> intégrez vos propres activités personnelles ! (ou custom activity)

Ainsi, vous avez une jolie solution :

  • la flexibilité et la simplicité de SPD
  • la puissance du .Net dans les activités

Nota bene

Pour ceux qui suivent la technologie SharePoint + Workflow, ce post n'est pas une nouveauté certes, mais ce n'est pas le cas de tous. Mais comme cette technique me semble être désormais un classique, il est bon de la faire connaître

 

Comme SPD s' appuie exclusivement sur le code déclaratif XOML pour créer ses workflows, rien ne vous empêche d' inclure dedans vos propres références à des activités "custom" !

Mieux que cela, vous pouvez aussi intégrez ces "custom activity" directement dans l'interface de création de SPD

Des lors, vous pouvez intégrer dans une simple DLL, toutes les spécificités d'action que vous avez besoin et les utilisez d'un claquement de doigt depuis un interface SPD.

Mieux que ça encore, vous pouvez créer toutes une famille d'activité réutilisable entre vos grands WF entreprise et le panel de choix de SPD. Sous entendu, mutualiser et factoriser le travail de dev jusqu'au niveau des "super utilisateurs" qui peuvent créer tout seul les workflow locaux

Pratique non ? SURE !

Si vous vous sentez de tester ASAP cette technique, voici quelques liens qui sauront vous ravir !!!

 

Allez, bon développement à tous !

Oh dernière remarque : SPD n'est pas l'alpha et l'omega du workflow
>>> Si vous commencez à avoir quelques centaines d'instance de WF via SPD, il serait peut être temps de penser à les modéliser en pur WF + SP.
(Fabrice , tu vois ce que je veux dire non ?)

Renaud Comte aka TheMit (un peu de WF de temps à autre, ça change)
Member of WygTeam
http://www.wygwam.com

Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
Posted: jeudi 14 août 2008 11:23 par themit

Commentaires

phil a dit :

"Plutôt que sortir votre VS.Net le Nabaztag qui suit (demandé à Phil, il expliquera smile_tongue)..."

Plutôt que de longues explications : http://www.woodwardweb.com/gadgets/000434.html

:)

# août 14, 2008 14:28

ROMELARD Fabrice a dit :

Personnellement, je déconseille ouvertement SPD pour les créations de WorkFlow.

Ce produit ne doit être utilisé que dans le cadre de modélisation, maketage, simulation, ...

Mais surtout jamais de production.

En effet, le cas classique est celui ou le WF créé avec SPD fonctionne un moment et habitue les utilisateurs, puis d'un coup sans raison tout s'arrête. Aucun message d'erreur nulle part, aucune raison particulière, mais tout est bien stoppé.

- Exemple : http://forums.microsoft.com/MSDN-FR/ShowPost.aspx?PostID=3708296&SiteID=12

La seule solution est de tout supprimer et tout recréer, mais des questions se posent alors :

- Comment expliquer aux utilisateurs qu'ils ont perdu toutes les étapes en cours ?

- Comment dire à ces mêmes utilisateurs que la solution développée peut casser à tout moment ?

- Comment ne pas dégrader l'image de la plateforme SharePoint à cause de la fiabilité pitoyable de ce produit ?

Bref, il faut vraiment réfléchir à cela avant de se lancer dans ce type d'aventure et de s'y casser les dents.

Romelard Fabrice [MVP]

# août 14, 2008 14:29

phil a dit :

Plus sérieusement, je suis pas fan non plus de l'utilisation de SPD pour les workflows pour les mêmes raisons que fabrice.

C'est pratique pour des POC par contre.

# août 14, 2008 14:35

ROMELARD Fabrice a dit :

Pour appuyer mon avis, nous avons eu une ferme SharePoint (Ferme WSS V3 des US avec plus de 10 000 Users) qui s'est mise a partir en vrille d'un coup (sans aucune raison) à cause de WF SPD avec Custom Activities alors que tout marchait bien peu avant.

La solution avant de totalement supprimer ce WF était de faire un IISRESET de cette ferme toutes les 30 à 60 min, car on avait un Error 500 qui apparaissait.

Donc ce n'est vraiment pas parce que je suis fan de VS, mais réellement parce que le résultat des WF sous SPD est réellement "sal" et sans aucun contrôle.

Romelard Fabrice [MVP]

# août 14, 2008 14:45

themit a dit :

Et voila, je savais que le feedback arriverait en temps et en heure

Merci Phil et Fabrice de la contribution

J'ai cependant une question : Vu que SPD génére du XOML pour son WF, en quoi est il plus "different" d'un WF pure VS ?

Humhum

Renaud

# août 14, 2008 14:55

ROMELARD Fabrice a dit :

A mon sens le XOML généré par VS et celui de SPD doivent différer.

De plus ce XOML de SPD n'est pas généré réellement dans des fichiers physiques, mais se voit directement stockés en DB (au niveau de la collection de site, ce qui explique en partie pourquoi un WF de SPD est spécifique à un site et une collection).

Lorsqu'on ouvre un XOML de SPD et qu'on le compare avec celui d'un VS, les grandes différences qui sautent aux yeux :

- Bloc XML de départ différents "RootWorkflowActivityWithData" pour SPD, "SequentialWorkflowActivity" dans les WF Sequentiels de VS

- Pas de possibilité de mettre de code C# dans les WF SPD, donc pas d'utilisation des MethodInvoking="xxxxx" pour les composant VS

- Fixation en dur des GUID des listes SharePoint utiliées pour le WF SPD <ns0:LookupActivity ListId="{}{E81BF4FB-E5FA-4DBB-9315-B63E7ADC5315}" ....

Bref à voir si en changeant ces premiers points on arrive à s'en sortir, mais je me demande si ca ne risque pas de faire perdre plus de temps que d'en gagner.

Romelard Fabrice [MVP]

# août 14, 2008 15:52

phil a dit :

C'est vrai qu'il est possible de migrer le WF fait avec SPD vers VS mais il n'existe pas de guideline officielles à ce sujet à ce sujet.

Et pour l'avoir fait de nombreuses fois, sans être difficiles, ce n'est pas très friendly...

Mon plus gros problème est justement le déploiement : Effectivement il est très simple de déployer un WF via SPD mais que ce passe t il dès qu'on veut utiliser le même WF sur une autre liste/site/etc...

J'ai un facheuse tendance à limiter l'utilisation de SPD en environnement de développement pour Masterpage, Layout voire cas extrème WF (quand ils sont ultra simples) pour après exporter le tout dans une solution (WSP) proprement par la suite.

Mais bon je sais qu'on fait tous pareil :)

# août 14, 2008 19:49

davidrei a dit :

Autre solution...

On sort tous notre portefeuille et on achète des licences K2 BlackPoint .. :D :D :D

Un vrai moteur de WF :) N'importe quel End-User ayant un minimum de connaissance des processus métiers peut modéliser son WF.

http://blackpoint.k2.com/en/index.aspx

Amicalement,

# août 15, 2008 18:09

ROMELARD Fabrice a dit :

Il existe d'autres produits tiers permettant de créer des WF dans SharePoint, certains plus ou moins intégrés :

- NINTEX (parfaitement intégré à SharePoint 2007)

- WorkFlow Gen (permettant de travailler avec des interfaces 2003 ou 2007 ou même sans SharePoint)

Donc, il n'existe pas que K2 :)

Fabrice

# août 15, 2008 20:03

davidrei a dit :

Certes, et dans la foulé, il existe aussi Skelta :)

Pour moi Nintex n'est pas parfaitement intégré à Sharepoint. Dés que tu veux avoir des activités qui utilisent les résultats du service de recherche, "out of the box" c'est impossible. Il manque aussi des connecteurs comme celui à SAP de K2. D'autre part, le déploiement d'une solution Nintex ne peut s'affecter à un content type particulier dans Sharepoint.

Je dis ça sans avoir d'action à K2 :p .. si si !

David

# août 15, 2008 22:50

Chgog a dit :

Bonjour,

Je me permets de donner mon avis sur SPD.

Nous avons récemment lancé un workflow, selon moi peu complexe, mais qui nécessitait des évolutions facilement réalisables par des personnes "non expérimentés", d'où l'utilisation de SPD.

Le prototype s'est bien déroulé mais depuis la mise en production, nous nous sommes rendus à l’évidence: SPD ne tient pas du tout la charge.

Certains Workflows tombent en erreur sans raison apparente, et beaucoup de nos tâches restent éternellement verrouillés. (Après l’ouverture d’un case ms support, il s’est avéré que ces tâches verrouillées sont une conséquence des erreurs de workflow, non résolues à ce jour). Un expert Microsoft a analysé notre workflow et nous a confirmé qu'il était dans les bonnes pratiques, à l’exception de notre bibliothèque de documents qui contient les Workflows qui excède les 2000 éléments (4000 dans notre cas).

Bref, cette expérience nous donne une mauvaise image du produit, qui selon moi, possède de très gros atouts.

# septembre 17, 2008 15:38
Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- Merci par Blog de Jérémy Jeanson le 10-01-2019, 20:47

- Office 365: Script PowerShell pour auditer l’usage des Office Groups de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 11:02

- Office 365: Script PowerShell pour auditer l’usage de Microsoft Teams de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 10:39

- Office 365: Script PowerShell pour auditer l’usage de OneDrive for Business de votre tenant par Blog Technique de Romelard Fabrice le 04-25-2019, 15:13

- Office 365: Script PowerShell pour auditer l’usage de SharePoint Online de votre tenant par Blog Technique de Romelard Fabrice le 02-27-2019, 13:39

- Office 365: Script PowerShell pour auditer l’usage d’Exchange Online de votre tenant par Blog Technique de Romelard Fabrice le 02-25-2019, 15:07

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Stream Portal par Blog Technique de Romelard Fabrice le 02-21-2019, 17:56

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Video Portal par Blog Technique de Romelard Fabrice le 02-18-2019, 18:56

- Office 365: Script PowerShell pour extraire les Audit Log basés sur des filtres fournis par Blog Technique de Romelard Fabrice le 01-28-2019, 16:13

- SharePoint Online: Script PowerShell pour désactiver l’Option IRM des sites SPO non autorisés par Blog Technique de Romelard Fabrice le 12-14-2018, 13:01