以下步骤展示如何显示 /api/monitor 服务提供的指标列表示例。

在上个帖子中，我概述了以 Prometheus 格式显示 IRIS 指标的服务。 该贴介绍了如何在容器中设置和运行 IRIS 预览版 2019.4，然后列出了指标。

本帖假定您已安装 Docker。 如果未安装，现在就为您的平台安装吧 :)

步骤 1. 下载并运行 docker 形式的 IRIS 预览版

按照预览发行版的下载说明下载预览版许可证密钥和 IRIS Docker 映像。 例如，我选择了 InterSystems IRIS for Health 2019.4。

按照 Docker 容器中的 InterSystems 产品初见中的说明操作。 如果您熟悉容器，请跳转到标题为“下载 InterSystems IRIS Docker 映像”的部分。

以下终端输出说明了我用来加载 docker 映像的过程。 docker load 命令可能需要几分钟的时间才能运行；

$ pwd
/Users/myhome/Downloads/iris_2019.4

$ ls
InterSystems IRIS for Health (Container)_2019.4.0_Docker(Ubuntu)_12-31-2019.ISCkey  irishealth-2019.4.0.379.0-docker.

请问cahce中所有的数据库访问都是通过cache server完成的吗，比如使用终端访问数据库、studio开发的应用、使用第三方库使用代码都是先访问cache server，然后通过cache server对数据进行存取的吗?使用studio开发的应用程序也是跑在cache server中吗? 如果是的话studio开发的应用程序(比如web程序)如何跟cache server分开部署呢?

按照此网址的指示 https://gettingstarted.intersystems.com/language-quickstarts/java-quick… 下载quickstarts-java示例代码 运行xepplaystocktsTask1模块程序提示InterSystems XEP is not supported by the specified server 请问有人知道具体原因吗我的server有什么不对吗。

使用客户端的server manager添加server没有server类型的选项,是因为我使用的cache版本目前不支持吗

在上一篇文章《互操作消息统一管理系列：Message Bank》中，我们了解到在Message Bank中，消息均以半结构化（XML）或非结构化（Stream）的形式保存，因此无法与客户端的结构化消息一样，直接支持基于索引的检索。为此，需要在Message Bank中定义Search Table以支持查询。关于Search Table的定义和作用，请查阅https://docs.intersystems.com/healthconnectlatest/csp/docbook/DocBook.UI.Page.cls?KEY=EEDI_search_tables。

一. 在Message Bank中查询消息的特殊之处

大家如果使用过消息查看器，则能够了解IRIS自动持久化消息并提供界面让大家能够根据消息头中（如发生事件、来源、目标等）或消息体中（如患者姓名、诊断名称等消息的具体属性）来查询消息。 而在Message Bank上进行查询时，如果直接使用消息查看器，能够查询的是Message Bank的Production中传输的消息，而若不是在源系统中出现的消息，这一点一定不要混淆。

一. 企业信息库简介

企业信息库（MessageBank）是一个可选的远程归档设施，可以从多个来自不同实例的互操作性Production中收集信息、事件日志项目和搜索表项。如下图所示：

这套环境由两种角色的实例构成： 企业信息库服务器，它本身也是一个Production，完全由Message Bank服务组成，接收来自任何数量的客户Production提交的消息、日志等。

客户端Operation（Message Bank Operation），将其添加到一个正在运行的Production中，并用企业信息库服务器的地址进行配置。如连接通畅，消息和日志即可自动转发到Message Bank并在其中存储。

为了使你能方便地看到信息库中的信息，InterSystems IRIS®提供了以下附加选项。

对于企业信息库实例，管理门户自动包括企业监控器页面，在那里你可以监控客户端Production的状态，浏览消息库，并对被监控客户的消息进行检索。

对于每个客户端实例，你在消息库实例中配置一个到企业监控器的链接。

如下所示：

二. 常见应用场景

消息归档

在使用IRIS互操作性时，对于生产环境，为保障其有充足的磁盘空间和即时查询的效率，通常会采用消息和日志过期策略。在生产环境中只保留近期（如一个月）的信息以备回溯，过期数据将定期被清除。

2020 年席卷全球的新冠疫情使每个人都在关注与 COVID-19 有关的新闻和数字。

为什么不趁这个机会去创造一些简单直观的东西，来帮助关注全球的疫苗接种数量呢？

