Catégorie : Administration

MOSS 2007 : Optimiser le chargement d’un formulaire Infopath.

SOMMAIRE

  • 1. INTRODUCTION
  • 2. DEUX TYPES DE TEMPS DE CHARGEMENT : COTE SERVEUR ET COTE CLIENT
  • 3. ENVISAGER DES CHARGEMENTS EN  » DUR  » VIA DES LISTES XML
    • 3.1. Cas d’utilisation
    • 3.2. Comment faire ?
    • 3.3. Bilan
  • 4. LE MEILLEUR COMPROMIS : UTILISER DES LISTES SHAREPOINT
    • 4.1. Cas d’utilisation
    • 4.2. Comment faire ?
    • 4.3. Bilan
  • 5. SCINDER EN DIFFERENTES VUES
  • 6. CONNEXIONS DIRECTES A LA BDD VIA DES FICHIERS UDCX EN CAS D’UTILISATION INTENSIVE DE SERVICES WEB
    • 6.1. Cas d’utilisation
    • 6.2. Comment faire ?
    • 6.3. Bilan
  • 7. MESURE DES GAINS
  • 8. BILAN

1. INTRODUCTION

En cas de lenteur de chargement d’un formulaire Infopath Form Services client léger (affichage sur navigateur web), une première piste à étudier serait les connexions de données. En effet, le temps de chargement des paramètres de connexion peuvent être longs, surtout si un grand nombre de données est rapatrié sur le client pour alimenter des listes déroulantes.

2. DEUX TYPES DE TEMPS DE CHARGEMENT : COTE SERVEUR ET COTE CLIENT.

Côté serveur, les traitements qui mettront le plus de temps sont :
– Toute la logique programmée dans le Form_Load du formulaire dans le code managé.
– La connexion aux sources de données et la mise en forme des données à envoyer au client.
Côté client, surtout sous IE6, ce qui mettra le plus de temps est l’ingestion des données servant à alimenter les listes déroulantes. Plus ces données sont nombreuses, plus le client subira un temps  » bloqué  » où le CPU se caractérise par un taux d’occupation à 100%.
C’est donc sur ces deux aspects qu’il faudra jouer pour limiter le temps global de chargement d’un formulaire.

3. ENVISAGER DES CHARGEMENTS EN  » DUR  » VIA DES LISTES XML.

Le plus gros gain de temps à gagner est en utilisant des fichiers XML qui alimentent les listes déroulantes.

3.1. Cas d’utilisation

Pour des connexions secondaires alimentant des listes déroulantes dont le contenu ne change pas souvent, voire jamais.
NB : On aurait pu entrer manuellement ces données dans la liste, mais l’utilisation de listes XML permet une maintenance plus simple (on n’aura pas a retoucher le formulaire, mais seulement les fichiers XML avant de republier).

3.2. Comment faire ?

Le fichier XML peut simplement être de la forme :
 


mon_id
ma_valeur
�

 
Pour déclarer le fichier XML en tant que source de données, il suffit de faire :

  • Outils > Connexions de données > Ajouter.
  • Créer une connexion dans > Réception des données.
  •  » Suivant « .
  • Choisir  » Document XML « .
  •  » Suivant « .
  • Donner le chemin vers le fichier XML créé.
  •  » Suivant « .
  • Sélectionner  » Inclure les données� « .
  •  » Suivant « .
  •  » Terminer « .

La source de données est utilisable comme n’importe quelle autre. En tant que connexion secondaire, voici ce que cela donnerait pour une liste déroulante :

3.3. Bilan

Avantage : Le plus gros gain de temps de chargement côté serveur.
Inconvénients : Nécessité de republier le formulaire si la liste change. Stockage et mise à jour des fichiers XML via des lots DTS ou des moulinettes.

4. LE MEILLEUR COMPROMIS : UTILISER DES LISTES SHAREPOINT

Rapatrier des données à partir de liste SharePoint constitue le meilleur gain de temps côté serveur ET côté client.

4.1. Cas d’utilisation

