Saltar al contenido

Mejores prácticas de Jitterbit iPaaS

Introducción

Este documento sirve como una guía general para utilizar la plataforma de integración como servicio (iPaaS) de Jitterbit. Proporciona orientación sobre las mejores prácticas para escenarios de integración comunes y recomendaciones utilizando las herramientas disponibles. Este documento no es exhaustivo y no cubre todos los escenarios.

Este documento es para usuarios de Integration Studio, la versión basada en la web de la aplicación de diseño de proyectos de Jitterbit. Para mejores prácticas utilizando Design Studio, la aplicación de diseño de proyectos de Jitterbit para escritorio, consulte Mejores prácticas con Design Studio.

Las mejores prácticas para App Builder, la aplicación de Jitterbit para crear aplicaciones web y móviles, se cubren por separado.

Debería estar familiarizado con Jitterbit iPaaS e Integration Studio a partir de los siguientes recursos:

En este punto, debería conocer los conceptos y términos básicos utilizados en Jitterbit iPaaS, y entender lo que queremos decir con proyectos, operaciones, puntos finales, programación, transferencia y despliegue.

Consulte la sección Recursos adicionales al final de esta página para enlaces a videos y otros documentos que amplían estas mejores prácticas.

Soporte, Gerentes de Éxito del Cliente y documentación

El acceso al soporte de Jitterbit está incluido como parte de una licencia de cliente de Harmony. Cuando surgen preguntas o problemas técnicos, se puede obtener asistencia experta del soporte de Jitterbit. La página de soporte de Jitterbit describe instrucciones especiales para situaciones de caída de producción con el fin de escalar problemas sensibles al tiempo.

También se puede contactar a su Gerente de Éxito del Cliente (CSM) con preguntas relacionadas con licencias u otros temas.

Este sitio de documentación (Documentación de Jitterbit) y nuestro sitio de documentación para desarrolladores (Portal de Desarrolladores de Jitterbit) contienen más de 3,600 URL únicas de material técnico.

Para ayudarle a localizar material relevante, el cuadro de búsqueda está prefiltrado para limitar los resultados de búsqueda a la sección de documentación que se está accediendo actualmente. Se puede buscar en toda la documentación eliminando el filtro de búsqueda. Para buscar frases específicas, colóquelas entre comillas dobles.

Recetas y plantillas

El Mercado proporciona más de 400 recetas y plantillas listas para usar en Integration Studio como base para diseños de integración:

  • Una receta de integración mueve datos en una dirección entre objetos a través de dos aplicaciones o sistemas.

  • Una plantilla de proceso acelera la ejecución de un proceso comercial específico utilizando numerosos objetos a través de múltiples aplicaciones o sistemas. Las plantillas de proceso están diseñadas para reducir el tiempo de implementación entre un 50 y un 80 por ciento.

Actualizaciones del producto Jitterbit

Las actualizaciones del producto Jitterbit se lanzan con frecuencia (ver Calendario de lanzamientos). Incluso un lanzamiento menor contiene nuevas características y mejoras junto con correcciones de errores.

Las aplicaciones web accesibles a través del portal de Harmony se actualizan automáticamente y siempre ejecutan la última versión lanzada.

Las actualizaciones del gateway de API en la nube y del grupo de agentes en la nube se aplican automáticamente. Para los grupos de agentes en la nube, hay dos conjuntos: Producción y Sandbox. Este último conjunto se utiliza para probar la compatibilidad con versiones preliminares del software de agentes y no es un entorno de desarrollo.

Las aplicaciones instaladas localmente se actualizan descargando y ejecutando un instalador:

Se recomienda mantenerse al día con las versiones, particularmente aquellas que incluyen actualizaciones de características.

Simplicidad en el diseño del proyecto y preferencia de características

Durante el proceso de diseño de un proyecto de integración, se pueden encontrar múltiples métodos de implementación que pueden resultar en la misma funcionalidad.

Si bien a menudo hay ventajas o desventajas de un método sobre otro dependiendo del caso de uso de integración (como se documenta), se recomienda siempre tener en mente el principio rector de simplicidad. Los proyectos diseñados de la manera más simple posible suelen tener una mayor longevidad y son mucho más fáciles de entender para un externo si se necesita realizar un cambio. Por otro lado, los proyectos excesivamente complejos pueden ser más difíciles de mantener y de transferir a otros durante una transición de responsabilidades.

