検索

開発者の皆さん、こんにちは！ InterSystems デベロッパーツールコンテスト2023 の21の応募作品の中から、Experts Nomination 第4位に輝いた @Muhammad Waseem さんのiris-geo-map（インタラクティブに地図を生成し、地理データを視覚化するツール）についてご紹介します。 このツールは、Embedded Pythonを利用していて Folium Python ライブラリを使用されています。 特徴については @Muhammad Waseem さんの Open Exchange のREADMEもぜひご参照ください。 それでは、さっそく、使用開始までの手順です。（とても簡単です） IPM（InterSystems Package Mangaer：以前はZPMとも呼ばれていました）のクライアントツールを管理ポータルかスタジオからインポートしたら、以下コマンドを実行するだけでツールの準備が整います。 クライアントツールのインポートはどのネームスペースでも大丈夫です。管理ポータルからインポートされる場合は、以下メニューを利用します。 管理ポータル→システムエクスプローラ→クラス→インポート対象ネームスペースを選択→インポートボタンクリック ツールを配置したいネームスペースに移動し、ZPMコマンドを利用してインストールします。 zpm "install iris-geo-map" ZPMインストール時の出力例 USER>zpm "install iris-geo-map" [USER|iris-geo-map] Reload START (/usr/irissys/mgr/.modules/USER/iris-geo-map/1.0.4/)[USER|iris-geo-map] requirements.txt START[USER|iris-geo-map] requirements.txt SUCCESS[USER|iris-geo-map] Reload SUCCESS[iris-geo-map] Module object refreshed.[USER|iris-geo-map] Validate START[USER|iris-geo-map] Validate SUCCESS[USER|iris-geo-map] Compile START[USER|iris-geo-map] Compile SUCCESS[USER|iris-geo-map] Activate START[USER|iris-geo-map] Configure START[USER|iris-geo-map] Configure SUCCESS[USER|iris-geo-map] Activate SUCCESSUSER> インストールによって準備される dc.IrisGeoMap.Folium クラスの GetGeoDetails()メソッドを使って、住所情報から緯度経度の情報を取得してみましょう。 例は、インターシステムズジャパンの東京オフィスの住所です。 USER>do ##class(dc.IrisGeoMap.Folium).GetGeoDetails("6-10-1 Nishi-Shinjuku, Shinjuku-ku,Tokyo,160-0023") Location: 35 40m 53.5184s N, 139 42m 51.223s E Address: 外苑西通り, 大京町, 新宿区, 東京都, 160-0015, 日本 Latitude: 35.6815329 Longitude: 139.7142286 使用されているコードは以下の通りです。（Embedded Pythonを使用しています） ClassMethod GetGeoDetails(addr As %String) [ Language = python ] { from geopy.geocoders import Nominatim geolocator = Nominatim(user_agent="IrisGeoApp") try: location = geolocator.geocode(addr) print("Location:",location.point) print("Address:",location.address) point = location.point print("Latitude:", point.latitude) print("Longitude:", point.longitude) except: print("Not able to find location") } こんな具合で緯度経度情報を取得できるので、この結果を利用していくつかの場所にピンを指した地図を作成してみましょう（結果はHTMLで出力されます）。 この処理には、dc.IrisGeoMap.Folium クラスの MarkGeoDetails() メソッドを使用します。 do ##class(dc.IrisGeoMap.Folium).MarkGeoDetails("6-10-1 Nishi-Shinjuku,Fujiyoshida,Gion,Sapporo,Fukuoka,Osaka","irisgeomap_locations.html") 実行が完了すると第2引数で指定したディレクトリ、ファイル名でHTMLが生成されるので開いてみます。 インターシステムズ東京オフィス、富士吉田市、祇園、札幌市、大阪市、福岡市を地点に指定した結果が表示されました！ コードは以下の通りです。 GetGeoDetails()メソッドと同様に、第1引数に指定された住所情報から緯度経度情報を取得し、folium.Mapでマップオブジェクトを作ってから、folium.Markerで地図にピンを指しています。 Pythonを使うことで、こんなに簡単に地図にピンがさせてしまうのですね！ Python便利です。 ぜひ皆さんのお手元でも試してみてください！

