Help Center > Foundation Help

S’applique à :

  • Winshuttle Foundation

Amélioration des performances des formulaires de Composer

Rubriques connexes

Les recommandations suivantes vous permettront de résoudre les problèmes liés aux solutions et à améliorer leurs performances.

La plupart de ces options de résolution des problèmes s’appliquent également aux solutions Designer, mais cette section fait référence à Composer comme outil de création de solutions.

Dans cette page

Amélioration du temps de chargement des formulaires

Limiter les connexions de données

Retour au début

Écran Connexions de données de Winshuttle Composer

Les connexions de données Winshuttle Composer (listes SharePoint, base de données SQL, fichiers Excel, etc.) peuvent être utilisées comme sources (ou destinations) des données de processus. Par exemple, vous pouvez utiliser les connexions de données pour remplir les champs déroulants ou effectuer des recherches dans une base de données, par exemple).

Chaque connexion de données peut impacter les performances des solutions à différents degrés.

Lors de l’ajout d’une nouvelle connexion de données à la solution, apparaît la case à cocher Extraire automatiquement les données lors de l’ouverture du formulaire.

Si vous cochez la case, le formulaire ouvre la connexion de données, même si les données ne sont pas nécessaires lorsque le formulaire est ouvert.

Ce paramètre peut avoir un impact considérable sur l’ouverture d’un formulaire.

Par exemple, si une connexion de données est la source d’un contrôle de requête qui exécute une modification de champ, les données ne sont pas nécessaires tant que le contrôle de requête n’est pas déclenché, à savoir que l’utilisateur interagit activement avec le formulaire. Par conséquent, la connexion de données n’a pas besoin de se charger lorsque le formulaire est ouvert.

L’autorisation de l’ouverture des connexions de données uniquement lorsqu’elles sont nécessaires peut améliorer considérablement le temps de chargement initial du formulaire.

Recommandations

  • Dans la plupart des cas, cochez cette case lorsque la connexion de données fait office de source de données pour un champ déroulant. (Autrement, les données ne se chargent jamais dans le champ déroulant, et l’utilisateur ne dispose d’aucune option à sélectionner.)
  • S’il existe un grand nombre de connexions de données comme source de nombreux champs déroulants, remplacez le champ déroulant par un champ de texte avec un contrôle de recherche. La sélection du contrôle de recherche appelle la connexion de données au moment de l’utilisation pour qu’il ne soit pas nécessaire d’extraire les données lors du chargement du formulaire.
  • Il est judicieux de réduire le nombre de colonnes chargées dans la connexion de données aux champs nécessaires uniquement. Ainsi, vous accélérez le délai d’extraction des données depuis la source de données.

Réduire la taille du code XML et HTML

Retour au début

La combinaison unique de XML et HTML permet aux concepteurs de collecter les données de formulaire, mais la plupart des concepteurs ne maîtrisent pas parfaitement la relation entre XML et HTML dans une solution et son impact sur les performances.

Affichage du code XML d’un formulaire Winshuttle

  1. Ouvrez la liste (SharePoint) des formulaires Winshuttle.
  2. Dans la liste SharePoint, placez le pointeur de la souris sur la colonne Titre.
  3. Cliquez sur Afficher l’élément.

Lorsqu’un formulaire s’ouvre, l’ensemble du code XML du formulaire s’ouvre simultanément. Selon les champs conçus dans la vue du formulaire, le code XML est converti en code HTML à afficher à l’attention de l’utilisateur.

Plus un formulaire contient du code XML, plus le chargement du formulaire est long, car plus de code doit être converti en HTML.

Généralement, lors de la création de solutions, des champs et/ou des règles sont utilisés qui ne fonctionnent pas dans les tests, ou un processus utilisé remplace plusieurs champs et/ou règles. Cependant, si ces champs inutilisés ne sont pas supprimés de la solution, le chargement du formulaire est plus long.

L’élimination des « déperditions » dans une solution permet d’améliorer ses performances.

L’affichage et le masquage des champs et des groupes est une fonction pratique de Composer, mais masquer des champs inutiles dans une vue au lieu de les supprimer peut impacter négativement les performances du formulaire. La suppression des champs inutiles peut ne pas accélérer substantiellement le chargement, mais chaque seconde (ou milliseconde) compte.

Réduire les couloirs et améliorer les performances des résolveurs de participants

Retour au début

