Procedimiento de configuración para alta disponibilidad con Deployment Avanzado

Introducción

El siguiente documento enumera las tareas de infraestructura y las recomendaciones para configurar su proyecto de Bizagi en una arquitectura de sistema de alta disponibilidad.

Este documento sirve como una lista de verificación de IT para preparar la infraestructura (por primera vez configurando Bizagi), y también proporcionará los pasos guiados para configurar su proyecto de Bizagi una vez que esta infraestructura esté lista.

La siguiente imagen ilustra la arquitectura del sistema involucrada en una configuración de alta disponibilidad:

Antes de empezar

El procedimiento presentado en este documento se aplica cuando no hay conectividad entre su servidor de creación (conocido en Bizagi como el entorno de desarrollo) y los servidores operativos finales en los que desea implementar la implementación (conocido en Bizagi como el entorno de producción).

Por ejemplo, este procedimiento es útil para configurar un entorno de producción de alta disponibilidad en servicios en la nube (como Azure), mientras se tiene el entorno de desarrollo en servidores que no están necesariamente en la nube.

Por lo tanto, este procedimiento se basa en el concepto de Deployment avanzado para publicar los procesos de Bizagi en su entorno final (como se describe en Deployment Avanzado).

Las siguientes características de arquitectura aplican también:

•Una plataforma .NET (por ejemplo, Windows Server 2012 con IIS 8).

•Una base de datos de SQL Server (por ejemplo, versión 2012).

•Una unidad compartida de Windows para el repositorio de documentos (archivos adjuntos).

Lo que debe hacerse

Para configurar Bizagi en una arquitectura de alta disponibilidad, las siguientes secciones guiarán el procedimiento sobre lo que necesita revisar o llevar a cabo:

1. Preparar la infraestructura

Esta sección enumera las consideraciones y recomendaciones para preparar la infraestructura subyacente de su proyecto de Bizagi.

2. Instalar Bizagi

Esta sección describe las consideraciones y recomendaciones al instalar Automation Server.

3. Configurar su proyecto de Bizagi

Esta sección proporciona una guía paso a paso para configurar su proyecto de Bizagi.

4. Salir a producción

Esta sección describe los siguientes pasos necesarios para poner en funcionamiento su entorno de producción configurado.

Procedimiento

Siga las pautas y pasos que se presentan a continuación.

1. Preparar la infraestructura

Los siguientes requisitos previos consideran los aspectos relevantes de hardware y software para configurar el nivel de base de datos, el nivel de procesamiento digital y una configuración compatible de otros sistemas y aplicaciones integradas con Bizagi.

1.1 Nivel de base de datos (SQL Server)

El nivel de la base de datos (capa de acceso a datos) es donde se encuentra el motor de la base de datos.

Para alta disponibilidad, se configuran 2 o más nodos en una instancia de SQL Server en clúster para permitir las capacidades tolerancia a fallos.

1.1.1 Configuración del hardware

Asegúrese de cumplir con los requisitos mínimos de hardware o, preferiblemente, de que este hardware cumpla con una estimación de tamaño adecuada para su proyecto.

Por ejemplo, para Bizagi versión  11.2, considere:

•RAM superior a 16 GB.

•2 o más discos duros con más de 80 GB de espacio libre.

•Procesador con 4 núcleos mínimo. 3 GHz para procesamiento recomendado.

•Utilizando fuente de alimentación redundante.

•Usando más de 1 NIC (1 GB o más).

Recomendaciones adicionales:

•Tenga en cuenta que las especificaciones de hardware mínimas enumeradas anteriormente deben complementarse con los requisitos específicos de su proyecto mediante la realización de un análisis exhaustivo del tamaño.

•Se recomienda que el servidor de la base de datos se dedique exclusivamente a alojar la base de datos de Bizagi.

•Al configurar un clúster de base de datos, se aplican todas las recomendaciones comunes para una configuración en clúster, como asegurarse de que sus nodos utilicen: medidas redundantes para su SAN (si está usando una), las mejores prácticas para la conexión de red entre sus nodos (ancho de banda y latencia óptimos, NIC adicionales si es necesario), etc.

Bizagi es intensivo en el acceso a los datos y, por lo tanto, es realmente importante que las medidas de redundancia no ocupen recursos significativos utilizados por el procesamiento o transporte de los nodos de la base de datos.

1.1.2 Configuración del sistema operativo

Asegúrese de que está utilizando un sistema operativo compatible y su configuración en todos los nodos que forman parte de su clúster de base de datos.

Considere:

•Una versión e idioma compatibles del sistema operativo (es decir, Windows Server 2012, idioma inglés).

La misma versión de sistema operativo y paquetes de servicio en todos los nodos.

•Configuración de la configuración regional consecuente (fecha del servidor y el idioma).

