検索

Git を使用してIRIS でソリューションを構築することは、素晴らしいことです！ 単にローカルの git リポジトリにVSCodeを使用し、サーバーに変更をプッシュする... それは非常に簡単です。 でも、次の場合はどうでしょうか。 共有リモート開発環境で他の開発者と共同作業を行い、同じファイルの同時編集を回避したい場合 BPL、DTL、ピボット、ダッシュボードなどにおいて管理ポータルに基づくエディターを使用しており、 作業に簡潔なソース管理を使用したい場合 一部の作業においては引き続き Studio を使用しているかたまに VSCode から Studio に戻っているか、チームがまだ VSCode を完全に採用しておらず、一部のチームメンバーが Studio の使用を希望している場合 同じネームスペースで同時に多数の独立したプロジェクト（InterSystems Package Manager を使って定義された複数のパッケージなど）に取り組んでおり、（多数の個別のプロジェクトではなく）1 つの isfs 編集ビューからすべてのプロジェクトの作業を行い、適切な git リポジトリで変更を自動的に追跡する場合 このような状況では、あまり簡単なオペレーションとは言えませんでした。ただし、先月末に Git for Shared Development Environments（Open Exchange / GitHub）がリリースされるまでは、です。この拡張機能は、InterSystems パッケージマネージャーを使って入手できます。 zpm "install git-source-control" これがリリースされる前は、Git によるソース管理のオプションは、ほぼ Windows 限定かローカル開発環境限定の古い Git 拡張機能とこれに基づいた若干使用方法が合理化されているより最近の Open Exchange プロジェクトでした。 また、ファイルを処理するだけのバージョン管理システムに依存しない Port もあります。 git-source-control にあり、これらのパッケージには含まれないものとは何でしょうか？ あらゆるオペレーティングシステムで動作する単純なメニューベースの git 統合 リモート環境に SSH 通信することなく、増大する一連の共通 git アクティビティに対応する git ユーザーインターフェース 同じ環境で同時に作業する複数のユーザーを処理する並列制御。 クラスやルーチンなどに変更を行ったら、変更を破棄するかコミットするまでローカルに留まります。 （ただし、必要に応じて回避する方法があります！） パッケージマネージャー対応: zpm "load -dev /path/to/package" を行って、/path/to/package/.git が存在する場合は、パッケージのリソースへの変更はサーバーのファイルシステムの適切な場所に自動的に反映されます。 UI も、それが起動された class/etc に基づいて動作します。 このすべては VSCode より動作します。 スポイラー Studioからは以下の通り。 スポイラー git リポジトリを操作したり視覚的に状況をみるには スポイラー これを使って、IRIS ベースのソリューションの開発がうまくいけば幸いです。フィードバックをお待ちしています！ 注意 - 2021 Global Summit でのこのリリースのプレゼンテーションをご覧になるには、こちらの記事をご覧ください: https://community.intersystems.com/post/video-git-gitlab-shared-development-environments

これは InterSystems FAQ サイトの記事です。外部バックアップ機能と、SANソリューションが提供するスナップショット（スナップクローン、ミラークローンなど呼び方はベンダ毎に異なります）などのテクノロジを利用することで、バックアップ時のインスタンス停止時間を最短にすることができます。 操作手順概要は以下の通りです。 外部バックアップ用ユーティリティを利用して、データベースファイルへの書き込みを一時中断します(%SYSネームスペースで実行します)。 %SYS>set status=##class(Backup.General).ExternalFreeze() 外部のスナップショットユーティリティを使用して、ファイルシステムのスナップショットを作成します。 データベースファイルへの書き込みを再開するため、外部バックアップ用ユーティリティを使用します。 %SYS>set status=##class(Backup.General).ExternalThaw() バックアップメディアにスナップショットをコピーします。 【ご参考】ExternalFreeze() の処理は以下のようになります。 1. ジャーナルファイルの切り替え 2. データベースバッファ上の書き込み待ちバッファをすべてデータベースファイルに書き出す 3. ライトデーモンをサスペンド状態にする これらの処理の後、データベースファイルは静的な状態になり、外部のバックアップ処理によるバックアップが可能な状態(※)になります。※スナップショットコピーやミラーコピーの同期完了状態で切り離しが可能な状態。 この処理では、グローバルに対する書き込みを禁止していない為、データベースへの書き込みアクセスは、データベースキャッシュのバッファに余裕があれば可能です。ただし、ExternalFreeze() によるライトデーモンの不活動が長時間の場合、以下の条件で書き込みアクセスが待ち状態になります。 (1) 書き込み待ちのバッファ数が全バッファ数の70%以上になった場合 (2) ライトデーモンの不活動時間が10分以上(既定値)になった場合 (2)について、ライトデーモンの不活動時間のタイムアウト値は既定値で10分となっています。ExternalFreeze() が10分以上続く場合、ExternalThaw() が実施されるまで、書き込みアクセスが待ち状態になります。このライトデーモンの不活動時間のタイムアウト値は、ExternalFreeze() の第7パラメータにてsec単位で指定可能です。このタイムアウト値の範囲は、120秒～1200秒になります。 実行例： %SYS>s x=##class(Backup.General).ExternalFreeze(,,,,,,1200) ;タイムアウト値 20分 外部バックアップについての詳細は、以下のドキュメントをご覧ください。外部バックアップについて 各バックアップ方法については、以下の関連トピックをご覧ください。 【関連トピック】データベースのバックアップ方法について累積バックアップと差分バックアップの違いについて稼働中のインスタンスを停止せずにバックアップを行う方法データベースのバックアップについて(InterSystems Symposia 2014)VM Backups and Caché freeze/thaw scripts

