前言

在日常工作中经常会遇到大量的接口开发需求，对于没有IRIS开发经验的同事来说很不友好，需要求助于公司开发人员来做接口开发，对项目联调进度多少会有些影响，本文站在没有IRIS开发经验的工作人员角度来阐述一下如何利用xslt转换文件自动生成接口联调所需要的Message模型。

基本思路是首先定义一套通用的数据模型，用来接收定义消息所需要的基础属性，包括类名，请求&响应（对应继承Ens.Request&Ens.Response），节点名称、节点长度、是否必填、默认值、字段约束等等。

iris 是数据平台，更是一种数据库。对于熟悉SQL语句的人来说，会认为“既然是数据库，数据应该就能使用sql语句来查询”。这是对的，但是因为有global这个概念，保存的数据可能在global里面，而没有对应的表，也可能保存在类的参数定义里面。这些数据，不能使用sql直接查询。要查询iris数据库的数据，通常有几种方式：1.直接查询表的数据。2.查询视图。3.调用存储过程(call 命令)。其中要查询“只存于global里面或者类参数里定义的数据”，只有使用存储过程。但是存储过程有个问题，就是程序如果迁移到低版本的cache数据库后，数据类型的定义会有问题，且不再支持使用select的方式，只能使用call。这对于第三方熟悉sql的人员来说很不友好。因此结合global和表的关系，介绍一种我称为“进程表”的表。进程表，指数据只存于该进程中，global的样式为"^||global名“。通常按照默认存储新加一个持久类(对应会生成一个表)，然后手动的把global改成进程global，也就是加上”||“。然后写个方法，把需要查询出来的数据写入进程global。这样就能查询出来 了。调用形式为 SELECT * FROM People WHERE People_GLB()=1。

示例如下：

关注FHIR的大侠们估计都注意到了，FHIR更新了它支持的互操作范式，除了消息、文档、服务、API这4种，增加了2个：资源仓库、订阅。前面4个好理解，为什么资源仓库和订阅会成为FHIR的新的互操作范式？互操作与应用集成是什么关系？

这里借FHIR的新互操作范式，聊聊应用集成，看看集成平台是什么？有什么样的集成方案？以及怎么评价不同的方案。

Cache锁的异常直接影响数据库进程运行，堆积的锁如果处理不及时会造成Cache性能异常，导致数据库访问受限或严重卡顿。本文主要以实例分析介绍Cache中常见锁的作用及其对应的处理方式，包括：系统锁、数据锁、Session锁、仪器锁、程序文件锁。其中数据锁异常需要及时处理。

一般情况下，我们根据iris的portal向导创建数据库，然后创建命名空间。这个过程比较花时间，如果是已经存在的数据库，还需要再装载。翻阅portal调用的方法后，我整合了这几个方法。把这几个方法拷贝到任意已经存在的命名空间，通过执行CNNS（路径，命名空间），就可以快速创建好命名空间。方法的大概过程是，进入到%sys命名空间，然后依次创建数据库，创建命名空间，创建web应用。创建完成后，回到当前命名空间。

在使用xDBC连接到字符集为US7ASCII的Oracle数据库时，大家可能遇到过中文的乱码问题，尤其是使用Oracle自己的xDBC驱动的时候。

字符集为US7ASCII的Oracle数据库虽然可以保存中文数据，但给客户端带来了很多麻烦，需要对获取和提交的数据进行转码。

在Ensemble/Health Connect/InterSystems IRIS 中使用SQL适配器连接到这样的Oracle数据库时，可以使用$ZCVT函数进行转码。

1. $ZCVT函数

$ZCVT函数是广泛使用的字符串转换函数，可以做大小写转换、编码转换、URL 和 URI 转换等。我们用其编码转换能力来解决字符集转码问题。

2. 获取的SQL结果集数据有中文时

今天从官网下载了IRISHealth-2023.1.0.229.0-lnxrh9x64版本的数据库安装包，在RHEL9.0上进行安装配置测试，遇到一个问题，趁热记录下来。

测试环境及软件版本：

操作系统——Red Hat Enterprise Linux release 9.0 (Plow)

数据库——IRISHealth-2023.1.0.229.0-lnxrh9x64

测试创建镜像时，配置好虚拟IP，点击保存。

保存后发现数据库没有变成主成员状态，一直是等待的状态，如下图所示：

1 磁盘空间不足的常见情形
1）Journal所在磁盘空间不足。造成这种情况的原因有多种，比如，Mirror中备机未处于宕机状态，因此主机保留了Journal文件。
2）数据库所在磁盘空间不足。比如，集成平台上Ensemble/Health Connect/IRIS for Health的消息从未清除过，导致消息数据库DAT文件不断增大，直至将磁盘空间用尽。

我们可以看到以上两种情形下，Mirror都帮不上忙，也就是说一旦问题出现，主机和备机都没有办法立即承担起业务系统的运行，
第1)种，备机可能在故障出现前就已经宕机很长一段时间而没被发现，备机的数据很可能已经与主机严重不一致。实际上，主机之所以保留了大量的journal文件没有删除，就是为了让备机同步数据时使用。
第2)种，虽然配置了Mirror，但是消息主库正常情况下都是镜像库，在一个健康的Mirror中，备机和主机的镜像库数据保持同步，镜像库大小应当是相同的，假设主备机的硬件配置相同（这也是我们推荐的方式）那么磁盘空间不足在备机上同样存在。