Para diseñar proyectos más simples, se recomienda el siguiente orden de preferencia de características:

  1. Hacer uso de características sin código siempre que sea posible, como diseñar visualmente operaciones en el lienzo de diseño, agrupando componentes para ayudar a organizarlos, agregando etiquetas y comentarios al desplegar, y publicando operaciones como APIs.
  2. Aprovechar características de bajo código, como usar variables dentro de las pantallas de configuración de componentes basadas en asistente o manipular datos a nivel de campo en un mapeo de transformación utilizando una función de script.
  3. Según sea necesario, implementar lógica más compleja utilizando scripts escritos en el lenguaje de Jitterbit Script.
  4. Solo cuando no esté disponible un equivalente de Jitterbit Script, implementar scripts en JavaScript.

Diseño del proyecto y reutilización

Un escenario típico para reutilizar un proyecto implica el desarrollo de un proyecto inicial con el uso extensivo de variables globales y, especialmente, variables de proyecto. Los elementos configurables — como credenciales de endpoint, mapeos de campos opcionales, consultas parametrizadas, direcciones de correo electrónico y nombres de archivos — pueden ser expuestos como variables de proyecto. El proyecto inicial también puede contener funciones comunes como manejo de errores o el uso de cachés a nivel de entorno. El proyecto inicial se exporta y luego se importa en nuevos proyectos para formar una base consistente para el desarrollo.

Reutilización de endpoints

Los endpoints, creados al configurar una conexión y actividades asociadas utilizando conectores, se utilizan frecuentemente en operaciones. Sin embargo, no es necesario construir un endpoint único para cada operación. Dado que las configuraciones de actividad aceptan variables para rutas y nombres de archivos, se pueden construir endpoints genéricos una vez y luego configurarlos dinámicamente utilizando variables globales y de proyecto.

Por ejemplo, supongamos que se crea una conexión HTTP y una actividad asociada, y la configuración de la actividad especifica una ruta definida por una variable global, como $gv_http_path. Se puede utilizar un script controlador para poblar el $gv_http_path según sea necesario.

Otro ejemplo es una actividad de Consulta de Base de Datos con una condición. Su condición WHERE puede asignarse a una variable global, como $gv_database_condition.

La mayoría de los endpoints tienen la capacidad de ser configurados utilizando variables.

Reutilización de scripts

Los scripts independientes que realizan una función específica, como devolver una búsqueda en la base de datos o calcular un resultado a partir de una serie de argumentos, pueden ser candidatos para la reutilización, particularmente si se utilizan en múltiples operaciones.

Por ejemplo, si un script utiliza la función DBLookup contra una tabla de base de datos, y esta función se usa a lo largo del proyecto, entonces se puede construir un script independiente (separado de una operación). Usando la función ArgumentList o simples variables globales, el script puede aceptar argumentos y devolver un resultado. Dado que cada cadena de operación es un ámbito diferente, el mismo script se puede llamar de manera segura desde múltiples operaciones simultáneas.

Organización del proyecto

Los flujos de trabajo se utilizan como un medio de organización del proyecto. Un flujo de trabajo típicamente contiene operaciones relacionadas que procesan datos de principio a fin: Crear pedidos, Sincronizar maestro de clientes, Procesar confirmaciones, etc. Los procesos que son comunes en diferentes flujos de trabajo, como consultar un endpoint o manejar una condición de error de operación, pueden mantenerse en su propio flujo de trabajo y ser referenciados por otras operaciones de flujo de trabajo.

También puedes crear grupos personalizados donde se pueden recopilar componentes del proyecto para facilitar la referencia.

La configuración del Diseñador de un proyecto contiene la opción Numerar automáticamente las operaciones en el lienzo de diseño, que asignará automáticamente números a las operaciones según la posición de visualización de la operación en el diseñador del proyecto. Esos números no se muestran en los registros de operación. Si se necesita un esquema de numeración de operaciones, se puede implementar incorporando la numeración en el nombre de la operación.

Gestionar operaciones asincrónicas

Al usar la herramienta Invocar operación (Beta) o la función RunOperation en su modo asincrónico, las operaciones se ejecutan sin devolver el control a la función que llama. El uso de operaciones asincrónicas puede llevar a condiciones de carrera.

Por ejemplo, si Operación A actualiza una tabla de base de datos y está encadenada a Operación B, que lee esa misma tabla (ambas son sincrónicas), no se encuentran condiciones de carrera. Pero si Operación A se llama de manera asíncrona seguida inmediatamente por Operación B, entonces B puede ejecutarse antes de que A haya terminado.

