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

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,
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?

i am using curl with basic-auth and this seems to work for me:

Every request results in new session. The same for logout request.

I assume that the client browser remains the first http-basic-auth credentials and reusing it for the second (logout) request as well.

If i skip the basic-auth in curl request for the logout i will get 401 Unauthorized which is expected.

HTH,
Bernd

on Unix and Windows you can use PIPES:

s prog="whoami",oldIO=$IO open prog:"QR" use prog read result c prog use oldIO w !,result

if you already have pcl documents available, then probably using 3rd party pcl to pdf converter command-line tool would be the easiest solution for you. You can use $ZF(-1, <oscommand>) call-out from within COS to invoke conversion process.

(for example: VeryPDF PCL Converter, etc.)

HTH,
Bernd

Hi Peter,
this is very specific issue and hard to say with the information you've provided so far.
Are you sure this is related to Zen/Caché/CSPGateway and not a client-browser issue?

We need more information on this for a further investigation.

What changes are made that makes it stop working?

What client-browser/version you are using, what Caché version on server?

I assume you are using an "old" IE version, right?

The navigation to the #2 page called from #1 does work and loaded correctly?
Only the DXImageTransform did not work as expected in that case?
Calling #2 directly makes it working?

Did you try using IE-Developer-Tools (F12) to inspect and compare page-source and component loadings of both?
Any errors in the console, etc.?

Maybe it's better for you to report this in the WRC, so that support can continue with you on this!?

Regards,
Bernd

Steve,

starting with ZM 1.1.1 the "event" object is now passed to all event-handlers (unselect/onevent/onchange) as the optional last argument. User could now make use of it in their template client methods if needed (e.x. handle propagation-related issues, etc.)

This is missing in the documentation so far but is already addressed to be added shortly.

HTH,

Bernd

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.

 

Making a CSP Page the Home Page for the Web Server:

http://docs.intersystems.com/cache20152/csp/docbook/DocBook.UI.Page.cls?KEY=GCGI_oper_config#GCGI_home

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.