SIU-Pilaga/version3.11.0/consideraciones tecnicas

Consideraciones técnicas

Conectar SIU-Pilagá con otros sistemas

Para permitir que otros sistemas puedan acceder a los servicios que SIU-Pilagá tiene disponible

1. Se debe verificar la configuración del archivo servidor.ini ubicado en la siguiente ruta

   SIU-Pilaga/instalacion/i__produccion/p__pilaga/rest/servidor.ini

   autenticacion = digest
   
   ;;
   ;;Opciones que recibe la librería - > rest/rest.php
   ;;
   [settings]
   formato_respuesta = "json"
   url_protegida = "/(?=^((?!notificaciones).)+$)/xs"
   encoding = "utf-8"
   
   [v1]
   path_api = "SIU-Pilaga/php/rest/v1"
   ;path_api_pers = "SIU-Pilaga/personalizacion/php/rest/v1"

2. También se debe configurar el archivo servidor_usuarios.ini ubicado en la siguiente ruta

   SIU-Pilaga/instalacion/i__produccion/p__pilaga/rest/servidor_usuarios.ini

   El contenido de dicho archivo debe ser similar a lo siguiente, quedando configurados los usuarios que se utilizarán desde SIU-Pilagá. Este archivo puede contener otros usuarios para otros sistemas.

   [toba] *** (es el nombre del usuario que se puso en el archivo cliente.ini)
   password = toba *** (es el password del usuario que se puso en el archivo cliente.ini)
   api_key= toba

Conectar SIU-Pilagá con SIU-Diaguita

• En SIU-Pilagá

Para permitir el acceso externo a recursos de SIU-Diaguita, se debe tener en cuenta las siguientes configuraciones:

1. Crear una carpeta con el nombre diaguita (en minúsculas) en el directorio:

   SIU-Pilaga/instalacion/i__produccion/p__pilaga/rest

   Dentro de esta carpeta crear un archivo llamado cliente.ini, que va a contener lo siguiente:

   [conexion]
   ;;Recuerde dejar una barra (/) al finalizar la URL
   to = "http://localhost/diaguita/trunk/rest/" ***(es donde apunta la instalación Diaguita sumado del “/rest”)
   
   auth_tipo = digest ***(tipo de autorización)
   auth_usuario = toba ***(nombre del usuario)
   auth_password = toba ***(password del usuario)

2. Por ultimo se debe delimitar los siguientes parámetros en la base de datos de Pilagá:

   controla_comprobant_imputacion ---> Activada (Valor por defecto Activada)
   conexion_diaguita ----------------> Activada (Valor por defecto Desactivada)

   Se puede configurar desde la base de datos o funcionalmente a través de la siguiente ruta: Administración / Configuración de parámetros

• En SIU-Diaguita
  

  Para permitir que SIU-Diaguita acceda a recursos de SIU-Pilagá ir a Conectar SIU-Diaguita con SIU-Pilagá

Conectar SIU-Pilagá con SIU-Mapuche

• En SIU-Pilagá

Para permitir el acceso externo a recursos de SIU-Mapuche, se debe tener en cuenta las siguientes configuraciones:

1. Crear una carpeta con el nombre mapuche (en minúsculas) en el directorio:

   SIU-Pilaga/instalacion/i__produccion/p__pilaga/rest

   Dentro de esta carpeta crear un archivo llamado cliente.ini, que va a contener lo siguiente:

   [conexion]
   ;;Recuerde dejar una barra (/) al finalizar la URL
   to = "http://localhost/mapuche/trunk/rest/" ***(es donde apunta la instalación SIU-Mapuche sumado del “/rest”)
   
   auth_tipo = Basic ***(tipo de autorización)
   auth_usuario = toba ***(nombre del usuario)
   auth_password = toba ***(password del usuario)

Conectar SIU-Pilagá con SIU-Arai Proveedores

Configuración de la base de datos de Arai Proveedores

Para configurar el SIU - Araí Proveedores se debe configurar los parámetros de conexión a la base de datos de Araí Proveedores en el archivo instalador.env

###### CONFIG DE BASE DE DATOS ARAI PROVEEDORES ######
ARAI_PROV_DB_HOST=localhost
ARAI_PROV_DB_PORT=5432
ARAI_PROV_DB_DBNAME=db_arai_proveedores
ARAI_PROV_DB_USERNAME=postgres
ARAI_PROV_DB_PASSWORD=postgres
ARAI_PROV_DB_SCHEMA=public (NO MODIFICAR)
ARAI_PROV_DB_ENCODING=UTF8 (NO MODIFICAR)

