INFOPATH 2013 : Enregistrement personnalisé

Aujourd'hui un petit article permettant de détailler l'enregistrement d'un formulaire dans une bibliothèque SharePoint.

 

Rappel : Pour enregistrer le formulaire à la racine de la bibliothèque, il suffit de créer une connexion de données de type "Envoi" vers la bibliothèque de votre choix.

Afin de facilité le déploiement, il est préconisé d'utiliser un fichier "udcx" (universal data connexion) permettant de ne pas laisser l'url d'enregistrement stockée en dur dans le modèle du formulaire). Pour le passage vers un environnement différent, vous aurez uniquement à modifier le contenu du fichier UDCX stocké dans une bibliothèque SharePoint de type "Bibliothèque de connexion".

 

 

Pour plusieurs raisons, notamment pour se conformer aux 'bests practices' de Microsoft, vous pouvez être amené à enregistrer le formulaire dans un répertoire spécifique de votre bibliothèque de formulaire.

Par exemple, si vous partez sur une volumétrie de 2000 formulaires par an, il est préconisé de créer un répertoire par année dans votre bibliothèque.

 

Pour enregistrer votre formulaire dans un répertoire spécifique de votre bibliothèque de formulaire, il suffira d'utiliser le code C# suivant dans l'évènement "Forms_Submit" du formulaire :

 

FileSubmitConnection fileSubmitConnection = (FileSubmitConnection)DataConnections["Envoi formulaire demo "];
fileSubmitConnection.FolderUrl = string.Concat(fileSubmitConnection.FolderUrl, "/", "MonRepertoire");

fileSubmitConnection.Execute();
e.CancelableArgs.Cancel = false;

 

Ainsi, le formulaire s'enregistrera directement dans le répertoire "MonRepertoire" de la bibliothèque de formulaires.

 

SharePoint 2013 : Nouveautés installation

Aujourd'hui un article sur les quelques nouveautés rencontrées lors de l'installation de SharePoint Server 2013.

 

• IFILTER PDF:
  Première nouveauté, et non des moindre : Plus besoin d'installer de IFILTER PDF!
  Enfin en 2013, le IFILTER est incorporé nativement dans les binaires SharePoint. 
 
• Apparition de nouveaux services applicatifs :
• Machine translation Services (traduction de contenu),
• Access Services 2013 (application Access en mode 2013),
• App managment (gestion des applications SharePoint),
• Powerpoint conversion services (Conversion vers PDF),
• Work management services (synchronisation des tâches),
• Distributed cache services (utilisé pour la mise en cache des données sociales et de session).

• Office Web Apps :
  Les Office Web Apps s'installent désormais en dehors de la ferme SharePoint. Il sera possible de configurer une ferme dédiée aux WAC qui pourra être utilisée par toute l'entreprise.
  Attention: ces WACS ne se rattachent à la ferme uniquement par PowerShell.

• Recherche :
  La topologie de recherche, permettant de configurer les serveurs de crawl, de query ou d'administration), se configure uniquement via PowerShell à présent. L'interface disponible en SharePoint 2010 a disparu.

• Workflow :
  Par défaut, seuls les workflow de type SharePoint 2010 sont installé par défaut.
  Drôle de choix quand on sait le plus que peuvent apporter les workflow de type SharePoint 2013.
  Pour utiliser ces workflow basés sur le framework 4.5, vous aurez trois types d'installations disponibles (voir technet : http://technet.microsoft.com/en-us/library/jj219638.aspx):
• Installer les briques "Workflow Manager" et "Workflow client" sur chaque serveur de votre ferme,
• Installer une ferme de Workflow en dehors de votre ferme SharePoint,
• Utiliser Aure workflow,

INFOPATH : Rediriger un formulaire

Aujourd'hui un post rapide concernant la redirection de formulaire InfoPath.

Ce problème est souvent abordé sur les forums car les utilisateurs souhaitent que le formulaire vers une certaines page de leur site SharePoint à la fermeture.

Pour se faire, vous avez 2 options disponibles à utiliser en fonction de vos besoins de redirection :

 

