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.
Modifications apportées lors de la mise à niveau
- Clients natifs
- Ajoute la table Clients natifs [sys_sg_native_client]. Les enregistrements dans cette table représentent les clients natifs disponibles ; Agent mobile, Now Mobile et Mobile Onboarding.
- Barre de navigation
- Ajoute la table des navigations [sys_sg_navigation]. Les enregistrements dans cette table représentent une barre de navigation pour chaque client natif. Pendant la migration, le champ Application héritée [legacy_application] des enregistrements dans cette table est activé.
- Onglet Notifications
- Ajoute la table des onglets de notifications [sys_sg_notifications_tab]. Les enregistrements dans cette table représentent un onglet pour les notifications sur chaque barre de navigation.
- Onglet des paramètres
- Ajoute la table des onglets des paramètres [sys_sg_settings_tab]. Les enregistrements dans cette table représentent un onglet pour les paramètres sur chaque barre de navigation.
Cette mise à niveau comprend de nouvelles fonctionnalités telles que des lanceurs d’application et une barre de navigation configurable. Toutes les applications Mobile de système de base non modifiées installées sur votre instance sont automatiquement mises à jour pour fonctionner avec la nouvelle conception ; elles peuvent immédiatement être utilisées avec Studio. Pour plus de détails sur la hiérarchie Mobile utilisée dans New York et les versions ultérieures, consultez Hiérarchie Mobile.
Les applications de système de base modifiées et les applications que vous avez créées dans Madrid continueront de fonctionner après la mise à niveau. Ces applications ne seront configurables dans Studio qu’après avoir exécuté le script de migration Mobile.
Considérations suite à 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 vous assurer que le script de migration Mobile s’exécute.
- Applications de système de base modifiées
- Documentez les modifications que vous avez apportées aux applications Mobile fournies par ServiceNow, ainsi qu’aux applications que vous avez créées. Testez chacune de ces applications pour vous assurer qu’elles continuent de fonctionner comme prévu.
- Utiliser la fonctionnalité Déboguer la mise à niveau
La fonctionnalité de débogage de la 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 vidéo de formation dédiée à cet outil est disponible. Pour la visionner, consultez Utilisation de la fonctionnalité Déboguer la 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.
Une vidéo de formation dédiée à la résolution des enregistrements ignorés est disponible. Pour la visionner, consultez Mettre à niveau les enregistrements ignorés.
- Examiner la fonctionnalité 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 permettent de s’assurer que les utilisateurs peuvent continuer à travailler comme prévu après une mise à niveau. Le principe d’un test de régression est d’examiner vos applets, vos politiques d’interface utilisateur de l’écran et vos fonctions pour garantir qu’elles fonctionnent comme prévu.
Exécution du script de migration Mobile
Ce script convertit vos applications personnalisées et les applications de système de base modifiées pour le nouveau schéma Mobile disponible dans la version New York. Le script modifie uniquement le périmètre actuel lors de son exécution. Si vous avez plusieurs applications Mobile 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 apparaît lorsque vous accédez pour la première fois à une application personnalisée ou à une application de système de base que vous avez modifiée. Par exemple, lors de l’ouverture d’un enregistrement d’applet personnalisé ou modifié. Vous pouvez également voir l’invite de migration lors de l’accès 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’un des applets affichés par le sélecteur a besoin d’être migré.
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. Des collisions peuvent uniquement se produire lorsque vous avez modifié une application de système de base avant votre mise à niveau vers New York ou des versions ultérieures.
Modifications apportées par le script de migration Mobile
Cliquez sur Migrer afin de démarrer le script de migration pour le périmètre actuel. Le script de migration migre tous les enregistrements présents dans le périmètre, et pas seulement l’applet que vous avez ouvert.
- Transition des applications et des dossiers vers des lanceurs d’applet
Le schéma Madrid hérité a utilisé des applications Mobile et des dossiers pour organiser vos applets. Le schéma Now Mobile utilise des écrans de lanceur d’applet, qui sont divisés en sections de l’interface utilisateur. Le lanceur d’applet est accessible en appuyant sur les onglets de la barre de navigation qui apparaît en bas de vos écrans d’application.
Figure 1. Modifications apportées aux applications dans le schéma New York 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 d’icône pour chaque applet avec le dossier. Les écrans masqués n’apparaissent pas dans la section d’icône. Le script ajoute ensuite un onglet à la barre de navigation pour chacun des nouveaux lanceurs d’applet.
L’image d’exemple montre comment s’affiche l’application des incidents après le processus de migration. Les dossiers d’origine (Mes incidents et Incidents du groupe) apparaissent sous forme de sections de l’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 hérités Dossier [sys_sg_folder] et Application Mobile [sys_sg_application].
Pour plus de détails sur la barre de navigation, les lanceurs d’applet et leurs sections de l’interface utilisateur, consultez Barre de navigation et Écrans du lanceur.
- Migration de formulaire
- L'applet Formulaire remplace les écrans de détail racine utilisés pour afficher des formulaires d’enregistrement dans la version Madrid. La migration crée un enregistrement d’écran de formulaire [sys_sg_form_screen]. Le script crée des segments pour chaque écran incorporé à l'écran de détail principal d'origine. Les enregistrements de bouton [sys_sg_button] associés à l'écran de détail principal d'origine sont modifiés pour être associés au nouvel applet de formulaire.
- Migration de carte
- Les applets de carte n’utilisaient pas de vue d’élément pour afficher des champs dans des fiches de carte de la version Madrid. 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 Info de l’applet de carte d’origine.
- Migration de calendrier
- Le script de migration crée des enregistrements de flux d’élément d’intervalle de temps [sys_sg_time_span_item_stream] pour chaque calendrier. De plus, il associe l’élément de données d’origine des calendriers au nouveau flux d’élément. 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 des éléments
Le script de migration crée un enregistrement de flux d’élément [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é est modifié pour être associé au nouvel enregistrement de flux d’élément. Le script crée des enregistrements de flux d’élément d’intervalle de temps [sys_sg_time_span_item_stream] pour chaque écran de calendrier, ainsi que des enregistrements de flux d’élément d’emplacement [sys_sg_location_item_stream] pour les écrans de carte. Ces deux tables sont développées à partir de la table de flux d’élément, mais elles sont utilisées spécifiquement pour ces types d’écran.
- Nettoyage des écrans
- Les champs suivants ne sont plus utilisés dans les enregistrements Écran. Le script supprime ces champs des enregistrements d’appel de 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é [hidden]
En outre, le script supprime les valeurs des champs suivants sur les enregistrements d’écran Carte [sys_sg_map_screen] :- Table d’élément de données [data_item_table]
- Titre [title]
- Sous-titre [subtitle]
- Info [info]
- Emplacement [location]
- Balise [tag]
- Couleur de police de balise [tag_font_color]
- Couleur d’arrière-plan de la balise [tag_background_color]
- Style de 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 sur les enregistrements Configuration d'élément [sys_sg_master_item] :- Table [table]
- Écran [screen]
- Condition [condition]
- Commande de condition [condition_order]
Le script supprime la valeur du champ Vue d’élément [item_view] des enregistrements Écran de détails [sys_sg_details_screen].
Le script supprime la valeur du champ Vue d’élément [item_view] des enregistrements Écran de la 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 dédié à la migration Mobile pour New York sur le site de la communauté ServiceNow. https://community.servicenow.com/community?id=community_article&sys_id=f5121a33dba7f788fff8a345ca961957