Diferencia entre revisiones de «SIU-Pilaga/version3.12.0/consideraciones tecnicas»
(→Consideraciones técnicas) |
|||
| Línea 42: | Línea 42: | ||
api_key= toba | api_key= toba | ||
</source> | </source> | ||
| − | + | <br /> | |
| − | + | ||
==== '''Conectar SIU-Pilagá con SIU-Diaguita''' ==== | ==== '''Conectar SIU-Pilagá con SIU-Diaguita''' ==== | ||
* '''<u>''En SIU-Pilagá''</u>''' | * '''<u>''En SIU-Pilagá''</u>''' | ||
| Línea 102: | Línea 102: | ||
auth_password = toba ***(password del usuario) | auth_password = toba ***(password del usuario) | ||
</source> | </source> | ||
| − | + | <br /> | |
| − | + | ||
==== '''Conectar SIU-Pilagá con SIU-Guaraní''' ==== | ==== '''Conectar SIU-Pilagá con SIU-Guaraní''' ==== | ||
* '''<u>''En SIU-Pilagá''</u>''' | * '''<u>''En SIU-Pilagá''</u>''' | ||
Revisión del 13:10 29 sep 2022
Sumario
- 1 Consideraciones técnicas
Consideraciones técnicas
Conectar SIU-Pilagá con otros sistemas
Para permitir que otros sistemas puedan acceder a los servicios que SIU-Pilagá tiene disponible
- 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"
- 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:
- 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)
- 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:
- 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-Guaraní
- En SIU-Pilagá
- Para permitir el acceso externo a recursos de SIU-Guaraní, se debe tener en cuenta las siguientes configuraciones:
- Crear una carpeta con el nombre guarani (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/guarani/trunk/rest/" ***(es donde apunta la instalación SIU-Guarani sumado del “/rest”)
auth_tipo = digest ***(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:
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
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.12.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:
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:
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