Variable de entorno	Descripción
ARAI_PROV_DB_HOST	el host/ip del equipo donde corre la base de datos
ARAI_PROV_DB_PORT	el puerto donde corre la base de datos
ARAI_PROV_DB_DBNAME	el nombre de la base de datos de proveedores
ARAI_PROV_DB_USERNAME	el usuario para la conectarse a la base de datos
ARAI_PROV_DB_PASSWORD	la clave del usuario para conectarse a la base de datos
ARAI_PROV_DB_SCHEMA	el nombre del esquema dentro de la base de datos (NO MODIFICAR)
ARAI_PROV_DB_ENCODING	la codificación de caracteres de la base de datos. (UTF8 por defecto) (NO MODIFICAR)

Una vez configurado los parámetros, al ejecutar el proceso de instalación o actualización automáticamente genera la base de datos central de Araí Proveedores con la estructura de datos actualizada y configura la conexión en SIU-Pilagá.

Para obtener mayor información acerca de la sincronización podrán encontrar los pasos para | ejecutar la sincronización por linea de comandos

Estados de Sincronización

El cambio de los estados se puede hacer manualmente desde los parámetros del sistema, para modificarlo vamos a:

Administración/Configuración de Parámetros (aplicar_sincronizacion_arai_prov)

Modo conectado (valor sí): cada cambio que se realice se sincroniza automáticamente con la base de Araí Proveedores.

Modo desconectado (valor desconectado): si por algún motivo se cae la conexión con la red, se tendrá que poner este estado para poder cargar proveedores y seguir operando. Una vez que se restablezca la conexión, pedirá que se realice una sincronización inicial.

(Valor no): no se utiliza la funcionalidad Araí (en Pilagá), se carga personas/proveedores sin sincronizarse de manera normal.

Conectar SIU-Pilagá con la AFIP

Los pasos que se describen a continuación permiten configurar el acceso a recursos de la AFIP expuestos mediante servicios web.

Uso

En primer lugar para poder utilizar el servicio es necesario generar un certificado y clave privada tipo openssl.

Luego desde el portal de AFIP:
- Ingresar con clave fiscal
- Ingresar al servicio Administración de Certificados digitales (en el caso de no encontrarlo, agregarlo por el Administrador de Relaciones de Clave AFIP).

• Crear "Alias" para el certificado, e importar el certificado CSR, guardar.
• Identificar el "Alias", click en "Ver detalle", y descargar certificado CRT.

- Una vez generado el certificado se debe autorizar el servicio:

• Desde Administrador de Relaciones, habilitar Servicio ---> Consultas Padrón A4 (ws_sr_padron_a4).
• En la ventana de agregar, asociar un controlador fiscal, haciendo clic en Buscar de la línea de Representante, aparecerá la posibilidad de seleccionar el Alias generado previamente, seleccionarlo como computador fiscal. Luego clic en botón Confirmar.

Por ultimo el certificado descargado desde AFIP se debe guardar en la instalación de Pilagá. Ver apartado Configuración.

Para obtener mayor información de como obtener el certificado y la clave para utilizar el servicio ir a | Documentación Técnica de los WS de AFIP

Configuración

Una vez generado el certificado y la clave en Afip se debe proceder a configurar en el archivo instalador.env los parámetros de configuración de la Api.

###### CONFIG AFIP WS ######
AFIP_WS_CUIT=cuit
AFIP_WS_CERT=/ruta/a/cert
AFIP_WS_KEY=/ruta/a/key
AFIP_WS_TOKEN_DIR=/ruta/a/generacion/token

Parámetros de configuración disponibles

Parametro	Descripcion
AFIP_WS_CUIT	(int) El CUIT a usar en los Web Services.
AFIP_WS_CERT	(string)Ruta absoluta donde se encuentra el certificado
AFIP_WS_KEY	(string)Ruta absoluta donde se encuentra la clave
AFIP_WS_TOKEN_DIR	(string)Ruta absoluta donde la lib genera el token (requiere permisos de escritura)

-> Una vez configurado los parámetros, al ejecutar el proceso de instalación o actualización automáticamente genera la configuración en SIU-Pilagá y una vez finalizada la instalación ya se podrá usar el servicio de Afip en el sistema.

-> Si solo se configura la vinculación con AFIP, sin cambiar la versión del módulo, luego de la configuración de los parámetros ejecutar el comando:

