Hi,
i guess you need to add a wildcard * mapping handler to webserver /cspgateway configuration to pass extension-less requests to the caché-server as well. What webserver are you using? IIS or apache?

Yes, you can get the name/value params from the url by %request.Get("paramname") for example, but using query params at all is against good principles of REST.

this is great news, Jeffrey. I am glad you got it working.

Yes, this is rest api, the trailing slash in url IS important :)

Bernd

since via the private webserver it is working i don't think this (/api/atelier = disabled) is causing the issue.

Hi Jeffrey,

it seems this is a specific configuration issue which needs a more deeper look. (further logging, etc.)

I would suggest you to contact WRC support so that we can continue investigation.

Thanks and Regards,
Bernd

Hi,
ssl/tls (https) support for the atelier connections is planned for Atelier 1.1

It should work via external webserver too.

Did you get a response from http://<webserverip>:<port>/api/atelier/ in browser? (or postman, arc, etc.)

What version of Caché/HS you are running on server? (> write $ZV)

HTH,
Bernd

Nice article, good job Michael.
I guess order by LastName needs another approach!?
THX, Bernd

Troubleshoot #2

I just recently had a case on a customer site where their SAPJCo interface stopped working after the production or system gets restarted. This always results in the following error:

ERROR#5023: Java-Gateway-Error: java.lang.ClassNotFoundException ...

In order to make this working again, the sapjco3.jar and BAPI's always needs to imported/generated again.

The reason for this was, that using the SAPJCo installation/import webpage is setting and using the Class Path from the jar file during the import, but restarting production or system makes the production/service forget about it.

Solution: What's missing here is that in the EnsLib.JavaGateway.Service of the production the "Class Path" needs to be specified in the "additional settings" as well to the full-path reference to the sapjco3.jar.

With that setup in place, production and system could now be restarted without affecting the SAPJCo interface.