#SOAP

InterSystems IRIS の新バージョンに、 Hierarchical Navigable Small World (HNSW) インデックス・アルゴリズムに基づく新しい近似最近傍探索 (ANN) インデックスが搭載されました。こちらは、ベクトル検索 早期アクセスプログラム で入手いただけます。これにより、大規模なベクトルデータセットに対して非常に効率の良い近似最近傍探索が可能となり、クエリパフォーマンスとスケーラビリティが大幅に向上しました。

HNSW アルゴリズムは、グラフベース構造を利用して高次元データのベクトル検索を最適化するよう設計されており、大規模なベクトル集合における近似近傍探索を高速化します。HNSW によって、レコメンデーションシステム、自然言語処理、その他の機会学習アプリケーションなどすべてにおいて検索時間が大幅に短縮します。

HNSWの主な利点:

    •    データセットサイズ増加後も、より高速な検索が可能
    •    高精度をたもちながら、メモリ使用量を削減
    •    既存の IRIS ベクトル検索とのシームレスな統合

最新バージョンのトライアル

最新バージョンは、ベクトル検索 早期アクセスプログラム に参加いただくことで入手いただけます。ご興味のある方は、プログラムページから登録し、新バージョンをダウンロードしてお試しください。

InterSystems IRIS® データ・プラットフォーム 2022.3 からライセンス消費メカニズムにRESTとSOAPを追加しました。この変更により、コア・ベースライセンス以外でRESTまたはSOAPを使用している場合、アップグレード後にライセンス消費量が多くなる可能性があります。この勧告がお使いのシステムに該当するかどうかは、以下にあるFAQ(英語)のリンクをご参照ください。.

ライセンス使用について、こちらの表にまとめています。

この記事では、Caché Webアプリケーション（主にREST）のテストとデバッグを外部ツールを用いて行うことについて説明します。 パート2では、Cachéツールの使用について説明します。

サーバー側のコードを作成したのでクライアントからテストしたい、またはすでにWebアプリケーションが存在するが機能していない― そういったときに使用できるのがデバッグです。 この記事では、最も使いやすいツール（ブラウザ）から最も包括的なツール（パケットアナライザー）までを説明しますが、まずは、最も一般的なエラーとその解決方法について少し説明します。

PHP はその公開当初から、多くのライブラリや市場に出回っているほぼすべてのデータベースとの統合をサポートしていることでよく知られています（またそのことで批判を受けてもいます）。 にもかかわらず、何らかの不可解な理由により、グローバル変数については階層型データベースをサポートしませんでした。

グローバル変数は階層情報を格納するための構造です。 Key-Value型データベースにある程度似ていますが、キーを次のようにマルチレベルにできるという点で異なっています。

Webサービスを呼び出す際、ビジネスオペレーションには、規定時間内に応答が返されない場合の動作を制御する設定があります。

InterSystems API Manager(IAM) バージョン1.5がリリースされました

以前のバージョンからアップグレードできるIAMコンテナはWRCソフトウェア配布サイトのComponents areaからダウンロードすることができます。

ビルド番号はIAM 1.5.0.9-4 です。

InterSystems API Manager 1.5 ではAPIトラフィックの管理や、環境とAPI利用者の統合がさらに簡単になりました。新機能は以下の通りです。

このリリースは、Kong Enterprise バージョン 1.5.0.9 をベースにしています。これまでのIAMリリースにはKong Enterpriseのホワイトラベルバージョンが入っていましたが、このリリースではホワイトラベルなしバージョンが入っています。この変更で、より頻繁にリリースすることができ、 Kongの提供するドキュメントやその他の資産を効果的に活用できるようになりました。

IAM 1.5のドキュメントはこちらです。このドキュメントはIAM固有の部分のみカバーしています。

これは InterSystems FAQ サイトの記事です

Web サービス(SOAP)またはREST で IIS を経由してクライアントにエラー応答する際、既定では IISが生成するデフォルトのエラーページ( HTTP 500 エラー)が返されます。

SoapFaultなど、サーバ側で出力したエラーの詳細情報は返されません。

IIS7 以降、WebクライアントがWeb サービスの障害の詳細情報を取得するための設定オプションが追加されました。

HTTP ステータスコードがエラーの場合に、既存の応答をどうするかを existingResponse 属性で指定することができます。

こちらの値を、既定の Auto から PassThrough に変更することで、エラーの詳細情報が返されるように変更できます。
※設定変更後、IISの再起動が必要です。

詳細や設定手順については、以下ドキュメントをご参照ください。
Microsoft IIS 7 以降の設定手順について【IRIS】

Microsoft IIS 7 以降の設定手順について

※web.config ファイルの手動編集よりも、IIS マネージャに組み込まれている構成エディタ を使用する方法がエラーが少なく安全です。

