Archives de catégorie : Apps

3 choses que chaque programmeur devrait savoir

Introduction

Dans mes tâches de tous les jours, je dois modifier régulièrement du code et bien évidemment il y a des cas où on se dit vraiment « WTF? ».  Dans ce billet, je vais vous présenter quelque points à considérer afin d’améliorer la qualité de votre code et ainsi réduire le nombre de WTFs/minute lorsque vos collègues vous relirons.

Un commentaire sur les commentaires!

Assurez-vous que vos commentaires clarifient votre code et qu’il ne le rende pas plus obscur. Ajouté uniquement des commentaires pertinents expliquant ce que le code est censé accomplir. Vos commentaires d’en-tête devraient donner à n’importe quel programmeur assez d’information pour utiliser votre code sans avoir à le lire, tandis que vos commentaires au niveau des lignes devraient aider le développeur suivant à le corriger ou à le modifier. Comme avec toute autre forme d’écriture, il y a une habileté à écrire de bons commentaires et une grande partie de la compétence consiste à savoir quand ne pas les écrire.

À éviter :

'Instancie un nouveau dataset
Dim ds As New System.Data.DataSet

'Retourne la liste
Return listXYZ

Ne pas ignorer les erreurs!

Ignorer une erreur n’est pas une stratégie gagnante pour avoir du code solide. En fait, c’est tout simplement de la paresse. Peu importe la probabilité que vous pensez qu’une erreur se retrouve dans votre code, vous devriez toujours la vérifier et toujours la retourner. Vous ne gagnez pas de temps si vous ne le faites pas. Vous conservez des problèmes potentiels pour l’avenir.

À éviter :

try {
    // ...do something...
}
catch (...) {} // ignore errors

N’ayez pas peur de briser des choses!

Tout le monde a sans aucun doute travaillé sur un projet où le code était de qualité douteuse. Le système est mal architecturé et changer une chose vient toujours en briser une autre. Chaque fois que quelqu’un doit ajouter un module, l’objectif est de changer le moins de chose possible et de se croiser les doigts que ça ne plante pas. Bref, c’est l’équivalent de jouer une partie de Jenga.

N’ayez pas peur du code. Investir le temps de refactoriser le code va se payer plusieurs fois au cours du cycle de vie de l’application. Un avantage supplémentaire est que l’expérience de votre équipe face au système vous rend un peu plus experts en sachant comment il devrait fonctionner. En plus, travailler sur un système que vous détestez n’est pas la façon dont tout le monde devrait avoir à passer leur temps.

Advertisements

Créer un add-in part SharePoint Hosted pour afficher vos nouvelles avec le nombre de commentaires et de mentions « J’aime »

Je viens tout juste de publier mon premier vidéo sur le site Channel 9 :

video

Code source :

Pour s’y faire les technologies suivantes seront utilisées :

  • JavaScript
  • jQuery
  • SharePoint Hosted Add-in Part
  • SharePoint REST API

Je vous inviter à commenter et à évaluer ce vidéo !

 

Microsoft annonce le retrait des solutions SandBox contenant du code dans SharePoint Online

Microsoft vient de publier un article le 29 juillet 2016 annonçant le retrait des solutions SandBox contenant du code dans SharePoint Online. Cela fait déjà plus de deux (2) ans que les solutions SandBox contenant du code ont le statut d’obsolète.

Cependant, les solutions Sandbox contenant du code déclaratif et du JavaScript, connu sous le nom de solution SandBox sans-code sont encore viable.

La transition vers le modèle des Add-ins ou vers du développement côté client est donc inévitable pour les entreprises qui veulent demeurer compétitive.

L’époque où le modèle des Add-ins avait été ajouté avec peu d’exemples et de documentation est révolu avec les diverses initiatives de la communauté Pattern and Practices.

Ce qui s’en vient :

  • Dans le cadre du processus de suppression, l’activation de nouvelles solutions SandBox  contenant du code, ainsi que les mises à jour de solutions existantes ne sont plus possible; 
  • Dans les prochaines semaines, l’exécution de solutions SandBox contenant du code dans SharePoint Online sera également désactivé.

