Question
Michael Davidovich · Aug 26

Missing Ensemble Classes in IRIS for Health Community Docker

Hello,

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:

Ens.BusinessProcessBPL
Ens.BusinessService
EnsLib.RecordMap.ComplexChild
EnsLib.EDI.XML.Document
Ens.Request

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
0
0 191
Discussion (19)2
Log in or sign up to continue

Hi Michael! Probably the account you use doesn’t have WRC support. Nevertheless you should be able to pull community images from containers.InterSystems.com.

Ah yes, I pulled from my account I'm using now, not my work-email account.  Going back to the community image you spec below.

BTW, for IRIS Community images you can use:

FROM intersystemsdc/iris-community

to pull the latest release image of InterSystems IRIS Community Edition with ZPM included.

Or:

FROM intersystemsdc/irishealth-community

And for the latest preview release:

FROM intersystemsdc/iris-community:preview

Hi Michael!

I guess the Namespace you deploy to doesn't have Interoperability enabled. You can simply check this by deploying your solution e.g. into the USER namespace, which is Interoperability enabled by default.

Hi @Evgeny Shvarov and thank you!

I did forget to mention I do have this in the Installer.cls

 <Namespace Name="${NAMESPACE}" Code="${NAMESPACE}" Data="${NAMESPACE}" Create="yes" Ensemble="1">

Is Ensemble=1 the same as having interoperability enabled?

Yes, this is how you create Interoperability-enabled namespace using %Installer

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

Thanks, Alex.  I will remote into my build and run some of these commands and see where it gets me!

@Alex Woodhead 
Looks like ##class(%EnsembleMgr).IsEnsembleNamespace()=1

and ##class(EnsLib.HL7.Message).%ExistsId(1)=0

When I built my project, I got the same error messages as you might imagine with the output above.

Any other thoughts?

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

While I have some smart people on the line, any idea why I might see this message:

Sign-on inhibited: Startup or Installation in progress

I run a sleep command for 10 seconds before going into the container which I think is a good amount of time, but no dice.  I was able to get in no problem when I used a previous image.

10 seconds may not be enough, in my case starting IRIS may take more than one minute.

Where do you use the sleep command, and what for?

@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/waitISC.sh

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.