为了应对这一挑战，我使用了 Our World in Data 提供的数据，他们的使命是提供解决全球最大问题所需的研究和数据。

他们在 Github 上有一个专门的 COVID-19 数据仓库，我采用了疫苗接种数据来完善我的跟踪器。

如果你不了解他们，去调查一下吧，这值得你花上一些时间。 Github 仓库

应用程序 iris-vaccine-tracker 有三个不同页面。

1. 主仪表板
2. 数据表，其中包含仪表板中呈现的数据的详细信息。
3. 热图

仪表板

主仪表板提供全球疫苗接种情况的快速概览。

第一个小组件提供以下信息：

• 用于接种人群的疫苗数量
• 提供疫苗接种信息的国家/地区数量
• 迄今已接种的疫苗总数。

第二个小组件提供了一个疫苗接种时间线视图，其中包括疫苗接种数量最多的前 10 个国家/地区。

第三个小组件提供了排名靠前的国家/地区的条形图，显示迄今为止的疫苗接种总数。

最后一个小组件展示疫苗的分布情况，哪些疫苗正在被使用以及所占的百分比。

数据表

数据表显示主仪表板汇总数据的详细信息。

热图

热图是一种不同的视图，它使用我们已经在主仪表板和数据表中使用的信息，但现在使用 Country 持久化表提供的详细信息。

IRIS 中支持的四种方式：

SQL、Objects、REST 和 GraphQL  

卡济米尔·马列维奇，《运动员》(1932) 

>

> “你当然无法理解！ 习惯了坐马车旅行的人怎么可能理解乘坐火车或者飞机旅行的人的感受和印象？”
>

> >

> 卡济米尔·马列维奇 (1916)
>

## 引言

我们已经讨论过为什么在主题领域建模使用对象类型优于使用 SQL。 当时得出的结论和总结的事实如今依然适用。 那么，我们为什么要退后到对象和类型之前的时代，讨论将对象的操作拖回到使用global的技术？ 我们又为什么要鼓励面条式代码？难道是为了用它难以跟踪的错误考验开发者的技能熟练度？ 

目前有几种观点支持通过基于 SQL/REST/GraphQL 的 API 传输数据，而不是将其表示为类型/对象：

• 这些技术经过深入研究，相当易于部署。
• 知名度非常高，已在便捷的开源软件中广泛实现。
• 您通常别无选择，只能使用这些技术，尤其是在网络和数据库中。
• 最重要的是，API 仍然使用对象，因为它们提供了在代码中实现 API 的最适途径。

在讨论实现 API 之前，我们先来看一下底层的抽象层。 下图显示了数据在永久存储位置与处理并向应用程序用户呈现的位置之间的移动方式。

InterSystems API Manager (IAM) 版本1.5已正式发布。

IAM容器，包括从原有IAM版本升级的所有相关工件, 现在可以在 WRC 软件发布网址 组件区下载。

该版本的小版本号是 IAM 1.5.0.9-4。

InterSystems API Manager 1.5 使管理API通讯、与你的环境集成、加载API用户更加容易。它包含很多新特性，包括:

• 改进的用户体验
• 新的开发者门户工具
• 对Kafka connectivity的支持

这个版本基于Kong Enterprise version 1.5.0.9。之前的IAM版本包括一个贴牌版本的Kong Enterprise, 在本版本中的Kong Enterprise不再贴牌。 这个变化让我们可以更快的节奏带给您新的版本，并更有效地利用Kong提供的文档和其它资源。

请在 这里 查看IAM 1.5 的文档。这个文档仅说明IAM特殊的元素。产品中的文档链接直接打开Kong Enterprise的文档。

从IAM 0.34-1 升级需要通过3个中间版本累积升级，在 文档中有详细的说明。

IAM 仅以OCI (Open Container Initiative) 或 Docker 容器格式发放。

大家可能已经听说过，我们近期推出了InterSystems API管理器 (以下简称IAM)。InterSystems IRIS数据平台™新增了一项功能，支持用户监视、控制和管理IT基础架构中基于Web的API间通信。

在本文中，我将向大家展示如何设置IAM，并重点介绍IAM中可用的一些功能。InterSystems API管理器可提供你所需的一切功能。

我们不必等待SAM发布才开始规划和试用该API来监控IRIS实例。在以后的文章中，我将更深入地探讨可用的指标及其意义，并提供一些交互式仪表板的示例。首先，我将介绍一下相关背景和一些问题及答案。

