Consideraciones de almacenamiento entre variables, almacenamiento temporal, caché en la nube y Cloud Datastore en Jitterbit Integration Studio

Introducción

Integration Studio proporciona múltiples enfoques para manejar datos en tus integraciones. Estos van desde pasar valores simples entre operaciones hasta almacenar y recuperar datos. Cada enfoque está diseñado para casos de uso específicos y requisitos de rendimiento. Esta página describe los enfoques recomendados y no es una lista exhaustiva de todos los enfoques.

Variables para el paso de datos

Las variables están diseñadas para pasar valores, configuraciones y pequeñas cantidades de datos entre diferentes componentes en tu integración. Las variables son útiles cuando necesitas compartir información como IDs de sesión, parámetros de configuración o valores calculados entre scripts, transformaciones y operaciones. Estos tipos de variables están disponibles para su uso:

Para ejemplos e información detallada sobre cada tipo de variable, consulta sus páginas de documentación individuales.

Conectores de almacenamiento para la persistencia de datos

Los conectores de almacenamiento manejan el almacenamiento y la recuperación de archivos y datos persistentes dentro de tus integraciones. Estos conectores de almacenamiento son útiles cuando trabajas con archivos de datos reales, necesitas almacenar temporalmente resultados de procesamiento o requieres datos que persisten más allá de una sola cadena de operación:

Variable

Los endpoints de variable (Leer y Escribir actividades, que leen o escriben en una variable global), son fáciles de codificar y reducen la complejidad. Sin embargo, tienen ciertas limitaciones.

Se recomienda utilizar un endpoint de variable para escenarios donde una integración trabaja con conjuntos de datos pequeños, como solicitudes y respuestas de servicios web, o archivos pequeños con unos pocos cientos de registros.

Cuando el conjunto de datos alcanza el rango de megabytes, el endpoint de variable se vuelve más lento y comienza a ocurrir degradación cuando los datos superan los 4 MB de tamaño.

Cuando el conjunto de datos está en el rango más grande de varios megabytes, existe un riesgo de truncamiento de datos. Se recomienda limitar el uso de endpoints de variable a 50 MB para ser conservador y prevenir cualquier riesgo de truncamiento.

El uso de endpoints de variable en operaciones asincrónicas requiere una consideración especial. Hay un límite de 7 KB en el tamaño de un conjunto de datos utilizado en un endpoint de variable que se usa en una operación asincrónica. En este escenario, exceder ese límite puede resultar en truncamiento. Consulte la función RunOperation para una descripción de cómo llamar a una operación asincrónica.

Los endpoints de variable permiten la reutilización y reducen la complejidad

Utilizar un endpoint de variable para conjuntos de datos pequeños puede permitir la reutilización y reducir la complejidad. Por ejemplo, al construir cadenas de operaciones, cada operación puede tener actividades que funcionen como fuentes (Leer actividades) y objetivos (Escribir actividades). En lugar de construir combinaciones individuales de fuente o objetivo para cada operación, se puede utilizar un objetivo y una fuente de variable comunes.

Para aumentar la reutilización y la estandarización, se puede construir un script reutilizable que registre el contenido de la variable. Este enfoque también se puede lograr utilizando almacenamiento temporal, pero se necesita scripting adicional para inicializar la ruta y el nombre del archivo.

Al utilizar un endpoint de Variable, su alcance es la cadena de operación. Los valores del endpoint de Variable son únicos para una cadena de operación particular y se borran cuando la cadena de operación se completa. Este no es el caso con un endpoint de Almacenamiento Temporal (descrito en la sección siguiente).

Al realizar pruebas unitarias de operación, utilizar un endpoint de Variable es útil para cargar datos de prueba. Se puede agregar un script al principio de la cadena de operación para escribir datos de prueba:

  $memory = "a,b,c";

En contraste, escribir datos en un endpoint de Almacenamiento Temporal se ve así:

  WriteFile("<TAG>activity:tempstorage/Temporary Storage/tempstorage_write/Write</TAG>", "a,b,c");

  FlushFile("<TAG>activity:tempstorage/Temporary Storage/tempstorage_write/Write</TAG>");

Del mismo modo, leer datos es más simple con un endpoint de Variable:

  myLocalVar= $memory;

En contraste, así es como se leen datos de un endpoint de Almacenamiento Temporal:

  myLocalVar = ReadFile("<TAG>activity:tempstorage/Temporary Storage/tempstorage_read/Read</TAG>");

Almacenamiento Temporal

Almacenamiento Temporal los endpoints se utilizan frecuentemente en operaciones tanto en agentes en la nube como privados. Estos son distintos de Almacenamiento Local los endpoints, que solo se pueden usar en agentes privados.

Al utilizar un endpoint de Almacenamiento Temporal, los archivos temporales se escriben y se leen desde el directorio temporal predeterminado del sistema operativo en el agente que está realizando el trabajo:

• En el caso de un solo agente privado, el directorio de almacenamiento temporal es el directorio temporal predeterminado de ese servidor de agente privado.
• Si se están utilizando más de un agente privado en un grupo de agentes privados, el directorio de almacenamiento temporal es el directorio temporal predeterminado del servidor de agente privado específico que está realizando el trabajo.
• Como los agentes en la nube están agrupados en un grupo de agentes en la nube, el directorio de almacenamiento temporal es el directorio temporal predeterminado del servidor de agente en la nube específico que está realizando el trabajo.

