Existing users of our Deltanji source code management tool, which runs natively inside Caché / Ensemble / HealthShare, may want to start using Atelier without having first to re-engineer their source control. I foresee a need for an Atelier user to be able to interact with a Deltanji dialog and then trigger a server-side action.

Was that repository URL pre-populated in your Atelier?

Maybe the response Dmitry gave to this post I created in the Atelier community will help you.

Hermain, I think yours predates the point where ISC implemented the ability to update Atelier from within Atelier. I suggest you download the latest kit and install that. Thereafter you ought to be able to update from within. But bear in mind I'm not an ISC person, so my advice might be incorrect.

Thanks Dmitry. That worked, upgrading me from 1.0.107 to 1.0.112

That's interesting to know. It means that my experiment can become:

USER>s oResult=##class(%Library.File).FileSetFunc("c:\s\","*.txt")
 
USER>while oResult.%Next() {w !,oResult.%Get("Name")}

...

And now static code analysis that detects classmethod references can spot the use of the secret FileSetFunc method within the class that implements the query I'm using.

Sounds good. Any estimate of when we'll get access to this?

Thanks for the feedback Ben.

I'm familiar with System Defaults, and we actively try and promote their use when we talk to Ensemble users about this issue. However, the way that Portal defaults to filing configuration item settings into the class means that it's all too easy to do this by accident. In contrast, to add/edit a System Defaults type of setting requires significantly more effort within the UI. Surely a better job could be done here?

I expect Prodlog 94592 already has the name of George James Software all over it, as we've been lobbying on this issue since the very beginning. While we wait, we've devised some techniques that allow Deltanji to leverage the OnConfigChange classmethod that a 2012.1+ production class can be given. You can read about them here.

John

At analysis time you can choose which packages to include. The webapp whose time-based graphical output I showed above doesn't let you filter a whole-namespace analysis to view only the stats for a single package. But the Structure101g Studio tool gives a lot more power. For example, here's a drilldown into the top-level packages:

Overall bar length is code size. The red portion is the XS of the package.

I have fixed the XS whitepaper link. Thanks for reporting that. 

I'm not advocating making your live environment the first one you upgrade. Upgrade a QA environment initially, and do enough testing there to be confident that your app works.

I take your point about keeping up with the technology curve, but it's no good the next release of your app using all the whizzy new features of the latest Caché version if you're not able to deploy it to your customers until they can be coaxed to upgrade. Yes, you can use the new features as a carrot to entice them to upgrade, but meanwhile you probably have support commitments to them that mean occasionally patching the app release they're currently using.

That's certainly a useful tip. I wonder if it would have helped in a situation we assisted an Ensemble site with last year. They'd upgraded their DEV and QA environments from 2013.1 to 2015.1 but their LIVE was still on 2013.1. Then they amended an HL7 schema in DEV, exported it, imported it to QA, verified it worked, and finally loaded it to LIVE, where it broke the production.

The cause turned out to be a change made in 2014.1 and documented in a bullet point here. Yes, they had been unwise not to retain a QA or pre-live staging environment on the exact Ensemble version that LIVE was running.