※HTTP エラー について
 

HealthShare の理想的な Apache HTTPD Web サーバー構成に関するお問い合わせをよくいただいています。 この記事では、真っ先に推奨される HealthShare 製品の Web サーバー構成について概要を説明します。

何よりもまず第一に、Apache HTTPD バージョン 2.4.x（64ビット）を使用することをお勧めします。 2.2.x のような旧バージョンも使用できますが、HealthShare のパフォーマンスとスケーラビリティを確保するにはバージョン 2.2 はお勧めできません。

これはInterSystems FAQ サイトの記事です。

デフォルトでは、セキュリティ脆弱性対応の観点でウェブサービス用テストページの実行を許可していません。

テスト目的等で利用する場合は、テストページへのアクセスを有効にする必要があり、以下グローバル変数のセットを %SYS ネームスペースで実行する必要があります。

set ^SYS("Security","CSP","AllowClass",0,"%SOAP.WebServiceInvoke")=1
set ^SYS("Security","CSP","AllowClass",0,"%SOAP.WebServiceInfo")=1

※この設定はウェブサービス用テストページのために必要な設定です。SOAPクライアントから通常のリクエストを実行する場合は設定不要です。

詳細については、以下のドキュメントもご参照下さい。

カタログおよびテスト・ページについて【IRIS】

カタログおよびテスト・ページについて 

みなさん、こんにちは。

数日前、SOAP（Web）サービスを使用して、REST に基づく新しいアプリケーション API と同じ認証を使用できるように、既存のレガシーアプリケーションを拡張したい、とお客様から伺いました。 新しいアプリケーションは OAuth2 を使用しているため、課題は明らかでした。SOAP リクエストを含むアクセストークンをどのようにしてサーバーに渡すか、ということです。

Google でしばらく調べてみたところ、SOAP エンベロープにヘッダー要素を追加してから、アクセストークンを検証するために必要なことを Web サービス実装が実行できるようにするのが 1 つの実現方法であることがわかりました。

最近、InterSystems 内で PHP から Caché ベースの Web サービスに接続が必要になる事例がいくつかありました。 これらの最初の事例とは、実はこの開発者コミュニティそのものであり、他の InterSystems サイト/アプリケーションとのシングルサインオンに Web サービスを使用しています。 次の例は、パスワード認証を使用して PHP から Caché ベースの Web サービス（具体的には SAMPLES ネームスペースの Web サービス）に接続する方法を示しています。

（注意: この例は、/csp/samples に対してパスワード認証が有効になっていることを前提としています。） 

InterSystems API Management（IAM）は、IT インフラストラクチャ内の Web ベースの API との間のトラフィックを監視、制御、および管理できる InterSystems IRIS Data Platform の新機能です。 アナウンスを見逃した方は、こちらのリンクを参照してください。 また、IAM の使い方を説明した記事もあります。

この記事では、InterSystems API Management を使用して API の負荷を分散します。

この例では、2 つの InterSystems IRIS インスタンスを使用し、クライアントに /api/atelier REST API を公開したいと思います。

そのようにしたいと思う理由は、次のようにさまざまです。

• 負荷分散により、サーバー間でワークロードを分散する。
• ブルーグリーンデプロイの実践。片方を「本番用」、もう片方を「開発用」とする 2 台のサーバーを用意し、それらを切り替えられるようにする。
• カナリアデプロイの実践。1 台のサーバーでのみ新しいバージョンを公開し、クライアントの 1 ％をそこに移動する。
• 高可用性構成の実現。
• その他。

最初の記事では、RESTForms（永続クラス用のREST API）について説明をしました。 基本的な機能についてはすでに説明しましたが、ここではクエリ機能を中心とする高度な機能について説明します。

• 基本クエリ
• クエリ引数
• カスタムクエリ

クエリ

クエリを使用すると、任意の条件に基づいてデータの一部を取得できます。 RESTFormsには、2種類のクエリがあります。

• 基本クエリは一度定義すればすべてのRESTFormsクラスに対して機能します。異なっているのはフィールドリストのみです。
• カスタムクエリはそれが指定され、使用できるクラスに対してのみ機能しますが、開発者はクエリの本文に完全にアクセスできます。

基本クエリ

一度定義すると、すべてのクラスか一部のクラスですぐに使用できます。 基本クエリはシステムによって定義されているものもありますが、開発者が追加することもできます。これらのクエリはすべて、SELECTのフィールドリストのみを定義します。 その他すべて（絞り込み、ページネーションなど）はRESTFormsによって行われます。 form/objects/:class/:query を呼び出すと、単純なクエリを実行できます。 2番目の :query パラメーターはクエリ名（クエリの SELECT と FROM の間の内容）を定義します。 デフォルトのクエリタイプは次のとおりです。