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

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

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

发现官网上的native api for java教程无内容. 是不是后端出问题了​​​​​​

我想安装Windows版本的管理门户引擎来创建Cache InterSystems数据库
我想为Cache InterSystems创建一个样本数据库，并想通过Cache Entity Framework Provider访问它。但是，我无法找到一个特定的管理门户引擎来创建数据库。

你能指导一下如何在Windows中安装管理门户吗？

I want to install Management Portal Engine for Windows to create Cache InterSystems DB

I want to create a Sample Database for Cache InterSystems and want to access it via Cache Entity Framework Provider. But, I cannot find a particular engine of Management Portal to create a database.

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

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

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

假设你有下面的类：

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

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

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

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

这是有好处的，因为：

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

介绍

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

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

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

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

这些API虽然在IRIS 2020.1中已经实现了，但没有被放在官方文档里。

这都是直接从Class Reference中提取的，我只是收集了它来创建第一个概述。

ObjectScript的本地API遵循其他语言平台上使用的API。它从一个静态API开始，允许用户使用Iris Connection连接到IRIS命名空间，无论是本地还是远程。连接接口允许用户实例化IRIS本地API类（%Net.DB.Iris）。然后，该实例可用于访问IRIS全局数组，管理事务，调用例程或类中实现的函数和方法，以及实例化远程迭代器。

这是一个IRIS 2020.2上的代码示例，并非InterSystems 官方支持！

本demo基于原始类描述 is based on the raw class descriptions.
使用的数据类是Address, Person, Employee, Company
如果要做更有吸引力的 demo, 可以添加 JSONtoString by ID的方法

用ZPM安装后从终端启动：After installation with ZPM just run from Terminal

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

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

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

IRIS 中支持的四种方式：

SQL、Objects、REST 和 GraphQL

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

>

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

> >

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

## 引言

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

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

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

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