Requerimientos HS para SoflandERPWEB OnPremise

I. Introducción

El presente documento es un compendio de los principales requerimientos de hardware y
software, necesarios para el adecuado funcionamiento de Softland ERP Web.

La información a que se hace referencia constituye una guía para efectos de dimensionar
recursos para esta aplicación; por lo tanto, no debe considerarse como una recomendación
formal y definitiva de Softland, cualquiera de las subsidiarias, o funcionarios, para efectos de
compra de hardware y software. Esto por cuanto son múltiples variables las que en un
momento dado determinan las características y requerimientos precisos de recursos para la
combinación de productos y tecnologías que se tienen o esperan adquirir.

Es importante mencionar que si bien la información que aquí se incluye trata de ser lo más
completa posible, no necesariamente los requerimientos documentados son los que
representan la totalidad de estos. Asimismo, debido a la lógica evolución de los productos
de software, tanto de Softland como de terceros, puede ocurrir que sin previo aviso una
especificación o requisito en particular cambie. Se sugiere consultar siempre la última
versión del documento la cual estará disponible en el área de clientes del Web site de
Softland

Se espera que este instrumento sirva tanto a funcionarios de Softland, aliados y clientes. En
procura de conservar la información lo más completa y veraz posible, se insta a contribuir
con el mejoramiento de este documento refiriendo sus sugerencias de mejora y corrección
por medio del portal de clientes de Softland.

El siguiente diagrama muestra los elementos que deben ser tomados en cuenta en la
instalación del producto en instancias administradas por el cliente

II. Servidor de base de datos

Requerimientos de Software Servidor de Base de datos

Sistema Operativo

En todos los casos es preferible actualizar el Sistema Operativo al último Service Pack
disponible.

Motor de Base de Datos (SABD/DBMS)1

Nota importante: El nombre de la base de datos no puede contener números o caracteres
especiales al inicio, por ejemplo: 8290SOFTLAND; crear una base de datos con este contenido
genera una serie de errores en algunas consultas del sistema por lo tanto técnicamente no
es recomendable hacerlo de esa manera.

Requerimientos de Hardware servidor de base de datos

Se recomienda que el servidor sea exclusivo para alojar la base de datos del ERP, es decir que
no sea un servidor de aplicaciones.

Requerimientos:

La configuración del servidor dependerá del motor de base de datos elegido (Oracle o SQL
Server), crecimiento de datos en la base de datos, la cantidad de usuarios concurrentes y el
nivel transaccional esperado, entre otras cosas. Por tanto, es recomendable que el cliente
recurra al fabricante de la base de datos para efectos de dimensionar mejor los equipos que
desea/debe adquirir.
Se recomienda elegir una configuración mínima que permita operar de forma razonable por
al menos un plazo de dos años (alcanzando al término de dicho plazo un máximo del 80%
de consumo de los recursos).
Es posible considerar la siguiente guía para ajustar la configuración requerida para su
servidor:

Algunas referencias que se pueden consultar para efectos de evaluación y selección de
servidores son:
https://www.dell.com/empresas/p/servers.aspx
https://www.hpe.com/lamerica/es/h

 

III. Servidor de aplicaciones
Requerimientos de Hardware y Software servidor de aplicaciones

Consumo de Memoria
Tabla Recomendada de Memoria tomando en cuenta la carga de empleados o bien la
cantidad de usuarios.

*LA FAMILIA DE PROCESADORES XEON DE INTEL O SUPERIOR ES MÁS RECOMENDADA PARA SERVIDORES DE APLICACIONES DE ALTA DEMANDA DE TRABAJO Y DESEMPEÑO. AYUDA DE FORMA IMPORTANTE A MEJORAR EL PODER DE PROCESAMIENTO Y TIEMPOS DE RESPUESTA DE APLICACIONES PARA INTERNET, SERVIDORES DE CORREO, PEQUEÑAS BASES DE DATOS Y APLICACIONES
TÉCNICAS MODERADAS EN CÁLCULOS
*VER TABLA DE CONSUMO DE MEMORIA SEGÚN LA CANTIDAD DE USUARIOS

Recomendaciones de publicación

Establecer una página segura con un Certificado de Seguridad y activación de TLS 1.2 en la
comunicación entre los navegadores y el servidor de aplicaciones.
Tener el IIS del sistema operativo activo.

IV. Dispositivos desde los cuales se utiliza la aplicación
Hardware Recomendado

Navegadores certificados:
- Firefox
- Edge
- Chrome

V. REQUERIMIENTOS DE SOFTWARE API GATEWAY
     Requisitos para la Instalación del Conector de APIs

El conector de APIs ha sido diseñado para facilitar la integración entre sistemas mediante la
exposición de servicios web RESTful, permitiendo una comunicación eficiente, fluida y segura
entre las aplicaciones. Este componente se instala en un servidor con Internet Information
Services (IIS) y se conecta directamente a la base de datos del sistema ERP.

Requisitos para la Instalación:

1. Servidor IIS
     • Versión de IIS: 7.0 o superior
     • Sistema Operativo: Windows Server 2016 o superior
     • Espacio en Disco: Mínimo 2 GB libres
     • Memoria RAM: Al menos 16 GB
2. Base de Datos
     • Tipo: SQL Server 2016 o superior
     • Acceso: Usuario con permisos de lectura y escritura
     • Conexión: Cadena de conexión proporcionada por el cliente o configurador
