Aplicar el paquete usando el ejecutable

<< Clic para mostrar Tabla de Contenidos >>

Navegación:  Automation Server > Deployment > Deployment Avanzado > Cómo aplicar un paquete de deployment >

Aplicar el paquete usando el ejecutable

Introducción

Este artículo explica como puede aplicar un paquete de deployment usando el ejecutable de Bizagi Engine.

 

Archivo ejecutable del Deployment Avanzado

El Deployment Avanzado consiste de una herramienta de Exportación que le ayuda a aplicar un paquete de deployment.

Este archivo ejecutable viene instalado por defecto en la ruta del Management Console (en C:\Program Files\Bizagi\Bizagi Studio\MC).

 

Archivo de configuración

La configuración del ejecutable se realiza a través de sus archivos con extensión .config.

Este archivos de configuración contienen formato XML y corresponde de la siguiente manera:

CreateImport.exe config para CreateImport.exe

 

El archivo de configuración contiene la siguiente estructura, donde requieren configuración de tres llaves dentro del elemento <appSettings>:

ProofConcept_Utility: Contiene el nombre del utilitario, al archivo ejecutable que referencia.

DSNDB: Contiene el string de conexión a la base de datos al cuál el ejecutable se conecta. En el caso del CreateDatabase.exe, la conexión representa la base de datos que aún no ha sido creada.

PROVIDERTYPE: Especifica el proveedor de datos para esa conexión (SQL Server o Oracle).

 

ConfigFiles

 

Para configurar un ejecutable, deberá incluir el detalle de la conexión a la base de datos y del proveedor.

 

Al utilizar SQL Server:

<add key="DSNDB" value="Persist Security Info=True;User ID=[SQL_Login];Password=[Login_password];Data Source=[DB_Server]\[Named_instance];Initial Catalog=[Database];" />

<add key="PROVIDERTYPE" value="MSSqlClient" />

Considere:

[SQL_Login]: La cuenta de login que se utiliza para conectarse a una instancia SQL Server.

[Login_password]: La contraseña cifrada de la cuenta de login de la conexión. Se recomienda cifrar la contraseña utilizando la funcionalidad de Cifrado de Clave.

[DB_Server]: Nombre o dirección IP del servidor de base de datos. Utilice \[nombre_instancia] si aplica (si no es la instancia sin nombre por defecto).

[Database]: El nombre de la base de datos del ambiente de su proyecto. Recuerde que para el CreateDatabase particularmente, esta base de datos es la que aún no ha sido creada.

 

note_pin

Al configurar los archivos ejecutables, el login de SQL Server requerirá de permisos de sysadmin.

 

Al utilizar Oracle:

<add key="DSNDB" value="Data Source=[DB_Server]:[Port_number]/[Service];User ID=[User_schema];Password=[User_schema_password];Unicode=True;" />

<add key="PROVIDERTYPE" value="Oracle" />

Considere:

[DB_Server]: Nombre o dirección IP del servidor de base de datos.

[Port_number]: El número de puerto utilizado para la conexión a ese servicio.

[Service]: El identificador de servicio usado para su base de datos Oracle.

[User_schema]: El nombre de la base de datos del ambiente de su proyecto (esquema de usuario). Recuerde que para el CreateDatabase particularmente, esta base de datos es la que aún no ha sido creada.

[User_schema_password]: La contraseña cifrada para ese esquema de usuario.

 

Como se mencionó antes, la contraseña de la base de datos debe estar cifrada para protegerla en caso de acceso no autorizado a los archivos de configuración. Siga este procedimiento para cifrar la contraseña:

 

1. En el Portal de Trabajo de su ambiente de desarrollo, dé clic en Admin y en el menú de Seguridad seleccione Cifrado de Clave.

 

PasswordEnc_01

 

Esto mostrará una ventana con la que se puede cifrar cualquier texto que necesite.

 

