你好,从执行日志上看,问题发生在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

您好,产品提供的REST API还没有独立的文章一一列举,目前是归属在对应的功能模块中。

您可以在文档库(如 https://docs.intersystems.com/irisforhealthlatest/csp/docbook/DocBook.UI...)检索“REST Interface”,可以获得有REST接口的功能的对应章节链接,如下所示:

 

您好,
对于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被集成到用户自己的应用中去:

 

您好,这个现象是由于采用命名空间的默认应用程序来发布SOAP服务引起。

通常我们建议将portal使用的web application和服务用的web application分开,用独立的Web application发布Web Service或RESTful服务,因为访问服务和访问portal的用户,用户角色不应该是一样的。
比如现在这样portal和服务共用一个web application,如果要让soap不用授权就需要取消对这个命名空间的默认程序的授权限制,意味着谁都能登录进portal甚至进行修改。

SOAP使用的独立web application尽量使用授权,不用授权意味着任何网络请求都可以通过接口执行代码消耗服务器资源。

您这个情况可以尝试取消Web Application的“必要的资源”设置看看

您好,通常对于第三方的数据库连接,最常见的性能问题的根源在于平台一侧的数据吞吐量大于对方数据库接收数据的能力,在使用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
  }

您好,不知您是用什么工具构建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...

如果是指数据库层的读写分离,可以使用Sharding技术,利用Sharding技术中的计算结点和数据结点,搭建负载均衡+读写分离的数据库集群,参考:

https://docs.intersystems.com/irisforhealthlatest/csp/docbook/DocBook.UI...

如果服务器/实例资源有限,又想实现读负载与写负载的分离,那么基于@Qiao Peng指出的镜像异步成员,在API层(即应用程序层)通过业务流程来控制查询/写入操作的分发则是成本较低的方案。