JDBC 兼容性状态 **这是一篇 [InterSystems 常见问题解答网站](https://faq.intersystems.co.jp/)文章。

版本 2009.1 及更高版本与 JDBC 4.0 API 兼容。 有关详细信息，请查阅以下文档。 [关于 JDBC 支持](First Look: JDBC and InterSystems Databases - InterSystems IRIS Data Platform 2020.3
)

InterSystems 是一家已经深耕数据库平台领域达44年的公司，成立于1978年，现在已经在全球的80多个国家开展相关业务，每天有超过10亿患者的电子病历数据都跑在以我们的数据库平台构建的应用系统之上。

您可能已经听说，我们目前正在为所有正在使用 Caché 和 Ensemble 的客户提供限时免费迁移到我们的下一代数据平台 InterSystems IRIS 的机会。

虽然我们依旧如往常一样全力支持那些正在使用 Caché 数据库和 Ensemble 集成引擎的客户，但我们还是认为 InterSystems IRIS 是未来的关键。它结合了 Caché 和 Ensemble 的所有功能，并添加了大量令人兴奋的强大功能，从机器学习到原生 Python。

这也正是我们为现有客户提供迁移到 InterSystems IRIS 并使用这些新功能的原因。 我们也通过就地迁移支持轻松迁移，这意味着无需数据库转换、分步迁移指南、教程等。

听起来挺有趣对吗？ 以下是我针对当前 Caché 和 Ensemble 应迁移到 InterSystems IRIS 的五个主要原因。

REF: https://docs.intersystems.com/healthconnectlatest/csp/docbook/Doc.View.c...

REF: https://docs.intersystems.com/healthconnectlatest/csp/docbook/DocBook.UI...

开发REST服务有两个方式， 一个是生生的写代码， 定义接口的标准，被称为"Manually Coding"。第2个方式是目前越来越流行的"Sepcification-first"，也就是使用描述性的语言定义接口规范，然后通过这个规范生成接口代码。第2种方式更快捷，但这里我还是从第一种介绍起，对理解里面的代码层次更容易一些，而这是调试一个接口必须的。

从代码开发REST服务

最近一些用户问到监控集成平台业务行为查询的问题，例如如何查询服务的平均耗时、发生错误的服务数量...

业务行为监控对于集成平台来说非常重要，可以帮助我们：

• 监控系统健康情况 — 查看系统性能表现。例如发现队列积压和长耗时的消息处理，都可能是性能问题的表现。
• 排查异常 — 通过查看业务行为数据，帮助我们判断特定的业务组件配置是否是造成性能瓶颈的主要原因。
• 做业务规划 — 通过业务行为数据，了解各个业务量变化情况，并辅助我们做业务规划。
• 做硬件规划 — 通过长期跟踪消息吞吐量的变化了解性能的变化和业务量的增长，进而辅助我们做硬件计划，避免出现在性能问题。

仅提供这些查询是很容易的，但要更好地监控集成平台的业务行为，需要更深入的了解InterSystems集成架构。

Object Script(四)

我想与您分享一些在 Caché 中同样存在但几乎不为人知且大多未使用的存储功能。 它们当然可以在 IRIS 中使用，并且在大型分布式存储架构中变得越来越重要。

日常工作中，JSON使用越来越多，很多其他的语言里面有成熟的JSON API,但cache 我一直没找到。而同事们使用的基本都是自己写的一些JSON工具。这些小工具，多多少少有些局限。使用ensemble2016后，发现了 Ens.Util.JSON类，他可以处理JSON。翻阅代码后，实际上主要API是 %ZEN.Auxiliary.abstractController。在使用中，我们遇到一个问题，那就是有些JSON的节点名是带有下划线的，这个不太好处理。一般来说，我们把对象转为xml的时候，对象的属性我们是去掉下划线的，带下划线的名字是用 XMLNAME来设置的，于是考虑JSON里面也使用它（如果配置了）作为对象转JSON的时候，JSON的名字。

在本文中，我们将讨论孤立消息。

什么是孤立消息

每个消息正文都与一个保存元数据的消息标头相关联。 标头保存源配置名称、目标配置名称、创建时间、处理时间、关联的消息正文引用、会话信息、消息正文类名、消息状态等信息。 当有消息正文记录没有相应的标头记录时，这些消息正文称为孤立消息正文。 我们将讨论可能导致孤立消息正文产生的原因。

仅清除标头

在清除任务设置中，BodiesToo 设置用于指定是否将消息正文与消息标头一起清除。 如果关闭此设置，清除任务将只删除消息标头，而保留消息正文。 这些消息正文将成为孤立记录，因为所引用的标头已被删除。 如果清除消息标头但保留消息正文，则管理门户将无法清除孤立消息正文。 在这种情况下，必须以编程方式清除消息正文。

请参阅有关清除任务的文档

Production是开发者基于InterSystems IRIS产品家族实现互操作功能的主要技术架构。而每个Production的运行依赖于三类主要的业务组件：

“池大小”（PoolSize）设置的值决定了一个组件的作业的量和启动方式。在这篇文章中我们将具体讨论对于不同类型的组件来说“池大小”设置的可能值和这些值所代表的含义。

Pool Size = 1

对于所有的组件来说，运行池大小为1的含义都是一样的: 该组件有且只有一个作业，单独运行该组件的代码，顺序处理发送到该组件的消息（FIFO）。

Pool Size > 1

对于业务进程（BP）和业务操作（BO）来说，当运行池大小大于1时，该组件将运行多个作业（作业数=运行池大小设置数）。每个作业都只运行该组件的代码，但消息处理的顺序将被打乱。将运行池的大小设为大于1的值可以在一定程度上提升组件处理消息的性能，但是每个作业的性能还是受限于系统资源的，所以并不是说组件的性能可以随着运行池的大小增加而无限提升。

对于轮询类业务服务（Polling BS）来说，当运行池大小大于1时，该服务也将运行多个作业（作业数=运行池大小设置数）。但这种配置会导致多个进程对轮询结果产生竞争（race condition），所以一般情况下轮询服务不应将运行池大小设为大于1的数值。

消息查看器可以重新发送消息，但不适合重新发送大量消息（>100）。为此，您应该使用如下的Object Script代码：

在生产环境中IRIS通常以故障转移集群的形态被部署，而集群中各故障转移成员的镜像状态将决定该集群在故障发生时是否能够顺利切换保障业务不中断。因此，成员状态通常也是运维团队需要巡检或监控的目标。

尽管IRIS内部API提供了丰富的集群配置、成员状态监控等一系列接口，但除Portal上的镜像监视器外，并没有特定的接口便于从外部系统访问（如进行企业级监控集成时），也没有整合好的监控接口可用与获取镜像的健康状态。但在IRIS上开发一个REST接口暴露镜像状态数据并不困难，如下所示：

这篇文章是前面文章[首次使用InterSystems IRIS] 互操作性: 它是如何工作的？