3. Red y Seguridad
     • Puertos: Asegurar la apertura de los puertos necesarios entre IIS y la base de datos
     • Certificados: Certificado SSL instalado para cifrado de comunicaciones
     • Protocolos: Habilitación de TLS 1.2 para conexiones seguras entre navegador y servidor
4. Software Adicional Requerido
     • Plataforma: Desarrollado en .NET 8.0
     • Dependencias necesarias en IIS:
          o Microsoft ASP.NET 8.0
          o Microsoft .NET Runtime 8.0
          o Microsoft .NET 8.0 – Windows Server Hosting Bundle

Este paquete de hospedaje incluye el runtime, el soporte para ASP.NET y la compatibilidad con
IIS. Está disponible en el instalador proporcionado y también se incluye automáticamente en el
asistente de instalación del conector.

Recomendaciones Técnicas

Las recomendaciones técnicas presentadas en esta sección se basan en una serie de pruebas de
rendimiento realizadas en un entorno controlado en la nube. Para estas pruebas se utilizó un
único servidor que alojó tanto el API Gateway como la base de datos, con el fin de simular
condiciones representativas del entorno operativo.
Especificaciones del entorno de prueba:
• Memoria RAM: 16 GB
• Almacenamiento: 126 GB de disco duro
Con el objetivo de evaluar la capacidad de respuesta y la estabilidad del API, se llevaron a cabo
pruebas utilizando diferentes volúmenes de registros por solicitud: 100, 1,000, 5,000, 10,000 y
20,000. Estas pruebas se aplicaron a cada uno de los endpoints disponibles en el sistema,
permitiendo medir el comportamiento en condiciones de carga progresiva.
Los resultados obtenidos sirvieron como base para definir los límites recomendados por solicitud
y por día, garantizando un rendimiento óptimo en entornos productivos.
Propuesta de Límites por Endpoint
A continuación, se presenta la propuesta de límites máximos de transacciones por solicitud y por
día para cada endpoint. Estos valores se determinaron en función de los tiempos de respuesta,
la latencia observada durante las pruebas y el propósito funcional de cada endpoint

     1. Creación: En este caso se utilizó el endpoint de creación de empleados como referencia;
     sin embargo, la misma lógica y comportamiento aplica a otros endpoints de creación,
     como los correspondientes a clientes, artículos, entre otros.

Creación de Empleados
Sugerencia de limites

Cantidad máxima por solicitud: 1,000
Cantidad máxima por día: 4,000
Se recomienda establecer un límite máximo de 1,000 registros por solicitud, con base en los
resultados obtenidos durante las pruebas de rendimiento.
Adicionalmente, se define un límite diario de 4,000 registros, pensado para ofrecer flexibilidad
en entornos con múltiples compañías dentro de la misma base de datos del ERP

Cabe destacar que también se llevaron a cabo pruebas con 20,000 empleados en una única
solicitud. Aunque se observó un aumento en el tiempo promedio de procesamiento, el API se
comportó de manera estable y sin errores críticos.

     2. Modificación: En este caso se utilizó el endpoint de modificación de empleados como
     referencia; no obstante, la misma lógica de operación y comportamiento aplica a otros
     endpoints de modificación, como los de clientes, artículos, entre otros.

Modificación de empleados
Sugerencia de limites

Cantidad máxima por solicitud: 1,000
Cantidad máxima por día: 6,500
Se plantea una sugerencia similar a la aplicada en la creación de empleados, estableciendo un
límite máximo de 1,000 registros por solicitud.
Asimismo, se ha incrementado el límite diario de registros para permitir modificaciones masivas
de empleados en situaciones puntuales. Aunque este tipo de actualizaciones no son frecuentes,
pueden ser necesarias ante eventos como la incorporación de un nuevo campo en el ERP, ajustes
por requerimientos legales o procesos de reorganización interna.

     3. Carga: En este caso se hace referencia a la carga de conceptos de nómina como ejemplo,
     sin embargo, la misma lógica y relación de procesamiento aplica a los distintos endpoints
     de carga disponibles en el sistema, tales como clientes, artículos, entre otros.

Carga de conceptos a nómina
Sugerencia de limites

Cantidad máxima por solicitud: 5,000
Cantidad máxima por día: 30,000
Se recomienda establecer un límite de 5,000 registros por solicitud, considerando que los
conceptos gestionados mediante esta funcionalidad suelen corresponder a rubros variables del
empleado, como horas extra, bonos o deducciones por préstamos, entre otros.
Adicionalmente, se ha incrementado el límite de registros diarios a 30,000, lo que permite, por
ejemplo, que una empresa con 1,000 empleados cargue hasta 30 registros por persona en un
mismo día. Esto proporciona mayor flexibilidad y capacidad para la gestión eficiente de la
nómina.

Conclusiones Generales

• El procesamiento frecuente de transacciones masivas incrementa significativamente el
consumo de memoria en SQL Server. Esto se debe a que el motor administra la memoria de
forma dinámica, expandiéndola según la demanda y reteniéndola para mejorar el
rendimiento de consultas futuras.
No obstante, la liberación de memoria no es inmediata, ya que SQL Server prioriza la
reutilización interna antes de liberar recursos al sistema operativo. Como consecuencia, un
uso intensivo y constante puede aumentar la carga sobre los recursos disponibles. Para
mantener un rendimiento óptimo y evitar impactos sobre otros procesos de menor volumen,
se recomienda aislar estos escenarios de alta demanda en componentes dedicados.