Noting that there is an argument needed which seemed to be lost in the page translation. Argument as
do ##class(%EnsembleMgr).EnableNamespace($namespace)
I have previously investigated a similar question, which came up when I was passing Content-Length in code headers but was seeing broker responses sometimes of Transfer-Encoding:chunked.
At an abstracted level, IRIS sits on the left with the code -> CSP gateway sits in the middle -> web service sits on the right.
Generally,
Web service will get and deal with headers as:
- If Content-Length is passed it will be used, and Transfer-Encoding will NOT be set
set %response.Headers("Content-Length") = %request.Get("FileSize",1)
- If there is no Content-Length, Transfer-Encoding will be determined and used
The CSP Gateway has settings which specify when to use Content-Length or Transfer-Encoding.
These can be changed to your specification.
For example, the Content-Length can be set to be always used, and never Transfer-Encoding.
In (my) CSP Gateway settings:
- Content-Length will be used if less than 0.005 GB
- If more, then Transfer-Encoding will be used
This can cause the broker response to sometimes have Content-Length and sometimes have Transfer-Encoding:chunked based on file size.
Another layer of complexity,
There is built in logic in the CSP Gateway for:
- Before Transfer-Encoding, recognize large files and gzip them to compress.
This throws away previous headers and replaces them. This means that even if Content-Length is set in the headers or as default in the CSP Gateway, if the file is large enough it will be gzipped and Transfer-Encoding will occur anyways.
To avoid Transfer-Encoding, solution is to force no gzipping in the CSP Gateway.
set %response.GzipOutput = 0 // Tell CSP gateway not to modify output, allows Content-Length header





Hi Yone,
The documentation you reference is for IRIS for Health 2025.1, while you note that your product version is IRIS 2020.1. The methods differ between versions, so looking at the 2020.1 documentation will show you the valid methods to use for your version.
If you see the documentation for IRIS 2020.1 Ens.Util.Log, you can see under the Inherited Methods (Including Private Methods) section that there is no BuildIndex() option, which explains why the error you get is <METHOD DOES NOT EXIST>.
Looking at the correct documentation version, there is information for IRIS 2020.1 on Building Indices and on Validating Indices. The documentation notes that "The preferred way of building indices is to use the %BuildIndices() method or the %BuildIndicesAsync() method" as %Library.Persistent.%BuildIndices() or %Library.Persistent.%BuildIndicesAsync(). There is further information on the recommended cases for each.
Hopefully this helps point you to a successful method!