Cuando se utiliza un grupo de agentes privado con múltiples agentes o un grupo de agentes en la nube, las operaciones de almacenamiento temporal permanecerán en el mismo servidor mientras sean parte de una cadena de operaciones. Sin embargo, si tienes dos cadenas separadas donde Cadena A escribe en el archivo de almacenamiento temporal myfile y Cadena B más tarde lee de myfile, Cadena B podría no acceder al mismo servidor de agente que Cadena A utilizó para escribir.

Al utilizar almacenamiento temporal, ten en cuenta estas pautas:

• Al usar agentes privados, para hacer que tu proyecto sea a prueba de actualizaciones, utiliza el almacenamiento temporal de tal manera que pasar de un solo agente privado a un grupo de agentes múltiples no requiera refactorización.

• Para asegurar que las lecturas y escrituras en el almacenamiento temporal ocurran en el mismo servidor de agente, mantén todas las actividades de Lectura y Escritura que hagan referencia al mismo almacenamiento temporal dentro de una sola cadena de operaciones. Esto se aplica ya sea que estés utilizando un grupo de agentes privados con múltiples agentes o un grupo de agentes en la nube.

• El almacenamiento temporal en agentes privados se elimina después de 24 horas por defecto por el servicio de limpieza de archivos de Jitterbit. La frecuencia del servicio de limpieza se puede configurar a través del archivo de configuración del agente privado en la sección [FileCleanup]. Sin embargo, en los agentes en la nube, los archivos temporales pueden ser eliminados de inmediato.

• Los agentes en la nube tienen un límite de tamaño de archivo de almacenamiento temporal de 50 GB por archivo. Los archivos temporales más grandes de 50 GB son posibles solo cuando se utilizan agentes privados.

• Al escribir en el almacenamiento temporal, el valor predeterminado es sobrescribir archivos. Esto se puede cambiar con la casilla de verificación Agregar al archivo en una actividad de escritura en almacenamiento temporal. Normalmente, esto requiere que después de leer la fuente, el archivo sea eliminado o archivado. Una forma sencilla de hacer esto es utilizar las opciones de post-procesamiento Eliminar archivo o Renombrar archivo en una actividad de lectura en almacenamiento temporal.

• Las palabras clave de nombre de archivo están disponibles y se pueden usar al crear un nombre de archivo.

  Ejemplo

  Puedes usar la [unique] palabra clave de nombre de archivo en una actividad de escritura en almacenamiento temporal para generar automáticamente nombres de archivo únicos y evitar sobrescribir archivos. Por ejemplo, nombrar tu archivo processing_[unique].csv crea archivos como processing_20240820143052123.csv.

• Un archivo en almacenamiento temporal se puede leer construyendo un script con la función ReadFile. Por ejemplo: ReadFile("<TAG>activity:tempstorage/Temporary Storage/tempstorage_read/Read</TAG>"). Ten en cuenta que esto funciona de manera confiable solo si hay un único agente privado.

Cloud Datastore (Beta)

Cloud Datastore (Beta) proporciona una solución de almacenamiento persistente donde la persistencia de datos varía según el tipo de almacenamiento, a diferencia de las soluciones de almacenamiento temporal que eliminan los datos después de que se completa una operación.

Cloud Datastore (Beta) aborda dos casos de uso principales:

• Soluciones de pares clave-valor: Almacena datos de búsqueda como US > Estados Unidos que se pueden referenciar en múltiples operaciones y proyectos.
• Procesamiento de datos basado en flujos de trabajo de estado: Gestiona datos que se mueven a través de diferentes estados de procesamiento, con limpieza automatizada para registros procesados.

Cloud Datastore (Beta) admite dos tipos de almacenamiento con diferentes características de persistencia:

• Búsqueda por clave: Los datos persisten hasta que se eliminan explícitamente, ideal para datos de referencia y tablas de búsqueda.
• Búsqueda por valor: Datos con flujos de trabajo de estado donde los registros se retienen por un máximo de 90 días. Sin embargo, una vez que los datos alcanzan el estado Processed, se eliminan automáticamente después de 60 días.

Funciones de caché en la nube

Más allá de las variables centrales y los conectores de almacenamiento, Integration Studio ofrece funciones de caché en la nube para mejorar el rendimiento y la funcionalidad de su integración.

Las funciones de caché en la nube ReadCache y WriteCache se utilizan para asignar espacios de datos que están disponibles en todos los proyectos y en todos los entornos. Un valor en caché es visible para todas las operaciones que se ejecutan en el mismo ámbito hasta que expira, independientemente de cómo se inició esa operación o en qué agente se ejecuta. Al almacenar datos en caché en Harmony, en lugar de depender de almacenes de datos locales o específicos de agentes como Temporary Storage o conectores Variable, los datos pueden compartirse entre operaciones separadas y a través de proyectos.

Estos son usos adicionales de la caché en la nube:

• Los datos pueden compartirse entre operaciones asíncronas dentro de un proyecto.
• Los errores que se generan en diferentes operaciones podrían almacenarse en una caché común. Al acumular resultados de operaciones de esta manera, se pueden construir alertas más completas.
• Los tokens de inicio de sesión pueden compartirse entre operaciones.