Carolina, me olvide de comentarte de que si es necesario instalar el SIU-Arai si se quiere utilizar el portal de Autogestión demo.

Hola Carolina,

Lo que debes modificar (o mejor dicho setear) es una variable de entorno para poder decirle al SIU-Toba que la carpeta de instalación del proyecto SIU-Arai esta en otro directorio.

Los pasos a seguir son los siguientes:

En la consola de Linux ejecuta lo siguiente:
export toba_instalacion_dir={ruta_al_arai}/instalacion
Si no me equivoco en tu caso es:
 
export toba_instalacion_dir=/usr/local/siu/arai/instalacion
Luego de esto ya deberías poder ejecutar el comando toba sobre el proyecto SIU-Arai, por ejemplo:

/usr/local/siu/arai/toba/bin/toba servicios_web generar_cert -p arai -i produccion
Vamos a proceder a modificar la documentación para contemplar este problema.

Saludos, y por favor comentanos como te fue.

Hola,

Antes que nada, quería comentarte de que no existen WebServices para consultar toda la información que manejan estos 2 sistemas. Los WebServices que tienen cada uno de los sistemas solo contemplan información especifica, y por ahora acotada, supongo que con el tiempo se ira ampliando.

Lo que entiendo que necesitas es conectarte directamente con las bases de datos de cada uno de los sistemas para esto necesitas saber los datos de conexión:

- IP del Servidor
- Puerto (casi siempre 5432)
- Nombre de Base de Datos
- Usuario
- Clave

También vas a necesitar configurar el "schema", pero eso es sabido por cada proyecto en mapuche es "mapuche" y en pilaga es "public".

Un tema no menor si es que deseas conectarte desde otro servidor es que el motor de bases de datos (postgres) este configurado para escuchar consultas desde afuera de su propio servidor  (no viene así configurado por default).

Como un tema mas avanzado, en caso de querer conectarte te recomiendo que crees un usuario especifico para comunicarte con estas bases desde el nuevo servidor.

Para comenzar con el desarrollo de la aplicación te recomiendo que trabajes con copias de las bases de datos de forma local en la maquina que te pongas a desarrollar.

Saludos!

Hola Carolina,

Si, esto que comentas es posible, en la institución donde me desempeño como técnico estamos trabajando en armar un portal que incluya funcionalidades de RRHH tomadas desde los WS del SIU-Mapuche pero con una autenticación centralizada totalmente diferente (LDAP y SSO).

Te recuerdo que el portal de autogestión es una demo de las nuevas posibilidades que brindan los sistemas SIU, pero no esta recomendado que sea utilizado como un producto en producción. Se aconseja a los interesados a que desarrollen sus propios sistemas para integrar los sistemas SIU.

Saludos!

Hola Juan Cruz,

En la Universidad Nacional de Quilmes tenemos varias instancias del SIU-Pilagá en el mismo servidor funcionando sin problemas.

Como bien decís, no es necesario mantener fechas anteriores en las bases de consultas, inclusive resulta peligroso, por que se pueden llegar a hacer movimientos con esa fecha, en el caso de que estén con fecha actual, en alguna oportunidad vi que el SIU-Pilagá valida la fecha y si no es del periodo no te deja operar (tomémoslo como otra medida de seguridad)

Básicamente en la UNQ tenemos 4 servidores donde trabajamos con SIU-Pilagá.

Servidor de Aplicación de Producción (con fecha actual):
- SIU-Pilagá 2014
- SIU-Pilagá 2013 (Solo consulta)
- SIU-Pilagá 2012 (Solo consulta)
- SIU-Pilagá 2011 (Solo consulta)
- SIU-Pilagá 2010 (Solo consulta)

Servidor de Base de Datos de Producción (con fecha actual)

- SIU-Pilagá 2014
- SIU-Pilagá ...
- SIU-Mapuche (solo para mostrar que compartimos el server de BD con otras apps)
- SIU-Diaguita (solo para mostrar que compartimos el server de BD con otras apps)
...

Servidor de Aplicación de Pruebas y Muletos (la fecha varia de la necesidad): 
- Todas las instancias que sean necesarias.

Servidor de Base de Datos de Pruebas y Muletos (con fecha actual): 
- Todas las instancias que sean necesarias.

Algo importante para poder utilizar varias instancias en el mismo servidor, es que deben tener dominios diferentes, sino ya que las rutas son iguales, entre diferentes versiones pueden entrar en conflicto (me sucedió). Ej:

- pilaga.sistemas.unq.edu.ar <-- Producción (actualmente periodo 2014)
- 2013.pilaga.sistemas.unq.edu.ar <-- Instancia de consulta del periodo 2013
- 2012.pilaga.sistemas.unq.edu.ar <-- Instancia de consulta del periodo 2012
- 2011.pilaga.sistemas.unq.edu.ar <-- Instancia de consulta del periodo 2011

