Pourquoi Apps? Quel est le problème avec les WSP?

Une chose est sure, aujourd'hui la tendance c'est la portabilité! plus de grands PC et des écrans à tube cathodique ! Aujourd’hui, on peut tout faire à partir de notre Smartphone, notre tablette, Surface... Ce virage oblige même les grands à penser plus App que Web Application.

"Apps" n’est pas qu’une stratégie de marketing ayant pour but la diffusion de SharePoint dans le marché mobile, c’est aussi une substitution intégrale des solutions bac à sable proposée par la version 2010. Et oui, plus de SandBox en 2013 ! Aujourd’hui on n’a que :

-Les solutions de ferme (full trust) en WSP

-Les APP

Pour faire des App, il faut savoir que :

1. Y’aura pas de code spécifique au niveau du serveur.

 2. Tous vos spécifiques seront développés côté client (navigateur) ou bien dans d’autre contextes (IIS, ou bien AZURE) extrêmement externes à SharePoint

 3.  l’Object Model serveur (SOM) est remplacé par le “Client Script Object model (CSOM) / Rest Services”. L’authentification se base sur OAuth. (Expliqué ultérieurement)

 4. L’installation, la désinstallation et la mise à jour d’une App n’affecte pas le site SharePoint qui la consomme.

 5. plus de possibilité pour l’utilisation mobile (tablettes et Smartphones)

Types de déploiement d’Apps :                      

Comment ça marche ?

Scénario1: Ici l’App est installé soit chez un provider de service, soit dans du Cloud AZURE. Donc toute dépendance de cette App sera créée, maintenue, supprimée en dehors de SharePoint, et donc d’une manière sécurisant la ferme SP. Ça rend L’APP sécurisé et non vulnérable dans une perspective d’exécution.

Scénario2: Quand on crée, importe, ou rajoute une App hosté dans SharePoint, ceci va créer un SPWeb appelé App Web séparé et dédiée pour l’App en question dans une collection de site aussi dédiée qu’on appelle, l’App-Catalog. Il faut savoir que cette collection de site va être configurée sur un App Domain différent de celui de la ferme qui va consommer toutes les App qui y sont installées :

Exemple : si notre collection de site de ferme est : http://Upperlink.com/sites/portail

On peut prévoir une nomenclature comme suis pour nos App (exemple : calculette) :

http://ULapp-4545-4544-5454-5454.UpperlinkApps.com/sites/Calculette/home.aspx

En ayant cette expression régulière pour l’url :  [prefix]-[appGUID].siteApps.com <==> site.com

Ma SharePoint-Hosted App dans VS2013 :

Avant de commencer, si nous disposons d’une machine StandAlone de développeur, il faut activer Active Directory Domain Services, pour créer différents domaines dans le même serveur.

Etape 1 : Dans visual studio, sélectionnez : « App for SharePoint »

Spécifier le nom de l’App, l’emplacement du projet VS et le nom de la solution.

En sélectionnant après l’option « hosting », assurez vous que c’est le « SharePoint-hosted » que vous choisissez.Vous pouvez choisir du AutoHosted si c’est pour déployer votre application sur AZUR, ou bien du provider hosted si vous voulez deployer votre App sur un fournisseur d’apps.

Etape 2 : nous voilà avec du contenu créé par défaut :

Nous trouvons une page « Default.aspx » ainsi que des fichiers de configuration et de script JS classiques. En effet, cette page est très importante parce qu’elle présente le point de départ de l’APP une fois elle est déployé. D’après ce qui a été dit précédemment, une App SharePoint se déploie automatiquement dans son propre Web dans la collection de site Catalogue d’application,  donc il faut être vigilant par rapport au nom de la page.

Etape 3 : Voici un aperçu du code-behind de la page en question :

Le premier cadre surligné fait référence aux différentes bibliothèques Javascript disponibles. Comme nous utiliserons Client Side Object Model(CSOM), ces bibliothèques Javascript fourniront tous les outils nécessaires lors de l’exécution de notre code spécifique.
Le second cadre surligné se réfère au fichier de script local se rapportant à l’App en question. Nous verrons ce fichier plus en détail dans l’étape suivante.

