Configuration pour développer une APPs sur VOTRE SharePoint 2013

 

Cet article s’adresse aux développeurs qui ont entendu parler du nouveau modèle de développement proposé par SharePoint 2013, les APPs, et qui souhaitent configurer un serveur pour être à même de développer et tester de tels types d’applications.

 

En quelques mots :

 

Ce modèle permet de créer des applications web qui communiquent avec un site SharePoint 2013, sans forcément être hébergées / exécutées sur celui-ci. C’est en quelque sorte une extension de la notion d’application “SandBoxed”. La communication entre l’APPs et le SharePoint se faisant essentiellement à l’aide de web services.

 

SharePoint 2013 propose 3 types d’APP :

 

– Provider Hosted : votre APP est un site web hébergé par vos soins ou celui d’un hébergeur tiers et communique avec votre SharePoint ou un site Office 365.

 

– Auto Hosted : votre APP est un site web hébergé sur Windows Azure et communique avec votre SharePoint ou un site Office 365

 

– SharePoint Hosted : votre APP est un site web hébergé dans votre SharePoint (ou site Office 365) et communique avec celui-ci via l’API client en JavaScript uniquement.

 

Dans cet article je vais vous donner les étapes indispensables pour configurer un serveur SharePoint 2013 afin de pouvoir commencer à développer des APPs et de les héberger, que ce soit des “Provider Hosted” ou “SharePoint Hosted”.

 

Je n’aborderai pas la configuration pour utiliser un site Office 365 ou encore pour utiliser Azure. Nous ferons donc du “On-Premises” comme on dit…

 

Je récapitule donc l’objectif de l’environnement via un petit schéma:

 

image

 

Sommaire

1- Prérequis

2- Configuration “On Premises”

3- 1ère Application “SharePoint Hosted”

4- Configuration “High Trust”

5- 1ère Application “Provider Hosted”

1 – Prérequis :

Il vous faut une machine (machine virtuelle très souvent) avec la configuration suivante :

– 2 ou 4 processeurs

– 4, 8, 16 Go de RAM !… plus vous en aurez, mieux ça passera ! Clairement avec 4Go c’est un peu limite…

– Windows Server 2008 R2 x64 (je n’ai pas testé avec Windows Server 2012 mais y a pas de raisons pour que ça marche pas)

– SQL Server 2008 R2 ou 2012 (là j’ai testé SQL 2012, ça passe sans soucis)

– SharePoint Server 2013 Public Preview

– Visual Studio 2012 et les “Office Developer Tools for Visual Studio 2012” (les modèles de projets SharePoint 2013…)

 

Il vous faudra aussi un contrôleur de domaine sur lequel vous pourrez joindre votre serveur. En général j’utilise une petite VM (mono proc, 512Mo de RAM) ça suffit…

 

Je ne vais pas aborder l’installation de Windows Server ni même SQL Server, je pense que vous qui me lisez connaissez ou trouverez bien comment faire ces étapes.

 

Concernant l’installation de SharePoint 2013 (ça n’a pas beaucoup changé depuis la 2010 de ce point de vue) ATTENTION tout de même :

– Il nous faudra une version Server et pas foundation car le service de UserProfile est nécessaire et n’est pas inclus dans la version foundation

– dans cette version (1ère béta publique), le développement ne fonctionne que si votre installation est une installation en mode “complète” !

 

image

 

Pensez à choisir judicieusement le compte avec lequel vous ferez toutes ces installations, ce doit être un compte de domaine qui vous servira aussi pour faire le développement et déployer vos APPs, mais ce doit être un compte différent de celui utilisé comme compte de la ferme (celui que vous renseignez dans le wizard d’installation et qui fait tourner le service timer et la central admin).

Si vous suivez les bonnes pratiques habituelles vous ne devriez pas avoir de soucis, en résumé évitez de tout faire avec juste un compte administrateur !

 

Enfin, il vous faudra une première Web Application avec une collection de site basée sur le modèle de site “Developer Site”. Vous devez passer par ce type de site pour vos déploiements. Là encore, ça se passe comme sous SharePoint 2010 via le site de Central Admin :

 