Les processus Winshuttle tentent de résoudre tous les couloirs dans un workflow à chaque lancement du formulaire. La durée de résolution de chaque résolveur peut varier selon l’opération qu’il exécute, par exemple, interrogation de SharePoint ou d’Active Directory. Tenez compte des points suivants :

  • L’ajout d’un plus grand nombre de couloirs à un workflow allonge la durée du chargement du formulaire.
  • L’augmentation du nombre d’utilisateurs à placer dans un couloir peut réduire les performances.
  • La réduction du volume de données qu’un formulaire doit traiter pour résoudre un couloir améliore les performances de traitement du formulaire.
  • La suppression des couloirs inutiles d’un processus ou l’utilisation de différentes méthodes de résolution des couloirs peut améliorer (réduire) le délai de chargement du formulaire.

Par exemple, lors de l’utilisation de SiteGroupDriver avec les options de contrôle système SelectFromRole, la résolution du couloir est plus longue, car le nombre de personnes dans le groupe SharePoint augmente.

Conseil : Évitez également de pointer vers des listes contenant tous les employés. Envisagez plutôt d’utiliser une requête SharePoint avec un contrôle Résolveur de participant dans la vue de formulaire.

Réduire le traitement dans le formulaire

Retour au début

Si un formulaire se charge rapidement et qu’une requête renvoie des données dans un délai de 60 secondes, l’expérience est médiocre, quel que soit le gain de temps total pour l’utilisateur. Les sections suivantes expliquent comment améliorer le traitement dans le formulaire pour améliorer et accélérer l’expérience utilisateur.

Utiliser la pagination des grands ensembles de données

Retour au début

Une option de pagination de recherche dans les résultats a été introduite dans Composer 11.0.1. La pagination des résultats de la recherche des données permet à un formulaire d’afficher uniquement un nombre limité d’enregistrements à la fois, et donc d’accélérer la recherche et l’affichage des résultats pour l’utilisateur du formulaire.

Cela implique que même s’il existe un grand ensemble de données (et donc un code XML de grande taille), le formulaire affiche uniquement une partie du code XML, et n’affiche l’ensemble suivant de lignes que lorsque l’utilisateur parcourt l’ensemble de résultats. Cela peut avoir un impact important sur les performances dans le formulaire avec de plus grandes tailles de données.

S’il est nécessaire d’afficher de grands ensembles de données dans un formulaire, utilisez la pagination.

Considérer d’autres sources de données

Retour au début

La source d’une requête peut également jouer un rôle important dans le délai de traitement du formulaire. Les sources de données ne fonctionnent pas toutes de manière identique.

Par exemple, vous pouvez ne pas vouloir utiliser un contrôle de recherche SAP F4 sur un champ parce que vous voulez limiter les options accessibles à l’utilisateur en fonction du code d’entreprise. Le contrôle de recherche SAP F4 fournit toutes les options disponibles, mais ne peut pas les manipuler. À la place, vous créez une requête Winshuttle qui s’exécute la nuit et transfère les données dans une liste SharePoint, où vous pouvez maintenant appliquer un filtre en fonction du code d’entreprise.

Explorer d’autres options

Query peut également transférer ces mêmes données dans une base de données SQL, et les professionnels en base de données ont démontré que les requêtes SQL étaient plus rapides que les requêtes SharePoint (CAML).

Le passage de SharePoint à SQL peut avoir un impact minime ou aucun impact sur les petits ensembles de données ou les ensembles de données brutes auxquels sont appliqués un grand nombre de filtres avant de retourner des données.

Un autre avantage de SQL (ou d’autres bases de données, telles qu’Oracle) par rapport à SharePoint réside dans la création de vues, un ensemble de données prédéfini, créé par une requête sur le serveur, pouvant être utilisé comme source de données telle qu’une autre table.

L’utilisation de vues peut accélérer les requêtes, car elles peuvent contenir des données d’une multitude de tables. Elles peuvent également contenir des données auxquelles les filtres nécessaires ont déjà été appliqués.

Créez des vues sur la base de données SQL pour accélérer le traitement dans le formulaire. Si une table SQL source contient 100 000 enregistrements et que le processus ne nécessite qu’un sous-ensemble de ces enregistrements, la requête doit analyser tous ces enregistrements avant de retourner les données. Si vous créez une vue dans la base de données SQL, qui contient uniquement ce même sous-ensemble, la requête analyse moins de données, et le traitement est plus rapide.

Optimiser Winshuttle Query

Retour au début