コミュニティの皆さん、こんにちは。お元気ですか？ 皆さんは、創造性をどのようにして発揮していますか？ 新しいアイデアはどのようにしてテストしていますか？ 数年にもわたって、私はずっと新しいものを作り出し、既存のものを改良し、実験、テスト、破壊（いつも壊れてしまいます）を経て作り直し、そしてこのプロセスを繰り返してきました。 InterSystems が推進するコンテストは、モチベーションを大きく持ち上げてくれます。もちろん、賞品に目が行ってしまうことは否定できませんが。 しかし、賞品や報酬だけでなく、こういったコンテストでは自分の創造性が試されますし、作成、改良、テスト、実験の機会が得られます。 さらに、最も素晴らしいのは、何をやるのも自由であるということです！ 私の場合、こういった機会は、独自の [ホワット・イフ...?](https://en.wikipedia.org/wiki/What_If...%3F_(TV_series))（マーベルが作家に自由にストーリーを改良させるシリーズ）を作成できるチャンスと見なしているため、これらのアイデアを私と一緒に受け入れてくれる人がいたのは幸運でした @José.Pereira に感謝です。 前回の相互運用性コンテストでは [Message Viewer](https://openexchange.intersystems.com/package/IRIS-Interoperability-Message-Viewer?tab=details) を作成したのですが、今回の相互運用性コンテストでも Message Viewer をもう一度取り上げました。_ただし_、**独自のビジュアルトレース機能**を追加して、です！ InterSystems テクノロジーを使用しており、統合機能の部分（Ensemble/Interoperability）をご存知の方であれば誰でも、ビジュアルトレース機能は長い間、同じ状態のまま、問題なく存在していたことをご存知でしょう。 確かに機能しますし、メッセージのシーケンス図や詳細を表示して情報や XML を引き出したりできますが、 機能するからと言って、改善しない理由はありませんよね？ 新しい視点をもたらし、ちょっとした変化を促進してもよいのではないでしょうか？ 例として、Steve Rogers がいます。マーベルの主人公の 1 人であるキャプテン・アメリカですが、ペギー・カーターをキャプテンとして再構想、制作、テストしました😂 それでは、私たちが作った新しい「ペギー・カーター」、つまりビジュアルトレースについて少しお話ししましょう！  古き良きビジュアルトレースを以下に示します。  さて、ここに数千件ものメッセージがあり、単純なメッセージを簡単に再送できない状態であることを想像してみてください。 メッセージビューア画面に戻り、メッセージを掘り起こしながら、検索して再送信する必要があるでしょう。  そこで、新しい外観で情報を集めて単純な機能を提供することで、これが可能であることを示すことを考えました。開発者の日常業務が少しでも楽になると思います。  **デモ** このアプリを気に入ってもらえて、投票する価値があると思ってくれたなら、**IRIS Message Viewer** に投票してください！  

これは InterSystems FAQ サイトの記事です。 以下のような情報収集ツールがあります。 1) 性能評価の為のツール GLOSTAT グローバルアクセスのカウンター情報 mgstat グローバルアクセスのカウンター情報を連続してファイルに記録する JOBEXAM 問題のあるプロセスをモニターする SystemCheck または Buttons 内部情報の収集 使用方法詳細は以下の記事もご参照ください。 【IRISベース】トラブル発生時の情報収集方法（IRIS ／ IRIS for Health ／ UCR 編） 【Caché ベース】トラブル発生時の情報収集方法（Caché ／ Ensemble ／ HealthConnect 編） PERFMON グローバル、ルーチン、プロセス毎のグローバルアクセスカウンタ情報 収集例は添付のPDFをご参照ください PERFMON に用意された関数名を利用して、PERFMON で収集したデータをファイル出力するサンプルプログラムもご用意しています。 https://github.com/Intersystems-jp/FAQ-ZPERFMON PROFILE アプリケーションのルーチンおよびクラスのパフォーマンス解析（ルーチン単位に消費CPU、グローバル参照など取得可能） %SYS.MONLBL 特定のルーチンを行単位でパフォーマンス解析（処理時間など行単位に計測） 詳細については、以下ドキュメントをご参照下さい。 ^GLOSTAT を使用したグローバル動作の統計収集について【IRIS】 ^GLOSTAT を使用したグローバル動作の統計収集について ^PERFMON を使用したシステム・パフォーマンスの監視について【IRIS】 ^PERFMON を使用したシステム・パフォーマンスの監視について ^PROFILE を使用したルーチン・パフォーマンスの監視について【IRIS】 ^PROFILE を使用したルーチン・パフォーマンスの監視について ※PROFILEは、Caché2009.1で追加されたシステムルーチンです。 ^%SYS.MONLBL を使用したルーチン・パフォーマンスの検証について【IRIS】 ^%SYS.MONLBL を使用したルーチン・パフォーマンスの検証について ^mgstat を使用したパフォーマンスの監視について【IRIS】 ^mgstat を使用したパフォーマンスの監視について 2) Windowsのパフォーマンスモニター インターシステムズのユーティリティでありませんが、CPU、メモリ、ディスクI/O のどれがパーフォマンスのボトルネックになっているのかを特定する為に使用します。 使用方法については、「パフォーマンス調査ガイド　～知っておこう システムの基準値～」の P35～38 をご参照ください。 3) 情報収集例 パフォーマンス低下時に、1) でご紹介した mgstat と 2) の情報収集を行います。 1) の mgstat により、データベースに対するアクセス量が取得でき、2) によりパフォーマンス低下時、コンピュータのどの資源が不足しているかの判別の材料になります。 さらに必要であれば、1) のPERFMONの情報収集を行い 、これによりアクセスの多いグローバル、ルーチンの情報が取得できます。 特定のルーチンに対するパフォーマンス解析では、以下2つのルーチンを利用します。 ルーチンのCPU使用率、グローバル参照数、処理時間など計測する場合は　PROFILE 行単位でパフォーマンス解析（処理時間の計測など）を行う場合は　%SYS.MONLBL ご利用状況に合わせて、ご使用ください。

