Migration mobile de la version Madrid vers la version New York et versions ultérieures
Migrez vos applications Mobile vers la version New York ou versions ultérieures pour profiter de fonctionnalités améliorées et continuer à effectuer des modifications dans Studio.
Changements apportés lors de votre mise à niveau
- Clients natifs
- Ajoute la table Clients natifs [sys_sg_native_client]. Les enregistrements de cette table représentent les clients natifs disponibles ; Agent mobile, Now Mobile et Mobile Onboarding.
- Barre de navigation
- Ajoute la table de navigations [sys_sg_navigation]. Les enregistrements de cette table représentent une barre de navigation pour chacun des clients natifs. Le champ Application héritée [legacy_application] des enregistrements de cette table au cours de la migration est activé.
- Onglet Notifications
- Ajoute la table des onglets de notification [sys_sg_notifications_tab]. Les enregistrements de cette table représentent un onglet de notifications sur chaque barre de navigation.
- Onglet Paramètres
- Ajoute la table des onglets Paramètres [sys_sg_settings_tab]. Les enregistrements de cette table représentent un onglet pour les paramètres de chaque barre de navigation.
Cette mise à niveau inclut de nouvelles fonctionnalités telles que des lanceurs d’applications et une barre de navigation configurable. Toutes les applications mobiles du système de base non modifiées installées sur votre instance sont automatiquement mises à jour pour fonctionner avec la nouvelle conception et peuvent être utilisées Studio immédiatement. Pour en savoir plus sur la hiérarchie des appareils mobiles utilisée dans et les versions ultérieures, reportez-vous à New York la section Hiérarchie mobile.
Les applications du système de base modifiées et les applications que vous avez créées continueront Madrid de fonctionner après la mise à niveau. Ces applications ne sont pas configurables dans Studio une fois que vous avez exécuté le script de migration mobile.
Considérations postérieures à la mise à niveau
Après une mise à niveau, tenez compte des informations suivantes pour confirmer que votre implémentation mobile fonctionne comme prévu et assurez-vous que le script de migration mobile s’exécute.
- Applications du système de base modifiées
- Documentez toutes les modifications que vous avez apportées aux applications mobiles fournies par , ainsi qu’aux ServiceNow applications que vous avez créées. Testez chacune de ces applications pour vous assurer qu’elles continuent de fonctionner comme prévu.
- Utiliser la fonction de débogage de mise à niveau
La fonctionnalité de débogage de mise à niveau peut vous aider à diagnostiquer rapidement les problèmes de mise à niveau. Pour plus d’informations sur cette fonctionnalité, voir Déboguer la mise à niveau.
Une formation vidéo sur cet outil est disponible. Pour afficher ce cours, voir Utilisation du débogage de mise à niveau
- Examiner les enregistrements ignorés
Pour éviter de remplacer vos personnalisations, le processus de mise à niveau ne met pas à jour les enregistrements que vous avez modifiés. Au lieu de cela, le processus de mise à niveau note cet enregistrement ignoré dans les journaux de mise à niveau.
Un cours de formation vidéo sur la résolution des enregistrements ignorés est disponible. Pour consulter ce cours, consultez Mettre à niveau les enregistrements ignorés.
- Examiner les fonctionnalités après la mise à niveau
- Une fois que vous avez mis à niveau votre instance et exécuté le script de migration, les tests de régression peuvent vous aider à vous assurer que vos utilisateurs peuvent continuer à travailler comme prévu après une mise à niveau. Un test de régression est un examen de vos applets, de vos politiques d’interface utilisateur d’écran et de vos fonctions pour vous assurer qu’ils fonctionnent comme prévu.
Exécution du script de migration mobile
Ce script convertit vos applications personnalisées et toute application du système de base modifiée vers le nouveau schéma mobile disponible dans la version (release New York ). Le script ne modifie le champ d’application actuel que lorsqu’il s’exécute. Si vous disposez de plusieurs applications mobiles incluses dans le périmètre, vous devez exécuter le script pour chaque périmètre.
Après une mise à niveau, l’option d’exécution du script de migration s’affiche lorsque vous accédez pour la première fois à une application personnalisée ou à une application du système de base que vous avez modifiée. Par exemple, lors de l’ouverture d’un enregistrement d’applet modifié ou personnalisé. Vous pouvez également voir l’invite de migration lorsque vous accédez au sélecteur d’applet dans Studio en accédant à et en cliquant sur l’icône contextuelle ( 
). L’invite de migration s’affiche si l’une des applets affichées dans le sélecteur nécessite une migration.
Une fois le script terminé, vous pouvez être invité à résoudre les collisions détectées par le processus de migration. Les collisions sont des enregistrements créés par ServiceNow que vous avez modifiés et qui ne sont pas automatiquement mis à niveau. Les collisions ne peuvent se produire que lorsque vous avez modifié une application système de base avant votre mise à niveau vers des New York versions ultérieures ou ultérieures.
Changements apportés par le script de migration mobile
Cliquez sur Migrer pour démarrer le script de migration pour le périmètre actuel. Le script de migration migre tous les enregistrements dans le champ d’application, pas seulement l’applet que vous avez ouvert.
- Transition des applications et des dossiers vers les lanceurs d’applet
Le schéma hérité Madrid utilisait des applications mobiles et des dossiers pour organiser vos applets. Le Now Mobile schéma utilise des écrans de lanceur d’applet, qui sont divisés en sections d’interface utilisateur. Le lanceur d’applet est accessible en appuyant sur les onglets de la barre de navigation qui apparaît en bas des écrans de votre application.
Figure 1. Modifications apportées aux applications dans le New York schéma Le script de migration crée un lanceur d’applet pour chaque enregistrement d’application mobile. Le script convertit chaque dossier de l’application mobile d’origine en une nouvelle section d’icône horizontale dans ce lanceur d’applet. Le script crée ensuite une icône dans la section des icônes pour chaque applet avec le dossier. Les écrans masqués n’apparaissent pas dans la section des icônes. Le script ajoute ensuite un onglet à la barre de navigation pour chacun des nouveaux lanceurs d’applet.
L’exemple d’image montre comment l’application des incidents apparaît après le processus de migration. Les dossiers d’origine (Mes incidents et Incidents de groupe) s’affichent sous forme de sections d’interface utilisateur dans le lanceur d’applet Incidents . Ces sections de l’interface utilisateur peuvent défiler horizontalement pour afficher autant d’applets que nécessaire. L’application Incidents est accessible en appuyant sur l’onglet Incidents dans la barre de navigation.
Après la migration, le script supprime les enregistrements de dossier [sys_sg_folder] et d’application mobile [sys_sg_application] hérités.
Pour en savoir plus sur la barre de navigation, les lanceurs d’applet et leurs sections d’interface utilisateur, reportez-vous aux sections Barre de navigation, et Écrans du lanceur.
- Migration de formulaire
- L’applet Formulaire remplace les écrans de détails racines utilisés pour afficher les formulaires d’enregistrement dans la Madrid mise en production. La migration crée un enregistrement d’écran de formulaire [sys_sg_form_screen]. Le script crée des segments pour chaque écran incorporé dans l’écran de détails principal d’origine. N’importe quel bouton [sys_sg_button] enregistrements associés à l’écran de détails principal d’origine Changement à associer au nouvel applet de formulaire.
- Migration de carte
- Les applets de carte n’utilisaient pas de vue d’élément pour afficher les champs dans les cartes de carte dans la Madrid version. Le script de migration crée un enregistrement de vue d’élément[sys_sg_item_view] pour chaque applet de carte à l’aide des champs Titre, Balise, Sous-titre et Informations de l’applet de carte d’origine.
- Migration du calendrier
- Le script de migration crée des enregistrements de flux d’éléments d’intervalle de temps [sys_sg_time_span_item_stream] pour chaque calendrier et associe l’élément de données d’origine du calendrier au nouveau flux d’éléments. Le script de migration crée également un enregistrement d’applet de formulaire [sys_sg_form_screen] et migre les boutons de l’écran incorporé d’origine des calendriers vers le nouveau formulaire.
- Flux d’éléments et configurations d’éléments
Le script de migration crée un enregistrement de flux d’éléments [sys_sg_item_stream] pour chaque écran de l’application incluse dans le périmètre. L’enregistrement d’élément de données d’origine associé à l’application héritée est modifié pour être associé au nouvel enregistrement de flux d’éléments. Le script crée des enregistrements de flux d’éléments d’intervalle de temps [sys_sg_time_span_item_stream] pour chaque écran de calendrier et des enregistrements de flux d’éléments d’emplacement [sys_sg_location_item_stream] pour les écrans de carte. Ces deux tables sont issues de la table de flux d’éléments, mais sont utilisées spécifiquement pour ces types d’écran.
- Nettoyage d’écran
- Les champs suivants ne sont plus utilisés dans les enregistrements d’écran. Le script supprime ces champs des enregistrements d’appels dans la table Écran [sys_sg_screen].
- Rôles d’utilisateur [application_roles]
- Ordre [order]
- Parent [parent]
- Table parente [parent_table]
- Élément de données [sys_sg_data_item]
- Masqué [masqué]
En outre, le script supprime également les valeurs des champs suivants des enregistrements de l’écran de carte [sys_sg_map_screen] :- Table d’éléments de données [data_item_table]
- Titre [title]
- Sous-titre [sous-titre]
- Informations [info]
- Emplacement [location]
- Balise [tag]
- Couleur de police de la balise [tag_font_color]
- Couleur d’arrière-plan de la balise [tag_background_color]
- Style de la balise [tag_style]
- Téléphone [phone]
- Type de couleur d’épingle [pin_color_type]
- Couleur d’épingle [pin_color]
Le script supprime les valeurs des champs suivants dans les enregistrements de configuration d’élément [sys_sg_master_item] :- Table [table]
- Écran [écran]
- Condition [condition]
- Ordre de condition [condition_order]
Le script supprime la valeur du champ Vue d’élément [item_view] des enregistrements de l’écran de détails [sys_sg_details_screen].
Le script supprime la valeur du champ Vue d’élément [item_view] des enregistrements de l’écran de liste [sys_sg_list_screen].
Le script supprime la valeur du champ Élément de données [data_item] des enregistrements Vue d’élément [item_view].
Plus de ressources
Pour plus d’informations sur le processus de migration, consultez le Guide de migration mobile pour New York sur le site de la ServiceNow communauté. https://community.servicenow.com/community?id=community_article&sys_id=f5121a33dba7f788fff8a345ca961957