Bibliothèques d’action de serveur
Une bibliothèque d’action de serveur est un fichier .mtd qui contient un ou plusieurs Groupes d’action. Sa fonctionnalité est limitée au traitement de ces Groupes d’action. Lors de l’exécution, une solution peut envoyer un appel à une bibliothèque d’action de serveur, avec ou sans les paramètres. La bibliothèque d’action de serveur traite le Groupe d’action spécifié et retourne le résultat à la solution d’appel.
L’avantage d’utiliser une action bibliothèque de serveur est que, puisqu’elle opère de manière autonome par rapport à la solution (appelante) principale, elle peut être modifiée à l’extérieur de la solution. Ceci a des avantages :
•Le design de la solution principale ne doit pas être modifié ;
•En conséquence, il n’est pas nécessaire de déployer une solution principale modifiée sur le serveur (pour mettre à jour la solution existante sur le serveur) ;
•Les appareils client ne doivent pas télécharger la solution modifiée ;
•Si vous modifiez une bibliothèque d’action de serveur, tout ce qui reste à faire est de déployer la bibliothèque d’action de serveur pour qu’elle écrase l’ancienne bibliothèque d’action de serveur. Il s’agit d’un déploiement qui n’affecte pas le flux de travail général exécuté.
Notez, toutefois, que les frais généraux (en termes de traitement et temps) seront plus élevés lorsque vous utilisez un Groupe d’action dans une bibliothèque d’action de serveur que si vous utilisez un Groupe d’action dans la solution principale. De manière conséquente, une bibliothèque d’action de serveur ne devrait être utilisée que si son avantage principal (de modification et exécution autonomes) fournit un avantage apparent par rapport au Groupe d’action dans la solution principale.
MobileTogether Server Advanced Edition
Les bibliothèques d’action de serveur peuvent être déployées vers MobileTogether Server Advanced Edition uniquement, et non vers l’édition standard de MobileTogether Server.
Cas d’utilisation
Par exemple, considérez une situation dans laquelle les données sont extraites depuis la structure de données, qui est en dehors de votre contrôle et qui change de manière arbitraire et à intervalles irréguliers. Il serait difficile de modifier et de déployer une nouvelle solution principale et mettre à jour des solutions déjà téléchargées à chaque fois que la structure des données change. Toutefois, une bibliothèque d’action de serveur pourrait gérer les modifications de la structure de données à l’extérieur de la solution principale, traiter la structure de données modifiée, et retourner les données vers la solution principale pour que les données retournées soient conformes à la structure attendue par la solution.
Les avantages sont évidents :
•La bibliothèque d’action de serveur, puisque son objectif est limité, est plus petite et plus simple que la solution principale et peut être modifiée plus facilement et plus rapidement.
•La structure de données externe modifiée peut être traitée entièrement à l’intérieur de la bibliothèque d’action de serveur pour que les données puissent être extraites de la structure des données et envoyées à la solution principale dans une structure utilisée par la solution principale.
•La bibliothèque d’action de serveur modifiée peut être déployée vers le serveur moyennant une procédure de déploiement simple. La solution principale, qui est également déployée sur le serveur, ne doit pas être modifiée de quelque manière que ce soit. Les solutions déjà téléchargées aux clients n’en seront pas non plus mises à jour.
Exemple
Dans notre description des bibliothèques d’action de serveur dans cette section, nous utilisons l’exemple d’une bibliothèque d’action de serveur qui lit les contenus du dossier spécifié en utilisant l’action Lire le dossier de MobileTogether. Cette action dans la bibliothèque d’action de serveur lit les informations sur chaque item dans le dossier - sous-dossier ou fichier - et stocke l’information sur l’item dans une arborescence XML de la bibliothèque d’action de serveur. L’arborescence de données est envoyée depuis la bibliothèque d’action de serveur à la solution principale en tant que valeur de retour de la bibliothèque d’action de serveur.
Dans notre exemple, la question clé à résoudre dans la solution principale est comment spécifier lesquels des trois dossiers doivent être lus. Disons que la solution principale fonctionne avec trois jeux de données fixes (statique et inchangé) qui sont basés dans la collection actuelle - un pour les livres, films et musique respectivement. Dans la solution principale, l’utilisateur sélectionne un des dossiers (livres, films ou musique) et la solution principale doit lire le dossier sélectionné. Un problème apparaît si l’une des collections sous-jacentes actuelles est changée, car la solution principale utilise des jeux de données fixes et ceux-ci seront alors obsolètes. Un changement pourrait être l’un des points suivants : (i) de nouveaux contenus de dossier ou modifiés, (ii) une structure de données modifiée de l’arborescence de données, et/ou (iii) un autre emplacement de dossier.
Dans notre exemple, nous avons choisi de considérer uniquement un changement d’emplacement de dossier. Si les ensembles de données fixes étaient dans la solution principale et que vous décidiez de les mettre à jour, alors la solution principale modifiée devrait être redéployée sur MobileTogether Server et être retéléchargée sur tous les appareils clients affectés. C’est là où la bibliothèque d’action de serveur entre en jeu. Le(s) (nouveau/x) emplacement(s) de dossier(s) peut/peuvent être spécifié(s) dans la bibliothèque d’action de serveur, de telle manière que la solution principale n’est pas concernée par l’emplacement du dossier. Elle gère directement les données sur le dossier respectif, qui lui seront transférées par la bibliothèque d’action de serveur. Les mises à jour peuvent être réalisées dans la bibliothèque d’action de serveur et la solution principale ne sera pas modifiée. La solution principale peut alors appeler un Groupe d’action de la bibliothèque d’action de serveur. Le Groupe d’action lit les données du dossier pertinent, entrepose les données du dossier dans un nœud d’arborescence et retourne ces données dans la solution principale. Si un emplacement de dossier change, alors la solution principale contiendra les nouvelles données sans devoir être modifiée.
La capture d'écran ci-dessous montre une action de commande de la solution principale. L'action exécute un appel vers un Groupe d’action appelé ScanFolder (qui est défini dans la bibliothèque d’action de serveur appelée ServerLibrary.mtd). L’appel contient un paramètre unique appelé $FolderToScan, la valeur duquel est fourni par l’utilisateur dans la solution principale et stockée ici dans le nœud de source de page. Cette entrée d’utilisateur indique le type d’une collection (livres, films ou musique) que l’utilisateur veut scanner. Lorsque l’appel vers le Groupe d'action est réalisé lors de l’exécution, le Groupe d’action sera exécuté dans la bibliothèque d’action de serveur (qui se trouve en dehors de la solution principale) et les données sur le dossier scanné seront passées de nouveau à la solution principale et stockées dans une variable de solution appelée $FolderReadout. Cette variable, contenant les données du dossier scanné, remplacera les contenus de la source de page $XML1 dans la solution principale (réalisée avec l’action Remplacer le(s) Nœud(s)). En conséquence, les données qui sont maintenant contenues dans $XML1 sont les informations mises à jour sur le dossier scanné.
Veuillez noter les points suivants sur l’appel d’une bibliothèque d’action de serveur et sur la capture d’écran ci-dessus. Pour voir les paramètres pertinents, vous pouvez ouvrir le fichier de tutoriel appelé MainSolution.mtd dans le dossier ServerActionLibraries du dossier des Tutoriels. Afin de scanner un vrai dossier lors d’une simulation, vous devrez spécifier, dans le fichier de bibliothèque d’action de serveur (ServerLibrary.mtd), les chemins vers les vrais dossiers sur votre système (voir la rubrique Créer une bibliothèque d’action de serveur pour les détails).
•La capture d’écran ci-dessus affiche la dialogue des Actions de l’action OnFinishEditing de la seule combo box de la solution principale.
•La sélection de l’utilisateur dans cette combo box qui peut être l’une des valeurs, Books, Film, Music sera enregistrée dans le nœud $PERSISTENT/Root/UserSelection.
•Les bibliothèques d’action de serveur que vous souhaitez accéder depuis la solution principale doit être ajoutée aux bibliothèques d’action de serveur de la solution principale dans le Volet de fichier.
•Une fois que la bibliothèque d’action de serveur a été ajoutée à une solution (voir le point précédent), alors tous les Groupes d’action de cette bibliothèque de serveur seront disponibles automatiquement dans les dialogues d’Action de la solution (voir la section des Groupes d’action dans la capture d’écran ci-dessus).
•Dans la solution principale, de manière générale, Let action est utilisée pour appeler un Groupe d’action de la bibliothèque d’action de serveur (voir la capture d’écran ci-dessus). Ceci est dû au fait que la variable de Let action ($FolderReadout dans la capture d’écran ci-dessus) peut être facilement définie pour recevoir une valeur de retour du Groupe d’action (voir la capture d’écran ci-dessus).
•Lorsqu’un appel est fait dans un Groupe d’action, les paramètres de Groupes d’action - définis dans la bibliothèque d’action de serveur - sont recensés à l’intérieur de la définition Let action. Le Groupe d’action ScanFolder qui est affiché dans la capture d’écran ci-dessus a un paramètre appelé $FolderToScan. Vous pouvez désormais définir la valeur que ce paramètre doit avoir quand l’appel est réalisé vers le Groupe d’action. Dans notre exemple, ce paramètre est la sélection de l’utilisateur, qui est faite par le biais de la combo box de la solution et stockée dans le nœud $PERSISTENT/Root/UserSelection en tant que valeur de la variable $FolderToScan.
•L’action Remplacer le(s) Nœud(s) remplace les données de la source de page $XML1 dans la solution principale avec les données dans la variable $FolderReadout, qui sont les données retournées depuis la bibliothèque d’action de serveur.