Además, se debe gestionar el número de llamadas asíncronas simultáneas, ya que el número de operaciones simultáneas que se ejecutan en un agente está limitado (ver la sección [OperationEngine] del archivo de configuración del agente privado).

Credenciales de endpoint

Recomendamos usar un ID de sistema con permisos de administración para las credenciales de endpoint, en lugar de un ID a nivel de usuario. Los IDs de usuario suelen expirar o deben ser desactivados cuando un usuario deja una empresa.

Al usar variables de proyecto (cuyos valores pueden ser ocultos) para la gestión de credenciales, un administrador de organización de Harmony no tiene que ingresar credenciales de producción. Al configurar los permisos de usuario apropiados, un usuario puede aplicar las credenciales de producción a través de la página Proyectos de la Consola de Gestión.

Si se utilizan agentes privados, como alternativa a usar la Consola de Gestión, se pueden gestionar variables globales utilizando la sección [PredefinedGlobalVariables] del archivo de configuración del agente privado.

Persistir datos de integración

Cuando construyes integraciones en Integration Studio, elige un enfoque de almacenamiento de datos basado en el tamaño de tus datos y los requisitos de persistencia. Puedes usar variables, conectores de almacenamiento y funciones de caché.

Para una explicación más detallada de los enfoques, consulta Consideraciones de almacenamiento.

Variables

Utiliza variables para pasar valores, configuraciones y pequeñas cantidades de datos entre componentes de integración. Elige un tipo de variable según el alcance:

Conectores de almacenamiento

Estos conectores de almacenamiento están diseñados para almacenar y recuperar archivos y grandes conjuntos de datos que necesitan persistir más allá de una única cadena de operación:

Conector Persistencia Límites de tamaño Mejor para
Variable Cadena de operación 50 MB Archivos pequeños y pruebas
Almacenamiento temporal Cadena de operación 50 GB (nube) Archivos grandes y procesamiento
Cloud Datastore (Beta) Hasta que se elimine TBD Tablas de búsqueda y datos entre operaciones

Cuando utilices estos conectores, ten en cuenta las siguientes consideraciones:

  • Variable: Funciona mejor para pequeños conjuntos de datos. El rendimiento disminuye con archivos mayores de 4 MB. Existe un riesgo de truncamiento de datos por encima de 50 MB. Las variables son útiles para pruebas unitarias y aumentan la reutilización al crear un objetivo y fuente comunes para operaciones encadenadas.

  • Almacenamiento temporal: Estos archivos se escriben en el directorio temporal predeterminado del agente. Al usar un grupo de agentes privados con múltiples agentes o un grupo de agentes en la nube, las operaciones que utilizan almacenamiento temporal deben estar en la misma cadena de operación para asegurar que se ejecuten en el mismo agente. En agentes en la nube, los archivos pueden ser eliminados inmediatamente. En agentes privados, los archivos generalmente se eliminan después de 24 horas.

  • Cloud Datastore (Beta): Este conector proporciona una solución persistente para pares clave-valor o datos estructurados. Es ideal para compartir tablas de búsqueda o datos de referencia entre operaciones y proyectos.

Cloud caching

Utiliza las funciones ReadCache y WriteCache cuando necesites compartir datos entre proyectos, entornos u operaciones asincrónicas. El almacenamiento en caché en la nube es ideal para tokens de inicio de sesión, acumulación de errores y datos temporales a los que múltiples operaciones necesitan acceder.

Scripting

Los scripts escritos en el lenguaje Jitterbit Script o JavaScript pueden ser utilizados casi en cualquier lugar dentro de las operaciones y dentro de los mapeos de transformación.

When to use scripting

Las operaciones pueden organizarse en cadenas de operaciones de dos maneras: (1) vinculando operaciones utilizando condiciones de On Success y On Fail mediante acciones de operación, o (2) utilizando un controlador script.

En lugar de utilizar acciones de operación, un script controlador utiliza la función RunOperation para vincular operaciones mediante un script.

Para capturar una operación fallida, se puede utilizar la función If junto con RunOperation. Por ejemplo: If(!RunOperation(<operation tag>),<condition>), donde la condición puede utilizar GetLastError para capturar el error, y puede optar por detener todo el proceso utilizando RaiseError, y/o ejecutar otro proceso para acumular el texto del error.