• La version simple : Elle consiste à modifier le paramètre "Source" dans l'url à l'ouverture du formulaire. En effet, le paramètre "Source" permet de préciser l'emplacement vers lequel l'utilisateur sera redirigé à la fermeture du formulaire (après exécution de la connexion de données). Cette méthode conviendra parfaitement si l'adresse de redirection est connue avant l'ouverture du formulaire.

 

• La version complexe : Elle consiste a rediriger en code managé ".Net" celui-ci vers n'importe quel emplacement spécifique  pouvant être calculé dans le formulaire (par exemple url dynamique en fonction de la valeur d'un champ du formulaire, ...):
  HttpContext.Current.Response.Clear();
  HttpContext.Current.Response.Flush();
  HttpContext.Current.Response.Buffer = false;
  HttpContext.Current.Response.Write("Positionner ici le javascript pour la redirection");
  HttpContext.Current.Response.End();

INFOPATH : Impossible de publier le formulaire

Aujourd'hui un petit post sur InfoPath.
Parfois, lorsque vous publiez un formulaire InfoPath sous SharePoint, vous pouvez obtenir ce genre d'erreur sympathique : "InfoPath cannot find or cannot access the following web server"

Après avoir réalisé les vérifications d'usage suivante:

• Tester l'url précisée pour la publication,
• Tester avec une autre bibliothèque,
• Tester avec un autre formulaire,
• Tester depuis un autre poste client,
• Vérifier la connexion au domaine,...

il s'avère qu'aucun formulaire ne veut se publier sur cette fameuse collection de sites.

Pas de panique, il s'agit tout simplement d'un problème de paramètrage sur le type de contenu "Formulaire" de votre collection de sites. Pour corriger cela, vous devez vous connecter à la racine de votre collection de sites SharePoint puis suivre les actions suivantes:

• Aller dans "Actions du site",
• Cliquer sur "Paramètre du site",
• Cliquer sur "Type de contenu",
• Cliquer sur "Formulaire",
• Aller dans les paramètres avancés de ce type de contenu formulaire,
• Supprimer la valeur renseignée dans la première zone de texte correspondant à l'url d'un document existant,
• Cliquer sur OK

A présent, si vous retentez de republier le formulaire, celui-ci sera déployé sans problème.
Simple, mais encore faut-il connaitre l'astuce...

SHAREPOINT 2013 : Licence serveur

Aujourd'hui, un petit article sur SharePoint 2013 et la nouvelle stratégie de licencing.

Auparavant, avec SharePoint Server 2010 vous aviez le choix entre une licence Standard ou une licence Entreprise. Pour rappel, l'iso de SharePoint était identique et seul la clé de licence activait ou non certaines fonctionnalités.

Ce mode de licensing posait problème pour de nombreux clients ayant acquis des licences standards et souhaitant octroyer à une certaine partie de leur population des CALs de niveau entreprise. La préconisation initiale était de monter 2 fermes différentes (sic). La réaction des clients étant évidemment virulente, cela s'est mué en accords déclaratifs.

 

A présent, révolution dans SharePoint 2013: il est possible de mixer les types de licence (4 types différent : standard, entreprise, web apps, duet).
Bizarrement pour brider les CALs, et ainsi l'utilisation des fonctionnalités entreprise, il n'est pas possible d'utiliser l'interface. Il faut passer par l'utilisation de commandes Powershell.

Voici un exemple de commandes permettant de limiter finement l'utilisation des licences:

 

# Affichage du mode de licence actuellement en place sur la ferme (true ou false, false par défaut)
Get-SPUserLicensing

# Autorise la mise en place de mode de licensing distinct
Enable-SPUserLicensing

# Vérification des types de licence disponible (standard, entreprise, web apps, duet)
Get-SPUserLicense

# Affectation de licences entreprise à un groupe AD donné si besoin
$a=New-SPUserLicenseMapping -SecurityGroup "GroupeADEntreprise" -License Enterprise
$a | Add-SPUserLicenseMapping

Ainsi, seuls les utilisateurs positionnés dans le groupe AD nommé "GroupeADEntreprise" auront accès aux fonctionnalités entreprise de SharePoint 2013!

Ceci doit être pris en compte dès la mise en place de la ferme SharePoint afin de ne pas avoir de surprise de cout de licence.