Hi Stella,

I dubt the code that returns "a LIST error" is the code you posted here.
There seems to be a few problems with the code posted, including:
- I don't think the query will compile with " as Count" (Count is a reserved word in SQL)
- You should get an <UNDEFINED> error when referencing the Count variable in the for loop

Please note that Settings in Ens.Config.Item is a "list Of Ens.Config.Setting", that's an instance of %Library.ListOfObjects, not a $list.

In general, when I code, today I try to avoid %ResultSet, that I consider deprecated, in favor of %SQL.Statement. But that's, maybe, my opinion.

As to a possible solution, I'm not sure the full list can be obtained with a single SQL query because the result consists of a "main" collection of all productions hosts and, for each host, a collection of settings.
Lists in Object Scrtipt Classes are not projected to SQL by default (SQLPROJECTION and/or STORAGEDEFAULT may change that default).

So, to get the list of all Settings, two loops are necessary, one for all hosts, another for all settings within the host, something like:

ClassMethod SettingsQuery()
{

    Set sc=$$$OK
    Try {
        Set sqlQuery="Select Production, Name, Settings from Ens_Config.Item "
        Set stSql=##class(%SQL.Statement).%New()
        Set stSql.%ObjectSelectMode=1
        Set rsSql=##class(%SQL.Statement).%ExecDirect(.stSql, sqlQuery)
        If rsSql.%SQLCODE < 0 {
            Set sc = $$$ERROR($$$GeneralError,"%SQLCODE="_rsSql.%SQLCODE_", %Message="_rsSql.%Message)
            Quit
        }
        
        While rsSql.%Next(.sc) {
            If $$$ISERR(sc) Quit
            Write rsSql.Production.Name," -> ",rsSql.Name," has ",rsSql.Settings.Count()," settings:",!
            For SettingCounter=1:1:rsSql.Settings.Count() {
                Write ?10,rsSql.Settings.GetAt(SettingCounter).Name," = ",rsSql.Settings.GetAt(SettingCounter).Value,!
            }
            Write !
        }
    } Catch CatchError {
        #dim CatchError as %Exception.SystemException
        Set sc=CatchError.AsStatus()
    }
    Quit sc
}

Now, you got what you asked....but, I'm not sure you got what you want/need. ;)
There are several issues/pitfalls.
There are Business Host settings and Adapter settings, there are settings with default values....and more...

I REALLY wish ISC provided an interface to get a list of all settings, along with "actual" values (as used by the production, wherever the value comes from....) of each/all Business hosts within a production.
But...I keep wishing, any other has the same wish? :)

Enrico

P.S.: Please note that the code posted works in IRIS but does not work with Ensemble/HS due to a bug on how %ListOf* are handled when %ObjectSelectMode=1

P.P.S: how can I paste properly insented and "colored" code directly from Studio?