Un script controlador puede ser beneficioso en situaciones como las siguientes:

  • Para ejecutar una operación que depende de factores externos como variables de proyecto o datos.
  • Para llamar a sub-operaciones desde dentro de un bucle, donde los datos se pasan a la operación desde una lista.
  • Para rastrear las actividades de la cadena de operaciones. Por ejemplo: (WriteToOperationLog("cantidad de registros a procesar: " + cnt), WriteToOperationLog("Iniciando operación de actualización en: " + Now()), WriteToOperationLog("Consulta a la base de datos: " + sql), etc.)

Otras áreas donde se utiliza frecuentemente la secuenciación son dentro de los campos mapeados en transformaciones y en otros scripts independientes. Si el mismo script se está utilizando en más de una transformación, considera configurar ese script como un script independiente y llamarlo desde cada transformación utilizando RunScript.

Convención de nombres para variables

Jitterbit iPaaS tiene cuatro tipos de variables:

Dado que el alcance de una variable local está limitado a un solo script, una convención de nombres para ellas puede ser muy simple, como letras en minúsculas o una palabra inicial, como return o myVariable. No se permiten puntos en las variables locales.

Las variables globales, dado que su alcance es mayor (una variable global está disponible para ser referenciada en las mismas operaciones o en operaciones posteriores y scripts dentro de una cadena de operaciones), deben utilizar una convención de nombres consistente para evitar confusiones. Por ejemplo, utilizando múltiples componentes para un nombre de variable, separados por puntos, se podría seguir un patrón como este:

type.category.subcategory
Componente Descripción
type Una abreviatura corta que identifica el tipo de variable, como pv (variable de proyecto), gv (variable global), io (nombre de origen/destino del endpoint), dict (diccionario), etc.
category Una categoría lógica para la variable, como sfdc, shipearly, confirm, order, etc.
subcategory Una subcategoría lógica para la variable, como purchase_orders, categories, ids, etc.

Combinando estos componentes, estos son los posibles nombres de variables:

  • $pv_shopify_base_url
  • $dict_staples_po_line_items
  • $io_request
  • $gv_sfdc_workorder_id

Dado que las variables se ordenan alfabéticamente en varios lugares de la interfaz de usuario, organizarlas jerárquicamente ayudará a gestionar y utilizar las variables.

Cualquiera que sea la convención que elijas usar, recomendamos codificarla y documentarla para que todos los miembros del equipo puedan utilizarla de manera consistente en todos los proyectos.

Nota

Si planeas usar variables globales de Jitterbit Script en un script de JavaScript, es importante usar guiones bajos en lugar de puntos:

  • $example_arr_names
  • $example_sfdc_success_message

Environments

Jitterbit permite metodologías del ciclo de vida del desarrollo de software a través del uso de entornos. Puedes configurar tanto entornos de producción como no producción.

Por ejemplo, supongamos que se configuran un entorno de Desarrollo y un entorno de Producción en la Consola de Administración y ambos están asociados con el mismo grupo de agentes. Supongamos que un proyecto se desarrolla primero en el entorno de Desarrollo.

Integration Studio tiene una función de transferencia que copiará ese proyecto al entorno de Producción, después de lo cual las credenciales del endpoint se cambian a las credenciales del endpoint de Producción utilizando variables de proyecto. También se cambian otros endpoints de origen y destino. Después de la transferencia inicial, cualquier transferencia adicional del mismo proyecto de Desarrollo a Producción excluye la migración de los valores de las variables del proyecto a menos que sean nuevas variables de proyecto.

Testing

Jitterbit permite un desarrollo de integración rápido y pruebas unitarias al hacer visible los datos de integración reales durante el tiempo de diseño. La ventaja obvia es permitir un proceso de desarrollo iterativo al mostrar los datos antes y después de las transformaciones de campo, en lugar de construir toda la operación, ejecutarla e inspeccionar la salida. Los datos se hacen visibles utilizando la función de vista previa en una transformación.

Después de que los datos de origen de muestra sean importados o generados, la transformación mostrará la salida de cualquier mapeo y scripts incrustados.

Solución de problemas

Un concepto clave para una arquitectura de integración saludable es reconocer que surgirán preguntas por parte del negocio sobre la precisión del trabajo de integración, particularmente cuando aparezcan discrepancias en los datos del punto final. La integración puede o no ser la culpable. Es responsabilidad del proyecto de integración proporcionar un alto grado de transparencia para ayudar a resolver preguntas sobre la precisión de los datos.

Por ejemplo, si los datos en un punto final de destino parecen ser incorrectos, entonces típicamente se llama al soporte de integración para proporcionar detalles sobre cualquier acción de integración, como tiempos, fuentes, lógica de transformación, mensajes de éxito o fracaso, etc. El proceso de solución de problemas se beneficiará al hacer que esa información esté disponible como parte estándar de la arquitectura de integración. En Jitterbit iPaaS, esto se apoya a través de registros y alertas.

