Envvar Config
Desde la version 3.1.0 de SIU-Toba se cuenta con un objeto que se utiliza como concentrador de configuraciones, las cuales se utilizan durante el runtime tanto de comandos como de la aplicación.
Dicho objeto se invoca a traves del instanciador toba::config() y se puede:
- Obtener los datos de toda una sección de configuración
- Obtener los datos de un parámetro puntual
- Consultar la existencia de un parámetro puntual
- Agregar archivos ini particulares de la aplicación al objeto
A partir de la version 3.1.12 se agrega además la posibilidad de que los valores en dichos archivos sean el reflejo de variables de entorno.
Para que SIU-Toba reconozca los valores en los archivos como variables de entorno, se deben especificar los mismos con el siguiente formato $env(VAR_NAME)$, de esta manera podemos tener un archivo instancia.ini definido de la siguiente manera:
[toba_referencia]
path = "/usr/local/app/vendor/siu-toba/framework/proyectos/toba_referencia"
url = "$env(ALIAS_TOBA_REFERENCIA)$"
full_url = "$env(SERVER_SCHEME)$://$env(DOMINIO_APLICACION)$/$env(ALIAS_TOBA_REFERENCIA)$"
De manera similar podemos actuar sobre el resto de los archivos de configuración del framework.
Existen archivos que al tener un contenido más dinámico y con una cantidad de entradas variable, son más complicados de sumar a este esquema, requieren mas trabajo que si directamente incluyeramos los valores propiamente dichos.
Tal es el caso de los datos de autenticación para web services, por ejemplo para un mecanismo basic deberiamos tener una multiplicidad de lineas de la siguiente forma:
[$env(VARIABLE_ID_USUARIO)$]
password=$env(VARIABLE_PWD_USUARIO)$
Donde cada entrada requeriría de dos variables de entorno, algo que rápidamente puede convertirse en un problema de gestión. Para este caso, adoptamos un esquema "comprimido" donde definimos una única variable de entorno con la información que necesitamos.
API_BASIC_CLIENTES='[["usr1","pwd1],["usr2", "pwd2"],...]'
De manera similar si utilizamos como método de autenticación SSL definiriamos una variable de entorno API_SSL_CLIENTES y de esa manera se evita el procesamiento del archivo servidor_usuarios.ini.
En el caso de los clientes REST, la situación es similar en algún punto.. ya que la estructura del archivo es fija pero la cantidad de archivos de configuración, va variando de acuerdo a los WS que se consumen.
Para no tener que recurrir a agregar dichos archivos de manera dinámica, es que podemos definir los datos para consumir el WS en una variable de entorno con el siguiente formato.
CREDENCIALES_API_BASIC_IDWEBSERVICE='[["usr_id", "usr_pwd", "url_ws"]]'
Como el mecanismo de autenticación lo define cada WS, por el momento esta opción solo esta disponible para la autenticación basic.
Estos mecanismos "comprimidos" para Web Services se encuentran disponibles a partir de la versión 3.3.6 de SIU-Toba.
A partir de la version v3.4.0 de Toba es posible agregar un componente extra en la configuración del cliente.
Dicho componente representa la versión de la API que se quiere consumir, de esta forma se separa la URL del host que provee la API de la versión de la misma.
Este dato puede ser recuperado por el cliente invocando el metodo toba_servicio_web_cliente_rest::get_datos_conexion(ID_SERVICIO) en caso de necesitar realizar chequeos de compatibilidad que determinen la porcion de codigo a ejecutarse.
De esta forma, la configuración en formato comprimido quedaria de la siguiente manera:
CREDENCIALES_API_BASIC_IDWEBSERVICE='[["usr_id", "usr_pwd", "url_ws", "version_ws"]]'
El formato del parametro version_ws se corresponde con el número de versión de API deseado, por ej: 1.0 para la API v1, en gral como se utiliza la version major el segundo componente (aunque debe estar presente) puede ser cualquier número.
La URL final de impacto del servicio se generara haciendo uso de los ultimos 2 componentes (si se encuentran presentes), esto es url_ws y el valor correspondiente al indice principal de version_ws (o major version):
to = url_ws[/v(major-value)]