これは InterSystems FAQ サイトの記事です。IRISのプロセスを終了したい場合、管理ポータルから行う方法と、ターミナルからユーティリティやコマンドを使用して行う方法があります。 こちらのトピックでは、以下の3つの方法で停止する方法をご紹介します。 【プロセスの停止方法】 １．管理ポータルから停止する方法 ２．ユーティリティーで停止する方法（RESJOB、JOBEXAM） ３．プログラムで停止する方法 【注意】IRIS外から（Windowsならタスクマネージャーなど）、プロセスの終了は絶対に行わないでください。IRIS外からプロセス終了してしまうと、IRIS内部ではプロセスの削除を検知できなかったりすることで、IRISの動作が不安定になったり、システム全体がハングする危険性がありますので、ご注意ください。 外部から停止の例外が一つだけあります。$ZF コマンドによって起動された子プロセスが、何らかの問題で応答を返さなかった場合、$ZF コマンドを実行した親プロセスはそのまま残り続けます。そのような親プロセスを終了したい場合、通常の上記１～３の方法では停止できません。その際は、先に外部から子プロセスを停止する必要があります。子プロセスを特定するためには、以下の方法があります。 例：Windowsの場合 1. process explorer（マイクロソフト製） 2. PowerShell コマンド PS>wmic Process where '(parentprocessid=10188)' get 'processid,executablepath' では、以下に通常のプロセスを停止する方法をご紹介します。 １．管理ポータルから停止する方法 システムオペレーション > プロセスよりプロセス一覧を表示し、終了したいプロセスの 詳細 リンクをクリックし、詳細ページを開きます。 終了ボタンをクリックすると、モーダルダイアログが開くので、終了ボタンを押してプロセスを終了します。 ２．ユーティリティーで停止する方法（RESJOB、JOBEXAM） 管理者権限でターミナルにログインし、ユーティリティを実行します。 ★RESJOB USER>zn "%SYS" %SYS>do ^RESJOB Force a process to quit InterSystems IRIS Process ID (? for status report): 56528 // 終了したいプロセスIDを入力＋Enter で終了する Process ID (? for status report): // Enter で抜ける（ ? を入れるとプロセス一覧が表示される） %SYS> ★JOBEXAM %SYS>do ^JOBEXAM IRIS for Windows (x86-64) 2025.1 (Build 225_1U) Job# NSpace Routine Commands Globals State PID Current device 1 CONTROL 0 0 RUNW 66824 2 WRTDMN 26 357 RUNW 18340 3 GARCOL 0 0 RUNW 48172 4 JRNDMN 156 25 RUNW 44180 5 EXPDMN 0 0 RUNW 46292 6 %SYS %SYS.WorkQueueMgr133834 13242 SEMW 42112 //./nul 7 %SYS MONITOR 31238 78 EVTW 62572 //./nul 8 %SYS CLNDMN 0 21 RUNW 58484 //./nul 9 %SYS LMFMON 1587 80 EVTW 17168 //./nul 10 %SYS RECEIVE 795 97 HANGW 17212 //./nul 11 USER shell 362 37 READ 41016 |TRM|:|41016 // これを終了する場合 12 %SYS %SYS.WorkQueueMgr 77088 7396 EVTW 3848 //./nul 13 %SYS %SYS.SERVER 0 17 READ 48840 1972: 14 %SYS %SYS.TaskSuper 2073 135 EVTW 22480 //./nul 15 %SYS SYS.VSSWriter 0 14 RUNW 6884 //./nul 16 %SYS %SYS.Monitor.Co<5697596 2242094 EVTW 26840 //./nul 17 %SYS %SYS.WorkQueueMgr 4763 156 SEMW 39616 //./nul 19 %SYS %SYS.sqlcq.uEidd<133559 1338 RUN 37884 |TRM|:|37884 (N)ext,(P)rev,(G)oto,(E)xamine,(T)erminate,(S)uspend,(R)esume,(Q)uit => // T 押下（Terminate） Terminate: Enter Job # or "P" followed by the PID: P41016 // P+プロセスID または Job番号を入力＋Enter ： Job Terminated でプロセスが終了する ３．プログラムで停止する方法 USER>zn "%SYS" %SYS>do $SYSTEM.Process.Terminate(17456) // ^RESJOB ユーティリティと同じ。プロセスIDを指定して終了する %SYS> %SYS>do $SYSTEM.Process.Terminate() // 自分自身（現在の）プロセスを終了する場合

## コンテナ [InterSystems IRIS Data Platformの公開](https://community.intersystems.com/post/intersystems-iris-data-platform-201810-release)により、Dockerコンテナでも製品を提供しています。 コンテナとは一体何でしょうか。 基本的なコンテナの定義は、プロセスのサンドボックスの定義です。   コンテナは、たとえば実行できるという点において、仮想マシン（VM）に似た部分を持つソフトウェア定義パッケージです。  コンテナは、完全なOSエミュレーションを使わずに分離することができるため、 VMよりもはるかに軽量です。  本質的に、コンテナは、どのようにアプリケーションをシステムから別のシステムに確実に移動し、それが動作することを保証できるのかという問題に対する答えと言えます。 アプリケーションのすべての依存関係をコンテナにカプセル化し、プロセス分離領域を作成することにより、アプリケーションソリューションがプラットフォーム間で移動した場合でも動作するという高い保証を得ることができます。   プロセスは、オペレーティングシステムによって実行が可能です。 これらのプロセスはアドレス領域、ネームスペース、cgroupなどを共有し、通常、OSの環境全体にアクセスすることができます。それらのスケジュールと管理は、OSが行います。 すべて良いことではありますが、特定のプロセスやいくつかのプロセスを分離して、特定のタスクや演算、またはサービスを実行したい場合はどうでしょうか。 手短に言えば、プロセスを分離できる機能こそ、コンテナが提供している機能なのです。 したがって、コンテナをプロセスのサンドボックスとして定義することができるでしょう。  では、サンドボックスとは何でしょうか。 サンドボックスは、コンテナがプロセスを持つ分離レベルです。 この機能は、ネットワークインターフェース、マウントポイント、インタープロセス通信（IPC）、ユニバーサルタイムシェアリング（UTS）といったシステムのほかの重要な部分もサンドボックス化することのできるネームスペースと呼ばれるLinuxのカーネル機能により実装されています（）。  コンテナまたはサンドボックスは、制御グループまたはcgroupと呼ばれる別のカーネル機能によっても管理または制御することができます（）。 コンテナがほかのコンテナやホストとリソースを共有する上で、ほかのネイバーに害を与えないように、コンテナにルールが適用されます。  コンテナとVMの違いを理解するには、VMを_家_に、そしてコンテナを_マンション_に例えることができます。    VMは、一軒家のように、自己完結型で独立しています。 それぞれの家には、配管、暖房、電気といった固有のインフラストラクチャが備わっており、 最低要件も与えられています（最低、寝室は1室、屋根は1つなど）。  一方のコンテナは、共有のインフラストラクチャを使用するように作られているため、マンションとして捉えることができます。 マンションの建物は、配管、暖房、電機システム、正面玄関、エレベーターなどを共有していますが、これと同様に、コンテナも、Linuxカーネルを通じてホストが提供しているリソースを使用します。 また、マンションの各居住戸のサイズや形には様々なものがあることも考えましょう。  コンテナには完全なOSはなく、/binの実行可能ファイルや /etcの構成ファイルと定義ファイルといった、最小限必要なLinux OSしか備わっていないため、サイズが非常に小さくなります。そのため、その場所を移動したり、スピンアップする場合に、一秒きっかりで敏速に行うことができます。  コンテナを構築した瞬間から、ソフトウェアファクトリーのプロビジョニングパイプラインを通じ、本番環境での最終実行に至るまで、アジリティを得られることになります。 ちなみに、コンテナはCI/CDマイクロサービスアーキテクチャのコンテキストにピッタリと収まりますが、これはまた別の機会にお話ししましょう。 コンテナ内のプロセスは、コンテナのライフサイクルと密接な関係があり、 コンテナを_起動_すれば、アプリのすべてのサービスも起動して実行し（たとえば、あるWebサーバーコンテナのポート80と、InterSystems IRISコンテナのポート57772と1972）、 コンテナを_停止_すれば、すべてのプロセスも停止します。  この記事では、コンテナのランタイムの基本的な概念について説明しました。コンテナは、プロセスをホストやその他のコンテナから分離するサンドボックスです。  コンテナを理解するには、その[イメージ](https://community.intersystems.com/post/container-what-container-image)に関する別の側面もあります。 これについては、第2部の記事で説明することにします。