嗨，开发者们！

秋高气爽之际，我们很高兴地宣布启动🏆InterSystems开发者社区中文版首届技术征文大赛 🏆（←点击链接进入参赛页面，浏览所有参赛文章）！

从2022年9月5日-10月24日（北京时间），欢迎热爱InterSystems技术的你来投稿，撰写与InterSystems技术相关的文章。

🎁参与奖 我们为每一位成功参赛的作者准备了礼品！

🏆优秀文章大奖 Apple iPad; Beats Fit Pro; HUAWEI WATCH; Logitech键盘; WD固态硬盘；KEEP智能手环

各大技术社区常年充斥着关于字符集支持、乱码的问题。Cache’/Ensemble/HealthConnect/IRIS的用户也经常遇到这类问题。为何文字乱码在信息化发展这么久后还会困扰我们？因为字符集、多语言实在有点复杂。

我计划写三篇：第一篇花点时间回顾一下多语言字符集的简史，第二篇介绍一下各种技术对于字符集和字符编码的使用声明，最后一篇会介绍常见的ISC技术和工具的乱码、尤其是中文乱码的现象和解决办法。

如果您正打算学习FHIR、或者正在基于FHIR开发，最佳的学习和开发环境需要一个完备的FHIR 服务器，帮助您理解FHIR标准和调试FHIR应用。使用InterSystems IRIS医疗行业版可以快速配置出FHIR服务器和FHIR资源仓库。这篇文章介绍如何在5分钟内在InterSystems IRIS医疗行业版上配置FHIR服务器和FHIR资源仓库；同时对初学者介绍FHIR测试数据生成与加载的方法，和基本的FHIR REST API操作。

软件准备

1. InterSystems IRIS医疗行业版

您可以使用已有的2020.1及以上的InterSystems IRIS医疗行业版。如果您还没有，那么就在社区里下载一个最新的、免费的社区版吧。

数据平台一直在进化：从数据中心到数据中台，离散的数据资产得到进一步梳理和整合、按业务封装数据和操作数据的方法，并逐步提供了企业统一的访问、更新、检索、查询等数据服务。

然而市场上不乏听到数据平台的成功案例，却鲜见这些案例得到大规模推广。原因是什么呢？

一. 传统数据平台建设的挑战

传统数据平台的数据模型基于各自厂商的理解，缺乏统一行业数据模型和行业语义。可供参考的国内卫生信息数据元、数据集标准并非完整的行业语义，例如没有业务实体模型和数据元关系定义。传统的数据平台建设通常根据业务域，围绕数据应用需求组织数据。经常看到按业务域划分为CDR（临床数据中心）、ODR（运营数据中心）、RDR（科研数据中心）......

这造成了几个挑战：

1. 按业务域、而非业务实体来划分数据，虽然方便相应的业务域数据分析，但跨业务域重叠的业务实体数据，例如患者，需要跨数据中心同步。这些同步由于数据模型上的差异，往往非全息拷贝。随着同步次数越多，跨数据中心的数据越失真，造成数据资产多源不统一、数据资产一致性问题和时效性问题。

2. 数据平台产品语义表达上参差不齐，业务用户依赖数据工程师对数据理解和操作，无论是统计分析还是机器学习，海量的实施工作无法满足业务敏捷性要求；

上一篇：
IRIS中的权限管理

在上一篇文章中，我们介绍了IRIS中的权限控制体系。在本文中我们将以一个常见的实施需求为例介绍如何使用IRIS的权限配置出一个只能使用SQL的用户。

需求的分解

和所有用户需求一样，当用户提出一个需求时，除其语义显式的含义之外，还需分析其是否具有没有明确说明的含义。
对于一个只能使用SQL的用户这样一个需求，即应当结合平台的特征分解成为功能需求：
具有一个合法，可通过用户名和密码使用IRIS的用户
该用户的数据库权限
- 确认项：可以使用SQL访问所有数据库还是某几个特定的数据库？
该用户的SQL权限
- 确认项：对于特定的数据库，是否可以执行所有的DDL？
- 确认项：对于特定的数据库，是否对每一张表都可以执行Select、Update等所有的DML
该用户的程序权限
- 确认项：用户是否可以通过Portal登录并管理IRIS？

技术支持团队在不同的项目中发现了类似中间人攻击的情况， 和各位分享一下。

我们的系统一般是安装在内网里，没有恶意的中间人攻击的风险。但是在有些医院发现了这样的情况：IT在网络中安装了某种网络监控或者嗅探的设备， 它会在通信通道中模拟其中一方，或者双方的通信节点， 以截获通信双方的网络流量。通常它不影响双方的通信，但偶尔，它会中断双方的连接， 造成业务的中断。实质上这也是一种中间人攻击的情况，只不过这是用户允许的行为，偶然出现了故障。

我们看看以下的例子:

以下的wireshark抓包截图中， 172.18.1.131和172.18.1.145在正常的通信过程中， 忽然收到了RST消息，造成了TCP连接上的复位。