La misma configuración para todos los nodos.

Recomendaciones adicionales:

•Se aplican todas las recomendaciones comunes para la configuración de los servidores, como deshabilitar las actualizaciones automáticas del sistema operativo.

Asegúrese de considerar las actualizaciones dentro de sus políticas de administración de parches.

•Teniendo en cuenta sus políticas antivirus, los archivos de base de datos no deben analizarse.

1.1.3. Instalación del servidor SQL

Asegúrese de que SQL Server esté correctamente instalado en todos los nodos que forman parte de su grupo de bases de datos.

Considere:

•Se utiliza una versión compatible de SQL Server (es decir, cuando se usa 2012: versión 11.0.5058.0 x64).

La misma versión en todos los nodos.

•Esta instancia utiliza una intercalación compatible (es decir, la intercalación predeterminada y recomendada es SQL_Latin1_General_CP1_CI_AS).

La misma intercalación en todos los nodos.

•La versión y la intercalación coinciden con la utilizada en las instancias de SQL Server de sus entornos de creación y prueba.

•Activación del modo de autenticación de SQL Server (mixto) para todos los nodos.

•Crear al menos una cuenta de inicio de sesión de SQL Server que tenga permisos de master y de tempd (una cuenta de administrados de Procesos con el rol de servidor public, permisos de create database, backup database y grant view any definition en la base de datos master, permisos de create, select y drop table, grant view any definition en la base de datos tempdb).

Esta cuenta tiene el mismo nombre de usuario y contraseña en todos los nodos.

Recomendaciones adicionales:

•Puede considerar la posibilidad de personalizar su configuración de SQL Server configurando su instancia de SQL Server en un puerto diferente al puerto 1433 predeterminado y configurándola como una instancia con nombre (es decir, para lograr la seguridad a través de medidas de obscurity).

También debe deshabilitar la cuenta sa y usar una cuenta sysadmin diferente, y usar la aplicación de contraseñas seguras.

Tenga en cuenta que toda la configuración mencionada anteriormente (incluido un número de puerto o una instancia con nombre) para todos los nodos de su clúster de SQL Server debería ser homogénea.

•Tenga en cuenta que un proyecto de Bizagi usa 1 base de datos en su instancia de SQL Server y, por lo tanto, se usa comúnmente una configuración de clúster de SQL Server activo-pasivo (se recomienda para la mayoría de los escenarios).

Sin embargo, si su proyecto maneja un gran volumen de información y planea usar una base de datos replicada (ODS) para informes y análisis, puede considerar una configuración activa-activa (clúster de tolerancia a fallos de múltiples instancias) en lugar de separar el host de la base de datos transaccional de la que proporciona informes y análisis.

1.2. Nivel de procesamiento digital (plataforma .NET)

El nivel de proceso digital es donde opera el Portal de Trabajo de Bizagi.

En una plataforma .NET, Microsoft Internet Information Services aloja el Portal de Trabajo.

Para alta disponibilidad, 2 o más nodos activos están configurados en un clúster para proporcionar capacidades de equilibrio de carga.

1.2.1. Configuración de hardware

Asegúrese de cumplir con los requisitos mínimos de hardware o, preferiblemente, de que este hardware cumpla con una estimación de tamaño adecuada para su proyecto.

Para la versión 11.2 de Bizagi, considere:

•RAM superior a 16 GB.

•2 o más discos duros con más de 80 GB de espacio libre.

•Procesador con 4 núcleos mínimo. 3 GHz para procesamiento recomendado.

•Utilizando fuente de alimentación redundante.

•Usando más de 1 NIC (1 GB o más).

Tenga en cuenta que las especificaciones de hardware mínimas enumeradas anteriormente deben complementarse con los requisitos de su proyecto específico mediante la realización de un análisis exhaustivo del tamaño.

1.2.2 Configuración del sistema operativo

Asegúrese de utilizar un sistema operativo compatible y su configuración en todos los nodos que forman parte de su clúster.

Considere:

•Una versión e idioma compatibles del sistema operativo (p. ej., Windows Server 2012, idioma inglés).

La misma versión de sistema operativo y paquetes de servicio en todos los nodos.

•Ajustar la configuración regional en consecuencia (fecha del servidor y el idioma).

La misma configuración para todos los nodos.

Recomendaciones adicionales

•Se aplican todas las recomendaciones comunes para la configuración de los servidores, como deshabilitar las actualizaciones automáticas del sistema operativo.

Asegúrese de tener las últimas actualizaciones y considere su mantenimiento dentro de sus políticas de administración de parches.

1.2.3. Instalación del IIS

Asegúrese de que el IIS esté correctamente instalado en todos los nodos que forman parte de su clúster.

Considere:

