El día de hoy hemos escogido un tema de tipo técnico, algo de lo que nunca habíamos escrito anteriormente, pero creo puede aportar al conocimiento de la comunidad. Existen varias formas de implementar SAP Business One, ya sea una instalación dentro de una empresa (mejor conocida como On-Premise) o en la nube (proveedores como Amazon, Google o Azure). Boyala, desde sus inicios, nació como una instalación en la nube, y con el tiempo ha ido evolucionando a diferentes formas de implementación. Pero, ya sea que tengas un proyecto On-Premise o Cloud, siempre puedes hacerte esta pregunta ¿Configurar el acceso de SAP Business One utilizando versión WEB o Remote Desktop? Hoy exploraremos estas dos formas de implementación y algunas ventajas o desventajas de cada una. Veamos.
Remote Desktop (RDS)
Esta fue la primera forma de implementación que manejamos en el 2013. Básicamente una implementación de este tipo se compone de la instalación del sistema en un servidor al que el usuario accede remotamente. Es un tipo de instalación bastante usado en las empresas por su facilidad de mantenimiento y configuración. Anteriormente, tenías que instalar el cliente de SAP Business One en la máquina de los usuarios y cuando tocaba hacer un mantenimiento o actualización, entonces la ventana de tiempo era larga porque había que actualizar máquina por máquina.
Ahora, dentro de las instalaciones de este tipo hay una variante que es la recomendada para internet público, y es el uso de Gateways para la conexión remota. El Gateway sirve de enlace con el mundo exterior a través de un puerto seguro y permite publicar solamente la aplicación que desees. A diferencia del Remote Desktop, no tienes un escritorio, si no que solamente abres la aplicación como si estuviera instalada en la máquina. El RemoteApp, como se le conoce, es compatible en casi todos los dispositivos MAC, PC, iOS y Android, lo que hace que la aplicación se pueda usar prácticamente en cualquier ambiente. Aparte, durante esta pandemia, los ataques a servidores de Remote Desktop publicados sin Gateways han incrementado preocupantemente, tratando de explotar vulnerabilidades conocidas en este tipo de servicios expuestos en el internet público.
Usar este tipo de instalaciones tiene un costo asociado con la cantidad de servidores que se necesitan. Se recomiendan por lo menos dos, uno para que haga de enlace y el servidor donde vas a alojar la aplicación, en este caso SAP Business One. También es recomendable utilizar un certificado SSL para publicar el Gateway y los CALs de remote desktop son obligatorios. Cada servidor de Windows deja conectar hasta 2 usuarios simultáneos. De ahí en adelante, necesitas comprar los CALs para que se puedan conectar los usuarios y eso trae otro costo de licenciamiento que los proveedores de nube por lo general no brindan.
Una ventaja que puedes tener al usar Gateways es que te permite crear balanceo entre servidores, por ende, puedes tener redundancia entre servidores de aplicación para distribuir la carga o en caso de que uno falle el otro esté y la disponibilidad del servicio sea mayor. De último, pero no menos importante, está el consumo de recursos (CPU y RAM) de alojar la aplicación a través de sesiones remotas vs. web, y de esto haremos una comparación en un momento.
Implementación WEB
Ahora hablemos de una implementación WEB. Desde la versión 9.1 (si no me equivoco) SAP Business One trajo un componente que se llama Browser Access Service (BAS). Recuerdo que la primera vez que vi esto fue en un Summit de SAP en el 2014, y toda la sala hizo un gran WAOOO. Este componente lo que hace es una emulación del cliente desktop a través de un servidor Apache para la conexión de un navegador, manteniendo gran parte de las funcionalidades del cliente tradicional (ver nota 2194215 de SAP para limitantes). Su implementación se puede publicar en la web utilizando dos métodos, Network Address Translation (NAT) o Reverse Proxy. En mi opinión, reverse proxy creo que es un poco más complicado, pero trae mejores resultados por diferentes razones.
La primera es que podemos aislar fácilmente el servidor de aplicación del servidor que funciona de cara al usuario con reverse proxy; y segundo es que el reverse proxy que recomienda SAP, NGNIX en este caso, permite hacer diferentes cosas como balanceo de cargas entre otras. Los costos asociados de utilizar la instalación tipo WEB son menores en comparación con RDS, porque no se necesitan licencias de Remote Desktop, el servidor que funciona como reverse proxy puede ser LINUX, siendo estos más baratos que un Remote Gateway en Windows y el consumo de recursos del servidor de aplicaciones es menor.
Veamos un ejemplo de consumo de CPU entre un servidor RDS y un servidor BAS, con los mismos recursos, para el mismo tipo de usuarios, durante las mismas horas. La línea naranja corresponde a un servidor RDS y la azul a un BAS. La naranja se mantiene siempre por encima del 10% durante horas hábiles, mientras que la azul rara vez pasa el 5% de carga. Cualquiera diría que el RDS está manejando más usuarios que el BAS, por ende, más carga
Some type of erectile dysfunction is experienced by: 40 percent of women suffered from the problem of dysfunction in conjugal relationship and best price for cialis at least one in every four women was unable to reach orgasm. Unlike the run of the mill course of online purchase viagra online http://aimhousepatong.com/item8099.html deliveries, Kamagra medicines are delivered within 24 hours a day in order to stay healthy keep physical and sports activities on daily basis. There are female libido boosters that act like viagra online ordering gned for women. He also recommends eating plenty of salads, cereals, nuts, fish order levitra online and oysters.
Las gráficas de abajo representan la cantidad de sesiones abiertas en esos servidores durante esos periodos, y podemos ver que el BAS tiene la mayoría del tiempo arriba de 20 sesiones, llegando a tener hasta 37. La gráfica azul nos muestra que el RDS, la mayoría del tiempo estuvo por debajo de 20, con un máximo de 22. En otras palabras, el servidor BAS puede manejar más sesiones con menos consumo de CPU (recuerden, mismo tipo de usuarios durante las mismas horas). Si haces un análisis del comportamiento de las sesiones, verás que por cada sesión de RDS, se levantan una serie de procesos dentro del servidor Windows, mientras que por cada sesión BAS, el sistema solo necesita levantar el proceso del cliente de SAP Business One.
Si el componente BAS tiene estas características tan interesantes, ¿entonces por qué no muchas implementaciones lo utilizan? Creo que hay varias razones, dentro de las que puedo enumerar el desconocimiento del componente como la primera. Durante el lanzamiento de la versión 10, hubo varios posts de personas en SAP sobre posibilidad de descontinuar el componte BAS, incluso en las primeras presentaciones de la versión salía que el mismo había sido descontinuado. Un colaborador de SAP, involucrado en el desarrollo del producto puso un post sobre las razones por las que se podría descontinuar, y una de ellas era la baja adopción dentro de la comunidad. Dichosamente, después que SAP lo pensara dos veces, el mismo se dejó activo en la versión 10.
Otras razones pueden ser la complejidad con que algunos ven la configuración NAT/Reverse Proxy, la falta de compatibilidad de muchos Add-ons con el BAS, el que exista un límite de tiempo de inactividad en la sesión, o lentitud en el uso. Esta última causa he notado que es cuando se intenta mezclar un acceso RDS con uno BAS. Si lo van a hacer, háganlo por separado, no intenten tener ambos servicios en el mismo servidor porque los resultados no son buenos. Puedes tener lo mejor de los dos mundos usando un híbrido. Los usuarios que necesiten tener acceso al cliente Windows, que usen un acceso de Remote App y aquellos que tengan funciones generales, que no necesiten del cliente Windows, puedan acceder utilizando el BAS.
Para implementaciones grandes esto es un ahorro significativo en costos y a la vez se traduce en un efecto de redundancia por el hecho de que, si el servidor RDS tiene problemas, tienes acceso al BAS o viceversa. También tienes una mejor experiencia para aquellos usuarios sencillos que pueden acceder por un simple navegador (en lo personal me gusta mucho más trabajar en el BAS). Si tienes dudas de cómo hacer una implementación de BAS, en youtube hay un sin números de videos de cómo se instala tanto para implementaciones On-Premise como de Cloud Control Center. De igual forma, hay un sin número de videos de cómo hacer una instalación de Remote Gateway para RDS. Lo importante, y la idea de este pequeño artículo, es ilustrar que hay opciones para implementaciones de SAP Business One aparte del escritorio remoto tradicional. En la versión 10 se está estrenando un nuevo WEB Client, que viene completamente rediseñado y que seguro en poco tiempo será el más utilizado para las instalaciones del sistema.
Síguenos en las redes para más tips y blogs como este, también puedes seguirnos en nuestro canal de youtube para que no te pierdas ninguno de los videos de tutoriales de SAP Business One.
¡Hasta la próxima!