Registro

Los registros de operación capturan datos clave por defecto, como los tiempos de ejecución de la operación y mensajes de éxito, fracaso o cancelación. Si hay fallos y el punto final devuelve información de fallo, entonces el registro capturará esa información.

Con respecto a los fallos, la respuesta se utiliza para determinar el estado. Por ejemplo, si se recibe un código de estado HTTP 400 o más en una respuesta, esto se considera un fallo. Si la solicitud tiene un estado de 200 pero la respuesta contiene errores de datos, esto se trata como un éxito.

Al desarrollar un proyecto de integración, utiliza la función WriteToOperationLog en los mapeos y scripts para capturar datos clave y pasos en el proceso. Esto típicamente es tan simple como: WriteToOperationLog("El id es: "+sourcefieldid).

Si se desea capturar toda la salida de una transformación, esto se puede hacer construyendo una operación que lea la fuente, realice la transformación y escriba la salida en un Variable o un Almacenamiento Temporal en lugar del punto final de destino. Un script posterior a la operación puede leer la salida y registrarla. Luego se puede realizar la "verdadera" operación.

Los registros se pueden ver en la pantalla de registro de operaciones del Integration Studio o en la página de Operaciones en tiempo de ejecución de la Consola de Administración. La página de Operaciones en tiempo de ejecución de la Consola de Administración puede ser accedida por el personal de soporte sin necesidad de navegar al proyecto.

Los datos en los registros son buscables. Para filtrar solo los registros que necesitas, puedes usar la sintaxis de búsqueda message=%\<tu texto>% tanto en los registros de operaciones del Integration Studio como en los de la Consola de Administración.

Frecuentemente, las API tienen un mensaje de respuesta informativo de éxito o no éxito. Si el registro de depuración está habilitado para la API, el cuerpo de la solicitud se capturará en los registros de API (que son distintos de los registros de operaciones).

Los registros de operaciones, incluidos los mensajes de registro detallados de agentes en la nube y agentes privados, se retienen durante 30 días por Harmony.

Alertas

Frecuentemente, los resultados de la integración no solo necesitan ser registrados, sino que también deben ser escalados. Las notificaciones por correo electrónico se pueden adjuntar fácilmente a operaciones y caminos de éxito/fallo o ser llamadas desde scripts. Alternativamente, puedes usar el conector de Correo electrónico para configurar una actividad de enviar correo electrónico como el objetivo de una operación.

Para información adicional, consulta Configurar alertas, registros y manejo de errores.

Recursos adicionales

Estas secciones y páginas en la documentación proporcionan prácticas recomendadas adicionales.

Charlas técnicas

Las charlas técnicas de Jitterbit son presentaciones en video que cubren áreas de interés para usuarios de todos los niveles:

Tech Talk Duration Release Date
API proxy 39:53 2019.01.09
APIs 49:22 2018.08.07
Integration Studio 43:53 2019.05.14
Mejores prácticas para la orquestación de proyectos complejos 50:46 2018.10.16
Constructor de conectores 50:19 2019.07.16
Entornos 1:04:22 2018.04.04
Almacenamiento y gestión de credenciales externas 46:58 2020.10.09
Mejores prácticas para el manejo de errores 27:22 2018.03.13
Mejores prácticas de Jitterbit 1:04:38 2020.03.16
Mejores prácticas de registro 1:03:02 2019.02.12
Administrador del Portal de API Abiertas 57:21 2019.11.05
Mejores prácticas para fuentes de paso y variables globales 42:44 2018.12.05
Mejores prácticas para agentes privados 42:43 2018.07.05
Plantillas de procesos 43:27 2020.07.08
Mejores prácticas para la organización de proyectos 1:08:39 2018.06.08

Documentación

La documentación de Jitterbit incluye las mejores prácticas junto con nuestras páginas sobre el uso de los productos de Jitterbit:

Seguridad

Metodología de proyectos de integración

  • Metodología de proyectos de integración
    Elementos clave que un Gerente de Proyecto para un proyecto de Integration Studio debe conocer, incluyendo cómo organizar su equipo, recopilar y validar requisitos de manera clara y concisa, y aprovechar las fortalezas de Jitterbit iPaaS para entregar un proyecto de integración exitoso.

Cómo hacer

Registro

Agentes