•Se use una versión compatible de IIS (es decir, cuando se usa un sistema operativo compatible, se admite su versión IIS). Por ejemplo, en un Windows Server 2012, se utiliza IIS 8.

La misma versión en todos los nodos.

•Habilitar las siguientes funciones de servidor para su Web server:

IIS 6 Metabase compatibility, IIS Metabase and IIS 6 configuration compatibility, y IIS Management Console (Herramientas de administración de Web), .NET Extensibility 4.5 y ASP.NET 4.5 (World Wide Web Services), Static Content (Características comunes de HTTP), Static Content Compression y Dynamic Content Compression (características de rendimiento), Basic authentication, Windows authentication y IP and Domain restrictions (características de seguridad).

Además, considere la posibilidad de habilitar la función Servidor SMTP y usar el servicio IIS SMTP como una conexión puente a su SMTP corporativo (recomendado).

Recomendaciones adicionales

•Considere tener a mano un certificado de servidor válido para configurar el uso de HTTPS más adelante (para mayor seguridad).

•Si planea instalar Automation Server a través de su instalador como se describe más adelante, no necesitará considerar otros requisitos previos.

De lo contrario, y solo si no ejecuta el instalador del Servidor de automatización, deberá asegurarse de instalar la versión 4.5.2 de Microsoft .NET Framework completa.

1.3. Otros sistemas y aplicaciones

Esta sección se aplica a sus sistemas y aplicaciones corporativos que se integrarán con Bizagi.

Esto depende de los servicios que su proyecto de Bizagi usará específicamente.

1.3.1 Dominio - Cuenta de servicio

La configuración del dominio no requiere ninguna acción o modificaciones especiales para Bizagi.

Solo deberá tener en cuenta que se recomienda utilizar una cuenta de servicio dedicado para Bizagi de acuerdo con las mejores prácticas.

Para esto, asegúrese de crear una cuenta de dominio que se utilizará para iniciar los servicios del Portal de Trabajo (es decir, convertirse en la identidad utilizada por el grupo de aplicaciones en el IIS y por el servicio de Scheduler) y que su contraseña no caduque.

1.3.2. Servidor de archivos - Carpeta compartida

Al usar una carpeta compartida en un servidor de archivos, como su repositorio de documentos (adjuntos de casos), establezca que la cuenta de dominio especificada anteriormente tenga derechos de lectura y escritura en esa carpeta.

Asegúrese de que todos los nodos de su clúster de Bizagi puedan acceder a este servidor de archivos.

1.3.3.Balanceador de carga - sesiones Sticky

Puede usar un balanceador de carga que pueda dirigir las solicitudes entre los diferentes nodos de su clúster de Bizagi.

Se recomienda utilizar un balanceador de carga de hardware como F5.

Asegúrese de habilitar las sesiones adhesivas en la configuración de enrutamiento de su balanceador de carga (independientemente del algoritmo utilizado para equilibrar las solicitudes).

Al final, publicará la URL del balanceador de carga al que sus usuarios finales acceden a Bizagi. Esta URL puede usar un nombre de IP o DNS y un directorio virtual que se debe asignar para enrutar a los nodos y al directorio virtual de su clúster de Bizagi.

1.3.4. Servidor SMTP - soporte de retransmisión

Puede utilizar su servidor SMTP corporativo para enviar notificaciones por correo electrónico.

Asegúrese de que su servidor SMTP admita la retransmisión.

Se recomienda confiar en el servicio SMTP de IIS como servicio intermedio entre Bizagi y su servidor SMTP corporativo (una conexión puenteada) para asegurarse de que se admite la transmisión y personalizar los parámetros de configuración para integrarlos en su servidor SMTP corporativo (como como uso de la autenticación, un número de puerto diferente al puerto predeterminado 25, etc.).

Más información sobre el uso del servicio SMTP de IIS en Usando un servidor SMTP.

1.3.5. Configuración de Firewall - puertos

Asegúrese de que los puertos autorizados y el acceso se conceden en consecuencia entre sus diferentes servidores como se describe a continuación.

•La conectividad de los servidores de Bizagi al nivel de la base de datos se realiza a través del puerto TCP especificado por su instancia de la base de datos (o la configuración del listener).

•La conectividad al Portal de Trabajo desde los dispositivos del usuario final se realiza a través de puertos HTTP estándar (el puerto predeterminado 80 o 443 cuando se usa SSL sobre HTTPS).

Puede modificar el puerto predeterminado más adelante al configurar su proyecto de Bizagi.

1.3.6. Otros

Dependiendo de los requisitos de integración de su proyecto de Bizagi, es posible que deba asegurarse de que otros sistemas y aplicaciones corporativas estén disponibles y utilizando una conectividad de red adecuada (por ejemplo, un sistema de proveedor de identidad o LDAP, servicios en la nube, API integradas, sistemas o bases de datos).

