Hi Eduard,

thank you for your answer. Actually: I could make it work with String parameters, but I'm still struggling with GlobalCharacterStream/char[]. So I'm pretty sure that the demo.cashreg.json.JSONValidator class is there. Also because it is the class, which I'm importing through the Java Gateway from the very same .jar file (successfully). Maybe I'm going to give it a try with GlobalBinrayStream/byte{] instead - however it should not make a difference.

Regards,

Attila

Hi Laura. it's quite hard to properly explain this without repeating a significant part of our documentation. But if I'd like to keep it short, here we have to talk about three things: 

  • The definition of the business hosts (services, processes, operations) are classes. Let's put it that way: In those classes you define the configurable parameters and the functionality in an abstract way. 
  • Then you add "instances" of those business hosts (BH) to your Production. Actually: you can add multiple "instances" of the same BH to your Production and each and every instances have their own parameters configured. That XML block in the Production class contains the paramater settings of all the business hosts added to the Production.
  • When you start the Production, Ensemble instantiates real object instances of your BH classes in the background to manage the runtime behavior of the Production. Some of them are persistent objects (business processes) and can store their runtime state on disk, others (services, operations) exists in-memory only. So this is NOT where you should start.

Conclusion: if you want to know more about your Production, the XML block in your Production class can tell you the actual configuration of your business hosts. The various business host classes can tell you how they work (I guess, this latter is not what your users want to know).

I would store the original filename in a property anyway. SQLComputed properties (as long as they are not Calculated or Transient) are calculated when the record is inserted or updated (you can further restrict re-calculation with the SQLComputeOnChange keyword) and stored with the record as any other properties.

That makes also possible to maintain indices based on SQLComputed properties, with two conditions:

  • The SQLComputeCode must be deterministic - this is quite obvious, I think.
  • If you change the SQLComputeCode, that won't affect the records stored in your database, nor the corresponding indices - so you'll have to trigger a re-calculation to apply the new compute code.

See also our online documentation on the topic.