HI All,
I need to configure/fetch different values for a variable at each environment level.
Assume that there is a string variable called "passcode " in Input/Output tab,
I have to fetch value for the variable.
It should be
For DEV=> abc123,
For SIT=> def321
For PROD=>3a2b1c
Are there any alternate solutions to fetch the value apart from Global variable option?
Hi Mohammed,
which version of wM are you using?
Most likely the global variable option is the easiest variant to implement as it relies on built-in-services.
For further assistance I would like to ask you to describe your use case in more detail.
Regards,
Holger
You may also try extended settings and use pub.utils:getServerProperty. What i like is you can define the default value in case setting is not configured.
Unlike global variables where the service fails and stops its execution it works like a charm.
Hello Mohammad,
Global variables is one of the good ways to hold your environment specific values, specially the secrets, by checking “is password” checkbox.
Any reason you are looking for different ways to achieve this?
One good way is to have these passcodes maintained in a file as configuration, and you fetch them from file system.
Have respective environment’s file hold the value of passcode specific to that environment. ( One time setup )
Pros:
Passcodes remain secure with only Admins having access.
Changing passcodes can be done in much easier way.
Another way you can achieve this, with some level of hardcoding. ( use only if these passcodes are not sensitive secrets)
Define a global variable which will return you the name of current_env ( Dev, Test, Prod etc )
Define a service with which will have all the env passcodes hardcoded in it, and based on the value of global variable current_env, it will return respective env’s passcode.
Downside of this approach will be changing passcodes will result in code change.
If you commit code to snv, all your passcodes are accessible to all developers. security issue.
While global vars and server properties are possibilities, I would advise against them. Naming scheme and scalability are two of the concerns. Easy to lose control of what gets defined and inadvertently clobbering something.
Our approach is to use a configuration or properties file of some sort that is independent of packages. We store them in their own directory. Typically named similarly to the package that uses the config, or logical name if it has more general-purpose config.
You can use properties files, as defined by the Java Properties class. You can create a common Java service to load a properties file and return an IS document to the caller. You can also use an XML file or a JSON file and use WmPublic services to load them as IS documents.
For passwords, you can use the the outbound password store provided by IS and use the WmPublic services to store/load them. We use that facility and created .dsp pages to use within IS Administrator to define/update passwords. We created a naming scheme for those. Then in the config files, we used a scheme to store the password store key for the applicable password and updated the “loadConfig” service recognize those keys and automatically lookup the key to get the password and return it in the IS doc.
Perhaps one of these additional options would work in your situation.
Hi Rob,
While property files have been great in the past, they become a big problem during containerization and cloud native transformations.
Our experiences taught us to keep them out of files - either centralize them to an external store and cache them or keep them to be as extended settings so that we can use Auto configure properties.
Just sharing the experiences.
Yes, definitely pros/cons to each approach and varies for specific installation detail. As usual, it is a trade-off of flexibility, complexity, etc.
We have a good naming convention that imposes order on global variables, but they are still unsatisfying. The biggest issue is that they are all stored in a single config file, with no separation for packages, environments, etc. This necessitates error-prone manual steps in deployments
I have seen the “WxConfig” module from Software Ag and it seems designed to address all of these concerns. But for some reason they won’t even offer it anymore.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.