この記事は、「プライベートWebサーバ（PWS）を使用しないバージョンの新規インストール／アップグレード：概要」の続きの記事で、IISをWebサーバとする場合の設定概要をご紹介します。（先に「概要」の記事をお読みいただくことをお勧めします。） 同一サーバ上にIISとInterSystems製品をインストールする場合、事前にIISを有効化しておくとIISに必要なWebゲートウェイのインストールと設定をIRISのインストーラーが自動で行います。 以降の説明では、以下のインストール方法について解説します。 1. IISを事前に準備しない状態での新規インストール 2. IISを事前に準備しない状態でのアップグレード 3. IISをインストールした後の新規／アップグレードインストール 4. IISの設定 ※ 図解では、InterSystems IRISを使用していますが、InterSystems製品で操作は共通です。 1. IISを事前に準備しない状態での新規インストール インストーラーを起動し、新規インストールではセットアップタイプを選択した後、アップグレード時は対象インスタンスを選択した後、ローカルにWebサーバ（IIS）を検出できないため、以下の選択肢を表示します。 選択肢1) About the installtion インストールを中止する 選択肢2) Continue the instllation without Web Gateway Webゲートウェイのインストール無しでインストールを進める（インストール後Webアクセスが行えません） 【新規インストール時のインストーラーの表示】 【アップグレードインストール時のインストーラーの表示】 新規インストールで 選択肢2）「Continue the instllation without Web Gateway」 を選択した場合 Webゲートウェイをインストールしないでインストールを継続するオプションとなるため、Webアクセスが行えません（＝管理ポータルを開く方法がありません）。 バージョン2023.2以降、新規インストール時にプライベートWebサーバはインストールされません。 そのため、このオプションを選択した場合、Webサーバがローカルの構成に存在しないためWebアクセスに必要な設定（Webゲートウェイのインストールと設定）が行われないため、Webアクセスが行えません。 Webアクセスを行うためには、IISなどのWebサーバをインストールし、別途Webサーバに対してWebゲートウェイのインストールとIRISへの接続設定が必要となります。 詳細はドキュメント：Web ゲートウェイのみのインストールをご参照ください。 2. IISを事前に準備しない状態でのアップグレード 1. IISを事前に準備しない状態での新規インストールと同様に、インストールを中止するか、Webゲートウェイのインストール無しでインストールを進めるか、選択肢が表示されます。 2023.1以前のバージョンからのアップグレードする場合は、プライベートWebサーバがインストールされているため、アップグレード前と同じ方法でWebアクセスが利用できます。 管理ポータルのアドレス：　http://localhost:52773/csp/sys/UtilHome.csp IRISのランチャーからアクセスする場合は、インスタンス名（例ではiris）のパスが付いたアドレスで管理ポータルが開きます。 例）http://localhost:52773/iris/csp/sys/UtilHome.csp アップグレード前と同じURLでランチャーからアクセスしたい場合は、接続編集画面の「CSPサーバインスタンス」に追記されているインスタンス名を消してください。 3. IISをインストールした後の新規／アップグレードインストール 事前にIISをインストールした場合、インストーラーがWebサーバを検出し、以下の選択肢を表示します。 選択肢1) Configure local IIS web server for this instance インストール中インスタンス用にローカルのIISWebサーバを構成します。 選択肢2) Do not configure local IIS web server for this instance インストール中インスタンス用にローカルのIIS Webサーバを構成しません。 選択肢1) Configure local IIS web server for this instance を選択した場合 IISを経由した管理ポータルのアクセスが行えます。 URLは以下のルールで指定します。 http://Webサーバ/インスタンス名/csp/sys/UtilHome.csp 例）http://localhost/iris/csp/sys/UtilHome.csp IRISのランチャーからもこのアドレスで管理ポータルが開きます。 アップグレード時に 選択肢2)「Do not configure local IIS web server for this instance」を選択した場合 アップグレード前に使用していたプライベートWebサーバが利用できます。 Webアクセス方法について詳細は、2. IISを事前に準備しない状態でのアップグレード の記述をご参照ください。 新規インストール時に 選択肢2)「Do not configure local IIS web server for this instance」を選択した場合 Webゲートウェイをインストールしないでインストールを継続するオプションとなるため、Webアクセスが行えません（＝管理ポータルを開く方法がありません）。 IISを事前準備しないときの新規インストールと同様です。詳しくは [新規インストールで 選択肢2）「Continue the instllation without Web Gateway」 を選択した場合] をご参照ください。 4.IISの設定 IISをWebサーバとして利用し、VSCodeでデバッグを行う場合、IISのWebSocketサービスを有効化する必要があります。 詳細は、別の記事にあるデバッグ時の注意点をご参照ください。

これは InterSystems FAQ サイトの記事です。InterSystems IRIS Data Platform（以下IRISと表記）ではマルチモデルのサポートにより、データに対して様々なアクセス手法を使用することができます。 主だったアクセス手法としてダイレクトアクセス、SQLアクセス、オブジェクトアクセスがあります。 ダイレクトアクセス は、IRISのネイティブ構造であるグローバルと呼ばれるキーバリュー型のデータに直接アクセスする方法です。 SQLアクセス は、リレーショナルデータベースシステムにアクセスするための標準言語であるSQLを使用してデータにアクセスする方法です。 オブジェクトアクセス は、オブジェクト指向言語でオブジェクトを操作するための表記法として幅広く利用されるドット記法を使用してデータにアクセスする方法です。 ダイレクトアクセスとSQLアクセスおよびオブジェクトアクセスでは、処理の抽象度が異なります。 抽象度が高くなるに伴い、内部的な処理のオーバヘッドが増加するため、単純な1スレッド単位でのアクセススピードの速さについては、ダイレクトアクセスが、SQLアクセスとオブジェクトアクセスに比較して速い場合が多いです。 しかしながら、今後SQLアクセスに関してより高速に処理できるよう様々な開発が進行中です。 その点を考慮すると段々とその性能差が縮小していくことが期待できます。 一方で、IRISではマルチコア、マルチCPU環境またはシャーディング機能を利用することでSQLクエリーを並列実行する機能があるので、並列実行が効力を発揮するケースでは、ダイレクトアクセスで処理するより、圧倒的に高速に処理できる（集計処理など）場合があります。 オブジェクトアクセスとSQLアクセスでは、条件次第で、どちらが速いとは一概に言えませんが、一般的にはSQLで処理するほうが高速です。　 クエリー処理に関しては、オブジェクトアクセスではなくSQLで実装することが一般的です。 またアクセススピードの違いには、使用するプログラミング言語の違いによる影響もあります。 全てのアクセス手法においてネイティブなプログラム言語であるObjectScriptでコードを記述するのが最速であるケースが多いです。 JDBCやODBC等を使用したSQL、オブジェクトアクセスの場合には、ObjectScriptでデータベースに直接アクセスするのに比しネットワーク層を介する分オーバーヘッドが大きくなり、大量にデータをアクセスする際には処理時間に大きな差が発生します。 しかしながら他のプログラム言語でのアクセスもObjectScriptでのアクセスに比して遜色のない性能が出るように製品の改良を続けていきますので、その差は少なくなっていくことが期待できます。 速度を比較する際、異なるアクセス手法に対して、条件を同じにすることは、非常に難しいことです。 あるいは、単純な速度比較は無意味なケースもあります。 アクセススピードを考える時には、以下の視点が必要です。 例えば、データの入力処理を考えてみると、データ登録前に入力データの妥当性チェックが必要となります。 オブジェクトアクセスとSQLアクセスでは、データ保存処理時、システムによる型に基づく妥当性チェックを自動的に行います。 一方、ダイレクトアクセスでは、開発者が自分で、その処理用コードを追加する必要があります。 また、オブジェクト間に複雑な関連がある場合、オブジェクトアクセスの場合は、システムがその複雑さを理解しながら、適切に処理してくれるのに対して、SQLアクセスの場合は、処理単位が行単位のため、関連は開発者が自分で処理しなければならないケースもでてきます。 これらの事と、処理スピードとは、基本的に逆の相関関係にあり、何らかのトレードオフがつきものです。 以上のことを踏まえ、どちらを優先するか考えながら適切なアクセス手法を選択することをお勧めします。（繰り返しになりますが、マルチコア、マルチCPU、シャーディング環境では、クエリー処理に関してSQLで処理することで高速に処理できる可能性が高まります。） さらに、InterSystems製品のメリットは、各種アクセス手法を適宜使い分けることにより、アプリケーション開発を最適化できる点にあることを、ご理解いただけたら幸いです。