Conclusion

Le retrait des solutions SandBox était inévitable mais personnellement, je trouve que quelque semaines est relativement court comme préavis. Un délai de quelque mois pour le retrait complet de l’exécution des solutions SandBox aurait été plus approprié. Par contre, je considère que c’est une bonne nouvelle car ça met un trait sur une technologie désuète et cela va permettre d’accélérer le développement d’application avec le modèle des Add-ins.

Source : http://dev.office.com/blogs/removing-code-based-sandbox-solutions-in-sharepoint-online

Les meilleures pratiques d’accès aux données avec le modèle objet SharePoint

J’ai dernièrement publié un billet intitulé : « Les meilleures pratiques d’accès aux données avec le modèle objet SharePoint » sur le blog de Technologia.

En voici un aperçu :

Introduction au langage CAML (Collaborative Application Markup Language)

Le CAML est un langage XML utilisé dans SharePoint pour définir les champs et les affichages des sites et des listes. On peut aussi effectuer une requête en CAML pour accéder à du contenu SharePoint avec l’aide de l’objet SPQuery.

  CAML   Le CAML est sensible à la case

Objectif

Optimiser l’accès au contenu SharePoint afin d’améliorer les performances et de respecter les bonnes pratiques de développement.

L’objet SPQuery

  • Exécute des requêtes sur les données efficacement;
  • Utilise le langage CAML pour spécifier le SELECT, le WHERE, le ORDER BY et le GROUP BY de l’instruction SELECT SQL sous-jacente;
  • S’adresse à un objet SPList précis;
  • Est la bonne pratique à utiliser lorsqu’on effectue une requête sur une liste.

Utilisation de l’objet SPQuery

Les objets SPQuery peuvent causer des problèmes de performance quand ils retournent un grand nombre de résultats.

Les recommandations suivantes vous aideront à optimiser votre code de manière à limiter l’impact sur la performance quand vos requêtes retournent un trop grand nombre de résultats :

  • Ne pas utiliser un objet SPQuery illimité (unbounded);
  • L’utilisation d’un objet SPQuery sans spécifier une valeur à la propriété RowLimit ne fonctionnera pas de manière efficace et va échouer sur de grandes listes. Il est recommandé de spécifier un RowLimit entre 1 et 2000;
  • Utilisez des champs indexés.

Si vous effectuez une requête sur un champ non indexé, la requête sera bloquée chaque fois que celle-ci retourne plus d’éléments que le seuil de requête (dès qu’il y aura plus d’éléments dans la liste que dans le seuil de requête). Il est recommandé de spécifier un RowLimit à une valeur qui est plus petite que le seuil de requête.

Pour conclure

Que vous utilisiez le modèle objet serveur (SSOM) ou un modèle de programmation client (CSOM/JSOM), le CAML est indispensable pour réaliser des requêtes performantes en plus de respecter les bonnes pratiques de développement.

Retrouvez l’article complet ici.

Nouveau nom des Apps pour SharePoint : Add-ins SharePoint

Introduction

Cette semaine, lorsque j’effectuais de la veille technologique sur le site d’Office PnP, j’ai été surpris de voir que certaines appellations avaient changées :

addinRename

 

Dans la dernière publication d’Office PnP nous pouvons apercevoir les mots « Add-in pour SharePoint » ainsi que « Add-in model ».

SharePoint Add-in ? Add-in model ?

N’ayez crainte, Microsoft n’a pas sortie un nouveau modèle de développement de son chapeau. Ils ont simplement renommé le terme « App » pour « Add-in » en anglais. En français, on parle maintenant d’un complément pour SharePoint.

Vous trouverez l’annonce officiel de Microsoft ici :

We are currently updating our products, documentation, samples, and other resources to reflect the platform name change from « apps for Office and SharePoint » to « Office and SharePoint Add-ins ». We made this change to better distinguish the extension platform from Office apps (applications). For your reference, the following table lists the names that are changing and the new names.

Nom d’origine Nouveau nom S’applique à
apps for Office Office Add-ins Office
mail app for Outlook Outlook Add-in Office
app for Excel Excel Add-in Office
app for PowerPoint PowerPoint Add-in Office
app for Word Word Add-in Office
Office App Model Office Add-in Model Office
apps for SharePoint SharePoint Add-ins SharePoint
SharePoint App Model SharePoint Add-in Model SharePoint
app part add-in part SharePoint
app web add-in web SharePoint

Source : https://msdn.microsoft.com/en-us/library/office/fp161507.aspx#bk_newname

 

Cheat sheet pour les développeurs SharePoint

Introduction

Règle générale, je vous propose des billets sur des problèmes rencontrés lors de mes expériences avec SharePoint. Cette fois-ci, je vous propose quelque chose de différent avec une Cheat Sheet spécifique pour les développeurs SharePoint. Le concept de Cheat Sheet existe depuis longtemps et présente généralement de la façon la plus concise possible, les grandes lignes d’un logiciel ou d’un langage informatique.

Pourquoi une Cheat Sheet ?

Lorsqu’on forme des développeurs SharePoint, on a beau leurs donner plusieurs trucs, il y a tellement de chose à savoir que souvent ils ont de la difficulté à retrouver toute l’information qu’ils recherchent.

C’est alors qu’on se fait poser plusieurs questions du genre :

  • Quel est le Token pour avoir le URL de la collection de site dans un Custom Action?
  • Comment je peux éviter d’hardcoder le URL absolue de mon site SharePoint?
  • Comment je peux récupérer le GUID de ma liste?
  • Comment je peux supprimer une WebPart qui a brisé ma page?
  • Comment je peux afficher un formulaire dans une boite de dialogue?
  • etc…

Si vous vous posez souvent ce genre de question, je vous inviter a télécharger et imprimer ma cheat Sheet.

telecharger-bouton

Voici un bref aperçu :

cheetSheetPreviewEffect

N’hésiter pas à commenter si vous avez des suggestions!

Utiliser les Patterns and Practices et le modèle des Apps pour déployer vos sites dans SharePoint Online ou on-premise

Introduction

Créer efficacement des sites personnalisées pour répondre aux besoins de nos clients c’est une des raisons de l’existence de SharePoint. Microsoft se concentre de plus en plus vers des déploiements dans le cloud, alors nous aurons inévitablement besoin d’avoir un modèle de déploiement qui est viable et facilement réalisable à la fois sur O365 et on-premise.

Dans cette optique, je me suis penché sérieusement sur la question afin de mieux comprendre les différentes techniques de déploiement de sites ainsi que leurs avantages et inconvénients.

Le déploiement de sites personnalisés dans SharePoint a évolué au cours des dernières versions et avec l’arrivé du modèle des Apps, il est évident qu’une façon de faire uniformisé s’impose. Une des techniques consiste à utiliser le modèle de Apps pour déployer vos sites.

Différentes techniques de déploiement de sites personnalisés

Avant d’entrer dans le vif du sujet, voyons un bref résumé des techniques qui s’offrent à nous pour effectuer le déploiement :

  • Modèles Web (Web Templates)
    • Seulement disponible au niveau de la collection de site dans O365
    • Difficile à maintenir à jour
  • Définitions de site (Site Definitions)
    • Non supporté dans O365
    • Beaucoup d’impact lors des mises à jours
  • Solutions de ferme personnalisées
    • Non supporté dans O365
    • Complexe à mettre en place et à maintenir
  • Création de structure de site avec Powershell
    • Complexe à mettre en place et à maintenir
  • Agrafage de fonctionnalités (Feature stappling)
    • Seulement disponible au niveau de la collection de site dans O365

Changement d’orientation de la part de Microsoft

Les modèles web (Web Templates) ont été, jusqu’à dernièrement, un excellent mécanisme fournis par Microsoft pour créer des centaines de sites d’équipes avec leurs propres personnalisations (bibliothèques, vues, WebPart, etc…) en addition à un modèle de site « out of the box ».

Cependant, lors d’une conférence au TechEd Europe 2014 (30 Octobre) Microsoft a annoncé ceci :

  • Éviter d’utiliser des définitions de site et des modèles Web
  • Éviter les pages maîtres personnalisées
  • Éviter d’utiliser le code XML déclaratif

siteProvisioning_NoSiteDef

Lien vers le vidéo

La raison derrière ce changement est, à mon avis, que Microsoft tente de faire d’Office 365 une plate-forme de développement qui n’est pas onéreuse à faire fonctionner et en même temps de fournir un service qui n’est pas trop complexe.

Maintenant, si on utilise des modèles Web nous ne bénéficieront pas des derniers changements pour chaque mise à jour de Microsoft. On parle ici d’une « taxe de personnalisation » que vous devez payer si vous utilisez des modèles Web.

Réaction face à ce changement d’orientation

J’évite volontairement de vous parler de l’orientation qui consiste à éviter les pages maître personnalisés et le code XML déclaratif car je ne suis pas complètement en accord avec ce changement. Je partage l’opinion de Chris O’Brien, il y aura toujours place à la personnalisation dans un site Intranet et le code XML déclaratif est encore supporté à 100% dans O365!

Tout comme nous n’avons pas immédiatement abandonné les solutions de fermes lors de l’arrivé du modèle des Apps, les modèles Web continueront sans doute d’être utilisé pour plusieurs scénarios pour où vous ne voudriez PAS de ces derniers changements provenant des mises à jour de Microsoft.

Cependant, je considère que pour les site d’équipe ainsi que pour les sites de projets, il n’est plus favorable d’utiliser un modèle Web et il serait plus approprié d’utiliser le modèle des Apps pour déployer vos sites afin d’éviter cette taxe de personnalisation!

Le modèle des Apps pour déployer vos sites

Le diagramme suivant illustre le déploiement de collections de site en utilisant le modèle des Apps ainsi qu’une approche asynchrone :

 

siteProvisioning_Remote

  1. Lorsqu’un utilisateur a besoin d’une nouvelle collection de site, il remplis les métadonnées requises dans le formulaire de création
  2. L’information est stockée dans un endroit centralisé
  3. Si requis, on peut y associer des flux d’approbation
  4. Les requêtes approuvées sont traitées par une tâche planifié distante. Ex : Une tâche planifié hébergé dans un serveur applicatif qui lance un script PowerShell ou une application console
  5. Le déploiement du site est réalisé en fonction des métadonnées fournis en utilisant le CSOM
  6. Une notification est envoyé à l’utilisateur pour lui informer de la création de la collection de site.

Le principe de cette technique consiste à sortir le code permettant d’effectuer le déploiement à l’extérieur de SharePoint afin d’avoir un faible couplage avec la plateforme. Cette technique fonctionne dans O365 ainsi qu’on-premise. Un des avantages est qu’il n’est pas nécessaire de déployer de fonctionnalités dans la ferme pour effectuer le déploiement. En plus de cela, il n’y a plus de dépendances avec des packages de solutions à l’intérieur des bases de données de contenu alors on pourrait uniquement restaurer celles-ci en cas de disaster recovery.

Fonctionnement technique

  1. Aller sur le site GitHub de OfficeDevPnp à l’adresse https://github.com/OfficeDev/PnP
  2. Cliquer sur le bouton « Download zip » et choisir un emplacement
  3. Extraire le Zip et aller dans le répertoire PnP-master\PnP-master\Samples\Provisioning.OnPrem.Async
  4. Ouvrir Provisioning.OnPrem.Async.Console.sln avec Visual Studio
  5. Vous retrouverez la méthode principale ProcessSiteCreationRequest
[...]

