New post
AllAccepted answers
Tomas Vaverka · Sep 25, 2018

The main cause of the problem is that you are not connecting to Terminal but Telnet.

If you connect to defined Server connection which name is different then the installed instance for given Cube, it starts Telnet and not Terminal - you can see it from the name of the window. Name for Terminal is  TRM:<process id> (<instance name>) while for Telnet the name is <IP address> - Caché Telnet.

For Windows systems you need to enable Telnet on port 23 (as defined by your Caché Server Manager) to be able to connect.

To enable Telnet you need to open Management Portal and go to System Administration > Security > Services > %Service Telnet, check the Enabled checkbox and save.

To change the Telnet port from default 23 you go to Management Portal > System Administration > Configuration > Device Settings > Telnet Settings.

Tomas Vaverka · Sep 21, 2018

It looks you are accessing webservice on internal InterSystems  site, are you an ISC employee?

Anyway, this is an error generated and sent by external webservice you try to call. It happens during processing of the SOAP request on the external webservice, you cannot fix it. So you should discuss it with author/provider of this webservice.

Tomas Vaverka · Jul 30, 2018

If you want to try to disable checking of the order of elements in XML, you can also change parameter XMLSEQUENCE in given class

Parameter XMLSEQUENCE = 0;

But it can have another side effects - like the one from XMLSEQUENCE parameter description:

If the XMLSEQUENCE = 1, then the order of the XML elements must match the order of the class properties. This allows us to deal with XML where the same field appears multiple times and is distinguished by the order.

So I would prefer to check if XML of given SOAP request comply to  WSDL of your web service and change it if not.

Tomas Vaverka · May 3, 2018

Please, could you also post values of given variables pstrNamespace, pstrGlobalName, pstrOutputPath? What OS/Caché version it is?
Try to also use "d" parameter instead of "-d" and check the status returned by method:

  Set sc = ##class(%Library.Global).Export(pstrNamespace, pstrGlobalName, pstrOutputPath,,,"-d")
  Do $system.OBJ.DIsplayError(sc)

It should return more information about the error.

Generally it tries to use device (file?) which was not opened, given line in version 2017.2.1 is:
    Xecute code Quit:'$t 0 Use dev Quit 1

Tomas Vaverka · Apr 4, 2018

Hi,

This message in cconsole.log is a warning that you have enabled Caché SOAP log (^ISCSOAP global) in given namespace. It can generate a lot of data and create a big file, therefore there is a danger it can fill-up your disk. 

Caché SOAP log shouldn't be enabled for long time, its meaning is only for debugging purposes - e.g. investigation of some SOAP issue.

More about ISCSOAP log can be found in Caché Documentation
http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GSOAP_debug_info_soap_log

Tomas Vaverka · Apr 3, 2018

The collation 20 is Portuguese2.

USER>zn "%SYS"
%SYS>Do ^COLLATE
Status       Number   Abbrev   Name
----------   ------   ------   ----------------------
Built-in        0     OANS     ISM Pre-6.2
Built-in        1     ANSI     ISM 6.2->6.4
Built-in        2     COBR     Ipsum/Cobra
Built-in        3     DTMC     DTM-compatible
Built-in        4     CBR2     Ipsum/Cobra-2
Built-in        5     UNIC     Cache standard
Not loaded     10     GER1     German1
Not loaded     11     POR1     Portuguese1
Not loaded     12     POL1     Polish1
Not loaded     13     GER2     German2
Not loaded     14     SPA1     Spanish1
Not loaded     15     DAN1     Danish1
Not loaded     16     CYR1     Cyrillic1
Not loaded     17     GRE1     Greek1
Available      18     CZE1     Czech1
Available      19     CZE2     Czech2
Not loaded     20     POR2     Portuguese2

To be able to mount database with such collation, you need to install Portuguese NLS locale to Caché (Management Portal > System Administration > Configuration > National Language Settings >  Locale Definitions). 

If you need further help, please contact InterSystems Worldwide Response Center (WRC).

Tomas Vaverka · Mar 26, 2018

The issue is that following method:

d ##class(%ZEN.Auxiliary.jsonProvider).%ObjectToJSON(soapresponse,.result,,"s")

doesn't set variable result, but only writes out the contents of object instance soapresponse  to the current device using JSON notation, as you can find in %ZEN.Auxiliary.jsonProvider class documentation.

To output the content in JSON format I would recommend to use %DynamicObject and its %ToJSON() method:

/// return json
Method infoJson() As %String [ WebMethod ]
{
    set soapresponse=##class(%DynamicObject).%New()
    set soapresponse.CustomerID="1"
    set soapresponse.Name="2"
    set soapresponse.Street="3"
    set soapresponse.City="4"
    set soapresponse.State="5"
    set soapresponse.Zip="6"
    s resultinfo=soapresponse.%ToJSON()
    q resultinfo
}

It should help to retrieve JSON string.

Tomas Vaverka · Mar 20, 2018

For pre-flight request (OPTIONS):

The problem is caused by the way how the OPTIONS request is handled. According to documentation, OPTIONS request doesn't need the authorization even if the CSP application requires it. But the CSP process still needs to access given REST class to get response for OPTIONS request. The problem is that given process is run under the user which logs from CSP Gateway to Caché - this is set in CSP Gateway Management page > Server Access.

If given user doesn't have right to access given namespace/database, it gets the <PROTECT> error on server and the CSP sends back the HTTP 404 error.

The solution is to add role to given CSP Gateway user with minimum READ access to corresponding database.