I would suggest enabling the Caché SOAP log to capture inbound, outbound, and security information - "ios" - then reproducing the error. (Be sure to disable the SOAP log by killing the ^ISCSOAP global when you are done.) This will print the error message in a more readable format, show the outbound message sent by your Caché SOAP client, etc.

If you are having trouble understanding the data in the SOAP log I would suggest opening a new case with the InterSystems Support staff, either by calling into +1 617-621-0700 or emailing support@intersystems.com.

This is a setting of any EnsLib.File.PassthroughService, found in the Additional Settings section:

The different options in the drop-down are described in the documentation that Marc linked to (here).

The two most common problems when we see behavior like this are:

  1. An unsupported version of Eclipse is installed - Eclipse Photon is the only supported version for Atelier. You can check your Eclipse version by going to the "About Eclipse" menu.
  2. An unsupported version of Java is installed - Java 8 is the only supported version for Atelier. You can check your Java version by entering "java -version" in an OS command prompt.

If you are still having trouble feel free to comment here in the Developer Community, or open a new WRC case (by emailing support@intersystems.com) to investigate with InterSystems Support.

Dave is working with InterSystems Support on this one. An update on the investigation:

This error is thrown when trying to import a file that is not UTF-8 encoded. Starting with Atelier 1.3.144 (the current beta version), the error message in this case is clearer:

com.intersystems.atelier.utils.CheckedExceptionWrapper: Failed to decode as UTF-8

Atelier requires that all files not stored as globals on the server be in UTF-8 format. Examples include HTML, CSS, TXT, and JS. So the solutions are either to convert files to UTF-8 encoding so that they can be synchronized using Atelier, or to modify the files directly on the file system.

It looks like Visual Studio Team Services (VSTS) is now Azure DevOps. There is an associated plugin for Eclipse called Visual Studio Team Explorer Everywhere (TEE). However Microsoft only supports that plugin for Eclipse 4.2 (Juno) - 4.6 (Neon). There is a note about this in the Microsoft Azure documentation here. Unfortunately this does not match up with the Atelier requirement of Eclipse 4.8 (Photon).

You may just be able to use a generic Git plugin, like EGit, since it seems like TEE is Git-based.


As far as your numbered questions go:

1. In general the best practice for storing code from an InterSystems product in source control is to use the UDL format rather than XML. UDL is the more human-readable format which is used for the local copies of files in Atelier projects. You can use the $SYSTEM.OBJ.ExportUDL() class method to export classes and routines in the UDL format from your Cache server.

2 & 3. I'm going to let other developers in the Community speak on their experience here. InterSystems does not provide tooling or our own published best practices for this, but rather suggests following industry standards + what works best for your organization specifically.

This has not been implemented Atelier. It is on the roadmap for the dev team. Since active Atelier development is on hold there is no timeline for implementation of this feature.

My understanding is that the BPL and DTL graphical editors in Atelier always use Eclipse's internal browser. It may be that your IE 11 browser is running in compatibility mode when embedded in Eclipse. Within the internal browser in Eclipse you can right click and select "View source". You may see something like this at the top:

<meta http-equiv="X-UA-Compatible" content="IE=9" />

You can find more information about Eclipse's internal browser and use of the X-UA-Compatible meta tag here. Can you send the contents of this <meta> line on your system?


It also may help to check the User-Agent header sent by the internal browser to the server. To find that:

  1. In a Caché Terminal enter the commands:
    kill ^%ISCLOG
    set ^%ISCLOG = 3
  2. Open a BPL or DTL in Atelier and switch to the graphical view
  3. Enter this command in Terminal:
    set ^%ISCLOG = 0

When you look at the ^%ISCLOG global there will be a $LISTBUILD like:

^%ISCLOG("Data",640,0) = $lb(900,,0,5628773246,"A"_$c(151,27)_"S"_$c(136)_"hÇ"_$c(155)_"ÙW¢·¡«"_$c(133)_"¤"_$c(148,159)_"©þÔ"_$c(20)_")5"_$c(144)_"ë"_$c(147,141)_"k"_$c(134)_"¢ë",2,"ENSDEMO","000000010000UnXM5atTr5Ar5MJaHkIPotZHaHeXwjNBDx3Mg3",,0,"","UnXM5atTr5",2,1,"/csp/ensdemo/",$lb("UnknownUser","%All","%All",64,-559038737),"","","","2019-05-14 19:52:24","2019-05-14 19:52:26","","Mozilla/5.0 (Windows NT 6.1; Win64; x64; Trident/7.0; rv:11.0) like Gecko","","",0,"","","","%iscmgtportal:6NkD8rSSEIGztlvX2WoQ0Q--",0,"",$lb("%iscmgtportal:6NkD8rSSEIGztlvX2WoQ0Q--"),"","","")

Send the User-Agent value (bolded in my example) as well.


The other option that might help is to change your system default browser. Can you test by making a different browser the default on your machine?


If none of these options do the trick it will probably be worth opening a new WRC case (by calling +1 617-621-0700 or emailing support@intersystems.com). That way an advisor can take a look at additional system-specific information.

Hi Martin, thanks for the additional explanation. I was able to reproduce this on my system with custom variables defined in a %ZLANGV routine. I will report this internally to the development team.

In the meantime, the workaround I came up with was to set a local variable equal to the $z custom variable then work with that local variable instead. For example this did not throw any syntax errors on my Atelier client:

    set var = $zsomething

    write var.Property

    do var.Method()

I'm not sure whether you are seeing this when writing new code, where this should be easy enough to implement, or if you are working with an existing code base, in which case this would likely be a bigger undertaking.

I do not see this behavior when working with custom functions that return objects. So again if this is new development you could consider defining custom functions using a %ZLANGF routine instead of variables in %ZLANGV.

I haven't tested this myself but from looking at past bug reports I believe that starting with Atelier 1.2, custom variables defined in a ^%ZLANG routine should parse correctly in Atelier as long as they start with a z.  The Atelier parser is expected to accept functions and special variables that start with $Z, and commands that start with Z.

Do your custom variables start with z? Can you also send your versions of Atelier and Eclipse?