Pour des connexions de données secondaires utilisées pour les listes déroulantes.

4.2. Comment faire ?

Considérons que les listes SharePoint existent, et qu’elles possèdent simplement deux colonnes :  » _id  » et  » _value  » :
Pour créer une connexion de données secondaire liée à cette liste sous InfoPath, il faut :

  • Cliquer sur Outils > Connexions de données > Ajouter.
  • Créer une connexion dans > Réception des données.
  • Faire  » Suivant « .
  • Choisir  » Bibliothèque ou liste SharePoint « .
  • Faire  » Suivant « .
  • Donner l’URL du site SharePoint.
  • Faire  » Suivant « .
  • Choisir la liste SharePoint correspondante (ici, ce serait  » FE_SITE « ).
  • Faire  » Suivant « .
  • Choisir les colonnes  » _id  » et  » _value « .
  • Faire  » Suivant « .
  • Faire  » Suivant « .
  • Cliquer sur  » Terminer « .

La connexion de données est prête à être utilisée en tant que connexion secondaire.

4.3. Bilan

Avantage : Gains de chargement des deux côtés, serveur et client. Plus simple à maintenir que des listes en dur dans le formulaire (via XML ou non).
Inconvénient : Les modifications sont faciles, il est donc aussi plus facile aussi de corrompre d’intégrité des données en modifiant un identifiant par exemple.

5. SCINDER EN DIFFERENTES VUES

Même s’il s’avère que l’ensemble des connexions de données et des données sont rapatriées sur le client même si elles ne seront pas utilisées par la vue affichée, cette solution est intéressante pour gagner en temps de chargement côté client.
Avantage : Meilleur gain de temps à gagner côté client.
Inconvénients : Les fonctionnalités du formulaire ne sont peut-être pas adaptées à un fonctionnement par vues.

6. CONNEXIONS DIRECTES A LA BDD VIA DES FICHIERS UDCX EN CAS D’UTILISATION INTENSIVE DE SERVICES WEB

Si l’utilisation de Services Web est obligatoire pour recevoir ET mettre à jour des données, elle ne l’est pas pour simplement recevoir des données.

6.1. Cas d’utilisation

Pour des connexions de données secondaires utilisées pour les listes déroulantes.
En effet, utiliser des services web en connexion secondaire qui retournent simplement des libellés est quelque peu abusif. Il faut envisager des connexions directes à la base de données.
Attention, dans notre cas de formulaires Infopath client léger, il faut utiliser obligatoirement des connexions de données stockées dans les fichiers UDCX eux-mêmes présents dans une bibliothèque SharePoint. Des connexions directes embedded dans le formulaires sont impossibles, sous peine d’erreurs 6932 au chargement.

6.2. Comment faire ?

Etape 1 : Créer une connexion de données classique :

  • Outils > Connexions de données > Ajouter.
  • Créer une connexion dans > Réception des données.
  •  » Suivant « .
  • Choisir  » Bases de données « .
  •  » Suivant « 
  • Cliquer sur le bouton  » Sélectionner une base de données  » et choisir le fichier ODC de liaison vers la BDD adéquat (le créer si nécessaire).
  • Choisir la table de laquelle seront extraites les données.
  • Cliquer sur  » OK  » si un message d’avertissement sur les mots de passe apparait.
  •  » Suivant « .
  •  » Suivant « .
  •  » Terminer « .

Etape 2 : Convertir en fichier UDCX hébergé dans une bibliothèque SharePoint :

  • Outils > Connexions de données.
  • Choisir la connexion fraichement créée
  • Cliquer sur  » Convertir « 
  • Une popup s’affiche, cliquer sur  » Parcourir « .
  • Entrer l’URL puis un nom de fichier UDCX pour cette connexion. L’URL est celle du site SharePoint + la bibliothèque de connexion de données. Exemple : http://203.34.222.205/sites/DevSAGA/DC.
  • Cliquer sur  » OK « .
  •  » Fermer « .

