El Client Gateway es un ejecutable creado por T6 Planning para ser instalado en el entorno del cliente. A través de él, las tareas de carga de datos remotos son posibles. Funciona como un intermediario entre el servidor y el cliente, buscando datos de acuerdo con la configuración proporcionada por el servidor y devolviendo los datos solicitados.
El Client Gateway está disponible para los sistemas operativos Windows y Linux. Instálelo de acuerdo con su sistema operativo. No es necesario instalar otros paquetes como requisitos.
El Client Gateway es una aplicación que se ejecutará en segundo plano en el terminal. Para finalizar la aplicación, simplemente cambie a la ventana donde se está ejecutando y envíe el comando CTRL+C
.
Antes de comenzar la instalación, es necesario descargar el archivo del Client Gateway correspondiente a su sistema operativo Linux o Windows. Sin embargo, es imprescindible que el SO sea compatible con uno de los cifrados TLS 1.2 o 1.3 utilizados por T6 Planning:
Para que ClientGateway para v12.0 funcione correctamente, debe instalar el paquete de tiempo de ejecución y hospedaje de .NET Core 8.0 para Windows (v8.0.0). Para obtener más información sobre los requisitos previos para la versión 12.0, vaya a Guía de instalación - v12.0.
Client Gateway para la versión v11.11:
Client Gateway para la versión v12.0:
TLS 1.2:
TLS 1.3:
Es necesario realizar la liberación del firewall para el puerto 443.
En la carpeta descomprimida, donde se encuentran los archivos del Client Gateway, busque el archivo appsettings.json
. Ábralo en un editor de texto, preferiblemente uno que lea archivos JSON.
A continuación se muestra una imagen que enmarca todos los parámetros que actualmente se encuentran en el Client Gateway, basándose en la versión utilizada en este manual.
{
"DataLoadGatewayConfig": {
"LogFile": "ppGateway.log",
"HealthFile": "ppHealth.log",
"HealthInterval": 20,
"Url": "http://localhost/Sysphera/dataloadhub",
"Key": "",
"Issuer": "https://sysphera.com/dataloadhub/issuer",
"Audience": "https://sysphera.com/dataloadhub/audience",
"ClientId": "",
"DataSources": [
{
"DataSourceName": "",
"DataSourceType": "",
"StringConnection": ""
},
]
}
}
Descripción de los parámetros:
Tanto
LogFile
comoHealthFile
aceptan rutas completas donde se espera que se guarden los archivos. Sin embargo, también se aceptan rutas relativas y, en este caso, se considerará la carpeta desde donde se llamó al Client Gateway para formar la ruta absoluta.
/dataloadhub/
. Este parámetro informa dónde se encuentra la parte que está en el servidor, con la cual el Client Gateway se comunicará.Tenemos 3 parámetros que no necesitan ser modificados:
Para los próximos parámetros, necesitaremos acceder a T6 y crear un objeto del tipo Carga de Datos Remota.
Podemos tener varios datasources. Simplemente agréguelos al archivo respetando el formato JSON.
Podemos conectarnos a través de SQLserver, Oracle, REST, MySQL, Postgree y ODBC.
Para obtener los datos para completar los parámetros mencionados anteriormente, necesitaremos seguir los siguientes pasos:
00000000-0000-0000-0000-000000000000
porque no se ha guardado ningún datasource;DataSourceName
del archivo appsettings.json
;StringConnection
del archivo appsettings.json
;StringConnection
del archivo appsettings.json
;Vamos asignar estos valores a los parámetros mencionados. A continuación, se muestra un ejemplo con los datasources de tipo SQLSERVER, ORACLE, POSTGRE, MySQL, CosmosDB y DATALOADREST:
"ClientId": "A1A1A1A1-B2B2-C3C3-D4D4-E5E5E5E5E5E5",
"DataSources": [
{
"DataSourceName": "SQLServer",
"DataSourceType": "SQLSERVER",
"StringConnection": "Data Source=SQLServerConnection;Initial Catalog=DataBaseName;Trusted_Connection=false;Persist Security Info=True;User ID=User;Password=pwd"
},
{
"DataSourceName": "Oracle",
"DataSourceType": "ORACLE",
"StringConnection": "Data Source=OracleConnection;User ID=user;Password=pwd"
},
{
"DataSourceName": "PostgreSQL",
"DataSourceType": "POSTGRESQL",
"StringConnection": "Server=host.docker.internal;Port=5432;Database=mydb;User Id=user;Password=pwd;"
},
{
"DataSourceName": "MySQL",
"DataSourceType": "MYSQL",
"StringConnection": "Server=host.docker.internal;Database=myDataBase;Uid=user;Pwd=pwd;"
},
{
"DataSourceName": "CosmosDB",
"DataSourceType": "COSMOSDB",
"StringConnection": "AccountEndpoint=https://cosmodb-example.documents.azure.com:443/;AccountKey=bpuRR4tLLQO6M2RB1Jop1KBJbByDm1zLGp2LJHeZJLaSSkft5aCApY9T2tUKx9qg591XyaSLZ0hRDDiACDb44k1vkA==",
"Configuration": {
"Database": "SampleDB",
"Container": "SampleContainer"
}
},
{
"DataSourceName": "Data Load Rest",
"DataSourceType": "DATALOADREST"
}
]
En el caso de CosmosDB, el propio motor de Azure proporciona el ConnectionString, que es una combinación de su URL con el campo Primary Key (o Secondary Key) que se muestran en la pestaña Keys de su portal de Azure. También tenemos el campo Configuration, que no se solicita en otros datasources. Los datos para completar este campo son el nombre del Database creado en el portal de Azure y el nombre del Container utilizado.
Utilizando la carga de datos remota en una conexión con una base de datos NoSQL (CosmosDB), podemos garantizar la existencia de una columna, incluso si no contiene datos:
Para visualizar, vamos a crear un proceso del Workflow:
SELECT
Container.ID AS itemId, Container.price, Container.tags, Container.custom ? (Container.custom): null AS custom
FROM Container;
Esta sintaxis realizará la consulta en la base de datos y generará una columna llamada "custom", independientemente de si existe o no en la base. Si existe y contiene datos, estos serán retornados; si no, la columna será retornada con el valor "null".
Puede seleccionar en Destino una tabla de datos ya existente en nuestro sistema, pero es necesario que el número de columnas y los nombres en sus encabezados coincidan con los de la tabla de origen;
Puede marcar la casilla Reestructurar tabla de datos automáticamente, que ajustará automáticamente la tabla de destino, sin necesidad de que coincida el número y los nombres de las columnas con los de la tabla de origen;
Primero, es necesario preparar un contenedor para el gateway;
src
del proyecto PowerPlanning cd C:...\powerplanning\src;ImagenPublica/ClientGateway:latest
);Reemplace
ImagenPublica/ClientGateway:latest
con el nombre correcto de la imagen pública que está utilizando.
.env
de ejemplo cp ClientGateway/.env.sample ./;
src
;.env.sample
con sus configuraciones code .env.sample;El clientID se obtiene a través de T6. Cuando creamos un objeto del tipo "Carga de Datos Remota", al abrirlo, tendremos un código que deberá ser insertado en la parte de configuración
DataLoadGatewayConfig__ClientId=********-****-****-****-***********
;
docker run --env-file .env.sample --name ClientGateway -d ImagenPublica/ClientGateway:latest
Se creará dentro de T6 una Tabla de Datos con el nombre de la conexión creada en el objeto Carga de Datos Remota Load Postgres;
Podemos marcar la checkbox Reestructurar tabla de datos automáticamente que hará el ajuste automático de la tabla de destino, sin la necesidad de tener el mismo número y nombre de columnas de la tabla de origen;
Al añadir datos a la tabla de forma externa (a través de la base de datos) y ejecutar el gatillo nuevamente, estos cambios se reflejarán en la tabla de datos creada en T6.
appsettings.json
dentro de la carpeta ClientGateway;En la configuración tenemos 2 parámetros principales a los que debemos prestar atención:
- URL: Debe contener necesariamente el endpoint /dataloadhub
- ClientID: Es el código generado al guardar el objeto del tipo Carga de Datos Remota en T6;
appsettings.json
vamos a insertar otro bloque de información:{
"DataSourceName": "ODBC MSSQL",
"DataSourceType": "ODBC",
"StringConnection": "Driver={ODBC Driver 17 for SQL Server};Server=myServerAddress;Database=myDataBase;UID=myUsername;PWD=myPassword;"
}
Después de configurarlo, vamos a volver a T6, donde crearemos un Proceso del Workflow para poder visualizar el funcionamiento.
Podemos seleccionar en Destino una tabla de datos ya existente en nuestro sistema, pero es necesario que el número de columnas y los nombres en sus encabezados sean iguales a los de la tabla de origen;
Podemos marcar la checkbox Reestructurar tabla de datos automáticamente que hará el ajuste automático de la tabla de destino, sin la necesidad de tener el mismo número y nombre de columnas de la tabla de origen;
Vamos a crear un objeto en T6 del tipo Carga de Datos Remota (o añadir otra conexión si ya tiene un objeto de este tipo);
appsettings.json
dentro de la carpeta ClientGateway;appsettings.json
vamos a insertar otro bloque de información:{
"DataSourceName": "ODBC EXCEL",
"DataSourceType": "ODBC",
"StringConnection": "Driver={Microsoft Excel Driver (*.xls, *.xlsx, *.xlsm, *.xlsb)};DBQ=C:\\MyExcel.xls;"
}
En StringConnection, DBQ es la ubicación donde se guarda el archivo de Excel
Después de configurarlo, vamos a volver a T6, donde crearemos un Proceso del Workflow para poder visualizar el funcionamiento.
Ocurrirá un error si hay cambios en las columnas existentes en el archivo de Excel. Se debe mantener el mismo nombre en el encabezado de las columnas, así como no debe alterarse el número de columnas.
DataLoadGatewayConfig
será necesario incluir una nueva entrada:DataSourceName: "Data Load Rest",
DataSourceType: "DATALOADREST"
Los pasos para registrar el Client Gateway como un servicio de Windows.
SC.exe
tiene otros parámetros que pueden ser utilizados en la creación de un servicio. En el paso a paso descrito anteriormente, estos son los parámetros mínimos obligatorios para registrar un servicio. Puede obtener más información sobre los otros parámetros haciendo clic en el enlace: Microsoft Learn - SC.exe create
Para eliminar el servicio creado, el comando es: sc delete ServiceName, donde ServiceName es el nombre del servicio que deseamos eliminar.
Después de descargar el archivo de ClientGateway para Linux en la sección 2.1 de este manual, necesitaremos crear un servicio en el directorio /etc/systemd/system/
, que nombraremos como ClientGateway.service
.
nano
, vi
, vim
. En este manual utilizaremos nano
;
sudo nano /etc/systemd/system/ClientGateway.service
# ClientGateway.service
[Unit]
Description=T6 Enterprise Client Gateway
[Service]
ExecStart=dotnet /home/azureuser/ClientGateway/ClientGateway.dll
SyslogIdentifier=T6ClientGateway
User=azureuser # Nombre del usuario de Linux que ejecutará el servicio
Restart=always
RestartSec=5
[Install]
WantedBy=multi-user.target
nano
podemos hacerlo presionando CTRL + O);nano
podemos hacerlo presionando CTRL + X);Para asegurarnos de que el servicio está funcionando correctamente, podemos verificar su estado ejecutando el siguiente comando: sudo systemctl status ClientGateway.
La carga de datos incremental reemplaza los datos de la tabla en la base de datos, primero eliminando los datos y luego insertándolos, según el período seleccionado.
Para utilizar la carga de datos incremental, seguiremos los siguientes pasos:
TableName
, StartDate
y EndDate
; (Para información complementaria sobre Workflow, Triggers y Parámetros, acceda a: Workflow BPM)Podemos seleccionar en Destino una tabla de datos ya existente en nuestro sistema, pero es necesario que el número de columnas y los nombres en sus encabezados sean iguales a los de la tabla de origen;
Podemos marcar la checkbox Reestructurar tabla de datos automáticamente que hará el ajuste automático de la tabla de destino, sin la necesidad de tener el mismo número y nombre de columnas de la tabla de origen;
StartDate
, referente a la fecha de inicio de los registros que queremos;EndDate
, referente a la fecha final de los registros seleccionados;Estas configuraciones solo definirán los registros que serán eliminados de la tabla de destino. La parte de inserción dependerá de lo que se defina en el comando SQL anterior (si solo hace el "SELECT", se cargarán todos los registros, independientemente de la cantidad).
Ejemplo del comando SQL aplicando los parámetros:
SELECT * FROM REP_EXPLORER_OBJECT
WHERE
datModified >= COALESCE(NULLIF('Instance(StartDate)',"),'1970-01-01')
AND
datModified < COALESCE(NULLIF('Instance(EndDate)',"),'5000-01-01')
StartDate
y EndDate
, con la fecha inicial y la fecha final, respectivamente;Siempre que se actualice la versión de T6, es estrictamente necesario actualizar la versión del Client Gateway.
Para utilizar la carga de datos para la creación dinámica de una tabla de datos, sigamos los siguientes pasos:
Si no existe ninguna tabla de datos con el nombre definido, esta se creará dinámicamente y se guardará en la carpeta Raíz del T6.
Atención, si ya existe una tabla de datos con el nombre definido en el parámetro, sus datos serán sobrescritos;
Después de finalizar la configuración del proceso, haga clic en Guardar y publique el cubo;
En el trigger del proceso, definiremos en el parámetro TableName el nombre de la tabla de datos de destino;
Para finalizar, después de insertar el valor en el parámetro, disparemos el trigger.