2. Ingrese la cadena a cifrar en el campo Texto a Cifrar y confírmelo en el siguiente campo. Esto asegurará que el texto ingresado por primera vez es correcto. Si el valor de ambos campos no es igual, la contraseña no será cifrada.

Finalmente, dé clic en Encriptar.

 

PasswordEnc_02

 

3. El campo Texto Cifrado mostrará la contraseña cifrada. Copie esta cadena de caracteres y péguela donde sea requerido.

 

CrytpPass

 

Configuración del tiempo de espera

En el deployment, la actualización de las propiedades de las tablas, como índices, nuevos atributos o incluso datos, puede llevar varios minutos, según si el paquete de deployment contiene objetos transaccionales para actualizar o no y el tamaño de la tabla que debe actualizarse en el ambiente de destino. Por ejemplo, cuando crean nuevas llaves de negocio.

 
Bizagi tiene una llave de configuración para establecer un tiempo de espera máximo de deployment. En el archivo de configuración CreateImport.exe, puede agregar la siguiente clave en la etiqueta de appsettings.

 

<add key = "TimeoutForDeploymentInMinutes" value = "25" />

 

Con esta llave, puede establecer el tiempo en minutos para el tiempo de espera máximo del deployment. La clave también se puede configurar en los siguientes archivos ejecutables asociados con el deployment avanzado:

• CreateImport.exe

• ImportProcessTemplate.exe

• MicroDeployment.exe

 

Abrir el ejecutable CreateImport

Para utilizar CreateImport.exe, previamente asegúrese de haber copiado la carpeta MC en una máquina que tenga acceso a la base de datos del ambiente de producción (esta carpeta contiene los tres ejecutables y los archivos .dlls que se utilizan).

Edite el archivo de configuración CreateImport.exe.config de manera que especifique la cadena de conexión a su base de datos del ambiente de producción.

Ejecute CreateImport.exe.

 

Import04Updated

 

La interfaz de usuario le presentará lo siguiente:

Base de datos destino (Target databse): Enseña la base de datos y el servidor de base de datos configurado, al cuál se está conectado.

Snapshot de base de datos (Database Snapchot): Cree un snapshot de su base de datos destino.

Examinar (Specify the file you want to import): Utilice el botón Examinar (Browse) para cargar el el archivo .bex creado. Si el archivo .bex fue generado con una contraseña aparece una ventada solicitándola. La ruta del archivo aparece en esta casilla.

 

AddPassword03

 

oHabilitar validación de metadata (Enable metadata validation): realiza validaciones en los metadatos para reducir los errores de implementación.

oReemplazar metadata del ambiente destino (Replace target environment metadata): En Bizagi, los administradores pueden realizar diferentes configuraciones desde el Portal de Trabajo o el Management Console como el tema, las configuraciones del ambiente como autenticación, localización (traducciones), Procesos en Vivo, entre otros. Si esta casilla de verificación está habilitada, la implementación recopila todas las configuraciones realizadas en el Portal de Trabajo del ambiente de desarrollo, las opciones de seguridad y todos los metadatos en override se reemplazarán en el ambiente destino. La casilla de verificación es responsable de identificar los override en el ambiente destino y reemplazar así los metadatos dando prioridad a la configuración del deployment.

 

Ahora, cuando se realizan configuraciones desde el Portal de Trabajo o el Management Console posteriores al deployment, se generará un override sobre los objetos modificados. Sí esta casilla de verificación no está habilitada, los cambios de objeto realizados en el ambiente de desarrollo se reflejarán en el ambiente destino cuando se realice el deployment, excepto por el override. Por otro lado, cuando la casilla de verificación está habilitada, el override será reemplazado por los cambios en los objetos realizados desde el ambiente de desarrollo.

 

note_pin

Se recomienda deshabilitar esta casilla de verificación para evitar la pérdida de datos debido al override de los objetos.

 

