Hi Wolf,

I am using v2017.2.1 and Atelier 1.2.118 and I'm not experiencing this.

What I have encountered with regard to license consumption and Atelier (also with version 1.1 of Atelier) was that if I did not define a proper user for the server login (i.e. UnknownUser) then multiple users where consumed (per CSP session of the REST calls). So the recommendation is (also regardless of this licensing aspect) to define a real User for login. Note the phenomena I saw was that of multiple Users, not multiple connections of the same User (if that was what you were seeing).

I suggest that if, also when you define a proper User for login, the issue persists (and you don't get any other swift answer from the Community), you should work with the WRC to resolve this (and then hopefully post the answer back here on the Community).

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 think using Ens.Config.DefaultSettings:%Export() and %Import() is the way to go (and would be the more supported and documented approach).

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.

Hi Jon,

I'm not sure this is exactly what you were looking for but you should be aware of the %XML.DataSet class.

With this class you can run an SQL query (for example returning all the instances of your class, or filter out some subset of it) and get the results in XML format (including the metadata of the result).

See more details in the docs.

Here's a sample run:

 
SAMPLES>set dataset=##class(%XML.DataSet).%New()
 
SAMPLES>write dataset.Prepare("SELECT TOP 5 ID, Name, DOB FROM Sample.Person WHERE Name %STARTSWITH ?")
1
SAMPLES>write dataset.Execute("b")
1
SAMPLES>do dataset.XMLExport()
<SQLResult>
<s:schema id="DefaultDataSet" xmlns="" attributeFormDefault="qualified" elementFormDefault="qualified" xmlns:s="http://www.w3.org/2001/XMLSchema" xmlns:msdata="urn:schemas-microsoft-com:xml-msdata">
  <s:element name="DefaultDataSet" msdata:IsDataSet="true">
    <s:complexType>
      <s:choice maxOccurs="unbounded">
        <s:element name="SQL">
          <s:complexType>
            <s:sequence>
              <s:element name="ID" type="s:long" minOccurs="0" />
              <s:element name="Name" type="s:string" minOccurs="0" />
              <s:element name="DOB" type="s:date" minOccurs="0" />
            </s:sequence>
          </s:complexType>
        </s:element>
      </s:choice>
    </s:complexType>
    <s:unique name="Constraint1" msdata:PrimaryKey="true">
      <s:selector xpath=".//SQL" />
      <s:field xpath="ID" />
    </s:unique>
  </s:element>
</s:schema>
<diffgr:diffgram xmlns:msdata="urn:schemas-microsoft-com:xml-msdata" xmlns:diffgr="urn:schemas-microsoft-com:xml-diffgram-v1">
<DefaultDataSet xmlns="">
  <SQL diffgr:id="SQL1" msdata:rowOrder="0">
    <ID>3</ID>
    <Name>Bush,Sam K.</Name>
    <DOB>1932-05-05</DOB>
  </SQL>
  <SQL diffgr:id="SQL2" msdata:rowOrder="1">
    <ID>53</ID>
    <Name>Basile,Rhonda B.</Name>
    <DOB>2001-07-18</DOB>
  </SQL>
  <SQL diffgr:id="SQL3" msdata:rowOrder="2">
    <ID>66</ID>
    <Name>Bachman,Julie M.</Name>
    <DOB>1959-10-11</DOB>
  </SQL>
  <SQL diffgr:id="SQL4" msdata:rowOrder="3">
    <ID>102</ID>
    <Name>Bach,Mo N.</Name>
    <DOB>1936-01-17</DOB>
  </SQL>
  <SQL diffgr:id="SQL5" msdata:rowOrder="4">
    <ID>116</ID>
    <Name>Braam,William V.</Name>
    <DOB>1983-03-06</DOB>
  </SQL>
</DefaultDataSet>
</diffgr:diffgram>
</SQLResult>