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,

to clarify. You have 3 possibilities:
- mg-dbx is a 3rd party product/connector (similar cache<nnnn>.node, iris<nnnn>.node, see next)
- cache<nnnn>.node, iris<nnnn>.node is InterSystems "legacy" node.js adaptor/connector. I don't know how long we will support it in future.
- Native API for node.js. This is InterSystems latest node.js API, recommended for new developments.
  See here: https://docs.intersystems.com/irislatest/csp/docbook/Doc.View.cls?KEY=PA...

Hi Marco,
if you are a supported customer you should have access to WRC online and ask for it. We will deliver it on demand depending on what you need.
If you don't have an active WRC account, write an email to support@intersystems.com and our FRC can clarify and create one for you.


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')


for tcp connection mode you need to specify superserver-port, not webserver port.