New post
AllAccepted answers
Attila Toth · Dec 9, 2022

Just one little addition to this InterSystems Data Platform Best Practice, which saved me a lot of time: 

if you may have tried this on a Windows machine with a password protected private key file (for example: created with the built-in Public Key Infrastructure of InterSystems products), you probably ran into this error message in the Apache error.log:
SSLPassPhraseDialog builtin is not supported on Win32

That's because- as the message suggests- the SSLPassPhraseDialog directive is not supported on Windows version of Apache 2.4 and it can't prompt you for your private key password on startup.

The solution is:
a) to make sure, that the SSLPassPhraseDialog directive is not explicitly turned on in your httpd.conf file (or additional include files) and
b) remove the pass phrase from your private key file with the following openssl command:
openssl rsa -in privatekey-withpass.key -out  privatekey-nopass.key

BTW: you don't necessarily need to install OpenSSL on your own. InterSystems products (at least at the moment) come with an openssl executable in their bin directories. Of course: if you want to make sure, that you use the latest and most secure version of the tool, it's better to install it separately.

Attila Toth · Jun 13, 2019

Hi Thembelani,

I haven't looked into this project of mine for a while, but I know about people using it actively, so I'm pretty sure that it should work. The very first thing what I would try (maybe already did - it wasn't clear from your comment) to call the ProducePDFFile() method with the third parameter (pDisplayLog) set to 1. If an error happens during the Apache FOP rendering process, usually it doesn't return any error messages, but you can ask to generate a log file instead of the real PDF document. This log file may contain a lot of useful information, if you had any problems.

Please let me know, if it helps. And if not: I'll try to reproduce your issues.

Best Regards,
Attila

Attila Toth · May 6, 2019

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

Attila Toth · May 5, 2016

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

Attila Toth · May 5, 2016

Production configuration is not stored in tables. Rather in an XML block of the Production class.

I'm not sure whether this is what you want, but if you want to view a user friendly documentation of a specific Production, I'd suggest to go to the Production Configuration (Management Portal > Ensemble > Configure > Production). On the Actions tab on the right the uppermost button is 'Document'. There you can generate a user friendly HTML or PDF documentation of your own Production, in the style of our documentation (see more complete instructions here). 

Attila Toth · May 5, 2016

My answer was not complete in this form: the same effect can be achieved with SQL Triggers, too. That version is more SQL compliant maybe. And the "computed" properties can be set in one of our callback methods (%OnBeforeSave - for example), if you prefer the object interface - this is not called when you update your records from SQL though.  

Which implementation is the best? Besides the SQL/Object preferences, I think that's rather a matter of taste. You can index your properties in all three cases, and you'll face mostly the same (or similiar) problems I mentioned above.

My personal vote would go to SQLComputeCode.

Attila Toth · May 5, 2016

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.