Bonnes pratiques de packaging des SmO SharePoint

L’architecture d’intégration de K2 avec SharePoint a beaucoup évolué lors de la sortie de SharePoint 2013, il faut donc un peu changer ses habitudes et il est conseillé de ne plus packager ses intégrations SharePoint de la même manière qu’avec SharePoint 2010 . Nous allons donc voir dans ce billet quelles sont les bonnes pratiques de création des SmO K2 pour SharePoint afin de pouvoir les packager et les déployer sans difficulté.

Les méthodes décrites dans ce billet sont valables pour SharePoint 2013, SharePoint 2016 et SharePoint Online.

La problématique

La problématique principale est la suivante : l’instanciation du service broker pour SharePoint se fait depuis l’app K2 pour SharePoint, or il n’est pas possible d’y maîtriser les GUID qui sont automatiquement générés (et il n’est pas supporté de les modifier manuellement comme on peut le faire avec d’autres service brokers, voir le billet sur le bon usage des connecteurs SharePoint, abordant ce point). Ainsi pour des objets équivalents sur 2 environnements différents, nous obtiendrons forcément des GUID différents, ce qui peut nous causer du souci lors du passage d’un environnement à l’autre. Bien que l’outil P&D tente des réconciliations automatiques en se basant sur les system names des objets SharePoint, il peut arriver de devoir faire de la réconciliation manuelle lors du déploiement et ceci ouvre la porte à des erreurs d’étourderie.

A ceci, peut se rajouter le cas particulier de nos clients O365 qui, dans la majorité des cas, vont avoir un seul tenant et une multitude de collections de sites jouant les rôles « d’environnements » de développement, recette, intégration, production alors que sur une infrastructure on-premises nos clients vont avoir autant de serveurs SharePoint que de serveurs K2 (la distinction entre environnements étant dans ce cas liée au serveur et non à la collection de sites, cela rend d’autant plus ardue la tâche de réconciliation automatique par l’outil de déploiement de K2).

Voici schématiquement les 2 cas de figure (un schéma est toujours plus parlant) :

Cas d'environnements on-premises VS cas d'environnements online
Cas d’environnements on-premises VS cas d’environnements online

Les bonnes pratiques

Alors pour éviter les réconciliations manuelles, l’idée est de ne pas utiliser les smartobjects générés par défaut et donc de créer ses propres smartobjects afin d’avoir le maximum d’objets dans votre package dont vous maîtrisez le GUID. Cela vous obligera, mais ce n’est pas un mal, à paramétrer uniquement les méthodes et propriétés dont votre application aura besoin (et non pas tout embarquer, sans vraiment savoir ce que cela inclue).

Pour illustrer ceci, nous allons prendre 2 exemples :

  1. Exposition d’une liste SharePoint (la liste EnK2Besoin).
  2. Exposition de la liste des utilisateurs d’un groupe SharePoint.

Après avoir créé la liste EnK2Besoin sur le site SharePoint, on va l’exposer pour utilisation dans K2 en cliquant sur le menu K2 > Application (1), puis en choisissant Create New Application (2) puis enfin en cliquant sur OK sur le dernier écran (3), sans créer de formulaires ou de processus.

(1)
(1)

(2)
(2)

(3)
(3)

Tous les objets et méthodes SharePoint dont nous avons besoin pour notre exemple sont donc exposés et on les retrouve dans notre explorateur de smartobjects… :

Visualisation des objets dans le smoST++
Visualisation des objets dans le smoST++

… mais l’idée est donc de ne pas les utiliser directement et d’en créer des spécifiques pour notre application, se basant sur les méthodes de SvO disponibles.

Création des objets K2

Il suffit alors de créer des smartobjects avancés et de sélectionner la méthode et les propriétés qui vous intéressent parmi celles exposées nativement :

Pour la liste enK2Besoin :

Créer un smo avancé
Créer un smo avancé

Sélectionner la méthode depuis le SvO Sharepoint
Sélectionner la méthode depuis le SvO Sharepoint

Créer les propriétés nécessaires
Créer les propriétés nécessaires

Et voilà
Et voilà

Pour la récupération des utilisateurs provenant d’un groupe SharePoint (même étapes que pour la liste précédente, il faut juste aller chercher la méthode de SvO Group>Get Users for Group, disponible dans la catégorie Management) :

Choisissez la méthode de SvO
Choisissez la méthode de SvO

Créez les propriétés nécessaires
Créez les propriétés nécessaires
Packaging

Ensuite, utilisons les objets qui viennent d’être créés dans des vues et forms K2 (dans mon cas, j’ai créé un form qui utilise une vue contenant 2 listes déroulantes qui utilisent nos smo comme source de données). Puis packageons avec P&D :

Sélectionner les objets à packager
Sélectionner les objets à packager

Contenu du package
Contenu du package
Déploiement

Il ne reste plus qu’à déployer sur le serveur cible.

Avant de s’occuper du package K2, commençons par créer ou déployer le contenu SharePoint nécessaire (dans notre cas, la liste EnK2Besoin). Ensuite, bien évidemment, il faut s’assurer que l’app K2 for SharePoint est bien déployée sur le collection de sites et activée sur le site cible.

On peut alors ouvrir notre package K2 avec l’outil P&D, puis lors de déploiement, afin de ne pas encombrer votre serveur cible avec des objets inutiles, vous pouvez décocher les objets qui ne sont pas directement dans votre catégorie (tout ce qu’il y a sous SharePoint 2013 dans mon cas), puis ensuite recocher les éléments qui ont été automatiquement décochés à l’intérieur de votre catégorie, comme on peut le voir sur la copie d’écran ci-dessous. Cela vous assure de n’embarquer que les objets directement utiles :

Eléments à déployer
Eléments à déployer

En espérant que cela vous aide à déployer plus rapidement 

Happy K2ing!

jean

Directeur technique de K2 France depuis 2006 et passionné par les technologies, je travaille dans le monde du BPM et des applications métier depuis... que je travaille :). Vous pouvez également me suivre sur twitter, linkedin.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *