JMPへのデータ取り込みは分析ワークフローの中核を成すため、JMP 18では新しいデータコネクタが導入され、JMPがアクセスできるサードパーティ製データソースの範囲が広がりました。JMP 18では、ODBCデータソースをより詳細に設定できるようになり、プラットフォーム間で設定を共有したり、JMP Liveに公開したりすることが容易になりました。本稿では、JMP 18に搭載されているデータコネクタだけでなく、JMPの将来のバージョンで拡張される予定のデータコネクタについても解説します。
おはようございます。お元気ですか？何時でも、これをご覧になっていらっしゃるでしょうか？Neal Siekierskiです。JMPのソフトウェア開発者で、データコネクタ・イニシアチブの主要開発者の一人です。本日は、そのデータコネクタ・イニシアチブについて、JMP 18にとっての意味、そして今後どのような意味を持つのかについてお話ししたいと思います。
ここに3つの「C」があります。これがData Connectで本当に実現したいことです。これまで以上に多くのデータソースに簡単に接続できるようにしたいのです。そして、それらの接続をより簡単に共有できるようにしたいのです。Mac、Windows、あるいは異なるプラットフォームを使用している同僚と、JMP Liveで接続を共有できるようにしたいのです。より多くのデータソースへのアクセスを提供すると同時に、これらすべてを1つの共通インターフェースで実現できるようにしたいのです。
JMP 18では、これらすべてを実現することはできませんでした。そこで、ODBCに注力しました。ODBCは、JMPがSQL ServerやMySQLなどのリモートデータソース、その他多くのデータベースと通信するために使用する技術です。ODBCを選んだのは、既に複数の種類のデータベースにアクセスできるため、さらに多くのデータベースにアクセスできるようにする余地があったからです。
現時点では、いくつかのハードルがあり、それが少し困難になっています。それが私たちが検討したもう一つの理由です。例えば、問題の原因の一つはSQLコードです。SQLコードはデータベースからデータを取得するために使用されるプログラミング言語ですが、JMPはSQLコードを作成し、ODBC APIを介して送信することで結果を取得し、データを表示する必要があります。
すべてのデータベースが全く同じSQLコードを持つわけではありません。例えば、PostgreSQLというデータベースでは、テーブル（この場合はお気に入りの大きなクラス）からいくつかの列を取得しています。これは以下のようになります。しかし、MySQLや他のデータベースで同じクエリを実行すると、以下のようになります。PostgreSQLでは二重引用符が使われていますが、MySQLではバッククォートが使われています。SQL Serverではまた異なります。
この権限のため、JMPはどのデータベースと通信しているかを認識する必要があります。その情報は取得できます。しかし、実際にJMPを使用するには、JMPがそれぞれのデータベースの種類を認識している必要があります。JMPがそのデータベースの種類を認識していない場合は、特別なフォールバック動作が行われます。それがうまく動作すれば素晴らしいことです。私たちは適切なデフォルト設定を作成するように努めていますが、うまく動作しない可能性もあります。その場合、データソースでクエリビルダーを使用することはできません。
もう一つの難題は、使用される接続文字列です。データベースに接続するために、JMPはODBCに、接続先や接続方法など様々な情報を伝える文字列を与える必要があります。非常にシンプルな接続文字列は以下のようになります。例えば、JMPが接続しているサーバーは、JMPがアクセス可能なテストマシンです。これについては後ほど詳しく説明します。
しかし、もっと重要なのは、ドライバも提供されていることです。ドライバとは、ODBCにプラグインして特定のデータソースにアクセスできるようにするソフトウェアです。ODBC自体はデータソースを実際には認識せず、他のソフトウェアと同様に、MacとWindowsにインストールすることはできません。インストールできたとしても、2つの異なるダウンロードが必要になります。つまり、2つの異なるソフトウェアです。ODBCの場合も、非常に似ています。
Actual SQL Serverは、Actualという会社が開発したMac用のSQL Serverドライバです。この接続文字列を使った接続を他のユーザーと共有したいのですが、相手がWindowsユーザーだったり、JMP Liveを使っていたりする場合は、接続文字列を変更する必要があります。
そのためには、Windowsドライバが何であるかを知る必要があります。今回の場合はSQL Serverです。私のWindowsマシンではこれを実行でき、問題なく動作します。しかし、繰り返しになりますが、データベースが何であるかを知っておく必要があります。各プラットフォームに対応するドライバも知っておく必要があり、それが共有を困難にしています。
JMPを必要とするデータベースの違い、それらに関する知識、そして接続の違いや接続文字列の違いなど、様々な要因が絡み合っています。接続を共有するのが難しい場合があり、必要なすべてのデータソースを接続するのも困難です。
これに対処するために、JMP 18 で内部的に導入されたデータ コネクタ フレームワークがあり、ODBC には特定のアプリケーションもあります。
これらのコアとなるアイデアは、JMPが接続タイプに応じて内部的に設定しているすべてのオプションをそのまま採用することです。SQL Serverはオプションセットの一つであり、Postgresには別のオプションセットが必要です。これらすべてを公開し、個別に設定できるようにしました。
こうすることで、ある面ではSQL Serverに似ているけれど、別の面では異なるデータベースを使用している場合でも、オプションを変更すれば問題なく動作します。これらのオプションは、単に設定メニューにあるものではありません。名前を付けて共有できる設定です。
設定一式を取得できます。名前を付けることもできます。特定のデータベースに接続する際に参照したり、別の場所に接続する際に別の設定を使用したりできます。名前が付けられているため、接続の共有も容易になります。
最後に、実際に行う設定はプラットフォームに依存する可能性があります。先ほど、ドライバーやその他の設定が異なる場合があったことを説明しました。
Macでは一つの機能だけ、Windowsでは何もしないという設定であれば、それは可能です。あるいは、よりきめ細かな設定があれば、それも可能かもしれません。これらが核となるアイデアです。これから詳しく説明しますが、すべてを実際に動作させて見せることはしません。
JMP についてです。ファイルデータベースに移動すると、新しいメニュー項目「データコネクタ」が表示されます。これをクリックすると、クエリビルダーを使ったことがある方ならお馴染みのウィンドウが表示されます。「新規接続」に移動すると、設定の一覧が表示されます。
ここでいくつか注意すべき点があります。一番上にあるものはすべて組み込みの設定なので、すべてcom.jmpで始まります。これらは私たちが提供しているものです。これらは社内でサポートしていた様々なデータベースに対応しており、今回このように公開されるようになりました。
これらは接続に直接役立つわけではないかもしれません。サーバーなどの情報は含まれていませんが、新しい設定を作成するための基盤として役立ちます。この下に、他の設定がいくつか表示されます。
これらのうちいくつかは自分で作成したものですが、ほとんどはそうではありません。JMPはODBCが管理する接続（DSNドメインソース名）から自動的に作成しました。ここには、私のMac上にある接続（DSN）のリストが表示されており、JMPにもこれらの接続がいくつか表示されています。
これらは自動的に作成されるので、簡単に始めることができます。これで終わりにしましょう。作成した接続にこれらがあるので、理想的には「接続」をクリックするだけで済むのが一番簡単です。
これは実際には機能しません。表示されるのはドライバからのエラーメッセージです。ユーザーIDが指定されていないと表示されます。これは、JMPがこの設定を変換する際に収集できなかった情報です。
しかし、ここで機会が与えられます。ダイアログには新しい設定を作成することが提案されているので、この設定をそのまま使用できます。必要なユーザー名とパスワードを追加してください。これで接続を試みることができます。それでは「はい」をクリックしましょう。
これはコネクタエディタです。後ほど詳しく説明しますが、とりあえず必要な情報を追加しましょう。パスワードが必要です。以前はパスワードがありませんでした。これからパスワードを設定します。それを入力します。ユーザー名も必要です。考え方は同じです。
入力が完了したので、接続テストを行ってみましょう。成功しています。接続前に動作する設定ができたので、コピーを保存しておきます。こうすることで、後で同じ作業を繰り返す手間が省けます。ここでの設定は、接続の設定が完了したので、これで保存しました。それでは接続しましょう。
ここにスキーマのリストがあります。これらのスキーマの1つを選択すると、テーブルのリストが表示されます。ここでは、真のテーブルビッグクラスを1つ選択します。最も簡単な方法は、テーブルを開くことです。「テーブルを開く」をクリックすると、テーブルが表示されます。素晴らしいですね。
クエリビルダーを使うこともできます。これを閉じて、代わりにクエリビルダーボタンをクリックしてください。クエリビルダーが起動すると、先ほどと同じインターフェースが表示されます。
クエリを構築できます。ステップ実行を続けます。いくつか列を追加してクエリを実行すると、クエリが終了するとテーブルが再び表示されます。テーブルが完成したので、すべて正常に動作していることを確認しました。もう一度、これを正しく実行できたとしましょう。
接続を保存したので、使えるはずです。これを切断しましょう。これで接続できます。保存した接続を見つけられます。接続できました。これで接続が完了し、すべてが再び表示されます。
では、テーブルをもう一度開いてみましょう。テーブルを開いたら、何か他の用途に使いたいかもしれません。共有についてお話ししました。同僚と共有することと、JMP Liveと共有することです。では、2つ目のテーブルからJMP Liveに共有してみましょう。
データテーブルを公開します。これが表示されたので、テーブルができました。「次へ」をクリックしましょう。これを自分のパーソナルスペースに公開します。これで公開が完了しました。閉じて、JMP Live に移動しましょう。
更新する個人スペースはこちらです。テーブルが表示されているので、開いてください。読み込みが完了するまでお待ちください。設定に移動すると、スクリプトを使ってデータを更新するオプションがあります。ここでクエリビルダーとの違いの一つが分かります。以前は更新スクリプトを設定するために接続文字列が必要でした。今度はソーススクリプトを使ってみると、少し違うものが表示されます。
今はこれを詳しく見るつもりはありません。動作するかどうかを確認したいだけなので、保存しておきます。認証情報を割り当てて、先に進み、「更新」をクリックします。動作するかどうか確認してみましょう。失敗しました。なぜ失敗したのか見てみましょう。ここでエラーが発生しています。少し分かりにくいですが、有効なドライバーを指定しなかったことが原因です。
スクリプトをもう少し詳しく見てみましょう。何が起こっているのか理解するために、driver actual open source databasesという行があります。これはドライバを指定しています。しかし、これはMac専用のドライバなので、動作しないのも当然です。
以前なら、Windowsドライバの名前を調べて、それをここに代入して再試行する必要がありました。しかし今回は、名前を調べる必要はありません。削除して保存し、もう一度試してみます。成功したようですので、リロードします。
実際には特に変わった点はありません。データは変更されていませんが、更新されたことがはっきりと分かります。これがうまくいった理由です。もう一度、スクリプトを見てみましょう。この組み込み設定を使用しています。JMPによって作成された設定と一致するように、追加の設定項目を追加しました。
一般的に、JMP をライブで公開するときは常に、指定した構成と同等のものが作成されるようにソース スクリプトを設定します。
違いの理由です。pkg-config に JMP dev というIDを単に指定しないのは、JMP Live がその名前を認識しないからです。JMP Live との互換性を高めるために、JMP Live に搭載されていることが分かっている組み込み設定の1つをベースに、その他すべての設定を追加することで、同等の設定を再度作成します。
この組み込み設定のおかげで、問題なく動作します。先ほども申し上げたように、データコネクタの核となる考え方の一つは、プラットフォームに依存した設定を行えることです。この組み込み設定、つまりPostgresの組み込み設定では、実行しているプラットフォームに適したドライバーが自動的に検索されます。
私のMacでは、Windows用のオープンソースデータベースドライバや、Windows用のPostgresドライバが見つかりました。組み込みのものはすべて同じように動作します。
これも成功です。MacとWindows、そして異なるドライバーセットがインストールされている可能性のあるマシン間での共有も容易になります。これがJMPのライブです。JMPに戻ってこれを閉じましょう。接続を解除して、まっさらな状態に戻りましょう。これで設定が完了しました。これはJMPによって作成されたものです。
さて、自分で設定を作成したい場合はどうすればよいでしょうか。ODBCマネージャーを経由せずに、JMPに取得させてここに表示させましょう。同時にその設定も確認してみましょう。より詳細に説明します。今回はSQLサーバーに接続します。これがこの設定です。
「新規」をクリックすると、この設定を起点として新しい設定が作成されます。SQL Serverの細かい設定をいちいち指定する必要はありません。接続に固有の設定だけを指定すれば大丈夫です。これを開くと、エディタが再び表示されます。それでは、もう少し詳しく見ていきましょう。
まず、接続の種類とJMP 18があります。ODBCのみです。次に接続のベースがあります。先ほど言ったように、組み込みのSQLサーバー構成から始めます。ここにSQLサーバー、つまり組み込みのSQLサーバー構成があるのがわかります。そして、これを使って具体的に何が必要なのかを特定します。他にもオプションがあります。ODBC全般のデフォルト設定だけで、完全にゼロから始めることもできます。
ファイルへのパスを指定することもできますし、ベースとして使用する設定をインラインで指定することもできます。しかし、一般的には別の設定を使用することになると思うので、ここにあるIDがその設定になります。その下にはすべてのオプションが表示されており、これらはグループ化されています。最初のグループは接続情報です。
接続先と資格情報。ODBCの接続文字列に含まれる情報です。その下には他のオプションがあり、SQLに関するさまざまなオプションと、基盤となるODBCレイヤーに関するオプションがあります。
ここで「接続」を選択すると、実際に接続を確立します。必要な情報を入力します。データベース名はSQBTestです。入力すると、このチェックボックスがオフになっているのがわかります。これは、この基本設定から取得した値を使用しているかどうかを示しています。
変更したかどうかは分かりませんが、チェックボックスはオフになっています。再度チェックを入れると、元の値に戻ります。しかし、これは必要なので、もう一度入力します。
JMP 19までの共有用のドライバーがここにあります。これは必要なので、すぐに実行します。パスワード値はここにあります。サーバーはjmpdev2です。ユーザー名も確認しました。接続できるか確認してみましょう。接続できました。しかし、先に進む前に、あるシナリオを考えてみましょう。SQL Serverに接続していないとします。SQL Serverと非常によく似ていますが、完全に同一ではないサーバーに接続しているとします。
違いは、SQL Serverが角括弧を使うことを覚えているでしょうか。Postgresのように二重引用符を使うとしましょう。SQLオプションを詳しく見ていくと、様々な項目があることがわかります。では、引用符の種類を見てみましょう。現在は角括弧で指定されています。これを二重引用符に変更すれば、データベースの要件に一致するようになります。
このデモにとって便利なことに、SQL Serverは実際には両方をサポートしています。角括弧はSQL Serverのネイティブな構文ですが、二重引用符の方がより標準的です。SQL Serverは両方をサポートしているので、実際に動作を確認してみましょう。これを保存しましょう。これが私のSQL Serverになります。接続してみましょう。
テーブルを確認する前に、例えばクラスを選択できます。クエリビルダーを使ってみてください。クエリビルダーが表示されるので、生成されたSQLコードに選択内容が反映されているのがわかります。
通常、角括弧は角引用符で囲まれるはずですが、今回は二重引用符を使用しています。これで動作していることも確認できます。クエリを実行すると、テーブルが作成されます。繰り返しますが、必ずしもゼロからではなく、基本的な設定から設定を作成しました。いくつかのオプションを指定するだけで、完全に機能する接続ができました。
動作を少し調整して、少し変化をつけることもできました。これで大変な作業は終わりです。では、組織内の他の誰かがこれを利用したい場合はどうすればいいでしょうか？これらの接続は、先ほど示したJMP Liveだけでなく、他のユーザーと共有することも可能です。
これを行うには、ここにある小さな赤い三角形のメニューをクリックします。これをクリックすると、コネクタを共有するオプションが表示されます。これを呼び出します。左側に設定の一覧が表示されています。ここに表示されているのは、組み込みのコネクタは共有する必要がないため除外されているものです。
設定を選択すると、右側に表示されます。ダブルクリックで設定を選択しましたが、ボタンもいくつかあります。これをクリックすると移動、つまり削除できます。これをクリックすると再度追加されます。共有するためにアドインを作成します。JMPの追加機能を使用して、これらの設定を配布し、簡単にインストールできるようにします。
これはアドインなので、すべてのアドインにIDが必要です。下のボックスがIDです。サブコンポーネントを反転したマシンのホスト名をデフォルト設定します。私のマシンのアドレスはmh382.mmt.comです。これをcom.sas.mmt.mh302としています。これがベースになります。構成を1つしか追加していないので、その名前を使用します。例えば、もう1つ追加した場合は、データコネクタのみになります。
でも、これは削除しましょう。「保存」をクリックしましょう。デフォルトでは、完全なIDとJMPアドインを組み合わせた名前になっています。でも、これは不要です。もう少し分かりやすい名前にできるので、「Server」と名付けましょう。実際、もっと良い方法があります。この組み込みの名前を使う必要はありません。これをキャンセルしましょう。名前を変更しましょう。例えば、company の場合は、私のユーザー名を使います。この名前をそのまま使うのではなく、今年のDiscovery Conferenceで私たちが何をしたいのかを伝えましょう。
「保存」をクリックします。少し分かりやすい名前に変更します。保存すると、パスワードを保存するかどうか尋ねられます。パスワードは必ずしも他の人と共有したいものではないと思われるため、自動的に削除するオプションがあります。今回は、パスワードを削除しましょう。
保存されたのが分かります。デスクトップにこのアドインが表示されましたね。さて、どうすればいいでしょうか？誰かに渡す必要があります。今回は、誰かに渡すのではなく、自分自身に渡します。Windowsの方ですが、Windowsに切り替えましょう。すぐにログインしてください。JMPがあります。ダウンロードフォルダにあるこのアドインを見つけてください。JMPを開いてインストールすれば、すぐにこのアドインが見つかります。
では、実際に動作を確認してみましょう。ファイル、データベース、データコネクタに進みます。設定が表示されます。ここにあります。接続してみます。ログインに失敗したため接続に失敗しました。なるほど、納得です。パスワードを変更しました。では、もう少し設定してみましょう。パスワードを元に戻します。テストしてみましょう。動作するか確認してください。「OK」をクリックします。接続されたことがわかります。
Mac版[inaudible 00:26:10]を作成しました。Windows版に移行し、接続できるようになりました。同じ設定で全てが動作するのを確認しましょう。これが共有です。これは最初から設定したものです。しかし、これは内部でどのように機能するのでしょうか。JMPに戻りましょう。SQL Serverの組み込み設定の下にこれがあります。他にも作成した設定があります。
では、それらはどのように見えるのでしょうか？どこに保存されているのでしょうか？組み込みの設定はJMPインストールフォルダ内のフォルダに保存されますが、ユーザーが作成した設定は、他のデータと共にJMPのユーザーデータ領域に保存されます。Macのユーザーフォルダ内のライブラリフォルダに移動すると、Windowsでは「Application Support」→「JMP」と進みます。
これはApp Dataの下のフォルダです。JMP固有の情報に加えて、バージョン固有の情報などが含まれています。Python関連の情報もあります。データコネクタフォルダもあります。
これを開くと、私が作成したすべての設定に対応するファイルと、JMPがODBCから作成したファイルが表示されます。例えば、MySQL Serverの設定ファイルがあり、JMP Data Connector（JMPデータコネクタ）を表すJMP DC拡張子があります。これらのJMP DCファイルに加えて、JMPDataConnectorRegistry.JSONファイルもあります。このファイルには、例えばMySQL Serverの名前とこのファイルをマッピングする情報がすべて含まれています。
他にも情報が含まれている可能性があります。では、中身を見てみましょう。ここではテキストエディタを使用します。すみません、これは間違ったエディタでした。似たようなエディタを2つ挙げたので、こちらを開いてみます。JSLのようなテキストがたくさん表示されています。これはJSL、というかJSLのサブセットだからです。
左側にオプション名、右側にその値が表示されています。最初の行は特別なもので、com.JMP.SQLServer によって識別されるベースがこれであることを示しています。設定内容が確認できます。設定したサーバーがデータベースであり、pro タイプに変更を加えたものであることがわかります。
一般的に、左側のオプション名はエディタ内のものと非常によく似ています。右側には、エディタ内のものとほぼ同じ値があります。ここでは、末尾に例を示す短いテキストはありません。特に注目すべきは、ユーザー名とパスワードがエンコードされた文字列で保存されていることです。このように保存することで、ユーザー名とパスワードを直接保存する必要がないようにしています。
しかし、JMPはそれらすべてに接続できました。先ほども言ったように、これはJSLです。プラットフォーム固有の設定を追加したい場合、組み込みの設定で既に確認済みです。しかし、自分で設定したい場合、例えば、まだ説明していないオプション、つまりブロックフェッチを選択したい場合、ブロックフェッチが有効になります。これは、有効にすればデータ取得の効率を高める機能ですが、サポートされていないか、正しく動作しない場合があります。
例えば、Macでは動作するのだが、Windowsでは動作しない、という状況を考えてみましょう。WindowsとMacでは有効にしたいのですが、それ以外では無効にしたいのです。このように、Block FetchオプションをこのJSL式に設定すると、右側の値はすべてJSLコードなので、目的の効果が得られます。
JMPはこの設定を読み込むたびに、これを評価します。「ああ、そうだ」と表示されます。今回の場合はMacなので、ブロックフェッチをオンにします。これで動作します。JMP自体もJSLを使ってこれらの設定を操作できます。邪魔にならないので、この部分は閉じておきましょう。
すべて閉じましょう。JMPに戻りましょう。ここでスクリプトエディタを開きましょう。これは定型文です。何ができるでしょうか？ファイルから設定を読み込むことができます。これはメモリ内のデータコネクタになります。もう一度見てみましょう…これまで作業してきたMySQLサーバーを見てみましょう。この行で読み込みます。これで設定が提供されます。その後、特定の値を取得するなど、設定済みのブロックフェッチオプションを取得できます。
あるいは、引用符の種類を取得することもできます。オプションを変更できるので、引用符の種類を以前の値（括弧）に戻すことができます。ブロックフェッチをオフにするだけで済みます。これで、再度出力して、期待どおりの効果が得られているかどうかを確認できます。これらをすべて実行すると、ブロックフェッチがオンになっていることがわかります。引用符の種類は二重引用符です。そして、設定後は、すべてがオフになっています。
これが、これを操作するためにできることの一部です。全体を見てみると、デフォルト値ではない値がすべて表示されます。例えば、ユーザー名とパスワードが表示されます。しかし、SQL Serverがデフォルトとは異なる他のオプションも多数あります。これらをすべて確認してください。レジストリ。名前から実際の設定へのマッピングもJSL経由でアクセスできます。
ここに変数があります。これで利用可能なすべてのエントリを取得するなどの操作を行うことができます。これは、作成したエントリとJMPに組み込まれているエントリの両方をリストします。Windowsでこれを行う場合は、アドイン経由でインストールされたものも表示されます。特定のエントリに関するメタデータを取得できます。ここで作成した設定を確認することもできます。これにより、名前とパスの両方がわかります。これらは重要な情報ですが、種類も含まれています。ODBCなので、ドライバーも含まれています。
JSL用の設定を登録することもできます。例えば、独自の設定を記述したい場合は、MySQLServer2DCという名前にします。新しいパス変数を追加しました。パス変数についてご存知の方はご存知かと思いますが、これは先ほど示したデータコネクタフォルダを指しています。そこにテキストを書き込むことができます。
シンプルにしましょう。まずはMySQLサーバーの基本設定から始めましょう。例えば、ある設定を元に戻します。これで設定は完了です。最後に、follow my pathを使って登録します。名前は、他の設定と同様にファイル名と一致します。次にパスです。パスです。これらをすべて実行すれば、読み込みを試せるはずです。
ここでは、以前と同じことを2つ行います。動作が確認でき、何かが出力されます。変更した値も取得できます。そこに表示されているのが分かります。さて、繰り返しますが、JSLを使って設定を操作できることは既に確認しました。これらの設定を直接操作したい場合は、ファイルシステム上の場所を確認し、プラットフォーム固有の設定を追加できます。
たくさんお話しましたが、そろそろまとめに入りましょう。最初に戻りましょう。この取り組みには具体的な目標があると申し上げました。では、一つずつ見ていきましょう。まずは、より多くのデータソースに接続できるようにすることです。JMP 18では、ODBC内でのデータソースアクセスを拡張しました。例えば、SQL ServerのJSON型を変更することで、SQL Serverで何ができるのか、少しでも感じていただけたかと思います。
データソースとの互換性を強化しました。共有に関しては、JMP Live to Windows への共有機能をご紹介したことで、JMP Live to Windows で何ができるかご理解いただけたかと思います。最後に、より統一されたインタラクションを実現しました。これはこれまで見たことのない機能です。新しいインターフェースをご紹介しました。ODBC でのみ動作するインターフェースもご紹介しました。ここで重要なのは、私たちがODBCに注力し、他の機能のための基盤を築いていたということです。これは将来的に実現される予定です。
JMP 18.1の今後の展開についてお話しますと、主にエディターにいくつかの小さな機能強化を予定しています。JMP 19では、エディターにさらなる機能強化を加える予定です。しかし、より重要なのは、新しいタイプの接続が追加されることです。現在はODBCのみに対応していますが、他の機能にも拡張する予定です。まず最初に触れておきたいのはSASです。
JMP 18ではSAS接続を削除せざるを得ませんでしたが、JMP 19ではSAS接続を復活させ、このデータコネクタフレームワークに統合します。つまり、同じエディターで同じインターフェースを使用して設定を編集し、アドインのように設定を共有することが可能です。また、Amazon S3とMicrosoft SharePointへの接続も追加します。これは、以前から皆様からご要望をいただいていた機能だと思います。
S3とSharePointの興味深い点は、JMPと一緒に配布されないことです。SASについては、JMP 18以前のバージョンと同等の機能を目指しており、JMPと一緒に配布されます。以前から利用できていたGSL機能の多くにアクセスできるようになります。
S3とSharePointについては、JMPにパッケージ化されませんが、JMPマーケットプレイスを通じて配布されます。ご存知の方もいらっしゃるかもしれません。もしご存知でなければ、Discoveryのどこかで耳にすることになるでしょう。
簡単に言うと、これはJMPの拡張機能を配布する方法になります。S3とSharePointへの接続も、この方法で配布する予定です。これらの拡張機能をJMPで動作させるために、JMPから公開されるPython APIを定義します。このAPIは、コネクタフレームワークに接続するために必要なすべての機能と連携し、クエリビルダーなどにも利用できるようになります。
これらを実装するために、このインターフェースと既存のPythonライブラリを使用しました。これはPythonエコシステムの素晴らしさの一部であり、JMP 18のPython統合を改善するために私たちが行ってきた作業の成果でもあります。しかし、これは私たちだけに限定されるものではありません。
このインターフェースは今後公開し、ドキュメント化する予定です。これにより、私たちだけでなく、皆さんにも新しいタイプの接続を作成し、クエリービルダーと統合されたJMPと連携させることができるようになります。同じツールをすべて使用できます。
これが今後の取り組みです。私の話は以上です。改めて申し上げたいのは、18で行ったことが、ここでお話ししているような将来の改善の基盤を築くだけでなく、ODBCの機能を大幅に向上させるものになることを願っています。
より多くのデータソースに接続できるようになり、それらの接続をより簡単に共有できるようになるということです。繰り返しになりますが、私たちができることの面で、将来はさらに良くなると考えています。そこで何ができるのか、楽しみにしています。それでは、ご視聴ありがとうございました。ディスカバリーの続きもお楽しみください。
