Hi Luiz,  yes - I ran into this too and implemented a similar approach, however - the last thing I do is then remove the license key from the image.

This is because I do not want (in my case at least), to build images which hold valid keys.  Especially if posting this the image to a public registry.

I would expect consumers of the image would bring their own license key.

Hi,

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.

Steve

Hi,

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.

Steve

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.

Steve

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.

Steve