RELOAD=1 should work. Once the configuration is reloaded the line with RELOAD=1 will be removed automatically.
Registry functions to control Webgateway from within IRIS will work *after* the Webgateway is registered on the IRIS instance. That happens during the first/initial connection/request. It works, even if Webgateway is on a different machine/system. Please note: registry functions could be disabled in the Webgateway-Configuration. (default = enabled)

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="" xmlns:sp="" xmlns:wsap="" xmlns:wsp="" name="service">
  <cfg:service classname="[your webservice-class]">
          <sp:UsernameToken sp:IncludeToken="">

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:


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


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 don't understand why its not working in the NodeJs v0.10
What error do you get? Why using such outdated/ancient NodeJS versions?

>I need to get file from Cache Database. File stored as a FileBinaryStream in DB.  

You need to provide much more details in order for us able to help you.

See docs/class-reference here which might be helping you:

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.



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†


To let *all* (and custom) CGI-Variables coming through, you probably need to set the extra environment variables in the CSP Gateway configuration.

You can set/specify via the "Extra CGI Environment Variables" Setting in the "Application Access" section in CSP Gateway Management.

If you enter a * here, *all* CGI-Variables will be sent/tranmitted and provided to Caché-Server-Side in the %request.CgiEnvs multidimensional property.