すべて
ベストアンサー
DC AI Bot · 6月17日 記事へ

発生している事象について、取得できた情報から言えることは主に3点です。

  1. #988 が必ずしも TLS 設定そのものの失敗を意味しない場合があります。

    InterSystems の SSL/TLS 構成画面の「テスト」は、TLS ハンドシェイク後に GET / HTTP/1.0 を送信して応答を読みに行く実装になっており、相手サーバーがそれを想定していない場合は接続を閉じるため、#988: SSL connection failed のように見えることがあります。一方で、その情報では実際の HTTP リクエスト自体は成功していたとされています。したがって、SSL/TLS構成のテストで #988 が出ても、それだけで Office 365 向け TLS 構成が誤っているとは断定できません。 [1]

  2. Office 365 / Microsoft 側の基本認証廃止に対応する方向としては、OAuth 2.0 を使うのが適切です。

    取得した情報では、InterSystems は OAuth 2.0 クライアント機能を提供しており、外部の認可サーバー向けに authorization_endpoint、token_endpoint、jwks_uri、TLS/SSL 構成などを設定する形で連携できるとされています。また、Microsoft 向けの事例として、Azure Entra ID でのアプリ登録、リダイレクト URI の登録、/csp/sys/oauth2 の有効化、ログを使ったトラブルシュートが挙げられています。 [2]

  3. メール送信で Microsoft 365 を使う場合、少なくとも取得資料上は「アクセストークンを取得して、それを接続処理に渡す」方式が示されています。

    取得した情報では、InterSystems 側で不足しがちなのは「アクセストークン取得」であり、そこは外部コードや Embedded Python などで補う実装例が紹介されています。トークン取得後は、そのアクセストークンをメール接続処理に渡すやり方が説明されています。したがって、Microsoft が基本認証を廃止した現在、従来のユーザー名/パスワードだけに依存した SMTP 接続ではなく、OAuth 2.0 前提の構成を検討すべきというのが、取得情報から導ける結論です。 [2][3][4]

補足すると、Outlook/Office 365 の SMTP 接続例に関する別の議論では、ポート 587 を使うなら STARTTLS を使う必要があるという指摘があり、%Net.SMTP を使う場合は SSL/TLS 構成を作成し、smtp.SSLConfiguration を設定し、smtp.UseSTARTTLS = 1 にすることが案内されています。 [5]

したがって、あなたのケースでは次を切り分けるのがよさそうです。

  • #988 が SSL/TLS テスト画面だけで起きているのか、実際の送信処理でも起きているのかを分けて確認すること。テスト画面の失敗だけなら、相手サーバーの応答仕様による見かけ上の失敗の可能性があります。 [1]
  • SMTP 認証方式がまだ Basic Authentication 前提になっていないか確認すること。Microsoft 365 では OAuth 2.0 利用が推奨方向として示されています。 [2][3][4]
  • SMTP/587 を使うなら STARTTLS を有効にする設定になっているか確認すること。 [5]

なお、取得できた資料の中には、**「IRIS 上の smtp.office365.com で #988 が出る特定の TLS パラメータ不備」**を直接特定した情報はありませんでした。そのため、#988 の直接原因が Office 365 固有の証明書チェーン問題なのか、SMTP テスト方法による見かけの失敗なのか、あるいは認証方式の不一致なのかについては、ここで断定はできません。 [1][2][5]


Sources:

  • コメントを投稿するにはログインしてください
DC AI Bot · 5月25日 記事へ

このエラーは、hl7.fhir.r4.examples@4.0.1 パッケージ単体の依存関係から、IRIS が「どの core package に属するか」を特定できないために発生していると読めます。ご提示のエラー文そのものが、Package '... has no dependencies that identify a core package であり、InterSystems の FHIR パッケージ処理では package.json の dependencies に core package 依存関係があることが前提です。[1]

InterSystems でカスタムまたは追加パッケージを取り込む際は、package.json に最低限 name、version、dependencies が必要で、例として R4 なら hl7.fhir.r4.core:"4.0.1" のように core package を依存関係として記述します。[1]

また、パッケージは「依存関係の順に」取り込む必要があり、コミュニティ投稿でも「依存の深いものから順に手動でたどって import する」運用が案内されています。[2]

そのため、今回の hl7.fhir.r4.examples は、そのままでは IRIS が有効な FHIR core 依存を認識できない形式であり、正常な「適用可能パッケージ」として扱えていない可能性が高いです。[1][2]

Package Configuration に存在していても、Server Configuration 側のドロップダウンに出ない件については、エンドポイントに適したパッケージだけが Custom Packages に表示され、たとえば R4 依存パッケージしかない場合は R3/R5 サーバーには表示されない、と説明されています。つまり、取り込み済みであっても、サーバーに適合すると判断されないパッケージは候補に出ません。[1]

[!NOTE]

Adding one or more packages to the set of custom packages that are enabled for an endpoint triggers the system to re-index search tables when you save your changes. [1]

対処として、文書から言える範囲では次の確認が必要です。

  1. hl7.fhir.r4.examples-4.0.1/package/package.json の dependencies に、hl7.fhir.r4.core":"4.0.1" のような core package 依存があるか確認する。[1]
  2. 依存関係にあるパッケージを、依存の深い順に先に import する。[2]
  3. import 後、必要なら HS.FHIRMeta.Storage.Package.GetAllPackages() で実際にロード済みパッケージ ID を確認する。[1]

確認用の一覧取得方法は次です。[1]

set packages = ##class(HS.FHIRMeta.Storage.Package).GetAllPackages()
for i=1:1:packages.Count()
{
  write packages.GetAt(i).id,!
}

import 自体に使う API はご使用の HS.FHIRMeta.Load.NpmLoader.importPackages() で正しいです。[1]

do ##class(HS.FHIRMeta.Load.NpmLoader).importPackages($lb("C:\fhir-packages\node_modules\myorg.fhir.myPackage\"))

なお、コミュニティでは「FHIR registry client により依存解決・ダウンロード・インストールを自動化する機能は将来版予定」とされており、現状は依存関係を手動で確認して順序通りに import する前提です。[2]

結論として、hl7.fhir.r4.examples を hl7.fhir.us.core の前提パッケージとしてそのまま import しようとしても、当該パッケージの dependencies が core package を識別できないため、IRIS では正常なパッケージとして扱えず、ドロップダウンにも出ない、という状況が考えられます。まずは package.json の依存関係定義を確認し、core package を識別できる形かどうかを見てください。[1][2]


Sources:

  • コメントを投稿するにはログインしてください