Le Post Infeeny

Les articles des consultants et experts Infeeny

#SPC2012 : Understanding and Maintaining SharePoint Apps for IT Pros

Tuesday, 16h30, Chris Whitehead (@mrwhitey, chwhite@microsoft.com), MCM sur SP 2010, PFE EMEA Tech Lead, MS UK. Sam Hassani (@samhassa, samhassa@microsoft.com), Premier Field Engineering MCM sur SP 2010, SP Beta Support, MS UK.

http://sharepoint.microsoft.com/blogs/fromthefield

Résumé

La session est très intéressante concernant la gestion des App d’un point de vue IT Pro. Les différents éléments à prendre en compte pour l’installation, la gestion de la sécurité, la gestion du cycle de vie et le monitoring.

Beaucoup de choses ont déjà été vues dans d’autres sessions mais tout ce qui a un rapport avec l’ITP est résumé dans cette session.

// DEMO directement d’une App

Il ajoute une App simplement Poll App développée personnellement.

Il arrive sur une App qui permet de créer des enquêtes.

Il ajoute une enquête via un formulaire avec une question et 3 réponses possible.

Il revient sur le host web, il ajoute une App part sur sa page d’accueil, et la configure pour se baser sur l’enquête.

Effet démo … grosse erreur sur la page, content cannot be displayed. Il y a des problèmes de connexion étant donné que la démo se fait sur O365.

// Retour sur les slides : Apps et la sécurité

Il revient sue le mode de développement, où il faut bien vérifier que les apps ne soient pas full trust comme peuvent configurer les dévs.

Il revient sur les sandbox qui permettaient d’isoler les développements. Mais ce fut une solution très compliquée à maintenir.

Sur SP2013, les Apps prennent leur sens en proposant une solution sandbox plus facile à maintenir. Tout est Apps dans SharePoint 2013.

L’évolution est passé de solutions fermes, à sandbox qui étaient trop strictes pour les développeurs et compliquée pour les administrateurs des sites, maintenant nous avons les Apps, les codes sont exécutés côté client plutôt avec un cycle de vie géré.

Il revient sur les types d’hébergements pour les Apps (autohosted, provider hosted, ou SharePoint hosted) Sur les SP hosted, on a un App web comme sous-site du site sur lequel il est installé.

Sur les cloud hosted, les sites existent en général et un App Web est optionnel.

// App UI components

