#SOAP

Post a job 关注
0 关注者 · 10 帖子

SOAP（简单对象访问协议的缩写）是一种消息传递协议规范，用于在计算机网络中实施 Web 服务时交换结构化信息。

了解更多信息。

Post a job 关注
文章 姚 鑫 · 八月 28, 2024 2m read

第九章 创建和使用策略 - 创建并附加策略

第九章 创建和使用策略 - 创建并附加策略

创建并附加策略

要创建策略并将其附加到Web 服务或客户端，请创建并编译配置类。有多种方法可以创建此类：

  • 使用 GeneratePolicyFromWSDL() 方法从 WSDL 生成配置类。如果 Web 服务或客户端类已存在，并且您不想重新生成，则适用此选项。
  • 为现有的 Web 服务或客户端手动创建配置类。

如果从 WSDL 生成策略类，则可能需要按下一节所述对其进行编辑。

从 WSDL 生成策略

在某些情况下，可能已经有客户端类，但没有相应的配置类。例如，如果从 WSDL 生成客户端类，而 WSDL 后来被修改为包含 WS-Policy 信息，则可能会发生这种情况。在这种情况下，可以使用 %SOAP.WSDL.Reader中的实用程序方法单独生成配置类，如下所示：

  1. 创建 %SOAP.WSDL.Reader 的实例。
  2. 根据需要设置该实例的属性。请参阅 %SOAP.WSDL.Reader 类文档。

不要使用 Process() 方法。

  1. 调用实例的 GeneratePolicyFromWSDL() 方法。

此方法具有以下签名：

method GeneratePolicyFromWSDL(wsdlURL As %String, 
    clientWebServiceClass As %String, 
    policyConfigClass As %String) as %Status

其中：

  • wsdlURL 是包含策略的 WSDL 的 URL。假设 WSDL 仅指定一个端口。
  • clientWebServiceClass 是 Web 客户端类的名称。有责任确保此 Web 客户端与给定的 WSDL 匹配。
  • policyConfigClass 是要创建的配置类的名称。

这将为 Web 服务客户端创建（或覆盖）一个配置类，其中包含 Web 服务的 WSDL 指定的策略。如果 WSDL 中没有策略，则创建一个空的配置类。如果实例的 CompileClasses 属性等于 1，则将编译该配置类。

#InterSystems IRIS #InterSystems IRIS for Health #Java #SOAP
0
0 101
文章 姚 鑫 · 七月 25, 2024 2m read

第四章 覆盖 HTTP SOAP 操作和请求消息名称

第四章 覆盖 HTTP SOAP 操作和请求消息名称

覆盖 HTTP SOAP 操作和请求消息名称

当通过 HTTP 调用 Web 方法时，HTTP 标头必须包含 SOAP 操作，该操作是指示 SOAP HTTP 请求意图的 URI。对于 SOAP 1.1，SOAP 操作作为 SOAPAction HTTP 标头包含在内。对于 SOAP 1.2，它包含在 Content-Type HTTP 标头中。

SOAP 操作指示 SOAP HTTP 请求的意图。该值是一个标识意图的 URI；它通常用于路由入站 SOAP 消息。例如，防火墙可以使用此标头适当地过滤 HTTP 中的 SOAP 请求消息。

对于 Web 服务中的 Web 方法，SOAPAction HTTP 标头默认具有以下形式（对于 SOAP 1.1）：

SOAPAction: NAMESPACE/Package.Class.Method

其中 NAMESPACE 是 Web 服务的 NAMESPACE 参数的值，Package.Class.Method 是用作 Web 方法的方法的名称。例如：

SOAPAction: http://www.myapp.org/GSOAP.WebService.GetPerson

要覆盖此设置，请在 Web 方法的定义中为 SoapAction 方法关键字指定一个值。指定一个带引号的字符串，表示 SOAP 请求的意图。在典型情况下，Web 服务中的每个 Web 方法都会为 SoapAction 指定一个唯一值（如果有）。

