Hi Scott,

my first thought here was use ^GBLOCKCOPY.

GBLOCKCOPY can copy all globals from one database into a new database or namespace.

So in your case create a new namespace with the correct mappings and new default databases. then use ^GBLOCKCOPY to copy all globals into this namespace. The copy to namespace follows the mapping definition for the namespace and should split Global(data) and Routine(also in globals) into the respective default databases.
This new databases can also created mirrored and then would be populated on all nodes respectively.

A caveat though i would test this first as i am a bit unsure if it really gets all globals located in a database(including system), although i am pretty sure it does.

Hi,

so just to summarize what i understood. 

You have a superclass with some logging method. Now every time the logging method is called from a child class it logs the name of the superclass instead of the Child class?

If so the issue is that $CLASSNAME returns the name of the class where the method is located not where a method is called from.

To work around this behaviour you would need to rewrite your logging method to be a codegenerator, e.g.

instead of:

ClassMethod Log()
{
    w $CLASSNAME()
}

rewrite it like this:
 

ClassMethod Log() [ codemode = generator, forcegenerate ]
{
    do %code.WriteLine("    w $CLASSNAME()")
    quit 1
}

This will locate the Log method from the superclass to the child class and have $CLASSNAME resolve to the child classname.

Ther eis one inherent flaw i found when using linux service definitions. If you once stop/start IRIS using iris stop/start command it breaks the automated shutdown.

To work around this we usually define 2 service definition, one for normal control and one to ensure the instance goes down during shutdown.

example definitions:
 

    [Unit]

    Description=Shutdown management for ISC IRIS Instance SAMPLEINST - to ensure DB instance is properly shutdown on system reboot

    [Service]

    Type=oneshot

    RemainAfterExit=true

    ExecStart=/bin/true

    ExecStop=/usr/bin/iris  stop SAMPLEINST quietly

    [Install]

    WantedBy=multi-user.target

   

    # normal management

    [Unit]

    Description=Management for ISC IRIS Instance SAMPLEINST

    [Service]

    Type=oneshot

    RemainAfterExit=true

    ExecStart=/usr/bin/iris start SAMPLEINST quietly

    ExecReload=/usr/bin/iris   stop SAMPLEINST quietly restart

    ExecStop=/usr/bin/iris   stop SAMPLEINST quietly

    [Install]

    WantedBy=multi-user.target

    Alias=IRIS-iSAMPLEINST.service

Hi,

Try setting the Cookie security to LAX. This essentially has nothing to with the IRIS/Cache version but with the CORS standard implemented in modern browsers.

Cookies with SameSite attribute set to None are only allowed if they are secure. refer to https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls...

Hi Luis,

just looking at documentation try disabling: Do Not Use Delimited Identifiers by Default
 

snip from documentation (ref: documentation:

Do Not Use Delimited Identifiers by Default

The Do not use delimited identifiers by default option controls the format of identifiers in the generated routines.

Select this check box if you are using a database that does not support delimited SQL identifiers. This currently includes the following databases:

  • Sybase
  • Informix
  • MS SQL Server

Clear the check box if you are using any other database. All SQL identifiers will be delimited.

Hi Philip,

not knowing anything about your deployment or applications hosted by IRIS this will be only very high-level.

There are multiple ways how this can be achieved. 

Essentially the easiest way is to stop/freeze the IRIS instance on your backup mirror in LIVE then, depending on your databse sizes. Either copy the database files over to your test environment, or take afilesystem snapshot and transfer that accross. After start,thaw the backup mirror iris instance.

On the test environment break the mirror. shutdown the instance on your primary test mirror. copy in the databases you transferred (ensure the global mappings are the same), you can choose at this point to not overwrite certain databases you do not want to be refreshed e.g. localsysconfig. start up the iris instance, remove the mirror flag from the database files you just refreshed and then do all post refresh activities. at the end you have to rebuild the TEST mirror though, as per IRIS doco. 

When you do Delegated Auth you add code to ZAUTHENTICATE that validates the request against what you want e.g. you grab userid from the incoming web session, or even content of the get parameters provided and validate it against a global that was mapped via ECP from your primary server, that global could save e.g. client ip and username.
Then you can assign a valid user in ZAUTHENTICATE for the incoming connection, no password needed.

I don't think you can provide object script code via the UI for security reasons.

What you probably need to do is open you production item in Studio/VSCode.

Then overwrite the OnInit() method with something like

Below code is not validated and will not be 100% correct in regard to function specs etc, this is only used for clarification and example:

Method OnInit(.............) as %Status
{
    set ..IpAddress=$get(^ehrIP)
    set status=#super()
    return status
}

Hi Cathrine,

usually, TrakCare as a web application does not directly integrate with a dictation software. Any dictation software is used to fille the appropriate text field in the TrakCare browser window after parsing the dictation.

For more details and for a in depth look i would suggest you get an iService ticket raised so the specialist/development can have a look at it.

Best Regards
Timo

Hi Carl,

easiest way is to save the authorization to a global, have that global mapped via ECP to your child servers.
On the child servers create a ZAUTHENTICATE routine and implement delegated authentication. essentially you use this routine to check on connection open on the child server if the incoming connection is a valid request based on the auth global mapped from your primary server, then allow or deny.

The better approach here, if you don't want to use SystemDefaults.

Is to add a global mapping for your global config variable ^ehrIP to the %ALL namespace pointing it to a config database. This will point the ^ehrIP global in each namespace to the same storage location.

Then you can access this global via ^ehrIP as usual. I would not use % globals as they are saved in the %SYS namespace and application code/data should not be living in the %SYS namespace.

From a SMS point of view this is major hell.
If you are coding you application currently, then rather then checking a database for settings instead of using global mappings, code your application that it checks a "higher-priority global first" then defaults to the global default mapping.

example core config uses ^ %SYS for instance wide config and ^SYS for local namespace config.

In this scenario you would not even need a %ALL namespace global mapping.