./bin/instalador proyecto:reconfigurar afip

Anonimizar la Base de datos

Backup Anonimizado

Éste es un comando pensado para que cuando necesiten enviar su base de datos, por algún problema, lo hagan de forma que los datos no contengan valores reales de las personas.
La forma de utilizar este comando es la siguiente:
Acceder por línea de comandos a la carpeta bin del sistema y ejecutar

Para Linux

sh pilaga.sh base anonimizar_base

El backup anonimizado será exportado dentro de la carpeta que se especifica en el archivo ../bin/pilaga.sh para la variable "pilaga_directorio_exportacion"
Cuando se corre el comando para exportar la base, lo que está haciendo el comando es ejecutar un pg_dump y luego pasarle esos datos a un ejecutable llamado mask.
Éste ejecutable compilado en C recorre la salida del pg_dump y compara los datos con un archivo llamado mask.conf.pilaga.
En ese archivo lo que se tiene es el esquema, tabla, campo y función para anonimizar, entonces devuelve un campo anónimo según la función utilizada.

Configuración para utilizar comprobantes Jasper/PDF

Requisitos previos

Tener instalado, Java Runtime Environment 1.8.x (se requiere JRE debido a que se utiliza la tecnología JasperReports para realizar la generación de todos los documentos/comprobantes emitidos por el sistema)

Consideración técnica

Jasper en el java bridge define una constante JAVA_PIPE_DIR =/dev/shm, para evitar el uso de este directorio que refiere al uso de memoria compartida (en el existen problemas de permisos), se puede configurar en el php.ini (al fin del mismo) el parámetro de la siguiente manera, como por ejemplo:
java.pipe_dir = /usr/local/SIU-Pilaga-3.11.1/temp
Tener en cuenta que se debería elegir un directorio físico del servidor que sea constante y perdure en el tiempo, ya que el ejemplo no contempla la actualización del sistema por lo que siempre seria necesario estar modificando el php.ini, esto queda a abiertamente a criterio del técnico el cual brindara los permisos necesarios a esa carpeta vinculada en la variable.

Ejecución del motor Jasper

Iniciar el servidor de JasperReports, situándose en .../SIU-Pilaga/bin, y ejecutar el siguiente comando:

sudo pilaga_reportes.sh start

Importante: Este comando tiene que estar siempre activo para que se puedan generar los comprobantes en jasper.

