Yone, try to set ContentCharset AFTER setting of  ContentType:

 set httpRequest.ContentType "application/json"
 
set httpRequest.ContentCharset "UTF-8"
 

This is from %Net.HttpRequest class documentation:

property ContentCharset as %String [ Calculated ];

This is the charset to encode the contents with. This is actually specified in the HTTP Content-Type header with something like:

Content-Type: text/html; charset=UTF-8

You must set this property after you set the ContentType or it will overwrite this value.

Will it change anything?

Could you please provide more details? Are you creating SOAP WebService in Caché and want to return stream data? Or is it a SOAP client connecting to some external webservice?

Generally for WebService you define return type as %Stream.GlobalCharacter,  then create and fill the stream object and that's it.

Example of web method returning stream data:

Method GetStream(text As %String) As %Stream.GlobalCharacter [ WebMethod ]
{
 set stream=##class(%Stream.GlobalCharacter).%New()
 Do stream.WriteLine("First Line")
 Do stream.WriteLine("Second Line")
 Do stream.WriteLine("Last Line with Text: "_text)
 Quit stream
}
Is this what you are looking for?

I think the solution is to use character stream and made manual Base64Encoding/Decoding.

I have created two methods for it:

/// Flags - 0 - Insert CR/LF after every 76 characters (Default)<br>
/// Flags - 1 - Do not insert CR/LF after every 76 characters.<br>
ClassMethod Base64Encode(tIn As %Stream.TmpBinary, Output tOut As %Stream.TmpCharacter, chunk As %Integer = 32000, Flags As %Integer = 1) As %Status
{
   set sc = $$$OK
   if $g(tIn)="" quit $$$ERROR(5001, "Input stream required")
   if '$IsObject(tIn) quit $$$ERROR(5001,"Input is not a stream object")
   if 'tIn.%IsA("%Stream.Object") quit $$$ERROR(5001,"Input object is not a stream")
   If '$IsObject($g(tOut)) {
    set tOut=##class(%Stream.TmpCharacter).%New()
   }
   if 'tOut.%IsA("%Stream.Object") quit $$$ERROR(5001,"Output object is not a stream")
   set chunk=chunk-(chunk#3)
   do tIn.Rewind()
   While 'tIn.AtEnd {
    set sc= tOut.Write($SYSTEM.Encryption.Base64Encode(tIn.Read(chunk),Flags))
    if 'sc Quit
   }
   Quit sc
}

ClassMethod Base64Decode(tIn As %Stream.TmpBinary, Output tOut As %Stream.TmpCharacter, chunk As %Integer = 32000) As %Status
{
   set sc = $$$OK
   if $g(tIn)="" quit $$$ERROR(5001,"Input stream required")
   if '$IsObject(tIn) quit $$$ERROR(5001,"Input is not a stream object")
   if 'tIn.%IsA("%Stream.Object") quit $$$ERROR(5001,"Input object is not a stream")
   If '$IsObject($g(tOut)) {
    set tOut=##class(%Stream.TmpCharacter).%New()
   }
   if 'tOut.%IsA("%Stream.Object") quit $$$ERROR(5001,"Output object is not a stream")
   set chunk=chunk-(chunk#4)
   do tIn.Rewind()
   While 'tIn.AtEnd {
    set sc= tOut.Write($SYSTEM.Encryption.Base64Decode(tIn.Read(chunk)))
    if 'sc Quit
   }
   Quit sc
}
 

Then in the code you need to call it e.g.:

  set sc = ..Base64Encode(tPDF,tDocRequest.FileContent,,1)
               

where 'tPDF' is a stream object with original PDF content, tDocRequest.FileContent then will contain given PDF encoded to Base64 - this is what binary streams do automatically.

This is not version nor index, it is part of the routine name. Each class compiles at the routines. There is always <classname>.0 routine with class descriptor (always only as .OBJ code), where it holds the information what code it should run for particular property/method.

It then generates number of routines with generated code. For most classes there is only one - <classname>.1

If incremental compile is detected, it does not recreate <classname>.1 routine but creates a new routine <classname>.2 with the new code and updates the class descriptor to reflect it.

This is a absolute path to your webserver.  The URLs for given css and js files are:

http://<webserver>/jbsscan/stylesheets/style.css
http://<webserver>/jbsscan/javascript/javascriptScanner.js

The location depends on the definition of the DocumentRoot in your Apache httpd.conf. E.g. for following example

DocumentRoot "c:/Apache24/htdocs"

the files should be located in following folders

C:\Apache24\htdocs\jbsscan\stylesheets\
C:\Apache24\htdocs\jbsscan\javascript\

What also matter is how CSP Gateway in Apache is set. E.g. Caché Private Apache webserver is set to serve all files from Caché (directive CSP On), therefore it is served by Caché server and depends on settings of corresponding CSP application on Caché server side.

Hi, there is also archive of older checklist available in same documentation, so you can check what changed since version 2013.1 and if it affects your application - https://docs.intersystems.com/cache20172/csp/docbook/DocBook.UI.Page.cls...

What I see as a problem is the Caché version you mentioned - 2017.2.2 (Build 865U_SU) is SingleUser version, available as download for evaluation purposes. It is not meant for development/production purposes. It also doesn't allow to enter a Caché license key, it has built-in license with single user there.

So I would recommend to contact your InterSystems Sales Rep. or WRC to get the full installation kit for Caché 2017.2.2.

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.

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.

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.

Please, could you also post values of given variables pstrNamespacepstrGlobalNamepstrOutputPath? 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

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

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.