開発者の皆さん、こんにちは🌂 今年は早い梅雨入りでした ☔ さて、新しい✨ 実行／開発環境テンプレートを作成しました。 Docker 🐳、docker-compose 、git がインストールされていれば、すぐにお試しいただけます。ぜひご利用ください！ 今回は、ご存知の方が多いと思われる（？）某アニメの登場人物を使った人物相関図をテーマに【キーバリュー形式で IRIS に登録してグラフ構造で表示してみた】を体験できるテンプレートです（テンプレートは、Python／Node.js／Java からお試しいただける環境をご用意しています）。 人物相関図のイメージ 以下、今回のテーマについて、ビデオと文字でご紹介しています。最後までお付き合いいただければ幸いです！（ビデオは全体で 7 分 20 秒） 人物相関図と言えば、グラフデータベースをイメージされると思います。 IRIS はグラフデータベースではないのですが、IRIS ネイティブのデータの「グローバル」を利用することで、グラフデータベースと似たような構造を表現することができます。 IRIS の高パフォーマンスを支える 「グローバル」 は 40 年以上前（＝ InterSystems 創業）から InterSystems のコア技術であるデータベースとして提供されてきました。 「グローバル」 に対する操作方法は、現代のカテゴリに合わせるとしたら NoSQL データベースと言えます。 では、どのようにグラフデータベースのような構造を表現しているか？についてですが、グラフ構造は、ノードと辺から構成されていて、辺は 2 つのノードを結び付けるものです。 SNS の「友達」で考えると、ノードは「ユーザ」、辺は「友達関係」で表現できます。 テンプレートで使用している人物相関図では、ノードは「登場人物」、辺は「登場人物との関係」を表現しています。 人物相関図のノードと辺（エッジ） ノードと辺を、どのようにグローバル変数に設定しているでしょうか。 ノードは以下の通りです（配列には、画面表示に利用するノードの ID を設定し、右辺に人物名を登録しています）。 ^Relation("Eren")="主人公（エレン）" 辺（エッジ）は以下の通りです（グローバル変数の配列を利用して、登場人物 → 関係のある人 [ソース→ターゲット] を設定しています）。 主人公エレンは、アルミン、ミカサ、ジークと関係がある。を表現しています。 ^Relation("Eren","Armin")="" ^Relation("Eren","Mikasa")="" ^Relation("Eren","Zeke")="" 両者で関係がある場合は、さらに以下のような配列を追加します。 ^Relation("Mikasa")="エレンの幼馴染（ミカサ）" ^Relation("Mikasa","Armin")="" ^Relation("Mikasa","Eren")="" 実際に、IRIS サーバ側で記述する場合には、ObjectScript の SET コマンドを使用してグローバル変数を設定します。 set ^Relation("Eren")="主人公（エレン）" set ^Relation("Eren","Mikasa")="" set ^Relation("Eren","Armin")="" set ^Relation("Eren","Zeke")="" set ^Relation("Mikasa")="エレンの幼馴染（ミカサ）" set ^Relation("Mikasa","Armin")="" set ^Relation("Mikasa","Eren")="" 配列のサブスクリプト（括弧の中身）は、配列のノード（例では、第 1 番目と第 2 番目）毎に Unicode 昇順でソートされます。 実行後、管理ポータルなどからグローバル変数一覧を参照すると、実行順に関係なく Unicode 昇順にソートされていることを確認できます。 管理ポータルは、http://localhost:52779/csp/sys/UtilHome.csp でアクセスできます（ユーザ名：_system　、パスワード：SYS）。 ※ポート番号はご利用環境に合わせてご変更ください。 管理ポータル > [システムエクスプローラ] > [グローバル] > 左画面で「ネームスペース」USER を選択 > ^Relation の「表示」をクリック ここまでご紹介したグローバル変数に対する各言語のコード例については、テンプレート用リポジトリの以下サブディレクトリをご参照ください。 👉 https://github.com/Intersystems-jp/IRIS-NativeAPI-Template Python ：jupyter のコンテナを用意します（Jupyter は 8896 ポートでアクセスできます）。 Node.js：Node 12 のコンテナを用意します（8080 ポートで確認用 Web ページを参照できます）。 Java：OpenJDK 8 のコンテナを用意します。 1) テンプレートの処理概要 各言語ごとのシンプルなコード例とコンテナで提供している内容についての解説は、以下のビデオでもご紹介しています（全体で 9 分 20 秒）。 テンプレートでは、Python / Node.js / Java 用から IRIS 用コンテナへ、キーバリュー形式でのアクセスを行うため、Native API を使用しています。 各言語で必要な irisnative モジュールを使用するための手順は、言語ごとのサブディレクトリで解説しています。 Python Node.js Java ビデオでもご紹介していますが、シンプルなコード例は以下の通りです。 Python の例 #irisnativeモジュールインポート import irisnative #IRISに接続　(ホスト名,スーパーサーバポート番号,ネームスペース,ユーザ,パスワード) connection = irisnative.createConnection("iris",1972,"user","_system","SYS") #IRISインスタンス生成 iris_native = irisnative.createIris(connection) #値設定 iris_native.set("鎧の巨人\n（ライナー）","Relation","Reiner") iris_native.set("超大型の巨人\n（ベルトルト）","Relation","Bertolt") iris_native.set(None,"Relation","Reiner","Bertolt") iris_native.set(None,"Relation","Bertolt","Reiner") #Iterator() for source,value in iris_native.iterator("Relation").items(): print(source,"-",value) for target,value in iris_native.iterator("Relation",source).items(): print(" 関係者：",target) connection.close() Node.js の例 const irisnativeapi = require('intersystems-iris-native'); //接続 let connectionInfo = {"host": "nativeapi-iris","port": 1972,"ns":"USER","user":"_SYSTEM","pwd":"SYS"}; const connection = irisnativeapi.createConnection(connectionInfo); //IRISインスタンス生成 const irisNative = connection.createIris(); //値設定 irisNative.set("鎧の巨人（ライナー）","Relation","Reiner"); irisNative.set("超大型の巨人（ベルトルト）","Relation","Bertolt"); irisNative.set(null,"Relation","Reiner","Bertolt"); irisNative.set(null,"Relation","Bertolt","Reiner"); let ite1=irisNative.iterator("Relation"); //Iterator() for ([source,data] of ite1) { console.log("source"+"-"+data); let ite2=irisNative.iterator("Relation",source); for ([target] of ite2) { console.log(" 関係者：",target); } } connection.close(); 【Java の例】 package NativeAPI; import com.intersystems.jdbc.IRIS; import com.intersystems.jdbc.IRISConnection; import com.intersystems.jdbc.IRISDataSource; import com.intersystems.jdbc.IRISIterator; public class Test{ public static void main (String[] args) { try { //接続オープンには IRISDataSourceを使う IRISDataSource ds = new IRISDataSource(); // jdbc:IRIS://ホスト名:スーパーサーバポート/ネームスペース名 ds.setURL("jdbc:IRIS://localhost:1972/user"); ds.setUser("_SYSTEM"); //ユーザ名 ds.setPassword("SYS"); //パスワード IRISConnection dbconnection = (IRISConnection) ds.getConnection(); //create irisNative object IRIS irisNative = IRIS.createIRIS(dbconnection); irisNative.set("鎧の巨人（ライナー）","Relation","Reiner"); irisNative.set("超大型の巨人（ベルトルト）","Relation","Bertolt"); irisNative.set("","Relation","Reiner","Bertolt"); irisNative.set("","Relation","Bertolt","Reiner"); IRISIterator character=irisNative.getIRISIterator("Relation"); while (character.hasNext()) { String source=character.next(); System.out.println("\n人物 = "+ source + " - 説明："+ character.getValue()); //関係のある人を表示（^Relation） IRISIterator correlate=irisNative.getIRISIterator("Relation",source); while (correlate.hasNext()) { String target=correlate.next(); System.out.println(" 関係者 : "+ target); } } //irisの接続をClose irisNative.close(); dbconnection.close(); } catch (Exception ex) { System.out.println(ex.getMessage()); } } 2) Native API について Native API は、IRIS 内部のネイティブデータ（＝グローバル変数）を直接操作できる API で Python、Node.js、Java、.NET からアクセスできます。 グローバル変数の操作には、IRIS サーバーサイドプログラミングで使用する ObjectScript を利用しますが、Native API を利用することで、ObjectScript を使用せずにお好みの言語からアクセスすることができます。 また、Native API は、グローバル変数の設定／取得の他にも、クラスメソッド、ルーチン、関数を実行することができます。 3) テンプレートの使用方法 言語ごとのサブディレクトリにある README をご参照ください。 Python Node.js Java テンプレートの例に使用した某アニメの人物相関図ですが、実は完成していません。 あの登場人物がいない！とお気づきの方、ぜひ追加いただき、よろしければ記事の返信欄に貼り付けていただければ・・。 最後までお読みいただきありがとうございました！ 関連記事（NoSQLをテーマにした詳細説明付き記事）：Python Native APIでNoSQLデータベースにアクセス

