i would start using "postman" to try out google restful api for your particular needs. To see what exactly you need to sent (request) and what you get in return (response). With that in place you can start coding some kind of wrapper methods using %Net.HttpRequest for doing the same requests and preparing the appropriate results from the response for your further processing, as you've already figured out before by using postman.

HTH, Bernd

Hi Soufiane,
as you can see in the GetAccessTokenFromRequest() method, the access token is taken from the http authorization bearer header or from the encoded entity body's access_token parameter.  As described in RFC6750, see here: https://tools.ietf.org/html/rfc6750

Your client need to send that way. Not within the url as a name/value param.

On resource server side you then need to continue with this, see section "Code Requirements" here: http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GOAUTH_resource

Be also aware on the prerequisites and code requirements also.


yes, thanks for the hint. I've reported a internal JIRA for our documentation team in order to correct it.

Thank you,

Hi Maarten,
sorry for the late reply.

What versions of Caché/Ensemble and CSPGateway/webserver's you are using?
Is there a Load-Balancing configured in between?
Is the websocket-connection using same web-app-path than csp-page?
Is it reproducible? How often does it happen? When does it occur? On first/initial websocket-connection or sometime changing in between?
Why is that causing you a problem?

It's very hard to say more with that limited information you've provided so far.
I would suggest you to contact WRC online since i believe this needs a deeper look and investigation.


Hi Tom,
the Cache SOAP log does not show HTTP headers.  To see the SOAPAction header sent out by Cache-SOAP-Client you need to use something like tcpTrace, etc.

However, can you please try if it make a difference if you use


in your soap-webclient?

If the web client has the parameter SOAPACTIONQUOTED=1, then the web client will quote the
SOAPAction value for SOAP 1.1.

If that does not help i would suggest you to contact WRC to open a WRC-ticket since this probably needs a more detailed review and deeper investigation.


Hi Tom,
please look at the documentation link you've found in more detail.

You need to specify logfile as well. Log will not be written in global, it will be written in file, for example:

>Set ^ISCSOAP("Log")="io"

>Set ^ISCSOAP("LogFile") ="c:\temp\iscsoap.txt"

The SOAP-Log needs to be set per namespace, so it will be only active for that namespace.
Please also don't forget to disable SOAP-Log when you're done with you testings/debuggings. ( >K ^ISCSOAP )


Hi James,
it seems you are correct, direct marco evaluation is not yet supported.

As a workaround, you can define class-parameters for the $$$ macros you wanna use in your installer/manifest class:

Parameter CacheVersion = {$$$CacheVersion};

which then can be referenced in XDATA manifest that way: (parameter expression)



Hi Sebastian,
you can request the SMP login page (etc.) from time to time by https or http to see what is working.
Let me know if that is what you are asking for. Feel free to open a WRC problem so we can discuss this further on the phone, etc.
Kind regards,

ah, you are trying with /csp/samples/docserver. Be aware that for security reasons this web-app is by default *disabled*. If you wanna use it you need to *enable* it.