如果 SoapAction 在该 Web 服务中不唯一，则每个方法都必须具有唯一的 SoapRequestMessage 方法关键字值。此关键字指定请求消息的 SOAP 主体中的顶部元素的名称。请注意，SoapRequestMessage 仅对包装的文档/文字消息有效。

指定元素是否符合条件

ELEMENTQUALIFIED 参数（ Web 服务的）控制 WSDL 架构中 elementFormDefault 属性的值。具体来说：

  • 如果 ELEMENTQUALIFIED 为 1，则 elementFormDefault 为“qualified”。
  • 如果 ELEMENTQUALIFIED 为 0，则 elementFormDefault 为“unqualified”。

此参数的默认值取决于 SoapBodyUse 类关键字的值。请参阅类定义参考。通常，SoapBodyUse 是“文字”，这意味着 ELEMENTQUALIFIED 为 1。

控制消息部分是否使用元素或类型

Web 服务有一个参数 (XMLELEMENT)，用于控制 SOAP 消息的消息部分的精确格式。具体来说：

  • 如果 XMLELEMENT 为 1，则 <part> 元素具有名为 name 和 element 的属性。在本例中，WSDL 包含一个示例 <message> 元素，如下所示：
<message name="GetPersonSoapOut">
  <part name="GetPersonResult" element="s0:Person" />
</message>
  • 如果 XMLELEMENT 为 0，则 <part> 元素具有名为 name 和 type 的属性。在本例中，WSDL 包含一个示例 <message> 元素，如下所示：
<message name="GetPersonSoapOut">
  <part name="GetPersonResult" type="s0:Person" />
</message>

此参数的默认值取决于 SoapBodyUse 类关键字的值。请参阅类定义参考。通常，SoapBodyUse 是“literal”，这意味着 XMLELEMENT 为 1。

#InterSystems IRIS for Health #SOAP
0
0 118
问题 water huang · 十一月 17, 2022

ensemble发布BS服务 访问需要用户名密码

环境是windows server2012 r2 standard+ensemble2016.

新搭建的环境，安装ensemble的时候，选的是正常模式，就是设置了密码，然后新建了命名空间，发布了bs服务（webservice服务），访问的时候需要用户密码，如果在安全里面的web应用程序里面设置为不需要密码，不勾选密码，就访问不了服务，production页面都进不去。这个还需要什么配置吗？期望的效果是，登录portal需要用户名密码，但是对应某些命名空间发布的web服务，不需要用户密码就能访问

#Ensemble #SOAP
3
0 283
文章 Tete Zhang · 十月 26, 2022 3m read

运行池大小配置的解读

“池大小”（PoolSize）设置的值决定了一个组件的作业的量和启动方式。在这篇文章中我们将具体讨论对于不同类型的组件来说“池大小”设置的可能值和这些值所代表的含义。

Pool Size = 1

对于所有的组件来说，运行池大小为1的含义都是一样的: 该组件有且只有一个作业，单独运行该组件的代码，顺序处理发送到该组件的消息（FIFO）。

Pool Size > 1

对于业务进程（BP）和业务操作（BO）来说，当运行池大小大于1时，该组件将运行多个作业（作业数=运行池大小设置数）。每个作业都只运行该组件的代码，但消息处理的顺序将被打乱。将运行池的大小设为大于1的值可以在一定程度上提升组件处理消息的性能，但是每个作业的性能还是受限于系统资源的，所以并不是说组件的性能可以随着运行池的大小增加而无限提升。

对于轮询类业务服务（Polling BS）来说，当运行池大小大于1时，该服务也将运行多个作业（作业数=运行池大小设置数）。但这种配置会导致多个进程对轮询结果产生竞争（race condition），所以一般情况下轮询服务不应将运行池大小设为大于1的数值。

