SHAREPOINT 2013 : Tour d'horizon des Apps

Pour ceux ayant suivis le nouveau modèle de développement apparu dans SharePoint 2013, les Apps se décomposaient en trois types:
 

• SharePoint-hosted:
• Hébergement : Application hébergée dans SharePoint (à l'intérieur de la collection de sites),
• Développement : Ces applications permettent uniquement de coder en JS (JSOM ou REST pour s'interfacer avec SP). Par conception, l'authentification est basée sur SP,
• Isolation : L'isolation est de niveau ferme (pas possible de partager les données entre fermes).

 

• Autohosted:
• Hébergement : Applications O365 hébergées dans un Azure (tout est déja précablé et le déploiement est simplifié),
• Développement : Possibilité de développer en ASP.Net (MVC, WebForms, etc).
• Isolation : L'application est dans le tenant : "o365apps.net domain" et accède uniquement aux données du tenant O365.

• Provider-hosted (dites de type cloud) :
• Hébergement : Ces apps peuvent être hébergées dans Azure ou sur un serveur web de l'entreprise,
• Développement : Il est possible d'utiliser n'importe quelle technologie web réaliser son apps : ASP.Net, PHP, ... sera possible de communiquer avec SharePoint via du CSOM (Cliend Side Object Model) ou REST (pour des technologies non MS),
• Isolation : Il est possible de partager cette application entre diverses fermes SharePoint.

 

Depuis Mai 2014, le type "Auto-hosted" est retiré (cette fonctionnalité était en mode preview). L'article suivant de Microsoft détaille ceci : http://blogs.office.com/2014/05/16/update-on-autohosted-apps-preview-program/

Une mauvaise nouvelle alors que le mode de développement "Sandbox" est déprécié en SP2013.
Donc le seul et unique moyen de personnaliser Office 365 en restant dans les préconisations SharePoint reste le modèle "Provider-hosted".

InfoPath : Connexion au profil utilisateur en mode claims

Une des nouveautés de SharePoint 2013 a été l'introduction du mode d'authentification claims par défaut. Ce changement d'authentification entraine de nombreux impacts sur les applications et notamment "InfoPath Forms Services" (à noter que par conception, InfoPath en mode client lourd n'est pas concerné).

 

Dans les versions précédentes de SharePoint, de nombreuses sociétés utilisaient les formulaires IPFS en récupérant des informations de l'utilisateur connecté via le service de profil utilisateur (département, adresse mail, téléphone, numéro d'employé,...).

Si vous migrez et travaillez sur une application utilisant le mode claims, vous rencontrerez des erreurs de type "5566" lors de l'utilisation des connexions de données.

 

Il existe malgré tout un moyen de contournement qui consiste à utiliser le "Secure Store Service" de SharePoint:

 

• Se connecter à l'administration centrale de SharePoint,
• Créer une clé de type "Ticket du groupe" dans le Secure Store de votre ferme SharePoint :

 

 

• Configurer le compte Windows à utiliser pour votre connexion à l'UPS :

 

• Concevoir le formulaire en InfoPath en se connectant au service SOAP "userprofileservice.asmx" et convertir cette connexion en fichier UDCX via l'interface "Convertir" des connexions de données InfoPath :

 

 

 

• Modifier le fichier déposé dans la bibliothèque de connexion de données comme ci-dessous (il sera nécessaire de l'enregistrer localement et de le redéposer) en précisant la clé renseignée dans le secure store :

 

 

Attention : Ne pas oublier de dé-commenter la ligne "Authentication" et d'approuver le fichier UDCX après l'avoir téléchargé.

 

 

A présent, votre formulaire récupérera correctement les valeurs dans la base de profil SharePoint. Voici l'exemple d'un formulaire de liste SharePoint customisé avec InfoPath: