Hi Fabio,
it seems this is not working with the 1.3.2 jQM plugin. It works with the 1.4.3 jQM plugin, so please switch over.
I also would suggest you to do
var view = zen('mainView');
view.disableItem('button',true);
in onloadHandler() instead of onPageShow()
Regards,
Bernd
This is solution using class/package mappings.
Another alternative would be only using global mappings.
So if ABC is your centralized application/code namespace/db, you can create XYZ namespace/db which by default is pointing to your central application ABC db (routines and globals) BUT with global mappings added to (own) separated XYZ namespace/db. To ensure your data is separated.
You only need a login dispatcher (csp-app) in front which in the login process will route/redirect the csp-process to be run in approperiate destination namespace via url, e.g. /app/login.cls -> /app/xyz/...
No need to remap js-files, etc. on webserver config, etc. with that since /app/xyz csp-app is physically pointing to your central location.
You can add as many "clients" like XYZ through this, all working with the same base/central application-code but with separated (or common data) depending on your global-mapping definitions.
Making a CSP Page the Home Page for the Web Server:
despite it is documented, please try to enter the IIS default document name without the preceded /
it should be : csp/samples/menu.csp
HTH, please let us know.
great article Stefan. 
Opens various possibilitys.
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.
Nice article, good job Michael. I guess order by LastName needs another approach!? THX, Bernd
since via the private webserver it is working i don't think this (/api/atelier = disabled) is causing the issue.
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
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.
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?
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.
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,
Bernd
see here: "Registering Additional File Types with CSP" and "Mapping the CSP File Extensions" right before.
http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY…
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
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 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 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
yes, thanks for the hint. I've reported a internal JIRA for our documentation team in order to correct it.
Thank you,
Bernd
if you look in the following article i've posted today,
there is a code example of a similar utils.Http:getJSON() method included.
Thank you Dan :)
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é.
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.
open declaration for/on routines will be included/fixed in upcoming v1.2. Stay tuned.
do you already have called
What is the result?
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
as an alternative, you also can use apache pdfbox. See here for example:
https://dzone.com/articles/apache-pdfbox-command-line-tools-no-java-coding-re
Hi Steve, what you're missing? This is "Using Node.js with Caché" and includes the available API's. Connection options and parameters are described here as well.
Cheers,
Bernd
just to clarify:
Caché cube unfortunately does notsupport 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-a…
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 David,
you have to use IRIS() (all uppercase).
There is a typo in the documentation we will correct soon.
Regards,
Bernd
Hi Jiri,
we have done some recent changes to make this working without the need of configuring a redirection.
Please drop me a note if you are interested or contact WRC and i will investigate more details on this for you.
Kind regards,
Bernd
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.
x86:
PE L
x64:
PE d†
HTH,
Bernd
i just tried and installed from kit-file "CSPGateway-2018.1.1.643.0-win_x64.exe" and the CSPa24.dll included is 64-bit as expected.