[Global Summit 2022](https://learning.intersystems.com/course/view.php?id=2077) または [2022.2 ローンチウェビナー](https://www.intersystems.com/resources/whats-new-in-intersystems-iris-2022-2/)の内容からよく覚えていると思いますが、InterSystems IRIS の分析ソリューションに組み込むための目覚ましい新機能をリリースしようとしています。 分析クエリを桁違いに高速化する、代替の SQL テーブルデータ格納手法である[カラムナー(列指向)ストレージ](https://learning.intersystems.com/course/view.php?id=2112)です。 もともと 2022.2 の実験的機能としてリリースされましたが、[最新の 2022.3 開発者プレビュー](https://community.intersystems.com/post/intersystems-publishes-developer-preview-5-intersystems-iris-iris-health-healthshare-health)には多数の更新が含まれているため、別途ここで簡単に説明したいと思います。 ### 簡単な要約 カラムナーストレージにあまり詳しくない方は、[こちらの簡単な紹介動画](https://learning.intersystems.com/course/view.php?id=2112)かこの件に関する [GS2022 セッション](http://learning.intersystems.com/course/view.php?id=2077)をご覧ください。 手短に言うと、新しい `$vector` データ型を用いて、列ごとに 64k チャンクでテーブルデータをエンコーディングしています。 `$vector` は、疎データと密データの両方を効率的に格納できるように、アダプティブエンコーディングスキームを利用する（現時点では）内部専用のデータ型です。 エンコーディングは、一度に 64k チャンク全体の集計、グループ化、およびフィルタを計算し、可能な場合は [SIMD 命令](https://en.wikipedia.org/wiki/Single_instruction,_multiple_data)を利用するなどの、一連の専用の `$vector` 演算にも最適化されています。  SQL クエリ時に、これらのチャンクに対しても動作するクエリプランを作成して、これらの演算を利用します。想像できるように、従来の行単位での処理に比べ、これによってクエリを実行するための IO の量と ObjectScript 命令の数が大幅に削減されます。 もちろん、行指向における単一値演算に比べれば、個別の IO はより大きく、`$vector` 演算は多少重くなりますが、非常に大きなメリットがあります。 $vector データを処理し、チャンク全体を一連の高速な個々の演算にプッシュする実行戦略を「ベクトル化された」クエリプランと呼んでいます ### とにかく速い 最も重要なのは、すべてが高速化されたことです。 列インデックスに関するオプティマイザの理解が深まったことで、リクエストされたフィールドの一部が列インデックスまたはデータマップに格納されていない場合であっても、より多くのクエリが列インデックスを使用するようになります。 また、多くのケースで列インデックスとビットマップインデックスが組み合わせられるようになります。これは、列インデックスを既存のスキーマに追加することから始める場合に役立ちます。 新しいキットには、いくつかのクエリ処理の機能強化に対する低レベルの `$vector` 演算の最適化から並列化できるより広範な一連のベクトル化されたクエリプランまで、パフォーマンスを改善する多数の変更がスタック全体に含められています。 `INSERT .. SELECT` ステートメントなどによる特定のデータ読み込み方法も インデックスの構築にすでに使用しているバッファリングされたモデルを採用し、テーブル全体を非常に高いパフォーマンスで構築できるようになっています。 ### ベクトル化された JOIN このリリースで追加された最も注目すべき機能は、ベクトル化の方法による列データの JOIN のサポートです。 2022.2 では、クエリ内で 2 つのテーブルからデータを結合する場合、列編成のデータでも行編成のデータでも機能する堅牢な行単位の JOIN 戦略に頼っていました。 今回は、JOIN の両端が列形式で格納されている場合、新しいカーネル API を使用して、メモリ内で JOIN し、`$vector` 形式を保持することができるようになっています。 これは最も複雑なクエリであっても完全にベクトル化されたクエリプランにするもう 1 つの重要なステップです。 以下に、新しい関数を利用するクエリの例を示します。[前のデモ](https://github.com/bdeboe/isc-taxi-demo)で使用した New York Taxi データセットの自己結合を行っています。 SELECT   COUNT(*),   MAX(r1.total_amount - r2.total_amount) FROM   NYTaxi.Rides r1,   NYTaxi.Rides r2 WHERE   r1.DOLocationID = r2.PULocationID   AND r1.tpep_dropoff_datetime = r2.tpep_pickup_datetime   AND r2.DOLocationID = r1.PULocationID   AND r1.passenger_count > 2   AND r2.passenger_count > 2 このクエリは、乗客が 2 人を超えるルートのペアを検索します。2 番目のルートが最初のルートが終了する時点で同時刻に開始し、2 番目のルートが最初の開始地点に戻るルートペアです。 非常に有用な分析ではありませんが、このスキーマには実際のテーブルが 1 つしかなく、複合 JOIN キーのお陰で味気なさが少し緩和されています。 このステートメントのクエリプランには、`Apply vector operation %VHASH`（複合 JOIN キーの作成用）と `Read vector-join temp-file A` などのスニペットが含まれており、新しいベクトル化された結合が機能していることを示しています。 これは、長めのクエリプランにある小さく些細なもののように聞こえるかもしれませんが、内部では多くのスマートエンジニアリングが伴っています。このようなことをただ許可せず、スキーマレイアウトに厳しい制約を課す一般的なカラムナーデータベースベンダーがかなりの数存在しますので、ぜひ一緒にこれを楽しみましょう！ :-) クエリプランがその一時ファイルの読み取りを続けると、Join 後の作業にまだ行単位の処理が残っていることに気づくかもしれません。そこで... ### 今後の予定 カラムナーストレージは 2022.3 でも「実験的」となっていますが、本番対応に近づいており、間もなくマルチテーブルクエリ用の完全なエンドツーエンドベクトル化が可能になります(訳注：2023.1では本番用としてリリースされています)。 これには、先ほど述べた JOIN 後の作業、クエリオプティマイザのより幅広いサポート、カラムナーテーブルの読み込みのさらなる高速化、共有メモリサポートなどの JOIN のさらなる機能強化などが含まれます。 要するに、今こそ、2022.3 Community Edition を使用して [New York Taxi データセット](https://github.com/bdeboe/isc-taxi-demo/)を試してみる絶好の機会です（現時点では [IPM](https://openexchange.intersystems.com/package/NY-Taxi-Demo) で、または [Docker スクリプト](https://github.com/bdeboe/isc-taxi-demo)を使用）。そうすれば、2023.1 がリリースされる頃には「Run」を押すだけで済みます！ カラムナーストレージを独自のデータとクエリで使用する方法について、より具体的なアドバイスに興味のある方は、私かアカウントチームに直接ご連絡ください。[Global Summit 2023](https://www.intersystems.com/gs2023/) でお会いできるかもしれません ;-)

これは InterSystems FAQ サイトの記事です。 Linux で シェルスクリプト(shell script) からルーチンやメソッドを実行し戻り値を取得するには、iris コマンドを使用します。 詳細はドキュメント「インスタンスの接続について」 をご参照ください。 コマンド記述例は以下の通りです。 iris session インスタンス名 -U ネームスペース名 "実行ルーチン・メソッド" シェルスクリプトへの戻り値の指定は、ルーチンやメソッド終了時に指定する QUIT や RETURN コマンドに引数を指定する方法ではなく、プロセス処理終了時に %SYSTEM.Process クラスの Terminate() メソッドを使用して 特殊変数 $? に値を返す方法を利用します。 値は、0～255 を指定できます。 ルーチンでの利用例は以下の通りです。 // ルーチン名をTestとします start1() public { 　hang 5 // 5秒待つ 　//第2引数に指定した数値がシェルスクリプトに戻ります 　set st=$system.Process.Terminate($JOB,11) } 実行例は以下の通りです。 # iris session iris -U USER "start1^Test()" # echo $? 11 クラスメソッドでの利用例は以下の通りです。 Class Test.Class1 { ClassMethod test() { 　hang 5 // 5秒待つ 　//第2引数に指定した数値が シェルスクリプトに戻ります 　set st=$system.Process.Terminate($JOB,12) } } 実行例は以下の通りです。 # iris session iris -U USER "##class(Test.Class1).test()" # echo $? 12 関連情報もあります。以下、FAQサイトのトピックをご参照ください。 Windowsバッチでターミナルスクリプトを実行する方法を教えてください Windows のバッチスクリプトでIRISのルーチンやメソッドの戻り値を取得する方法を教えてください。

これは InterSystems FAQ サイトの記事です。 以下例のクラスメソッド getLatestID() のように ObjectScript のクラスメソッドを用意します。返したい値を戻り値に指定し、SQLストアドプロシージャ（SqlProc）キーワードを指定するだけで値が返せます。 ClassMethod getLatestID() As %Integer [ SqlName = getLatestID, SqlProc ] { set latestID=$Order(^ISJ.TestClass1D(""),-1) quit latestID } 操作を試す場合は、以下のクラス定義をご準備ください。 Class ISJ.TestClass1 Extends (%Persistent, %Populate) { Property name As %String; ClassMethod getLatestID() As %Integer [ SqlName = getLatestID, SqlProc ] { set latestID=$Order(^ISJ.TestClass1D(""),-1) quit latestID } } データ自動生成を行うユーティリティクラス（%Populate）を継承しているため、Populate() メソッドを実行するとテストデータが作成できます。以下の例では、10件の ISJ.TestClass1 クラスに対応するデータを作成しています。 （USER ネームスペースに上記クラスを定義した状態での実行例） USER>do ##class(ISJ.TestClass1).Populate(10) 作成したクラスメソッドをストアド関数として実行している例は以下の通りです。 （ターミナルをSQLの実行環境に変更してから SELECT文を実行している例です） USER>do $system.SQL.Shell() SQL Command Line Shell ---------------------------------------------------- The command prefix is currently set to: <<nothing>>. Enter <command>, 'q' to quit, '?' for help. [SQL]USER>>select ISJ.getLatestID() As LatestID 1. select ISJ.getLatestID() As LatestID LatestID 10 1 Rows(s) Affected statement prepare time(s)/globals/cmds/disk: 0.0545s/33171/145091/8ms execute time(s)/globals/cmds/disk: 0.0003s/1/415/0ms cached query class: %sqlcq.USER.cls30 --------------------------------------------------------------------------- [SQL]USER>>select ID from ISJ.TestClass1 2. select ID from ISJ.TestClass1 ID 1 2 3 4 5 6 7 8 9 10 10 Rows(s) Affected statement prepare time(s)/globals/cmds/disk: 0.0481s/33891/148856/0ms execute time(s)/globals/cmds/disk: 0.0003s/11/887/0ms cached query class: %sqlcq.USER.cls31 --------------------------------------------------------------------------- [SQL]USER>> また、以下実行例のように記述すると、最新 ID の name だけ表示します。 select name from ISJ.TestClass1 WHERE ID=ISJ.getLatestID()

これは InterSystems FAQ サイトの記事です。 SQLのINSERT/UPDATE/DELETE文で大量のデータを更新する際に、高速化する方法をご紹介します。以下の2つの手順を実行することで、更新処理のパフォーマンスを向上させることが可能です。 １．INSERT/UPDATE/DELETE時にインデックスを作成せず、あとでまとめて作成する ２．INSERT/UPDATE/DELETE時にジャーナルをOFFにする １は、%NOINDEX キーワードを指定してインデックスの生成を後でまとめて行うことで、インデックスの構築を抑制しパフォーマンスを向上させる方法です。 クエリ実行例は、以下のようになります。 例： UPDATE %NOINDEX tablename … INSERT %NOINDEX INTO tablename … DELETE %NOINDEX FROM tablename ... 更新後、あとでまとめてインデックスを再構築する場合は管理ポータルで行う方法と、コマンドで行う方法の2種類があります。 ◆ 管理ポータルの場合... [システムエクスプローラ] > [SQL]　(ネームスペース指定＆テーブルを選択して) アクション - テーブルのインデックスを再構築... ◆ コマンドの場合... Set sc = ##class(Schems.TableName).%BuildIndices() ２は、データ作成時にジャーナルをオフにすることでパフォーマンスを向上させます。ただし、トランザクションのロールバックにはジャーナルが必要ですので、ロールバックを正しく動作させたい場合にはこの方法は使用しないでください。また、こちらの機能は、ミラーリング対象のデータベースには使用できません。 方法は以下のようになります。 do DISABLE^%SYS.NOJRN // ジャーナリングを停止 do ENABLE^%SYS.NOJRN // ジャーナリングを開始

これは InterSystems FAQ サイトの記事です。 まず以下のようなREST APIを定義したクラスを作成します。 Class User.REST Extends %CSP.REST { Parameter HandleCorsRequest = 1; XData UrlMap [ XMLNamespace = "http://www.intersystems.com/urlmap" ] { <Routes> <Route Url="/req1" Method="GET" Call="req1"/> <Route Url="/req2/:value" Method="POST" Call="req2"/> <Route Url="/req3" Method="GET" Call="req3"/> </Routes> } ClassMethod req1() As %Status { write $G(^test) quit $$$OK } ClassMethod req2(value As %String) As %Status { set ^test=$g(value) quit $$$OK } ClassMethod req3() As %Status { write $ZDT($H) quit $$$OK } } 次にこのREST APIを呼び出すHTMLファイル(test.html)を作成します。 <html ng-app="xxx"> <head> <title>REST API Test</title> <script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.6.9/angular.min.js"></script> <script language="JavaScript"> var app=angular.module('xxx',[]); app.controller('AppController', ['$scope', '$http', function($scope, $http) { // running on load $http.get('http://localhost:52773/csp/rest/req1').then ( function(res) { $scope.x=res.data; } ,function(res) { $scope.x="NG!!!"; } ); // running on submit $scope.test2 = function() { alert($scope.name); $http.post('http://localhost:52773/csp/rest/req2/'+$scope.name).then ( function(res) { location.reload(); } ,function(res) { alert("NG"); } ); }; // runnning on click $scope.test3 = function() { $http.get('http://localhost:52773/csp/rest/req3').then ( function(res) { alert(res.data); } ,function(res) { alert("NG"); } ); }; } ]) </script> </head> <body ng-controller="AppController"> ^test : {{x}}<br><br> <form ng-submit="test2()"> update ^test: <input type="text" ng-model="name"> <input type="submit" value="Save!"> </form> <input type="button" value="OnClick" ng-click="test3()"> </body> </html> ------------------------------------------------------ サンプル実行方法 ------------------------------------------------------ (1) test.html をデスクトップなど適当なフォルダにおき、中身の接続先のポート番号を、管理ポータルと同じものに変更して保存。 (2) REST.cls を IRIS にインポート (3) ポータル > システム管理 > セキュリティ > アプリケーション＞ウェブ・アプリケーション > 新しいウェブ・アプリケーション作成 名前: /csp/rest ネームスペース: REST.clsのネームスペース ディスパッチクラス: User.REST (4) ターミナルで ^test を登録 set ^test=123 (5) test.html をダブルクリックで実行

お客様のシステムで発生した障害に対処するための製品修正や社内のコードレビューで新たに発見された潜在的な問題に対応するための修正などは、問題の重要度（運用に支障をきたす、アプリケーションの動作に影響があるなど）に応じて、順次新しいメジャーバージョン、メンテナンスバージョンに取り込まれていきます。 一方で、新しいバージョンのリリースには所定の時間が必要ですので、そのリリース前に該当する修正だけを適用したいというご要望にお応えするためにInterSystemsではアドホックと呼んでいる応急パッチを提供することも可能です。 しかしながら、この対応はあくまでも個別の応急処置であり、その問題が対処されたバージョンがリリースされた後には、そのバージョンをご使用いただくことを推奨致します。 この様な個別対応を繰り返し行うと、システムの構成管理が複雑化し、管理上のコストが上昇し、思わぬシステムトラブルの遠因になることもあります。 特に複数のエンドユーザー様に同じソリューションを提供する様なケースでは、システムの提供時期等によりシステム構成が変わり、適用可能なオペレーティングシステム等が変化することに伴い、全ての適用パッチを見直す必要が出てくることも想定されます。