En la tabla de Objetos en Override, puede ver cualés de estos objetos son configurables en el ambiente de Producción y pueden estar en Override en el ambiente de Producción. Sí la casilla de verificación Reemplazar metadata del ambiente destino está habilitada, sobrescribirá lo que hay en el ambiente de Producción. Sí en la columna de Opción avanzada, el objeto tiene un valor distinto a N/A significa que va incluido en las opciones avanzadas del deployment. Cuando el valor es N/A, los objetos de dicho tipo no se pueden seleccionar o especificar y en un deployment pueden llegar a irse por dependencias.

 

oIgnorar la eliminación de objetos referenciados (Ignore removing referenced objects): Cuando se eliminan objetos en el ambiente de desarrollo, las dependencias de la entidad eliminada se llevarán a cabo en el paquete de implementación. En el procedimiento de deployment, Bizagi evalúa qué objetos se han eliminado del paquete y sí uno de ellos todavía está en uso en el ambiente destino, ignorará esos objetos de la importación.

 

Por ejemplo, puede tener dos procesos (1 y 2 respectivamente) en Studio compartiendo la misma entidad. Cuando se implementen ambos procesos, serán visibles en el ambiente de desarrollo. Si la entidad se elimina en el ambiente de desarrollo y el deployment se realiza para el Proceso 1, las dependencias de la entidad eliminada se llevarán a cabo en el paquete del deployment, mientras que en el ambiente destino, el Proceso 2 seguirá utilizando la entidad compartida.

 

note_pin

Se recomienda activar esta casilla de verificación para evitar conflictos con los objetos en uso en el ambiente destino.

 

Información del Paquete (Package information): Esta sección muestra el autor (usuario), proyecto, base de datos de origen y la fecha de creación del paquete a importar.

Podrá utilizar las opciones Ver objetos de proceso a importar (View process objects to import) o Ver opciones avanzadas de exportación (View export advanced options) para revisar la información que se incluye en el paquete tal como se presentan dichas opciones desde el Export.

oView process objects to import: ver todos los objetos que contienen información del proceso que será publicado en el ambiente destino.

oView export advanced options: ver todas las opciones avanzadas que serán publicadas y actualizadas en el ambiente destino.

oView description: ver el resumen de la exportación escrita por la persona que generó el archivo.

 

Import04

 

note_pin

Le recomendamos siempre seleccionar la opción Enable metadata validation. Esta opción detecta dos de los errores más comunes en el deployment:

References to objects that don't exist in the catalog: Este error se genera cuando un objeto del deployment hace referencia a un elemento que no existe en el paquete o en la base de datos objetivo.

Processes without an associated version: Este error se genera cuando objetos como reglas y elementos de Experiencia no tienen una versión del proceso asociada. Si esto sucede revise la configuración de su deployment y asegúrese de seleccionar una versión del proceso para estos objetos.

Estas validaciones son muy importantes pues reducen los errores que se pueden presentar en el ambiente de Producción.

 

Revise los objetos a incluir en el deployment por medio de las opciones Ver los objetos de proceso (View process objects to import), Ver opciones avanzadas de exportación (View export advanced options) y Ver descripción (View description) para ver los objetos que serán incluidos en el deployment:

 

ExportPackage

 

ViewEditObjects

 

note_pin

Si marca las opciones de autenticación, se reemplazará la autenticación configurada en el ambiente destino. No use esta opción a menos que esté seguro de cambiar las opciones de autenticación con la configuración de su ambiente de origen.

 

Haga clic en Aplicar a la base de datos (Apply package).

Esta opción da inicio al procedimiento de aplicar el paquete, correrá procedimientos en la base de datos de destino (por ejemplo su ambiente de producción), y por lo tanto es importante que tome las medidas necesarias en este punto.

 

Import03

 

Esto podrá tardar un par de minutos y recuerde que en este punto se ejecutarán scripts a nivel de base de datos.

Una vez haya finalizado, se notificará el éxito de la operación:

 

ImportAnalysis

 

note_pin

