.png)
InterSystems IRIS for Health™は、世界で最も重要なデータを管理する医療アプリケーションの迅速な開発を目的に特別に設計された世界初、かつ唯一のデータプラットフォームです。 トランザクションの処理と分析、拡張可能な医療データモデル、FHIRベースのソリューション開発、医療情報の相互運用性に関わる標準規格への対応など、すぐに使える強力な機能を搭載しています。 これらすべての機能により、開発者は価値を実現し、画期的なアプリケーションをすばやく構築することができます。 詳細はこちらをご覧ください
開発者の皆さん、こんにちは！
InterSystems オンラインプログラミングコンテストの次の内容が決定しました！
🏆 InterSystems プログラミングコンテスト：FHIR 対応 AI エージェント🏆
期間： 2026年5月25日～6月14日
賞金総額: $12,000
以前のバージョンにおいても、FHIRサーバーをOAuth 2.0経由でのリクエスト受付に対応させる設定が可能でした（例：SMART on FHIRクライアント向け）。しかし、現在では v2024.3, （以前リリースされたバージョン） , では、これをより容易に行える新機能が追加されました。具体的には、OAuth FHIR Client QuickStartが追加されました。
.png)
この「QuickStart」は、ウィザード形式の「ヘルパー」ツールであり、わずか5つの簡単なステップ（実際には3ステップのみです...）で、FHIRサーバーをOAuthサーバーに接続し、FHIRリクエストに対するOAuth認証および認可を有効にすることができます。
すでに定義済みのFHIRサーバー（エンドポイント）をお持ちの場合もあれば、まだ定義しておらず、このクイックスタートとして今定義したい場合もあるかもしれません。
IAMの管理を手動で行うには手間ががかります。OpenAPI（Swagger）仕様を使用して、APIがすでにしっかりとドキュメント化されている場合はなおさらです。 Open API仕様から直接、Kongサービスやルートを自動生成できたらいいのにと思いませんか？
このObjectScriptメソッドはまさにその処理を行います。仕様クラスの XData ブロック内に保管されているOpenAPI 2.0仕様を読み取り、IAM構成を同期するために使用できるdecKと互換性があるYAMLファイルを生成します。
メソッド ConvertOpenAPIXDataToDeckYAML の機能は次のとおりです。
OpenAPI仕様を読み取る： 指定したクラス内の OpenAPI という名前の XData ブロックから読み取ります。
JSONを解析する：動的オブジェクトに変換します。
エンドポイントを抽出する ：HTTPメソッドも抽出します。
以下は、2026 年の IRIS リリースカレンダーの更新情報と、2027 年に予定されている変更点の概要です。2026 年における主なポイントは、メンテナンスリリースのバージョン番号付けが、これまでの年とは若干異なる点です。
2026 年：IRIS 2026.1 メンテナンスリリースのバージョン番号
このバージョン番号付けの変更は、2027年に予定されているメンテナンス頻度の拡大に備えたものです。
2027 年：メンテナンスリリースの頻度拡大
2027 年よりお客様が IRIS の新バージョンをより迅速に導入できるよう、メンテナンスリリースの頻度を高める予定です。
2027 年のメンテナンスリリースに関する詳細は、来年発表される予定です。
EM および CD のリリースに関する詳細については リリースストリームのドキュメント をご覧ください。
InterSystems IRIS® データプラットフォーム、 InterSystems IRIS® for Health および HealthShare® Health Connect™ のメンテナンスバージョン 2025.1.4 および 2024.1.6 がリリースされました。今回のリリースでは、最近お知らせした以下の警告や勧告の修正が含まれています。
より良い製品を皆様と共に作り上げていくため、 アイデアポータル 内の リリース後のフィードバック カテゴリからご意見をお寄せください。
詳細な変更リストとアップグレードチェックリストはこちらのドキュメントをご参照ください(すべて英語 2025.
| 警告 ID | 影響を受ける製品とバージョン | リスクカテゴリー & スコア | 発生条件 |
| IF-9262 |
InterSystems IRIS® for Health InterSystems Health Connect™ |
システム安定性に関する懸念 5 (高リスク) |
FHIRおよび医療情報相互運用性の問題により、アップグレードが失敗したり、予期せぬ および 望ましくない製品の挙動が見られる |
|
勧告 ID |
影響を受ける製品とバージョン |
リスクカテゴリーとスコア |
発生条件 |
|
IF-9396 |
InterSystems IRIS® for Health InterSystems Health Connect™ バージョン |
システム安定線に関する懸念: 3 |
もっとも一般的なケースは、単一のウェブサーバに複数の構成をインストール する場合や、製品UIページをウェブサーバーのカスタマイズした論理パスに 適用する場合です。
影響を受けた構成では製品UIからFHIRサーバーの機能を実行することができません。その他の既存のAPI、ターミナルやObjectScriptのメソッドは影響を受けません。
| 警告 ID | 影響を受ける製品とバージョン | リスクカテゴリー & スコア | 発生条件 |
|---|---|---|---|
| HSIEC-12800 | InterSystems IRIS® for Health InterSystems Health Connect™ version 2026.1.0.233.0 | システム安定性に関する懸念 高リスク | 1. HL7 から SDA3 への変換が使用されている 2. 薬剤関連のメッセージには TQ1 セグメントが 含まれている 3. TQ1-3 リピートパターンには複数の繰り返し が含まれている |
HL7 から SDA3 への変換ロジックにおいて、特定の薬剤関連 HL7 メッセージを 処理する際に無限ループを引き起こす可能性のある問題が確認されました。 この問題は、メッセージに含まれる TQ1 セグメントの「TQ1-3 Repeat Pattern」 フィールドに複数の繰り返し設定が含まれている場合に発生します。
この条件が満たされる場合、該当する HL7 メッセージは SDA への変換に失敗す る可能性があります。
Claude CodeはIRISのことかなり理解してくれていますが、それでもやはり想定外が発生します。
まず１つ目は既に何回か発生した問題で、正しく指示しないと今後もよく発生する可能性の高い問題です。
IRISの文字型のデータ（%String）のコレーション（照合）は、デフォルトではSQLUPPERとなっていて、その結果としてデータをSQLで取得すると大文字に変換されて返ってくる場合があります。（GROUP BYなどのソートして集計する場合）
それを意識せずに（通常誰も意識していないと思いますが）、Claude Codeにそのデータの値に依存するような指示を与えると、期待した結果が得られないことが起こります。
例えば、何々のカラムの値がGroup BYで指定したカラムで集計した場合、返ってくるそのカラムの値が大文字となるため実際のデータはSupportだけれども実際に返ってくる値がSUPPORTとなっているためにマッチしないという感じです。
Claude Codeのスキルにこれをちゃんと記載するか、クラス定義のCOLLATEをSQLSTRINGに変更することでこの状況を回避できると思います。
もう一つ最近遭遇した問題は、これはさすがに難しいだろうという感じのものです。
IRISにはご存知の方も多いと思いますが、計算フィールドという非常に便利な機能があります。
データベースを確認したところ、巨大な^rINDEXSQLグローバルが存在しているようですが、これはなぜでしょうか？ 😬
管理ポータルのSQLページにおいて、「SQLステートメント」の下に「古いデータをクリーンアップ」ボタンがおりますが、これはどのような機能でしょうか？ 🤔
ステートメントのリストにおいて、一部のステートメントには「Location」値が設定されていますが、他のステートメントには設定されていないようです。これはどうしてでしょう？ 🤨
そうですね、確かにこれらはすべて関連しています。
一般的に、実行されたSQLクエリに関する基本的な統計情報 は保持しております。 キャッシュされたSQLクエリを削除する際、ステートメントリスト内のステートメントエントリ自体は削除せず、統計情報は保持いたします（将来の比較に役立つ可能性があるためです）。ただし、ロケーション列は「クリア」します（既存のキャッシュ済みクエリを指さなくなるためです）。 これらの「古い」ステートメント（もはやどこも指していないもの）をクリーンアップしたい場合は、「古いステートメントをクリーンアップ」ボタンを押することができます。
以下のような表示になります（システムエクスプローラー -> SQL -> SQLステートメント）：
.png)
[注記：旧バージョン（例：v2020.
Claude Codeを使うようになってから、創作意欲が爆上がりです。
今までは、何かを作りたいと思っても実際にコーディングをするのが面倒なので、よっぽどのニーズがないとプログラミングまでは至らなかったのですが、仕様をちょこちょこっと書くと後はClaude Codeが勝手にやってくれるので、生産性が雲泥の差です。
私はObjectScriptネイティブ世代なので、これからはPythonと言われても少し躊躇する部分がありましたが、逆にClaude CodeはPythonが大得意なので、新規に開発する際に、ObjectScriptを選ぶ理由がほとんどなくなりました。
とはいえ、Claude CodeがEmbedded Pythonのくせをどの程度理解しているか少し懸念があったのですが、それはかなり取り越し苦労だとわかってきました。
IRISのドキュメントに書かれていることは大体ちゃんと理解してくれています。
そして、自分でPythonコードを書いたら決して書けないような簡潔で洗練されたコードを書いてくれます。
今まであったらいいなと思いつつ、面倒なので、ほとんどやっていない処理としてテーブルのインポート・エクスポートがあります。
FHIR検索を、あらかじめ定義されたリソースの「リスト」ごとに制限することは、場合によってはより便利で、より効率的であり、より安全です。
バージョン2025.1より、当社のFHIRサーバーでは複数のリスト関連機能をサポートしております。
こちらでそれらを重点的にご説明し、いくつかの サンプルをご提供いたします。
一般的には、公式のFHIRドキュメントよりリストリソースの詳細について利用できます。
しかしながら、上記に基づいた簡単な 説明を以下に示します：
FHIRのリスト リストリソースは、フラット（オプションとしてオーダー付き）レコードの集合体を表し、臨床リスト（例：アレルギー、薬剤、アラート、病歴）やワークフロー管理（例：患者追跡、教育ケース）に使用されます。 リストは均質（単一のリソースタイプ）または 不均質（混合タイプ、例：状態、アレルギー・不耐性、処置にまたがる問題リスト）である場合があります。 リストは、単純なクエリでは取得できないキュレート・抽出されたデータセットが必要な場合に使用します（例：現在のアレルギーと全記録アレルギーの比較）。 リストをクエリすると、ポイント イン タイム スナップショットが得られます。 一方、リソースエンドポイントをクエリすると、通常はより広範でキュレートされていない「現時点での」データセットが返されます。
最新バージョン（2025.
インターシステムズは、InterSystems IRIS® data platform、InterSystems IRIS® for HealthTM、HealthShare® Health Connect のメンテナンスバージョン 2023.1.7 をリリースしました。
より良い製品を共に作り上げるため、アイデアポータル の「Post-Release Feedback」カテゴリでご意見をお寄せください。
ドキュメント
変更点の詳細と、アップグレードチェックリストは以下のリンクからご覧いただけます。(すべて英語)
早期アクセスプログラム(EAPs)について
現在、多くの早期アクセスプログラムをご提供しております。 こちらの ページ からご興味のあるプログラムにお申込みいただけます。
キットの入手方法
InterSystems IRIS と InterSystems IRIS for Health の通常インストーラパッケージ形式のキットは WRC Direct の IRIS ダウンロードページから、HealthShare Health Connect のキットは HealthShare ダウンロードページ からそれぞれ入手してください。
インターシステムズは、InterSystems IRIS data platform、InterSystems IRIS for Health および HealthShare Health Connect のバージョン 2026.1 をリリースをしました。2026.1 は、拡張メンテナンス（EM）リリースです。
データベース・スケーラビリティの強化
データベースの容量制限が撤廃されました。これにより、従来の容量制限をこえてもデータ移行が必要なく、円滑にシステム拡張できるようになりました。また低レベルパフォーマンスも改善され、大規模運用がさらに最適化されています。
ユーザー定義の論理キーに基づきテーブルと関連インデックスデータを分割し、データベース間で簡単にマッピングできるようになりました。これによりストレージの階層化が可能となり、大容量テーブルにおけるクエリパフォーマンスと運用効率が向上しました。この機能は早期アクセス・プログラムで提供されている実験的な機能です。早期アクセス・プログラムに参加いただくと、機能のアップデートを受け取ったり、フィードバックを送信することが可能となります。
相互運用プロダクションでは、HTTPクライアントとして動作するビジネスオペレーションを常に設定することが可能です。このオペレーションはOAuth 2.0による認証を利用しますが、この認証方式に対応するためにはオペレーションのカスタマイズが必要でした。 最近リリースされた v2024.3以降では、 この処理をより容易に行うための新機能が追加され、新たな設定オプションが提供されています。
HTTPアウトバウンドアダプターをご利用のビジネスオペレーションにおいて、OAuthグループの下に新しい設定項目が追加されております。
例えば：
新しいOAuth関連の 設定に関するドキュメントはこちらでご覧いただけます。
関連するオペレーションのスクリーンショットの例を以下に示します：
.png)
| 警告 ID | 影響を受ける製品とバージョン | リスクカテゴリー & スコア | 発生条件 |
| DP-449126 | InterSystems IRIS® data platform InterSystems IRIS® for Health InterSystems Health Connect™ versions 2024.1.0 – 2024.1.5, 2024.2.0, 2024.3.0, 2025.1.0 – 2025.1.3, 2025.2.0, 2025.3.0 |
データ整合性 低リスク | CSP セッションイベント用のカスタムロジックの一部として実行されるデータベース更新が、ジャーナリングされない可能性があります。 |
カスタムロジック内でのグローバルのSetおよびKillがジャーナルに記録されない問題を修正しました。修正対象となったカスタムロジックは、%CSP.SessionEvents のサブクラスを介して実装された CSP セッションイベント用に実行されるカスタムロジックです。
この問題は、カスタムロジックがミラーリングされたデータベースに対して行ったSetおよびKillでは発生しません。この条件下では、操作は通常どおりジャーナリングされます。
根本原因は、当該ロジックを実行するデーモンプロセスがプロセスごとのジャーナリング状態を、起動元プロセスから受け継いでいることにあります。
監査はサーバーのセキュリティを確保する上で極めて重要な機能であり、かなり 以前から、サーバーで実行されるSQL文を監査する機能を提供しております。
v2024.3 が既にリリースされておりますが、監査すべきこれらイベントを定義するためのより詳細なオプションを提供しております。
従来は、アクセスメカニズムに準じてSQL文の監査を決定することができました。例えば、JDBC/ODBCからの文の実行と、埋め込みSQL (例えば： コード内で&&sqlを使用する場合など) と、ダイナミックSQL(例えば：コード内で%SQL.Statement%SQL.Statementを使用する場合や、Mgmt. ポータルのSQLクエリ実行、あるいはターミナルのSQLシェルからの実行など）、そして今回、これに 加えて、 特定の種類のステートメントのみを監査対象とすることも可能です（アクセス制御機構に基づき、従来と同様に）。対象となる種類は以下の通りです：
データベースの要素や設定、その他のデータ以外のものを変更する文です。例：CREATE / ALTER TABLE
データを変更する文です。
開発者の皆さん、こんにちは。
先日の 第３回InterSystemsJapan開発者コミュニティミートアップでは、Google Colab を使ったワークショップを実施しました。
その際、解説を読みながら、その場でコードを実行できる Jupyter Notebook の良さを改めて実感しました。
こうした課題は、Notebook 形式にするだけで驚くほど解決します。
サンプルコードのすぐ横に解説を置けるので、迷う時間が減り、そのまま作業ドキュメントにもできます。
ObjectScript でも同じことができれば、学習にも現場作業にもとても便利ですよね。
実は以前、開発者コミュニティに Jupyter Notebooks に ObjectScript を追加する方法（https://jp.community.intersystems.com/node/521496）といった記事が紹介されていました。「これは便利そう！」と思い GitHub リポジトリ（https://github.com/Vekkby/objectsriptkernel
最近あるお客様にIRIS for Healthをご紹介する機会があり、技術者の方向けのデモを交えた説明をするためにIRIS for Healthのデモ環境の準備をしました。
元ネタは @Mihoko Iijima がポストした以下の投稿です。
FHIR R4 リソースリポジトリを簡単にお試しいただける開発環境テンプレートのご紹介
非常にわかりやすい動画での説明もあるのでご覧ください。
これから試す方向けに、新しいバージョン（2025.3）でお試しいただけるよう若干の修正をしましたので、紹介します。
https://github.com/TomoOkuyama/iris4h-demo
主な修正点は以下です。
メッセージを 簡単に再送信する機能は、相互運用性における当社の強力な特徴の一つであります。
v2024.3 がまもなくリリースされます（（開発者プレビュー版は既に利用可能です） 既に 公開済みです。これにより、さらに簡単になりました！
Visual Trace 内から、メッセージヘッダーの横に「再送信」ボタンを見つけられます。こちらをクリックすると、通常の「メッセージ再送信エディター」が表示されます（メッセージビューアーを経由して特定のメッセージを 検索する必要はありません）。
以下に、その例を示します：
.png)
関連するリリースノートもご覧ください。
| 警告 Id | 影響を受ける製品とバージョン | リスクカテゴリー & スコア | 発生条件 |
| DP-448888 |
製品: バージョン: |
運用: 高リスク | 2TB以上のデータベースキャッシュを使用したとき |
上記で指定されたバージョンでは、データベースキャッシュが 2,097,152MB(2TB) 以上の場合、インスタンスの起動が失敗したり、稼働中にシステムがハングする可能性があります。キャッシュ値を手動で設定していないインスタンスの初期データベースキャッシュは、システム物理メモリの 25% になるため、物理メモリが 8TB 以上ある場合は、キャッシュ未設定のインスタンスでは本障害が発生する可能性があります。詳細については、以下のドキュメントをご参照ください。
InterSystems IRIS for Health v2024.3 は、すでにしばらく前より 開発者向けプレビュー版として 提供されており、今回導入された FHIR 検索に関連する新しいサポートについてご紹介いたします。
以下の2つの修飾子 のサポートが追加されました：-
これにより、 より柔軟で洗練された、より豊富な検索クエリが可能になります。
また、検索結果のパラメータ -
を使用すると、よりコンパクトな（そしておそらくより効率的な）結果を得ることができます。
関連するリリースノートもご覧ください。
これは InterSystems FAQ サイトの記事です。
通常、フォームデータを受け取りたい場合は、CSPと同様に %request.Get() で受け取れます。
URLパラメータで、?name=123 のようにリクエストする場合も、同様に%request.Get(“name”) で受け取れます。
ファイルの場合は、%request.MimeDataで取得できます
例：
set%request.MimeData
HTMLやPostmanなどで、通常のテキストデータをフォームデータとして送る場合も、%request.Get() で受け取れます。
例：
"name"
ただ同じフォームデータを送る場合でも、例えばPowerShellで以下のように Invoke-RestMethod コマンドを利用して、ファイルを含む Form データをを送る場合、"txt" や "name" など一緒に送るパラメータもStreamデータとして送られます。
Invoke-RestMethod -Uri
その場合は、以下のように取得できます。
例：
"name"今回は、プログラミングというほどのこともないですが
IRISのフロントエンド開発ツールとしてReactを利用しています。
Reactに限らずWeb開発のフレームワークを利用する場合のポイントとしてCSSフレームワークをどうするかというのがあります。
今までは、定番というか一番とっつきやすいBootStrapを使用してきました。
利用が簡単な分、カスタマイズの幅が少ないかなということを感じていました。
とはいえ、他のCSSフレームワークを使うにしても、それをまた学習して、１から書き直すのも大変だなということでそのままにしてきました。
今回、Claude Codeという最強のツールを得たことで、BootStrapをMaterializeに変更するように依頼してみました。
結果は、一発で修正完了
実行確認まで5分もかからないスピード感で終了しました。
もし自分でMaterializeを自習して、実装した場合は、少なくとも２、3日はかかったのではないかと思います。
BootStrapの画面
Materializeの画面
すっかりClaude Codeにはまってきてしまいました。
前回はIRISデベロッパーらしくObjectScriptプログラミングの話ですが、今回は、Pythonプログラミングです。
私は、個人会社を持っていまして、経理の細かいことは、当然税理士さんにお任せなのですが、とはいえ日々の経費の管理は自分でやる必要があります。
基本はエクセルに経費情報を入力するというオペレーションなのですが、入力を省力化するためにIRISデータベースを使用したPythonプログラムを作っていました。
その中で本当はやりたいのだけれども、非常に煩雑で面倒臭い処理(決して難しい処理ではないですが)を先延ばしにしてきました。
そこでこれはClaude Codeの格好の題材だと思い、依頼してみることにしました。
結果は、三回のやり取り（実際には、二回目の依頼の際に間違えて送信ボタンを押したので、実質的に二回）で10分もかからずに修正が終わり、期待した通りの結果を得ることができました。
もし自分でコーディングをした場合、おそらく半日仕事、下手をすれば1日仕事だったかもしれません。
この経験を通して感じたのは、既存プログラムの修正には非常に使えるということです。
多少依頼内容に曖昧な点があっても、既存のコードを非常に高速かつ完全、網羅的に理解してくれるので、そういう曖昧性をある意味埋めてくれます。
InterSystemsテクノロジーを本番環境にデプロイする際の推奨事項の1つは、高可用性を設定することです。 これらのInterSystemsテクノロジーにお勧めのAPI Managerは、InterSystems API Manager（IAM）です。 IAM（特にKong Gateway）には複数のデプロイトポロジーがあります。
高可用性を重視する場合は、以下を利用できます。
a) Kong Traditionalモード：複数ノードクラスタ
b) Hybridモード
c) DB-lessモード
それぞれ詳しく説明する前に、最初にInterSystemsが提供するすぐに利用可能なデプロイを理解しましょう（IAMバージョン3.10のインストール）。
Kong Traditionalモード
Kong Traditionalモードは単一ノードクラスタです。 まだお読みでない場合は、@Guillaume.Rongier7183による素晴らしい記事、 IAM (InterSystems API Manager), Zero to Hero をお読みください。IAMの設定してInterSystems IRISで作業する方法についてついて非常に分かりやすく説明しています。
現在、Kong Traditionalモードの単一ノードクラスタは、IKO経由でのIAMデプロイオプションでのみサポートされています。
IRISではCSPタグベースの開発は、非推奨(Deplicated)になっています。
非推奨とはいえ、いますぐ使えなくなることはないと思います。
が、CSP機能に含まれるHyperEventの#server()#呼び出しは、かなりやばいということがわかってきました。
これはChromeを始めとするメジャーなブラウザーが提供しているSynchronous XMLHttpRequestという関数を呼び出しています。
この関数をGoogleは10年前くらいから非推奨機能としていて、いつか完全に機能をドロップすると宣言しています。
インターシステムズのドキュメントにもさりげなく記載されています。
とはいえ、10年もそのままなので、希望的観測をすれば、今後も使える可能性は高いかもしれません。
しかし、ある日突然なくなるリスクはゼロではありません。
ですので、#server()#呼び出しをお手元のコードからなるべく早く取り除くのが賢明です。
それでは、どうすれば良いのか？
ということですが、今のご時世で考えれば、REST APIに変えましょうというのが美しい世界ですが、おそらく書き換えのコストは、半端じゃないでしょう。
ということで、現実的な解は、#Call()#に置き換えることだと思います。
最近話題のClaude Codeを使って、ObjectScriptプログラミングをトライしてみました。
もちろんClaude CodeにObjectScriptのコードを書かせるにはそれなりの指示が必要ですが、適切なプロンプトを与えると想像以上にちゃんとしたObjectScriptコードを書いてくれます。
今回試したのは、少し前に投稿したCSPの#server問題に対応するため、#serverをREST APIに書き換えるというものです。
元のソースは、
https://github.com/wolfman0719/shopdemo
これはCSPのデモアプリケーションですが、しっかりと#server機能を使用しています。
結論をいうと、%sessionがRESTとCSP間で共有できないという根本問題があって、実行成功までには至っていませんが面倒なコーディングをかなりカーバーしてくれることがわかります。
(REST APIをCSPクラスで実装することで%session共有の問題を回避でき、Claude Codeが生成したロジックの正しさは証明されました)
そして、Claude Codeは、 ObjectScriptのことかなり理解してくれています。
ObjectScriptプログラマーが少ない問題を大きく改善してくれる可能性があります。
それでは、私がどのようなことを行ったか説明します。
あるお客さんから、ワークフローの待受画面での新着通知方法についてご相談がありました。
何か良い方法は無いでしょうか。 といった内容です。
この課題に対して調査したところ、以下の方式が見つかりました。
今回は以下の点について手順や設定等解説していきたいと思います。
nginx-push-stream-module を使った SSE (Server-Sent Events) 通知/subscribe) とサーバ送信 (/publish) の最小実装まずは全体像です。データの流れをシンプルに分けることで、役割が明確になります。
これは InterSystems FAQ サイトの記事です。
WebゲートウェイのSystem Status（システムステータス）ページでは、現在のすべてのアクティブな接続のステータスを確認することができます。
最初のステータステーブル (システムステータス) は、IRIS への接続に関する情報を表示します。
2番目のステータステーブル (InterSystems IRIS サーバ) は、InterSystems IRIS サーバに関する情報を表示します。
3 番目のステータステーブルは、アプリケーションパスの情報を表示します。
4 番目のテーブルは、Web ゲートウェイの応答キャッシュに保持されるフォームを表示します。
いくつかのサンプル接続ステータスを例にご説明します。
【ケース１】
接続最小数５の設定で、現在3接続が処理中の場合。
使用中のプロセスは InUse のステータス、待ち受けで空いているプロセスは Free で表示されます。
※Free の接続は、[非活動タイムアウト(無使用タイムアウト)] まで残り、タイムアウトを過ぎると自動的に終了します。
ただし、[サーバ接続最小数] 分の接続は上記タイムアウトが過ぎても残り、次のリクエストで使用されます。
アイドル時間/タイムアウトの表示例は、0/0(接続最小数で残り続ける接続) や、300/86400(タイムアウト86400秒中、300秒経過)になります。
※Server のステータスは、Webゲートウェイレジストリメソッドで使用のプロセスです。
CSP.iniで以下の設定をしている場合は、このプロセスは作成されません。
[SYSTEM]
REGISTRY_METHODS=Disabled