Asegúrese de considerar también cualquier tema adicional relacionado con la accesibilidad (puertos), autorización / seguridad o licencias de componentes de terceros.

Recomendaciones adicionales

•Dependiendo de sus acuerdos de nivel de servicio, considere cualquier medida redundante para la disponibilidad de dichos servicios o sistemas.

Por ejemplo, para el servidor SMTP y si no hay redundancia, se pondrán en cola las notificaciones de soporte de retransmisión.

Se recomienda mejorar la disponibilidad y la redundancia de su servidor de archivos y el contenido de su carpeta compartida, ya que estos almacenarán documentos de casos.

2. Instalar Bizagi

La instalación de Bizagi para un entorno de producción se realiza ejecutando el instalador de Automation Server en todos los nodos de su clúster.

El instalador más reciente está disponible para plataformas de 64 bits directamente en http://www.bizagi.com, pero tenga en cuenta que la versión de Automation Server tiene que coincidir con la versión de Bizagi Studio utilizada en el entorno de creación.

Recomendaciones adicionales

•Se aplican todas las recomendaciones comunes para las mejores prácticas de instalación de programas, como instalar Automation Server en una partición diferente a la unidad C:\ predeterminada.

•Verifique que la instalación de Automation Server cree un grupo de usuarios local llamado Bizagi y que su usuario esté incluido explícitamente en él.

Este grupo de usuarios se utiliza para abrir Bizagi Management Console para administrar su sistema Bizagi.

De manera similar, para crear y actualizar proyectos, necesitará que su usuario esté incluido explícitamente en el grupo de Administrators.

También puede verificar que la Consola de Administración de Bizagi está instalada.

•En este punto, asegúrese de haber comprado una licencia de Bizagi para respaldar a los usuarios finales de producción.

Reinicie el servidor si es necesario (la instalación de Bizagi puede solicitarle esto).

3. Configurar su proyecto de Bizagi

Siga estos pasos para configurar los componentes necesarios de la infraestructura subyacente para su proyecto de Bizagi.

A través de estos pasos, el entorno operativo de producción se prepara y se prepara para el despliegue de procesos.

3.1. Defina cuál de sus nodos será su nodo maestro

Del conjunto de nodos que tiene el Automation Server, uno de estos se configurará como el nodo maestro del clúster, y los demás nodos se convertirán en nodos esclavos.

Asegúrese de definir este nodo maestro para poder identificarlo en cualquier momento.

3.2. Cree el proyecto del ambiente de producción (en el nodo maestro)

Desde el nodo maestro, ejecute Bizagi Management Console con derechos de administrador para crear el proyecto del ambiente de producción.

Nombre este proyecto exactamente como desea que los usuarios finales accedan a su Portal de Trabajo de Bizagi (aunque luego es posible cambiar el nombre).

Especifique la conexión a su nivel de base de datos (es decir, instancia de clúster de tolerancia a fallos o listener) asegurándose de utilizar la cuenta de administrador de procesos de SQL Server tal como se creó y se describe en la sección 1.1.3.

Su proyecto creado debe dar como resultado: una base de datos en su nivel de base de datos, un servicio de programador configurado como un servicio local de Windows y un sitio web local en el IIS.

El sitio web local (Bizagi Portal de Trabajo) se crea bajo el sitio web predeterminado y está configurado para usar un pool de aplicaciones de 64 bits, solo para Bizagi, y que se crea automáticamente en este proceso (el pool se llama Bizagi 64-Bit ASP.NET v4.0).

Una vez que se haya creado el proyecto, detenga el servicio de Scheduler.

Recomendaciones adicionales

•Se aplican todas las recomendaciones comunes para las mejores prácticas de instalación de programas, como crear este proyecto en una partición diferente a la unidad C:\ predeterminada (en esta ruta, se ubicarán las carpetas y los archivos relevantes).

3.3. Eliminar la base de datos creada

En el nivel de la base de datos, elimine esa base de datos creada en la sección 3.2.

Esta base de datos no será la última, por lo que no se tiene en cuenta de esta manera.

3.4. Cree los componentes clúster (en cada nodo esclavo)

Desde cada uno de los nodos esclavos, ejecute el Management Console con derechos de administrador para crear los componentes en clúster necesarios para ese proyecto de entorno de producción.

Nombra este proyecto exactamente como nombraste el proyecto como se realizó en la sección 3.2.

Especifique la conexión a su nivel de base de datos (es decir, instancia de clúster de tolerancia a fallos o listener) asegurándose de utilizar la cuenta de administrador de procesos de SQL Server tal como se creó y se describe en la sección 1.1.3.

