转到文章 Nicky Zhu · 九月 29 你好,这个界面的内容基于活动量监控,需要在production中加入BO Ens.Activity.Operation.Local,可参考https://cn.community.intersystems.com/post/%E9%9B%86%E6%88%90%E4%BA%A7%E... 以及 https://cn.community.intersystems.com/post/intersystems-%E6%95%B0%E6%8D%...
转到文章 Nicky Zhu · 八月 2, 2023 你好,从执行日志上看,问题发生在SOAP Adapter尝试将字符流转换为XML的过程中,由于不能正确地识别XML中的节点标记导致错误,这类问题根源出现在被调用一方的返回消息中,常见的情况包括: 1. 被调用端与IRIS两侧采用的编码不同,例如对端采用GB18030而IRIS采用UTF-8(SOAP服务默认编码),导致无法正确解析XML 2. 对端返回的不是合法XML,可能包括XML结构错误、包含ASCII码控制字符等 建议: 保存对端返回的报文,然后 1. 确认对端返回报文的编码,可以使用ATOM、UltraEdit等文本编辑器进行编码转化,查看字符是否能正常显示 2. 采用XML SPY、Oxygen XML Editor等专业XML处理工具对报文进行XML合法性校验 核心是先确认对端返回的是合法、编码正确的XML
转到文章 Nicky Zhu · 三月 1, 2023 Hi, 有两个办法: 1. 自己写代码扫描messages.log获得这些告警 2. 扩展平台内置的告警通知类,可以自定义传感器、消息订阅器和通知分发器,参见 https://docs.intersystems.com/irisforhealth20223/csp/docbook/DocBook.UI....
转到文章 Nicky Zhu · 一月 4, 2023 您好,产品提供的REST API还没有独立的文章一一列举,目前是归属在对应的功能模块中。 您可以在文档库(如 https://docs.intersystems.com/irisforhealthlatest/csp/docbook/DocBook.UI...)检索“REST Interface”,可以获得有REST接口的功能的对应章节链接,如下所示:
转到文章 Nicky Zhu · 十二月 27, 2022 您好,对于BPL中的成分,由于其在代码中以XML记录,可以通过解析该类中xdata中的xml代码段,基于xml文本提取出switch标签中的内容进行解析可以获得其中的内容,可参考https://docs.intersystems.com/irisforhealth20222/csp/docbook/Doc.View.cl... 但需要理解的是,基于静态代码分析得到的结果是理论上的分支,不一定能代表实际的业务运行情况,例如在代码有bug导致分支无效的情况等。而所有流经IRIS的消息都被持久化在消息标中,基于消息表通过SQL进行统计更能反映实际的业务运行状况。可参考:https://cn.community.intersystems.com/post/intersystems-%E6%95%B0%E6%8D%...https://cn.community.intersystems.com/post/%E9%9B%86%E6%88%90%E4%BA%A7%E... 另外,IRIS所有产品都带有查看消息的web界面,可以从portal中访问,也可以作为一个url被集成到用户自己的应用中去:
转到文章 Nicky Zhu · 十一月 17, 2022 您好,这个现象是由于采用命名空间的默认应用程序来发布SOAP服务引起。 通常我们建议将portal使用的web application和服务用的web application分开,用独立的Web application发布Web Service或RESTful服务,因为访问服务和访问portal的用户,用户角色不应该是一样的。比如现在这样portal和服务共用一个web application,如果要让soap不用授权就需要取消对这个命名空间的默认程序的授权限制,意味着谁都能登录进portal甚至进行修改。 SOAP使用的独立web application尽量使用授权,不用授权意味着任何网络请求都可以通过接口执行代码消耗服务器资源。 您这个情况可以尝试取消Web Application的“必要的资源”设置看看
转到文章 Nicky Zhu · 九月 8, 2022 您好,通常对于第三方的数据库连接,最常见的性能问题的根源在于平台一侧的数据吞吐量大于对方数据库接收数据的能力,在使用BO及OutboundAdapter时,可以观察到消息队列拥堵,尤其是低业务量下顺畅,高业务量下出现队列快速拥堵的情况下,几乎可以肯定是对端数据库的性能缺陷。 在这种情况下,由于堵点不在平台而在数据库,在平台侧的所有优化都解决不了问题,只能保障平台不因对端数据库的拥堵崩溃。可选的处理手段有: 1. 最终用户根据数据库的吞吐量降低整个平台的吞吐量 2. 最终用户要求保障平台吞吐量,但对端数据库无法优化,则需要接受在平台中堆积队列的现实 3. 最终用户要求保障平台吞吐量,对端数据库改进性能以满足平台吞吐的需要 建议对方的数据库性能进行基准性能和压力测试,使得平台和数据库在吞吐量上相互适应 打印对端数据库的出错信息,可参考 //Create new Gateway connection object set gc=##class(%SQLGatewayConnection).%New() If gc=$$$NULLOREF quit $$$ERROR($$$GeneralError,"Cannot create %SQLGatewayConnection.") //Make connection to target DSN s pDSN="Cache Samples" s usr="_system" s pwd="SYS" set sc=gc.Connect(pDSN,usr,pwd,0) If $$$ISERR(sc) quit sc if gc.ConnectionHandle="" quit $$$ERROR($$$GeneralError,"Connection failed") set sc=gc.AllocateStatement(.hstmt) if $$$ISERR(sc) quit sc //Prepare statement for execution set pQuery= "insert into scott.dept (deptno,dname,loc) values (10,'Customer Support','Tokyo')" set sc=gc.Prepare(hstmt,pQuery) if $$$ISERR(sc) quit sc //Execute statement set sc=gc.Execute(hstmt) if $$$ISERR(sc) { Set xsc=gc.GetErrorList(hstmt,.err) Zwrite err Quit err }
转到文章 Nicky Zhu · 八月 10, 2022 您好,不知您是用什么工具构建dashboard。 如果是deepsee或者其他BI工具,在构建dashboard之前需要先基于关系模型构建分析模型(如Cube)。而直接导入的global文件如果不包含该数据对应的表或对象元数据,就不能通过建立cube分析模型构建dashboard。 但如果只是需要dashboard展示数据,并没有建立分析模型必要,则可以考虑通过定义KPI,书写自定义代码建立global与KPI结果集转换关系的方式来构建dashboard。参见: https://docs.intersystems.com/irisforhealth20221/csp/docbook/Doc.View.cl... https://docs.intersystems.com/irisforhealth20221/csp/docbook/Doc.View.cl...
转到文章 Nicky Zhu · 八月 10, 2022 建议先学习产品的权限控制体系,可以参考这个系列的两篇文章 https://cn.community.intersystems.com/post/iris%E4%B8%AD%E7%9A%84%E6%9D%...
转到文章 Nicky Zhu · 四月 26, 2022 透视表需要基于Cube或Subject Area构建,您需要先建立Cube和SA才能创建透视表 在BI套件中,Architect/模型工具用于创建Cube和SA;Analyzer/分析器 用于创建透视表
转到文章 Nicky Zhu · 四月 25, 2022 您好,不知道您是不是使用BI套件在制作dashboard? 如果是,那么dashboard只是个用于摆放数据控件的容器,本身不需要绑定数据源。 对于数据源的绑定是通过在dashboard中引用透视表或其他数据可视化组件完成的。
转到文章 Nicky Zhu · 三月 16, 2022 从文档库搜索关键词“JDBC“ 进入第一篇或第二篇文档,其中明确指出了IRIS使用的JDBC参数 耗时大约15秒 请务必使用官方文档以达到事半功倍的效果哦