IRIS（和Caché）一直在收集自身及其运行平台的数十个指标。收集这些指标来监控Caché和IRIS的方法向来有很多。我发现，很少有安装软件使用IRIS和Caché的内置解决方案。譬如，History Monitor作为性能和系统使用指标的历史数据库，已经推出很长时间了，但它没有简便方法可实时显示这些指标和仪表系统。

IRIS平台解决方案（以及整个业界）正在从仅在一些本地实例上运行的单体式应用程序过渡到“随处”部署的分布式解决方案。在许多用例中，原有的IRIS监控方案并不适用于这些新的模式。InterSystems没有做重复工作，而是将目光投向当前流行的、经过验证的监控和告警开源解决方案。

在最近的项目里，多方同时连接同一个数据库并执行增删改查等各项数据操作。研发人员不时发现一些数据在不合规的情况下被新增甚至删除。因此，在实际工作中会有监控数据操作以便识别和处理异常操作的需求。本文将以监控和识别删除操作为例，介绍如何通过IRIS的审计功能实现对数据操作的监控和查询。

注意事项

在应用审计功能之前，必须注意的是：

1. 开启审计功能会事无巨细地记录每一条对应的操作（如被执行的SQL），因此对于存储空间的需求将急剧增加。举例而言，仅开启对XDBCStatement的监控后，对于一张只由5个简单（整型，VARCHAR型）字段构成的表中插入100万条记录，在Audit数据库中将占用300～400MB的空间。在因业务所需确实需要开启审计功能时，必须预先分配更多磁盘空间给IRIS Audit数据库，并在审计功能开启期间定时巡检磁盘空间，避免因日志占满磁盘导致其他数据无法写入引发系统挂起的故障。
2. 在研发环境中多人、多单位需要连接数据库时，应为不同的开发者和数据来源分配独立的数据库账户和权限，避免多人共用超级账户，导致数据异常时难以追踪异常操作究竟从何而来。也就意味着为不同角色的开发、测试、用户等参与者开启独立的用户，分配各自所需的的数据库权限以及管理数据库账户这样一系列项目正常运行所依赖的实践并不能被审计功能所替代。

在这个由三个部分组成的系列文章中，介绍了如何在OAuth 2.0标准下使用IAM简单地为IRIS中的未经验证的服务添加安全性。 

第一部分介绍了一些OAuth 2.0背景知识，以及IRIS和IAM的一些初始定义和配置，以帮助读者理解确保服务安全的整个过程。 

第二部分详细讨论和演示了配置IAM所需的步骤——验证传入请求中的访问令牌，并在验证成功时将请求转发到后端。 

本系列的最后一部分将讨论和演示IAM生成访问令牌（充当授权服务器）并对其进行验证时所需的配置，以及一些重要的最终考虑事项。 

如果您想试用IAM，请联系InterSystems销售代表。 

场景2：IAM作为授权服务器和访问令牌验证器  

与上个场景不同的是，该场景中将使用一个名为“OAuth 2.0 Authentication”的插件。 

如果要在资源所有者密码凭证流中将IAM作为授权服务器使用，客户端应用程序必须对用户名和密码进行身份验证。只有在身份验证成功时，才能发出获取IAM访问令牌的请求。 

首先，将其添加到“SampleIRISService”中。正如下面截屏所示，需要填充一些不同的字段来配置此插件。 

首先，将“SampleIRISService”的ID粘贴到“service_id”字段中，这样就可以在服务中启用该插件。 

在“config.auth_header_name”字段中，需要指定携带授权令牌的头名称。

在这个由三部分组成的系列文章中，我们将展示如何在OAuth 2.0标准下使用IAM简单地为IRIS中的未经验证的服务添加安全性。 

在第一部分中，我们介绍了一些OAuth 2.0背景知识，以及IRIS和IAM的初始定义和配置，以帮助读者理解确保服务安全的整个过程。 

现在，本文将详细讨论和演示配置IAM所需的步骤——验证传入请求中的访问令牌，并在验证成功时将请求转发到后端。 

本系列的最后一部分将讨论和演示IAM生成访问令牌（充当授权服务器）并对其进行验证时所需的配置，以及一些重要的最终考虑事项。 