Su proyecto creado debe dar como resultado: una base de datos en su nivel de base de datos, un servicio de programador configurado como un servicio local de Windows y un sitio web local en el IIS.

El sitio web local (Bizagi Portal de Trabajo) se crea bajo el sitio web predeterminado y está configurado para usar un pool de aplicaciones de 64 bits, solo para Bizagi, y que se crea automáticamente en este proceso (el pool se llama Bizagi 64-Bit ASP.NET v4.0.

Una vez que se haya creado el proyecto, detenga el servicio de Scheduler.

Asegúrese de realizar el siguiente paso 3.5 (eliminar la base de datos creada) antes de repetir este paso en nodos esclavos adicionales.

Recomendaciones adicionales

•Se aplican todas las recomendaciones comunes para las mejores prácticas de instalación de programas, como crear este proyecto en una partición diferente a la unidad C:\ predeterminada (en esta ruta, se ubicarán las carpetas y los archivos relevantes).

3.5. Eliminar la base de datos creada

En el nivel de la base de datos, elimine esa base de datos creada en la sección 3.4.

Esta base de datos no será la última, por lo que no se tiene en cuenta de esta manera.

3.6. Crear la base de datos de producción

Desde el nodo maestro, ejecute la herramienta llamada CreateDatabase.exe con permisos de administrador para crear la base de datos del entorno de producción (esta herramienta se encuentra en la carpeta donde se encuentra el Management Console).

Configure el archivo CreateDatabase.exe.config para: Use un string de conexión a su base de datos (es decir, instancia de clúster de tolerancia a fallos o listener) asegurándose de usar la cuenta de administrador de procesos de SQL Server como se creó y describe en la sección 1.1.3 , para nombrar esta Al crear la base de datos, asegúrese de marcar la casilla que indica que esta base de datos se marcará como una base de datos de producción.

Esto debería resultar en una base de datos final creada en su nivel de base de datos.

3.7. Llevar a cabo las mejores prácticas para la configuración de almacenamiento de SQL Server

De acuerdo con las características de hardware de los nodos de su base de datos (es decir, la cantidad de discos duros, la cantidad de procesadores o núcleos), puede configurar los archivos de datos y los registros para un rendimiento mejorado (ampliándolos).

Las mejores prácticas orientadas a la configuración de almacenamiento en una base de datos de SQL Server incluyen medidas recomendadas como:

•Considerar la creación de múltiples archivos de datos y grupos de archivos para la base de datos de Bizagi, a fin de beneficiarse de las operaciones de E / S paralelas (de acuerdo con las características de su hardware).

•Colocar archivos de registro en su propia unidad, separado de los archivos de datos.

Los archivos de registro se escriben casi exclusivamente en forma secuencial, y no se leen a menudo (las excepciones a esto son las medidas de sincronización involucradas en la creación de reflejo de la base de datos o los grupos de disponibilidad AlwaysOn).

Esta configuración favorece un rápido rendimiento de escritura.

•Colocar tempdb en su propia unidad.

Tempdb se usa internamente para múltiples propósitos por SQL Server, por lo que tenerlo en su propio subsistema de E / S ayuda.

•Del mismo modo, considerar el almacenamiento de las copias de seguridad de la base de datos en sus propias unidades para fines de redundancia, así como para reducir la contención de E / S con otros volúmenes.

•Configurar tempdb con múltiples archivos de datos y grupos de archivos predimensionados para evitar el crecimiento automático (utilizando un archivo de datos por CPU).

Recomendaciones adicionales

•Al pre-dimensionar, considere recomendaciones comunes tales como: Deshabilitar el crecimiento automático de los archivos de datos, hacer que los datos y los archivos de registro no utilicen más del 90% del espacio disponible en el disco, teniendo el archivo de registro el doble del tamaño de un solo archivo de datos, y establecer crecimiento automático para el archivo de registro a un tamaño específico.

•En este punto, puede verificar que la base de datos de Bizagi tenga habilitado el aislamiento de instantáneas. Específicamente:

Permitir Snapshot isolation: True (ALLOW_SNAPSHOT_ISOLATION ON)

Está Read-committed snapshot isolation en: True (READ_COMMITTED_SNAPSHOT ON)

Tenga en cuenta que al utilizar los niveles de aislamiento de instantáneas anteriores, es aún más importante que aumente los recursos y aplique las mejores prácticas para la base de datos tempdb (es decir, utilice un volumen separado que garantice operaciones de E / S de alta velocidad).

Las recomendaciones anteriores no implican que tales tareas no necesiten ser monitoreadas o ajustadas constantemente.

Si se aplica a su grupo de bases de datos, en este punto también puede considerar la configuración de la sincronización de su grupo de disponibilidad, ya que no se realizarán más restauraciones de respaldo en este procedimiento.

3.8. Cree una cuenta dedicada de SQL Server para las operaciones de Bizagi

Cree una cuenta de SQL Server para ser utilizada únicamente por Bizagi.

Esta cuenta será utilizada tanto por el servicio de scheduler como por el sitio web local (Bizagi Portal de Trabajo) y tendrá solo los derechos estrictamente necesarios en su instancia de SQL Server y en la base de datos específica creada en la sección 3.2.

Los derechos necesarios son la función de servidor público y las siguientes asignaciones de usuario para la base de datos de Bizagi: db_datareader, db_datawriter, public, rlBA_SQL_BizAgiWebApp y rlBA_SQL_ExecuteBizAgiSPs.

Recomendaciones adicionales

•Se aplican todas las recomendaciones comunes para esta cuenta, como asegurarse de que tenga una contraseña segura pero que no caduque.

Puede establecer inicialmente la misma contraseña para esta cuenta que la utilizada para la cuenta de administrador de proceso creada y descrita en la sección 1.1.3.

De esta manera, no tendrá que modificar de inmediato la contraseña de la cadena de conexión, sino hacerlo más tarde.

•Recuerde que si está utilizando algún tipo de duplicación o sincronización de base de datos para medidas de recuperación ante desastres o recuperación de desastres (por ejemplo, un grupo de disponibilidad AlwaysOn), deberá asegurarse de que dicha cuenta de SQL Server se cree de manera coherente en las múltiples instancias de sus nodos redundantes.

3.9. Editar la configuración del Portal de Trabajo

Desde cada uno de los nodos, ingrese al administrador de IIS para editar las configuraciones utilizadas por el sitio web del Portal de Trabajo.

En este punto, debe considerar:

•Instale y cree el enlace HTTPS que considera su certificado de servidor, como se recomienda en la sección 1.2.3 (considerando también el nombre de su servidor del balanceador de carga). Considere el puerto que utilizará para HTTPS en la configuración adicional (balanceador de carga, firewall, etc.).

•Separar la carpeta física de servicios web SOA aparte de Cache.asmx, WFEQuery.asmx y WFAsync.asmx para que pueda incluir medidas de seguridad adicionales, como la autenticación básica de estos recursos.

En caso de que su proyecto no necesite publicar la API de Bizagi, puede dejar dichos servicios web SOA completamente restringidos.

•Incluyendo cualquier definición de seguridad adicional de acuerdo con la forma en que espera tener acceso al Portal de Trabajo, como definir una lista blanca de IP.

•Usar la cuenta de servicio de dominio dedicado como el conjunto de identidades para iniciar el grupo de aplicaciones utilizado por Bizagi (requerirá que a esta cuenta se le conceda el inicio de sesión como un derecho de servicio).

Para esta cuenta, verifique los derechos adecuados para esa cuenta de servicio dedicada a la ruta física de los archivos y carpetas del sitio web.

Desde cada uno de los nodos, asegúrese de editar el archivo de configuración del Portal de Trabajo que es el archivo web.config ubicado en la ruta física de la carpeta del sitio web de IIS.

Al editar este archivo, Considere:

•Editar la cadena de conexión, de modo que use la cuenta dedicada de SQL Server como se creó en la sección 3.8.

Mantenga la misma contraseña si se aplica (temporalmente), como se recomienda en esa misma sección.

Puede usar la misma contraseña para una configuración de conexión inicial y, más adelante, cambiar la contraseña especificando una encriptada que se base en la opción de encriptación disponible en el menú de administración del Portal de Trabajo de Bizagi.

•Incluir las siguientes líneas dentro del elemento<appSettings>, para todos sus nodos (nodos maestro y esclavo).

Considere establecer el Protocolo = HTTPS cuando use SSL sobre HTTPS en lugar de HTTP, como se recomienda en la sección 1.2.3.

<add key="SERVER_NAME" value="VALOR_CORRESPONDIENTE"/>

<add key="APP_NAME" value="VALOR_CORRESPONDIENTE"/>

<add key="PROTOCOL" value="HTTPS"/>

Tenga en cuenta que para el valor de Server_name,  debe especificar el nombre virtual del balanceador de carga. Para el valor de App_name, debe especificar el sitio web virtual del balanceador de carga. Estas llaves son necesarias para que los links incluidos en notificaciones email (e.g. Case link) se redireccionen al servidor adecuado.

3.10. Editar la configuración del scheduler

Desde cada uno de los nodos, asegúrese de editar el archivo de configuración del scheduler, que es el archivo BizAgi.Scheduler.Services.exe.config ubicado en la carpeta Scheduler de la ruta física donde creó el proyecto Bizagi.

Al editar este archivo, considere:

•Usar la cuenta de servicio de dominio dedicado como el conjunto de identidades para iniciar el Programador mediante la edición de las propiedades del servicio (requerirá que a esta cuenta se le conceda el inicio de sesión como un derecho de servicio).

Para esta cuenta, verifique los derechos adecuados para esa cuenta de servicio dedicada a la ruta física de los archivos y carpetas del sitio web.

•También puede elegir establecer dependencias o reintentar más acciones.

•Editar la cadena de conexión, de modo que use la cuenta dedicada de SQL Server como se creó en la sección 3.8.

Mantenga la misma contraseña si se aplica (temporalmente), como se recomienda en esa misma sección.

Puede usar la misma contraseña para una configuración de conexión inicial y, más adelante, cambiar la contraseña especificando una encriptada que se base en la opción de encriptación disponible en el menú de administración del Portal de Trabajo de Bizagi.

•Incluir las siguientes líneas dentro del elemento<appSettings>, para todos sus nodos (nodos maestro y esclavo).

Considere establecer el Protocolo = HTTPS cuando use SSL sobre HTTPS en lugar de HTTP, como se recomienda en la sección 1.2.3.

<add key="SERVER_NAME" value="VALOR_CORRESPONDIENTE"/>

<add key="APP_NAME" value="VALOR_CORRESPONDIENTE"/>

<add key="PROTOCOL" value="HTTPS"/>

Tenga en cuenta que para el valor de Server_name,  debe especificar el nombre virtual del balanceador de carga. Para el valor de App_name, debe especificar el sitio web virtual del balanceador de carga.

•Incluir las siguientes lineas dentro del elemento<appSettings>, pero solo para sus nodos esclavos.

<add key="DisableAsynchCaseClosing" value="1"/>

<add key="DisableInterfaceErrorLogger" value="1"/>

De esta manera, solo el nodo maestro realizará tareas de mantenimiento del sistema.

Forzar la versión de TLS

Si usted está usando HTTPS con el protocolo TLS, y tiene una versión específica, por ejemplo, la versión 1.1 o 1.2, usted necesita incluir la siguiente llave en el web.config del Portal de Trabajo:

<add key="TLSSupport" value="Tls1.2" />

Considere revisar si los navegadores de los usuarios finales tienen habilitado este protocolo. Los siguientes servidores tiene el protocolo TLS 1.1 activado por defecto:

Para revisar si TLS está activo en su navegador, siga los siguientes pasos:

Microsoft Internet Explorer

1. Abra Internet Explorer

2. Desde la barrade menú, haga clic en Herramientas > Opciones de Internet > Pestaña de Avanzados

3. Navegue hasta la categoría de Seguridad. Manualmente revise la caja para usar TLS 1.1 o TLS 1.2.

Google Chrome

1. Las conexiones siempre están negociadas en el grado más alto.

2. Si usted usa una versión de Google Chrome en versión 22 o mayor, TLS 1.1 es automáticamente soportado. TLS 1.1 y 1.2 son soportadas automáticamente desde la versión 29.

Mozilla Firefox

1. Abra Firefox

2. En la barra de direcciones URL, ingrese about:config y presione enter.

3. En el campo de búsqueda ingrese tls. Busque y haga doble clic en security.tls.version.max

4. Defina el valor entero en 4 y fuerce un protocolo máximo de TLS 1.3.

Para más información consulte HTTPS protocol.

3.11. Aplicar la licencia

Aplique su licencia de Automation Server.

Póngase en contacto con nuestro equipo de soporte para asistirlo en la aplicación de la licencia.

De forma predeterminada, el servicio del programador ejecutará las tareas de mantenimiento del sistema todos los días, desde las 23:00 horas hasta las 24:00 horas (hora del servidor).

Las tareas de mantenimiento del sistema incluyen el traslado de información de casos y actividades cerradas de una tabla a otra (ajuste).

El mantenimiento se detendrá en un momento cercano a la hora de finalización, independientemente de si aún es necesario mover algunos registros (quedarán pendientes para la próxima ejecución).

Para cambiar o ampliar este marco de tiempo de mantenimiento, notifique a nuestro equipo de soporte.

Tenga en cuenta que debe cambiar el período de tiempo considerando que no afecta la operación de su Sistema (que se debe establecer en horas no ocupadas), y preferiblemente de acuerdo con el tamaño de su proyecto en relación con una estimación de la cantidad de casos y actividades que se cierran por día.

3.12. Iniciar / reiniciar sus servicios

Desde cada uno de los nodos, asegúrese de iniciar cada servicio IIS (un reinicio es útil para asegurarse de vaciar cualquier caché anterior).

De forma similar y desde cada uno de los nodos, asegúrese de iniciar o reiniciar cada servicio de scheduler.

Si desea cambiar la contraseña de la cuenta dedicada de SQL Server como se creó en la sección 3.8, puede hacerlo y asegurarse de actualizar los archivos de configuración para usar dicha contraseña como se hace en las secciones 3.9 y 3.10.

4. Salir a producción

En este punto, la infraestructura está configurada para su sistema de alta disponibilidad de Bizagi (su proyecto de Bizagi está configurado y principalmente espera la implementación del proceso).

4.1 Deployment de procesos

Tenga en cuenta que existen 2 alternativas para el deployment de procesos: deployment en un clic o la herramienta de deployment avanzado.

Recuerde que todo el procedimiento presentado anteriormente y las siguientes pautas en este documento se basan en el uso del deployment avanzado (deployment en un clic no se usa en ningún momento).

De esta manera, deberá ejecutar la herramienta de deployment avanzado para terminar de aplicar los scripts a la base de datos de producción creada en la sección 3.6.

Para más documentación acerca del Advance deployment haga clic acá.

Las ventajas de utilizar la implementación avanzada son:

•No implica una restauración de copia de seguridad que puede llevar más tiempo y llevar a un procedimiento más confuso.

•Como un procedimiento de configuración completo, tiene menos consideraciones que hacen que tome menos tiempo. Le permite dejar la infraestructura lista para su ambiente de producción (por ejemplo, después de la implementación no necesita aplicar ningún script adicional para configurar su licencia o clúster, ni utilizar Management Console para las preparaciones).

Los contras de usar la implementación avanzada son:

•El ambiente de desarrollo no será consciente del deployment, lo que significa que no reconocerá la existencia de un ambiente de producción y, por lo tanto, no realizará validaciones en los comandos de eliminar o modificar.

Esto significa que los usuarios de Bizagi Studio deben tener mucho cuidado de no eliminar en el entorno de desarrollo, ningún objeto (ni modificar sus definiciones clave) que ya se haya implementado en producción, ya que esto puede dar lugar a problemas de integridad de los datos.

En este punto, puede proceder a utilizar la herramienta de implementación en Bizagi para publicar procesos en su base de datos de entorno de producción.

Tenga en cuenta que en este escenario específico, no es necesario crear la base de datos en blanco para el ambiente de producción, porque ya se ha configurado.

Pasos futuros - notas importantes de las actualizaciones de versiones

Reconozca las siguientes notas para una actualización de la versión menor de Bizagi en el futuro.

Tenga en cuenta que la actualización a una versión principal no se considera a continuación, ya que este tema necesitaría una evaluación previa de Bizagi Ltd.

Estas notas deben ser relevantes para que usted planifique su próxima actualización de la versión de Bizagi.

Recomendaciones de procedimiento general

Se aplican todas las recomendaciones comunes para una actualización del sistema, tales como:

•Coordinar, revisar y comunicar el plan de actualización.

•Programar la actualización para realizarse en horario no laborable.

•Evaluar los riesgos y realizar de copias de seguridad de todos los componentes de Bizagi.

•Asegurarse de que la actualización de la versión se haya probado y certificado correctamente en sus ambientes de desarrollo y prueba (considerando también si necesita un ambiente de prueba en función de la naturaleza de sus procesos y casos existentes). Verificando la actualización también en producción.

Personalizaciones y sobrecargas.

Identifique si su proyecto tiene algún archivo de personalización dado o sobrecarga de definiciones.

De esta manera, además de respaldar estos archivos agregados (.js, .css, .dll, etc.) antes de una actualización, asegúrese de volver a aplicar dichos cambios después de que una actualización de la versión haya ejecutado sus cambios y reemplazos.

Esto se aplica también con el paso realizado en la sección 3.9, donde los servicios web Cache.asmx, WFEQuery.asmx y WFAsync.asmx  se dejan separados de los servicios web orientados a los negocios.

Después de una actualización, deberá revisar o volver a aplicar los cambios de configuración después de los cambios y reemplazos automáticos.

Actualizando todos los nodos

Recuerde que todos los nodos de su clúster usan su propio conjunto de componentes de Bizagi (Scheduler y sitio web local).

Al actualizar el proyecto, asegúrese de confirmar que este procedimiento debe realizarse a través del Management Console en cada nodo.

Después de actualizar cada nodo, edite o verifique la cuenta de SQL Server (inicio de sesión, contraseña) utilizada en la cadena de conexión utilizada tanto por el Scheduler como por el Portal de Trabajo, para que se establezca como se describe en las secciones 3.9 y 3.10.

También deberá volver a aplicar los cambios en la configuración del servicio de Scheduler: el inicio de sesión en la identidad del servicio del Scheduler (reconfigurarlo para iniciarse mediante el uso de la cuenta de servicio de dominio) y otras dependencias o acciones de reintento.