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

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

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

Enrico

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 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?