I’m setup git with intergration server, problem here is it take too much time to setup local IS
Now in my server have many global variable,connection, adapter
Is there anyway to import global variable,connection, adapter from other server like package as a zip file
Please have a look @ Deployer support in webMethods suite of products. Deployer can be used to perform the steps that you are requesting.
I know about deployer but it will not sync between IS with local IS if someone change server code,
can I manage global variable, connection, adapter by git ?
And if I create a global variable in local , how to push it to remote git repo ?
And I think “http://techcommunity.softwareag.com/pwiki/-/wiki” link now broken, can anyone fix this, I cannot access to see tutorial of Intergrate server
The global variables (in the MSR) are held in a file here
/<path to install>/IntegrationServer/config/globalVariables.cnf.
For an IS it’ll be:
/<path to install>/IntegrationServer/instances/<instancename>/config/globalVariables.cnf.
I typically wouldn’t add the entirety of the IS install into git, but selectively add the things required, whilst thinking about your git strategy
For example, your code for each package would typically reside inside its own repository.
Global variables are at a global level - not on a package level and therefore reside inside the config file highlighted. Therefore you might want to commit this into a global level repo.
Alternative approaches would be to hold the config inside the package and use services from within the package to access, versus global variables. You could even still use the global variables potentially, hold the config in the package and have it set/update the needed global variables on package load. If the config is scoped to the package though, I’d potentially consider other ways.
There are other cnf files on the global level that you might also need to configure, e.g. ACLs.
As Kalpesh stated, deployer does handle these from a deployment perspective, but you still probably want to commit the files into a repository first and then use repository based deployment to builld/deploy downstream if you’re doing classic style deployment of packages.
If you’re building images from this for execution as containers, you might want to think about how you can inject the configuration into the image so you can use the same image in every environment, which is always my preferred way to treat images - to have the same image, but different configuration injected during the deploy of it into the relevant environment.
Thank you but with password in global variable, format is “gvhandle…” , Do we need only globalVariables.cnf file ?
I believe passwords will be held in config/txnPassStore.dat, so you’d need this as well however this is a binary file where passwords are encrypted (using the master password) and holds more than just the global variable passwords.
As such, you might want to rethink the implementation here.
Whilst you could store this in git, committing passwords into source control really isn’t a great idea, and even though these are encrypted, through the master password, if you checkout to a different dev environment, with a different master password, they won’t be able to decrypt the passwords and they’d need to be reset anyway.
Also, if everyone shares the same master passwords (quite common in dev), then that means anyone can decrypt this after pulling from source control, so doesn’t necessarily protect the password. You might also find that different environments have different passwords and quite possibly different master passwords, and operations teams might control the passwords to a QA/Stage/Prod environment.
Worse still, many people forget to change the master password (even from the default)!
A more simple alternative is to just check the global variable exists before using, and expect it to be defined in each environment. If it’s not defined throw out a warning of some sort. If passwords are different in each environment, you wouldn’t want to always redeploy these anyway. This way an ops team could set the value in production, and a dev team could set the value in dev. But this solution doesn’t work so well with devops automation of builds/etc.
In that context I’ve seen customers use password managers or config management tools for this sort of thing with the password being pulled into the server/environment on build as part of devops processes or first use/startup/etc from the config management server. This means passwords aren’t then ‘distributed’ throughout source control/etc and helps to avoid/remove creating potential attack vectors should a malicious actor get hold of the source.
Whenever passwords are used programmatically, you always need to think carefully about any consequences and proceed with caution.
2 Likes
Additionally you might want to check if using CommandCentral might help you here.
Regards,
Holger