Altova MobileTogether Server

Les boutons de l'onglet présentent les fonctions suivantes :

Autres actions disponibles :

•Pour naviguer vers le haut dans la hiérarchie du conteneur, cliquer sur le dossier ancêtre requis dans le chemin dans la partie supérieure de l'onglet Flux de travail

•Pour naviguer vers le bas dans la hiérarchie du conteneur, cliquer sur un conteneur pour l'ouvrir

•Cliquer sur une URL d'un fichier de solution pour exécuter la solution

Paramètres d'entrée

Vous pouvez spécifier les paramètres d'entrée sous la forme "Key1=Value1;Key2=Value2;...;KeyN=ValueN". Si une valeur a des espaces, utilisez les guillemets autour de celle-ci. Ces valeurs de paramètre sont passées à la solution quand la solution est démarrée et stockée dans la solution de la variable globale MT_InputParameters (pour information sur laquelle, voir MobileTogether Designer user manual). Les paramètres d'entrée peuvent être utilisés à l'intérieur de la solution pour atteindre différents objectifs, si vous précisez le paramètre d'entrée "Department=Sales", alors il serait possible de filtrer votre base de données pour ne montrer que les enregistrements du département nommé Sales.

Vous pouvez spécifier les paramètres d'entrée d'une solution d'une des manières suivantes :

•Cliquer sur l'icône de la roue située après le nom de la solution. Ceci ouvre le dialogue Changer objet, dans lequel vous pouvez spécifier les paramètres d'entrée de la solution.

•Sélectionner une solution et cliquer sur Créer lien. Dans le dialogue Créer lien qui apparaît, saisissez les paramètres d'entrée de la solution (voir la description du dialogue ci-dessous).

Note :   La variable globale MT_InputParameters d'une solution peut recevoir des paramètres d'entrée de ce point d'entrée MobileTogether Server, mais également de points d'origine associés au design (voir MobileTogether Designer user manual). Dans de tels cas, les paramètres d'entrée sont fusionnés. Si le nom clé est le même, alors la valeur définie pour des raccourcis dans MobileTogether Server prime et sera la valeur attribuée à la clef.

Créer un lien

Vous pouvez créer un lien dans une solution et placer le lien dans un conteneur qui n'est pas le même que celui contenant la solution. Ceci permet à la solution d'être accédée depuis différents conteneurs. L'avantage est qu'en utilisant différents paramètres d'entrée pour chaque lien, la solution peut apparaître de différentes manières lorsqu'elle est ouverte via différents liens. Par exemple, vous pourrez créer un lien dans un conteneur nommé Sales et lui donner un paramètre d'entrée "Department=Sales". Dans la solution, vous pouvez préciser que lorsque la solution est ouverte, elle sera filtrée sur la valeur du nom de département dans son paramètre d'entrée. Donc, lorsque la solution est ouverte via le lien dans le conteneur Sales, les enregistrements de la solution seront filtrés pour afficher, en raison de son paramètre d'entrée, uniquement les enregistrements du département Sales. Vous pouvez créer d'autres liens dans d'autres conteneurs (disons, pour Accounts ou Legal), et définir des paramètres d'entrée pour eux. Quand la solution est ouverte via ces liens, les enregistrements affichés seraient ensuite filtrés pour le département approprié. La solution ouverte dans de tels cas serait la solution d'origine. La fonction du lien vous permet de présenter et traiter la solution de différentes manières conformément aux paramètres d'entrée correspondant au lien.

Alternativement au cas de l'exemple décrit ci-dessus, la disponibilité des paramètres permet d'autres scénarios variés. Par exemple, un cas d'utilisation puissant serait la possibilité d'utiliser une base de données alternative à la solution.

Notez, toutefois, que dans tous ces cas, ce qui se passe lorsque la valeur du paramètre est transmise à la solution dépend entièrement de la manière dont le paramètre est géré dans le design.