如果您想试用IAM，请联系InterSystems销售代表。

场景1：IAM作为访问令牌验证器  

在该场景中，需要使用一个外部授权服务器生成JWT（JSON Web Token）格式的访问令牌。该JWT使用了RS256算法和私钥签名。为了验证JWT签名，另一方（本例中是IAM）需要拥有授权服务器提供的公钥。 

由外部授权服务器生成的JWT主体中还包括一个名为“exp”的声明（包含该令牌过期的时间戳），以及另一个名为“iss”的声明（包含授权服务器的地址）。 

因此，IAM需要先使用授权服务器的公钥和JWT内部“exp”声明中包含的过期时间戳对JWT签名进行验证，然后再将请求转发给IRIS。 

对IAM进行相应配置时，首先要向IAM中的“SampleIRISService”添加一个名为“JWT”的插件。

介绍 

目前，诸多应用程序通过开放授权框架（OAuth）来安全、可靠、高效地访问各种服务中的资源。InterSystems IRIS目前已兼容OAuth 2.0框架。事实上社区有一篇关于OAuth 2.0和InterSystems IRIS的精彩文章，链接如下。 

然而，随着API管理工具的出现，一些组织开始将其用作单点身份验证，从而防止未经授权的请求到达下游服务，并将授权/身份验证复杂性从服务本身分离出来。 

您可能知道，InterSystems已经推出了自己的API管理工具，即InterSystems API Management （IAM），以IRIS Enterprise license（IRIS Community版本不含此功能）的形式提供。这里是社区另一篇介绍InterSystems AIM的精华帖。 

这是三篇系列文章中的第一篇，该系列文章将展示如何在OAuth 2.0标准下使用IAM简单地为IRIS中的未经验证的服务添加安全性。 

第一部分将介绍OAuth 2.0相关背景，以及IRIS和IAM的初始定义和配置，以帮助读者理解确保服务安全的整个过程。 

本系列文章的后续部分还将介绍两种使用IAM保护服务的可能的场景。在第一种场景中，IAM只验证传入请求中的访问令牌，如果验证成功，则将请求转发到后端。在第二种场景中，IAM将生成一个访问令牌（充当授权服务器）并对其进行验证。

在本文中，我想谈一谈规范优先的 REST API 开发方式。

传统的代码优先 REST API 开发是这样的：

• 编写代码
• 使其支持 REST
• 形成文档（成为 REST API）

规范优先遵循同样的步骤，不过是反过来的。 我们先制定规范（同时兼做文档），然后根据它生成一个样板 REST 应用，最后编写一些业务逻辑。

这是有好处的，因为：

• 对于想要使用你的 REST API 的外部或前端开发者，你总是有相关且有用的文档
• 使用 OAS (Swagger) 创建的规范可以导入各种工具，从而进行编辑、客户端生成、API 管理、单元测试和自动化，或者许多其他任务的简化
• 改进了 API 架构。 在代码优先的方式中，API 是逐个方法开发的，因此开发者很容易失去对整体 API 架构的跟踪，但在规范优先的方式中，开发者被强制从 API 使用者的角度与 API 进行交互，这通常有助于设计出更简洁的 API 架构
• 更快的开发速度 - 由于所有样板代码都是自动生成的，你无需编写代码，只需开发业务逻辑。
• 更快的反馈循环 - 使用者可以立即查看 API，并且只需修改规范即可轻松提供建议 让我们以规范优先的方式开发 API 吧！

最近，我需要从持久类和序列类生成一个 Swagger 规范，所以我发布了我的代码（它并不完整 - 你仍然需要处理应用程序的细节，但这是一个开始）。 代码在这里。

假设你有下面的类：

Class REST.Test.Person Extends %Persistent
{
/// 人的名字。
Property Name As %String [ Required ];
/// 人的社会安全号。 这通过模式匹配进行验证。
Property SSN As %String [ Required ];
/// 人的出生日期。
Property DOB As %Date;
/// 人的家庭地址。 这里使用一个嵌入对象。
Property Home As Address;
/// 人的办公室地址。 这里使用一个嵌入对象。
Property Office As Address;
/// 人的配偶。 这是对另一个持久对象的引用。
Property Spouse As Person;
/// 代表人喜欢的颜色的字符串集合。
Property FavoriteColors As list Of %String;
/// 代表人喜欢的颜色的字符串集合。