just to clarify:

Caché cube unfortunately does not support opening web-ressources by https directly so far. (currently only http fix)

Special version of ServerManager.exe does not help to solve this issue. It's for the "old" way of doing ssl/tls client configurations, which is not recommended for recent versions of Caché anymore.

See here Katherine's great article on the new way of configuring client application for ssl/tls :

https://community.intersystems.com/post/configuring-cach%C3%A9-client-ap...

A workaround to solve this issue with the Cube is to setup http to https redirection on the webserver level as already mentioned here by Eduard as well.

Regards,
Bernd

Hi,
underscore in method names are *not* supported and possible, I am afraid.

Besides the SoapAction already mentioned by Eduard you can try if adjusting the SoapMessageName and SoapRequestMessage keywords
at the method level in your WebService are helping to get what you want.

Here is an example:

Method AddInteger(Arg1 As %Integer = 0, Arg2 As %Integer = 0) As %Integer [ SoapAction = Add_Integer, SoapMessageName = Add_Integer_Response, SoapRequestMessage = Add_Integer, WebMethod ]
{
  Quit Arg1 + Arg2
}

HTH,

Bernd

if i remember correctly you do not need to create a custom tag in order to use your customer version of the lookup-class. You can use the default CSP:search tag and provide your modified custom lookup-class by the "searchpage" attribute.

<csp:Search name="FindPerson"
    searchpage="%ZCSP.PageLookup.cls?SEARCH&..."
    onselect="onFindCustomer"
    classname="Sample.Person"
    ...

on my surface book win10-x64, in a test using a simple (non-time-intensive) math-function/calculation (atan2(x,y)) in Node.js returning back the result, it turns out that callouts by REST are ~100 times faster than callouts by a command-pipe/$ZF(-1), due to the overhead of creating a child process for each callout every time.

Eduard, this was for a windows-platform only. I couldn't find a suitable windows command line tool for *raw* deflate/inflate compression/decompression, so i wrote my own, knowing that Node provides a built-in zlib module.
Please note that zlib, etc. or compression/decompression is not what this article is about in the first place.
I only have chosen this as an example of a function not directly available (by native) in Caché.
Maybe you're right and this is probably not the ideal function/example,  but the article is meant more about the mechanism and way/practice
and on how to use a REST callout in general as an alternative way (instead of using a shell/command callout) making Node modules and their capabilities available from within Caché.

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.

HTH,
Bernd

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.

Regards,
Bernd

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

Parameter SOAPACTIONQUOTED=1;

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.

HTH,
Bernd

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 )

HTH,
Bernd

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)

${#CacheVersion}


HTH,
Bernd