L'intégration des données dans JMP est essentielle au flux de travail analytique. C'est pourquoi JMP 18 introduit de nouveaux connecteurs de données afin d'élargir l'éventail des sources de données tierces accessibles à JMP. JMP 18 permet une configuration plus détaillée des sources de données ODBC et facilite le partage de ces configurations avec les collègues, quelle que soit la plateforme, ainsi que leur publication sur JMP Live. Nous abordons les connecteurs de données, non seulement ceux existants dans JMP 18, mais aussi les projets d'extension pour les versions futures de JMP.
Bonjour ou bonjour, quel que soit le moment de la journée où vous regardez cette vidéo. Je m'appelle Neal Siekierski et je suis développeur logiciel chez JMP. Je suis l'un des principaux développeurs de notre projet Data Connector. Je suis ici aujourd'hui pour vous parler de ce projet, de son importance pour JMP 18 et de ses implications futures.
Nous avons ici ces trois points essentiels. C'est ce que nous souhaitons vraiment réaliser avec Data Connect : simplifier la connexion à un plus grand nombre de sources de données qu'auparavant et faciliter le partage de ces connexions. Que ce soit avec vos collègues utilisant la même plateforme (Mac ou Windows) ou une plateforme différente, vous pourrez également les partager avec JMP Live. Tout en vous donnant accès à davantage de sources de données, nous voulons vous permettre de gérer l'ensemble de ces opérations depuis une interface unique.
Avec JMP 18, nous ne pouvions pas tout faire. Nous nous sommes donc concentrés sur ODBC. ODBC est une technologie utilisée par JMP pour communiquer avec des sources de données distantes, des bases de données comme SQL Server ou MySQL, et bien d'autres. Nous avons choisi ODBC car, étant donné qu'il permet déjà d'accéder à de nombreux types de bases de données, il était possible d'étendre encore davantage ses fonctionnalités.
Il existe actuellement certains obstacles qui compliquent un peu les choses. C'est une autre raison pour laquelle nous avons examiné ce point. Par exemple, l'une des sources de difficultés que nous constatons réside dans le code SQL. Le code SQL est un langage de programmation utilisé pour extraire des données des bases de données, et JMP doit générer ce code, l'envoyer via l'API ODBC afin de récupérer les résultats et d'afficher vos données.
Toutes les bases de données n'ont pas un code SQL exactement identique. Par exemple, avec PostgreSQL, si nous récupérons quelques colonnes d'une table (ici, notre classe principale), la requête ressemblera à ceci. Mais la même requête pour MySQL et d'autres bases de données sera différente. Vous pouvez constater que PostgreSQL utilise des guillemets doubles, MySQL des accents graves, et SQL Server est encore différent.
Grâce à ce droit, JMP doit connaître la base de données à laquelle il se connecte. Nous pouvons obtenir cette information. Cependant, pour pouvoir l'utiliser, JMP doit connaître chaque type de base de données. Si JMP ne reconnaît pas un type de base de données, nous avons un comportement de repli spécifique. S'il fonctionne, tant mieux. Nous essayons de définir des valeurs par défaut raisonnables, mais il se peut qu'elles ne fonctionnent pas. Dans ce cas, vous ne pourrez pas utiliser le générateur de requêtes avec votre source de données.
Une autre source de difficulté réside dans les chaînes de connexion utilisées. Pour se connecter à une base de données, JMP doit fournir à ODBC une chaîne contenant diverses informations : l’emplacement du serveur, la méthode de connexion, etc. Une chaîne de connexion très simple ressemble à ceci. Par exemple, le serveur auquel JMP se connecte est une machine de test à laquelle nous avons accès chez JMP. Nous verrons davantage de cas similaires.
Mais surtout, nous avons aussi un pilote. Un pilote est un logiciel spécifique qui se connecte à ODBC pour vous donner accès à une source de données particulière. ODBC lui-même ne gère pas les sources de données et, comme pour la plupart des logiciels, vous ne pouvez pas l'installer sur Mac et Windows. Ou alors, il faut effectuer deux téléchargements distincts. Ce sont deux logiciels différents. C'est très similaire pour ODBC.
Actual SQL Server est un pilote pour SQL Server développé par la société Actual et destiné aux Mac. Si je disposais d'une connexion utilisant cette chaîne de connexion et que je souhaitais la partager avec une autre personne sous Windows ou utilisant JMP Live, cette dernière devrait la modifier.
Pour cela, il faudrait connaître le pilote Windows. Dans ce cas précis, il s'agit de SQL Server. Je peux l'exécuter sur mon ordinateur Windows sans problème. Mais là encore, il faut connaître la base de données. Il faut connaître son pilote correspondant sur chaque plateforme, ce qui complique le partage.
Entre les différentes bases de données nécessitant des JMP, la connaissance de ces dernières et les différences de connexion et de chaînes de connexion, il peut être difficile de partager des connexions et de connecter toutes les sources de données souhaitées.
Pour gérer cela, nous disposons du framework de connecteurs de données que nous avons introduit en interne dans JMP 18, et nous avons également une application spécifique en ODBC.
L'idée principale est d'avoir repris toutes les options que JMP configure en interne en fonction du type de connexion. SQL Server requiert un ensemble d'options, PostgreSQL un autre. Nous les avons toutes rendues accessibles et configurables individuellement.
Ainsi, si vous utilisez une base de données similaire à SQL Server sur certains points, mais différente sur d'autres, il vous suffit de modifier une option pour que cela fonctionne. Ces options ne se limitent pas aux préférences du système ; il s'agit de configurations personnalisables, que nous pouvons ensuite partager.
Vous pouvez obtenir une configuration complète et lui donner un nom. Ensuite, pour vous connecter à une base de données spécifique, vous pouvez y faire référence. Si vous souhaitez vous connecter à une autre base de données, vous utiliserez une autre configuration. Le fait qu'elles soient nommées facilite également le partage de ces connexions.
Enfin, les paramètres que vous définissez peuvent dépendre de la plateforme. Nous venons de voir comment les pilotes et d'autres paramètres peuvent nécessiter des configurations différentes.
Si une fonctionnalité doit être spécifique à Mac et différente de celle de Windows, c'est possible. De même, pour des besoins plus précis, c'est envisageable. Voilà les idées principales. J'aimerais maintenant les développer, mais sans démonstrations concrètes.
Voici JMP. Dans la base de données de fichiers, un nouvel élément de menu, « Connecteurs de données », apparaît. En cliquant dessus, une fenêtre s'affiche ; si vous avez déjà utilisé Query Builder, elle vous semblera sans doute familière. En sélectionnant « Nouvelle connexion », une liste de configurations s'affiche.
Quelques points importants à noter. Les éléments en haut de la page sont des configurations intégrées ; ils commencent donc tous par com.jmp. Ils sont fournis par nos soins et correspondent aux différentes bases de données que nous gérions en interne et que nous proposons désormais également ici.
Ces configurations ne sont peut-être pas directement utiles pour la connexion. Elles ne contiennent pas d'informations comme celles d'un serveur, mais elles restent pratiques pour créer de nouvelles configurations. Ci-dessous, vous trouverez d'autres configurations.
J'en ai créé certaines moi-même. La plupart, cependant, ont été générées automatiquement par JMP à partir des connexions gérées par ODBC, appelées noms de source de domaine DNS. Vous pouvez voir ici la liste des connexions DNS présentes sur mon Mac, et plusieurs d'entre elles apparaissent également dans JMP.
Ces connexions sont créées automatiquement pour faciliter la prise en main. Je vais donc fermer cette fenêtre. Puisqu'elles sont déjà présentes dans mes connexions, l'idéal serait de pouvoir simplement cliquer sur « Se connecter ».
Cela ne fonctionne pas. Nous obtenons un message d'erreur du pilote indiquant qu'aucun identifiant utilisateur n'a été fourni. JMP n'a pas pu collecter cette information lors de la conversion de cette configuration.
Nous avons cependant la possibilité de le faire. La boîte de dialogue nous propose de créer une nouvelle configuration ; nous pouvons donc utiliser celle-ci. Ajoutons ce dont nous avons besoin, à savoir un nom d'utilisateur et un mot de passe. Ensuite, nous pourrons essayer de nous connecter. Alors, cliquons sur « Oui ».
Voici l'éditeur de connecteurs. Nous y reviendrons plus en détail ultérieurement. Pour l'instant, ajoutons simplement les informations nécessaires. Il nous faut un mot de passe. Il n'y en avait pas auparavant. Désormais, nous allons en définir un. Je vais le saisir. Il nous faut également un nom d'utilisateur. Même principe.
Maintenant que ces informations sont renseignées, nous pouvons tester la connexion. Elle a réussi. Puisque nous avons une configuration fonctionnelle, avant de nous connecter, nous allons en enregistrer une copie. Cela nous évitera de devoir recommencer plus tard. La connexion est maintenant configurée ; je l'ai donc enregistrée. C'est bon, on se connecte.
Nous voyons ici une liste de schémas. Si je sélectionne l'un de ces schémas, nous voyons une liste de tables. Nous allons choisir la table principale, « bigclass ». Le plus simple est maintenant d'ouvrir la table. En cliquant sur « Ouvrir la table », nous voyons notre table s'afficher. Parfait.
Mais nous pouvons aussi utiliser le générateur de requêtes. Je vais fermer cette fenêtre ; nous pouvons maintenant cliquer sur le bouton « Générateur de requêtes ». Le générateur de requêtes s’affiche ; nous y retrouvons la même interface qu’auparavant.
Nous pouvons construire notre requête. Je peux continuer à la parcourir étape par étape. Ajouter des colonnes, exécuter la requête, et une fois celle-ci terminée, nous retrouvons notre tableau. Maintenant que nous avons notre tableau, nous avons constaté que tout fonctionne. Supposons que nous recommencions.
Nous avons enregistré une connexion, nous devrions donc pouvoir l'utiliser. Déconnectons-nous. C'est bon, nous pouvons y aller. Nous retrouvons celle que nous avions enregistrée. Nous pouvons nous connecter, et voilà, c'est fait ! Tout est de nouveau visible.
Ouvrons à nouveau notre tableau. Puisque nous l'avons ouvert, nous pourrions l'utiliser pour autre chose. J'ai évoqué le partage, aussi bien avec vos collègues qu'avec JMP Live. Commençons par le partage sur JMP Live.
Je vais publier le tableau de données. Il s'affiche correctement, nous avons donc notre tableau. Cliquez sur Suivant. Nous allons simplement le publier dans mon espace personnel. C'est fait, fermons cette fenêtre et passons à JMP Live.
Voici mon espace personnel que je vais actualiser. Notre tableau s'affiche maintenant ; ouvrez-le. Attendez le chargement, puis accédez aux paramètres pour actualiser vos données par script. C'est là que réside une des différences avec le Générateur de requêtes. Auparavant, une chaîne de connexion était nécessaire pour configurer un script d'actualisation. Désormais, en utilisant le script source, vous constaterez une légère différence.
Je ne vais pas trop m'attarder là-dessus pour l'instant. Je veux juste vérifier si ça fonctionne, alors je l'enregistre. Je vais saisir des identifiants, puis… Je clique sur « Actualiser ». On verra bien. Ça n'a pas marché. Voyons pourquoi. On obtient une erreur. C'est un peu difficile à comprendre, mais en gros, ça signifie qu'on n'a pas spécifié de pilote valide.
Examinons notre script plus en détail pour comprendre ce qui se passe. On y trouve la ligne « driver actual open source databases ». On spécifie un pilote. Or, comme vous pouvez le constater, il s'agit d'un pilote exclusif à Mac ; il n'est donc pas surprenant qu'il ne fonctionne pas.
Auparavant, il aurait fallu trouver le nom du pilote Windows, le remplacer ici, puis réessayer. Mais cette fois-ci, je n'ai pas besoin de le chercher. Je vais le supprimer. Je vais l'enregistrer, et nous allons réessayer. Apparemment, ça a fonctionné, alors je le recharge.
Il n'y a rien de vraiment différent ici. Les données n'ont pas changé, mais nous avons constaté une actualisation. Voici pourquoi cela a fonctionné. Revenons à notre script. Nous utilisons la configuration intégrée. Nous avons ajouté ces éléments de configuration supplémentaires pour qu'elle corresponde à celle créée par JMP.
En règle générale, lorsque nous publions JMP en ligne, nous configurons le script source de manière à créer un élément équivalent à la configuration que vous avez spécifiée.
La raison de cette différence : nous n'indiquons pas simplement « ID JMP dev » à pkg-config car JMP Live ne reconnaît pas ce nom. Pour une meilleure compatibilité avec JMP Live, nous créons une configuration équivalente à partir d'une configuration intégrée présente dans JMP Live, à laquelle nous ajoutons tous les autres éléments.
Cette configuration intégrée permet le bon fonctionnement du système. Comme je l'ai dit, l'un des principes fondamentaux des connecteurs de données est la possibilité d'une configuration dépendante de la plateforme. On le constate avec cette configuration intégrée, la configuration Postgres intégrée, qui recherche automatiquement un pilote approprié sur la plateforme d'exécution.
Sur mon Mac, il trouvait le pilote de base de données open source sous Windows, il trouvait le pilote Postgres pour Windows. Tous les pilotes intégrés fonctionnent de la même manière.
Cela facilite également le partage entre Mac et Windows, ainsi qu'entre machines disposant de pilotes différents. Voilà pour JMP Live. Retournons à JMP pour fermer cette fenêtre. Déconnectons-nous pour repartir de zéro. La configuration est maintenant terminée. Elle a été créée par JMP.
Et si nous voulions créer nous-mêmes une configuration ? Sans passer par le gestionnaire ODBC, nous pourrions demander à JMP de la récupérer et de l'afficher ici. Voyons cela en même temps. Abordons les choses plus en détail. Connectons-nous maintenant au serveur SQL. Voici la configuration.
Si je clique sur « Nouveau », je pourrai créer une nouvelle configuration à partir de celle-ci. Je n'aurai donc pas à spécifier chaque détail concernant SQL Server, mais seulement les éléments spécifiques à ma connexion. L'éditeur s'affiche à nouveau. Examinons cela plus en détail.
Tout d'abord, nous avons le type de connexion et JMP 18. Nous n'avons que ODBC. Ensuite, nous avons la base de la connexion ; comme je l'ai dit, nous partons de la configuration SQL Server intégrée. Nous voyons ici notre configuration SQL Server intégrée. Et plus précisément, nous identifions ce que nous voulons avec celle-ci. Il existe d'autres options. Nous pouvons partir de zéro en utilisant simplement les paramètres par défaut pour ODBC en général.
Nous pourrions spécifier le chemin d'accès à un fichier. Nous pourrions même définir une configuration de base. Mais en règle générale, vous utiliserez probablement une autre configuration, qui correspond à cet identifiant. Juste en dessous, vous trouverez toutes les options, regroupées par catégories. Le premier groupe concerne les informations de connexion.
Il s'agit de l'endroit où vous vous connectez et de vos informations d'identification. Ce sont les éléments contenus dans la chaîne de connexion ODBC. En dessous se trouvent d'autres options ; nous voyons donc diverses options pour SQL, ainsi que des options spécifiques à la couche ODBC sous-jacente.
Si je clique ici sur Connexion, c'est que nous allons établir une connexion. Je vais donc renseigner les informations nécessaires. Le nom de la base de données est SQBTest. Vous pouvez constater que cette case à cocher est décochée. Cela indique si nous utilisons la valeur issue de la configuration de base.
Que je l'aie modifiée ou non, la case est décochée. Je peux la recocher, et elle reprendra sa valeur initiale. Mais nous en avons besoin. Je vais donc la remplir à nouveau.
Nous voyons ici le pilote de partage jusqu'à JMP 19. Je dois effectuer cette opération, alors faisons-le rapidement. Voici le mot de passe. Notre serveur est à nouveau jmpdev2. Nous avons notre nom d'utilisateur. Vérifions la connexion. Elle s'établit. Mais avant d'aller plus loin, considérons un scénario. Imaginons que je ne me connecte pas à SQL Server. Imaginons un système très similaire, mais pas tout à fait identique.
La différence réside dans l'utilisation des crochets : SQL Server utilise des crochets, tandis que PostgreSQL utilise des guillemets doubles. En explorant les options SQL, on constate de nombreuses différences. Intéressons-nous au type de guillemets. Actuellement, il est spécifié comme étant des crochets. En le remplaçant par des guillemets doubles, nous obtiendrons le comportement attendu par notre base de données.
Pour cette démonstration, SQL Server prend en charge les deux syntaxes. Les crochets sont sa syntaxe native, mais les guillemets sont plus courants. Puisqu'il les prend en charge toutes les deux, voyons cela en pratique. Enregistrons. Ce sera mon serveur SQL Server. Connectons-nous.
Avant de pouvoir visualiser les tables existantes, nous pouvons sélectionner une classe, par exemple. En utilisant le générateur de requêtes, nous verrons que le code SQL généré correspond à notre choix.
Normalement, on s'attendrait à trouver les guillemets droits et les crochets droits. Mais ici, ce sont des guillemets doubles. On constate d'ailleurs que cela fonctionne. Si j'exécute la requête, j'obtiens bien notre tableau. J'ai créé une configuration non pas de zéro, mais à partir des configurations de base. Il m'a suffi de renseigner quelques options pour obtenir une connexion parfaitement fonctionnelle.
J'ai même pu modifier légèrement certains comportements. Tout ce travail a été accompli. Et si quelqu'un d'autre dans mon organisation souhaitait en profiter ? Il est possible de partager ces connexions non seulement avec JMP Live, comme je l'ai montré, mais aussi avec d'autres systèmes.
Pour cela, nous avons ce petit menu triangulaire rouge. En cliquant dessus, nous voyons une option permettant de partager les connecteurs. Je vais l'afficher. Vous pouvez voir la liste de nos configurations à gauche. Celles affichées ici excluent les connecteurs intégrés, car il n'est pas nécessaire de les partager.
Si nous sélectionnons notre configuration, elle s'affichera ici, à droite. J'ai double-cliqué pour cela, mais nous avons aussi ces boutons : je peux cliquer sur celui-ci pour la déplacer ou la supprimer. Je clique ici pour l'ajouter à nouveau. Pour la partager, nous allons créer un module complémentaire. Nous utiliserons la fonction d'ajout de JMP afin de distribuer ces configurations et de simplifier leur installation.
Mais comme il s'agit d'un module complémentaire, tous les modules complémentaires ont besoin d'un identifiant. C'est le rôle de cette case ici. Elle permet de définir par défaut le nom d'hôte de votre machine, les sous-composants étant inversés. L'adresse de ma machine est mh382.mmt.com. Nous l'avons inversée : com.sas.mmt.mh302. Ce sera la base. Comme je n'ai ajouté qu'une seule configuration, le module utilisera simplement son nom. Si j'en ajoutais une autre, par exemple, il s'agirait alors simplement de « connecteurs de données ».
Mais supprimons cela. Cliquons sur Enregistrer. Le nom par défaut est l'identifiant complet suivi de « JMP ». Mais ce n'est pas nécessaire. Nous pouvons le rendre plus convivial ; appelons-le simplement « Serveur ». En fait, nous pouvons faire encore mieux. Inutile d'utiliser ce nom intégré. Annulons-le. Changeons le nom. Prenons par exemple « Société » ; nous allons utiliser mon nom d'utilisateur. Au lieu de réutiliser ce nom, nous allons préciser son utilité pour la conférence Discovery de cette année.
Cliquez sur Enregistrer. Nous allons le renommer pour quelque chose de plus convivial. Enregistrez-le, et on nous demande maintenant si nous voulons conserver le mot de passe. Comme nous supposons que vous ne souhaitez pas forcément le partager, nous vous proposons une option pour le supprimer automatiquement. Dans ce cas, supprimons-le.
Vous voyez, c'est enregistré. Mon bureau affiche maintenant ce module complémentaire. Mais que faire ensuite ? Il faudrait le donner à quelqu'un d'autre. Dans ce cas, au lieu de le donner à quelqu'un d'autre, je vais me l'installer moi-même. Passons à Windows. Connectons-nous rapidement, et voilà. Voici JMP. Il nous faut trouver ce module complémentaire ; mon dossier Téléchargements se trouve ici. J'ai maintenant le module complémentaire, je l'ouvre avec JMP et je l'installe.
Très bien, passons à la pratique. Nous allons dans Fichier, Base de données, Connecteurs de données. Nous allons afficher nos configurations. Voilà. Essayons de nous connecter. La connexion a échoué car l'authentification a échoué. C'est logique. Nous avons déplacé notre mot de passe. Supposons que nous souhaitions le configurer davantage. Ajoutons à nouveau ce mot de passe. Vous pouvez le tester. Voyez, ça fonctionne. Nous cliquons sur OK. La connexion est établie.
Nous avons créé un Mac [inaudible 00:26:10]. Nous l'avons transféré sous Windows et la connexion est établie. Nous verrons comment tout cela fonctionne. Il s'agit du partage de fichiers et de la configuration initiale. Mais comment tout cela fonctionne-t-il en interne ? Revenons à JMP. Nous voyons ceci dans la configuration intégrée de SQL Server. Nous voyons les autres configurations que nous avons créées.
À quoi ressemblent-elles ? Où se trouvent-elles ? Les configurations intégrées sont stockées dans un dossier faisant partie de l'installation de JMP. Celles que vous créez se trouvent dans le répertoire de données utilisateur de JMP, avec toutes vos autres données. Sur Mac, accédez au dossier Bibliothèque de votre dossier utilisateur ; sur Windows, accédez à Application Support puis à JMP.
Il s'agit d'un dossier situé dans AppData. Vous pouvez y voir, outre diverses informations spécifiques à JMP, des éléments liés à la version, des fichiers Python et un dossier pour les connecteurs de données.
Si j'ouvre ce dossier, je vois des fichiers correspondant à toutes les configurations que j'ai effectuées et aux connexions JMP générées via ODBC. Par exemple, on y trouve la configuration du serveur MySQL, avec l'extension JMP DC (connecteur de données JMP). Outre ces fichiers JMP DC, on trouve également le fichier JMPDataConnectorRegistry.JSON. Ce dernier contient les informations permettant, par exemple, d'associer le nom du serveur MySQL à ce fichier spécifique.
Il peut aussi contenir d'autres informations. Mais voyons ce qu'il contient. Nous allons utiliser un éditeur de texte, et maintenant… pardon, je me suis trompé. J'en ai nommé deux très similaires, alors ouvrons celui-ci. On y voit beaucoup de texte qui ressemble à du JSL, et c'est parce qu'il s'agit de JSL, ou plutôt, d'un sous-ensemble de JSL.
Ici, à gauche, nous avons les noms de nos options et à droite, leurs valeurs. Cette première ligne est particulière : elle indique que notre base est celle qui sera identifiée par com.JMP.SQLServer. Nous pouvons voir les paramètres associés. Nous constatons que le serveur que nous avons configuré est leur base de données, une modification apportée au type professionnel.
De manière générale, les noms des options à gauche correspondent très précisément à ce qui se trouve dans l'éditeur. À droite, les valeurs sont également similaires à celles de l'éditeur. Ici, le petit texte d'exemple à la fin est absent. Plus précisément, pour le nom d'utilisateur et le mot de passe, nous avons ici des chaînes encodées. Ces informations sont stockées de cette manière afin de ne pas enregistrer directement votre nom d'utilisateur et votre mot de passe.
Mais JMP a pu se connecter à tous ces appareils malgré tout, et comme je l'ai dit, il s'agit de JSL. On le constate notamment lorsqu'on souhaite ajouter une configuration spécifique à une plateforme ; nous l'avons vu pour les configurations intégrées. Mais si l'on veut le faire nous-mêmes, prenons par exemple une option que nous n'avons pas encore abordée : la récupération par blocs. Cette fonctionnalité permet d'obtenir des données plus efficacement si elle est activée, mais elle n'est pas toujours prise en charge ou ne fonctionne pas correctement.
Supposons que cela fonctionne sur mon Mac, mais pas sur Windows. Nous souhaitons l'activer sur Windows et sur Mac, mais le désactiver ailleurs. Avec une ligne comme celle-ci, où j'ai défini l'option « Block Fetch » avec cette expression JSL, nous obtiendrons l'effet désiré, car toutes les valeurs à droite sont simplement du code JSL.
À chaque chargement de cette configuration par JMP, il l'évaluera. Il confirmera que, dans ce cas précis (nous sommes sur Mac), la récupération par blocs est activée. Voilà comment cela fonctionnera. JMP lui-même peut utiliser JSL pour gérer ces éléments. Fermons cette discussion, car le problème est résolu.
Pour conclure, nous revoilà dans JMP. Ouvrons un éditeur de script. C'est du code standard. Que puis-je faire ? Je peux charger la configuration depuis un fichier. Ce sera un connecteur de données en mémoire. Regardons à nouveau… Nous avons travaillé avec ce serveur MySQL. Cette ligne va le charger et nous fournir sa configuration. Je peux ensuite extraire des valeurs spécifiques, comme l'option « Récupération de blocs » que nous avons définie.
Je pourrais aussi récupérer le type de guillemet. Je peux modifier les options, donc je pourrais rétablir la valeur précédente du type de guillemet, à savoir « parenthèses ». Je pourrais simplement désactiver l'extraction de blocs. On peut maintenant l'afficher à nouveau pour vérifier que cela produit l'effet escompté. Si j'exécute tout cela, on constate que l'extraction de blocs est activée et que le type de guillemet est « double ». Une fois la configuration effectuée, tout est désactivé.
Voici quelques possibilités de manipulation. En observant l'ensemble, on constate que toutes les valeurs autres que leurs valeurs par défaut s'affichent. Par exemple, notre nom d'utilisateur et notre mot de passe sont visibles. Mais on remarque aussi de nombreuses autres options où la configuration de SQL Server diffère de celle par défaut. Vous pouvez consulter tout cela dans le registre. Cette correspondance entre les noms et les configurations réelles est également accessible via JSL.
J'ai une variable ici. Je peux ensuite récupérer toutes les entrées disponibles. La liste affichera à la fois celles que nous avons créées et celles intégrées à JMP. Sous Windows, nous verrions également l'entrée installée via le module complémentaire. Nous pouvons obtenir les métadonnées d'une entrée particulière. Nous pouvons consulter une configuration que nous avons créée. Celle-ci nous indiquera le nom et le chemin d'accès, informations essentielles, ainsi que le type et, puisqu'il s'agit d'une connexion ODBC, le pilote.
Vous pouvez également enregistrer une configuration JSL. Supposons que nous voulions créer la nôtre, que nous appellerons MySQLServer2DC. Nous avons ajouté une nouvelle variable de chemin. Pour ceux qui connaissent ce type de configuration, elle pointe directement vers le dossier des connecteurs de données que je vous montrais précédemment. Je peux y saisir du texte.
On va faire simple. On va commencer par la configuration de base de notre serveur MySQL. On va rétablir certains paramètres à leur valeur initiale. Voilà. Enfin, en suivant mon chemin, je vais l'enregistrer. Le nom correspondra au nom du fichier, comme pour les autres. Ensuite, le chemin. Si j'exécute tout ça, on pourra essayer de le charger.
Ici, nous allons procéder comme précédemment, mais avec les deux. On peut constater que cela fonctionne et que quelque chose s'affiche. On peut même récupérer la valeur modifiée. Voyez, elle est bien là. Bien, nous l'avons donc encore une fois vu : nous pouvons tous deux utiliser JSL pour manipuler les configurations. Si nous sommes prêts à travailler directement avec ces configurations, nous pouvons voir où elles se trouvent dans le système de fichiers et ajouter une configuration spécifique à la plateforme.
J'ai abordé beaucoup de sujets. Pour conclure, revenons au début. J'ai mentionné que nous avions des objectifs précis pour cette initiative. Passons-les en revue un par un. Le premier était de permettre la connexion à davantage de sources de données. Pour JMP 18, nous avons étendu l'accès aux sources de données via ODBC. J'espère qu'en modifiant, par exemple, le type JSON pour SQL Server, je vous ai donné un aperçu des possibilités offertes.
Nous avons amélioré la compatibilité avec vos sources de données. Concernant le partage, j'espère que la démonstration du partage de JMP Live vers Windows a permis de mieux comprendre nos possibilités. Enfin, une interaction plus uniforme. C'est une nouveauté pour nous. Je vous ai présenté une nouvelle interface, compatible uniquement avec ODBC. Il est important de rappeler que nous nous concentrons sur ODBC et que nous avons posé les bases d'autres fonctionnalités. Celles-ci seront disponibles ultérieurement.
Concernant l'avenir de JMP 18.1, nous prévoyons quelques améliorations mineures, principalement pour l'éditeur. Avec JMP 19, l'éditeur bénéficiera d'améliorations plus poussées. Mais surtout, nous introduirons de nouveaux types de connexions. Nous allons étendre une fonctionnalité actuellement réservée à ODBC à d'autres protocoles. Le premier d'entre eux que je souhaite mentionner est SAS.
Dans JMP 18, nous avons dû supprimer la connectivité SAS. Mais dans JMP 19, elle est de retour et sera intégrée à notre framework de connecteurs de données. Vous retrouverez ainsi la même interface de connexion, le même éditeur pour la modification des configurations et la même possibilité de partager ces configurations, comme avec les modules complémentaires. Nous ajouterons également la connectivité à Amazon S3 et Microsoft SharePoint, une fonctionnalité très attendue.
Ce qui est intéressant avec S3 et SharePoint, c'est qu'ils ne seront pas distribués avec JMP. En revanche, pour SAS, nous visons une solution similaire à celle d'avant JMP 18. SAS sera distribué avec JMP et vous aurez accès à une grande partie des fonctionnalités GSL existantes.
S3 et SharePoint ne seront pas inclus dans JMP, mais distribués via la Marketplace JMP. Certains d'entre vous en ont peut-être déjà entendu parler. Sinon, vous en entendrez probablement parler lors de la présentation.
En résumé, il s'agira d'un moyen de distribuer des extensions pour JMP. Nous distribuerons ainsi la connectivité S3 et SharePoint. Pour assurer leur intégration avec JMP, nous définirons une API Python exposée par JMP, permettant d'interagir avec tous les éléments nécessaires à l'intégration dans ce framework de connecteurs, puis d'accéder à Query Builder et aux fonctionnalités suivantes.
Pour ce faire, nous utilisons cette interface, ainsi que des bibliothèques Python existantes. C'est là toute la richesse de l'écosystème Python, et le fruit de notre travail d'amélioration de l'intégration Python pour JMP 18. Mais cette technologie ne nous sera pas exclusivement réservée.
Cette interface, que nous allons rendre publique et documenter, vous permettra non seulement de la découvrir, mais aussi de créer de nouveaux types de connexions et de les intégrer à JMP et à Query Builder. Vous pourrez utiliser les mêmes outils.
Voilà ce que nous allons faire à l'avenir. C'est tout ce que j'avais à dire. Je tiens à réaffirmer que j'espère que ce que nous avons accompli en 2018 a non seulement jeté les bases d'améliorations futures comme celles que j'évoque ici, mais constitue également une mise à niveau significative des possibilités offertes par ODBC.
Il est désormais possible de se connecter à davantage de sources de données et de partager plus facilement ces connexions. Je suis convaincu que l'avenir nous réserve encore plus de possibilités. J'ai hâte de découvrir ce que nous pourrons accomplir. Sur ce, je vous remercie de votre écoute et j'espère que vous apprécierez la suite de cette exploration.