Il existe la possibilité d’avoir l’App en page plein écran (expérience immersive, Il est aussi possible d’ajouter en App Part comme une iframe au sein d’une page du site hôte.

Dernière possibilité est de faire un custom action sur une liste permettant d’accéder à l’App.

// Le domaine isolé

Sur un app Poll installée sur http://intranet/sites/SPC , on a dit qu’une App est une sous-site. On imagine avoir alors http://intranet/sites/SPC/Poll … mais non, c’est plutôt http://app-bpojp4554-G4545.intranetapps/sites/SPC/Poll.

Cela permet de déporter la sécurité sur le navigateur qui doit gérer les appels cross-domain et qui en l’occurrence les bloque.

Une URL http://app-bdf2016ea7dacb.contosoapps.com/sites/SPC/Poll est décomposée ainsi

* app : App prefix

* bdf2016ea7dacb : App Id

* contosoapps.com : App domain

* /sites/SPC : Host web

* /Poll : App name

// DEMO : App

Hassani revient sur sa démo qu’il fait marcher depuis tout à l’heure.

Il explique que l’App peut être utilisée dans son host web comme ça.

Whitehead reprend la parole pour montrer effectivement la structure de l’URL.

Il explique qu’il a mis en place du code qui récupère du code sur bing mais que cela ne fonctionne pas à cause de cette fameuse same origin policy qui empêche les appels cross domains.

// DEMO : Image converter – custom action

Il montre une App Image Converter.

Il ne rentre pas dessus mais va sur une Picture Library sur le host web.

Il a grâce à l’app mis une Custom actions permettant d’ouvrir une App hébergée sur Azure dans laquelle il passe l’image de la picture library et où l’App sur Azure va convertir l’image en noir et blanc.

// Retour sur les slides

Hassani revient sur les considérations à prendre en compte lors du déploiement d’Apps.

* App domain (ex : contosoapps) –> Domaine séparé ou sous-domain (contosoapps.com ou apps.contoso.com). Il faut faire attention avec une potentielle faille possible via des cookies de sous-domaines.

* Noms de domaine : utiliser une entrée Wildcard dans le DNS est conseillée

* Utilisation d’un certificat SSL pour l’entrée wildcard car nous avons des émissions de tokens oAuth en clair sinon

// Configuration de la ferme SharePoint

2 services applications : Subscription Settings et App Manamgenent (doivent utiliser le même groupe de proxy) Dans le SharePoint App Settings –> définir le App URLs (préfix et domain), App catalog (catalogue d’apps), Store settings (possibilité d’acheter des Apps), App denied endpoints (list de webservices à exclure dans les Apps).

A prendre en compte :

* Les Apps ne supportent pas Kerberos

* Identity provider doivent supporter les enregistrer en wildcard si on utilise l’authentification SAML

* Les Apps ne supporte pas les zones multiples (il existe des workaround)

* Utilisation des routing web application lorsque nous avons plusieurs URL dans une web application. Le routine des requêtes peut ne pas marcher. Il faut créer une web app sans host header qui va servir de « catch all » et qui va utiliser le App Management Service Application pour savoir quelle site il doit servir comme host web.

// DEMO : Configurer une ferme on premise

* Il créé un domain contosoapps.local avec une entrée A, en wildcard qui pointe vers le serveur SharePoint

* Il a déjà ajouté les Service Applications (App Management et Subscriptions Settings) et explique qu’il a démarré les services correspondant

* Il note dans la central administration qu’il a la possibilité de déclarer les prefixes et app domain de ses apps (contosoapps.local précédemment créé dans le DNS + le préfix arbitraire « app »)

* Il a créé un App Catalog pour une webapplication donnée. A noter qu’une fois définie, il ne peut modifier l’app catalog pur une webapp par la central admin. Il faut le faire par Powershell

* En allant sur le site de catalogue d’apps, il explique qu’on peut avoir des Apps pour Office, pour SharePoint et la possibilité de gérer les requêtes à des Apps de façon centralisée pour l’administrateur.

* Il retourne dans la central d’administration où il configure les paramètres du catalogue. Il permet notamment aux utilisateurs de récupérer des Apps depuis le SharePoint Store.

// DEMO : Autorisation sur les Apps et App permissions

Scénario : il héberge ses photos sur Fabrikam et s’authentifie pour poster et récupérer les photos Contoso, est une agence qui imprime les photos où il s’authentifie.

Son scénario est comme la session précédente, la possibilité depuis contoso de récupérer les photos de Fabrikam.

La problématique est également la même, cela l’embête que Contoso connaisse son mot de passe Fabrikam Ce qu’il voudrait est la possibilité d’utiliser un système permettant à Contoso d’avoir le droit d’agir en un nom pour effectuer une certaine action sans passer à Contoso le login/mdp de son compte.

Ceci est pour expliquer OAuth.

Définition : « OAuth enables users to approve an application to act on their behalf without sharing their user name and password. »

Comment ça fonctionne :

1. Le client envoie une requête à SharePoint

2. SharePoint requête un jeton de contexte à ACS

3. ACS renvoie un jeton signé à SharePoint

4. SharePoint renvoie une page avec le jeton de contexte au site de l’App

5. Le site de l’App va accéder à ACS pour faire une requête avec le jeton

6. ACS valide le jeton au site de l’App (jeton d’accès – access token)

7. Le site de l’App fait une requête à SharePoint avec le requête + le jeton d’accès

8. SharePoint valide le jeton d’accès et renvoie les données à l’App

9. L’App renvoie la page à afficher en IFrame.

Il continue sur le fait qu’une App peut être développée en demande des permissions sur différents objets SharePoint. En demandant une action en agissant comme l’utilisateur (User identity), de l’App de la part de l’utilisateur (App on behalf on user identity), ou bien de l’App elle même.

Pour cela, il faut définir les AppPermissionRequest (vu dans la session précédente) avec le Scope et le Right.

// Retour sur les slides : Apps lifecycle Process :

* Install an App  –  (fait par App Installation Service – Timer job). Utilisation de Import-SPAppPackage ou Install-SPApp

* Gestion de la licence – Timer job License renewal. Il y a 3 types de licences : Free, Trial, Paid. Pour les licences à utilisateurs limités, il faut mapper les licences sur les utilisateurs.

* Backup et restore de l’App – Export-SPAppPackage et Import-SPAppPackage. Un backup-spsite va aussi backuper les Apps installés mais attention aux apps qui ne sont pas installées sur la ferme de destination

* Mise à jour de l’App – Timers jobs : App State Update et Internal App State Update. Une fois que l’app a une mise à jour, il y a une notification invitant à mettre à jour les Apps. Cmdlets existent en Powershell

* Déinstallation de l’App – Cmdlet : Uninstall-SPAppInstance. A noter que l’App web est supprimé ainsi que tout le contenu qui y est lié.

// DEMO : App lifecycle management

Une app est installé sur une collection de site A.

Sur l’App Catalog il avait une App en v1.0.0.0 Il a une app en .APP qu’il drag et drop sur l’app catalog.

L’app est passée en v2.0.0.0.

Il retourne sur la collection de sites A, et rien n’a changé. Le Job ne s’est pas exécuté.

Il va sur Internal App State Update timer job qui est configuré à 24h. Il l’exécute manuellement.

Il retourne sur sa collection de sites A, il voit qu’il y a une update pour son App. En cliquant sur « Update », l’App se met à jour.

// DEMO : Monitoring and jogging

Il montre un site O365. Il va sur Site Contents, clique sur le menu d’une App et fait Details.

Il voit alors qu’il y a 11 runtime errors sur les 4 derniers jours. En cliquant sur 11, il voit l’erreur qui est le message de l’Exception qui peut être remontée au développeur directement.

Il peut avoir dans le menu des Apps, la possibilité de voir le nombre de sites sur lesquels est installé l’App.

Attention lors d’environnement avec plusieurs front on peut arriver à avoir 8 erreurs, mais 0 installations. Cela est sûrement dû au fait que les timer jobs s’exécutent en retournant l’information au même endroit. Selon si un WFE renvoie l’info en premier ou l’autre, on peut avoir des incohérences.

Christian

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :