When working on a client-server oriented environment with Sitecore, you will have to develop your Sitecore Items locally, and send them to the server. Of course, you will use the “Publish” feature in Sitecore at first. But then, you will certainly need to edit your items and compare them with the precedent versions for example. That’s why you will need to serialize your items and integrate them in your favourite source control software…

A fabulous and mysterious creature appears in front of you : The unicorn.

I. Installing Unicorn on your local Sitecore instance

• Open your Visual Studio Project as an adminstrator

• Open the Package Manager Console (Tools>Nuget PackageManage>Package Manager Console)

• Install the Unicorn Nuget Package by using the command :

• Install-Package Unicorn

• Go to the App_Config/Include/Unicorn Folder.

• Rename “Unicorn.Configs.Default.example” to “Unicorn.Configs.Default.config”.

• Edit the file with your favourite text editor.

In this file, (within the <configuration> and <predicate> nodes) you need to signal the items that you want to synchronise or not. You can exclude the files you don’t need.

For example :

• Rebuild and Deploy your Visual Studio solution
.
• Go to the following URL : http://yoursitecoreinstance/unicorn.aspx . Log-in with your admin credentials, to get to this page :

• Click on the “Reserialize” button.

The Unicorn console opens up and creates for the first time all the .yml files, representing each items that you wanted to synchronise.

If everything goes well, go back to the configuration page.

• Click on the “Sync” button this time

The same console is displayed, and generates the items. You should now get all the items you wanted in your folder :

That’s all !!! When you edit a Sitecore item and want to keep a trace of it, just click on the Sync button. The files generated are in .yml extension and can be read by any existing text editor.

II. Create an automated deployment script for your items

A. Prepare the client-server communication

The next step that get us closer to a full automated Sitecore/Unicorn server, would be to set-up an deployment script.

Unicorn has already delivered for us these scripts right here :
https://github.com/kamsar/Unicorn

• You can choose to download the whole archive or only the folder named “doc / PowerShell Remote Scripting /”

Put the three files in the same folder, somewhere on your local disk.

• Open the file “sample.ps1”. I renamed it to “UnicornRemoteSync.ps1”.

• Edit this line and replace the url by the address of your remote server :

• Generate yourself a secret token. I used the website http://passwordsgenerator.net/ to get a 100 length token. It should be enough
.
• Copy the token, and paste it to the configuration line
.
• Go on your remote server, in your Website folder, in “App_Config\Include\Unicorn”.

Edit the Unicorn configuration file : “Unicorn.UI.config”, and paste your secret token in the “SharedSecret” tag :

You have now configured the connection between your remote server and your client. You just have to prepare the connection by signing your powershell scripts.

B. Sign your powershell scripts on your local machine

For this operation, I create another powershell file to separate execute my commands :

• Change your signature execution policy to ‘Unrestricted’ :

Set-ExecutionPolicy Unrestricted

• Use makecert.exe to create your own Certificate Authority

In Windows 10, this program is located at 'C:\Program Files (x86)\Windows Kits\10\bin\x64'.

./makecert.exe -pe -n "CN=versusmind" -ss My -a sha1 -eku 1.3.6.1.5.5.7.3.3 -iv versusmind.pvk -ic versusmind.cer

• Open your certificate LocalMachine Certificate store (mmc.exe)

• Develop the TreeList :

Go in the “Trusted publishers” folder and import the certificate that we have generated in the previous step.(All Tasks > Import… > Browse in the directory where makecert.exe is located)

• Once the certificate is imported, open it, and go to the “Details” tab :

Select the line “Thumbprint” and copy the associated.

• In your powershell script, edit the following line :

$cert = Get-ChildItem -Path Cert:\CurrentUser\My\AF2E902AB3DECF2BF6FB84043AF6B1B4E28A2957
Write-Host $cert

Replace “CurrentUser” by “LocalMachine” if you are rather your local computer certificate store. And then, replace the token by the thumbprint copied previously.

Execute these commands and make sure that everything is ok :

• Finally we can sign our certificate :

Set-AuthenticodeSignature -FilePath '.\UnicornRemoteSync.ps1' -Certificate $cert

• Once this is done, you just have to execute your powershell script, and enjoy your automated deployment asset ;-).

Warning : If your server responds with this kind of errors :

Invoke-WebRequest : The underlying connection was closed: An unexpected error occurred on a send. 

Just add the following lines :

add-type @"
    using System.Net;
    using System.Security.Cryptography.X509Certificates;
    public class TrustAllCertsPolicy : ICertificatePolicy {
        public bool CheckValidationResult(
            ServicePoint srvPoint, X509Certificate certificate,
            WebRequest request, int certificateProblem) {
            return true;
        }
    }
"@
[System.Net.ServicePointManager]::CertificatePolicy = New-Object TrustAllCertsPolicy

Just before the call of the WebRequest command. It’s a workaround concerning https policy restriction, which can save you a lot of time, trust me.

III. References

Here are some of the wonderful websites I used to write down this article :
• http://blog.karbyn.com/articles/sitecore-getting-started-with-unicorn/
• https://github.com/kamsar/Unicorn
• https://kamsar.net/index.php/2017/06/Unicorn-4-Released/
• https://stackoverflow.com/questions/11696944/powershell-v3-invoke-webrequest-https-error

Le Marketing contextuel est un terme qui n’est pas forcément explicite aux yeux de tous. Il est pourtant présent dans bien des domaines, que ce soit dans le web, ou ailleurs. En effet, le contenu proposé, compte tenu du support sur lequel il apparaît (TV, tablette, PC, panneaux publicitaires, …) et surtout à qui il s’adresse (tranche d’âge, sexe, mode de vie, …) doit pouvoir s’adapter. Pour en savoir plus, je vous renvoie à mon autre article concernant le marketing contextuel (http://www.versusmind.eu/blog/introduction-a-sitecore-notions-de-base-du-cms) .

Dans le CMS Web qu’est Sitecore (je préfère parler de CXP pour Sitecore car même si la base de gestion de contenu est présente, c’est bien ses fonction d’expérience (AI + analytics) qui le caractérise et surtout précise l’importance de nos compétences auprès de nos clients), ce type de marketing est inscrit dans l’ADN du projet. C’est pourquoi il est important de définir en amont cette stratégie marketing dont  découle la structure du projet web.

Construire et faire évoluer un projet Web sous Sitecore, peut s’apparenter à la construction d’une maison. Les fondations (l’agencement des instances sitecore) doivent bien sûr être assez solides pour supporter le poids des premières pièces (ici, les fonctionnalités de base du site web). Mais on doit aussi pouvoir anticiper les extensions si la famille s’agrandit (besoin utilisateur modifié et fonctionnalités supplémentaires non définies au départ). Si elles n’ont pas pris en compte ces éventualités, il faudra détruire des parties déjà construites et perdre du temps sur sa construction, ou prendre le risque à la bâtisse de s’effondrer…

Voyons donc ici les types d’architectures et les outils qui permettent de faire face à ces risques.
 

Industri quoi ?

Quand on parle d’industrialisation, l’une des premières choses qui peut venir à l’esprit est l’image de la répétition, de la production en grande quantité, etc… Dans notre contexte, il s’agit plutôt de l’élaboration de l’infrastructure qui va nous permettre de gérer efficacement un ensemble de solutions web, et de les rendre apte à accepter toute évolution au long de leurs développements. Il faut que ces projets soient armés pour faire face à ces contraintes et puissent pouvoir répondre rapidement à ces demandes.
Aujourd’hui, Sitecore est bien entendu concerné par ces contraintes. C’est pourquoi le CMS s’est étoffé et possède aujourd’hui les clés d’un développement flexible et adapté aux problématiques projet. Aujourd’hui, les envies des visiteurs ou clients d’un site évoluent constamment. Les modes et les solutions technologiques sont calquées sur ce rythme. Il est donc impensable de re-développer entièrement certains pans d’un projet web à chaque fois qu’il est modifié. Il doit être donc le plus modulaire possible, aussi bien dans son code, que dans son architecture.

Architecture

Un site classique développé sous Sitecore s’articule grossièrement comme ceci :

Fig. 1 : Schéma de répartition des serveurs dans une instance Sitecore monosite classique. https://community.sitecore.net/)

On distingue trois bases de données différentes. Master, Web et Core et qui ont chacune des fonctionnalités qui leur sont propres.
-    Un serveur de base de données qui va gérer ces bases
-    Une instance nommée « Content Management Server » : Elle permet aux responsables du site de modifier et d’ajouter du nouveau contenu sur le site via l’interface d'administration.
-    Une instance nommée « Content Delivery Server » : Elle se charge de publier le contenu web et de le mettre à disposition des visiteurs du site.
Ces ensembles figurent donc en général sur une même machine physique.
Pour l’exploitation d’un site en production, Sitecore propose la possibilité de faire évoluer cette architecture vers un découpage de ce type :



Fig. 2 : Schéma de représentation d’un site multi-instance sitecore. (https://csuwannarat.files.wordpress.com/2011/12/dep01.png?w=466&h=374)

Ici, on a scindé le CD (content delivery server) en deux parties distinctes, gérées par du load balancing. Cela permet de rediriger l’activité d’un serveur vers l’autre lorsque celle-ci se trouve ralentie ou bouchée par une surcharge de visites en certaines périodes par exemple.
Ainsi, on peut avoir un environnement de « pré-production » (Web) qui permet de faire les vérifications d’usages sur le serveur de production, et d’avoir un autre environnement de production (Live, copie de Web), relié directement aux serveurs de Content Delivery.
Cet exemple nous montre que Sitecore permet d’agencer ses éléments comme on le souhaite pour avoir une configuration adaptée au fonctionnement direct de l’entreprise concernée.
Dans certaines sociétés, il n’est pas rare de voir fleurir autour d’un site principal, d’autres applications web qui viennent souvent se greffer au contenu existant et ainsi évitent le dédoublement d’informations. Sitecore permet également de gérer cela en proposant une configuration d’instances multisites.

Fig. 3 : Schéma de composition du Content Delivery dans une instance multisite. (http://digital-learnings.blogspot.fr/2015/12/sitecore-multi-site-or-multi-instance.html)

Ici, ce qui change par rapport à une architecture plus traditionnelle c’est qu’on a deux serveurs web IIS différents, gérés par un unique Content Delivery, mais renvoyant vers deux sites Sitecore bien distincts. Le contenu lui provient des items Sitecore générés en amont.
Des modifications peuvent donc être faites au sein d’une seule instance Sitecore et impacter l’un ou l’autre site web publié, mais aussi les deux à la fois.
Avec l’arrivée récente de Sitecore dans le cloud (avec Microsoft Azure), la gestion de cette architecture en est largement simplifiée et ceci est encore plus d’actualité depuis que Sitecore propose sa solution de Cloud: Sitecore continue d’utiliser Microsoft Azure mais le support est géré directement par le CMS, vous simplifiant ainsi les démarches

Dans un souci de performance, mais aussi d’évolutivité, Sitecore peut donc s’adapter des architectures simples ou complexes, tout en gardant sa flexibilité.
 

Outils

Les développeurs non plus ne sont pas en reste quand il s’agit de s’adapter aux évolutions d’une application web. Ils sont même souvent confrontés en premier aux besoins des utilisateurs, et donc, de leurs évolutions. Voici quelques outils primordiaux dans la réalisation de projets web « industrialisés».

GlassMapper

En installant une instance Sitecore de base, une API fournie par l’éditeur est aussi rendue accessible. Avec celle-ci, on peut manipuler l’ensemble des items créées via l’interface d’administration, d’en rajouter, supprimer, etc… Cela dit, il faut que chaque item que l’on va remodeler soit facilement récupérable et identifiable dans le code.
Cela demande un temps de travail relativement important, surtout si le nombre d’items différents, de templates grossit avec l’instance.

Glass Mapper permet de répondre à cette problématique en proposant aux développeurs de générer automatiquement le code qui va représenter les items Sitecore, sous forme de classe.

C’est donc un gain de productivité non négligeable que d’utiliser une aide telle que celle-ci.
http://glass.lu/.

Hedgehog TDS

Toujours dans l’optique de faire gagner du temps aux développeurs, TDS est rapidement devenue une référence majeure des outils compatibles avec Sitecore.

Fig. 4 : Boîte de dialogue du module TDS, dans Visual Studio. Aperçu des fonctionnalités du module.

Intégré à Visual Studio, cet assistant va se synchroniser avec l’instance Sitecore, afin d’avoir à portée de main, dans votre projet Sitecore, l’intégralité des items développés. Il permet donc, dans l’IDE, de se connecter à l’instance et d’ouvrir une fenêtre qui accède à l’interface Web, sans ouvrir un navigateur.
Lors du travail en équipe, il est également important de faire attention aux conflits entre les différents items. TDS permet justement de comparer sa version locale du projet, et d’éventuellement fusionner les modifications avec celles présentes sur le serveur de destination.

Fig. 5 : Impression d’écran de la synchronisation des items Sitecore dans TDS.

Cerise sur le gâteau, il est également possible de publier et de déployer l’instance Sitecore, depuis son interface.
Aujourd’hui, son utilisation peut remplacer totalement l’outil Sitecore Rocks, qui lui est gratuit.
https://www.teamdevelopmentforsitecore.com/
 

Unicorn

Une alternative gratuite à TDS, Unicorn répond à toutes les problématiques posées, à sa manière. Il utilise par exemple des fichiers YAML pour décrire la structure des items.Il s’agit d’un type de fichier, qui respecte une certaine syntaxe, et qui décrit principalement des structures de vues, d'objets, ou de fichiers de configurations).
https://github.com/kamsar/Unicorn
 

Helix

Plus qu’un outil de développement à proprement parler, Helix est un ensemble de règles de conduite et de recommandations proposées par Sitecore. Elles permettent aux développeurs de structurer leurs projets, afin de le pérenniser tout en restant orienté vers leurs objectifs de performance, de qualité et d’évolutivité.
Le référentiel Helix dispose de plusieurs sites web open source. Cet ensemble s’appelle Habitat : https://github.com/sitecore/habitat
http://helix.sitecore.net/.
 

Sitecore Courier

Par défaut, il est possible de créer des packages d’installation des instances Sitecore. Par l’intermédiaire d’un assistant proposé par le CMS, il est possible de choisir la composition de ces packages, d’en importer, etc… Malheureusement, il s’agit d’une opération manuelle fastidieuse. Avec Sitecore Courier, il est maintenant possible de générer automatiquement ces packages. Ce module analyse les items sitecore et peut se rendre compte des items qui ont changés. Il va donc à un moment donné créer des packages de mises à jour (patchs) en prenant uniquement les modifications à appliquer. https://sitecorecourier.codeplex.com/

RAZL

Autre produit proposé par la firme Hedgehog, cet outil est très pratique lorsqu’on souhaite gérer un ensemble d’instances en production. Le module compare les différentes bases de données des instances et souligne les différences. On peut donc par la suite procéder à des synchronisations, importations, etc… Il existe des modules sitecore gratuits dans la même veine : Coast For Sitecore, ou Content Migrator SideKick.

https://www.teamdevelopmentforsitecore.com/Razl

Synthèse

Avec l’essor du CMS Sitecore et du marketing contextuel, la possibilité de construire un environnement efficace et flexible est grandissante. Les sociétés qui utilisent le CMS en ont grandement besoin, et Sitecore en est conscient. C’est pourquoi plusieurs clés ont été proposées, soit par Sitecore directement, soit par sa communauté.

Ces clés d’industrialisation affectent les solutions web sous deux niveaux. L’architecture dans un premier temps avec la répartition des instances (multi-sites, multi-instances, dans le cloud…)
Dans un second temps, l’exploitation des instances (les migrations de données notamment), et le développement des applications Web, en corrélation avec les items Sitecore.
En combinant judicieusement ces solutions, les besoins des utilisateurs peuvent être plus efficacement satisfaits, et les applications web évoluent de façon plus pérenne.

Le Marketing Contextuel est un terme qui n’est pas forcément explicite aux yeux de tous. Il est pourtant applicable à la quasi-totalité des sites web actuels. En expliquant les tenants et les aboutissants de cette démarche marketing particulière, nous allons parcourir les outils que Sitecore nous propose pour les appliquer à un projet web.

En partant de sa définition stricte, le marketing contextuel consiste à adapter, le plus souvent en temps réel la démarche marketing en fonction de l'internaute qui a été identifié, l'endroit où il se situe sur le site, les choix qu'il fait pendant sa navigation. On peut distinguer trois grands leviers essentiels du marketing contextuel : l’identité du visiteur, son parcours dans le contenu qu’on va lui proposer, et le plan d’action mise en place en réponse de ces données.

L’identité du visiteur

Avant toute chose, lorsqu’on décide de mettre en place une démarche marketing dans un projet quelconque, il faut se poser la question suivante : Qui est le destinataire de cette démarche ? A qui s’adresse-t-on ? Cette identité se forge au fur et à mesure du parcours du site.

En effet, l’identité n’est pas simplement le renseignement d’un pseudonyme ou d’une adresse e-mail. Il s’agit de constituer un profil complet, qui va déterminer dans quelle catégorie on va glisser l’utilisateur. Cette catégorie caricaturale, établie selon les comportements d’un groupement de personnes est appelée “persona”. Dans le monde du Web, on établit un persona notamment grâce aux caractéristiques suivantes :

• Les mots-clés utilisés sur le site. Que ça soit dans les champs de recherche, l’utilisation de formulaires de contacts, etc... Les mots saisis reflètent souvent l’envie première d’un utilisateur.

• Le canal d’origine. Le site ou l’application qui a dirigé l’utilisateur vers le site peut déterminer l’intention première d’une personne. Par exemple, si la personne vient d’un lien unique généré sur twitter, elle viendra consulter un contenu précis en quelques minutes (article d’actualités par exemple), tandis que si la personne est issue d’une recherche par Google, elle sera potentiellement intéressée par le site dans sa globalité et souhaiterait découvrir plus de contenu.

• Les pages visitées

• Les renseignements personnels (âge, sexe, nationalité, etc…)

Tous ces critères sont des données que Sitecore peut enregistrer et utiliser. Avant de les exploiter, il revient à un utilisateur de Sitecore de créer des personas, via l’application “Marketing Center” du panneau d’administration.

Le parcours client

Comme dit précédemment, c’est au fur et à mesure des visites de l’utilisateur qu’on peut affiner de plus en plus précisément l’idée qu’on se fait de ce visiteur. On peut alors le catégoriser à chacune de ses visites et pourquoi pas, le transformer en client final.

Lorsqu’on élabore une démarche marketing sur son projet web, on est souvent amené à déterminer et à hiérarchiser “l’engagement du client” :

Fig. 3 : Exemple d’échelonnage des engagements d’un projet marketing. Plus une action possède un engagement important, plus sa valeur sera placé en haut de la pyramide. (Sitecore Context Marketing Workbook)

Dans Sitecore, on peut déclarer explicitement ces valeurs d’engagement, il s’agit des goals. Chaque déclenchement de ces actions définies rapproche un peu plus l’utilisateur d'un persona.

Ces goals attribuent une valeur à des actions unitaires ou à des enchaînements d’actions. Par exemple, dans un site e-commerce, le visiteur va aller dans une catégorie de produit, va cliquer sur le produit en question, puis va se renseigner sur le prix. Cet enchaînement peut déclencher un goal et catégoriser le client dans un persona.

Chaque fois que ces actions seront déclenchées, la valeur de la visite de l’utilisateur est incrémentée de la valeur attribuée.

Fig. 4 : Création du goal “Utilisateur enregistré”. (https://goo.gl/FMqcvp)

Le goal peut alors être attribué à n’importe quel type d’interactions avec le site web (affichage d’une page particulière, enchaînement de clics sur des boutons différents, etc…) et peut être la cible de conditions personnalisées :

Fig. 5 : Le Rule Set Editor permet de créer des conditions en se basant sur une multitude de règles prédéfinies et personnalisables en intégralité. (https://goo.gl/p1JmSh)

Soit le goal est déclenché lorsqu’une de ces conditions est atteinte, soit il est déclenché par du code.

Par exemple :

Le parcours du visiteur et les valeurs associées sont visibles dans l’interface d’administration également :

Fig. 6 : Analyse d’un parcours utilisateur dans le Path Analyzer, dans le panneau d'administration. (https://goo.gl/9VkfuL)

La mise à jour automatique du contenu

L’exploitation statistique des données recueillies précédemment est primordiale dans la prise de décision future pour le projet. Non seulement elle permettra d’engager des actions à moyen terme, mais en plus, elle permet de modifier en temps réel le contenu de l’application Web.

Sitecore met à disposition de ses développeurs une API de programmation. Celle-ci permet de manipuler n’importe quel élément du CMS, en C#, y compris les personas, et les goals.

Le code ci-dessus permet de détecter le ou les personas attribués au visiteur de la page. Ainsi, on peut éventuellement en sélectionner un, et afficher du contenu spécifique pour ce persona. Si on a par exemple un visiteur qui est dans une catégorie “adolescent” on pourra lui proposer du contenu qui lui correspond, (jeux vidéos, actus people, etc…).

Synthèse

Le marketing contextuel, dans le cadre d’un projet web est un concept qui s’articule autour de trois éléments principaux: l’identification du potentiel client, le parcours de cette personne au sein du site web, et la modification du contenu en conséquence. Définie en général en amont d’un projet, la démarche permet de structurer un projet pour qu’il s’inscrive dans la stratégie marketing globale d’une entreprise.

Sitecore intègre totalement cette dimension-là, au travers des éléments tels que les goals ou les personas notamment. La gestion de ce marketing contextuel peut se faire soit grâce à l’interface d’administration de Sitecore (par la création de conditions personnalisées), soit directement depuis le code en utilisant l’API fournie aux développeurs.

En utilisant ces outils de façon judicieuse pour manipuler les items Sitecore, on se rend compte qu’on arrive à adapter efficacement notre site à chaque profil d’utilisateur. De plus, les catégories issues de l’analyse faite au préalable (personas), seront très utiles lors de la restitution des données. Cette restitution de statistiques existe sous différentes formes dans Sitecore, mais ce sera l’objet d’un prochain billet sur ce blog.