Le dernier cadre représente le rendu HTML de mon APP (simple). Merci de noter que dans ce tutoriel on va surtout se focaliser sur le mécanisme de déploiement plutôt que sur un code source spécifique étalé.

Etape 4 : ceci est le contenu du App.js. Dans ce fichier, nous pouvons gérer le contexte SharePoint  et les informations applicatives dans lesquelles l’App est en train de s’exécuter. En gros ici, je récupère le nom e l’utilisateur connecté et je l’injecte dans le paragraphe « Message » du html de la « Default.aspx »

Etape 5 : J’essaye de déployer l’App, OUPS Erreur !

" Error occurred in deployment step 'Install app for SharePoint': Failed to install app for SharePoint. Please see the output window for details."

L’output widow indique aussi que :

" ErrorDetail: Apps are disabled on this site. "

En revenant en arrière, et surtout au niveau de la définition du mode de fonctionnement de L’App, on sait que cette dernière crée son propre Web au moment où elle se déploie, et doit avoir un nom de domaine différent de celui de la ferme SharePoint courante. Ce que nous allons faire pour la prochain étape !

Etape 6 : Création d’un nouveau App Domain pour la configuration de « l’App Web » :

Le domaine créé pour la ferme SharePoint est : sharepoint13.com ; Nous allons du coup (afin de respecter l’expression régulière type) créer un domaine sharepoint13apps.com pour héberger nos Apps.

Nous allons donc ouvrir : outils d’administration ==> DNS et nous verrons déjà le domain local sur lequel notre ferme a été installée :

Clic droit sur Forward Lookup Zone, New Zone, Next, Next,Next, Next,  la fenêtre suivante va apparaître :

Une fois le nouveau domaine créé, nous allon maintenant créer un alias (CNAME) pour permettre aux Apps de créer leur propre nom de domaine sous Sharepoint13Apps.com.

Clic droit sur Sharepoint13Apps.com, Refresh, clic droit encore surSharepoint13Apps.com et puis sélectionnez  New Alias (CNAME) :

Spécifier les champs comme indiqué ci dessous et puis valider : 

Là, l’App Domain est créé, reste à le tester via un ping : vers blabla.sharepoint13apps.com :

Etape 7 : nous allons maintenant enregistrer ce nouveau domaine au niveau de sharepoint dans la section « App Management »

En cliquant sur le lien Configure App URLs, nous nous retrouvons avec le message d’erreur suivant :

"The Subscription Settings service and corresponding application and proxy needs to be running in order to make changes to these settings.»

Donc, nous sommes amenés à créer cette application de service avec une pool d’application dédiée. Nous commençons par créer un compte géré ayant les droits d’administration locale sur la machine, je choisis tout simplement :"Sharepoint13\SPSubSettingsAppAccount".
Ci-dessous un script Power Shell vous permettant de faire ceci :

Une fois le script terminé, nous avons créé l’application de service « Suscription Settings », avec un proxy et un pool d’application dédiés.

Pour vérifier ça :

Central Admin ==> Service Applications ==> Manage Service Applications ==>

Etape 8 : Nous allons maintenant revenir à l’administration centrale ==> Apps ==> configure App URLs :

Vous remarquerez que le domaine dédié au Apps que nous venons de créer est automatiquement spécifié dans l’interface ci-dessus. Reste à spécifier le préfixe que vous voulez donner à vos Apps.

Dès lors, nous pouvons redéployer notre solution Visual Studio  comme indiqué à l’étape 5.

Une fois c’est fait, vous pouvez vérifier au niveau du site de débogage http://win12sp13:48999/ votre App :

Site actions ==> site contents :

En cliquant sur l’App, vous remarquerez que cette dernière est configurée sur un nom de domain totalement différent de celui de la ferme SharePoint, donc ne présente aucune vulnérabilité potentielle pour notre ferme :

Voilà voilà !