Âncora

	_GoBack
	_GoBack

Image Removed
Synthesis Director

Image Added

DIRECTOR - Manual de Integración 1.0

Manual de

...

Integración SD Server – SD Agent

...

Painel
borderColor #E4E3E3
bgColor #ffffff
titleColor #ffffff
borderWidth 1px
titleBGColor #704581
title REVISIONES

Expandir
title Expandir revisiones

Fecha
Versión
Cambios – Motivo
21/02/2017
1.0
Creación del documento
22/02/2017
1.1
Agregación del apartado Tipos de Operación
23/02/2017
1.2
Agregación del parámetro dbbackup en la operación Install
08/03/2017
1.3
Agregación de los ACK en las operaciones de Update e Install
Modificación de los códigos en los Anexos
10/03/2017
1.4
Agregación de campos en las respuestas de SD Agent sobre el sistema de la terminal
18/05/2017
1.5
Se agregó el manejo de scripts por changeSetID
22/05/2016
1.6
Re-estructuración de contenido
Agregado de integración con maven
08/08/2017
1.7
Eliminación de mensaje "status" del DirectorServer al agente.
Agregado de compañía, tienda y terminal en mensajes de "update" e "install"
16/08/2017
1.8
Agregado de:
HTTPS
Utilización de token en la mensajería entre agente y server
Referencia a clases que representan la mensajería
Pasaje de datos enviados en URL al BODY del POST en formato JSON
08/09/2017
1.9
Soporte Base de datos Hyper Sonic
05/10/2017
1.10
Agregado de explicación de archivo "ignore.txt"
...
22/03/2018 1.
...
Diagrama de Synthesis Director
...
Gestionarlas soluciones STS que se permitirán actualizar
Gestionar las versiones completas de soluciones STS
Centralizar las versiones de soluciones STS en un servidor del retailer
Descargar de forma remota las versiones de soluciones STS en terminales de tiendas
Actualizar versiones de soluciones STS en terminales de tiendas
Monitorear de forma centralizada las versiones que posee una terminal
Monitorear de forma centralizada el detalle del sistema de una terminal
...
Las versiones pertenecen a cada Producto o Solución Synthesis. Se importan a Synthesis Director en un archivo comprimido. Cada producto manejará una última versión, la cual las terminales actualizarán sus soluciones a esta misma.
...
Las versiones a ser deployadas en Director Server deben ser archivo ZIP con la siguiente estructura de directorios:
...
app
...
Aplicación
...
dentro de app deben ir los binarios y archivos de configuración de la solución.
...
meta-data
...
Agente
...
de uso futuro
...
conf
...
Agente
...
Incluye configuración usada por el agente, por ejemplo el "ignore.txt"
...
scripts
...
Agente
...
dentro de scripts se deben colocar los archivos de script de base de datos de la aplicación. En cada actualización/instalación, el agente ejecutará los scripts aún no ejecutados. Para mayor referencia dirigirse a la sección del agente.
...
batch
...
Agente
...
de uso futuro
...
legal/license
...
Director
...
de uso futuro
...
legal/terms
...
Director
...
archivos de términos y condiciones de uso de la solución en formato texto con extensión txt. Al momento de deployar una nueva versión, el sistema Director Server mostrará el contenido de cada archivo para que el usuario lo acepte.
...
docs
...
Aplicación
...
cualquier documentación que se quiera dejar disponible en las terminales.
...
Existen 2 forma de integrarse a Synthesis Director:
Integrando el componente agente
O comunicándose directamente con el director server
...
El SD Agente se compone mínimamente de un paquete de binarios y un archivo de configuración advagent.properties.
La integración con la solución a manejar y monitorear se realiza a través de scripts del sistema operativo, en el caso de Windows serán .bat o .cmd, en Linux serán shell scripts por ejemplo bash scripts.
Las operaciones que realiza el agente con la solución son: inicar, detener, consultar estado de ejecución y opcionalmente consultar paramentos y estados adicionales.
Por lo tanto es necesario indicar en el archivo de configuración éstos scripts, además de los parámetros requeridos por la solución y los requeridos por el agente.
...
Requerir status de la solución a comandar e informar al SD Server
Descargar actualizaciones de la solución
Efectuar la instalación de las actualizaciones
Ejecutar los scripts de BBDD y actualizar su estado de ejecución en la misma.
Monitoreo de indicadores de sistema operativo (memoria, disco)
Recolectar información adicional y enviarlo al server.
Requerir estado e Informar
Periódicamente el agente hace un envió de status al SD Server con datos de status recolectados de la solución, estado de actualización e instalación. En cuanto a informar el estado de ejecución la solución, el agente ejecuta un script que se especifica en el parámetro de configuración application.command.status y se envía el mensaje descripto en el capítulo 2 - Status
Descargar actualizaciones
Cuando el agente recibe del SD Server el comando update (ver capítulo 2 - Update)
Se conecta al repositorio especificado en el comando, y realiza la descarga de actualizaciones.
Instalación de actualizaciones
Cuando el agente recibe del SD Server el comando install (ver capítulo 2 -Install)
Procede a realizar varias tareas:
Detener la solución
Backup de archivos de la version de solución que está instalada
Backup de base de datos de la solución.
Instalación de los nuevos archivos descargados del repositorio
Ejecución de scrips de base de datos
Iniciar la solución
...
Detener Solución
El agente ejecuta el shell script indicado en el parámetro application.command.stop
Backup de archivos
Se copian los archivos de la solución indicados en application.base.path en el directorio de resguardo indicado en el parámetro application.backup.path, vaciando previamente su contenido.
Backup de base de datos
Se efectúa un backup en la base de datos cuyos parámetros de conexión se indican en los parámetros sql.*
El backup de BD se puede obviar si en el comando de install se especifica backupdb=false.
En el caso de MS Sql Server, el backup es realizado a través de script con el comando sql "backup database ..." soportado en las versiones de Sql Server retail y express.
En el caso de BD Oracle, el backup se realiza con la herramienta de Oracle "rman", la cual sólo puede ser ejecutada en la misma máquina dónde está ejecutándose el motor de la BBDD, esta es una característica de esta BD en particular, por lo tanto requiere que el agente esté instalado y ejecutándose en la misma máquina que el motor BD para realizar el backup.
Instalación de los nuevos archivos
Se copian los archivos descargados del repositorio, los correspondientes a la solución, en el directorio especificado en
application.base.path
Todos los archivos serán copiados respetando la estructura de directorios contenida en el paquete de actualización descargado de director (git) salvo los definidos en los archivos "ignore.txt" situados en:
Directorio raíz del agente
Tiene la intención de ser usado siempre con el fin de ignorar archivos que normalmente poseen una configuración particular por terminal/instalación y qué si son pisados, la aplicación deja de funcionar
Directorio "conf" del paquete de actualización
tiene la intención de ser usado eventualmente en una versión en particular
Se ignorarán los archivos/directorios que se encuentren listados en el archivo "ignore.txt".
Se admite "" como comodín múltiple ó
'?' como comodín simple.
...
En este caso se ignorarán los archivos/directorios que comiencen con "config", los archivos "run.bat" y los archivos/directorios que se llamen "ejemplo" y posean cualquier extensión.
Nota
NOTA: No está soportado ignorar rutas.
Ejecución de scripts de base de datos
Los motores actualmente soportados con los siguientes:
Microsoft SQL Server
Oracle
Hyper Sonic
En caso que existan scripts de base de datos, se sigue el siguiente proceso descripto en la siguiente ilustración:
...
En base a la propiedad script.subFolder del archivo de configuración; que indica a partir de que carpeta dentro de scripts se deben buscar los archivos (no recursivamente), se escanean los archivos que cumplen con el patrón .sql.
Nota
Nota: Esto permite poder tener distintas carpetas con los scripts, por ejemplo: mssql, Oracle, db2, PROD, laboratorio, etc, con el objetivo de poder manejar para el mismo producto/solución, diferentes configuración de BBDD, como ser POS vs Kiosco
...
– Changeset src/db.changelog.create.xml::script-20160616-74::autor
Siendo:
el nombre del archivo: db.changelog.create.xml
el changeSetID: script-20160616-74
el nombre del autor: autor
...
3. Debe existir en la base de datos la tabla STS_DB_CHANGE_LOG descripta al final de este documento en la sección: DDL Tabla para actualización de scripts. Esta tabla contiene entradas por changeLogID que indican su status (0=OK, 1=ERROR) de ejecución, de este modo, se evita volver a ejecutar un script que ya fue ejecutado previamente, también, el propósito de esta tabla es tener una bitácora que indica el timestamp en que sucede la ejecución, el status, el orden de ejecución, el nombre del archivo del que provino el changeSetID, el resultado de la ejecución, etc.
4. En este paso se buscan los ya procesados descriptos en el punto anterior.
Se conforman colecciones que indican de cada archivo, que changeSetID es candidato a ejecutar y su script.
Se retorna el contenido del paso anterior.
Por cada archivo, se toma cada changeSetID, se impacta en STS_DB_CHANGE_LOG que se está por ejecutar, se ejecuta el script, en caso de error toma ese retorno y termina el proceso de actualización, también refleja el error en STS_DB_CHANGE_LOG. En caso de no haber errores, por cada script se impacta la correcta ejecución también en STS_DB_CHANGE_LOG.
Nota
Notas:
Para Microsoft SQL Server se usa como fin de comando la sentencia GO
Para Oracle se usa como fin de comando el carácter ";" o bien el formato de Stored Procedure
Para Hyper Sonic se usa como fin de comando el carácter ";"
Todos los comandos SQL dentro de un ChangetSet se ejecutan dentro de una transacción SQL. Si una sentencia falla se hará Rollback. Se debe notar que las capacidades de Rollback serán dadas por el motor de base de datos utizado. Por ejemplo, no en todos los motores de BBDD funciona un rollback de un comando ALTER TABLE.
Se adjuntan ejemplos tanto para MSSQLServer, Oracle y Hyper Sonic:
Image RemovedImage RemovedImage Removed
Iniciar la solución
El agente ejecuta el shell script indicado en el parámetro application.command.start
...
company.id
...
Id de la compañía, configurada en SD Server.
...
store.id
...
Id de la tienda, configurada en SD Server.
...
terminal.id
...
Id de la terminal, configurada en SD Server.
...
device.type
...
Categoría o tipo de la terminal, configurada en SD Server.
...
listening.port
...
Puerto TCP/IP en que el agente expone los servicios http
...
advserver.url
...
Direccion URL base (de la forma https//ip:port/) del SD Server
...
advserver.status.path
...
Path relativo al URL base de SD Server, donde el SD Aget informa status
...
advserver.polling.seconds
...
Período en segundos en que el SD Agent informa estatus al SD Server
...
product.code
...
Código del Producto STS, configurado en SD Server.
...
product.description
...
Descripción del Producto STS, configurado en SD Server.
...
product.version
...
Versión del Producto STS, configurado en SD Server.
...
repository.local.path
...
Directorio local donde almacenar las actualizaciones descargadas del repositorio
...
application.base.path
...
Directorio de la Solución STS
...
application.backup.path
...
Directorio para resguasdar la Solución previo una acatualización
...
application.command.start
...
Shell script con los comandos necesarios para iniciar la Solución
...
application.command.status
...
Shell script con los comandos para solicitar estado a la Solución
...
application.command.stop
...
Shell script con los comandos para detener la Solución
...
application.status.running.text
...
Texto a buscar por SD Agent en el comand.status para tomar como app en ejecución
...
application.extended.info.command
...
Shell script para que las aplicaciones informen datos adicionales
...
application.extended.info.resultfile
...
Archivo de texto con informacion adicional a informar en el envió de status
...
cancel.install.if.app.running
...
Flag que con valor 'true' cancela la instalación si la Solución está en ejecución
...
application.start.on.agent.start
...
Flag que con valor 'true' indica iniciar la Solucíon al inicar el SD Agent
...
application.start.after.install
...
Flag que con valor 'true' indica iniciar la Solucíon luego de instalación
...
sql.server
...
Direccion ip del servidor de BD Sql
...
sql.port
...
Port del servidor de BD Sql
...
sql.db
...
Nombre de la BD Sql
...
sql.user
...
Usuario de la BD
...
sql.pass
...
Contraseña de la BD (Base 64 del TDES generado con herramienta CipherUtil )
...
sql.bkp.dir
...
Directorio del backup del la BD (locla al server donde reside la BD)
...
sql.db.type
...
Tipo de servidor Sql: 'oracle' o 'mssql'
...
sql.oracle.bin.dir
...
Directorio de binarios de la instalacíon BD Oracle, donde reside la herramienta 'rman'
...
sql.oracle.temp.dir
...
Directorio temporal requerido para la ejecución de la herramienta 'rman'
...
scripts.subFolder
...
Es el path relativo a la carpeta scripts en donde van a estar los scripts a ejecutar.
Ejemplos: Mssql, Oracle, Mssql-demo, Oracle-prod, .
Repositorio
...
Contraseñas
...
Información adicional
...
DDL Tabla para actualización de scripts.
...
11
Agregado de propiedad agentVersion para indicar la versión del agente
Explicación de uso de comando status

Painel
borderColor #E4E3E3
titleColor #ffffff
borderWidth 1
titleBGColor #704581
title CONTENIDO

Expandir
title Expandir contenido
Índice
style dist

1. Introducción

1.1 Acerca de este documento

En el presente documento se explicará cómo integrarse a Synthesis Director así como las distintas maneras de hacerlo.

1.2 Qué es Synthesis Director?

Synthesis Director es una solución de Synthesis Retail Solutions que permite gestionar, administrar, distribuir y monitorear de manera centralizada y eficiente nuevas versiones de productos Synthesis en la red de tiendas de un retailer.
Además permite monitoreo los recursos de una terminal de forma centralizada, eficiente y proactiva.

1.3 Arquitectura de Synthesis Director

Synthesis Director está compuesto por un servidor y N agentes.
Los agentes corren en las terminales de la red del retail y son los encargados en enviar información a servidor.
A su vez, el servidor es el encargado de enviar comandos a los agentes quienes lo ejecutan: sincronizar, actualizar, etc.
A continuación se puede ver un diagrama que detalle lo antes explicado:

Image Added

Diagrama de Synthesis Director

1.4 Alcance

Synthesis Director tiene el siguiente alcance:

Gestionarlas soluciones STS que se permitirán actualizar
Gestionar las versiones completas de soluciones STS
Centralizar las versiones de soluciones STS en un servidor del retailer
Descargar de forma remota las versiones de soluciones STS en terminales de tiendas
Actualizar versiones de soluciones STS en terminales de tiendas
Monitorear de forma centralizada las versiones que posee una terminal
Monitorear de forma centralizada el detalle del sistema de una terminal

2. Manejo de versiones

2.1 Introducción

Las versiones pertenecen a cada Producto o Solución Synthesis. Se importan a Synthesis Director en un archivo comprimido. Cada producto manejará una última versión, la cual las terminales actualizarán sus soluciones a esta misma.

2.2 Empaquetado de soluciones

Las versiones a ser deployadas en Director Server deben ser archivo ZIP con la siguiente estructura de directorios:

Directorio	Usado por	Descripción
app	Aplicación	dentro de app deben ir los binarios y archivos de configuración de la solución.
meta-data	Agente	de uso futuro
conf	Agente	Incluye configuración usada por el agente, por ejemplo el "ignore.txt"
scripts	Agente	dentro de scripts se deben colocar los archivos de script de base de datos de la aplicación. En cada actualización/instalación, el agente ejecutará los scripts aún no ejecutados. Para mayor referencia dirigirse a la sección del agente.
batch	Agente	de uso futuro
legal/license	Director	de uso futuro
legal/terms	Director	archivos de términos y condiciones de uso de la solución en formato texto con extensión txt. Al momento de deployar una nueva versión, el sistema Director Server mostrará el contenido de cada archivo para que el usuario lo acepte.
docs	Aplicación	cualquier documentación que se quiera dejar disponible en las terminales.

A continuación se muestra un ejemplo de estructura:

Image Added

3. Integración de aplicación

Existen 2 forma de integrarse a Synthesis Director:

Âncora
_Integrando_el_componente
_Integrando_el_componente
Âncora
_Toc495332180
_Toc495332180
4. Integrando el componente agente

Âncora
_Toc477778331
_Toc477778331
Âncora
_Toc477779401
_Toc477779401
Âncora
_Toc483212356
_Toc483212356
Âncora
_Toc477778332
_Toc477778332
Âncora
_Toc495332181
_Toc495332181
4.1 Introducción

En este apartado se detallan el esquema propuesto para integrar SD Agent a soluciones.

4.2 Estructura del SD Agent

El SD Agente se compone mínimamente de un paquete de binarios y un archivo de configuración advagent.properties.
La integración con la solución a manejar y monitorear se realiza a través de scripts del sistema operativo, en el caso de Windows serán .bat o .cmd, en Linux serán shell scripts por ejemplo bash scripts.
Las operaciones que realiza el agente con la solución son: inicar, detener, consultar estado de ejecución y opcionalmente consultar paramentos y estados adicionales.
Por lo tanto es necesario indicar en el archivo de configuración éstos scripts, además de los parámetros requeridos por la solución y los requeridos por el agente.

4.3 Operaciones que realiza el SD Agent

Como se mencionó en el capítulo 2, las operaciones que realiza en SD Agent son:

Requerir status de la solución a comandar e informar al SD Server
Descargar actualizaciones de la solución
Efectuar la instalación de las actualizaciones
Ejecutar los scripts de BBDD y actualizar su estado de ejecución en la misma.
Monitoreo de indicadores de sistema operativo (memoria, disco)
Recolectar información adicional y enviarlo al server.

Requerir estado e Informar

Periódicamente el agente hace un envió de status al SD Server con datos de status recolectados de la solución, estado de actualización e instalación. En cuanto a informar el estado de ejecución la solución, el agente ejecuta un script que se especifica en el parámetro de configuración application.command.status y se envía el mensaje descripto en el capítulo 2 - Status

Descargar actualizaciones

Cuando el agente recibe del SD Server el comando update (ver capítulo 2 - Update)
Se conecta al repositorio especificado en el comando, y realiza la descarga de actualizaciones.

Instalación de actualizaciones

Cuando el agente recibe del SD Server el comando install (ver capítulo 2 -Install)
Procede a realizar varias tareas:

Detener la solución
Backup de archivos de la version de solución que está instalada
Backup de base de datos de la solución.
Instalación de los nuevos archivos descargados del repositorio
Ejecución de scrips de base de datos
Iniciar la solución

A continuación de detallan estas tareas:

Detener Solución

El agente ejecuta el shell script indicado en el parámetro application.command.stop

Backup de archivos

Se copian los archivos de la solución indicados en application.base.path en el directorio de resguardo indicado en el parámetro application.backup.path, vaciando previamente su contenido.

Backup de base de datos

Se efectúa un backup en la base de datos cuyos parámetros de conexión se indican en los parámetros sql.*
El backup de BD se puede obviar si en el comando de install se especifica backupdb=false.
En el caso de MS Sql Server, el backup es realizado a través de script con el comando sql "backup database ..." soportado en las versiones de Sql Server retail y express.
En el caso de BD Oracle, el backup se realiza con la herramienta de Oracle "rman", la cual sólo puede ser ejecutada en la misma máquina dónde está ejecutándose el motor de la BBDD, esta es una característica de esta BD en particular, por lo tanto requiere que el agente esté instalado y ejecutándose en la misma máquina que el motor BD para realizar el backup.

Instalación de los nuevos archivos

Se copian los archivos descargados del repositorio, los correspondientes a la solución, en el directorio especificado en

application.base.path

Todos los archivos serán copiados respetando la estructura de directorios contenida en el paquete de actualización descargado de director (git) salvo los definidos en los archivos "ignore.txt" situados en:

Directorio raíz del agente
1. Tiene la intención de ser usado siempre con el fin de ignorar archivos que normalmente poseen una configuración particular por terminal/instalación y qué si son pisados, la aplicación deja de funcionar
Directorio "conf" del paquete de actualización
1. tiene la intención de ser usado eventualmente en una versión en particular

Se ignorarán los archivos/directorios que se encuentren listados en el archivo "ignore.txt".
Se admite "*" como comodín múltiple ó
'?' como comodín simple.

Por ejemplo:

config*
run.bat
ejemplo.*

En este caso se ignorarán los archivos/directorios que comiencen con "config", los archivos "run.bat" y los archivos/directorios que se llamen "ejemplo" y posean cualquier extensión.

Nota
NOTA: No está soportado ignorar rutas.

Ejecución de scripts de base de datos

Los motores actualmente soportados con los siguientes:

Microsoft SQL Server
Oracle
Hyper Sonic

En caso que existan scripts de base de datos, se sigue el siguiente proceso descripto en la siguiente ilustración:

Image Added
Ilustración 1 - Proceso de ejecución de scripts

En base a la propiedad script.subFolder del archivo de configuración; que indica a partir de que carpeta dentro de scripts se deben buscar los archivos (no recursivamente), se escanean los archivos que cumplen con el patrón *.sql.

Nota
Nota: Esto permite poder tener distintas carpetas con los scripts, por ejemplo: mssql, Oracle, db2, PROD, laboratorio, etc, con el objetivo de poder manejar para el mismo producto/solución, diferentes configuración de BBDD, como ser POS vs Kiosco

2. Se retornan todos los identificadores de changeSetIDs encontrados en el archivo. Un ChangeSetID es un identificador único que representa un conjunto de script o cambios que posee una versión determinada, por ejemplo:

– Changeset src/db.changelog.create.xml::script-20160616-74::autor
Siendo:

el nombre del archivo: db.changelog.create.xml
el changeSetID: script-20160616-74
el nombre del autor: autor

La/s línea/s siguiente/s hasta el final del archivo o hasta el próximo identificador de changeLog, compone/n el script SQL a ejecutar. En caso de encontrar duplicados, lo indica y detiene el proceso.

IP de la terminal donde se encuentra el SD Agent

3. Debe existir en la base de datos la tabla STS_DB_CHANGE_LOG descripta al final de este documento en la sección: DDL Tabla para actualización de scripts. Esta tabla contiene entradas por changeLogID que indican su status (0=OK, 1=ERROR) de ejecución, de este modo, se evita volver a ejecutar un script que ya fue ejecutado previamente, también, el propósito de esta tabla es tener una bitácora que indica el timestamp en que sucede la ejecución, el status, el orden de ejecución, el nombre del archivo del que provino el changeSetID, el resultado de la ejecución, etc.

4. En este paso se buscan los ya procesados descriptos en el punto anterior.

1. Se conforman colecciones que indican de cada archivo, que changeSetID es candidato a ejecutar y su script.
2. Se retorna el contenido del paso anterior.
  1. Por cada archivo, se toma cada changeSetID, se impacta en STS_DB_CHANGE_LOG que se está por ejecutar, se ejecuta el script, en caso de error toma ese retorno y termina el proceso de actualización, también refleja el error en STS_DB_CHANGE_LOG. En caso de no haber errores, por cada script se impacta la correcta ejecución también en STS_DB_CHANGE_LOG.

Nota

Notas:

Para Microsoft SQL Server se usa como fin de comando la sentencia GO
Para Oracle se usa como fin de comando el carácter ";" o bien el formato de Stored Procedure
Para Hyper Sonic se usa como fin de comando el carácter ";"
Todos los comandos SQL dentro de un ChangetSet se ejecutan dentro de una transacción SQL. Si una sentencia falla se hará Rollback. Se debe notar que las capacidades de Rollback serán dadas por el motor de base de datos utizado. Por ejemplo, no en todos los motores de BBDD funciona un rollback de un comando ALTER TABLE.

Se adjuntan ejemplos tanto para MSSQLServer, Oracle y Hyper Sonic:

View file

name	hsqldb-sql-store.sql
height	250

View file

name	mssql-sql-store.sql
height	250

View file

name	oracle-sql-store.sql
height	250

Iniciar la solución

El agente ejecuta el shell script indicado en el parámetro application.command.start

Âncora
_Toc477778335
_Toc477778335
Âncora
_Toc495332184
_Toc495332184
4.4 Estructura orientativa del SD Agent aplicado a una Solución

Como se mencionó anteriormente, el SD Agent se compone de binarios y configuración.
La solución que manejará el agente requerirá su propia estructura de directorios para sus binarios y configuración.
Adicionalmente, el agente utilizará directorios adicionales como por ejemplo para descargar las actualizaciones desde el repositorio y realizar backup de archivos
La estructura de directorios podría ser:
sdSolucion
│
├───sdAgent
│ ├───lib
│ └───logs
├───sdAgentCmds
├───bkp
├───localRepo
└───Solucion
├───app
├───batch
├───docs
├───legal
├───meta-data
└───scripts

En el directorio sdAgent contendrá el archivo de configuración advAgent.properties y algunos archivos adicionales, como ser un batch script para iniciar el agente, un directorio lib donde residirán los binarios de agente, un directorio logs donde el agente dejará registro de la actividad.
El directorio sdAgentCmds contendrá los shell scripts para iniciar/detener/consultar la solución.
El directorio bkp es dónde se hará el backpup de los archivos de la solución durante la tarea de instalación.
El directorio localrepo es dónde se descargarán las actualizaciones del repositorio remoto.
El directorio Solucion correponde a la estructura de archivos de la solución, que durante la instalación se genera a partir de lo descargado en localrepo
Dentro del directorio Solucion, en app estará todo requerido por la solución para su funcionamiento. Los otros directorios batch, docs, legal, scripts, el de scripts es dónde la solución dejará los scripts de BD que el agente ejecutará durante una instalación

Âncora
_Toc477778336
_Toc477778336
Âncora
_Toc495332185
_Toc495332185
4.5 Configuración del SD Agent

Se realiza en el archivo advAgent.properties

Campo	Descripción
company.id	Id de la compañía, configurada en SD Server.
store.id	Id de la tienda, configurada en SD Server.
terminal.id	Id de la terminal, configurada en SD Server.
device.type	Categoría o tipo de la terminal, configurada en SD Server.
listening.port	Puerto TCP/IP en que el agente expone los servicios http
advserver.url	Direccion URL base (de la forma https//ip:port/) del SD Server
advserver.status.path	Path relativo al URL base de SD Server, donde el SD Aget informa status
advserver.polling.seconds	Período en segundos en que el SD Agent informa estatus al SD Server
product.code	Código del Producto STS, configurado en SD Server.
product.description	Descripción del Producto STS, configurado en SD Server.
product.version	Versión del Producto STS, configurado en SD Server.
repository.local.path	Directorio local donde almacenar las actualizaciones descargadas del repositorio
application.base.path	Directorio de la Solución STS
application.backup.path	Directorio para resguasdar la Solución previo una acatualización
application.command.start	Shell script con los comandos necesarios para iniciar la Solución
application.command.status	Shell script con los comandos para solicitar estado a la Solución
application.command.stop	Shell script con los comandos para detener la Solución
application.status.running.text	Texto a buscar por SD Agent en el comand.status para tomar como app en ejecución
application.extended.info.command	Shell script para que las aplicaciones informen datos adicionales
application.extended.info.resultfile	Archivo de texto con informacion adicional a informar en el envió de status
cancel.install.if.app.running	Flag que con valor 'true' cancela la instalación si la Solución está en ejecución
application.start.on.agent.start	Flag que con valor 'true' indica iniciar la Solucíon al inicar el SD Agent
application.start.after.install	Flag que con valor 'true' indica iniciar la Solucíon luego de instalación
sql.server	Direccion ip del servidor de BD Sql
sql.port	Port del servidor de BD Sql
sql.db	Nombre de la BD Sql
sql.user	Usuario de la BD
sql.pass	Contraseña de la BD (Base 64 del TDES generado con herramienta CipherUtil )
sql.bkp.dir	Directorio del backup del la BD (locla al server donde reside la BD)
sql.db.type	Tipo de servidor Sql: 'oracle' o 'mssql'
sql.oracle.bin.dir	Directorio de binarios de la instalacíon BD Oracle, donde reside la herramienta 'rman'
sql.oracle.temp.dir	Directorio temporal requerido para la ejecución de la herramienta 'rman'
scripts.subFolder	Es el path relativo a la carpeta scripts en donde van a estar los scripts a ejecutar. Ejemplos: Mssql, Oracle, Mssql-demo, Oracle-prod, .

Repositorio

Los valores repository.remote.url, repository.user, repository.pass serán provistos por el SD Server en el mensaje de update. En caso que el SD Sever no lo envíe, se utilizarán los configurados.

Contraseñas

Para los valores de contraseña, se provee de una herramienta 'CipherUtil' para encriptar las mismas y codificar dicho encriptado en Base 64, de forma que pueda copiarse sin problemas de caracteres de control.
El CipherUtil es un archivo .jar y se ejecuta desde linea de comando:
java -cp cipherUtil.jar com.synthesis.advagent.CipherUtil
Solicita el ingreso del valor a encriptar y genera por pantalla el valor a copiar en la configuración, adicionalmente guarda el valor en un archivo cuyo nombre indica por pantalla.

Información adicional

El valor application.extended.info.command indica un shell script, para que la Solución pueda suministrar información adicional para que el agente envíe al SD Server en el envío de status. Los datos que genere dicho script deberá guardarlo en un archivo (indicado en application.extended.info) para que el SD Agent lo tome.
El formato de este archivo deberá 'categoria.nombre=valor'. El SD Server agrupará la información en base a dicha categoría.
Ejemplo de un registro del archivo: user.language=en

DDL Tabla para actualización de scripts.

Para tener un seguimiento de la ejecución de los scripts, se usa la siguiente tabla con la que el agente cuenta para mantener el orden y ejecución.

En Microsoft SQL Server:

CREATE TABLE STS_DB_CHANGE_LOG
(
CHANGE_SET_ID VARCHAR(200) NOT NULL,
PRODUCT_ID VARCHAR(100) NOT NULL,
DATEEXECUTED DATETIME,
FILENAME VARCHAR(200),
ORDEREXECUTED INT,
LOGEXECUTED TEXT,
STATUS INT,
CONSTRAINT STS_DB_CHANGE_LOG_CHANGE_SET_ID_PRODUCT_ID_pk PRIMARY KEY (CHANGE_SET_ID, PRODUCT_ID)
)

En Oracle:

CREATE TABLE STS_DB_CHANGE_LOG
(
CHANGE_SET_ID VARCHAR2(200) NOT NULL,
PRODUCT_ID VARCHAR2(100) NOT NULL,
DATEEXECUTED DATE,
FILENAME VARCHAR2(200),
ORDEREXECUTED NUMBER(10),
LOGEXECUTED LONG,
STATUS NUMBER(10),
CONSTRAINT CHANGE_SET_ID_PRODUCT_ID_pk PRIMARY KEY (CHANGE_SET_ID, PRODUCT_ID)
)

En Hyper Sonic

CREATE TABLE STS_DB_CHANGE_LOG(CHANGE_SET_ID varchar(200) NOT NULL,PRODUCT_ID varchar(100) NOT NULL,DATEEXECUTED datetime NULL,FILENAME varchar(200) NOT NULL,ORDEREXECUTED int NULL,LOGEXECUTED varchar(32768) NULL,STATUS varchar(200) NULL
);
ALTER TABLE STS_DB_CHANGE_LOG ADD CONSTRAINT PK_STS_DB_CHANGE_LOGUNIQUE (CHANGE_SET_ID,PRODUCT_ID );

Las columnas de esta tabla tiene el siguiente propósito:

...

CHANGE_SET_ID
1. Tipo dato: VARCHAR(200)
2. Uso: identificador de conjunto de cambios o CHANGE SET
PRODUCT_ID
1. Tipo dato: varchar(100)
2. Uso: Identificador del producto, el mismo que está bajo la propiedad del agente "product.code"
DATEEXECUTED
1. Tipo dato: datetime
2. Uso: fecha en que se ejecutó el change set
FILENAME
1. Tipo dato: VARCHAR(200)
2. Uso: de que archivo se sacó el change set
ORDEREXECUTED
1. Tipo dato: Integer
2. Uso: orden de ejecución. Número consecutivo, de uso principal para SAC
LOGEXECUTED
1. Tipo dato: BLOB
2. Uso: resultado de ejecución del change set
STATUS
1. Tipo de dato: int
2. Uso: indica si la ejecución fue o no exitosa (ERROR/OK)

Âncora
_Toc495332186
_Toc495332186
4.6 Integración con Maven

El agente está publicado en Maven.
Por lo tanto se puede integrar el agente a la solución referenciando el siguiente artefacto:

...

company.id=$(company) store.id=$(store) terminal.id=$(terminal) device.type=$(device) listening.port=$(port) advserver.url=$(url) product.code=$(product) product.description=$(product.description) product.version=$(version) repository.local.path=$(local.path) application.base.path=$(base.path) application.backup.path=$(backup.path) scripts.subfolder=$(scripts.subFolder) application.command.start=$(cmd.start) application.command.status=$(cmd.status) application.extended.info.command=$(cmd.info) application.extended.info.resultfile=$(cmd.info.result) application.command.stop=$(cmd.stop) cancel.install.if.app.running=$(cancelIfRunningApp) application.start.on.agent.start=$(appStartOnAgentStart) application.start.after.install=$(appStartAfterInstall)

Nota
Nota: las propiedades a reemplazar son las que están entre $(….)

...

#*****************************************************************************************************************# Datos de conexion a la BBDD# NOTA: La realizacion del backup es condicional a que el director-server envie el flag de backup#***************************************************************************************************************** #tipo de base de datos a utilizar. Valores soportados "mssql", "oracle" y "hsqldb". En caso de no utilizar BBDD dejar vacio sql.db.type=$(sql.db.type) #IP de BBDD. En HSQLDB dejar vacio sql.server=$(sql.server) #puerto de BBDD. En HSQLDB dejar vacio sql.port=$(sql.port) #nombre de BBDD. EN HSQLDB poner la ruta y nombre del archivo que la BBDD sql.db=$(sql.db) #nombre de la instancia de la BBDD. Dato opcional. Si está vacio no se usa sql.instance=$(sql.instance) #usuario de la BBDD sql.user=$(sql.user) #contraseña de la BBDD sql.pass=$(sql.pass) #directorio donde se realizará el backup de la BBDD. Solo se usara si el Director Server envía el flga activo de Backup sql.bkp.dir=$(sql.bkp.dir) #El backup en oracle se hace a traves de una herramienta llamada "". Oracle no permite el backup a traves de un comando SQL, por lo que es requerido tener previamente#instalado dicha herramienta sql.oracle.bin.dir=$(sql.oracle.bin.dir) # C:\\oraclexe\\app\\oracle\\product\\11.2.0\\server
bin sql.oracle.temp.dir=$(sql.oracle.temp.dir) # C:
oraclexe sql.oracle.sid=$(sql.oracle.sid)

Âncora
_Comunicándose_directamente_con
_Comunicándose_directamente_con
Âncora
_Toc495332187
_Toc495332187
5. Comunicándose directamente con el director

Âncora
_Toc475547346
_Toc475547346
Âncora
_Toc475550219
_Toc475550219
Âncora
_Toc476311274
_Toc476311274
Âncora
_Toc476827876
_Toc476827876
Âncora
_Toc476923208
_Toc476923208
Âncora
_Toc476923224
_Toc476923224
Âncora
_

...

Toc476923248
_

...

Toc476923248
Âncora
_

...

Toc477779395
_

...

Toc477779395
Âncora
_

...

Toc483212368
_

...

Toc483212368
Âncora
_

...

Toc483212928
_

...

Toc483212928
Âncora
_

...

Toc483212951
_

...

Toc483212951
Âncora
_

...

Toc495332188
_Toc495332188
5.1 Integración

La integración directa con Director Server consiste en enviar directamente los mensajes soportados por el servidor y saber interpretar los mensajes que éste último es capaz de enviar en forma de comandos.

Âncora
_

...

Toc495332189
_

...

Toc495332189
5.2 Tipos de Operación

En este apartado se detallan los mensajes implementados en Synthesis Director.

Âncora
_

...

Status
_

...

Status
Âncora
_

...

Toc495332190
_

...

La integración directa con Director Server consiste en enviar directamente los mensajes soportados por el servidor y saber interpretar los mensajes que éste último es capaz de enviar en forma de comandos.

...

En este apartado se detallan los mensajes implementados en Synthesis Director.

...

Este mensaje de estado es utilizado para que el SD Agent informe los detalles de la terminal y de la versión del Producto STS en la terminal.
Es un mensaje que va desde el Agente hacia el Server.

Aviso
Importante: Se recomienda el envío del mensaje status cada 2,5 minutos.

Sentido del mensaje

El mensaje de estado va desde el agente hacia el Director Server.
Agent  Server

Mensajería

El mensaje de estado se debe enviar a Director Server mediante el uso de un POST y bajo HTTPS a la siguiente URL:

...

En el BODY del requerimiento se debe enviar un mensaje en formato JSON con la siguiente información:

...

companyId

...

Id de la compañía del retail. Se carga por configuración

...

listeningPort

...

Puerto de la terminal donde se encuentra el SD Agent. Se carga por configuración

...

date

...

Fecha y hora de envío. Formato aaaammddHHmmssSUTC, donde S es el símbolo positivo o negativo y UTC es el huso horario en formato hhmm

...

deviceType

...

Categoría de la terminal. Se carga por configuración

...

terminalId

...

Terminal de la tienda de la compañía del retail. Se carga por configuración

...

storeId

...

Id de la tienda de la compañía del retail. Se carga por configuración

...

host

...

Nombre de la terminal donde se encuentra el SD Agent

...

ip

...

IP de la terminal donde se encuentra el SD Agent

...

token

...

Un token que luego Director Server usará para enviar los comandos hacia el agente.
Sirve principalmente como medida adicional de seguridad.
Se aconseja renovar el token cada X cantidad de tiempo (12hs por ejemplo) o cada X cantidad de mensajes.

...

tokenExp

...

Toc495332190
5.2.1 Status

Este mensaje de estado es utilizado para que el SD Agent informe los detalles de la terminal y de la versión del Producto STS en la terminal.

Es un mensaje que va desde el Agente hacia el Server.

Aviso
Importante: Se recomienda el envío del mensaje status cada 2,5 minutos.

Sentido del mensaje

El mensaje de estado va desde el agente hacia el Director Server.
Agent  Server

Mensajería

El mensaje de estado se debe enviar a Director Server mediante el uso de un POST y bajo HTTPS a la siguiente URL:

https://IP:port/director/agent/status

En el BODY del requerimiento se debe enviar un mensaje en formato JSON con la siguiente información:

Estos valores serán procesados por director server e incluidos como información adicional de la terminal.
Las claves aquí utilizadas deberán ser dadas de alta en la BBDD de Director para poder mostrarlas correctamente en la consola de monitoreo.
La "clave" debe seguir el siguiente formato.
IdGrupo.NombrePropiedad donde
IdGrupo permite agrupar las propiedades según algun criterio de agrupación (hardware, sistema, etc)
NombrePropiedad es el nombre de la propiedad que se quiere visualizar
Ejemplo:
"bridgePOS.logged.user":"SUSER"
"promo.map.version":"1.0"

Colección	Campo	Descripción
	companyId	Id de la compañía del retail. Se carga por configuración
	listeningPort	Puerto de la terminal donde se encuentra el SD Agent. Se carga por configuración
	date	Fecha y hora de envío. Formato aaaammddHHmmssSUTC, donde S es el símbolo positivo o negativo y UTC es el huso horario en formato hhmm
	deviceType	Categoría de la terminal. Se carga por configuración
	terminalId	Terminal de la tienda de la compañía del retail. Se carga por configuración
	storeId	Id de la tienda de la compañía del retail. Se carga por configuración
	host	Nombre de la terminal donde se encuentra el SD Agent
	ip	IP de la terminal donde se encuentra el SD Agent
	agentVersion	Indica la versión de software del agente
	token	Un token que luego Director Server usará para enviar los comandos hacia el agente. Sirve principalmente como medida adicional de seguridad. Se aconseja renovar el token cada X cantidad de tiempo (12hs por ejemplo) o cada X cantidad de mensajes.
	tokenExp	Fecha y hora de expiración del token. Formato aaaammddHHmmssSUTC, donde S es el símbolo positivo o negativo y UTC es el huso horario en formato hhmm
product	status	Informa el estado de SD Agent. Ver tabla 6.1.1 Códigos de Estado de SD Agent
	detail	Mensaje adicional y detallado de la tarea
	appIsRunning	Informa si el Producto STS está en funcionamiento o está detenido. Valores posibles: true/false. El chequeo es según el Producto STS. Ejemplo, chequeo de puerto, control de proceso en ejecución, etc
	taskUUID	Identificador de la tarea enviado por SD Server. Solo se envía cuando el mensaje de status representa el estado de ejecución de una tarea, en ese caso se debe utilizar el taskUUID que el SD Server envió originalmente.
	taskStatus	Informa el código del estado de la tarea. Ver tabla 6.1.3 Códigos de Estado de Tarea Solo se envía cuando
	task	Código de la tarea. Ver tabla 6.1.2 Códigos de Tarea
	version	Versión del Producto STS. Si no se efectúo previamente una instalación se envía 0
	code	Código del Producto STS. Se carga por configuración
	description	Descripción del Producto STS. Se carga por configuración
	isAlivePort	Chequeo del puerto para POS. Se encuentra en desuso
	lastInstall	Fecha y hora de la última instalación del Producto STS. Formato aaaammddHHmmssSUTC, donde S es el símbolo positivo o negativo y UTC es el huso horario en formato hhmm. En caso de que nunca se haya instalado una versión, se envía el formato estándar 19700101
	lastUpdate	Fecha y hora de la última sincronización del Producto STS. Formato aaaammddHHmmssSUTC, donde S es el símbolo positivo o negativo y UTC es el huso horario en formato hhmm
product	status	Informa el estado de SD Agent. Ver tabla 6.1.1 Códigos de Estado de SD Agent
	detail	Mensaje adicional y detallado de la tarea
	appIsRunning	Informa si el Producto STS está en funcionamiento o está detenido. Valores posibles: true/false. El chequeo es según el Producto STS. Ejemplo, chequeo de puerto, control de proceso en ejecución, etc
	taskUUID	Identificador de la tarea enviado por SD Server. Solo se envía cuando el mensaje de status representa el estado de ejecución de una tarea, en ese caso se debe utilizar el taskUUID que el SD Server envió originalmente.
	taskStatus	Informa el código del estado de la tarea. Ver tabla 6.1.3 Códigos de Estado de Tarea Solo se envía cuando
	task	Código de la tarea. Ver tabla 6.1.2 Códigos de Tarea
	version	Versión del Producto STS. Si no se efectúo previamente una instalación se envía 0
	code	Código del Producto STS. Se carga por configuración
	description	Descripción del Producto STS. Se carga por configuración
	isAlivePort	Chequeo del puerto para POS. Se encuentra en desuso
	lastInstall	Fecha y hora de la última instalación del Producto STS. Formato aaaammddHHmmssSUTC, donde S es el símbolo positivo o negativo y UTC es el huso horario en formato hhmm. En caso de que nunca se haya instalado una versión, se envía el formato estándar 19700101
	lastUpdate	Fecha y hora de la última sincronización del Producto STS. Formato aaaammddHHmmssSUTC, donde S es el símbolo positivo o negativo y UTC es el huso horario en formato hhmm. En caso de que nunca se haya sincronizado una versión, se envía el formato estándar 19700101
	synchronizedVersion	Informa la última versión sincronizada del Producto STS
	free memory	Memoria libre (en Bytes) en la terminal, reportada por la JVM Oracle
info	measureunit	Unidad de medida que se informan los valores. Por defecto en Bytes
	free disk	Disco libre (en Bytes) en la terminal, de la unidad donde se ejecuta el agente
	total memory	Capacidad total de memoria (en Bytes) en la terminal, reportada por la JVM Oracle
	total disk	Capacidad total del disco (en Bytes) en la terminal, de la unidad donde se ejecuta el agente
	java.version	Versión de Java RuntimeEnvironment
	java.vendor	Proveedor de Java RuntimeEnvironment
	java.arch	Tamaño de la plataforma
	os.name	Nombre del sistema operativo
	os.version	Versión del sistema operativo
	os.arch	Arquitectura del sistema operativo
	Otros valores del tipo "clave-valor"		. En caso de que nunca se haya sincronizado una versión, se envía el formato estándar 19700101
	synchronizedVersion	Informa la última versión sincronizada del Producto STS
	free memory	Memoria libre (en Bytes) en la terminal, reportada por la JVM Oracle
info	measureunit	Unidad de medida que se informan los valores. Por defecto en Bytes
	free disk	Disco libre (en Bytes) en la terminal, de la unidad donde se ejecuta el agente
	total memory	Capacidad total de memoria (en Bytes) en la terminal, reportada por la JVM Oracle
	total disk	Capacidad total del disco (en Bytes) en la terminal, de la unidad donde se ejecuta el agente
	java.version	Versión de Java RuntimeEnvironment
	java.vendor	Proveedor de Java RuntimeEnvironment
	java.arch	Tamaño de la plataforma
	os.name	Nombre del sistema operativo
	os.version	Versión del sistema operativo
	os.arch	Arquitectura del sistema operativo
	Otros valores del tipo "clave-valor"	Estos valores serán procesados por director server e incluidos como información adicional de la terminal. Las claves aquí utilizadas deberán ser dadas de alta en la BBDD de Director para poder mostrarlas correctamente en la consola de monitoreo. La "clave" debe seguir el siguiente formato. *IdGrupo.NombrePropiedad* donde IdGrupo permite agrupar las propiedades según algun criterio de agrupación (hardware, sistema, etc) NombrePropiedad es el nombre de la propiedad que se quiere visualizar Ejemplo: "bridgePOS.logged.user":"SUSER" "promo.map.version":"1.0"

Detalle del uso del “Status”

El “status” sirve para informar al Director Server sobre el estado del agente. Existen principalmente 2 casos en donde se debe informar dicho estado

Periódicamente cada X cantidad de tiempo para informar el estado del agente, de la aplicación, etc. En este caso y a modo aclaratorio
1. “status”, siempre enviar 00, indicando que el agente está disponible.
2. “taskUUID”, en blanco porque no hay tarea
3. “task”, en blanco porque no hay tarea
4. “taskStatus”, en blanco porque no hay tarea
5. “detail”, en blanco porque no hay tarea, o bien, una descripción que simplemente se podrá apreciar en el log de DirectorServer
Cuando el DirectorServer solicitó realizar una acción (sincronizar o actualizar). Cada acción supone la ejecución de una serie de pasos o tareas. Entonces se espera que la ejecución de cada tarea implique enviar un mensaje al servidor para indicar el estado de ejecución de dicha a tarea. Los datos obligatorios en éste caso son:
1. “status”, para indicar si está sincronización o actualizando
2. “taskUUID”, para indicar el ID de la tarea. Este dato lo envió previamente el server.
3. “task”, para indicar que tarea se está realizando. Ej: deteniendo app, haciendo backup, etc
4. “taskStatus”, para indicar el estado de ejecución de la tarea antes idnicada.
5. “detail”, para dar más detalle de la tarea. Ej: si dio error, entonces indicar una descripción del error. Si no hay error, por ejemplo info de un directorio, de una tarea, etc. En todos los caso, el mismo se mostrará en consola

Image Added

Parte del mensaje de status

Image Added

Error indicado por agente al instalar

Ejemplo
{ "product":{ "taskUUID":"", "detail":"app not running", "appIsRunning":"false", "taskStatus":"", "status":"00", "version":"banana", "code":"demo", "description":"BridgePOS", "isAlivePort":"", "lastInstall":"19691231210000-0300", "task":"", "lastUpdate":"20170815115253-0300", "synchronizedVersion":"201706301807128-0300" }, "companyId":"CP1", "listeningPort":"8383", "token":"c90816fa-dde6-49a4-a975-5a959bde7adf", "date":"20170815181921-0300", "info":{ "memory.free":"1785778176", "java.arch":"64", "bridgePOS.scanner":"NCR 1.0 ", "java.version":"1.8.0_91", "os.arch":"amd64", "user.language":"es", "user.name":"juanc", "memory.total":"8452411392", "disk.total":"501044211712", "measure.unit":"bytes", "bridgePOS.logged.user":"Demo ", "disk.free":"379280224256", "os.version":"6.3", "java.vendor":"Oracle Corporation", "file.encoding":"Cp1252", "os.name":"Windows 8.1", "user.country":"AR" }, "deviceType":"333", "terminalId":"12", "storeId":"1", "host":"NTK-JUANC", "tokenExp":"20170815201651-0300", "ip":"127.0.0.1" }

Códigos de respuesta

El server puede responder los siguientes valores:

...

Código	Descripción	Acción
200	El requerimiento fue procesado satisfactoriamente	Ninguna
404	La combinación compañía, tienda, terminal, producto no fue encontrada.	revisar la configuración del sistema
500	Error interno del sistema.	Reintentar esperando un lapso aproximado de 5 segundos.

Acceso al código

Para no tener que implementar el mensaje de "status", se puede acceder a las clases que representan ésta estructura incluyendo la siguiente dependencia de MAVEN
<groupId>synthesis.vtol4.director</groupId>
<artifactId>director-messaging</artifactId>
<version>VERSION</version>
<packaging>jar</packaging>
Donde "VERSION" se le deberá solicitar al Product Manager de Director.
Un vez que se tiene referencia al paquete la clase que representa la estructura es la siguiente:
com.synthesis.advagent.model.AdvAgentInfo

Âncora
_Toc495332191
_Toc495332191
5.2.2 Update

Este mensaje se utiliza para efectuar la sincronización y el SD Agent responde con los detalles de la terminal.

Sentido del mensaje

El mensaje o comando "update" va desde Director Server al agente
Agent  Server

Mensajería

Director Server realizará un llamado al agente a través de un POST bajo el protocolo HTTPS a la siguiente URL
https://IP:port/advagent/update
Donde,

...

Ejemplo
{ "companyId":"CP1", "taskUUID":"192a0cf0-1bb4-4db2-9dd1-320184416aa", "token":"f1552a72-f980-4a7e-86eb-8883940ce64c", "repoPass":"nosotros", "command":"UPDATE", "repoUser":"root", "terminalId":"12", "storeId":"1", "toVersion":"201706301807128-0300", "repoUrl":"http://10.4.13.182/root/demo.git" }

Códigos de respuesta

El agente puede responder los siguientes valores:

...

Código	Descripción	Acción
200	El requerimiento fue recibido satisfactoriamente	Responder en el body lo siguiente: { "advAgent": { "ack": "0", "update": "command received" } }
401	El token de seguridad no es válido	El server deberá esperar a recibir un token actualizado desde el agente
404	URL inválida	Se deberá revisar la configuración de Director Server

Acceso al código

Para no tener que implementar el mensaje de "update", se puede acceder a las clases que representan ésta estructura incluyendo la siguiente dependencia de MAVEN
<groupId>synthesis.vtol4.director</groupId>
<artifactId>director-messaging</artifactId>
<version>VERSION</version>
<packaging>jar</packaging>
Donde "VERSION" se le deberá solicitar al Product Manager de Director.
Un vez que se tiene referencia al paquete la clase que representa la estructura es la siguiente:
com.synthesis.advagent.model.AdvUpdateCommand

Acciones posteriores

Posterior a la recepción del comando de update, se deben enviar mensajes de status indicando el estado de ejecución de la tarea.
El mensaje de status tiene el mismo formato que un status regular pero adicionando los siguientes campos:

taskUUID
taskStatus
task

Âncora
_Toc495332192
_Toc495332192
5.2.3 Install

Este mensaje se utiliza para indicar que el agente debe proceder a la instalación de una nueva versión de la solución de software.

Sentido del mensaje

El mensaje o comando "install" va desde Director Server al agente
Agent  Server

Mensajería

Director Server realizará un llamado al agente a través de un POST bajo el protocolo HTTPS a la siguiente URL
https://IP:port/advagent/install
Donde,

...

Ejemplo
{ "companyId":"CP1", "taskUUID":"192a0cf0-1bb4-4db2-9dd1-320184416aa", "token":"f1552a72-f980-4a7e-86eb-8883940ce64c", "command":"INSTALL", "terminalId":"12", "storeId":"1",
"dbbackup":"false",}

Códigos de respuesta

El agente puede responder los siguientes valores:

...

Código	Descripción	Acción
200	El requerimiento fue recibido satisfactoriamente	Responder en el body lo siguiente: { "advAgent": { "ack": "0", "update": "command received" } }
401	El token de seguridad no es válido	El server deberá esperar a recibir un token actualizado desde el agente
404	URL inválida	Se deberá revisar la configuración de Director Server

Acceso al código

Para no tener que implementar el mensaje de "install", se puede acceder a las clases que representan ésta estructura incluyendo la siguiente dependencia de MAVEN
<groupId>synthesis.vtol4.director</groupId>
<artifactId>director-messaging</artifactId>
<version>VERSION</version>
<packaging>jar</packaging>
Donde "VERSION" se le deberá solicitar al Product Manager de Director.
Un vez que se tiene referencia al paquete la clase que representa la estructura es la siguiente:
com.synthesis.advagent.model.AdvInstallCommand

Acciones posteriores

Posterior a la recepción del comando de install, se deben enviar mensajes de status indicando el estado de ejecución de la tarea.
El mensaje de status tiene el mismo formato que un status regular pero adicionando los siguientes campos:

taskUUID
taskStatus
task

Âncora
_Toc495332193
_Toc495332193
6. Apartados

Âncora
_Toc495332194
_Toc495332194
6.1 Código de estados

En la siguiente sección se detallan los códigos de estado que se manejan entre SD Agent y SD Server, tanto para la notificación de estado periódica, como para el informe de estado de ejecución de cada comando (el progreso).

Âncora
_Toc475547350
_Toc475547350
Âncora
_Toc475550225
_Toc475550225
Âncora
_Toc476311280
_Toc476311280
Âncora
_Toc476827882
_Toc476827882
Âncora
_Toc476923214
_Toc476923214
Âncora
_Toc476923230
_Toc476923230
Âncora
_Toc476923254
_Toc476923254
Âncora
_Toc477779408
_Toc477779408
Âncora
_Toc483212363
_Toc483212363
Âncora
_Toc483212923
_Toc483212923
Âncora
_Toc483212946
_Toc483212946
Âncora
_Códigos_de_Estado
_Códigos_de_Estado
Âncora
_Toc495332195
_Toc495332195
6.1.1 Códigos de Estado de SD Agent (campo "status")

Indica el estado del agente.

...

Código	Descripción	Detalle
00	agentStatusAvailable	Disponible
01	agentStatusUpdating	Sincronizando
02	agentStatusInstalling	Actualizando

Âncora
_Códigos_de_Tarea
_Códigos_de_Tarea
Âncora
_Toc495332196
_Toc495332196
6.1.2 Códigos de Tarea (campo "task")

Indica que tipo de tarea se está ejecutando en el agente

...

Código	Descripción	Operación	Detalle
01	stoppingCode	Install	Finalización de la aplicación
03	backupFsCode	Install	Copia del sistema de archivos
05	backupBdCode	Install	Copia de la base de datos
07	installingFilesCode	Install	Instalación de archivos
09	runningScriptsCode	Install	Ejecución de scripts
11	startingAppCode	Install	Iniciación de la aplicación
13	updatingRepository	Update	Actualización del repositorio
50	skippingScriptCode	Install	Omisión de script
51	stopInstallAppRunningCode	Install	Cancelación de instalación por aplicación en proceso

Âncora
_Códigos_de_Estado_2
_Códigos_de_Estado_2
Âncora
_Toc495332197
_Toc495332197
6.1.3 Códigos de Estado de Tarea (campo "taskStatus")

Indica el estado de la tarea en ejecución.

...

Árvore de páginas

Histórico da Página

Versões comparadas

Versão antiga 1

Nova versão Atual

Chave

DIRECTOR - Manual de Integración 1.0

Manual de

Integración SD Server – SD Agent

1. Introducción

1.1 Acerca de este documento

1.2 Qué es Synthesis Director?

1.3 Arquitectura de Synthesis Director

1.4 Alcance

2. Manejo de versiones

2.1 Introducción

2.2 Empaquetado de soluciones

3. Integración de aplicación

Âncora_Integrando_el_componente_Integrando_el_componente Âncora_Toc495332180_Toc4953321804. Integrando el componente agente

Âncora_Toc477778331_Toc477778331 Âncora_Toc477779401_Toc477779401 Âncora_Toc483212356_Toc483212356 Âncora_Toc477778332_Toc477778332 Âncora_Toc495332181_Toc4953321814.1 Introducción

4.2 Estructura del SD Agent

4.3 Operaciones que realiza el SD Agent

Âncora_Toc477778335_Toc477778335 Âncora_Toc495332184_Toc4953321844.4 Estructura orientativa del SD Agent aplicado a una Solución

Âncora_Toc477778336_Toc477778336 Âncora_Toc495332185_Toc4953321854.5 Configuración del SD Agent

Âncora_Toc495332186_Toc4953321864.6 Integración con Maven

Âncora_Comunicándose_directamente_con_Comunicándose_directamente_con Âncora_Toc495332187_Toc4953321875. Comunicándose directamente con el director

Âncora_Toc475547346_Toc475547346 Âncora_Toc475550219_Toc475550219 Âncora_Toc476311274_Toc476311274 Âncora_Toc476827876_Toc476827876 Âncora_Toc476923208_Toc476923208 Âncora_Toc476923224_Toc476923224 Âncora_

Toc476923248_

Toc476923248 Âncora_

Toc477779395_

Toc477779395 Âncora_

Toc483212368_

Toc483212368 Âncora_

Toc483212928_

Toc483212928 Âncora_

Toc483212951_

Toc483212951 Âncora_

Toc495332188_Toc4953321885.1 Integración

Âncora_

Toc495332189_

Toc4953321895.2 Tipos de Operación

Âncora_

Status_

Status Âncora_

Toc495332190_

Sentido del mensaje

Mensajería

Toc4953321905.2.1 Status

Sentido del mensaje

Mensajería

Códigos de respuesta

Acceso al código

Âncora_Toc495332191_Toc4953321915.2.2 Update

Sentido del mensaje

Mensajería

Códigos de respuesta

Acceso al código

Acciones posteriores

Âncora_Toc495332192_Toc4953321925.2.3 Install

Sentido del mensaje

Mensajería

Códigos de respuesta

Acceso al código

Acciones posteriores

Âncora_Toc495332193_Toc4953321936. Apartados

Âncora_Toc495332194_Toc4953321946.1 Código de estados

Âncora_Códigos_de_Tarea_Códigos_de_Tarea Âncora_Toc495332196_Toc4953321966.1.2 Códigos de Tarea (campo "task")

Âncora_Códigos_de_Estado_2_Códigos_de_Estado_2 Âncora_Toc495332197_Toc4953321976.1.3 Códigos de Estado de Tarea (campo "taskStatus")

Âncora
_Integrando_el_componente
_Integrando_el_componente
Âncora
_Toc495332180
_Toc495332180
4. Integrando el componente agente

Âncora
_Toc477778331
_Toc477778331
Âncora
_Toc477779401
_Toc477779401
Âncora
_Toc483212356
_Toc483212356
Âncora
_Toc477778332
_Toc477778332
Âncora
_Toc495332181
_Toc495332181
4.1 Introducción

Âncora
_Toc477778335
_Toc477778335
Âncora
_Toc495332184
_Toc495332184
4.4 Estructura orientativa del SD Agent aplicado a una Solución

Âncora
_Toc477778336
_Toc477778336
Âncora
_Toc495332185
_Toc495332185
4.5 Configuración del SD Agent

Âncora
_Toc495332186
_Toc495332186
4.6 Integración con Maven

Âncora
_Comunicándose_directamente_con
_Comunicándose_directamente_con
Âncora
_Toc495332187
_Toc495332187
5. Comunicándose directamente con el director

Âncora
_Toc475547346
_Toc475547346
Âncora
_Toc475550219
_Toc475550219
Âncora
_Toc476311274
_Toc476311274
Âncora
_Toc476827876
_Toc476827876
Âncora
_Toc476923208
_Toc476923208
Âncora
_Toc476923224
_Toc476923224
Âncora
_

Toc476923248
_

Toc476923248
Âncora
_

Toc477779395
_

Toc477779395
Âncora
_

Toc483212368
_

Toc483212368
Âncora
_

Toc483212928
_

Toc483212928
Âncora
_

Toc483212951
_

Toc483212951
Âncora
_

Toc495332188
_Toc495332188
5.1 Integración

Âncora
_

Toc495332189
_

Toc495332189
5.2 Tipos de Operación

Âncora
_

Status
_

Status
Âncora
_

Toc495332190
_

Toc495332190
5.2.1 Status

Âncora
_Toc495332191
_Toc495332191
5.2.2 Update

Âncora
_Toc495332192
_Toc495332192
5.2.3 Install

Âncora
_Toc495332193
_Toc495332193
6. Apartados

Âncora
_Toc495332194
_Toc495332194
6.1 Código de estados

Âncora
_Códigos_de_Tarea
_Códigos_de_Tarea
Âncora
_Toc495332196
_Toc495332196
6.1.2 Códigos de Tarea (campo "task")

Âncora
_Códigos_de_Estado_2
_Códigos_de_Estado_2
Âncora
_Toc495332197
_Toc495332197
6.1.3 Códigos de Estado de Tarea (campo "taskStatus")