这张图解释了您的私服是怎么工作的， 整篇文章在这里： Proxy-Registry
您需要有一台自己的的服务器， 在上面安装IRIS, zpm, 然后用zpm去下载另一个软件包“zpm-registry"。象这样
zpm:DEMO>search -r zpm-registry
registry https://pm.community.intersystems.com:
zpm-registry 1.1.11Repository: https://github.com/intersystems-community/zpm-registry/
zpm:DEMO>install zpm-registry
[DEMO|zpm-registry] Reload START (/usr/irissys/mgr/.modules/DEMO/zpm-registry/1.1.11/)
[DEMO|zpm-registry] Reload SUCCESS
[zpm-registry] Module object refreshed.安装InterSystems IRIS数据库的ODBC驱动，在Windows系统中配置数据源后，可以使用Microsoft Visual Studio 开发工具 中的服务器资源管理器很方便地连接到InterSystems IRIS数据库服务器，利用数据库连接的可视化视图，可以非常方便快捷地进行连接到InterSystems IRIS数据库的应用开发。本文将展示一个利用以上方式实现的例子，开发工具为Microsoft Visual Studio 2019，开发语言为C#，10分钟快速开发实现一个连接到InterSystems IRIS数据库的C#应用，在本例子中，可以通过选择日期和科室，查询指定日期和科室的就诊日志。
1、在成功安装InterSystems IRIS数据库的ODBC驱动后，从Windows的“控制面板”中选择“管理工具”，在“管理工具”中选择“ODBC数据源”。
2、在ODBC数据源管理的“用户DSN”标签下，选择“添加”，在随后弹出的“创建新数据源”窗口中选择“InterSystems ODBC”，点击“完成”进入下一步。
3、在弹出的“InterSystems ODBC数据源设置”窗口中，为数据源命名，填写连接数据库的信息，访问用户名和密码，点击“测试连接”，成功后点击“OK”保存。
Hi 开发者社区的成员们，大家好！
欢迎关注我们第一期 InterSystems Ideas News!
经过一段时间的学习和使用本文总结了一些使用VsCode开发的使用方法，本文偏向于应用但会对少量的我知晓的原理进行一部分解释。
参考教程链接：https://cn.community.intersystems.com/node/488611
VSCode下载：https://code.visualstudio.com/
1 优势：
2 劣势：
1官网安装Visual Studio Code编辑器
有Developer听闻了InterSystems的包管理器ZPM, 希望我能介绍一下。正好刚刚看到一个开发者论坛的新闻： Open Exchange ZPM is now InterSystems Package Manager , 觉得更有必要了。
简单说：zpm, 全称InterSystems ObjectScript Package Manager, 是一个包管理器, 开发者是Nikolay Soloviev和Dmitry Maslennikov。它先是在开发者社区里得到认可，以至于InterSystems开发者社区最近的一些比赛，要求参赛作品用zpm打包。然后就有了上面的链接的内容：InterSystems决定把它做为自己官方的打包工具, 将它改名字叫IPM(InterSystems Package Manager)，同时保持它的开源状况不变。
这里我还是用zpm称呼它。两个原因。1. 操作的命令还是zpm, 所谓ipm,只是官方给的名字。2. ipm新的注册中心还不太了解，而且到目前为止，IPM的注册中心还只对自己的雇员和付费用户开放。本文的读者应该都还没来得及付费，所以暂时先放放，还是叫它zpm。
考虑到没有程序员背景的读者而对包管理器不熟悉，啰嗦两句。
各位开发者社区的同学们，大家好！
在各位社区同学的大力支持下，我们的“首届技术征文大赛”圆满完赛！在过去一周多的时间里，我们整理了各类奖项及礼品，目前已经全部寄出！
.png)
最新寄出的是开发者征文大赛获奖者的奖品，请以下同学留意查收，如未收到快递信息，请及时与我们联系：
| @Zhe Wang |
@姚.
以上几个场景虽然大多都可以提前做好约定解决，但是可能有历史原因或者种种情况，需要我们自己能够解决，于是就有了下面的故事。
首先我方系统使用GB18030编码，然后碰到的情况大多都是对方可能是UTF8编码，所以主要来解决识别字节流是不是UTF8编码的。
SM4算法是一种分组密码算法。其分组长度为128bit，密钥长度也为128bit。加密算法与密钥扩展算法均采用32轮非线性迭代结构，以字（32位）为单位进行加密运算，每一次迭代运算均为一轮变换函数F。SM4算法加/解密算法的结构相同，只是使用轮密钥相反，其中解密轮密钥是加密轮密钥的逆序。
密钥长度为128比特，表示为MK=(MK(0),MK(1),MK(2),MK(3)),其中MKi(i=0,1,2,3)为字。 轮密钥表示为(rk(0),rk(1),...,rk(31)),其中rk(i)(i=0,...,31)为32比特字。轮密钥由秘钥生成。
首先，将明文转化为字节，由于SM4加密算法按照128个位进行分组，所以很大几率会出现最后一个分组不够128位的情况，需要进行填充，填充方式有很多，比如ZeroPadding、PKCS7Padding、PKCS5Padding，不管使用哪种方式，最后每个分组都是128位。每个分组按照32位一个字分成四个字。
ECB模式 电子密码本模式，最古老，最简单的模式，将加密的数据分成若干组，每组的大小跟加密密钥相同。不足的部分进行填充。 按照顺序将计算所得的数据连在一起即可，各段数据之间互不影响。
优点：简单，有利于并行计算，误差不会
Hi！大家好！
截至11月3日中午，我们的开发者社区会员共495人！我们准备了一份惊喜礼品，准备送给第500名开发者社区会员！
.png)
那么，谁是第500名幸运的开发者社区成员呢？我们拭目以待！(*^▽^*)
集成平台的关键在于解决系统之间的互联互通和互操作性的问题，是一个多厂商、多协议的体系结构。医院在集成平台实施的过程中，面临的第一件重要的事情就是交互标准的选择，目前的建设中，分为两队：非标准队和标准队。非标准队一般采用视图抓取、xml格式、json等等的自定义格式，标准队一般采用HL7 V3、HL7 V2、FHIR、DICOM等医疗领域标准，下面会简单介绍一下各种方式以及实施落地的难易程度。（以下内容中将以难易程度总分5★来表示，星数量越多代表难度越高）
与其说非标准，不如定义为院内交互标准，交互仅限于院内，是一种很有限的互操作，而且定制程度很高，需要很好地把握系统的内部知识。方案缺乏通用性，难以规模推广。但由于其技术门槛较低，学习成本较低，在集成系统数量较少时不失为一种经济快速的方法。
视图可以说是一种"古老"的交互方案了，几乎传统的系统交互都是用视图的方式，有实施周期短，上线速度快的优点，但提供视图一方数据库，在大量数据查询的时候，将面临系统压力过大，数据库速度变慢等问题。在集成平台建设中，使用视图形式，可以由集成平台定时轮询视图，将数据发送给需要的系统。这样可以减轻源系统的压力。但是无论进行怎么样架构设计，视图这种形式的最大的弊端：无法保证数据的实时性。落地难度：1星。
SM3密码杂凑算法是中国国家密码管理局2010年公布的中国商用密码杂凑算法标准。该算法于2012年发布为密码行业标准(GM/T 0004-2012)，2016年发布为国家密码杂凑算法标准(GB/T 32905-2016)。
SM3适用于商用密码应用中的数字签名和验证，是在[SHA-256]基础上改进实现的一种算法，其安全性和SHA-256相当。SM3和MD5的迭代过程类似，也采用Merkle-Damgard结构。消息分组长度为512位，摘要值长度为256位。
整个算法的执行过程可以概括成四个步骤：消息填充、消息扩展、迭代压缩、输出结果。
SM3的消息扩展步骤是以512位的数据分组作为输入的。因此，我们需要在一开始就把数据长度填充至512位的倍数。具体步骤如下：
1、先填充一个“1”，后面加上k个“0”。其中k是满足(n+1+k) mod 512 = 448的最小正整数。
2、追加64位的数据长度。
将填充后的消息m′按512比特进行分组：m′ = B(0)B(1)...B(n−1) 其中n=(l+k+65)/512。
SM3的迭代压缩步骤没有直接使用数据分组进行运算，而是使用这个步骤产生的132个消息
1，准备
本次安装环境：Kylin-Server-10-SP2-Release-Build09-20210524-x86_64.iso
安装系统适配的对应版本：HealthConnect-2021.1.2.338.0-lnxubuntux64.tar.gz；ISCAgent-2021.1.2.338.0-lnxubuntux64.tar.gz
系统语言选择：English（必要）
2，安装HealthConnect+webgateway
2.1 新建所需用户组
groupadd iscagent
2.2 解压文件
.png)
2.3 安装
本次安装，使用root用户及root用户组安装，超级端口改为51773
3，安装ISCAgent
3.1安装说明
ISCAgent是healthconnect的镜像服务，若是单机使用，则不需要安装。
3.2 解压文件
3.3 安装
3.3 加入服务
3.3.1 新建文件
在/etc/systemd/system 下创建文件，ISCAgent.service，内容如下:
[Unit]
Description=InterSystems Agent
After=syslog.target network-online.
门为医疗行业打造，深度整合国内外医疗行业标准，专有技术服务医疗行业44年，可能是全球最早从事医疗信息化的公司；
耕细做打磨数十年的稳定、可靠、易用、可扩展的数据平台；
色鲜明，不唯技术、终生负责、以解决客户问题为核心的特色企业文化；
一代混合一体化架构，一个平台同时支持混合事务处理、传统架构、容器化、云原生等多种应用场景；
构建系统夯基础，日常运维是保障。运维工作杂又细，业务连续是关键。等保评级都看它，日常练兵保安全。日常运维很重要，想要干好不容易。要想运维功夫硬，日常应该怎么做？
医院管理者、信息中心、业务骨干，每个角色都有独特的业务诉求，InterSystems IRIS医疗版互联互通套件专为国内用户设计，截至2021年，InterSystems技术已助力一百余家医院通过四级及以上医院信息互联互通标准化成熟度评级，其中，五乙用户占全国30%以上。
众说周知，EPIC 是电子病历厂商中当之无愧的领导者，本文让我们看看EPIC是如何玩转FHIR的，并进一步了解其互操作性方法、资源和API工具。
几十年来，EPIC和其他主要的EHR供应商一直在围绕着互操作性作斗争，有时候互相容忍，有时也得接受（开放接口）。
今天，大多数电子病历厂商已经针对市场和监管的压力采取了行动，采用FHIR API标准，扩大病人对医疗记录的访问。
但在早期，EPIC和其他竞争对手争先恐后地抢占市场份额，为了成为院内系统的主导者，与其他厂商分享数据、给别人提供数据访问似乎是自我毁灭。
那么今天，EPIC在FHIR API、SMART on FHIR 应用市场、患者访问和互操作性战略方面的立场如何？ 以下是关于EPIC在FHIR API和互操作性上提供的简单介绍和链接。
大多数EPIC集成的重点是通过EPIC系统提供扩展访问，但不一定与其他厂商共享。
Epic提供了以下几种连接方式（https://www.epic.com/interoperability/ehr-interoperability-from-anywher…;
我在这里和大家分享下在 Interoperability 的接口开发中，调用Web Service接口的几个超时参数的设置经验。
赶时间的同学可以直接拉到文章最下面看结论就好。
1.实验过程
首先我设计了一个Web service的服务器端，强制在接收到请求后 8s 返回结果。
在客户端我设置了响应超时7s, 重试间隔5s, 故障超时23s，如图：
.png)
在客户端、服务器端均设置了SOAP Log 记录接收和发送的内容
.png)
set ^ISCSOAP("Log")="io"
set ^ISCSOAP("LogFile")="c:\temp\soapClient.txt"经过整理日志我画了下面的数据流图
.png)
2. 得出下面结论：
3. 结论再验证
为了验证上面结论我修改了Web service的服务器端代码，强制在接收到请求后 23s 返回结果，
并且设置响应超时20s, 重试间隔6s, 故障超时25s，得出上面同样的结论：自动重发或者故障超时错误的触发条件都是收到响应超时错误。
.png)
“池大小”（PoolSize）设置的值决定了一个组件的作业的量和启动方式。在这篇文章中我们将具体讨论对于不同类型的组件来说“池大小”设置的可能值和这些值所代表的含义。
Pool Size = 1
对于所有的组件来说，运行池大小为1的含义都是一样的: 该组件有且只有一个作业，单独运行该组件的代码，顺序处理发送到该组件的消息（FIFO）。
Pool Size > 1
对于业务进程（BP）和业务操作（BO）来说，当运行池大小大于1时，该组件将运行多个作业（作业数=运行池大小设置数）。每个作业都只运行该组件的代码，但消息处理的顺序将被打乱。将运行池的大小设为大于1的值可以在一定程度上提升组件处理消息的性能，但是每个作业的性能还是受限于系统资源的，所以并不是说组件的性能可以随着运行池的大小增加而无限提升。
对于轮询类业务服务（Polling BS）来说，当运行池大小大于1时，该服务也将运行多个作业（作业数=运行池大小设置数）。但这种配置会导致多个进程对轮询结果产生竞争（race condition），所以一般情况下轮询服务不应将运行池大小设为大于1的数值。
对于作为服务器端接收外来网络连接的业务服务（TCP、HTTP、REST、SOAP等）来说，当运行池大小大于1时，运行的作业数将取决于“为每个连接创建作业（Job Per Connection）”设置的值。
在Cache数据库建表的时候，在定义字段长度的时候，长度设置为1000和长度设置为2000在存储一个长度为1000的值的时候占用的存储空间是否一致。是否在建表的时候建议把字段长度设置为MAXLEN=""
图1. 每vCPU每秒查询对比（InterSystems IRIS vs AWS Aurora MySQL，1-4 查询节点）
.png)
图2. 单节点插入/查询速度对比（InterSystems IRIS vs AWS Aurora MySQL vs MS SQL Server）
.png)
图3.
上线一个新的集成平台production或者组件是需要很多精力的，用户常常需要对每一个组件所满足的需求和所能提供的功能，使用到的协议，以及组件对系统资源的调用有深入细致的了解。在配置好一个production之后，您可能需要将这个production推送到测试或者正式环境，或者需要将一个写好的组件代码应用到不同的项目上。这些时候，production的导出功能可以方便您传输production或组件的配置和代码。
导出
需要导出production时，您可以移步到管理门户 - Interoperability - 相应的命名空间 - 列表 - Production 页面，选择您需要导出的production，再点击页面上的导出键进行导出。如下图1所示：
.png)
在弹出的对话框中，您可以选择在导出文件中您想包括的内容。如下图2所示：
.png)
您也可以通过管理门户 - Interoperability - 相应的命名空间 - 配置 - Production 页面，点击“Production 设置” - “操作”选项卡 - “导出”键进行导出。弹出的对话框同样如图2所示，会自动包括大部分production及其组件所需要的类。如果需要添加或更改导出的类，可以在此对话框进行操作。
.png)
如果您需要导出单个组件的代码和设置，可以在Production配置页面，选择您想导出的组件，点击“操作”选项卡 - “导出”键进行导出。
各位开发者社区的同学们，大家好！
10月24日晚，我们成功举办了“首届技术征文大赛线上分享会”，我们在这次活动中邀请了多位征文大赛的参赛同学分享技术心得，同期举办了多轮抽奖，以下是各个奖品的获奖名单，我们恭喜这些获奖者，同时提醒获奖者请务必通过二维码登记奖品领取信息（如已登记请忽视）。
谁没有 Library.SQLCatalogPriv
日常工作中，我们使用xml 应该是比较多的，早期的ensemble或者cache，对JSON的支持不是很好，但是对xml支持比较好。因此早期的接口方式中，webservice+xml的方式很常用。而对象导出为xml最简单的方式就是类继承
这里，我姑且定义一个类，用于说明使用场景。
各位开发者社区的同学们，大家好！
我们的🏆InterSystems开发者社区中文版首届技术征文大赛🏆（←点击链接进入参赛页面，浏览所有参赛文章）已经结束，此次大赛收到了来自20名参赛者的30篇参赛文章，感谢大家的积极参与！
以下是获奖名单！
当我们使用IRIS时，我们通常有能力快速的部署一个现成使用的BI基础模块（数据、分析立方体和IRIS BI仪表盘）。当我们开始使用Adaptive Analytics时，我们通常希望有同样的功能。Adaptive Analytics拥有我们需要的所有工具。文档中包含了对如何使用开放的网络API的描述。用户界面和引擎之间的所有交互也都是通过内部的Web API发生的，并且可以被发射出来。
有必要将这两个过程自动化：在容器中部署Adaptive Analytics和直接部署到服务器系统。为此，最简单的方法是使用bash脚本来处理API。我们唯一需要的第三方应用程序是一个名为jq的JSON文件解析器。你可以使用以下命令来安装它：
apt update
apt install -y jq
首先，我们需要登录以获得一个API访问令牌。这个令牌也适用于引擎本身的方法。我们必须将访问令牌保存在一个变量中，因为现在我们几乎在每个请求中都需要它。对于一个标准的登录和密码admin/admin，该命令将看起来像这样：
TOKEN=$(curl -u admin:admin --location --request GET 'http ://localhost:10500/default/auth')接下来，我们需要一个活跃的引擎来与API交互。
开发者社区的同学们，1024快乐！
今晚19:30，我们将通过“InterSystems首届技术征文大赛线上分享会”发布获奖名单、进行征文作品分享&点评、探讨热门话题，同期还将举办多轮抽奖！欢迎参会，锁定#腾讯会议
本节包含创建身份验证组时要考虑的一些要点。
By-ID 和登录 Cookie 共享更加强大和可预测。By-ID 组和 By-Session 组中。使用不同的身份验证策略可能会导致意外行为。 By-ID 优先于 By-Session。因此，如果一个应用程序两者都有，它会保持同步 By-ID。Cookie 而其他应用程序不允许，则通过用户名/密码进入组会验证整个组，而通过登录 cookie 输入只会验证部分应用程序。这可能会导致用户对为什么有时需要登录而有时不需要登录感到困惑。CSP 服务器认为每个应用程序都在一个身份验证组中。会话中的一个单独的应用程序形成一个单实体 By-Session 身份验证组。）By-ID 组中。By-Session 组很脆弱；使用 By-ID 是一种更稳健的方法。由于有关组的所有信息（包括其共享数据）都包含在单个会话中，因此该组很容易丢失。这是因为会话可能会超时，即在特定时间后会话会自动销毁。