この連載記事では、InterSystemsの技術とGitLabを使用したソフトウェア開発に向けて実現可能な複数の手法を紹介し、議論したいと思います。 次のようなトピックについて説明します。 Git 101 Gitフロー（開発プロセス） GitLabのインストール GitLabワークフロー 継続的デリバリー GitLabのインストールと構成 GitLab CI/CD コンテナを使用する理由 コンテナインフラストラクチャ コンテナを使用したCD 第1回の記事では、Gitの基本、Gitの概念を高度に理解することが現代のソフトウェア開発にとって重要である理由、Gitを使用してソフトウェアを開発する方法について説明しています。 第2回の記事では、ソフトウェアのライフサイクルの完全なプロセスであるGitLabワークフローについて説明しています。 第3回の記事では、GitLabのインストールと構成ならびに利用環境のGitLabへの接続について説明しています。 第4回の記事では、CDの構成を説明しています。 第5回の記事では、コンテナとその使用方法（および使用する理由）について説明しています。 第6回の記事では、コンテナを使用して継続的デリバリーのパイプラインを実行する必要がある主なコンポーネントと、それらすべての連携の仕組みについて説明しています。 この記事では、これまでの記事で説明した継続的デリバリーの構成を構築します。 ワークフロー 継続的デリバリーの構成では、次のことを行います。 GitLabリポジトリにコードを Push する Dockerイメージをビルドする テストする Dockerレジストリにイメージを公開する 古いコンテナをレジストリの新しいバージョンと入れ替える 図解では以下の通りです： 詳細は以下の通りです。 ビルド まず、Dockerイメージをビルドする必要があります。 インターシステムズの製品内で使用するコードはいつものようにリポジトリに保存され、CD設定は gitlab-ci.yml に保存されますが、それに加えて（セキュリティを高めるために）ビルドサーバーにサーバー固有のファイルをいくつか保存します。 GitLab.xml このファイルには、CDフックコードが含まれています。 前の記事で開発したもので、 GitHubで公開されています。 これはコードをロードしたり、さまざまなフックを実行したり、コードをテストするための小さなライブラリです。 好ましい代替策として、 gitサブモジュールを使用して、このプロジェクトまたは類似のものをリポジトリに含めることができます。 サブモジュールの方が最新の状態に保つことが簡単なので良いでしょう。 もう1つの方法としては、GitLabでリリースにタグを付け、 ADD コマンドで読み込む方法があります。 iris.key IRISのライセンスキーです。 サーバーに保存するのではなく、コンテナのビルド中にダウンロードすることもできます。 リポジトリに保存するのはあまり安全ではありません。 pwd.txt デフォルトのパスワードを含むファイル。 繰り返しますが、リポジトリに保存するのは安全ではありません。 また、別のサーバーでprod環境をホストしている場合は、デフォルトのパスワードが異なる場合があります。 load_ci.script 初期スクリプトは： OS認証を有効にする GitLab.xmlをロードする GitLabユーティリティ設定を初期化する コードをロードする set sc = ##Class(Security.System).Get("SYSTEM",.Properties) write:('sc) $System.Status.GetErrorText(sc) set AutheEnabled = Properties("AutheEnabled") set AutheEnabled = $zb(+AutheEnabled,16,7) set Properties("AutheEnabled") = AutheEnabled set sc = ##Class(Security.System).Modify("SYSTEM",.Properties) write:('sc) $System.Status.GetErrorText(sc) zn "USER" do ##class(%SYSTEM.OBJ).Load(##class(%File).ManagerDirectory() _ "GitLab.xml","cdk") do ##class(isc.git.Settings).setSetting("hooks", "MyApp/Hooks/") do ##class(isc.git.Settings).setSetting("tests", "MyApp/Tests/") do ##class(isc.git.GitLab).load() halt 1行目は意図的に空欄にしてあることにご注意ください。 設定によってはサーバー固有のものもあるので、リポジトリではなく個別に保存しています。 この初期フックが常に同じである場合は、リポジトリに保存すればよいだけです。 gitlab-ci.yml 次に、継続的デリバリーの構成のを参照します： build image: stage: build tags: - test script: - cp -r /InterSystems/mount ci - cd ci - echo 'SuperUser' | cat - pwd.txt load_ci.script > temp.txt - mv temp.txt load_ci.script - cd .. - docker build --build-arg CI_PROJECT_DIR=$CI_PROJECT_DIR -t docker.domain.com/test/docker:$CI_COMMIT_REF_NAME . ここでは何が起きているのでしょうか？ まず、最初にdocker build はベースのビルドディレクトリのサブディレクトリにしかアクセスできないので（この場合はリポジトリルートにのみ）、「秘密の」ディレクトリ (GitLab.xml、iris.key、pwd.txt および load_ci.scriptがあるもの）をクローンしたリポジトリにコピーする必要があります。 次に、最初のターミナルアクセスにはユーザーとパスが必要なので、load_ci.script に追加します（ load_ci.script の先頭の空行はそのためのものです）。 最後に、dockerイメージをビルドして次のように適切なタグを付けます。 docker.domain.com/test/docker：$CI_COMMIT_REF_NAME ここで $CI_COMMIT_REF_NAME は、現在のブランチの名前です。 イメージタグの最初の部分は、GitLabのプロジェクト名と同じ名前でなければならないので、GitLabのレジストリタブで確認することができます（タグ付けの方法はレジストリタブで確認することができます）。 Dockerfile Dockerイメージのビルドは、次のようにDockerfile を使用します。 FROM docker.intersystems.com/intersystems/iris:2018.1.1.611.0 ENV SRC_DIR=/tmp/srcENV CI_DIR=$SRC_DIR/ciENV CI_PROJECT_DIR=$SRC_DIR COPY ./ $SRC_DIR RUN cp $CI_DIR/iris.key $ISC_PACKAGE_INSTALLDIR/mgr/ \ && cp $CI_DIR/GitLab.xml $ISC_PACKAGE_INSTALLDIR/mgr/ \ && $ISC_PACKAGE_INSTALLDIR/dev/Cloud/ICM/changePassword.sh $CI_DIR/pwd.txt \ && iris start $ISC_PACKAGE_INSTANCENAME \ && irissession $ISC_PACKAGE_INSTANCENAME -U%SYS < $CI_DIR/load_ci.script \ && iris stop $ISC_PACKAGE_INSTANCENAME quietly 基本的なIRISコンテナから開始します。 まず、コンテナ内にリポジトリ（および「秘密の」ディレクトリ）をコピーします。 次に、ライセンスキーと GitLab.xml を mgr ディレクトリにコピーします。 次に、パスワードを pwd.txt の値に変更します。この操作では、pwd.txt が削除されることに注意してください。 その後、インスタンスが起動され、load_ci.script を実行します。 最後に、IRISインスタンスを停止します。 これがジョブログです（部分的に、ロード/コンパイルをスキップしたログ）： Running with gitlab-runner 10.6.0 (a3543a27) on docker 7b21e0c4Using Shell executor...Running on docker...Fetching changes...Removing ci/Removing temp.txtHEAD is now at 5ef9904 Build load_ci.scriptFrom http://gitlab.eduard.win/test/docker 5ef9904..9753a8d master -> origin/masterChecking out 9753a8db as master...Skipping Git submodules setup$ cp -r /InterSystems/mount ci$ cd ci$ echo 'SuperUser' | cat - pwd.txt load_ci.script > temp.txt$ mv temp.txt load_ci.script$ cd ..$ docker build --build-arg CI_PROJECT_DIR=$CI_PROJECT_DIR -t docker.eduard.win/test/docker:$CI_COMMIT_REF_NAME .Sending build context to Docker daemon 401.4kB Step 1/6 : FROM docker.intersystems.com/intersystems/iris:2018.1.1.611.0 ---> cd2e53e7f850Step 2/6 : ENV SRC_DIR=/tmp/src ---> Using cache ---> 68ba1cb00affStep 3/6 : ENV CI_DIR=$SRC_DIR/ci ---> Using cache ---> 6784c34a9ee6Step 4/6 : ENV CI_PROJECT_DIR=$SRC_DIR ---> Using cache ---> 3757fa88a28aStep 5/6 : COPY ./ $SRC_DIR ---> 5515e13741b0Step 6/6 : RUN cp $CI_DIR/iris.key $ISC_PACKAGE_INSTALLDIR/mgr/ && cp $CI_DIR/GitLab.xml $ISC_PACKAGE_INSTALLDIR/mgr/ && $ISC_PACKAGE_INSTALLDIR/dev/Cloud/ICM/changePassword.sh $CI_DIR/pwd.txt && iris start $ISC_PACKAGE_INSTANCENAME && irissession $ISC_PACKAGE_INSTANCENAME -U%SYS < $CI_DIR/load_ci.script && iris stop $ISC_PACKAGE_INSTANCENAME quietly ---> Running in 86526183cf7c.Waited 1 seconds for InterSystems IRIS to startThis copy of InterSystems IRIS has been licensed for use exclusively by:ISC Internal Container ShardingCopyright (c) 1986-2018 by InterSystems CorporationAny other use is a violation of your license agreement %SYS>1 %SYS>Using 'iris.cpf' configuration file This copy of InterSystems IRIS has been licensed for use exclusively by:ISC Internal Container ShardingCopyright (c) 1986-2018 by InterSystems CorporationAny other use is a violation of your license agreement 1 alert(s) during startup. See messages.log for details.Starting IRIS Node: 39702b122ab6, Instance: IRIS Username:Password: Load started on 04/06/2018 17:38:21Loading file /usr/irissys/mgr/GitLab.xml as xmlLoad finished successfully. USER> USER> [2018-04-06 17:38:22.017] Running init hooks: before [2018-04-06 17:38:22.017] Importing hooks dir /tmp/src/MyApp/Hooks/ [2018-04-06 17:38:22.374] Executing hook class: MyApp.Hooks.Global [2018-04-06 17:38:22.375] Executing hook class: MyApp.Hooks.Local [2018-04-06 17:38:22.375] Importing dir /tmp/src/ Loading file /tmp/src/MyApp/Tests/TestSuite.cls as udl Compilation started on 04/06/2018 17:38:22 with qualifiers 'c'Compilation finished successfully in 0.194s. Load finished successfully. [2018-04-06 17:38:22.876] Running init hooks: after [2018-04-06 17:38:22.878] Executing hook class: MyApp.Hooks.Local [2018-04-06 17:38:22.921] Executing hook class: MyApp.Hooks.GlobalRemoving intermediate container 39702b122ab6 ---> dea6b2123165[Warning] One or more build-args [CI_PROJECT_DIR] were not consumedSuccessfully built dea6b2123165Successfully tagged docker.domain.com/test/docker:masterJob succeeded Docker executorではなく GitLabShell executor を使用していることに注意してください。 Docker executorはイメージ内の何かが必要な場合に使用します。 例えば、Androidアプリケーションをjavaコンテナでビルドしていて、apkだけが必要な場合などです。 この場合はコンテナ全体が必要になり、そのためにShell executorが必要になります。 そのため、GitLab Shell executorを使用してDockerコマンドを実行しています。 Run イメージができたので、次は実行してみましょう。フィーチャーブランチの場合、古いコンテナを破棄して新しいコンテナを開始すればよいだけです。 この環境の場合、一時的なコンテナを実行し、テストが成功した場合に環境コンテナを置き換えることができます（これは読者の方にお任せします)。 スクリプトは以下の通りです。 destroy old: stage: destroy tags: - test script: - docker stop iris-$CI_COMMIT_REF_NAME || true - docker rm -f iris-$CI_COMMIT_REF_NAME || true このスクリプトは現在実行中のコンテナーを破棄し、常に成功します（デフォルトでは、Dockerが存在しないコンテナーを停止または削除しようとすると、失敗します）。 次に、新しいイメージを開始して環境として登録します。 Nginxコンテナは、 環境変数 VIRTUAL_HOST と（プロキシするポートを知るため）expose命令使用してリクエストを自動的にプロキシします。 run image: stage: run environment: name: $CI_COMMIT_REF_NAME url: http://$CI_COMMIT_REF_SLUG. docker.domain.com/index.html tags: - test script: - docker run -d --expose 52773 --env VIRTUAL_HOST=$CI_COMMIT_REF_SLUG.docker.eduard.win --name iris-$CI_COMMIT_REF_NAME docker.domain.com/test/docker:$CI_COMMIT_REF_NAME --log $ISC_PACKAGE_INSTALLDIR/mgr/messages.log テスト テストをいくつか実行してみましょう。 test image: stage: test tags: - test script: - docker exec iris-$CI_COMMIT_REF_NAME irissession iris -U USER "##class(isc.git.GitLab).test()" 公開 最後に、レジストリにイメージを公開しましょう。 publish image: stage: publish tags: - test script: - docker login docker.domain.com -u dev -p 123 - docker push docker.domain.com/test/docker:$CI_COMMIT_REF_NAME ユーザとパスワードはGitLabの秘密の変数を使って渡すことができます。 これで、GitLabでイメージを確認できます。 そして、他の開発者がレジストリからそれをpullすることができます。 Environmentタブでは、すべての環境を簡単に参照できます。 まとめ この連載記事では、継続的デリバリーの一般的な手法について説明しました。 これは非常に広範なトピックであり、この連載記事の内容は完成されたものではなく、レシピを集めたものとして考えてください。 アプリケーションのビルド、テスト、デリバリーを自動化したいのであれば、継続的デリバリー全般、特にGitLabが最適です。 継続的デリバリーとコンテナを使うことで、必要に応じてワークフローをカスタマイズできます。 リンク 記事のコード テストプロジェクト CDの構成を完成する 次の内容 以上です。 継続的デリバリーとコンテナの基本をすべて網羅できたと思います。 特にコンテナーに関しては、話さなかったトピックがたくさんあります（多分、また後日お話します）。 コンテナの外にデータを保存することができます。これにに関するドキュメントがあります kubernetesなどのオーケストレーション・プラットフォーム InterSystems Cloud Manager 環境管理－テスト用の一時的な環境の作成、フィーチャーブランチ合併後の旧環境の削除 マルチコンテナ展開用の Docker compose Dockerイメージのサイズとビルド時間の削減

