本文介绍如何在 InterSystems IRIS 中通过继承 EnsLib.HTTP.GenericOperation（或 EnsLib.REST.GenericOperation）实现 OAuth2.0 支持，包括 OAuth2.0 Client 配置、Access Token 自动获取与 Header 注入，适用于各类第三方 REST API 集成场景。

在企业集成项目中，我们经常需要通过 REST API 对接第三方平台，例如 CRM、支付系统、云服务和 Open API 网关。

这些接口大多数采用 OAuth 2.0 作为授权机制。

虽然 InterSystems IRIS 提供了功能强大的通用 HTTP / REST 业务操作类：

• EnsLib.HTTP.GenericOperation
• EnsLib.REST.GenericOperation

但目前它们不直接支持 OAuth2.0 Access Token 自动注入。

本文将介绍一种常见且推荐的实现方式：

通过继承 GenericOperation类，自定义一个支持 OAuth2.0 的通用业务操作类（Business Operation）

实现以下能力：

• 自动检查令牌(Token)是否有效
• 自动获访问令牌(Access Token)
• 自动注入授权头(Authorization Header)
• 对业务调用透明

一、先理解 OAuth2.

什么是 FHIR Profile?？

FHIRProfile是规则和约束的集合，用于定制和完善基础快速医疗互操作性资源 (FHIR) 资源（resource）。Profiling是一个重要的过程，它可以调整基础 FHIR 资源标准，以满足特定用例、地理区域、医疗机构或临床工作流程的独特要求。

基础 FHIR 规范为资源（如病人、观察或药物）提供了通用、灵活的定义，而Profiling则将这些通用资源转化为更精确的资源。这就确保了为特定社区或实施量身定制的数据交换的一致性和互操作性。

FHIR 旨在覆盖全球各种医疗保健场景。配置文件允许实施者在不丧失标准化优势的情况下调整这一通用平台。

Embeddedpy-bridge：嵌入式 Python 工具包

概述

嵌入式 Python改变了 InterSystems IRIS 的游戏规则，可直接在数据库中访问庞大的 Python 生态系统。但是，在 ObjectScript 和 Python 之间架起桥梁有时会让人感觉像是在两个不同的世界之间转换。

为了实现这种无缝过渡，请使用embeddedpy-bridge。

该软件包是一个以开发人员为中心的实用工具包，旨在为嵌入式 Python 提供高级 ObjectScript 封装、熟悉的语法和强大的错误处理功能。它允许开发人员使用他们已经熟悉的本地 IRIS 模式与 Python 数据结构交互。

挑战

虽然 %SYS.Python 库功能强大，但开发人员经常面临一些障碍：

1. 处理代理：使用原始代理浏览 Python 列表和字典对于 ObjectScript 来说并不 "原生"。
2. 迭代：标准 ObjectScript While 循环无法与 Python 迭代器进行本地 "对话"。
3. 命名空间管理：确保 Python 实用程序在整个系统中可用。

解决方案：embeddedpy-bridge

我的目标是创建一个 "桥梁"，让 Python 感觉像是 ObjectScript 中的一等公民。

主要功能

• py 前缀约定：%ZPython.Utils

InterSystems IRIS 的架构将数据的逻辑组织（命名空间）与其物理存储位置（数据库）分开。理解这种分离以及命名空间和数据库之间的区别对于有效的数据管理、安全性，尤其是高性能数据共享至关重要。

在本文中，我将讨论这些基础组件，并提供利用全局映射跨不同逻辑环境共享本地数据结构（全局）的实用指南。

数据库：物理现实

数据库代表了数据存储在磁盘上的物理现实。首先，它是文件系统中名为 IRIS.dat 的文件（例如，<安装文件夹>\mgr\user\IRIS.DAT ）。该文件的最大容量为 32TB。它是所有实际数据和代码的容器。数据库由 IRIS 内核管理，它在物理文件级别处理缓存、日志和事务日志。

安装 InterSystems IRIS DBMS 时，会自动安装以下数据库：

有时，根据预先定义的资源 "列表（List）"限制 FHIR 搜索会更方便、更高效、更安全。

自 2025.1 版起，我们的 FHIR 服务器支持多个与列表相关的功能。

我将在此重点介绍这些功能，并提供一些示例。

在使用InterSystems 互操作性（Iris/Health Connect/Ensemble）时，配置数据通常分散在许多生产项目中：服务、流程、操作、适配器及其设置。

常见的操作或安全需求是回答以下问题：

• 哪些接口引用了文件系统路径？
• 目录、网络共享或绝对路径配置在哪里？
• 我能否在所有产品中快速审核或记录这些信息？

下面的 ObjectScript 工具正是通过将选定的配置设置导出到 CSV 文件来解决这个问题的。

该脚本

1. 循环浏览所有现有命名空间
2. 查询所有命名空间中的所有互操作性配置项(Ens_Config.Item)
3. 遍历每个项目的设置
4. 提取文件系统/URL 路径（包含 :、/ 或 \ 的值）
5. 将结果写入CSV 文件，按类别分组
6. 生成便于审计的输出，可在 Excel 中打开或与操作/安全团队共享

典型用例

当您需要时，应使用此实用程序：

• 🔍审计整个产品的文件系统使用情况
• 🛡审查安全风险（本地路径、网络共享、数据库连接）
• 📄记录迁移、升级或灾难恢复规划的配置
• 🔄比较环境（开发环境vs测试环境vs 生产环境）
• 🧹清理遗留或未使用的路径

