I'm not clear what Tomcat has to do with your attempts to use Atelier. Atelier connects to Cache / Ensemble / HealthShare / IRIS servers, typically via the same webserver you use when managing those servers through InterSystems' Management Portal. This could be the private Apache instance that InterSystems installs by default, and which by default runs on port 57772.
I can get that error message from Atelier's connection setup dialog if I intentionally point to a web server that doesn't offer the /api/atelier REST interface to a Cache/Ensemble 2016.2+ server
From your original posting it's not clear to me that you're connecting to a suitable web server.
No sign yet of the updated release notes in the downloadable zip.
Did you consider creating a Studio Project containing everything you need? Then you can export the project to XML in a way that includes all the members of the project as well as the project definition.
It's also worth knowing that if you go to the Namespace tab of the Workspace pane, then expand Classes, you can right-click on a package and add the package to your current project. This may be better that adding individual classes to your project, because by adding the package you ensure that any classes added later to the package will be exported too.
It looks like this class is intended to be created in the %SYS namespace so it can use the Security.System class.
Also, be aware that classes you create in %SYS typically don't survive a Cache / Ensemble / HealthShare upgrade.
This section of the 2017.1.2 release notes looks relevant. I guess the problem occurs for all server-side source control classes, not just the Deltanji one
Category: DeepSee.User Interface
Platforms: AllDevKey: DTB633Version: 2017.1.2Summary: Ensure widgets can be edited when namespace uses source controlDescription:If source control is enabled in a namespace, privileged users could not edit dashboards. This change corrects this problem.
Dave, please tell us which bit(s) of the documentation you're referencing. Ideally, hyperlink to the copy rooted at https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls
What version(s) of Ensemble / HealthShare suffer from this bug? In what version did it get fixed?
Could you use the SQL Gateway feature to make your tables accessible there?
Your SetPersistentValue calls refer to LastModified, but your query refers to LastUpdated. Is this a typo in your post?
If you use Portal (Explorer, SQL) to run a query that reports LastUpdated values, what do they look like? More technically, what datatype are they?
You can create a Studio project interactively from within Studio. There are a few hints in the Studio doc here.
Or if you want to create/amend Studio projects programmatically, use the %Studio.Project class.
Not a direct answer to your question, but did you consider using the Size query of the %SYS.GlobalQuery class, as shown by this DC comment from @David Loveluck on another DC post?
https://community.intersystems.com/post/database-table-size#comment-12401
Though it now seems that 1.3 is the end of the Atelier road, right?
There's a table at http://georgejames.com/deltanjiEditions
The free Solo edition is intended for, well, solo situations, with one developer wanting straightforward checkout/checkin source versioning for their namespaces on their local Cache / Ensemble instance.
In your context the Team or Enterprise editions are more likely to be appropriate, particularly since the comparison table shows LUTs not being supported by Solo.
Deltanji is capable of a lot more than simple code versioning. Please contact me via the George James Software website if you'd like to evaluate Team or Enterprise editions, or if the capabilities of the Deploy edition are of interest to you.
Since you're using Ensemble, you may also like to know that Deltanji integrates with the Portal-based editors and with Studio, as well as with Atelier. It is server-side source control, so has no problem with scenarios where multiple developers work as a team in a single namespace.
Yes, Deltanji handles LUT and HL7 components natively. And yes, it's a paid product, though there is a free Solo edition.
Manish, I highly recommend you use the normal support channel for this, i.e. contact WRC.
IMO your best chance of getting this issue addressed by InterSystems is to engage with them through WRC (Worldwide Response Center).
Maybe worth stating that in the product docs?
It worked for me (2017.2.2 on Windows):
C:\InterSystems\Ens172\bin>CSESSION ENS172 < c:\s\try.script Node: TIN, Instance: ENS172 USER>zr USER> ; Test routine created by try.script file USER> w !,"This is written by INT routine ",$t(+0) USER> w !," which is created from a script injected to csession." USER>zs MyBootRoutine USER>d ^MyBootRoutine This is written by INT routine MyBootRoutine which is created from a script injected to csession. USER>; Clean up USER>zr zs MyBootRoutine USER>h C:\InterSystems\Ens172\bin>
Maybe your indented script lines (the ones to insert into the routine) aren't starting with $C(9)
Has InterSystems yet published any guidance to help existing Caché or Ensemble users move their code onto IRIS? I haven't yet found that kind of document at https://docs.intersystems.com/
Make your script create an INT routine and run it. Example try.script below. Your lines of code either begin with the TAB character or with a label followed by TAB.
zr
; Test routine created by try.script file
w !,"This is written by INT routine ",$t(+0)
w !," which is created from a script injected to csession."
zs MyBootRoutine
d ^MyBootRoutine
; Clean up
zr zs MyBootRoutine
hAnyone watching this thread may find the following answer from @Alexander.Koblov on another thread helpful.
https://community.intersystems.com/post/atelier-connection-broken-error##node-450031
Anyone watching this thread may find the following answer from @Alexander Koblov on another thread helpful.
https://community.intersystems.com/post/atelier-connection-broken-error##node-450031
Anyone watching this thread may find the following answer from @Alexander Koblov on another thread helpful.
https://community.intersystems.com/post/atelier-connection-broken-error##node-450031
Interesting! I've been suffering from the same problem, so I've just added those two lines in the hope they're a solution. Time will tell...
FWIW, my money is still on this being caused by the Linux firewall on the server not allowing incoming TCP connections to port 1972.