この連載記事では、InterSystemsの技術とGitLabを使用したソフトウェア開発に向けて実現可能な複数の手法を紹介し、議論したいと思います。 次のようなトピックについて説明します。 Git 101 Gitフロー（開発プロセス） GitLabのインストール GitLabワークフロー 継続的デリバリー GitLabのインストールと構成 GitLab CI/CD コンテナを使用する理由 コンテナを使用するGitLab CI/CD 第1回の記事では、Gitの基本、Gitの概念を高度に理解することが現代のソフトウェア開発にとって重要である理由、Gitを使用してソフトウェアを開発する方法について説明していますました。 第2回の記事では、アイデアからユーザーフィードバックまでの完全なソフトウェアライフサイクルプロセスであるGitLabワークフローについて説明しています。 第3回の記事では、GitLabのインストールと構成ならびに利用環境のGitLabへの接続について説明しています。 第4回の記事では、CDの構成を作成しています。 この記事では、コンテナとその使用方法（および使用する理由）について説明します。 この記事は、Dockerとコンテナの概念を熟知していることを前提としています。 コンテナとイメージについて知りたい場合は、@Luca Ravazzoloからの記事を確認してください。 メリット コンテナを使用することには次のような多くのメリットがあります。 移植性 効率 分離 軽量 不変性 これらについて詳しく説明しましょう。 移植性 コンテナは構成ファイルや依存関係など、アプリケーションの実行に必要なすべてのものを格納しています。 これにより、ローカルデスクトップ、物理サーバー、仮想サーバー、テスト、ステージング環境、プロダクション環境、パブリックまたはプライベートクラウドなどのさまざまな環境でアプリケーションを簡単かつ確実に実行できるようにしています。 移植性のもう1つのメリットは、いったんDockerイメージを構築して正常に動作することを確認したら、それはdockerが動作する環境（最近のWindows、Linux、MacOSサーバー）であればどこでも動作するということです。 効率 すべてのシステムソフトなどを実行する代わりに、自分のアプリケーションプロセスだけを本当に実行させる必要があります。 コンテナはまさにこの要件を満たすものです。コンテナは明示的に必要なプロセスのみを実行し、それ以外は何も実行しません。 コンテナは個別のオペレーティングシステムを必要としないため、使用するリソースが少なくなります。 VMは多くの場合数ギガバイトサイズですが、コンテナは通常数百メガバイトしかないため、単一のサーバーではVMよりも多くのコンテナを実行できます。 コンテナは基盤となるハードウェアをより高度に利用するため、必要なハードウェアが少なくなり、結果としてベアメタルのコストとデータセンターのコストが削減されます。 分離 コンテナはアプリケーションを他のすべてのものから分離します。また、同じサーバー上で複数のコンテナを実行できますが、それらは互いに完全に独立しています。 そのため、コンテナ間の通信は明示的に宣言する必要があります。 あるコンテナに障害が発生しても、それが他のコンテナには影響することはありません。障害が発生したコンテナはすぐに再起動できます。 このような分離によって、セキュリティ上のメリットも生まれます。 例えば、ベアメタルのウェブサーバーの脆弱性が悪用された場合は攻撃者がサーバー全体にアクセスできる可能性があります。しかし、コンテナの場合は攻撃者がアクセスできるのはウェブサーバーコンテナだけです。 軽量 コンテナは個別のOSを必要としないため、数秒で起動、停止、再起動できます。そのため、関連するすべての開発パイプラインと本番稼働までの時間が短縮されます。 そのため、より早く作業を開始し、設定に費やす時間をなくすことができます。 不変性 イミュータブルインフラストラクチャはインプレースで更新されるのではなく、デプロイするたびに置き換えられる不変のコンポーネントで構成されています。 これらのコンポーネントはデプロイのたびに1回作成され、テストと検証が可能な共通のイメージから起動されます。不変性によって不整合が抑制され、異なるアプリケーションの状態間で容易に複製や移動を行えるようになります。 不変性に関する詳細をお読みください。 新しい可能性 これらすべてのメリットにより、インフラストラクチャとワークフローをまったく新しい方法で管理できます。 オーケストレーション ベアメタル環境やVM環境には問題があります。これらには個別性があるため、予期できず、望ましくない多くの問題を、いずれもたらすことになります。 の問題に対する答えは、DevOpsチームがソースコードに使用するのと同じバージョン管理を使用した、記述モデルでのインフラストラクチャの管理手法であるInfrastructure as Code（コードとしてのインフラストラクチャ）です。 Infrastructure as Codeでは、デプロイコマンドは環境の起動状態に関係なく、常にターゲット環境を同じ構成に設定します。 これは、既存のターゲットを自動的に構成するか、既存のターゲットを破棄して新しい環境を再作成することによって実現されます。 したがって、チームはInfrastructure as Codeを使用して環境の記述を変更し、構成モデルにバージョンを付けます。これは、一般的にはJSONなどの適切にドキュメント化されたコード形式で記述されます。 リリースパイプラインは、モデルを実行してターゲット環境を構成します。 チームが変更を加える必要がある場合、チームはターゲットではなくソースを編集します。 これらはすべて実現可能であり、コンテナを使用する方がはるかに簡単です。 コンテナをシャットダウンして新しいコンテナを起動するには数秒かかりますが、新しいVMのプロビジョニングには数分かかります。そしてサーバーをクリーンな状態にロールバックすることさえ可能です。 スケーリング これまでの内容から、Infrastructure as Codeはそれ自体が静的であると理解されるかもしれません。 それは正しくありません。オーケストレーションツールは、現在のワークロードに基づいて水平スケーリング（さらに同じ環境をプロビジョニングすること）も提供できるためです。 現在必要なものだけを実行し、ニーズに応じてアプリケーションをスケーリングすれば良いのです。 これにより、コストを削減することもできます。 まとめ コンテナは開発パイプラインを合理化できます。 環境間の不整合が解消され、テストとデバッグが容易になります。 オーケストレーションを使用すると、スケーラブルなアプリケーションを構築できます。不変な任意の履歴ポイントへのデプロイやロールバックを簡単に実行できます。 組織は、上記のすべての問題が解決済みで、スケジューラーやオーケストレーターがより多くのことを自動処理するような高度な作業を望んでいます。 次の内容 次の記事では、コンテナを使用したプロビジョニングについて説明し、InterSystems IRIS Dockerコンテナを活用するCD構成を作成します。

