Hi John,
Out of curiosity - if you could share - what is your Plugin going to do?
Tani
- Log in to post comments
Hi John,
Out of curiosity - if you could share - what is your Plugin going to do?
Tani
Thanks Luca.
Note this is not instead of run-time monitoring and alerting.
This is intended for a one-time run (though could be iterative) at development/testing phase. In order to help plan the required disk-space (and validate proper purging). For this I thought something Ensemble-specific, as well as growth process-oriented (capture, run, capture, compare, report) was beneficial. In real-time production phase of course one would put into place the more generic core monitoring functionalities, and would have no use of this framework.
Thanks Dmitry.
Indeed the focus here was on finding the possible globals you would want to dive deeper into regarding why they are taking up relatively a lot of journal space, and thinking of ways to mitigate that.
When I get a chance I planned to follow-up with another post on ways to avoid journaling for such globals (though not always is that an option). Stay tuned...
William, following up on Stefano's last answer (and previous comments), I just wanted to add that you can consider using OS Authentication instead of leaving this open for unauthenticated access. This way you can allow only for the appropriate Windows User to run this command from the Windows command prompt.
William, for more info about using OS authentication see here from the docs. Specifically see also there a note regarding Kerberos on Windows and using Domain users. This might play better for you with your locked-down installation as OS authentication is not on by default (system-wide).
Assuming you want to use OS Authentication - you need to first make sure this on system-wide:

Then make sure it is on for the service (%Service_Console is this case):

And that you have a Caché User with the same name as the OS User (and that of course has the relevant authorization):

Then you should be able to run without having to authenticate separately to Caché.
For example opening the Terminal without getting prompted for login:

[ As opposed to the behavior without OS authentication enabled:
]
Hope this helps.
Thanks Eduard!
This looks great.
I'll let you know if we run into anything missing.
Regarding using non-journaled databases I just wanted to point out that this approach was taken by us (InterSystems) internally for certain Ensemble globals.
See this from the 2015.1 Ensemble Release Notes. For each Ensemble database another non-journaled database is created, with a naming convention of <myDatabase>ENSTEMP.
For example:

This database will hold specific data (that used to be in CACHETEMP).
Indeed the release note also mentions the mirroring implication.
This was done mainly for security considerations (as mentioned in the post above).
[Internally one can see JGM092 and JGM097 for details]
See comment to Alexey re <database>ENSTEMP databases.
I can do this Dmitry, but I am wondering why this is needed.
If this is in order to be able to copy & paste code, then in this post's case, the code pasted from terminal is either simple SETs, which have no meaning outside the context of the post's basic example, or if they are sample commands, then they appear elsewhere in the post where they can be copied from.
If there is another reason please let me know.
Thanks.
Thanks for clarifying Dmitry.
In this case, if people can't view the images then just replacing the Terminal images with text, will not be enough as their meaning and relevance is accompanied by the related Journal contents screenshots. And I don't think it makes sense to start replacing all of that with text as well. So for now I will leave this post as is. The essence anyway is written up in the body of the post, and the images are just for illustration and/or emphasis.
I will though take this into consideration and for future posts prefer text over Terminal images.
I added some functionality to register (and report) not only the global names but also the class name (using that global). Thanks Dale for the idea.
[Update is available via GitHub, link in the post above]
Here also is some sample output -
Data Usage Report
===========================
Database file size used: 1
Journal file size used: 0
Journal space used: 325108
Globals growth
----------------------
Ens.MessageBodyD .007
Ens.MessageHeaderD .02
Ens.MessageHeaderI .003
Ens.Util.LogD .004
ITest.Proxy.s0.AddressD ITest.Proxy.s0.Address.cls .004
ITest.Proxy.s0.PersonD ITest.Proxy.s0.Person.cls .003
Journal Profile
----------------------
Ens.ActiveMessage 26184
Ens.BusinessProcessD 3308
Ens.BusinessProcessI 1456
Ens.Configuration 424
Ens.JobRequest 132
Ens.JobStatus 112
Ens.MessageBodyD 19508
Ens.MessageHeaderD 34624
Ens.MessageHeaderI 89540
Ens.Queue 37996
Ens.Runtime 50920
Ens.Suspended 100
Ens.Util.LogD 10404
Ens.Util.LogI 12248
ITest.Proxy.s0.AddressD ITest.Proxy.s0.Address.cls 16096
ITest.Proxy.s0.PersonD ITest.Proxy.s0.Person.cls 8624
Globals remaining after purge
----------------------
ITest.Proxy.s0.AddressD ITest.Proxy.s0.Address.cls .004
ITest.Proxy.s0.PersonD ITest.Proxy.s0.Person.cls .003See this related post with a class that could help with auto-generating the %OnDelete method for your classes.
See this related post with a class that could help with auto-generating the %OnDelete method for your classes, that could make sure your message references to persistent classes get deleted together with the purge of the message body.
Nikita, this is really an excellent tool.
One question: The documentation states that Web Terminal is supported from version 2013.1 and up of Caché (Ensemble, etc.). But it seems (at least v4) to require functionality (e.g. %CSP.REST) that exists only in newer versions than 2013.1.
I assume older versions of Web Terminal supported 2013.1.
Could you please restate what is the minimal Caché version for v4 of Web Terminal, and what is the latest version of Web Terminal that did support Caché v2013.1.
(And perhaps update for every ("released") version of Web Terminal which is the minimal required Caché version.)
Thanks!
I thought it would be worthwhile to point out in the context of this question that we have an online course that addresses this topic:
https://learning.intersystems.com/enrol/index.php?id=34
Here's an outline of the course:
John,
It seems the link to the documentation you provided above is now broken (and yields an error page; it possibly worked in a previous version's docs).
I assume you meant this page:
http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GCNV_C176399
Thanks Alexander.
Indeed I had the Error Log view open and saw various errors - but those were to some projects I had in my workspace that connected to servers that were offline. So I ignored them.
But now you confirmed it should work on this version - I kicked off a new workspace, defined just one project to an online server, and I got to see my Add-Ins... ![]()
So unfortunately I don't know exactly what the problem was... but a new workspace solved it...
Thanks Michelle.
When I tried to use the Tools menu I was in an "Atelier element" (e.g. an Ensemble class) so I don't think that was the cause.
Just in case, I double-checked now again - I'm editing an Ensemble class and the items in the Tools menu are disabled... (in the workspace that originally gave the problem; in the newer workspace this does not happen)
Regarding Samples see also from the InterSystems IRIS documentation:
Please note that by default when a Persistent instance is %Saved()'d it gets done inside a Transaction, and therefore, even if the Database the Class' storage globals' are in, is not journaled, these SETs (and KILLs) will get journaled (for supporting rollback).
See this article for more details regarding avoiding journaling data. Specifically - the options of using CACHETEMP or turning off transactions for object filing.
Note if you are concerned with the audit logs generated for every turning off and on the journal for your process - you could simply turn off that System Audit event - %System/%System/JournalChange. Taking of course into consideration the drawback of not logging these kind of events outside the context of this specific scenario.
The issue of indexing data previously processed (before the Search Table was defined for the Business Service/Operation) is addressable by calling the BuildIndex() method of the relevant SearchTable class.
For example:
Set sc=##class(YourPackage.YourSearchTableClass).BuildIndex()Happy this helped.
In general (you might be aware of this, but for the benefit of the Community) a good resource about searching Messages (including Search Tables and SQL, and other options), is this Online Course.
What is the class name of your Web Service?
Is it also a Business Service? If so - what is the name of the BS component in the Production?
What URL are you using to access this WebService?
I have encountered this error when trying to call the WebService in a way that did not allow Ensemble to understand what is the name of the business service class it needs to use (for example by using the CfgItem URL parameter).
Hi Dmitry,
Recommending your very cool and useful utility to someone I realized I did not find installation instructions, not here in this article, nor in the GitHub readme.
Could you please point me to them, or in case they indeed do not exist currently can you please provide them, for the benefit not only of the person I'm sharing this with, but with other Community members who will want to use this in the future.
Tx!
See also using the ^SECURITY utility (for manual export vs. programmatic which is possible via the Security package classes API).
For example:
%SYS>do ^SECURITY 1) User setup 2) Role setup 3) Service setup 4) Resource setup 5) Application setup 6) Auditing setup 7) Domain setup 8) SSL configuration setup 9) Mobile phone service provider setup 10) OpenAM Identity Services setup 11) Encryption key setup 12) System parameter setup 13) X509 User setup 15) Exit Option? 2 1) Create role 2) Edit role 3) List roles 4) Detailed list roles 5) Delete role 6) Export roles 7) Import roles 8) Exit Option? 6 Export which roles? * =>
Looks great David! ![]()
I think for the "background" part this Global Summit presentation - "API Design for REST" (by @Michael Smart) could be helpful.
Regarding your question on the *.impl generated class -
if you already added code to this class and later update the swagger and consume it again - indeed the code you added will remain.
If you review the video recording of the Global Summit Solution Developer Conference session I mentioned above - you can see a live demonstration of this specific case. [I recommend you see all of it, but this particular part starts at about 33:30]
See also this related article.
If, as you mention the purpose of this logging is debugging, then I would recommend going with $$$TRACE vs. $$$LOGINFO. This will allow you to turn on and off tracing without making code changes. Whereas if you go with $$$LOGINFO it's always there unless you remove it (or comment it out), then you need to compile, and then if you need it once more...