private static string ProcessSiteCreationRequest(ClientContext ctx, ListItem listItem)
{

 //get the base tenant admin urls
 string tenantStr = ConfigurationManager.AppSettings["SiteCollectionRequests_SiteUrl"];

 // Resolve root site collection URL from host web. We assume that this has been set as the "TenantAdminSite"
 string rootSiteUrl = tenantStr.Substring(0, 8 + tenantStr.Substring(8).IndexOf("/"));

 //Resolve URL for the new site collection
 var webUrl = string.Format("{0}/sites/{1}", rootSiteUrl, listItem["SiteUrl"].ToString());
 var tenantAdminUri = new Uri(rootSiteUrl);
 string realm = TokenHelper.GetRealmFromTargetUrl(tenantAdminUri);
 var token = TokenHelper.GetAppOnlyAccessToken(TokenHelper.SharePointPrincipal, tenantAdminUri.Authority, realm).AccessToken;
 using (var adminContext = TokenHelper.GetClientContextWithAccessToken(tenantAdminUri.ToString(), token))
 {
 // Set the time out as high as possible
 adminContext.RequestTimeout = int.MaxValue;

 var tenant = new Tenant(adminContext);
 var properties = new SiteCreationProperties()
 {
 Url = webUrl,
 Owner = listItem["AdminAccount"].ToString(),
 Title = listItem["Title"].ToString(),
 Template = listItem["Template"].ToString(),
 };

 //start the SPO operation to create the site
 SpoOperation op = tenant.CreateSite(properties);
 adminContext.Load(op, i => i.IsComplete);
 adminContext.RequestTimeout = int.MaxValue;
 adminContext.ExecuteQuery();
 }

 // Do some branding for the new site
 SetThemeToNewSite(webUrl);

 return webUrl;
}

[...]

Afin d’uniformiser la manière de faire entre O365 et on-premise, vous remarquerez qu’on utilise la même notion de « Tenant« .

Une fois le code déployé, vous aurez un interface comme celui-ci pour saisir l’information concernant la collection de site à créer :

siteProvisioning_UI

Cette information sera ensuite sauvegardée dans une liste :

siteProvisioning_List

Finalement, l’application console que vous aurez lancé manuellement ou via une tâche planifié se chargera de créer la collection de site à partir de cette liste.

Pour plus d’information consulter ce vidéo qui présente en détail le fonctionnement du code et du processus.

Office Development Patterns & Practices (PnP)

En plus de fournir le code pour déployer des sites, le site d’Office PnP présente une série d’exemples et de scénarios sur les bonnes pratiques qui utilise le modèle des Apps.

Les exemples et scénarios utilisent les méthodes qui sont recommandées par l’équipe Office 365 et la majorité s’applique à :

  • Office 365 Multi Tenant (MT)
  • Office 365 Dedicated (D)
  • SharePoint 2013 on-premises

Voici quelque références pour les différents sites relié à Office PnP :

Conclusion

Le modèle des Apps pour déployer vos sites peut être la bonne solution dans une situation et peut ne pas l’être dans une autre. Le plus important est d’avoir une bonne compréhension des diverses techniques pour ensuite prendre une décision éclairé selon vos besoins. Le choix de votre technique de déploiement de site aura un impacte à long terme sur vos coûts de mise en place et de maintenance. J’aime bien la technique asynchrone proposé par Office PnP car il est possible de l’utiliser dans O365 ainsi que on-premise et de plus, l’utilisateur n’a pas besoin d’attendre dans son navigateur car il reçoit une notification à la fin du traitement.

Qu’est-ce que vous pensez de cette technique de déploiement de sites ?

Références

Building a async provisioning model par Office PnP

Office365 Developer Patterns and Practices par Vesa Juvonen

Provisioning site collections using SP App model in on-premises with just CSOM par Vesa Juvonen

Site provisioning techniques with SharePoint apps par Bert Jansen et Vesa Juvonen

Transforming Your SharePoint Full Trust Code to the SharePoint App Model  par Vesa Juvonen et Steve Walker

Developing for Office 365 – thoughts on use of custom master pages and web templates par Vesa Juvonen

Site provisioning techniques and remote provisioning in SharePoint 2013 par Chris O’Brien

L’effort de Microsoft au sujet de l’extensibilité d’Office 365 par Sébastien Levert