開発者の皆さん、こんにちは！ InterSystems デベロッパーツールコンテスト2023が開催され、21の応募作品の中から勝者が発表されました🏆 この記事では、世界のIRIS開発者の皆さんから注目を集めた作品をご紹介します。 最初は、Experts Nomination 第1位に輝いた @Dmitry Maslennikov さんの作品をご紹介します！ @Dmitry Maslennikov さんが解説されている記事（Welcome irissqlcli - advanced terminal for IRIS SQL）もあります。ぜひこちらもご覧ください。 @Dmitry Maslennikov さんは、IRIS SQL用の高度なターミナル irissqlcli を開発されました。 irissqlcli を使用すると、SQL記述時にSQL構文、関数、型、IRIS内テーブル名、カラム名に対する候補が表示されるため、SQL文がとても書きやすくなります。 ヘルプも充実しています。（\n　でヘルプが表示されます） 接続先のテーブル一覧を取得する場合は「.tables」で取得できました。 また、以下のように記入時に入力候補が表示されます。Pygments を利用されているようで、シンタックスがハイライトされてきれいです。 ​​irissqlcli の利用方法は3種類ありますが、この記事では、2種類をご紹介します。 その1：pipでirissqlcliをインストールして使う方法 Pythonがインストールされている環境で、以下実行します。 pip install -U irissqlcli 後は、irissqlcliコマンドを利用して、お手元のIRISに接続するだけです。 接続情報の指定は以下の通りです。 irissqlcli iris://IRISのユーザ名:パスワード@ホスト名:スーパーサーバポート/ネームスペース名 IRISのユーザ名がSuperUserで、パスワードがSYS、localhostの1972のスーパーサーバポートのIRISのUSERネームスペースに接続する方法は以下の通りです。 irissqlcli iris://SuperUser:SYS@localhost:1972 実際の画面は以下の通りです。（exitを入力すると元のプロンプトに戻りました） ​​​​ その2：irissqlcli-web用コンテナを利用する方法 Webターミナルで実行できるコンテナが提供されているので、dockerをインストールした環境で以下実行します。 docker run -d --name irissqlcli --restart always -p 7681:7681 caretdev/irissqlcli-web irissqlcli iris://_SYSTEM:SYS@host.docker.internal:1972/USER 上記実行で、caretdev/irissqlcli-web:latestのイメージがPullされます。（イメージのサイズは157MBでした。とても小さいです！） イメージのPullが完了するとコンテナが開始され、コンテナのホストにインストールされているIRISのスーパーサーバポート1972番、USERネームスペースにアクセスします。 コンテナが正常に開始されたかについては、docker ps で確認できます。 >docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 40f556b8fdd8 caretdev/irissqlcli-web "/usr/bin/tini -- tt…" 3 seconds ago Up 1 second 0.0.0.0:7681->7681/tcp irissqlcli localhost:7681 にアクセスすると、以下のように irissqlcliのWebターミナル版が開きます。 コンテナを停止する場合は、以下の実行で停止できます。 docker stop irissqlcli コンテナを削除したい場合は、以下の実行で削除できます。 docker rm irissqlcli 接続するIRISのスーパーサーバポートやネームスペースを変更したい場合は、docker run で指定している末尾の引数（irissqlcli以降）の接続情報を変更するだけで切り替えができます。 以下の実行例では、スーパーサーバーポート：51778、ネームスペース：TRAININGに接続しています。 >docker run -d --name irissqlcli --restart always -p 7681:7681 caretdev/irissqlcli-web irissqlcli iris://_SYSTEM:SYS@host.docker.internal:51778/training fd5523695e10f75b0b1157cf001741fb5ddfae5f74b4f58a5a960f96f88f6006 プロンプトの右端に指定したネームスペースが表示されます。 どちらの方法も使用中IRISに追加のインストールが不要ですので、お手軽にご利用いただけると思います ぜひ皆さんのIRISでも試してみてください。また、返信欄に使った感想など、ぜひお寄せください！