Una estrategia para asegurar que el motor de jasper esté siempre en ejecución es hacerlo mediante un sistema de control de procesos como supervisord (http://supervisord.org/), este se encarga de que el proceso siempre este activo y si se reinicia el servidor el proceso también se inicie.

Envíos de email

Configuración servidor SMTP

Para configurar el envío de e-mails se debe configurar el archivo instalador.env

###### CONFIG ENVIO MAILS (SMTP) ######
#SMTP_HOST=smtp@universidad.edu.ar
#SMTP_PORT=25
#SMTP_FROM=no-reply@universidad.edu.ar
#SMTP_USUARIO=no-reply@universidad.edu.ar
#SMTP_CLAVE=ClaveSmtp123
#SMTP_AUTH=1
#SMTP_SEGURIDAD="ssl|tls"
#SMTP_HELO=""
#SMTP_AUTO_TLS=1
#SMTP_EMAIL_PRUEBA=pruebas@universidad.edu.ar

A continuación se describe cada variable de entorno:

Variable de entorno	Descripción
SMTP_HELO	nombre HELO del host del servicio SMTP
SMTP_HOST	host del servicio SMTP
SMTP_PORT	puerto del servicio SMTP
SMTP_FROM	dirección que envía el mail
SMTP_SEGURIDAD	el tipo de seguridad SMPT. Puede ser ssl o tls
SMTP_AUTH	si requiere autenticación. Puede ser 1 o 0
SMTP_USUARIO	el usuario con el cual autenticar en el SMTP
SMTP_CLAVE	la clave del usuario
SMTP_AUTO_TLS	habilita o deshabilita tls (1 = Si, 0 = No)
SMTP_EMAIL_PRUEBA	cuenta de email donde se envían todas las notificaciones de email en entornos de prueba (No envia email a los proveedores)

Si se modifica algún parámetro de la configuración de SMTP en una instalación existente, para que impacte el cambio en el sistema se debe ejecutar el siguiente comando de reconfiguración:

./bin/instalador proyecto:reconfigurar smtp

Envíos de email de forma asíncrona

Esta funcionalidad permite a las operaciones que realizan envíos de email poder hacer los envíos asincronicamente, esto significa que la operación puede continuar y el usuario puede seguir operando en el sistema mientras que en un segundo plano se envían los emails sin detener el funcionamiento del sistema.

La cola de mensajes se almacena temporalmente en la base de datos de negocios en un schema llamado queue en una tabla llamada queue.

Inicializar cola de envíos

Al ejecutar el proceso de instalación o actualización del sistema, el instalador generará en el schema queue, la tabla queue donde se almacenara la cola de mensajes para ser enviado de forma asíncrona.

Lanzar worker de cola de emails

Una vez finalizada la instalación o actualización del sistema, cada vez que una operación envía un email este se almacena en una cola de emails en una tabla en la base de datos. Para que esta cola de mensajes sea leída en forma asíncrona y realice los envíos se debe mantener corriendo el siguiente comando en el servidor:

./pilaga.sh iniciar_workers_emails -p pilaga

Una vez ejecutado el comando este inicia un worker que queda en la espera de nuevos mails que se envían a la cola para tomar el mensaje y enviar mediante SMTP el correo electrónico relacionado con el mensaje de la cola al destinatario correspondiente.

Importante: Este comando tiene que estar siempre activo para que se puedan enviar los mails, ver supervisord

Tomar en cuenta que para el correcto funcionamiento del worker son necesarias configuraciones adicionales respecto a parámetros, templates, y filtros que se pueden encontrar aquí.

Logs

Por cada envió se genera un log con información de los mensajes enviados correctamente y los que se generaron un error al enviar, además registra log de si se genera alguna excepción en la ejecución del mismo. Este log se almacena el la carpeta del proyecto que está dentro del directorio de instalación, en el directorio de logs y el archivo tiene el nombre queue.log

Parámetro de sistema

El envío de cada email tiene configurado un retraso por defecto de 3000 milisegundos para evitar que se colapse el servidor SMTP al enviar de forma masiva una cierta cantidad de emails, si se necesita aumentar el valor del tiempo de retraso se debe hacer mediante la configuración de parámetros del sistema, modificando el parámetro llamado em_mensaje_retraso.

Bandeja de emails fallidos

En el caso que el envío de un email falle se almacenará cada email no enviado en una tabla ‘sau_em_mensaje_reenvio’, luego se puede visualizar un listado de los emails no enviados en la operación Bandeja de emails sin enviar que se encuentra dentro del menú de Administración y luego Opciones email. Desde esta operación se puede seleccionar uno o varios emails y volver a enviar, y en el caso de que vuelvan a fallar se volverán a registrar en la tabla de ‘sau_em_mensaje_reenvio’ para que en cualquier momento se vuelva a intentar el reenvío. En el caso de que no se quiera volver a enviar se puede seleccionar uno o varios emails del listado y eliminarlos definitivamente.

Instalación y configuración de worker en Supervisord

Para asegurar que los workers están siempre en ejecución es hacerlo mediante un sistema de control de procesos como supervisord (http://supervisord.org/), este se encarga de que el proceso siempre este activo y si se reinicia el servidor el proceso también se inicie.

Se recomienda el siguiente ejemplo de instalación y configuración de supervisord

El siguiente ejemplo muestra una configuración para el worker de cola de emails, creado en /etc/supervisor/conf.d/pilaga-email-worker.conf:

Ejemplo de configuración en Supervisord (pilaga-email-worker.conf):

[program:pilaga-email-worker]
command=<pilaga-path>/bin/toba proyecto iniciar_workers_emails -p pilaga
autostart=true
autorestart=true
stderr_logfile=/var/log/pilaga-email-worker_err.log
stderr_logfile_maxbytes=2MB
stderr_logfile_backups=10
stderr_capture_maxbytes=1MB
stdout_logfile=/var/log/pilaga-email-worker_stdout.log
stdout_logfile_maxbytes=10MB
stdout_logfile_backups=10
stdout_capture_maxbytes=1MB

Actualización del worker

Una vez realizada la actualización del sistema el <pilaga-path> deberá modificarse en el archivo anteriormente configurado.
Seguido a esto para que el Supervisord tome los cambios correspondientes deberán ejecutarse los siguientes comandos en este orden:

sudo supervisorctl stop
sudo supervisorctl reread
sudo supervisorctl update
sudo supervisorctl start all

---

<Volver