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

Hi Yakov,

You can see from the Docs here, for example re the Property ConnectAttrs (or later ConnectionAttributes):

ConnectAttrs

...

An optional set of SQL connection attribute options. For ODBC, they have the form:

attr:val,attr:val

For example, AutoCommit:1.

...

Set this property in the OnInit() method of your business operation or business service to specify the options to use at connection time.

For calling SetConnectAttr() see these Docs, for example:

If the connection has already been established, call the SetConnectAttr() method of the adapter. This method takes two arguments (the attribute name and the desired value) and returns a status. For example:
 Set tout= ..Adapter.SetConnectAttr("querytimeout",10)

As to the name of the attribute and the appropriate value you should consult the SQL Server documentation (for example this, but this will be up to you to verify).

If you need more assistance than this please get in touch and we can work on this together.

Hi Dmitrii,

Thanks for this question.

Programmatically you can use the method Security.Applications:Modify() (from within the %SYS namespace).

Here's an example:

 set props("RedirectEmptyPath")=1

 set status = ##class(Security.Applications).Modify("/myapp/name",.props)

This article by @David Hockenbroch covers this Security Applications API (including reference to this setting) in general.

Maybe the problem with IIS has to do with Web Socket support.

See for example from the Docs here:

This extension uses WebSockets to communicate with the InterSystems server during debugging. If you are experiencing issues when trying to start a debugging session, check that the InterSystems server’s web server allows WebSocket connections.

 For example from the Windows Features -

See also IIS Docs.

If this is not the issue let us know if you are getting any error on the VS Code side and/or if you can turn on some logging on the Web Gateway or Server side.

Until 2023.3 is GA, and you can upgrade to it, see also this related Global Summit 2023 session recording:

https://www.intersystems.com/performing-advanced-fhir-validation-intersy...

[Not sure I fully trust the presenter though 😉]

And the related Open Exchange app (and GitHub repo):

https://openexchange.intersystems.com/package/fhir-profile-validation

Thanks @Patrick Dunn this is indeed a common issue, so thanks for taking the time to post about it.

I was thinking that this might become an even more common issue once we remove our Private Web Server (PWS) [related post for reference] so added this Idea to allow the Web Gateway installer to do this work for you in advance.

@Andreas Dieckow please review (perhaps this was already taken into consideration).
 

Hi @Dmitrii Baranov 
You can take a peak at a similar task performed internally in the FHIR Server REST handler class -

HS.FHIRServer.RestHandler:marshallRequestFromHttp()

    // For compatability, copy all HTTP_ headers into the AdditionalInfo section of the request
    Set tKey = ""
    For {
        Set tKey = $ORDER(%request.CgiEnvs(tKey))
        Quit:tKey="" If tKey?1"HTTP_"1.E {
            // Determine the proper header name (will be all caps unfortunately)
            Set tHeader = $PIECE(tKey,"HTTP_",2,*) // Copy the HTTP headers - except for certain ones.
            If (tHeader '= "AUTHORIZATION") {
                Do pRequest.AdditionalInfo.SetAt(%request.CgiEnvs(tKey), "HEADER:"_tHeader)
            }
        }
    }

Note this is internal code.

You can also similar code for the Generic HTTP Service (used by the Passthrough I mentioned to Alex above), from:

EnsLib.HTTP.Service:addAttributesToBody()

    Set tattrH=$O(%request.CgiEnvs("HTTP_"))
    While $E(tattrH,1,5)="HTTP_" {
        If tattrH'="HTTP_URL",tattrH'="HTTP_VERSION" {
            Set attr=$REPLACE($E(tattrH,6,*),"_","-"), lwrattr=$ZCVT(attr,"L")
            If '((lwrattr="transfer-encoding")&&($ZCVT(%request.CgiEnvs(tattrH),"L")="chunked")),'((lwrattr="content-encoding")&&($ZCVT(%request.CgiEnvs(tattrH),"L")="gzip")) {
                Set:..#TOLOWERHEADERVARS attr=lwrattr
                Set:'$D(lwrattrs(lwrattr)) pStream.Attributes(attr)=%request.CgiEnvs(tattrH), lwrattrs(lwrattr)=""
                Set:"content-length"=lwrattr tLen=pStream.Attributes(attr)
                Set:"content-type"=lwrattr tContentType=pStream.Attributes(attr)
            } ElseIf (lwrattr="content-encoding") {
                Set tgzip = 1ElseIf tLen = "x" {
                Set tLen="xchunked"
            }
        }
        Set tattrH=$O(%request.CgiEnvs(tattrH))
    }

Again this is internal code.

But coming back to my comment to Alex above, I would recommend using one of the approaches I mentioned there (the Generic Passthrough service, or the FHIR Interop. built-in service) and this way all of the above is already handled for you.

Hi @Alex Baumberg !

First, if you just want to send an HTTP Request from one point to another you can use the HTTP Passthrough mechanism.

And see also my comment to Dmitrii's reply below.

In addition if you are focusing on FHIR requests (as I assume you are, per prior knowledge 😉) you can consider using the FHIR Interoperability Adapter mechanism where you will have a "digested" request which already includes all the HTTP Headers in the AdditionalInfo array.