#Ensemble #InterSystems IRIS for Health #全球响应中心 (WRC) #FTP #REST API #SOAP #开发运维 #调试
1
0 285
问题 e e · 六月 7, 2021

csp和webservice文件上传

为什么我用webservice上传文件比csp上传文件快？

webservice用的soap协议也得走http呀。csp直接处理http，少了xml的封装，按理来说应该更快。

经测试，1M的文件，csp慢了0.1s左右。在网关连接到1972后，有0.1s左右的停滞，不知道原因。

有什么办法能够使csp的文件上传速度比webservice快吗？

#Caché #CSP #SOAP
1
0 331
InterSystems 官方 Qiao Peng · 三月 3, 2021

IAM 1.5.0.9 正式发布

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

 

IAM容器，包括从原有IAM版本升级的所有相关工件, 现在可以在 WRC 软件发布网址 组件区下载。

 

该版本的小版本号是 IAM 1.5.0.9-4。

 

InterSystems API Manager 1.5 使管理API通讯、与你的环境集成、加载API用户更加容易。它包含很多新特性，包括:

 

  • 改进的用户体验
  • 新的开发者门户工具
  • 对Kafka connectivity的支持

 

这个版本基于Kong Enterprise version 1.5.0.9。之前的IAM版本包括一个贴牌版本的Kong Enterprise, 在本版本中的Kong Enterprise不再贴牌。 这个变化让我们可以更快的节奏带给您新的版本，并更有效地利用Kong提供的文档和其它资源。

 

请在 这里 查看IAM 1.5 的文档。这个文档仅说明IAM特殊的元素。产品中的文档链接直接打开Kong Enterprise的文档。

 

从IAM 0.34-1 升级需要通过3个中间版本累积升级，在 文档中有详细的说明。

 

#InterSystems IRIS #InterSystems 官方 #API #InterSystems API管理器（IAM） #REST API #SOAP
1
0 255
文章 Claire Zheng · 一月 20, 2021 8m read

InterSystems API 管理器简介

大家可能已经听说过，我们近期推出了InterSystems API管理器 (以下简称IAM)。InterSystems IRIS数据平台™新增了一项功能，支持用户监视、控制和管理IT基础架构中基于Web的API间通信。

在本文中，我将向大家展示如何设置IAM，并重点介绍IAM中可用的一些功能。InterSystems API管理器可提供你所需的一切功能。

#InterSystems IRIS #API #InterSystems API管理器（IAM） #REST API #SOAP
3
0 301
文章 Nicky Zhu · 一月 8, 2021 6m read

Web 服务业务操作客户端 – 响应超时行为

调用 Web 服务的过程中，在期望的时间内未返回响应时，后续发生的情况由业务操作的几个设置来控制。（请注意，这也与非 SOAP 简单 HTTP 调用等有关）