Hi Brad,
we have done quite a few similar project migrating, cloning and "splitting" Ensemble/HealthShare systems to/from different sites or systems.
In fact we are working on one migration (with some change in the target site) right now.
The actual recipe depends on the environment and the requirements, in your case is a "simple" move, and that simplify the job.
It is indeed possible to upgrade during the migration, but of course it adds a little more complexity and planning (AND TESTING!!).
One important aspect is the down time you can afford, if any. I've never done a migration with zero down time, I would say that around 30 minutes to one hour is feasible, in your case that does not require any modification maybe in less that 30 minutes it can be done.
Ensemble is an integration platform, it often connect to many systems and receive connection from many systems, often there are some sort of web/csp app where user are connecting, this must be taken in to account to simplify and speed up switch time.
Ideally you want to have full control of the "communication switch" so when the "new" system take over you can switch (divert) all the connection to the new system.
We usually install a temporary reverse proxy for all the HTTP/HTTPS traffic (soap, web/csp pages, rest, etc.) that "redirect" the traffic to the "old" system and ask all the connecting systems to "point" to the reverse proxy BEFORE (a week or two) "D day" (final migration switch date).
Then we make sure that ALL the HTTP/HTTPS traffic goes through the proxy (we always find some external system that "forgot" to change the endpoint...).
The "D day" you change the reverse proxy configuration to "redirect" the traffic to the new system, so this is under YOUR control.
For HL7 traffic we usually prepare in the "old" system a separate production that simply redirect received HL7 to the "new" system.
You need one Business Service and one Business Operation for each TCP/IP HL7 inbound adapters in all your productions (i.e. one for each HL7 port in your system).
This production can be implemented adding BS's (EnsLib.HL7.Service.TCPService) and BO's (EnsLib.HL7.Operation.TCPOperation) with simple point & click configuration.
When all your production in the old system have stopped and started in the new system, starting this production will redirect all the HL7 traffic to the new system, all under YOUR control.
As soon as the new system is up&runnign you can ask all the connecting partners/systems (HTTP/HTTPS and HL7) to change (at their convenience) the endpoint to the new system.
I believe that having the "main switch" in your control is crucial....particularly when you have tens of systems/partners connecting to Ensemble/HS.
Depending to your environment there maybe more type of connection to take care of...
Regarding setting up and migrating the system, the first goal is to replicate the configuration, usually this involve a fresh installation (better if using same drive/disk letters and structures), a preliminary copy of all the databases and configuration using some sort of backup (there are different options) and as much TESTING as possible in your environment. Are third party test systems available? If not you may need to build some mockup of the external system to perform some basic testing.
We usually take the opportunity to spit code ("routines") databases and globals (data) databases, if not already so.
The advantage of dividing code and data is the ability to change code in the target system and when performing the last migration/copy only data is transferred (actually, the database may contain code no longer used...no problem).
The final migration should only transfer the data (not config) and involve some sort of backup and journal file from backup to "shutdown", this way you can minimize the downtime to the minimum.
Please add in the middle of each step above: test, test, test and at the end test, test and test :)
There are many other aspects I forgot or depends on specific environments and requirements, these are only a few tips from my experience.
If you have any specific question, just ask, I can't commit for an answer, but maybe somebody else will ;)
Ciao,
Enrico  

Hi Guillaume,

I think the ParseFile method of %XML.TextReader is what you are looking for. I've not tested, but according to the documentation, it should work.

https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cl…

Note: the link is to IRIS doc., but should be the same in Ensemble  2017.

Enrico

I don't think you can add SqlProc at class level, but you can modify the class definition programmatically.

Look at the class %Dictionary.MethodDefinition and the property SqlProc, if you set it to 1 is the same as adding [SqlProc] to the method.

%Dictionary.MethodDefinition is a child class of %Dictionary.ClassDefinition.

Of course I advise you to test it in a temporary system/namespace before...

Hope it helps,

Enrico

Frankly I cannot see any advantage in using the sample you posted, it makes things more complicated with no advantage and no, it's not faster than just use a plain simple property.

There are cases when those "tricks" (calculated properties, Set/Get methods) can be useful, but that's not the case of the code in your sample.

Regarding VALUELIST, it makes it easy and simple to define a (typically small) set of valid values for a property, then, if necessary, you can optionally provide a "user friendly" representation of those value. If you don't find it useful or don't need it, well....don't use it.

Enrico

Try enabling the log in the Java Gateway. In Management Portal:

System Administration > Configuration > Connectivity > External Language Servers > Edit External Language Server

Edit the "%Java Server" (you may need to stop it, if started) and in Advanced Settings specify a Log File.

Then reproduce the problem and check the log file.

The log file (in some case) can grow significantly, you may want to disable it when done.

Enrico

I don't think alerts are stored in any file, they are stored in the Interoperability Event Log accessible from System Management Portal or via SQL using Ens_Util.Log table alerts have Type=6/Alert

Use the Schedule setting for the Business Operation:

https://docs.intersystems.com/iris20222/csp/docbook/DocBook.UI.Page.cls…

I haven't seen a database corruption for many years, I literally forgot the last time I saw it, it may be 15+ years or more. And in the past (last millennium) I've seen and dealt db corruption.

Out of curiosity, what are the symptoms or your corruption? How did it happened?

Exactly for that situation I use:

If##class(Ens.Job).ShouldBeQuiescent() || ##class(Ens.Job).ShouldTerminate() {
    ; do your closing housekeeping or...whatever..Quit
}

In your case maybe only ShouldTerminate() would be sufficient.

Enrico

You can change the port from 57772 to 80 in System Managment Portal: System Administrtion -> Configuration -> Additional Settings -> Startup -> WebServerPort

Or cache.cpf configurtion file:

WebServerPort=57772  to WebServerPort=80

Better, proper and suggested solution: install a properly configured web server using port 80, don't use the little web server installed by Ensemble.

Enrico