La source de données est utilisable comme n’importe quelle autre dans InfoPath.

6.3. Bilan

Avantages : Gains en temps de chargement Serveur.
Inconvénients : Il n’y en a pas en particulier.

7. MESURE DES GAINS

Voici un tableau qui récapitule des temps de chargements du même formulaire, mais avec quatre versions de connexions de données différentes :

  • Par Normal, il faut entendre un formulaire utilisant 38 connexions de données, toutes se servant de Web Services pour recevoir ou envoyer des données. Ce formulaire contient 19 listes déroulantes (!!).
  • UDCX : Signifie que 13 connexions sur les 38 ont été remplacées par des liens directs vers la base de données. Ces connexions secondaires sont toutes utilisées pour rapatrier les libellés des données affichées dans les listes déroulantes.
  • MOSS : 13 connexions vers des web services sur 38 sont remplacées connexions sur des listes SharePoint.
  • XML : Ces mêmes connexions de données sont cette fois ci des listes en dur dans le formulaire, alimentées à la base par un fichier XML.
  • VUES : On reprend le formulaire normal et ses 38 connexions de données, mais on le scinde en deux vues. La vue chargée par le navigateur contient alors  » seulement  » 12 listes déroulantes au lieu de 19.

Six mesures ont été faites, chacune prend en compte le temps de chargement serveur (S), client ( C) et le temps total (T).

Test N� 1 2 3 4 5 6 Moyenne
S C T S C T S C T S C T S C T S C T S C T
Normal 13,2 9,04 22,2 14,75 8,60 23,35 18,14 8,74 26,88 14,89 8,88 23,77 14,81 8,97 23,78 15,82 9,01 24,83 15,26 8,87 24,14
UDCX 10,9 9,02 19,9 14,26 9,27 23,53 12,20 9,15 21,35 12,53 9,22 21,75 12,04 9,20 21,24 12,54 9,20 21,74 12,41 9,18 21,59
MOSS 9,64 8,18 17,8 10,12 7,89 18,01 10,94 8,22 19,16 12,70 7,95 20,65 11,15 7,72 18,87 11,79 7,96 19,75 11,06 7,99 19,04
XML 9,35 8,88 18,2 9,76 8,71 18,47 10,37 9,37 19,74 9,93 8,62 18,55 9,54 8,67 18,21 9,95 8,77 18,72 9,82 8,84 18,65
VUES 14,4 7,09 21,5 14,85 7,00 21,85 15,24 6,97 22,21 15,48 6,98 22,46 15,41 6,88 22,29 14,24 6,87 21,11 14,93 6,97 21,90

Tableaux des gains en % :

Serveur Client Total
Normal 0,00 0,00 0,00
UDCX 18,69 -3,42 10,56
MOSS 27,55 9,99 21,10
XML 35,68 0,41 22,71
VUES 2,15 21,51 9,27

Trois résultats sont intéressants :

  • En vert, on se rend compte d’un gain important de chargement côté serveur lorsqu’on utilise des listes en dur inclues dans le formulaire.
  • En jaune, un gain évident de temps de chargement côté client lorsqu’on scinde de formulaire en plusieurs vues.
  • En bleu, l’utilisation de listes SharePoint fait gagner en performance sur les deux fronts !

8. BILAN

Dans un formulaire InfoPath complexe et qui comprend de nombreuses connexions de données, il ne faut pas hésiter à utiliser divers types de connexions, chacun ayant son cas d’utilisation :

  • Des listes en  » dur  » pour les données qui n’évoluent jamais. On gagne en connexions gourmandes. Cette solution est tout de même à éviter.
  • Des listes alimentées directement par des connexions directes à la BDD, c’est toujours moins lourd que de passer par des Web Services.
  • Scinder le formulaire en vues, ce qui limite ostensiblement la casse côté client.
  • Un choix judicieux : l’utilisation de listes SharePoint. Des gains ostensibles côté serveur et client, mais obligation de créer des listes (ce qui peut être fastidieux à faire) et attention aux droits d’accès à ces données.