Hi Tom,

What is the Type of the classes that you are creating - are they Serial? 

If so, this could explain the error as Serial classes cannot embed themselves (directly or indirectly).

If you can try creating Persistent classes instead of Serial let us know how that works for you.

Note - with Persistent classes, as I understand this is Ensemble, you will need to take care of deleting the various instances generated, once you purge the messages. See this Post for further details if relevant.

Hope this helps.

As I've communicated with Simcha directly, there is a built-in mechanism for this based on the Ensemble Security Audit functionality.

Enabling the '%Ensemble / %Production / ModifyConfiguration' event will yield an audit record for Ensemble Production configuration changes.

For example if you changed the "ArchivePath" setting of a Business Service called "XML In" the event would look like this in the Audit database search results:

And the event details will show this:

Note this will include not only the user that performed the change, the time and such general information, but also the:

  • Name of the Production
  • Name of the Item changed
  • Name of the Setting changed (for example)
  • Previous value (of setting)
  • New value (of setting)

Hi Uri,

Adding to what Vitaliy wrote I would like to share with you some input I got from our Development -

According to the question, there are a few situations to consider:

  1. Using a single gateway and multiplexing the data sent thru that one connection to a single gateway thread.
  2. Using a single gateway process with multiple threads communicating with individual Cache processes
  3. Using multiple gateway processes dedicated to different tasks that could have multiple connections/threads to each individual gateway process. 

Addressing this requires intimate knowledge of what the DotNet app is doing.  If the dotNet app has shared resources (making it single threaded) then option 1 is probably best.  Options 2 and 3 will tax the system with lots of process  creation and socket connections.  If they are using those options, it best to hold onto the connection established and not be constantly connecting and disconnecting.  With this in mind, they might combine the idea of multiplexing similar functions via a single connection that remains connected as a service.  Whether this uses 2 or 3 does not make a lot of difference, with the exception of situations where the DotNet application is not stable and can cause crashes, then it is best to isolate them to track down issues.

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:

Searching Messages Using the Message Viewer

https://learning.intersystems.com/enrol/index.php?id=34

Here's an outline of the course:

  1. The Message Viewer — describes how to navigate to and around the message viewer.
  2. Searching using Basic Criteria — describes how to search using basic criteria such as target/source, id, and time.
  3. Extended Criteria: Header and Body fields — describes how to search for messages using header and body fields.
  4. Search Tables, Virtual Documents, and SQL — describes how to search for messages using search tables, segment fields, property paths, and SQL

You can use a Message Router as your Business Process.

In the Routing Rule you can define the Message Class in the Rule's constraint to be Ens.StreamContainer, which is the default message type for file passthrough.

Then you can use the OriginalFilename property of the message to check regarding the extension of the file, for example.

Here's a sample screenshot to illustrate -

Hope this helps.

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

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.

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]

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.

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

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.