S'il est nécessaire de supprimer les données persistantes ou non dépend de ce qui a été défini quand la valeur du paramètre est passée à la solution. Si la valeur du paramétre a une conséquence stockée dans les données persistantes, alors vous allez éventuellement vouloir supprimer les données persistantes ; autrement, ce n'est pas nécessaire. Notez également l'effet inverse de supprimer les données persistantes, la solution n'aura pas accès aux données persistantes. Elle tentera d'utiliser les données fournies via les paramètres et, si les données ne remplacent pas les données persistantes, alors la solution pourrait démarrer avec des données manquantes ou avec des données inappropriées.

Cliquer le conteneur public pour ouvrir le conteneur et afficher son contenu. public est un conteneur prédéfini contenant des exemples de fichiers de design (solutions) fournis avec le programme. Cliquer sur une URL de solution pour l'exécuter.

Un conteneur contient des sous-conteneurs et/ou des solutions (aussi nommées fichiers de design  ou fichiers .mtd). Les contenus de chaque conteneur sont affichés en tant que liste tabulaire. Les colonnes de la table affichent les propriétés des solutions :

•Nom : nom du fichier de solutions tel qu'enregistré dans MobileTogether Designer.

•Appli, version d'Appli : les colonnes Appli et Ver appli apparaissent uniquement si au moins une Appli d'AppStore (voir le manuel d'utilisateur MobileTogether Designer) a été déployée sur le serveur. Elles affichent respectivement, le nom de l'Appli d'AppStore et sa version.

•Description : brève description de la solution qui peut être saisi en cliquant dans le champ.

•Version : version de MobileTogether Designer dans laquelle la solution a été créée.

•Dernier déploiement le : la date et l'heure du dernier déploiement de la solution.

•Dernier accès le : la date et l'heure du dernier accès de la solution.

•Configuration de la ressource globale : la ressource globale qui a été définie pour cette solution et déployée sur le serveur. Si aucune ressource globale n'est spécifiée, Default s'affichera.

•Données persistantes : un bouton Effacer apparaît dans cette colonne si les données ont été modifiées pendant l'exécution de la solution. Cliquer sur le bouton si vous souhaitez annuler les modifications.

•Test automatisé : Un symbole de roue bleu indique qu'au moins une marche d'essai pour les tests automatisés de cette solution est disponible, mais qu'aucune marche d'essai n'est active. Une roue rouge signifie qu'au moins une marche de test parmi les marches de test disponibles est active. Pour activer la marche de test d'un design ou pour configurer comment la marche de test est lue sur le client, cliquer sur l'icône de roue de la solution (affichée dans la capture d'écran ci-dessus). Cela affiche une page montrant les tests automatisés de cette solution (voir section suivante ci-dessous). Cliquer sur le roue dans l'en-tête de la colonne filtre l'affichage pour afficher uniquement que ces solutions dans le dossier actuel et le dossier descendant qui contient des tests automatisés. Pour plus d'informations concernant le Test Automatisé, voir la documentation MobileTogether Designer.

•Exécuter dans le navigateur : l'URL du serveur où le fichier de solution est déployé. Cliquer pour exécuter la solution.

Lorsque vous cliquez sur l'icône de la roue dans la colonne Test automatisé d'une solution, une page de configuration s'affiche qui montre le test automatisé de cette solution (capture d'écran ci-dessous).

La page Tests automatisés montre toutes les marches de test qui ont été déployées pour la solution sélectionnée. Vous pouvez configurer des marches de test individuelles pour la lecture sur les appareils clients comme suit :

1.Dans la colonne Activé, vérifiez les marches de test que vous souhaitez activer. Ces marches de test seront donc lues sur le client lorsque l'utilisateur lance une solution. Si plusieurs marches de test sont sélectionnées, toutes les marches de test sélectionnées seront lues lorsque le test est démarré sur le client. Si une de ces marches de test a été activée, alors, sur la page Flux de travail, la roue dans la colonne Tests automatisés du design sera affichée en rouge. Si vous souhaitez lire une marche de test sur le client Web, sur la page Flux de travail, cliquer sur l'icône Lecture dans la colonne Test automatisé.

2.Définir la vitesse de la marche de test dans la colonne Type exécution.

3.Définir les détails de log que vous souhaitez pendant la lecture. Pour ce faire, cochez les colonnes que vous souhaitez. Voir la section Test automatisé dans la documentation MobileTogether Designer pour plus d'informations concernant ces options.

4.Cliquer sur Enregistrer pour terminer.

Si vous souhaitez supprimer une marche de test, sélectionner sa case à cocher dans la colonne tout à fait à gauche et cliquer sur Supprimer sélection en bas.

Permissions

Dans la partie inférieure de la page Tests automatisés (capture d'écran ci-dessous), vous pouvez spécifier : (i) les utilisateurs et les rôles qui peuvent exécuter des tests automatisés pour la solution sélectionnée (dans l'onglet Sécurité), et (ii) les appareils sur lesquels des marches de test peuvent être effectués (sélectionnés dans l'onglet Appareils).

•Les utilisateurs et les rôles sont sélectionnés dans l'onglet Sécurité, les appareils sont sélectionnés dans l'onglet Appareils (voir capture d'écran ci-dessus).

•Pour attribuer un utilisateur/rôle ou un appareil dans la liste Autorisée, le choisir dans le volet de gauche et cliquer sur Attribuer (voir capture d'écran ci-dessus).

•Supprimer un utilisateur/rôle ou un appareil depuis la liste Autorisé en le sélectionnant et en cliquant sur Supprimer.

•Vous pouvez attribuer ou supprimer plusieurs sélections à la fois.

•Si aucun appareil n'est attribué à la liste Autorisé, les marches de test pour cette solution peuvent être exécutées sur tous les appareils.

Note :   Tous les tests automatisés qui ont été déployés avant une mise à jours de la version 4.1 (publiée le 27 février 2018) ou plus tard, obtiendront une permission de sécurité pour tous les utilisateurs/rôles ; cela signifie que tous les utilisateurs/rôles peuvent exécuter des tests automatisés. Il s'agit du même comportement que celui avant la mise à niveau. Pour les tests automatisés qui sont déployés après une mise à niveau à la version 4.1, les permissions de sécurité sont définies pour aucun utilisateur/rôle ; cela signifie que tout utilisateur ou rôle qui peut exécuter des tests automatisés doit être spécifié explicitement.

Les permissions sont des droits d'accès et elles peuvent être définies individuellement pour chaque conteneur. Les permissions déterminent quels utilisateur ou rôles ont accès à ce conteneur et quel type d'accès chaque utilisateur/rôle a (lecture, écriture, utilisation). Ces droits d'accès peuvent être définis pour le conteneur, ses flux de travail (ou solutions) et la sécurité lecture/écriture.

Règles de l'héritage des permissions

Les permissions sont vérifiées pour chaque interaction d'utilisateur. Un utilisateur peut uniquement accéder avec succès et/ou éditer lorsque toutes les permissions nécessaires sont accordées. Les permissions sont définies pour les groupes suivants :

Conteneur

•Lire : l'utilisateur peut faire une liste des contenus et trouver un objet dans le conteneur.

•Lire-écrire : outre l'écriture, permet de lire, de créer de nouveaux objets (et de supprimer des objets existants), selon les autres permissions pouvant s'appliquer.

Flux de travail

•Lire : l'utilisateur peut exécuter des solutions.

•Lire-écrire : l'utilisateur peut également écrire sur des données de solution. Pour modifier les données de fichiers, l'accès écriture doit aussi être accordé pour le conteneur.

Sécurité

•Lire : l'utilisateur peut lire la liste de permission de tout objet enfant du conteneur.

•Lire-écrire : l'utilisateur peut aussi changer la liste de permissions de tout objet enfant du conteneur.

•Par défaut, un utilisateur peut lire uniquement les permissions qui lui sont attribuées ou un rôle dont il est membre. Si le privilège Lire utilisateurs et Rôles est accordé (voir Utilisateurs et rôles), les utilisateurs peuvent lire toutes les entrées de permission.

Modifier les permissions d'un conteneur