JMP 19 étend la fonctionnalité de connecteur de données introduite dans JMP 18 afin d'offrir un accès uniforme à un plus grand nombre de sources de données. Outre l'ajout de nouveaux types de connexion intégrés, JMP 19 permettra également aux utilisateurs de définir leurs propres types de connexion via une API Python. À l'instar des types intégrés, ces types bénéficieront des avantages du connecteur de données, notamment la gestion de la configuration et l'intégration avec le générateur de requêtes. De plus, étant implémentés en Python, ils pourront exploiter les bibliothèques Python existantes. Cette présentation décrit l'API, aborde les concepts sous-jacents et en donne un exemple concret.
Bonjour. Je suis ici aujourd'hui pour vous parler du framework Data Connector de JMP, et plus précisément de son extension possible avec Python dans JMP 19. Dans JMP 18, nous avons introduit le framework Data Connector et l'avons utilisé pour offrir une connectivité ODBC améliorée. Dans JMP 19, nous allons plus loin.
Vous entendrez peut-être parler ailleurs de la façon dont nous l'utilisons pour nous reconnecter aux solutions SaaS et pour assurer une connectivité native à Snowflake. Nous utilisons également ce même framework, dont je vais vous parler (cette API Python), pour implémenter la connectivité à Amazon S3 et Microsoft SharePoint. Cette connectivité ne sera pas intégrée à JMP, mais distribuée via la Marketplace JMP.
Dans cette présentation, j'aimerais aborder plusieurs points. Tout d'abord, je souhaite expliquer brièvement pourquoi, si vous possédez votre propre source de données, vous pourriez l'intégrer à JMP. Si vous décidez de l'intégrer, vous devrez comprendre comment elle s'intègre, ce que JMP doit faire pour communiquer avec votre source de données et ce que vous devez fournir pour que cela soit possible. En particulier, quel code devez-vous écrire ?
Enfin, nous verrons comment partager votre code. Il fonctionne pour vous, mais d'autres personnes dans votre entreprise pourraient vouloir l'utiliser. Vous pourriez vouloir le partager avec d'autres utilisateurs de JMP dans le monde entier. Pour simplifier cette opération, nous avons choisi Python, notamment grâce aux bibliothèques déjà disponibles et au code que vous avez peut-être déjà écrit. C'est ainsi que nous avons établi les connexions pour Amazon S3 et Microsoft SharePoint. Nous pouvons utiliser des bibliothèques Python existantes, et nous espérons que cela vous facilitera également la tâche.
Une autre raison de procéder à l'intégration, outre la simplicité d'utilisation, réside dans la gestion simplifiée des configurations. L'éditeur de connecteurs et le générateur de requêtes permettent de créer et de modifier les configurations décrivant les connexions. Vous pouvez ainsi créer graphiquement des requêtes, filtrer vos données, sélectionner des colonnes, et bien plus encore. Enfin, la collaboration est facilitée : les connexions et les configurations créées peuvent être exportées et partagées via des modules complémentaires.
Si vous n'avez jamais vu cette fonctionnalité auparavant, vous la découvrirez plus en détail prochainement lors d'une démonstration. Mais avant cela, voyons comment tout s'articule. Pour commencer, vous avez votre source de données, que vous souhaitez connecter à JMP.
Mais lorsque nous parlons de données dans JMP, nous parlons de tables de données. Ces tables peuvent être facilement fournies à partir de votre source de données. Il se peut également que leur création nécessite un traitement. Par exemple, vous disposez peut-être d'un point d'accès web qui renvoie des données JSON structurées hiérarchiquement. Dans ce cas, un traitement sera nécessaire. Mais tant que ces données peuvent être exposées sous forme de table pour JMP, elles peuvent potentiellement être utilisées.
Lorsque Query Builder accède à ces données, il les traite comme s'il s'agissait d'une base de données traditionnelle, telle que MySQL ou SQL Server. Il s'attend à ce que vos données soient organisées en tables nommées, et que ces tables soient potentiellement elles-mêmes organisées en schémas nommés.
Mais vous avez probablement plusieurs sources de données. Ou, à défaut, plusieurs façons d'y accéder. Les utilisateurs peuvent avoir des identifiants différents. Ou vous préférez peut-être ne pas spécifier l'adresse de vos données. Quoi qu'il en soit, vous aurez probablement des options. En définissant des valeurs pour ces options, vous obtenez une configuration. Grâce à cette configuration, vous pouvez créer une source de données. Ces configurations sont créées avec l'éditeur de connecteurs de données.
Voilà, en résumé, la situation. Mais comment cela se traduit-il en code ? Voyons voir. Je suis dans JMP. Fermons cette fenêtre et repartons de zéro. À gauche, nous avons du code qui implémente plusieurs types de connecteurs de données. Un type est par exemple ODBC, intégré à JMP. Il peut s'agir d'un connecteur SaaS, local, distant ou via une connexion. Il peut aussi s'agir de Snowflake. Quoi qu'il en soit, Python est également une option pour tout type de connecteur que vous souhaitez implémenter.
En haut, nous avons des importations. Notamment, le module JMP intégré. Cette fonction utilitaire nous permet de visualiser les appels de fonctions. Elle est utilisée dans cette démonstration car c'est JMP qui appelle le code. Nous n'allons pas l'appeler fréquemment, mais il est important, pour comprendre son fonctionnement, de pouvoir suivre ces appels.
Le code ci-dessous implémente concrètement le type. Avant d'aller plus loin, examinons cette référence. Les différents éléments de cette liste correspondent, à bien des égards, au diagramme que je viens de vous montrer. Nous avons besoin d'options. Pour cela, nous allons créer une sous-classe de `jmp.DataConnectorType` et définir un attribut de champ qui définira ces options. Nous avons une configuration que nous devons convertir en source de données. Nous allons créer une sous-classe de `jmp.DataConnector` et définir une fonction, `_do_as_data_source`, qui effectuera cette conversion.
Enfin, nous avons la source de données elle-même. Il s'agit d'une autre sous-classe. Nous définirons des fonctions qui nous indiqueront les schémas, le cas échéant, nos tables et les données de chaque table. Bien que nous ne le voyions pas dans notre démonstration, il est important de noter que si vous avez des ressources qui ne sont pas automatiquement supprimées (par exemple, une connexion qui ne gère pas ce comportement), vous devrez utiliser la méthode spéciale de Python (avec un double underscore) pour les supprimer lorsqu'elles ne sont plus référencées. En effet, JMP laissera Python gérer cette suppression lors de la fermeture de la source de données.
Partant de ce constat, examinons à nouveau le code. Nous y trouvons SimpleFolderConnectorType, qui hérite de jmp.DataConnectorType. Comme indiqué, cette classe possède des champs contenant des options. La première et unique option est « Dossier ».
Dans ce cas précis, le terme « dossier » désigne notre source de données. Il s'agit d'un dossier unique sur mon système de fichiers local, et ce dossier expose les données sous la forme des fichiers qu'il contient.
Pour commencer, nous aurons « Folder », dont la valeur dans ce dictionnaire décrivant nos options est de type str | None. Cela signifie que nous aurons une valeur de chaîne optionnelle. Ensuite, nous avons notre classe de configuration, SimpleFolderConnector, qui hérite de jmp.DataConnector. Elle définira la fonction _do_as_data_source qui convertira, ou plutôt se connectera, à partir de notre configuration.
Nous pouvons accéder à la valeur de configuration « Dossier » en l'indexant, comme avec un dictionnaire intégré. Nous vérifierons si cette valeur est nulle (si l'utilisateur a omis de renseigner cette valeur par défaut) et, le cas échéant, nous l'informerons de son caractère obligatoire en générant une erreur.
Enfin, nous allons la convertir en source de données. La classe de source de données est la dernière de notre liste. Bien sûr, nous devons pouvoir la créer. Nous définissons une fonction d'initialisation. Nous vérifions, dans ce cas précis, s'il s'agit bien d'un répertoire, car nous voulons informer l'utilisateur (vous-même ou toute personne utilisant le code) en cas d'erreur. Normalement, la connexion à une source de données se fait lors de sa création. Ici, aucune connexion n'est nécessaire, mais nous pouvons au moins vérifier que le dossier existe.
L'étape suivante consistait à utiliser `get-schemas`. Dans ce cas précis, la source de données ne comporte aucun schéma. Nous avons un accès direct aux tables. Il n'est donc pas nécessaire de définir `get-schemas`, et JMP saura que notre source de données n'utilise pas de schémas.
Mais nous devons définir ce que sont les tables. Dans ce cas précis, bien qu'un paramètre de schéma soit requis, nous l'ignorons car nous ne les utilisons pas. Ensuite, puisque nous examinons les fichiers, nous les nommerons. Ici, nous utiliserons simplement leur nom. Nous parcourrons le dossier et chaque fichier qu'il contient renverra son nom.
Enfin, il nous faut récupérer les tables de données. C'est le rôle de cette dernière fonction d'ouverture de table. Il faut d'abord reconstituer le chemin d'accès au fichier contenant les données. Nous prendrons le nom de la table, qui correspond simplement au nom du fichier suivi du dossier, puis nous renverrons le chemin d'accès sous forme de chaîne de caractères.
Le modèle dont je parlais nécessite le renvoi d'un tableau de données, et c'est possible. Si vous avez, comme dans l'exemple que j'ai donné précédemment, un point de terminaison web, celui-ci renvoie un JSON hiérarchique (ou autre). Vous souhaiterez probablement convertir ce JSON en tableau de données ou le renvoyer directement.
Mais dans ce cas précis, puisqu'il s'agit d'un fichier provenant du système de fichiers (un cas que nous avons rencontré lors de la création des modules complémentaires S3 et SharePoint, et pour lequel nous avons constaté un intérêt certain concernant l'accès à d'autres systèmes de stockage de données de type fichier), il est possible d'ouvrir le fichier non pas directement, mais simplement en lui transmettant cette chaîne de caractères. JMP se chargera alors de l'ouvrir.
Il se chargera notamment de s'assurer que le fichier est ouvert en mode privé. La table de données renvoyée ici est un détail d'implémentation. Elle ne doit pas être directement accessible à l'utilisateur. Lorsque vous utilisez le générateur de requêtes, vous ne voyez pas les tables intermédiaires apparaître, seulement le résultat final. Dans ce cas, JMP s'en occupe. Cette méthode permet également à JMP de conserver tous les paramètres liés à l'ouverture de la table. J'y reviendrai plus en détail ultérieurement.
Enfin, nous avons ici l'appel à la fonction `jmp.DataConnector.tie`. Cette fonction prend deux arguments : la classe de type et la classe de connecteur, et s'assure qu'elles se reconnaissent mutuellement. Actuellement, aucune ne fait référence à l'autre, mais la classe `DataConnectorType` en haut de la fonction est utilisée par JMP comme point d'accès. Le type englobe tout le code et toutes les définitions qui constituent leur connectivité. Ils doivent donc se reconnaître mutuellement.
Enfin, un commentaire indique le type de la chaîne finale : DBC ou ODBC, SAS Viya ou SAS Remote. Dans le cas de Python, le deux-points indique qu'il s'agit d'une fonction. On trouve ensuite `__main__`, le nom du module, car il a été exécuté directement depuis JMP. Enfin, `SimpleFolderConnectorType` est le nom de la classe.
Voyons cela en pratique. Si j'ouvre la boîte de dialogue Connecteur de données et que je crée une nouvelle connexion, l'éditeur de connecteur de données s'ouvre. Si je sélectionne Python comme type, je peux alors saisir le reste de la chaîne. Il suffit de la renseigner.
Une fois cela fait, nous pouvons voir notre option « Dossier ». Vous voyez, elle est vide, ce qui correspond à « Aucun ». Si j'essaie de la tester (nous allons tenter de nous connecter et d'appeler cette fonction), nous verrons le message d'erreur suivant : « Le dossier est requis. »
Maintenant, pour accéder aux données, je vais utiliser les données d'importation d'exemple fournies avec JMP. Il s'agit de ce dossier. Je vais le copier. Je le recopie. Nous allons copier le chemin d'accès, puis l'ajouter à JMP. Voilà ce que nous avons testé. Tout est en ordre, nous allons donc nous connecter.
Maintenant que la connexion est établie, vous pouvez voir une liste de tables ici. Ces tables correspondent aux fichiers présents. On voit Animals_L.txt ici, et on le retrouve là. En consultant le journal, on constate que l'utilisation de cette fonction d'entrée de journal s'est avérée utile. On voit que la fonction _do_as_data_source a été appelée plusieurs fois, ainsi que l'initialisation de la source de données à plusieurs reprises lors de nos tests. On voit également que la fonction get-tables a été appelée, ce qui nous fournit à nouveau cette liste.
Si j'ouvre le générateur de requêtes, je peux voir que nous avons accès aux colonnes. On constate qu'en créant la requête, nous pouvons les ajouter. Il est possible d'appliquer des filtres. Par exemple, nous pouvons sélectionner seulement deux saisons. En consultant le code SQL, on voit qu'il reprend toutes ces informations. Exécutons la requête et nous obtenons nos résultats.
Vous vous demandez peut-être comment tout cela fonctionne. Nous créons une requête SQL. Nous exécutons du code SQL. Pourtant, lors de la définition initiale, la notion de SQL était quasiment inexistante. Cela fonctionne car nous avons fourni cet appel à la table ouverte ; nous avons indiqué comment accéder aux données. JMP se charge ensuite du reste. Il utilise SQLite, une sorte de base de données intégrée, pour exposer les données et permettre l'exécution de code SQL. Par exemple, la clause WHERE qui nous a permis de n'afficher que deux saisons.
Examinons maintenant un fichier plus complexe. Revenons peut-être à notre fichier principal, notre préféré, qui se trouve ici dans Excel. Retournons dans le Générateur de requêtes. On constate qu'avant toute action, cette boîte de dialogue s'affichait. Nous avons décidé que si vous avez plusieurs fichiers, il est nécessaire d'être invité à saisir des informations afin de préciser leur contenu. Lorsque JMP tente d'ouvrir ce fichier, il vous invite à renseigner, dans ce cas précis, les informations requises à l'aide de l'Assistant d'importation.
Tout semble correct, alors cliquez sur Importer. Comme précédemment, je vois les noms des colonnes et l'aperçu. Je clique maintenant sur Importer. Voilà, nos données sont importées. Vous vous demandez peut-être si je dois répéter cette opération à chaque fois ? La réponse est non.
Examinons ce script source. En haut, nous voyons ce que nous attendons : une nouvelle requête SQL, les informations de connexion (fournies ici par le connecteur de données), la référence à notre type et le dossier que nous avons spécifié.
Mais en examinant le tableau, on découvre une nouvelle option : « Paramètres d'ouverture ». Cette option reprend les paramètres spécifiés dans l'assistant d'importation. Plus précisément, elle utilise les arguments supplémentaires transmis à la fonction « open » dans les scripts sources de la table de classes sous-jacente et les fournit ici.
Ainsi, si je relance le processus, vous voyez, tout est ouvert et semble correct. Si nous avions modifié les paramètres de manière non standard, par exemple en commençant par une colonne ultérieure, cela se refléterait ici. On constate dans le journal que tout a redémarré. On voit que nous avons de nouveau appelé la fonction `_do_as_data_source`. Ensuite, nous avons obtenu la liste des tables, puis nous avons rouvert cette table.
Voilà pour les bases. Ceci semble un peu plus complexe. Mais ce n'est pas seulement plus complexe ; c'est aussi un peu plus complet. Il s'agissait, encore une fois, du minimum, du strict minimum pour établir une connexion.
Ça a l'air un peu plus sophistiqué maintenant. Au lieu d'un simple connecteur de dossier, nous aurons un connecteur de dossier complet. Voyez-vous, la définition des champs est bien plus complexe, mais elle repose sur des éléments de base similaires à ceux utilisés précédemment.
Ce qui est ajouté ici, en premier lieu, c'est l'utilisation de `jmp.DataConnectoGroupedFields`. Cela nous permet de spécifier que les champs sont regroupés. Cela influe sur leur affichage dans l'éditeur de connecteurs de données. Pour ODBC, les options sont regroupées, et nous pouvons utiliser la même fonctionnalité avec Python.
Chaque groupe spécifie une paire dans cette liste transmise à `jmp.DataConnectorGroupedFields`. Nous avons le nom, puis un dictionnaire, similaire à celui précédent, contenant le nom de l'option et la définition du champ. Le type de la définition du champ est toujours présent : `str | None`. Cependant, nous l'avons également encapsulé dans `jmp.DataConnectorField`, un alias créé car utilisé à plusieurs reprises et un peu long, afin de spécifier des informations supplémentaires, comme par exemple une infobulle qui s'affichera dans l'éditeur de connecteurs de données au survol du nom d'une option.
Vous spécifiez une valeur par défaut. Vous pouvez également spécifier un nom qui apparaîtra dans l'éditeur de connecteurs de données, différent de celui utilisé dans les fichiers de configuration JSL. Nous utilisons cette fonctionnalité dans JMP, par exemple avec ODBC, afin de localiser les noms des options ou de fournir des chaînes de caractères plus explicites que celles utilisées par défaut en JSL. Nous souhaitons donc un nom conforme au style JSL.
« Ordner » signifie « dossier » en allemand, je crois. Nous le verrons plus loin. Concernant l'affichage de notre source de données, il reste basé sur les dossiers, mais nous allons également prendre en charge les schémas. Dans ce cas, une option permettra, au lieu d'examiner les données comme auparavant, de considérer les dossiers enfants du dossier principal comme des schémas, et leurs fichiers comme des tables de données.
Nous aurons une autre option qui modifiera notre façon d'appréhender la correspondance entre les noms de tables et les fichiers sous-jacents, en se limitant à certaines extensions et en les tronquant.
La conversion vers une source de données lors de la connexion est similaire, mais légèrement plus complexe car nous disposons de plus d'options. Nous cochons toujours « Dossier », mais nous allons également cocher cette option d'extension. Une erreur sera générée, puis toutes les données seront transférées vers notre nouvelle source de données.
Notre nouvelle source de données vérifiera les dossiers au préalable et configurera les autres options. Elle fournira des schémas. Si nous utilisons ces schémas, le code sera similaire et parcourra les dossiers à l'intérieur du répertoire. Chaque sous-répertoire recevra son nom, qui servira de nom de schéma.
Si nous n'utilisons pas de schémas, et si nous n'avons pas défini notre nouvelle option avancée, nous renverrons simplement `None`. Auparavant, nous ne définissions pas de schémas (`get-schemas`), mais il n'est pas possible de définir une fonction ici ; par conséquent, vous pouvez renvoyer `None` pour signifier « Je n'en ai aucun ». Nous n'utilisons pas de schémas.
La fonction Get-tables fonctionne sur le même principe qu'auparavant. Au final, nous récupérons le nom d'un ensemble de fichiers. Cependant, en fonction des options disponibles, plusieurs méthodes sont possibles. Nous récupérons le répertoire. Le chemin d'accès dépend du schéma utilisé, et notamment de son utilisation. Ensuite, nous filtrons la liste pour ne conserver que les fichiers avant d'obtenir leurs noms, ou nous effectuons un traitement plus sophistiqué si nous prenons en compte les extensions.
Enfin, pour obtenir la table de données, nous inversons le processus de `get-schemas` et `get-tables`. Il faut reconstruire le chemin. On pourrait ajouter l'extension. Mais cela ne permettra pas d'obtenir le répertoire concerné, et nous rajouterons le nom du fichier à la fin avant de le renvoyer à nouveau sous forme de chemin… Nous renvoyons ainsi le chemin sous forme de chaîne de caractères. Nous l'assemblons, et nous retrouvons le nom de notre type comme précédemment.
Voyons voir. Je vais revenir en arrière pour pouvoir nous y référer. Comme précédemment, définissons le type. On voit ici notre nom personnalisé ainsi que l'infobulle. On utilisera le même chemin d'accès au dossier qu'avant. Récupérons-le. En fait, remontons d'un niveau. Utilisons la fonctionnalité de schéma. Copions-le.
On peut donc indiquer qu'on souhaite utiliser les sous-dossiers comme schémas. Puisque nous avons ajouté cette option avancée, nous allons l'utiliser. Vérifions que tout est correct. C'est bon. La connexion est établie. Assurons-nous que toutes les fenêtres sont bien visibles.
À gauche, nous voyons les schémas, qui correspondent en réalité aux noms des dossiers. Voici nos données d'importation. Nous constatons que nous les avons limitées aux fichiers .txt. Reprenons notre exemple des animaux, comme précédemment, et ouvrons-le. Nos données sont là. Tout fonctionne. Les appels sont toujours présents. Si nous consultons le journal, nous voyons des appels à `get-schemas`, `get-tables`, notre fonction utilitaire et `open-table`.
Vous avez accompli un travail considérable pour créer ces types. Maintenant, vous souhaitez les partager avec d'autres. C'est le dernier point que nous voulons aborder : comment procéder. J'ai une autre liste de vérification.
Vous avez écrit votre code Python, mais selon sa structure, il peut être judicieux de l'organiser en un package. L'objectif est de regrouper tous les éléments et de permettre leur installation avec un outil comme pip, ou dans ce cas, jpip (encapsulé par JMP), ce qui vous permet de spécifier les dépendances lors de l'installation. Par exemple, avec S3, nous dépendons du package Boto3, disponible sur PyPI, et l'utilisation d'un package offre une manière très naturelle de spécifier cette dépendance.
Il vous faudra créer des configurations de base. Souvenez-vous, tout à l'heure, je saisissais directement le nom du type dans l'éditeur de connecteurs de données. C'est bien beau, mais il serait plus simple de trouver une configuration dans la liste. Je pourrais ainsi créer une nouvelle configuration à partir de celle-ci, sans avoir à me souvenir du nom complet.
Vous aurez probablement besoin d'écrire un script d'installation. Nous disposons de ce formidable package Python, mais il nous faut l'installer dans un emplacement où il puisse être utilisé. Si nous pouvions automatiser le processus, ce serait vraiment génial.
Enfin, nous souhaitons intégrer le tout dans un module complémentaire. Ce format facilite l'installation et permet une distribution via le Marketplace. De plus, tout est regroupé dans un seul fichier.
Voyons voir à quoi cela ressemble. J'ai ici un module complémentaire qui contient une version plus aboutie du code que nous avons examiné plus tôt aujourd'hui. Je l'ai décompressé pour que nous puissions en voir le contenu. Le premier élément de la liste, je crois, était le package Python. Je l'ai créé ici. Nous avons notre code Python, structuré en un projet Python… pardon, en un package Python. Nous avons notre fichier pyproject.toml. Je n'ai pas vraiment le temps aujourd'hui de détailler la procédure de création, mais vous trouverez des ressources en ligne à ce sujet.
Nous avons un dossier « Connecteurs de données ». C'est là que se trouvent les configurations associées à l'extension, ici, les configurations de base. Si j'en examine une, par exemple, on constate qu'elle ne contient qu'une seule ligne spécifiant le type. Elle ne spécifie aucune configuration supplémentaire, mais elle fournit un élément que l'utilisateur peut utiliser. Ensuite, nous avons, dans ce cas précis, « addinLoad », qui contient le script d'installation.
Bien sûr, vous pouvez créer tout cela directement, mais vous pouvez aussi utiliser l'outil de création de modules complémentaires de JMP. Dans le menu Fichier, Nouveau, Module complémentaire, vous pouvez saisir un nom, un identifiant et spécifier la version minimale de JMP, qui est ici la version 19. Le champ « Script de démarrage » contient le script qui installera le module. Il est important de ne l'installer qu'une seule fois.
Nous avons les fichiers à ajouter. Ici, ils sont déjà décompressés, mais si c'est votre première création, ils peuvent se trouver ailleurs. Nous pouvons ajouter le package. Voilà, tout est là. Nous pouvons ajouter les connecteurs de données. Avec l'abonnement, nous pourrons enregistrer et créer notre propre module complémentaire. Une fois tous les éléments réunis, le processus de création devrait être assez simple.
Voilà tout ce que je voulais vous montrer. Résumons. Tout d'abord, j'aimerais vous expliquer pourquoi l'intégration est intéressante. Comme nous l'avons vu en introduction, le framework Data Connector offre de nombreuses possibilités : modification et partage des configurations, utilisation du générateur de requêtes pour construire vos requêtes de manière interactive. Cela justifie pleinement l'intégration de votre source de données. C'est là que Data Connector intervient. Nous avons vu que dans JMP, tout est organisé en tables de données, et nous souhaitons que cela ressemble à une base de données.
Quel code écrire ? Nous avons passé en revue les différentes sous-classes à définir, les fonctions à implémenter et la manière de spécifier les options. Enfin, nous avons abordé la création d'un module complémentaire et son partage avec d'autres utilisateurs ou sur la plateforme JMP Marketplace.
Voici, en quelque sorte, un aperçu rapide de tout ce qui est possible. Certains d'entre vous prennent peut-être des notes détaillées et font de nombreuses captures d'écran ou photos, mais si vous êtes comme moi, vous préférerez sans doute avoir d'autres supports de référence. La bonne nouvelle, c'est que nous disposons de ces informations et que nous continuons à les enrichir.
L'API que j'ai présentée aujourd'hui est documentée. Vous trouverez la documentation dans les notes EA, sous la section Accès aux données. Assurez-vous d'utiliser la dernière version, qui, selon les besoins, pourrait ne pas correspondre à la version EA actuelle si aucune modification n'a été apportée. Nous ajoutons actuellement de la documentation dans l'index des scripts. Cette documentation ne fournira pas la vue d'ensemble des notes EA, mais elle devrait servir de référence pour chaque fonction de l'API.
Enfin, concernant l'extension que je vous présentais précédemment, nous continuons de la développer et nous allons la publier sur le JMP Marketplace. Nous souhaitons qu'elle serve de ressource pour présenter l'API, mais aussi pour montrer comment créer un package Python et le publier sous forme d'extension.
Nous allons, une fois de plus, vous présenter tout ce que vous avez vu aujourd'hui, ainsi que quelques autres fonctionnalités plus avancées que je n'ai pas eu le temps d'aborder, mais qui pourraient s'avérer utiles. N'hésitez pas à y jeter un œil.
Enfin, j'aimerais vous parler de nos projets futurs. Dans JMP 20 et les versions ultérieures, nous envisageons d'ajouter des extensions à cette API. Par exemple, vous avez peut-être remarqué que pour traiter vos données, JMP les chargera localement, c'est-à-dire l'intégralité de votre table de données, puisque c'est ce que renvoie la commande `open table`. Nous l'utiliserons ensuite localement, comme je l'ai mentionné, via SQLite.
Mais si une partie du traitement peut être effectuée côté serveur, sans avoir à tout télécharger localement, nous souhaitons prendre en charge cette option. Nous allons étudier comment proposer cette fonctionnalité.
Voilà, je crois que c'est terminé. Merci de votre attention. J'espère que vous pourrez mettre en pratique ce que vous avez appris aujourd'hui et créer de nouvelles sources de données intégrées à ce framework Data Connector. Vous pourrez ensuite publier un module complémentaire à partir de ces sources et, de manière générale, travailler plus facilement avec vos données et les intégrer à JMP. Merci encore. C'est tout.
