· Aug 26, 2022

Missing Ensemble Classes in IRIS for Health Community Docker


I'm using CircleCI to spin up the image `store/intersystems/irishealth-community:2021.2.0.649.0`.

When building the application we are getting messages that say:

ERROR #5373: Class 'EnsLib.HL7.Message', used by 'Package.Class', does not exist
Skip class Package.Class

Other missing classes seem to include, but not limited to:


Binding to a port and looking the management portal, it seems we have the namespace HSLIB and some classes:

As far as we understand, these classes should be available on the community edition.  Is there possibly a setting or some setup we are missing in the build that these classes aren't generated?

Any help is appreciated!

Product version: IRIS 2021.2
$ZV: IRIS for UNIX (Ubuntu Server LTS for x86-64 Containers) 2021.2 (Build 649U) Thu Jan 20 2022 08:53:15 EST
Discussion (19)2
Log in or sign up to continue

@Evgeny Shvarov and @Alex Woodhead 

Lots of good progress here, but still a few issues:

- Thanks to @Dmitry Maslennikov and his help, I am using a Dockerfile and compose to do the build, so everything is a little more contained and standard (I used that coffee store template as a starting place)

- After running App.Installer.setup() via the Dockerfile commands, I run do ##class(%EnsembleMgr).EnableNamespace("$NAMESPACE").  After that I do some application setup logic including a recompile of those classes that depend on those Ensemble classes and I finally get that clean compile of those classes and no error messages saying HL7.Class does not exist.  

- As I mentioned before, the namespace element in the Installer.cls manifest has interoperability turned on <Namespace Name="${NAMESPACE}" Code="${NAMESPACE}-CODE" Data="${NAMESPACE}-DATA" Create="yes" Ensemble="1">

- How can I run the command do ##class(%EnsembleMgr).EnableNamespace("$NAMESPACE") after the creation of the application's namespace but BEFORE loading and compiling the source code? My only workaround is to recompile after running App.Installer.setup()  and do ##class(%EnsembleMgr).EnableNamespace("$NAMESPACE").  I'm not sure how and where the manifest for the application in App.Installer is used and where I can insert this enable method.  That said, I feel like that <Namespace> tag should be turning it on.  I can't find a reference in the documentation for this manifest.

- Another question/issue is CSP pages.  Following the template, in the docker file I 'COPY csp csp`.  In the installer I mapp the source director to all the code I put in the src folder (classes and mac files).  Should I copy my CSP file here as well so they compile?  My workaround is similar to above, I use a utility to compile the CSP pages in the csp director since the installer doesn't pick them up since they aren't in the source dir.

Some ideas for general configuration.

In a target namespace can test integration is enabled with:
write ##class(%EnsembleMgr).IsEnsembleNamespace()

Can enable integration for an existing namespace with:
do ##class(%EnsembleMgr).EnableNamespace($NAMESPACE)

When enabled, as a test can Run a integration method from mapped class:
write ##class(EnsLib.HL7.Message).%ExistsId(1)

This is sucessful if no longer showing class not found error.

It found the class and ran the method sucessfully.

Set rowId=1

If ##class(EnsLib.HL7.Message).%ExistsId(rowId)=0 or 1 then

    The class EnsLib.HL7.Message has been mapped to the current namespace.

It is giving 0 because there has been no HL7 messages created yet (with rowId 1) or message rowId 1 has been purged from namespace.

A better non-error prone way to programatically test whether the class is available to the namespace could use:

write ##class(%Dictionary.CompiledClass).%ExistsId("EnsLib.HL7.Message")

@Dmitry Maslennikov 

It's a bit much and there's probably a better way, but the long story short is that many of our static files are in a folder in the root, so I have to build the container, run a 'docker exec' command as root to copy my file to the root, exit out of that, then log in again as a the regular user to start the iris session and run the build script.  

The script uses the sleep command to wait (now at 70 seconds and working fine) for iris to finish starting so I can start the session and run the script.  Otherwise I get the startup error.  

So, it looks like you doing it a wrong way. 

If you need to build your application, then you have to do it with Dockerfile during the build stage, not when it is just up and running. And you still build some container before it.

In any case you may use this way, to wait until it's started

sleep 5; docker exec $CONTAINER /usr/irissys/dev/Cloud/ICM/

Teah, not documented, internally used script, but nothing offered instead.

Contact me directly, I may help to review the build process, and give particular recommendations.