image

 

2- Configuration “On Premises”

A ce stade on a en principe ce qu’il faut pour commencer à développer nos APPs. Oui, mais Non…

 

Pour des APPS de type “Provider Hosted”, il faut configurer le mode “High Trust” ! C’est l’objet des chapitres 4 et 5 de cet article.

 

Pour des APPs de type “SharePoint Hosted”, nous avons besoin de créer un sous domaine dédié à l’hébergement de celles-ci. C’est bien votre site SharePoint qui fait tourner les pages de votre APPs, mais il le fait sur un domaine “virtuel” qu’il doit connaitre.

Par exemple mon site SharePoint tourne sur l’url http://sp2013Paslatek.Paslatek.com, je vais donc configurer le domaine de mes APPS pour avoir le nom *.APPS.SP2013Paslatek.Paslatek.com et un nom de “Tenant” qui sera “Paslatek”

Ainsi à chaque APPs que je déploierai, SharePoint me génèrera un id unique et créera une URL en combinant l’id, le tenant et le nom de domaine dédié, par exemple :

http://Paslatek-abcd1234.APPS.SP2013Paslatek.Paslatek.com

 

Donc il faut configurer l’application de service qui est en charge de l’hébergement de ces « SharePoint Hosted APPS » et pour cela rien de mieux qu’un peu de PowerShell !

 

ATTENTION : le script suivant est à lancer avec un compte admin de la ferme (et en clic droite / exécuter en tant qu’admin)

 

ATTENTION Bis : Avant de lancer le script suivant, il faut que vous vérifiiez qu’il n’y a pas déjà d’application de service de type “APP Management” qui tourne sur votre SharePoint. Si c’est le cas, supprimez-la au préalable.

 

image

 

Le script à exécuter :

 1: net start spadminv4

 

 2: net start sptimerv4

 

 3: Set-SPAppDomain "APPS.SP2013Paslatek.Paslatek.com"

 

 4: Get-SPServiceInstance | where{$_.GetType().Name -eq "AppManagementServiceInstance" -or $_.GetType().Name -eq "SPSubscriptionSettingsServiceInstance"} | Start-SPServiceInstance

 

 5: Get-SPServiceInstance | where{$_.GetType().Name -eq "AppManagementServiceInstance" -or $_.GetType().Name -eq "SPSubscriptionSettingsServiceInstance"}

 

 6: $account = New-SPManagedAccount

 

 7: $account = Get-SPManagedAccount "domain\user"

 

 8: $appPoolSubSvc = New-SPServiceApplicationPool -Name SettingsServiceAppPool -Account $account

 

 9: $appPoolAppSvc = New-SPServiceApplicationPool -Name AppServiceAppPool -Account $account

 

 10: $appSubSvc = New-SPSubscriptionSettingsServiceApplication –ApplicationPool $appPoolSubSvc –Name SettingsServiceApp –DatabaseName SettingsServiceDB

 

 11: $proxySubSvc = New-SPSubscriptionSettingsServiceApplicationProxy –ServiceApplication $appSubSvc

 

 12: $appAppSvc = New-SPAppManagementServiceApplication -ApplicationPool $appPoolAppSvc -Name AppServiceApp -DatabaseName AppServiceDB

 

 13: $proxyAppSvc = New-SPAppManagementServiceApplicationProxy -ServiceApplication $appAppSvc

 

 14: Set-SPAppSiteSubscriptionName -Name "Paslatek" -Confirm:$false

 

– A la ligne 3 : Remplacez avec le nom d’hôte de votre choix

– A la ligne 6 : Un compte vous sera demandé, utilisez un compte de domaine. C’est celui qui fera tourner vos APPs. Généralement un compte de domaine dédié à cela.

– A la ligne 7 : Remplacez ‘”domain\user’” par le compte que vous aurez renseigné à la ligne 6

– A la ligne 8 et 9 vérifiez que vous n’avez pas déjà des pools de ces noms

– A la ligne 14 : Remplacez “Paslatek” par le nom de tenant de votre choix

 

