You might also find this HL7 benchmark post by @Mark Bolinsky useful, specifically the section titled "Disk Configuration", and the related "Table 2" there.

For convenience I'm pasting this table here (but read the original post for the full context, for example your scenario sounds more like the "T2 Workload" described there, rather than the "T4" one) -

Table 2: Disk Requirement per inbound HL7 T4 Message  

For the Mgmt. Portal side you can follow through @Yuri Marx Pereira Gomes's example (though it uses Google and not Keycloak but the principal is similar, you will need a ZAUTHENTICATE, you will find a sample there).

Re your question about accessing the Access Token, you can include in your ZAUTHENTICATE something like this:

 set isAuthorized=##class(%SYS.OAuth2.AccessToken).IsAuthorized(applicationName,sessionId,,.accessToken,,,.error)
 if isAuthorized {
    set sc=##class(%SYS.OAuth2.AccessToken).GetIntrospection(applicationName,accessToken,.jsonObject)
    ...
 }    
 // then you can access the jsonObject for getting info, e.g. (and this is from a KeyCloak example):
 set Username="OAuth2_"_jsonObject.username
 // or:
 set iterator=jsonObject."realm_access".roles.%GetIterator()
 while iterator.%GetNext(.key,.val) { 
    ...
 }

For the FHIR API you can look at @LuisAngel.PérezRamos's example (though it uses auth0, but again it should be similar).
In this case you don't have to worry about ZAUTHENTICATE because the FHIR Server infrastructure has you covered.

By the way, in v2024.3 which was just released, there's a new OAuth FHIR Client QuickStart you can use to set this up in an easier manner.

For other REST services this would depend on their nature and whether there is user interaction which allows for example the actions described in the two samples mentioned above.

Note, my colleague @Ariel Glikman and myself are in the midst of a project that includes interacting with KeyCloak, and possibly once it's complete we can share some insights, but this will take some time, so I wouldn't hold my breath waiting for this.

Another note, I believe that down the line (perhaps even with v2025.1) we will have more seamless out-of-the-box integration with these kinds of OAuth authentication flows, which will require less background work as you need to implement today with ZUATHENTICATE etc. Stay tuned...

I believe you need to use PasswordHash, see for example from Docs:

[Actions]

CreateUser:Name=SQLAdmin,
  PasswordHash="cec6638a357e7586fddfb15c0e7dd5719a1964e774cd37466fb0c49c05,
  323cb89148c887166dd2be61c107710539af2c01b43f07dccc8d030ac2c1a8cf7c5ace4a00d57e3780f,10000,SHA512",
  Roles="%SQL,%DB_USER"

Re PasswordHash see more details in the related Docs. For example:

$ docker run --rm -it containers.intersystems.com/intersystems/passwordhash:1.1 -algorithm SHA512 -workfactor 10000
Enter password:
Enter password again:
PasswordHash=0fad6b1a565e04efb5fe9259da8457456883e0a3a42c1a34acec49cbbc1fb8c4c40f1846559ce180c103898db836,dd0874dc346d23679ed1b49dd9f48baae82b9062,10000,SHA512

I think you mean something like this:

https://docs.intersystems.com/iris20241/csp/docbook/DocBook.UI.Page.cls?...

For the machine you got the <WIDE CHAR> error for - did you install 8bit or Unicode?

Your $ZV without the 'U' after the build number, suggests 8bit. I would recommend you install Unicode (8bit support is there more for customers who have legacy 8bit databases).

For the machine you do see the web applications, but can't browse to the page - 

Did you enable the Web Applications?

(https://docs.intersystems.com/irisforhealthlatest/csp/docbook/DocBook.UI...)

Are you getting an error when you browse there? (you can check the Browser Debugger just in case)

Might it be an authentication/authorization issue? (you can check the IRIS Audit, making sure you have Login Failure and/or Protect events enabled)

Thank you, so this is clearer, and it is happening much earlier than I was thinking. You are not trying to connect via xDBC to your FHIR SQL Builder projected tables, but rather just trying to create the first Analysis step.

This error "shouldn't happen", and I recommend you turn to our Cloud Support.

What you could attempt doing before, is opening the browser debugger and see (perhaps under Network and the related HTTP requests you see) if you see some "interesting" error that could shed some light on what is happening.

Perhaps you can provide more details as to what you are trying to do exactly and the way the error manifests itself.

For example you say "in cloud" do you mean via the FHIR Server cloud SaaS service?
If so you have to enable External Connections and setup External Rules. See from the Docs here.

Then under the overview page you should be able to see xDBC Details for connecting. See also here.

There is an article by @Iryna Mykhailova about connecting via xDBC to the IRIS Cloud SQL service, which should be very similar/identical.

Per the above a connection refused error might have to do with the TLS setup required for this connection (which the article above does not cover currently, but the service xDBC details in the Overview page does provide detailed instructions for).

Did you try accessing the terminal web app via port 52773, like your Mgmt. Portal?

52772 used to be the default port for the Private Web Server, but this could change per installation.

Theo, as you see it is described as "beta" therefore it is not currently publicly documented.

Internally you can see IF-1930. It states: "This should only be used with guidance from InterSystems Support."

See also this post https://community.intersystems.com/node/548491 by @Guillaume Rongier 

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

Maybe using the Portal built-in "Test LDAP Authentication" can help.

See Docs.

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.

Sorry for the basic questions -

Do you have data (Resources) in your FHIR Server?

How many Resources do you see were processed in the Analysis?

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.

See relevant values from the docs here:

https://docs.intersystems.com/irisforhealthlatest/csp/documatic/%25CSP.D...

Though this post does not address the question/issue raised directly it might help shed some light on some of the settings used.

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 = 1
            } ElseIf 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.

Re SOAP Wizard from VSCode see this related post.