I've previously logged this issue #1 at https://github.com/intersystems-community/openexchange/issues/1
- Log in to post comments
I've previously logged this issue #1 at https://github.com/intersystems-community/openexchange/issues/1
Here's one way, which uses $JUSTIFY to add leading spaces, then $TRANSLATE to convert these to zeroes:
USER>s number=1
USER>w $tr($j(number,4)," ","0")
0001
USER>I don't hold out much hope of EMS reappearing - see https://community.intersystems.com/post/what-current-status-enterprise-manager
I don't believe it's possible for the CACHESYS database (the one that sits behind the %SYS namespace) to be added to the mirror, because each member of the mirror needs to store instance-specific data there.
I've seen sites write their own scripts to export users, roles etc periodically from the master instance into files and import them into the other(s). For example, the Export method of Security.Users
But it's long puzzled me that InterSystems doesn't seem to have done this job for us all. Or perhaps they have, and I haven't yet heard about it.
Daniel, if your team benefits from working in a shared namespace but you'd still like source control, please consider using Deltanji from George James Software. This is a powerful and mature tool which runs natively within Caché / Ensemble / IRIS environments and integrates with Atelier, Studio and Portal editors. It is extensively used around the world, including at NHS sites.
A couple of years after my original post, we at George James Software got inspired to have another look at Visual Studio Code. And at Global Summit this week we premiered our upcoming extensions.
You can watch a video of my flash talk here.
https://youtu.be/1146vFuHoI8?t=1263
If you want to be notified when it is available please email your request to info@georgejames.com
How about using the Export and Import methods of Security.Applications ?
Answering my own question. It looks like /multicompile=0 does the trick.
When the Terminal shortcut connects to your local Cache instance it does so directly and doesn't use telnet. The presence of TRM in the window title confirms that you're connecting that way, so you're not using the telnet service.
Since you're able to use Portal, please go to System Administration > Security > Auditing. If auditing isn't already turned on, do that, then repeat the failed connect. Back in Portal use the audit viewer to see if there are any clues.
In Portal's Security section, check that your %Service_Console service is enabled.
What authentication methods does it accept?
The fact that your Terminal doesn't prompt for Username makes me think the service doesn't allow Unauthenticated. That's fair enough. But given that you used to be able to connect and now you can't, it looks like something changed on the config or the status of this Cache instance.
I'm guessing you're doing this on Windows, and using the "Terminal" option from the popup menu from a Cache "cube" in your system tray.
Is the cube blue? Or grey? Blue represents a locally-running instance of Cache, which is commonly how Windows folk have things, particularly when evaluating.
When you launch Terminal from your cube, what does the titlebar of the window say? It might mention Telnet, in which case you've somehow configured your cube to be connecting over telnet. When running on Windows, it's the Cache server that's responsible for operating the telnet service. Though if this isn't running you wouldn't get "Access denied", but instead a connection failure.
Please give us more information about your situation and I'm confident we'll be able to help you.
Building off the comment by @Thomas Granger about this perhaps being a permissions issue, I suggest you check out this previous DC article by me:
https://community.intersystems.com/post/who-does-windows-think-i-am
@sansa stark - seeing that you have posted 3 DC questions about LDAP in the past ten days I strongly recommend that you contact WRC (i.e. InterSystems Support) so that they can work with you interactively on your problem(s).
@Abbad Minhas I guess you have seen the 1.3 release announcement
I don't see anything in that to give you hope re HL7 and LUT support, but I'll be happy to be proved wrong.
Disappointing, but in the light of this announcement I can't say I'm surprised.
An alternative to deleting LNWDeploy.RoutingRules.Utility would be to amend it so it no longer extends Ens.Rule.FunctionSet. Doing this should make it invisible to the rule compiler, allowing your other class's methods to be detected.
Maybe also open a WRC ticket about your issue.
When the rule gets compiled, the GetFunctionSet classmethod of Ens.Rule.Utils enumerates all classmethods of Ens.Rule.FunctionSet and of all its subclasses in the namespace. The first occurrence of a classmethod name is recorded, and the class in which it's found is going to be the one that the compiler uses when it generates the rule's class code.
In your case SendToEaling is first found in LNWDeploy.RoutingRules.Utility rather than in LNWTIEPackage.RoutingRules.Utility (which collates later).
Per your comment, I think you'll need to specify the full reference to your function, i.e.
##class(LNWTIEPackage.RoutingRules.Utility).SendToEaling(HL7)
Update: so far I haven't found a way of explicitly indicating which class you want your custom utility function to be called in.
Have you watched the recording of the recent webinar?
https://community.intersystems.com/post/webinar-june-21-active-directory-integration-ldap
Did you consult the Cache documentation?
Gevorg, I'm only seeing a corrected title. The body of the post still makes two references to namespace:

A couple more comments:
Be aware that this code sample changes the password of every user, including the CSPSystem account used by your CSP-enabled your web servers, including the private Apache instance that hosts the browser-based admin of your server. Changing that password may prevent you using Portal until you have made the corresponding change via the Web Gateway Management page.
Here's a somewhat contrived case where that technique fails:
USER>s weirdlist=$lb("Very "_$lb($c(0))_" odd data",$c(0),2)
USER>s replaced=$replace(weirdlist,$lb($c(0)),$lb())
USER>zw weirdlist
weirdlist=$lb("Very "_$c(3,1,0)_" odd data",$c(0),2)
USER>zw replaced
replaced=$c(19,1)_"Very "_$c(1)_" odd data"_$c(1,3,4,2)
USER>The rules about indirection in ObjectScript can be a bit tricky to comprehend. Your last line is syntactically invalid.
Use this instead:
S @("C="_B)I second Jon's point about how the SET (v1,v2)=initialValue syntax makes clear to the reader that v1 and v2 begin with the same value.
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.