開発者の皆さんこんにちは。 前回のお知らせで、フィードバック・ポータル「インターシステムズ・アイデア」を紹介しました。今回は、このポータルについて、特にそこで扱われるトピックについて詳しく説明したいと思います。 以下のカテゴリーでアイデアを募集しています！ 💡 InterSystems Products では以下の製品について新しい開発の方向性に関するアイデアを投稿することができます。 InterSystems IRIS data platform InterSystems IRIS for Health InterSystems HealthShare InterSystems TrakCare 💡 InterSystems Services では以下のインターシステムズのサービスをよりよくするためのアイデアを投稿できます。 Developer Community Open Exchange app gallery Global Masters gamification platform Partner Directory Documentation Certification Learning and InterSystems Ideas Portal itself また、インターシステムズ社の製品やサービスとは直接関係のないフィードバックについては、「その他」というカテゴリが用意されています。 There is also the category "Other" for feedback that is not related directly neither to InterSystems Products or Services. カテゴリーを選択した後、以下のようにキーワードやタグを自由に追加してください。 ポータルに追加する価値のあるカテゴリーやキーワードについてもお気軽にお寄せください。皆様からのご意見をお待ちしております。 ではインターシステムズ・アイデアポータルでお会いしましょう ✌️

InterSystems製品のバックアップ方法の中の４つの目方法は「コールドバックアップ」です。 InterSystems製品を停止できるときに利用できるバックアップ方法です。別サーバに環境を移植するときや、コミュニティエディションから製品版キットのインストール環境にデータベースを移植する場合などにもお使いいただけます。 バックアップ手順 1. InterSystems製品を停止する 2. バックアップしたいデータベースを退避する 3. InterSystems製品を開始する 既存環境から新環境へ移植する場合などの手順 1. 既存環境のInterSystems製品を停止する。 既存環境の設定など含めて全てを新環境に移植する場合は、以下記事の退避内容をご確認いただき、ご準備ください。 【IRIS】サーバーを移行する際にコピーが必要な設定情報 【Caché／Ensemble】サーバーを移行する際にコピーが必要な設定情報を教えてください 2. 新環境にInterSystems製品をインストールする。 1. の手順でコピーしていた情報をもとに、新環境の構成を設定します。 3. 新環境のInterSystems製品を停止する。 4. 既存環境のデータベースファイル（.DAT）を新環境の対象となるデータベースディレクトリに配置する（置換する） 対象：ユーザ用DB 5. 新環境のInterSystems製品を開始する。 6. 一括コンパイルを実行する。 IRISにログイン（またはターミナルを起動し）以下実行します。 Do $system.OBJ.CompileAllNamespaces("u") ご参考：データ移行関連アーカイブビデオ ✅動画：InterSystems IRIS へのデータ移行方法 Caché/Ensemble システムから InterSystems IRIS に移行する場合、マイグレーション(インプレース変換)を行うのでなければ現行環境と新環境を一時的に並行稼働させる必要があるかもしれません。 そのような場合のインストールや構成についての注意点やデータ移行にどのような技術が利用可能かについてご紹介します。 ✅動画：InterSystems IRIS へのマイグレーション Caché/EnsembleからInterSystems IRISへの移行プロセスについて解説しています。