Esto se puede hacer via servidor de DNS agregando los registros correspondientes a cada dominio, y luego en el servidor de aplicación que va a hostear los SIU-Pilagá modificando cada uno de los toba.conf agregando algo similar a lo siguiente:

<VirtuaHost *:80>
    ServerName {Aquí va la ruta al dominio de la instancia de SIU-Pilagá}

    {Aquí va la configuración actual sin modificar}

</VirtualHost>

Por ejemplo para nuestra instancia 2013:

<VirtuaHost *:80>
    ServerName 2013.pilaga.sistemas.unq.edu.ar

    {Aquí va la configuración actual sin modificar}

</VirtualHost>

Con esto tambien se podria agregar otras configuraciones como por ejemplo un archivo especifico para logs de apache para cada instancia (proximamente!)

Si tenes mas dudas no dudes en consultarme nuevamente. Espero haber sido claro. Saludos!

Hola Paola, te respondo los dos puntos...

Ahhh.. ya me quedo mas claro!! Te comento que al fin pude generar los certificados y estoy con los comandos para configurar la interacción entre los servicios.
Ya pude ejecutar los 3 primeros comandos. Ahora bien cuando ejecuto el 4to:

$ {ruta_al_sistema}/pilaga/toba/bin/toba servicios_web serv_configurar -p pilaga -i produccion -h
cliente=autogestion -c {ruta_al_certificado_autogestion}/publica.crt

Me sale una pantalla donde me consulta que elija un valor, ¿ingreso como valor el texto "Tramites de Viaticos"?

Sobre este punto debes poner el ID, en este caso"TramitesViaticos"

$ {ruta_al_sistema}/pilaga/toba/bin/toba servicios_web serv_configurar -p pilaga -i produccion -s
cli_arai_tramites -h arai -c {ruta_al_certificado_arai}/publica.crt
$ {ruta_al_sistema}/pilaga/toba/bin/toba servicios_web serv_configurar -p pilaga -i produccion -s
cli_mapuche_categorias -h arai -c {ruta_al_certificado_arai}/publica.crt

¿Que puede ser?

Ahora sobre este punto, trate de reproducir el error pero sin éxito. Te propongo que para realizar una prueba ejecutes el comando con menos modificadores para que se propongan valores en pantalla, por ejemplo ejecuta lo siguiente:

$ {ruta_al_sistema}/pilaga/toba/bin/toba servicios_web serv_configurar -p pilaga -i produccion  -h arai -c {ruta_al_certificado_mapuche}/publica.crt
Si ejecutas el comando anterior, te debería aparecer una pantalla similar a:
Seleccione el servicio web
 --------------------------

+------------------------+------------------------+
| ID                     | VALORES                |
+------------------------+------------------------+
| cli_arai_tramites      | cli_arai_tramites      |
| cli_mapuche_categorias | cli_mapuche_categorias |
+------------------------+------------------------+
 Seleccione un valor perteneciente a la columna "ID"

(valor):
Contame como te fue, y disculpa las demoras, no me estaban llegando las notificaciones del foro.

Saludos!

Hola,

Voy tratando de responderte todas las preguntas:

Pero si estamos simulando la instalación en un entorno en produccion, lo que debiera hacer es ejecutar los comandos no?

No necesariamente hay que generar los certificados con los comandos sueltos, lo que hace el comando 'toba servicios_web generar_cert' es ejecutar los comandos sueltos solo, haciendo lo mas fácil que copiar o escribir todos los modificadores que lleva el comando.

Sobre que es mas correcto en una instancia de producción mi respuesta es que no afecta como lo generes, lo que deberias asegurar que los certificados son diferentes para cada sistema, y que el archivo privado.key es efectivamente privado, nadie mas debe tenerlo mas que el sistema en si... es lo que asegura que ese sistema es quien dice ser y no un atacante haciéndose pasar como un sistema para robarte información.

Entonces te consulto, en pilaga y en arai el archivo openssl tiene que estar dentro del directorio instalacion para poder ejecutar los comandos. Para el caso del Portal, donde debo alojar este archivo, dentro del directorio config?

Para el caso del potal el archivo puede estar donde quieras, el archivo solo es necesario al momento de crear los certificados, una vez que se crearon el archivo openssl.ini no es necesario para operar.

2) Otra duda: en el siguiente paso:
$ {ruta_al_sistema}/pilaga/toba/bin/toba servicios_web cli_configurar -p pilaga -i produccion -s
cli_mapuche_categorias -c {ruta_al_certificado_mapuche}/publica.crt
No existe ruta al certificado mapuche, porque estos se generan solo para SIU-Arai y SIU-Pilaga, entonces que ruta tomo?? la de los certificados de Arai o la de los certificados de Pilaga??

No se como se me paso esta pregunta al responder anteriormente. En el caso del SIU-Mapuche debes generar los certificados tal como lo haces para el Portal de Autogestión, el SIU-Mapuche se encuentra en una versión del SIU-Toba que no cuenta con la herramienta para generar los certificados.

Saludos!