Résoudre les problèmes des solutions de données de santé dans Microsoft Fabric (version préliminaire)
[Cet article fait partie de la documentation en version préliminaire et peut faire l’objet de modifications.]
Cet article fournit des informations sur les problèmes et les erreurs que vous pourriez rencontrer lors de l’utilisation des solutions de données de santé dans Microsoft Fabric (version préliminaire), et comment les résoudre. L’article comprend également des conseils sur la surveillance des applications.
Si votre problème persiste après avoir suivi les instructions de cet article, utilisez Créer un ticket de support pour soumettre un ticket d’incident.
Résoudre les problèmes de déploiement
Parfois, vous pouvez rencontrer des problèmes intermittents lorsque vous déployez les solutions de données de santé (version préliminaire) dans l’espace de travail Fabric. Voici quelques problèmes couramment observés et des solutions pour les résoudre :
La création de la solution échoue ou prend trop de temps.
Erreur : La création de la solution de santé est en cours depuis plus de 5 minutes et/ou échoue.
Cause : Cette erreur se produit s’il existe une autre solution de soins de santé qui partage le même nom ou qui a été récemment supprimée.
Résolution : si vous avez récemment supprimé une solution, attendez 30 à 60 minutes avant de tenter un autre déploiement.
Échec du déploiement de la capacité.
Erreur : Les fonctionnalités des solutions de données de santé (version préliminaire) ne parviennent pas à se déployer.
Résolution : Vérifiez si la fonctionnalité est répertoriée dans la section Gérer les capacités déployées .
- Si la fonctionnalité n’est pas répertoriée dans le tableau, essayez de la déployer à nouveau. Sélectionnez la vignette de la fonctionnalité, puis sélectionnez Déployer dans l’espace de travail.
- Si la fonctionnalité est répertoriée dans le tableau avec la valeur d’état Échec, créez un nouvel environnement des solutions de données de santé (version préliminaire) et redéployez-y la fonctionnalité.
Dépanner les tables non identifiées
Lorsque les tables Delta sont créées dans la lakehouse pour la première fois, elles peuvent temporairement s’afficher comme non identifiées ou vides dans la vue Explorateur de lakehouse. Cependant, elles devraient apparaître correctement sous le dossier tables après quelques minutes.
Réexécuter le pipeline de données
Pour réexécuter les exemples de données de bout en bout, suivez ces étapes :
Exécutez une instruction SQL Spark à partir d’un notebook pour supprimer toutes les tables d’une lakehouse. Prenons un exemple :
lakehouse_name = "<lakehouse_name>" tables = spark.sql(f"SHOW TABLES IN {lakehouse_name}") for row in tables.collect(): spark.sql(f"DROP TABLE {lakehouse_name}.{row[1]}")Utiliser Explorateur de fichiers OneLake pour vous connecter à OneLake dans votre explorateur de fichiers Windows.
Accédez au dossier de votre espace de travail dans l’Explorateur de fichiers Windows. Sous
<solution_name>.HealthDataManager/DMHCheckpoint, supprimez tous les dossiers correspondants dans<lakehouse_id>/<table_name>. Vous pouvez également utiliser Microsoft Spark Utilities (MSSparkUtils) for Fabric pour supprimer le dossier.Réexécutez tous les notebooks, en commençant par les notebooks d’ingestion dans la lakehouse bronze.
Moniteur Apache Spark applications avec Azure Log Analytics
Les journaux de l’application Apache Spark sont envoyés à une instance de l’espace de travail Azure Log Analytics que vous pouvez interroger. Utilisez cet exemple de requête Kusto pour filtrer les journaux spécifiques aux solutions de données de santé (version préliminaire) :
AppTraces
| where Properties['LoggerName'] contains "Healthcaredatasolutions"
or Properties['LoggerName'] contains "DMF"
or Properties['LoggerName'] contains "RMT"
| limit 1000
Les journaux de la console du notebook enregistrent également le RunId pour chaque exécution. Vous pouvez utiliser cette valeur pour récupérer les journaux pour une exécution spécifique, comme indiqué dans l’exemple de requête suivant :
AppTraces
| where Properties['RunId'] == "<RunId>"
Pour obtenir des informations générales sur la surveillance, consultez Utiliser le hub de surveillance Fabric.
Résoudre les erreurs d’autorisation avec le bloc-notes d’exportation FHIR
Lorsque vous exécutez le notebookd’exportation FHIR healthcare#_msft_fhir_export_service, vous pouvez voir une erreur HTTP 401 : Non autorisé si vous n’avez pas attribué les autorisations requises à l’application de fonction Azure ou au serveur FHIR.
Assurez-vous d’attribuer le rôle Exportateur de données FHIR à l’application de fonction sur le service FHIR et le rôle Contributeur de données blob de stockage au service FHIR sur le compte de stockage d’exportation configuré.
Pour plus d’informations, consultez les étapes postérieures au déploiement dans Déployer l’offre Place de marché Azure.
Résoudre les erreurs de conflit avec le bloc-notes d’exportation FHIR
Lorsque vous exécutez le notebook d’exportation FHIR healthcare#_msft_fhir_export_service, vous pouvez parfois voir une erreur HTTP 409 : Conflit.
L’application de fonction Azure est configurée pour exécuter une seule instance d’exportation à tout moment. Une erreur HTTP 409 signifie qu’une autre opération d’exportation est déjà en cours d’exécution. Attendez qu’elle se termine, puis déclenchez une autre exportation.
Surveiller les journaux des applications de fonction avec Log Analytics
Vous pouvez surveiller les journaux du service d’application de fonction d’exportation dans l’espace de travail Log Analytics déployé sur votre groupe de ressources Azure. Voici un exemple de requête Kusto pour afficher les traces de l’application de fonction :
AppTraces
| where AppRoleName startswith "msft-func-datamanager-export"
Réinitialiser la version d’exécution Spark dans l’espace de travail Fabric
Par défaut, tous les nouveaux espaces de travail Fabric utilisent la version d’exécution la plus récente de Fabric, qui est désormais Runtime 1.3. Toutefois, les solutions de données de santé (version préliminaire) ne prennent actuellement en charge que Runtime 1.2.
Par conséquent, après le déploiement des solutions de données de santé (version préliminaire) sur votre espace de travail, n’oubliez pas de mettre à jour la version d’exécution Fabric par défaut vers Runtime 1.2 (Apache Spark 3.4 et Delta Lake 2.4) avant d’exécuter l’un des pipelines ou notebooks. Sinon, les exécutions de votre pipeline ou notebook peuvent échouer.
Pour plus d’informations, consultez Prise en charge de plusieurs environnements d’exécution dans Fabric Runtime.
Actualiser l’interface utilisateur Fabric et l’explorateur de fichiers OneLake
Parfois, vous remarquerez que l’interface utilisateur Fabric ou l’explorateur de fichiers OneLake n’actualise pas toujours le contenu après chaque exécution du notebook. Si vous ne voyez pas le résultat attendu dans l’interface utilisateur après avoir exécuté une étape d’exécution, (par exemple, créer un dossier ou une lakehouse ou ingérer de nouvelles données dans une table), essayez d’actualiser l’artefact (table, lakehouse, dossier). Cette actualisation peut souvent résoudre les écarts avant d’explorer d’autres options ou d’approfondir les recherches.