Généralement, une requête peut être utilisée pour extraire un seul enregistrement à utiliser dans un formulaire, par exemple, des informations d’un article dans une unité donnée. Comment l’optimiser ?

Consultez la section relative à la conception de requête pour déterminer s’il est possible d’effectuer une recherche sur des champs indexés et non pas sur des champs non indexés. La recherche de champs indexés améliore les performances.

En outre, si plusieurs requêtes sont utilisées pour joindre plusieurs tables, essayez d’utiliser des scripts Query individuels pour chaque table et non pas un script qui joint un grand nombre de tables. Cela peut être particulièrement avantageux lorsque la jointure entre la table A et la table B SAP utilise une jointure discordante, une jointure où les champs n’ont pas la même définition.

L’extraction des données de classification SAP est un bon exemple. Les données de classification d’un grand nombre d’objets (articles, fournisseurs, etc.) sont stockées dans les mêmes tables, et les champs utilisés pour la jointure des données de classification sont différents.

Certaines configurations SAP impliquent d’utiliser la table INOB (internal object number table) pour rechercher les données de classification d’un article. Les jointures correctes sont MARA.MATNR => INOB.CUOBJ => AUSP.OBJEK. Le champ INOB.CUOBJ est de 18 caractères alors que la jointure à AUSP.OBJEK est de 40 caractères. Cette discordance affecte gravement les performances de traitement dans le formulaire.

Dans ce cas, la pratique montre qu’il est plus rapide d’interroger MARA et INOB pour extraire la valeur CUOBJ, puis d’utiliser cette valeur dans une seconde requête pour extraire les données depuis AUSP. La division de la requête en plusieurs requêtes n’accélère pas toujours les résultats, mais c’est un autre outil de la boîte à outils.

Mettre à jour les clés de configuration

Retour au début

Généralement, un formulaire exécute plusieurs services Web simultanément en cliquant sur un bouton. Cela peut affecter la réactivité des pages et générer, en fin de compte, des dépassements de délai d’attente du service Web.

Le délai d’expiration par défaut est de 500 secondes. Vous pouvez changer cette valeur, mais cela ne résout pas réellement le problème de réactivité. Cependant, Winshuttle fournit un grand nombre de clés qu’un développeur de solution peut utiliser pour l’exécution d’un processus et du système.

Une de ces clés, WebServiceProgressiveResponse, permet de définir la manière dont une page est mise à jour lorsque plusieurs services Web sont exécutés depuis un même bouton. Si vous affectez à WebServiceProgressiveResponse la valeur True, vous forcez la page à attendre la fin de tous les services Web avant d’actualiser la page.

Si vous lui affectez la valeur False, vous actualisez la page à la fin de l’exécution de chaque service Web, ce qui améliore le temps de réponse et l’expérience de l’utilisateur.

Optimiser les règles

Retour au début

Les règles de formulaire et leurs fonctions présentent de grandes différences. Certaines sont des règles strictement JavaScript qui actualisent les valeurs des champs du formulaire en fonction d’autres valeurs ou paramètres de champs du formulaire. Ces règles JavaScript de base s’exécutent généralement (pas toujours) sur le client, ce qui implique que l’action utilise les ressources système locales (à savoir, le PC de l’utilisateur). Comme les règles côté client ne communiquent pas avec les autres serveurs, la réactivité est généralement bonne.

Se concentrer sur les règles qui s’exécutent uniquement côté client, n’apporte pas d’améliorations considérables (éventuelles), à moins que le code personnalisé contiennent des erreurs.

Les règles qui reposent sur l’interaction serveur, par exemple, requêtes externes et recherches de données, peuvent être optimisées indépendamment pour les améliorer les performances.

L’analyse des règles qui reposent sur l’interaction serveur pour déterminer quand chacun de ces processus peuvent être exécutés est une bonne pratique. Par exemple, la règle peut-elle être exécutée à la fin du formulaire lorsque l’utilisateur l’envoie, ou en arrière plan par le workflow ?

Si des requêtes sont exécutées au chargement du formulaire et que le chargement dure 10 secondes, même si le délai d’attente est le même, l’utilisateur est susceptible de bénéficier d’une meilleure expérience que si le chargement dure 5 secondes et son envoi 5 secondes.

Le délai d’attente est toujours de 10 secondes, mais chaque délai d’attente est plus court. L’exécution des règles à la fin peut ne pas améliorer les délais d’attente cumulés, mais elle peut améliorer l’expérience de l’utilisateur.