· Aug 22

Best practice for automatically deploying and activating changes to CSP.ini?

We're trying to get a little more discipline around Web Gateway change control, and deploy changes to our CSP.ini from source control.  I was wondering if anyone cared to share their best practices in this area?  There is a "RELOAD" parameter ( which says you can put RELOAD=1 in your CSP.ini file in order to force it to automatically activate when noticed by the daemon.  

Do people use this approach, and keep RELOAD=1 stored in their CSP.ini in source control?  Or do you not use this but rather call into IRIS after copying the file to the web server:

Set status = %CSP.Mgr.GatewayMgr.ActivateCSPIni()


Does anyone know if this works even if the web server is on a different VM from InterSystems IRIS?  

I would love to hear people's thoughts on this and other best practices that you may have

(hoping especially that @Chris Munt will weigh in :) )

Product version: IRIS 2022.1
Discussion (6)3
Log in or sign up to continue

RELOAD=1 should work. Once the configuration is reloaded the line with RELOAD=1 will be removed automatically.
Registry functions to control Webgateway from within IRIS will work *after* the Webgateway is registered on the IRIS instance. That happens during the first/initial connection/request. It works, even if Webgateway is on a different machine/system. Please note: registry functions could be disabled in the Webgateway-Configuration. (default = enabled)

Thanks @Bernd Mueller  ... this is very helpful!

Do you see an issue with having RELOAD = 1 always in source control, even if it is removed from the environment copy?

I really like the idea of it reloading, but am concerned about RELOAD = 1 being removed from the copy sitting on our DEV environment where all changes originate ... it would be too easy for someone to accidentally upload a new version of the file without RELOAD = 1 being in the file, meaning it would propagate through our CICD pipeline without that value present and not automatically be activated in higher level environments.

Do you know if there is a way to prevent RELOAD = 1 from being removed from the CSP.ini?

Thanks chad - scripting automatic review failure is more involved than just scripting the calling of the API at deployment time (and not relying on RELOAD=1) so we'd probably go that route.  

If RELOAD = null is hardcoded for immediate removal than probably relying on that would be the more risky approach to change control in this case.  So we'd likely rely on "Set status = %CSP.Mgr.GatewayMgr.ActivateCSPIni()" for automation.