3- 1ère Application “SharePoint Hosted”

Nous avons ce qu’il faut pour le premier type d’hébergement : “SharePoint Hosted”.

– Lancez Visual Studio 2012 et créez un nouveau projet SharePoint 2013 / SharePoint APP :

 

image

 

 

– Renseignez le site pour le déploiement : ce doit être le site qui utilise le modèle “Developer site” créé au chapitre précédent.

 

image

 

– Exécutez la solution : Visual Studio va déployer votre application et modifier votre fichier host pour faire correspondre le nom de domaine de votre application (par exemple http://Paslatek-abcd1234.APPS.SP2013Paslatek.Paslatek.com) sur l’IP 127.0.0.1

 

La page “site content” qui permet de lancer l’application :

image

 

La page de l’application :

image

 

 

Principe de fonctionnement de l’application :

 

Un seul projet est créé. Il embarque à la fois les fichiers nécessaires à la déclaration de l’APP au sein du site SharePoint (la feature donc) et les pages, images, et scripts que vous allez embarquer dans votre application web.

 

Ce type d’application ne fonctionne qu’avec le modèle objet client de SharePoint en JavaScript : CSOM (Client Side Object Model). Le projet par défaut propose donc d’avoir une première page aspx, qui charge un fichier JavaScript et branche un évènement de type “Document Ready” sur une 1ère fonction.

Celle-ci va charger le CSOM et à son tour (une fois prêt) va appeler votre fonction “sharePointReady” qui se trouve dans le fichier “Scripts/APP.js”. C’est notre point d’entrée !

 

La structure du projet :

image

 

Vous remarquerez l’absence de “code-behind” pour la page aspx…

 

Le contenu de Default.aspx :

image

 

Ce n’est ni plus ni moins qu’une page de webparts. On y retrouve le ContentPlaceHolder principal et un paragraphe avec un id pour changer le contenu par script.

 

La gestion du branchement de vos scripts dans Default.aspx :

image

 

On demande à SharePoint de charger sp.js et d’exécuter la fonction SP.ClientContext qui permet d’initialiser la classe ClientContext, le cœur du modèle objet client, enfin il exécute notre fonction d’init.

 

Le fichier APP.js :

image

 

A partir de là vous n’avez plus qu’à compléter l’application par votre interface en html et le pilotage du contenu par des appels JQuery et/ou Modèle objet client SharePoint et/ou services REST fournis par SharePoint (et/ou autres services web fournis par des tiers aussi bien sûr). Par exemple l’affichage des listes du site courant avec le CSOM :

 

Le JavaScript:

1: function getListOfLists() {

 

 2:

 

 3:     collList = web.get_lists();

 

 4:

 

 5:     context.load(collList);

 

 6:

 

 7:     context.executeQueryAsync(onGetListsSuccess, onGetListsFail);

 

 8: }

 

 9:

 

 10: function onGetListsSuccess() {

 

 11:

 

 12:     $("#tableOfLists").empty();

 

 13:

 

 14:     var tableHeader = "<thead>" +

 

 15:                       "<th>Titre</th>" +

 

 16:                       "<th>Date de cr&eacute;ation</th>" +

 

 17:                     "</thead>";

 

 18:

 

 19:     var table = $("<table>", { id: "listsTable" }).append($(tableHeader));

 

 20:     for (var i = 0; i < collList.get_count() ; i++) {

 

 21:         var item = collList.itemAt(i);

 

 22:         var line = "<tr>" +

 

 23:                             "<td>" + item.get_title() + "</td>" +

 

 24:                             "<td>" + item.get_created() + "</td>" +

 

 25:                           "</tr>";

 

 26:

 

 27:         table.append($(line));

 

 28:     }

 

 29:

 

 30:     $("#tableOfLists").append(table);

 

 31: }

 

 32:

 

 33: function onGetListsFail(sender, args) {

 

 34:     alert('Failed to get lists. Error:' + args.get_message());

 

 35: }

 

 

Le résultat:

image

 

L’objectif de cet article n’étant pas de vous faire découvrir CSOM ou l’API REST mais de vous donner les éléments nécessaires pour vous y mettre ! Je n’irai donc pas plus en détail sur ce sujet.

 

4- Configuration “High Trust”

C’est un bon départ mais ce n’est pas forcement là où ce modèle d’APP est le plus intéressant. En effet l’idée principale, à mon sens, est surtout de vous fournir un moyen simple d’intégrer des applications “Legacy” à votre intranet SharePoint.

 

Donc des applications web existantes, avec du code-behind, qui seront plus facile à porter en ASP qu’à intégrer à SharePoint sous la forme “traditionnelle” de pages d’applications et de webparts. Ce sont donc les APP “Provider Hosted”. Ceci dit, je ne dis pas non plus que ce modèle est uniquement fait pour ce type d’applications…

 

Comme je l’indiquais plus haut, ce mode d’hébergement “On Premises” (sur votre serveur) n’est pas supporté sans configurer le mode High Trust. C’est à dire que nous allons indiquer au serveur SharePoint quelle application est autorisée à discuter avec lui et qu’il peut lui faire confiance jusqu’à un niveau déterminé.

 

Sur le principe les étapes de configuration sont les suivantes:

 

– Création d’un certificat public/private : ce certificat sera utilisé pour authentifier vos applications web distantes avec le serveur SharePoint

– Création d’un identifiant client unique : cet identifiant, associé au certificat, permettra d’identifier votre application. Il en faudra donc un différent pour chaque application

– Enregistrer l’association certificat / client id dans le service “App Managment” de SharePoint

– Et quelques autres petites configurations…

 

Pour plus de détails vous pouvez lire la procédure décrite ici (en anglais) mais si vous voulez aller plus vite, Andrew Connell fourni un script PowerShell ici qui permet de réaliser toutes ces étapes SAUF la génération des certificats.

Pour cette étape nous utilisons le serveur IIS pour générer un certificat “Self Signed”. Pour cela vous pouvez vous référer à cette partie-là de l’article MSDN.

Bien sûr dans la vrai vie vous serez amenez à utiliser des certificats issus d’autorités de confiance…

 

Pour plus de simplicité je me permets de mettre ce script à disposition ici. Son utilisation est relativement triviale. Vous devez lui fournir à minima en paramètres :

 

– un nom d’application

– l’url du site sur lequel vous comptez déployer l’APP. Donc la collection de site utilisant le modèle “Developer Site” créé au chapitre précédent

– le chemin du certificat

 

Par exemple:

image

 

Si tout se passe bien vous devriez obtenir un résultat de ce type :

 

image

 

Nous verrons dans le dernier chapitre comment utiliser ces informations (l’id client par exemple) dans l’application “Provider-Hosted”.

 

Ceci dit, il reste 2 prérequis avant de vous lancer dans le développement à proprement dit :

 

– Premier prérequis, il faut importer votre certificat (le cer) dans le magasin de certificats de votre serveur, dans les autorités racine de confiance (Trusted Root Certification Authorities):

– Lancez une console mmc

– Ajoutez l’addin “certificats” pour l’ordinateur local

– Sélectionnez le bon magasin, puis clic droite, puis importer

– Sélectionnez le fichier “cer” généré

image

– terminez l’assistant

image

 

A terme ces certificats doivent être déployés de la façon suivante :

– le pfx côté application web, donc chez votre provider

– le cer sur le serveur SharePoint

Dans mon cas, le même serveur joue les 2 rôles.

 

Second prérequis, chaque utilisateur qui devra accéder à notre application devra être présent dans les UserProfiles de votre serveur SharePoint. Si vous n’avez pas de synchronisation en place, passez par la page d’administration de l’application de service “User Profile” puis la page de gestion des profils utilisateurs. Ici vous pouvez ajouter manuellement les utilisateurs que vous utiliserez pour tester votre application :

 

image

 

5- 1ère Application “Provider Hosted”

Nous sommes maintenant prêts pour ce dernier chapitre, concernant notre 1ère APP “Provider Hosted”

– Lancez Visual Studio 2012 et créez un nouveau projet SharePoint 2013 / SharePoint APP

– Renseignez le site pour le déploiement : ce doit être le site qui utilise le modèle “Developer site” créé au chapitre précédent.

 

image

 

Principe de fonctionnement de l’application :

 

Cette fois ci vous constaterez que la solution Visual Studio contient 2 projets :

– le projet APP pour SharePoint, qui contient essentiellement un fichier AppManifest.xml

– le projet ASP.Net qui va héberger votre site / APP, sur IIS Express le temps de développer.

 

Avant d’exécuter la solution, des modifications sont à faire sur le code par défaut, en particulier concernant l’initialisation de la classe ClientContext afin d’utiliser un canal S2S, une communication sécurisée, entre notre application web et le site SharePoint.

 

– Modifiez le fichier web.config de votre application pour lui indiquer le chemin du certificat ainsi que le mot de passe utilisé lors de la génération de ce certificat en ajoutant les 2 clés d’AppSettings suivantes :

 1: <add key="ClientSigningCertificatePath" value="C:\HighTrustSampleCert.pfx" />

 

 2: <add key="ClientSigningCertificatePassword" value="password" />

 

– Toujours dans le fichier web.config, indiquez l’id client unique obtenu lors de l’exécution du script PowerShell au chapitre précédent :

 

image

 

– Modifiez le fichier AppManifest.xml (dans le projet SharePoint, clic droite / edit code) pour y indiquer aussi l’identifiant client

image

 

– Cette fois-ci la page Default.aspx contient du « Code-Behind », ouvrez le fichier Default.aspx.cs puis modifiez le code d’initialisation du ClientContext, la version par défaut du code de la page Default n’utilise pas un canal S2S, cependant la classe utilitaire TokenHelper nous fournit une méthode pour initialiser un tel type de canal :

 1: protected void Page_Load(object sender, EventArgs e)

 

 2: {

 

 3:     TokenHelper.TrustAllCertificates();

 

 4:     var sharepointUrl = new Uri(Request.QueryString["SPHostUrl"]);

 

 5:

 

 6:     using (var clientContext = TokenHelper.GetS2SClientContextWithWindowsIdentity(sharepointUrl, Request.LogonUserIdentity))

 

 7:     {

 

 8:         clientContext.Load(clientContext.Web, web => web.Title);

 

 9:         clientContext.ExecuteQuery();

 

 10:         Response.Write(clientContext.Web.Title);

 

 11:     }

 

 12:

 

 13: }

 

 

– Enfin, vous pouvez déployer l’ensemble des projets en tapant sur F5. Visual Studio va déployer la solution SharePoint, puis lancer IIS Express et y connecter votre site ASP. Un navigateur est lancé automatiquement sur une page de votre site SharePoint pour demander si vous faites confiance à cette application:

image

 

– Acceptez l’application, vous arrivez sur la page “Tout le contenu” du site, une tuile portant le nom de votre application permet de l’exécuter:

image

 

– le résultat : Ici le code de l’application est très basique, un simple Response.Write, mais bien sûr c’est volontaire, c’est maintenant à vous de jouer et de réaliser votre fonctionnalité en ASP !

image

 

Pour Conclure

Si tout c’est bien passé vous avez toutes les billes pour vous initier aux joies du CSOM et des services REST ou encore découvrir les possibilités de ce nouveau modèle de développement pour SharePoint.

 

A ces fins je vous conseille un peu de lecture, en anglais, par ici :

 

Important aspects of the app for SharePoint architecture and development landscape

SharePoint app code calls into SharePoint using CSOM and REST calls

Publié dans SharePoint Tagués avec : , , , , , , ,
Un commentaire pour “Configuration pour développer une APPs sur VOTRE SharePoint 2013
  1. Cet article est devenu ma référence pour la conf des apps sur SP. Keep up the good work matey. 🙂

Laisser un commentaire

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

*

Verifions que vous êtes un humain * Time limit is exhausted. Please reload CAPTCHA.

Archives

Social

  • Twitter
  • LinkedIn
  • Flux RSS
  • mvp
  • technet
  • Google+