Hi Ralf,
unfortunately you did not provide the policy.

It should look like this: (in Wizard, pick "Username Authentication over SSL/TLS" - leave everything else on the defaults!)

<cfg:configuration xmlns:cfg="http://www.intersystems.com/configuration" xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702" xmlns:wsap="http://www.w3.org/2006/05/addressing/wsdl" xmlns:wsp="http://www.w3.org/ns/ws-policy" name="service">
  <cfg:service classname="[your webservice-class]">
          <sp:UsernameToken sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient">

In SOAPUI, enable WS-Addressing. Below the request-message there is a small button-line starting with [Auth] ... here you also find [WS-A] where you can find a checkbox to enable it.
Add the WS-A to the request. Right click on the request-message -> "WS-A headers"-> "Add WS-A headers".
Right click on request-message you can Add "WSS UsernameToken" and "WS-Timestamp" if you do not have configured that otherwise in general.

This works for me.

Please note: SOAP-logging (with "iosv" flags) is always a good help.


Currently, there is no API to request a new session cookie.

If we wished to implement this in the absence of any real security concern it would need to be scheduled by our product management and as en enhancement.

So far you have not suggested any compelling reason to do this.

Do you have an example of a valid attack against CSP?

Sorry, but I still do not see a general CSP related vulnerability problem here.

Please let us continue in WRC problem you've already opened for this same question recently.

Thanks and kind regards,


i would start with the xml-structure you expect and which probably/hopefully is already defined by an xml-schema.

You can import xml-schemas into IRIS to generate XML-enabled classes which extends %XML.Adaptor.


If you do not have a xml-schema, you need to create it or your xml-enabled classes manually. (extending %XML.Adaptor)


If you have that ready, let your XML-enabled classes also extend %JSON.Adaptor.


Use %JSON.Adaptor to import the JSON data (i think DynamicObject is also supported here directly)
into your XML enabled class with the help of %JSONImport() method.

Then use XMLExport..() method (inherited from %XML.Adaptor) to export as XML data.

I have not tried this so far but i think it should work :)


are you all set now? Or do you still get the same error? Please confirm.

You can add parameter debug: "debug.log" with the open() if it still does not work in order to hopefully get more information!?

Anyway, if you are local anyway you should use native connectivity mode instead tcp since it get's you better performance.


you can test your Node environment within a simple windows command window (CMD.exe):

C:\>node -v

> x=require('cache.node')
{ Cache: [Function: Cache] }
> y = new x.Cache
> y.version()
'Node.js Adaptor for Cache: Version: 1.0.63 (CM)'

Do you have renamed cache0100.node into cache.node an copied it into location specified in environment variable NODE_PATH ? e.g. NODE_PATH=C:\Program Files\nodejs

If not, you need to specify path to cache.node within require(), e.g. x=require('c:/mypath/tocachenode/cache')


i would start with a SOAP-LOG ("ios") to see what is sent out and what SoapAction is used from within Caché soap client.
see SOAP Logging docs here.

Use/install 3rd party tool "soapUI" (there is a free version), import WSDL and try to sent request from here. See if you can make it working and chekc http-log in soapUI to see what soapUI is exactly sending out to the service.

Some WebServices requires SOAPAction http-header to be quoted. To achieve this you need to use SOAPACTIONQUOTED param in your WebClient class, e.g.



i just tried and installed from kit-file "CSPGateway-2018.1.1.643.0-win_x64.exe" and the CSPa24.dll included is 64-bit as expected.

yes, internal private apache webserver (PWS), the embedded one coming with the IRIS installation is still 32-bit on windows x64.

"CSPGateway-2018.1.1.643.0-win_x64"  kit should contain 64-bit CSPGateway binarys/dlls.

You can check bitness/architecture of your apache with the command: >httpd -V

Bitness of apache and CSPGateway binarys *must* match!

There is an alternative to dumpbin in order to check bitness of CSPGateway binarys/dlls which IMHO is easier:

Open executable or dll in editor (notepad, notepad++), check the first printable characters *after* the first occurrence of "PE".

This part is most likely to be surrounded by at least some whitespace (could be a lot of it), so it can be easily done visually.




PE  d†