这对使用许多接口和适配器的多个产品的大型实例尤其有用。

此外，在以前的版本中，您可以定义您的 FHIR 服务器接受通过 OAuth 2.0 发送的请求（例如，用于 FHIR 客户端上的 SMART），但在前不久发布的 v2024.3 中，有一项新功能可以更轻松地实现这一点，即OAuth FHIR 客户端快速启动（OAuth FHIR Client QuickStart）。

您发送了一个 HTTP 请求，但得到了一个 HTTP 错误，而且是一个您意想不到的 HTML 错误页面......这是怎么回事？

具体举例来说，也许您尝试读取 FHIR 资源（例如 /Patient/123），但得到的是 404 错误页面，尽管使用其他患者 ID 时，您得到的是资源有效载荷，因此 "页面 "肯定存在......为什么会得到 404 错误页面？

什么是 XML？

XML（可扩展标记语言）是一种灵活的、基于文本的、独立于平台的格式，用于以结构合理 、人机可读的方式存储和传输数据 。XML 允许用户定义自定义标签来描述数据的含义和组织结构。例如：<book><title>The Hitchhiker's Guide</title></book>.

XML 文档具有自描述性，其结构是一棵分层的元素树。每个文档都有一个封装所有其他内容的根元素。元素可以包含文本、子元素和属性（提供补充信息的名-值对）。这些文档通常用 .xml 文件存储

这种结构的完整性可以通过以下方式实现：

• DTD（文档类型定义）：提供基本的验证规则。
• XSD（XML 模式定义）：提供高级规则，包括数据类型和约束。

转换 XML 文档

这部分内容介绍如下：

1. 解析一般 XML 并将其转换为 HL7 标准。
2. 解析 CCDA（综合临床文档架构）文档（XML）并将其转换为 HL7 格式。

在这些实施过程中，两种格式都会首先转换为 InterSystems IRIS SDA（标准化数据架构）格式。这被认为是一种标准、高效、不易出错的方法，因为它有效地利用了平台的 预置类。数据采用 SDA 格式后，可无缝转换为任何目标标准，如 HL7 v2、 FHIR 或 CCDA。

互操作性用户界面现在包括可以在所有互操作性产品中使用的 DTL 编辑器和生产配置应用程序的现代化用户体验。您可以在现代化视图与标准视图之间切换。所有其他互操作性屏幕仍采用标准用户界面。请注意，仅对这两个应用程序进行了更改，我们在下面确定了当前可用的功能。

要在升级前试用新屏幕，您可以点击这里，从我们的社区工具包网页中下载 2025.1 版：https://evaluation.intersystems.com/Eval/。请观看“学习服务”中的简短教程构建集成：一种新的用户体验，了解对这些屏幕进行的用户增强！

生产配置 - 配置任务简介

• 生产配置：在以下版本的生产配置中受支持：

  • 创建/编辑/复制/删除主机
  • 停止/启动主机
  • 编辑生产设置
  • 停止/启动生产

• 源代码控制集成：支持上述配置功能的源代码控制集成。

• 分屏视图：用户可以直接从“生产配置”屏幕打开“规则编辑器”和“DTL 编辑器”，在分屏视图中查看和编辑产品中包含的规则和转换。

• 增强的筛选功能：使用顶部的搜索框，您可以搜索和筛选各种业务组件，包括多种类别、DTL 和子转换。 使用左侧边栏可以独立于主面板进行搜索，查看各种主机和类别中的搜索结果。

• 批量编辑主机类别：通过从生产配置中添加主机，您可以为生产添加新类别或编辑现有类别。

• 可展开路由器：可以展开路由器，内联查看所有规则、转换和连接。

出于实际原因，可能需要在 Linux 服务器重启后自动启动 IRIS 实例。

下面是在 Linux 服务器重启时通过 systemd 自动启动 IRIS 的步骤：

1. 在 /etc/systemd/system/iris.service 中创建一个 iris.service 文件，其中包含以下信息

[Unit]
Description=InterSystems IRIS Data Platform
After=network.target

[Service]
Type=forking
Useruser

注意：User应该填入IRIS实例的所有者。

2. 重新加载 systemd 配置管理器

sudo systemctl daemon-reload

3. 启用IRIS服务，使其自动启动

sudo systemctl 

激活后将创建软链接，自动启动 IRIS：

4. 试着重启服务器

5. 查看IRIS实例是否自动启动

开发新的互操作性Production时，最初在Production中添加设置是很自然的做法。

不过，一旦要将Production从开发环境移动到测试或其他环境，你就会发现 HTTP 服务器、IP 地址和/或端口之类的设置都需要更改。 为了避免这些设置在后续重新部署时被覆盖，必须将这些设置从Production得设置中移动到系统默认设置(System Default Settings)。

虽然系统默认设置可以手动创建，但是当生产中有大量业务组件时会难以处理。 因此，@Wietze Drost 让我开发一个工具自动执行此流程，通过筛选表达式指定哪些设置必须创建为系统默认设置。

• 这个表达式可以定义为“*:HTTPServer,SSLConfig*”，其中“\*”表示“为任何主机类名”。 冒号后面是需要移动的设置列表。 所以，这个表达式的意思是“为所有名为 HTTPServer 和 SSLConfig 的设置创建或更新系统默认设置”。