Este proceso genera un log en la carpeta donde se ejecutó el CreateImport.exe. Este log le permite identificar rápidamente la causa de un error durante la ejecución del proceso. Tiene como nombre logImport[FechaHora].txt donde FechaHora tiene el siguiente formato AAAAMMDD hh_mm_ss

 

Si el proceso fue exitoso el log se verá así:

3/01/2019 3:06:43 PM: Workspace is valid!
3/01/2019 3:07:11 PM: Adapter execution
3/01/2019 3:08:35 PM: Import catalog end

De lo contrario el log será similar a este:

2/21/2019 11:05:04 AM: Exception on Import: Package version is not supported by this version of bizagi: 11.1.0
2/21/2019 11:05:08 AM: [{"type":"IncompatibleVersion","Message":"Package version is not supported by this version of bizagi: 11.1.0"}]

 

Los logs no tienen localización por lo cual se muestran en Ingles. La primera línea muestra el tipo de error que se presentó durante la ejecución. Mientras que la segunda línea muestra información más detallada sobre el error en formato JSON. Dependiendo del error el log puede verse diferente sin embargo siempre tienen esta estructura básica.

 

Snapshot de Base de Datos

En el deployment avanzado usted puede importar el BEX usando el ejecutable createImort.exe. Bizagi ofrece la oportunidad de generar un snapshot de la base de datos destino, la cual puede reversar fácilmente en caso de que exista un problema externo afectando el procedimiento de deployment, y quiera volver a su estado inicial antes del deployment. Reversar un snapshot es más fácil que restaurar un backup, lo cual hace el deployment más eficiente.

 

Cuando  usted abre el createImport.exe, usted puede hacer clic en Backup database. Esto genera automáticamente el snapshot de la base de datos.

 

DBSnapshot

 

El nombre del snapshot es el nombre de la base de datos con un sello de tiempo: [Nombre_Base_de_Datos]_yyyyMMMdd_HHmmss.

 

DBSnapshot2

 

El snapshot siempre es creado en la misma instancia que la base de datos, y es un archivo de solo lectura:

 

DBSnapshot3

 

El snapshot de base de datos está disponible para las siguiente versiones de instancias SQL:

 

Versión Instancia SQL

Enterprise

Standard

Web

Express

SQL 2017

 

 

 

 

SQL 2016 SP1

 

 

 

 

SQL 2016

 

-

-

-

SQL 2014

 

-

-

-

SQL 2012

 

-

-

-

 

Consideraciones con Snapshots

Considere las siguientes recomendaciones relacionadas con snahpshots:

Si un snapshot existe, usted no puede borrar o restaurar su base de datos mientras en snapshot exista, tiene que borrarse primero.

No deje snapshots permanentemente. Estos deben ser usados para reversar la base de datos a su estado original en caso de ser necesario. Pero es recomendable borrar todos los snapshots luego de ser usados.

Un snapshot no reemplaza un backup. Mantenga sus esquemas de backups.

 

note_pin

Le recomendamos ver las siguientes consideraciones asociadas a snapshots en este link

 

Siguientes pasos

Una vez se haya completado el deployment de procesos a través del Deployment avanzado, recomendamos que se limpie la caché del servidor en producción antes de anunciar la finalización del deployment.

 

Cuando se ejecutan los procesos sobre un IIS (plataforma de .NET), después de realizar un deployment avanzado deberá limpiar la memoria caché del Portal de Trabajo y de la base de datos.

Para realizar esto, invoque los siguientes servicios web de Bizagi disponibles en cada proyecto:

Caché de formas de la base de datos: http://[su_servidor][su_proyecto]/webservices/cache.asmx?op=CleanRenderCache

Caché de aplicación: http://[su_servidor][su_proyecto]/webservices/cache.asmx?op=CleanUpCache

 

Note que seguidamente deberá reiniciar los servicios del IIS.

 

El procedimiento de despliegue solo considera metadata, esto significa que si desea preservar los datos de los usuarios y valores de las entidades paramétricas administradas en producción de su ambiente de desarrollo en el ambiente objetivo, debe realizar una Sincronización de datos.