I tracked this issue to $System.OBJ.Load() only apparent on IRIS 2021.2.  after upgrading to IRIS 2022.1, this issue went away.

Hope this helps others.

ok... Update: This definitely looks like a Microsoft bug.

Setting up the same classes/data in a new namespace on the same IRIS instance, and created a fresh DSN in ODBC to use works fine.

I even create a new namespace and global/package mapped all data from the original failed namespace, and created a fresh DSN in ODBC to use works fine too.

So - it's not the class/package/data definition in IRIS, or the IRIS version.  There is something Power BI is holding onto, which is related to the original DSN Name used, that is causing grief.

I'm sorted for now.

Hi Louis

Firstly, I don't think there is anything wrong with the code above.. but can you verify that the x509 certificate you created includes reference to the Certificate Authorities (the entire CA chain) that issued the sender's public key .


Hi Prashanth,  you do need to import these classes into the IRIS cloud instance's database.  (VSCode then accesses the cloud instance and pulls the code locally for editing in a local folder, or, access IRIS remotely for editing there).

To use VSCode, the VSCode connection to IRIS uses the IRIS SuperServer port to access IRIS in order to compile classes. Therefore, this port must be open from the cloud instance.

With this open SuperServer port, a local instance of IRIS Studio could be started, connected to IRIS, and then used to perform the import. Studio menu: Tools -> Import Local...

If you do not have Studio installed locally on your desktop yet, you can use the Management Portal, by going to  the menu System Explorer-> Classes -> Import  (after selecting your desired namespace).  On the dialog window asking for a file, you should be able to specify 'My Local machine' and the browser will look locally for the XML file to import into the instance.

Alternatively, you need to copy the XML file to the cloud instance, (using ftp, or other means), and from an IRIS Session, use the ##CLASS(%SYSTEM.OBJ).Import utility to import the XML file from the command line.


Hi Tom. The REST API definition itself within IRIS is not where TLS is negotiated and terminated (and hence not where mTLS is defined) between client and server.

Requiring https over http, and, insisting on mutual authentication is defined in a Web Server layer which then in turn, communicates with IRIS on a seperate port and protocol.

You need to first install a supported web server, and then add the IRIS Web Gateway (see docs) to it. Prove that regular http request of the API work.

Then, on the web server, enforce HTTPS and mutual authentication.  See your chosen web server's documentation for how to do this. (InterSystems does not provide this of course). IIS, Apache and NGINX are supported.

Once that's done, clients can only access the IRIS Rest API over https, which is negotiated/terminated against the web server, which can also insisted on client authentication (mTLS).

Hopefully this post sets you on the right path.




For existing documentation, I believe others have already directed you. If, however, you are not doing an in-place migration (that is, you are installing on a new server), then one needs to get a bit more creative.  (There are several reason why you may choose to switch to new servers - for example wanting to move to a different OS, or a version that is supported by IRIS which you cannot simply upgrade to.)

Your InterSystems Sales Engineer or even the WRC, are able to provide the detailed advice you need which is often specific to your situation.  The main things to consider is the downtime you can afford when you failover to IRIS, and the architecture you have (do you have multiple Cache nodes, ECP, mirrors, etc ?).

In general however, what I have done successfully is create IRIS Asynchronous Mirror servers of the Cache nodes, then, (on switch over) shutdown Cache and promote the IRIS servers to active mirror failover members etc.  You obviously need to ensure that the IRIS set of servers is readily configured with security, memory etc to take over as a valid Async DR node.

Finally note that this creation of IRIS nodes as async mirror nodes to Cache servers is not supported as a production configuration but only allowed for migration.

Please reach out to InterSystems WRC or Sales Engineering for more in-depth discussion and planning.



That should work (as advertised) but if you want a workaround .... call a method instead, that implements the same thing:

    <Invoke Class="App.Installer" Method="SetAutoStartProduction" CheckStatus="true" >
Arg Value="${MyNamespace}" />
      <Arg Value="myProd.Production" />

- assuming 'MyNamespace' contains the namespace name you are setting up, as a variable (or hard code it).

Then include the method:

ClassMethod SetAutoStartProduction(myNamespace, prodClass) As %Status

   quit ##class(%EnsembleMgr).SetAutoStart(myNamespaceprodClass)


Hi Muhammad,

For FHIR capability, one would need to be running the healthcare version of IRIS - so, you would need to run, in your case the "IRIS for Health" product, which is also available as a Community Edition.

This feature does not require additional licensing in order to appear. You just need to be on the right version of IRIS for Health.

This option you mentioned here ("Health > FHIR Configuration > Server Configuration") was first introduced with release 2020.4, so, any version of IRIS for Health should be on this, or a later version to enjoy this feature.

InterSystem's AWS marketplace offering that launches IRIS for Health Community Edition,  here - does in fact launch this correct release. You could use that instance.

InterSystems' Quick Start tutorial here, which helps people learn about FHIR, also uses the correct release, and starts an instance for you in the cloud to use. If you are learning about FHIR  I suggest the Quick Start tutorial is your friend there too. 

You do not need to be an InterSystems customer to take advantage of this.

If you are a customer of InterSystems, you can download the version of IRIS for Health that was first released with this feature (2020.4) via the Distributions pages of the WRC, but note, that this was a Docker Container release only. 

Assuming you do not want to use Docker Containers, then, the next, non-container release with this feature is IRIS for Health 2021.1, and as soon as this is generally available, I would recommend to progress with that version.



I have.

As Robert mentioned - disk I/O is one issue.  And the other issue is drive letter changes if the drive is moved between hosts (for example - the 'Journal File Location' pat set to D:\ in one instance - then drive 'D:' not found when the flash drive is moved between hosts.)  This can be overcome with scripts of sorts (potentially) - though I haven't tried to do that.

Hi Fernando,

Strange. I've never seen this before, and it seems like a bug to me.  If no other suggestions appears here, I would reach out to the support team at InterSystems for advice.

If just defining classes and routines, VS Code is another alternative IDE. This is being developed further to bring it in line with the features of Atelier and provides another formidable option.

Of course the more mature IDE is IRIS Studio, another alternative for you, if running on a Windows client.