Variables de ambiente/entorno

 

Variables de ambiente/entorno:

Hola, Alguien podría ayudarme, busco una forma de aplicar variables de ambiente PROD/DEV, y poder desde ahí tomar los valores como URL o credenciales de servicios Web o APIs , etc.

============================

Environment variables/environment:

Hi, Could someone help me, I'm looking for a way to apply PROD/DEV environment variables, and from there take values ??such as URLs or Web service credentials or APIs, etc.

By @Cristian23334364163h

Yes, your ColdFusion application can have access to and use environment variables. As you weigh this option, there are some ideas I wish to share with you. They are from personal experience.

Major advantages of environment variables:

1. The Operating System's environment variables comprise essentially a datastore. The variables are globally available to any application running on the Operating System.
PROD and DEV usually run on separate Operating Systems. So, you should have PROD environment variables on PROD's Operating System and DEV environment variables on DEV's Operating System.
Which is best-practice because it fosters "Separation of Concerns".

2.  Obtaining variables from the Operating System usually incurs less network latency than obtaining them from, say, a database such as SQL Server, Oracle or MySQL.

Major disadvantages of environment variables:

1. Environment variables are globally available to any application running on the Operating System. So other applications will have access to the variables that are specific to your ColdFusion application. That may be a security or privacy concern.

2. Environment variables are read-only, immutable. You cannot modify them at the level of the ColdFusion application.

Access and use:

Suppose you wish to access and use the following environment variables in your ColdFusion code:

on PROD:

DB_USERNAME_PROD
PAYMENT_WS_URL_PROD

on DEV

DB_USERNAME_DEV
PAYMENT_WS_URL_DEV

Then you could do it in one of two ways. Either way, you would store the value in application scope, because an environment varible is a global constant.

(1) using native CFML
Which is Charlie's suggestion (mentioned again because I want to add a qualification to it) 

<!--- on PROD --->
<cfset application.DB_USERNAME_PROD = server.system.environment["DB_USERNAME_PROD"]>
<cfset application.PAYMENT_WS_URL_PROD = server.system.environment["PAYMENT_WS_URL_PROD"]>

<!--- on DEV --->
<cfset application.DB_USERNAME_DEV = server.system.environment["DB_USERNAME_DEV"]>
<cfset application.PAYMENT_WS_URL_DEV = server.system.environment["PAYMENT_WS_URL_DEV"]>

The struct keys in this method are case-insensitive by default. So the following variations will also work:

<cfset application.DB_USERNAME_PROD = server.system.environment["DB_username_prod"]>
<cfset application.PAYMENT_WS_URL_PROD = server.system.environment["payment_WS_URL_prod"]>

(2) using Java

<!--- on PROD --->
<cfset systemObject = createObject("java", "java.lang.System")>
<cfset application.DB_USERNAME_PROD = systemObject.getenv()["DB_USERNAME_PROD"]>
<cfset application.PAYMENT_WS_URL_PROD = systemObject.getenv()["PAYMENT_WS_URL_PROD"]>

<!--- on DEV --->
<cfset systemObject = createObject("java", "java.lang.System")>
<cfset application.DB_USERNAME_DEV = systemObject.getenv()["DB_USERNAME_DEV"]>
<cfset application.PAYMENT_WS_URL_DEV = systemObject.getenv()["PAYMENT_WS_URL_DEV"]>

The keys in this method are case-sensitive by default. So the following variations will fail:

<cfset application.DB_USERNAME_PROD = server.system.environment["DB_username_prod"]>
<cfset application.PAYMENT_WS_URL_PROD = server.system.environment["payment_WS_URL_prod"]>