3 个主要设置为：

  • 响应超时

    • 指定从远程 Web 服务器获取响应的超时时间。

  • 重试间隔

    • 尝试与 Ensemble 之外的目标进行连接之间等待的秒数。

  • 故障超时

    • 尝试与 Ensemble 之外的目标保持连接的总秒数。 经过此秒数时间后，业务操作将丢弃消息数据并返回错误代码。

    归纳一下就是这样：

    我们将等待 Web 服务器的响应，时间为“响应超时”所用的时间。 如果此时间过后未收到响应，我们将在“重试间隔”时间过后再次调用 Web 服务器。 如此继续尝试，直到时间（从第一次尝试算起）达到“故障超时”设置的时间秒数。

    以下举例进行说明：

    假定以下设置：

    就是说：

    响应超时 - 等待 7 秒以响应

    重试间隔 - 每 10 秒重试一次

    故障超时 – 30 秒后“放弃”重试

    假定在 8 秒后返回响应，则情况如下：

  • 在 00:00，我们进行第一次调用
  • 在 00:07，由于未返回任何响应，我们在内部确认发生了“响应超时”错误（并在“事件日志”中记录“错误事件”），并根据重试策略和设置再次尝试 – “故障超时”尚未到达，因此引发了“需要重试标志”。
  • [在 00:08，Web 服务器返回一个响应，但由于我们已经将其记录为超时错误，因此我们不会收到此响应]
  • 在 00:10，重试间隔时间已到，并且由于引发了“需要重试标志”，我们将再次调用 Web 服务。
  • 在 00:17，如果仍未返回任何响应，我们将再次达到“响应超时”时间（请注意，在上面的“00:08/第 3 段中，返回的响应已被“忽略/丢弃”），因此我们再次在内部将此认为是错误（但这次不会再添加一个“错误事件日志”条目，只会在第一次尝试时记录此错误，而不是每次重试失败时都记录），由于我们尚未达到“故障超时”时间，因此需要再次引发“需要重试标志”。
  • [在 00:18，Web 服务器返回一个响应，这次我们还是接收不到]
  • 在 00:20，又达到重试间隔时间，我们将尝试第 3 次调用。
  • 在 00:27，仍无响应，再次发生“响应超时”错误，需要重试（仍未达到“故障超时”）。
  • [在 00:28，服务器未发回响应]
  • 在 00:30，再次达到重试间隔时间，我们进行第 4 次尝试（也是最后一次）。
  • 在 00:37，“响应超时”再次发生 – 这次，已达到“故障超时”时间，因此我们不会引发“需要重试标志”，而是放弃 – 我们在事件日志中记录一个错误事件，指出已达到故障超时时间，并且返回业务操作调用错误。

    • 以下是上述示例的调用“证据”。

    首先是服务器端 [来自 SOAP 日志] – 可以看到，其收到了 4 次调用/请求，均相隔 10 秒，每次在请求发出 8 秒后返回一个响应：

    05/31/2016 14:18:45 *********************
    Input to Web service with SOAP action = http://tempuri.org/Test.WSTimeouts.WebService.GetResponse
    ...
    05/31/2016 14:18:53 *********************
    Output from Web service with SOAP action = http://tempuri.org/Test.WSTimeouts.WebService.GetResponse
    ...
    05/31/2016 14:18:55 *********************
    Input to Web service with SOAP action = http://tempuri.org/Test.WSTimeouts.WebService.GetResponse
    ...
    05/31/2016 14:19:03 *********************
    Output from Web service with SOAP action = http://tempuri.org/Test.WSTimeouts.WebService.GetResponse
    ...
    05/31/2016 14:19:05 *********************
    Input to Web service with SOAP action = http://tempuri.org/Test.WSTimeouts.WebService.GetResponse
    ...
    05/31/2016 14:19:13 *********************
    Output from Web service with SOAP action = http://tempuri.org/Test.WSTimeouts.WebService.GetResponse
    ...
    05/31/2016 14:19:15 *********************
    Input to Web service with SOAP action = http://tempuri.org/Test.WSTimeouts.WebService.GetResponse
    ...
    05/31/2016 14:19:23 *********************
    Output from Web service with SOAP action = http://tempuri.org/Test.WSTimeouts.WebService.GetResponse
    ...
     

    现在，从 Ensemble BO/客户端，可以看到，有 4 次尝试，均相隔 10 秒，每次在 7 秒后记录响应超时错误。

    客户端

    05/31/2016 14:18:45 *********************
    Output from Web client with SOAP action = http://tempuri.org/Test.WSTimeouts.WebService.GetResponse
    ...
     
    05/31/2016 14:18:52 *********************
    Input to Web client with SOAP action = http://tempuri.org/Test.WSTimeouts.WebService.GetResponse
    ERROR #5922: Timed out waiting for response
    string**** SOAP client return error. method=GetResponse, action=http://tempuri.org/Test.WSTimeouts.WebService.GetResponse
         ERROR #5922: Timed out waiting for response
     
    05/31/2016 14:18:55 *********************
    Output from Web client with SOAP action = http://tempuri.org/Test.WSTimeouts.WebService.GetResponse
    ...
     
    05/31/2016 14:19:02 *********************
    Input to Web client with SOAP action = http://tempuri.org/Test.WSTimeouts.WebService.GetResponse
    ERROR #5922: Timed out waiting for response
    string**** SOAP client return error. method=GetResponse, action=http://tempuri.org/Test.WSTimeouts.WebService.GetResponse
         ERROR #5922: Timed out waiting for response
     
    05/31/2016 14:19:05 *********************
    Output from Web client with SOAP action = http://tempuri.org/Test.WSTimeouts.WebService.GetResponse
    ...
     
    05/31/2016 14:19:12 *********************
    Input to Web client with SOAP action = http://tempuri.org/Test.WSTimeouts.WebService.GetResponse
    ERROR #5922: Timed out waiting for response
    string**** SOAP client return error. method=GetResponse, action=http://tempuri.org/Test.WSTimeouts.WebService.GetResponse
         ERROR #5922: Timed out waiting for response
     
    05/31/2016 14:19:15 *********************
    Output from Web client with SOAP action = http://tempuri.org/Test.WSTimeouts.WebService.GetResponse
    ...
     
    05/31/2016 14:19:22 *********************
    Input to Web client with SOAP action = http://tempuri.org/Test.WSTimeouts.WebService.GetResponse
    ERROR #5922: Timed out waiting for response
    string**** SOAP client return error. method=GetResponse, action=http://tempuri.org/Test.WSTimeouts.WebService.GetResponse
         ERROR #5922: Timed out waiting for response

    以下是对 Ensemble 的可视化跟踪：

    以下是事件日志条目：

    以下为跟踪事件的日志示例[您可能需要放大以更好地读取文字]：

    由此，可以看到上述示例的一些“内部运作”：

    在日志行 ID #684，执行了首次调用 – 时间：17:09:16。

    然后，在 7 秒之后 (09:23)，我们收到响应超时错误 (#685)。 然后，操作记录了此错误 (#687)，并确定等待 3 秒钟，直到达到重试间隔时间；10 秒重试间隔时间减去 7 秒响应超时时间 (#688-#690)。

    经过 3 秒等待（ 09:26；＃691）之后，进行第 2 次尝试 (#692)，结果相同，继续重复操作，直到第 4 次尝试 (#704)。 在第 4 次尝试失败（09:53；＃705）之后，由于达到超时时间（30 秒），因此未进行另一次尝试。

    #Ensemble #SOAP #业务运营
    0
    0 334
    文章 Louis Lu · 一月 7, 2021 4m read

    创建“虚拟”的SOAP Web 服务

    在 Caché 中处理 SOAP 请求时，有时需要通过直接访问（有时是编辑）所发送的 XML（即 SOAP 请求和随后的 SOAP 响应）来调试错误。 如果要调试 Caché Web 服务，使用 SoapUI (https://www.soapui.org/) 之类的工具手动创建和控制 SOAP 请求通常很有用，这样可以很容易地在 Caché Web 服务上看到调整的效果。

    但是如果已经有 Web 服务（可能不是 Caché），并且想要调试相关的 Caché Web 客户端该怎么办？ 您可能已将 SOAP 响应 XML 保存在文件中（例如 Caché SOAP 日志），您需要一个“虚拟”Web 服务将其发送到 Caché Web 客户端，就像实际的 Web 服务一样操作。

    由于我经常在技术支持的过程中需要调试客户的 Caché Web 客户端，我创建了这样一个“虚拟”的Web 服务 – 见下文：

    Class JSUtil.DummyWebService Extends %CSP.Page
{

/// Mimic a SOAP Web Service by sending the specified SOAP Response XML.
/// Typically this XML will be copied-and-pasted from a SOAP log.
Parameter CONTENTTYPE = "text/xml";

/// File containing the SOAP Response XML:
Parameter XMLFILENAME = "C:\data\soapresponse.txt";

ClassMethod OnPage() As %Status
   {
                set XML=""
                set stream = ##class(%Stream.FileCharacter).%New()
                set sc = stream.LinkToFile(..#XMLFILENAME)

                while 'stream.AtEnd {
                 set XML = XML_stream.Read()
                }

    write XML
   quit $$$OK
   }

}

    要使用 JSUtil.DummyWebService 类：

  • 1.将参数 XMLFILENAME 的值更改为包含来自 Web 服务的 SOAP 响应的 XML 的位置。 通常，此文件可内容可通过手动剪切和粘贴 Caché SOAP 日志中的响应 XML 消息来创建。
  • 2.使用 Studio 的“View Web Page”获取此 CSP 页面的 URL，它应显示响应的XML消息内容。
  • 3.将上面的 URL 粘贴到 Caché Web 客户端的 LOCATION 参数中。

    • 现在，当调用 Caché Web 客户端时，它将收到参数 XMLFILENAME 指向的 SOAP 请求 XML。

    我已经多次使用这种方法来帮助调试 Caché Web 客户端。 参考以下示例：

    SOAP 日志的“Web 客户端的输入”中包含以下错误：

    ERROR #6203: Unexpected Element

    （完整的 SOAP 日志可在此处找到：https://github.com/ISC-schulman/InterSystems/raw/master/soaplog.txt）

    我们还有 Web 服务的 WSDL (https://github.com/ISC-schulman/InterSystems/raw/master/example.wsdl)，但无法访问 Web 服务本身。 （虽然这对于 InterSystems 支持来说很常见，但不可否认，对于客户可能并不常见 – 这只是一个简单的示例，说明如何使用 DummyWebService。）

    首先，使用 DummyWebService 重现错误：

  • 1.使用 SOAP 向导从提供的 WSDL 生成 Web 客户端。 所有参数均使用默认值（尽管您可以指定包名称。）
  • 2.查看 SOAP 日志，然后将 Web 服务响应的XML（“Input to Web client”）剪切并粘贴到文件中： OK 
  • 3.通过 JSUtil.DummyWebService 中的参数 XMLFILENAME 指向此文件。
  • 4.使用 Studio 的“Display Web Page”查看 DummyWebService – 它应显示步骤 2 中创建的文件内容。
  • 5.将步骤 4 中的 URL 剪切并粘贴到步骤 1 中生成的 Web 客户端的 LOCATION 参数中。
  • 6.调用 Web 客户端，例如
    •  set client = ##class(MyWebService.RequestWSSoapHttpPort).%New()  do client.createAsynchronuosRequest("x") quit
  • 7. 验证（例如通过 SOAP 日志）是否发生相同错误，即“ERROR #6203: Unexpected Element”。

    •   接下来我们解决这个错误。 这里会经历一些过程或反复试验，但同样只是为了说明如何使用 DummyWebService。

  • 1.像之前一样使用 SOAP 向导和提供的 WSDL 生成 Web 客户端 – 指定不同的包名称以防止覆盖第一个 Web 客户端。 另外，参数全部采用默认值，除了一处： 在 SOAP 向导的步骤 3 中选择“对于文档样式的 Web 方法使用未包装的消息格式(Use unwrapped message format for document style web methods)”
  • 2.重复上面的步骤 5 和 6。
  • 3.验证（例如通过 SOAP 日志）Web 客户端错误是否已修正。

    • （注意：使用“未包装的消息格式(unwrapped message format)”是解决 Web 客户端问题的常见解决方案 – 有关详细信息，请参见我们的文档中的“使用 SOAP 向导”。）

    总结

    可以使用 DummyWebService 类将指定的 SOAP 响应（例如，从 SOAP 日志）发送到 Caché Web 客户端，以模拟 Web 服务的响应。

    #Caché #SOAP
    0
    0 309