InterSystems IRIS® データ・プラットフォーム 2022.3 からライセンス消費メカニズムにRESTとSOAPを追加しました。この変更により、コア・ベースライセンス以外でRESTまたはSOAPを使用している場合、アップグレード後にライセンス消費量が多くなる可能性があります。この勧告がお使いのシステムに該当するかどうかは、以下にあるFAQ(英語)のリンクをご参照ください。. ライセンス使用について、こちらの表にまとめています。 製品 REST と SOAP のリクエストがライセンスを消費するかどうか InterSystems Caché® する InterSystems Ensemble® しない InterSystems IRIS, InterSystems IRIS® for Health, Health Connect 2022.3 より前 しない InterSystems IRIS, InterSystems IRIS for Health, Health Connect 2022.3 以降 する お客様からはCaché と IRIS ではライセンス消費の一貫性を求められていました。今回の変更により REST と SOAP のライセンス消費がライセンス規約に準拠するようになります。また、すべての InterSystems 製品にわたって一貫性を維持します。バージョン 2022.3 を超えるアップグレードを計画する場合は、この変更による潜在的な影響を考慮する必要があります。 この変更の影響を理解しやすくするために、InterSystems は一時的な緩和策を含むリソースを提供しています。詳細については、以下を参照してください。 FAQ - ライセンス消費の変更について 本件に関する製品変更IDは DP-417320です。 ⚠ この勧告について質問がある場合は、カスタマーサポートセンター（jpnsup@intersystems.com）までお問い合わせください。

