User Answers

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

Hi,
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.

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.

HTH,

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:

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.

if we can not allocate a license for a REST call/request we report a "503 Service unavailable" error by default.

Please note: Studio, Terminal and SMP allocates a license-slot. Every unauthenticated REST request will retain a license-slot for at least 10 sec. after request is finished.

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.

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}