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.

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 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.

There are two types of errors in the sample that you sent, one of which has been corrected and one of which is being actively investigated. The workaround while this is under investigation is to use the graphical DTL editor in the System Management Portal.

ERROR #5001: attribute 'sourceclass' is not declared for element 'transform'

ERROR #5001: attribute 'sourcedoctype' is not declared for element 'transform'

ERROR #5001: attribute 'targetclass' is not declared for element 'transform'

ERROR #5001: attribute 'targetdoctype' is not declared for element 'transform'

These errors have been reported to the Atelier development team here at InterSystems and are being investigated. We do not have a timeline for the fix, but you can always reach out to the WRC to check in on the status of the internal report.

ERROR #5001: element 'assign' is not allowed for content model '(annotation?)'

This error has been corrected, starting with Ensemble 2017.2.1. If you are seeing this when compiling against later versions of the product please send us your version string (by clicking the About link in the top-left of the System Management Portal).

Hi Connor, I've been working with Michelle Stolwyk on this one and I do not think this is a large-scale issue with the stable Atelier repository. I just installed Java 8, Eclipse Photon, and Atelier 1.3.139 (from the stable repo on a fresh machine without any problems.

I think the issue on your system does boil down to a security/proxy problem. Here is an article I've used to help with this type of issue in the past:

If you are still having trouble I would suggest reaching out to InterSystems Support (by calling +1 617-621-0700 or emailing for help with your specific configuration. InterSystems will not be the authority on how to configure a proxy, Java certs, etc. But we can point you in the right direction and send some resources that our customers have used in the past.

I would suggest first checking the browser you have selected in your Eclipse settings. From the preferences page, select General > Web Browser and confirm that the expected browser is selected.

Next take a look at the settings in your IE 11 browser to check the Emulation settings. (In the F12 Developer Tools make sure that the Document Mode selected there is not 7.)

If you are still having trouble I think we'll need to look into your system-specific settings, such as the operating system, exact build of IE, etc.. That would probably be best handled by InterSystems Support.

As an aside - Atelier is supported on the Eclipse Photon release, not on the 2018-12 release. I do not necessarily think this will solve the problem you are seeing now, but we have seen this cause other problems when using the Atelier plugin. So I would suggest getting a fresh install of the Eclipse Photon client here then install Atelier on this new client.

David opened a WRC case and we are looking into the cause of this issue. I'll post the resolution here in the DC once we are done with our investigation.


Update 11/26/18: We were not able to get to the bottom of this, as David reached a point where he was unable to spend the time to investigate further.

This is not possible at the moment. But it is something that has been requested by customers before, and it is on the Atelier development roadmap!

My best guess from the description here is that the CSP application was not created properly in the Atelier Project. Currently you cannot create a new CSP application at the Atelier Project level - you need to copy the CSP app from the server. For example:

1. Create a new web application in Caché:

2. In the Atelier Server Explorer, right-click that new CSP application and copy to an Atelier Project (you may need to refresh the server connection for the new application to show up):

3. Create a new CSP page and select the newly copied CSP application:

4. The CSP page should compile as expected in the new web application:

If you would like someone to dial into your system and debug this with you, you can always contact InterSystems Support (by emailing or calling +1 617-621-0700).

Development is aware of this issue. We do not have a timeline on when it will be fixed.

If you would like to track the progress of the development change, I would suggest opening up a WRC case (email or call +1 617-621-0700). A Support advisor will be able to link the relevant development change to the WRC case then you can keep track of it using the new UX in the WRC application.