Note that if you are running a recent release of iris, that is not the community edition, and, does not deploy the personal web server - chances are your docker-compose defines 2 services, one for iris and one for the webgateway.

So for VS Code to reach iris,  I have had to change the docker objectscript.conn entries in the original post to:

      "docker-compose": {
        "service": "webgateway",
        "internalPort": 80


where 'webgateway' is the name of the iris-webgateway service as named in the docker-compose file.



My understanding is that these classes: HS.FHIR.DTL.vR4.Model.Resource.*

Are internal for DTL purposes only, and not to be used for serialisation or creation of some type of repository of resources. For that, one should use the FHIR Repository, (and FHIR SQL Builder for SQL query of resources).

Happy for product management/developers to chip in here and confirm.


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 Stefan,

I wonder what led you to determine that the DTL is being drawn by using InterSystems CSP AutoForm (%CSP.Util.AutoFormGenerator), because, I added the XDATA block to the child class to include only the child class's properties as suggested, (and omitting the inverse property):

XData FormDefinition
  <field property="childPropA"/>
field property="childPropB"/>

but the inverse property, in the DTL, still appears.  (also confirmed defining XMLPROJECTION="NONE' on the inverse relationship property also has no effect)

looking at %CSP.Util.AutoFormGenerator, I see my XDATA block definition is being checked, and honored, returning as it should, the list of properties for a form - but this does not seem to end up effecting the DTL Wizard.


Hi Henrique

Following your instructions in OpenExchange to start a container with this iiris-kaggle-socrata-generator, has resulted in the following error for me:  

iris_1  | terminate called after throwing an instance of 'std::runtime_error'
 iris_1  |   what():  Unable to find/open file iris-main.log

With the container failing to start.

Also - Installing ZPM, and then running zpm "install iris-kaggle-socrata-generator",  in the USER  namespace of a freshly installed instance of IRIS, just hangs.

Do you have any clues as to what might be going wrong here in either of the above ?

Thanks - 

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.




As this is git support for shared development,  multiple developers log into and share the same, remote server - are they still individually able to create GIT branches ? How will the server's local git repository identify one users items from another's ? I guess I'm struggling to see how this would actually with branches.

Should the IRIS users log in as their own IRIS user account ? Is this required ?

Thanks - Steve