Container: FHIR Configuration Utility returning 404 error after upgrading IRIS

Question

Question

Kari Vatjus-Anttila · Dec 21, 2023

Hello,

I've been running IRIS in a container for a while with the durable %SYS feature. Previously, I was running IRIS 2022.x version and decided to upgrade to 2023.1. During image build, I create some namespaces and install a FHIR repo into one of them using the following script:

Do ##class(HS.FHIRServer.Installer).InstallNamespace()
Do ##class(HS.FHIRServer.Installer).InstallInstance(appKey, strategyClass, metadataPackages)

However, when I updated the container (stopped the existing one, started the new one), I noticed a peculiar error. I couldn't open the FHIR Configuration Management utility anymore as it was pointing to an incorrect location.

In the web applications, I can see that the fhirconfig web application resides in /csp/healthshare/<namespace>/fhirconfig/ URL, but the FHIR config utility points to /csp/<namespace>/fhirconfig/ for some reason.

If I manually enter the URL as /csp/healthshare/<namespace>/fhirconfig/, the utility opens correctly. If I delete the durable directory and start anew, the URLs are working and pointing to /csp/healthshare/<namespace>/fhirconfig/. Deleting durable is not an option.

TL;DR: How do I update the FHIR configuration URLs to point to the correct web application? /csp/<namespace>/fhirconfig/ -> /csp/healthshare/<namespace>/fhirconfig/?

Product version: IRIS 2023.1

$ZV: IRIS for UNIX (Ubuntu Server LTS for x86-64 Containers) 2023.1.2 (Build 450U) Mon Oct 16 2023 11:25:49 EDT

Discussion (2)2

Log in or sign up to continue

Tani Frankel · Dec 24, 2023

I believe you have stumbled across a known issue - that if you call the method you mentioned above HS.FHIRServer.Installer:InstallNamespace() in a container, more than once, the FHIR Config UI app breaks (due to the folder location you mentioned above).

This was fixed since version 2023.2 (I see you are using 2023.1).

If you want to upgrade to 2023.2/3 you will have the fix. (just note the differences between CD (Continuous Delivery) releases and EM (Extended Maintenance) ones (like 2023.2/3); see this article for more details).

If you can't upgrade now I suggest you turn to your local InterSystems account team (@Anssi Kauppi /
@Janne Korhonen) and/or InterSystems WRC (you can reference the internal fix IF-4531).

0 0

score 0 · Answer 1 · 2023-12-22T05:57:04-05:00

I looked through the source to understand how those links are generated and found this:

When you click the Health button in the Management Portal, the list of namespaces that are displayed in the chooser are linked to the default application of the namespace, which in my case happened to be /csp/<namespace>. That was the reason why the URLs were returning 404. After I modified the namespace default application to be /csp/healthshare/<namespace>, the links started working.

So after I upgraded the container, the web application data was stored in durable %SYS and was not updated on container startup. One has to modify the applications manually or via some method after instance startup (%ZSTART, for example).

Here is a short script that I used to update the default application for all namespaces:

Set $NAMESPACE = "%SYS"
Set oldUiUrl = "/csp/" _ namespace _ "/"
Set newUiUrl = "/csp/healthshare/" _ namespace _ "/"
Set namespace = "yournamespace" // Change this to your namespace or add it as a method parameter that is used to loop through all your namespaces
Write "Checking if app " _ oldUiUrl _ " exists...", !
If (##class(Security.Applications).Exists(oldUiUrl, .oldApp, .status)) {
    If (##class(Security.Applications).Exists(newUiUrl, .newApp, .status)) {
        Write "Switching namespace default application from " _ oldUiUrl _ " to " _ newUiUrl, !
        Set namespace = $ZConvert(namespace, "L")
        Set props("IsNameSpaceDefault") = 0
        Set sc = ##class(Security.Applications).Modify(oldUiUrl, .props)
        If $$$ISERR(sc) {
            Write "Failed to modify application " _ oldUiUrl _ ". Error=" _ $SYSTEM.sc.GetErrorText(sc), !
            Return sc
        } Else {
            Write "Application " _ oldUiUrl _ " modified successfully", !
        }
        Set props("IsNameSpaceDefault") = 1
        Set sc = ##class(Security.Applications).Modify(newUiUrl, .props)
        If $$$ISERR(sc) {
            Write "Failed to modify application " _ newUiUrl _ ". Error=" _ $SYSTEM.sc.GetErrorText(sc), !
            Return sc
        } Else {
            Write "Application " _ newUiUrl _ " modified successfully", !
        }
    }
}

If you have any good tips on how to improve the upgrade process, please share them in the comments.