インターシステムズは、InterSystems IRIS®データプラットフォーム、InterSystems IRIS® for HealthTM、HealthShare® Health Connect のメンテナンスバージョン 2024.1.4 と 2023.1.6 をリリースしました。このリリースには以前ご案内した 警告：SQLクエリが間違った結果を返す の修正を含みます。製品の品質改善のために、開発者コミュニティを通じてぜひご意見をお聞かせください。 ドキュメント 詳細な変更リストとアップグレードチェックリストはこちらのドキュメントをご参照ください(すべて英語です):✅ 2024.1.4 InterSystems IRIS InterSystems IRIS for Health HealthShare Health Connect ✅ 2023.1.6 InterSystems IRIS InterSystems IRIS for Health HealthShare Health Connect 早期アクセスプログラム (Early Access Programs; EAPs) 多くの 早期アクセスプログラムをご用意しております。こちらの ページ からご興味のあるプログラムにお申込みいただけます。 キットの入手方法 InterSystems IRIS と InterSystems IRIS for Health の通常インストーラパッケージ形式のキットは WRC Direct の IRIS ダウンロードページ から、HealthShare Health Connect のキットは HealthShare ダウンロードページ からそれぞれ入手してください。コンテナイメージは InterSystems Container Registry から入手できます。 利用可能なパッケージ情報 本リリースでは従来からのインストーラパッケージ形式とコンテナイメージ形式をご用意しています。その一覧は、 2024.1サポートプラットフォームページ(英語) と 2023.1サポートプラットフォームページ(英語) をご覧ください。 本メンテナンスリリースのバージョン番号は、2024.1.4.512.0 と 2023.1.6.809.0 です。

これは InterSystems FAQ サイトの記事です。 同一システムに InterSystems 製品を複数インストールした場合、ドライバマネージャに登録される InterSystems 用の ODBCドライバは、インストールされた製品の中で最新バージョンのドライバが登録されたままとなります。 以下のレジストリエントリを変更することで、任意のドライバへ変更できます。 なお、RegFiles.bat 実行では ODBCドライバは切り替わらないのでご注意ください。 レジストリエントリは、以下の通りです。 HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBCINST.INI\InterSystems ODBC キーの Driver 値HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBCINST.INI\InterSystems ODBC キーの Setup 値 上記エントリには、現在使用中のドライバへのパスが記録されています。 これらを、切り替える対象となるドライバが存在するパスに変更してください。