Saltar al contenido

Mejores prácticas para Jitterbit Design Studio

Introducción

Este documento tiene como objetivo servir como una guía para usar Harmony con Design Studio, la aplicación de diseño de proyectos de Jitterbit basada en escritorio. Para mejores prácticas utilizando Integration Studio, la versión web de la aplicación de diseño de proyectos de Jitterbit, consulte mejores prácticas de Harmony.

Este documento no pretende ser exhaustivo ni cubrir todos los escenarios de integración. Más bien, busca proporcionar orientación para escenarios de integración comunes y recomendar las mejores opciones al utilizar las muchas herramientas disponibles para un usuario de Jitterbit.

Esta página se lee mejor después de que tenga familiaridad con Jitterbit: ha revisado la página de Introducción, completado los cursos de Jitterbit University, y quizás haya completado un proyecto de integración por su cuenta. En ese momento, conocerá los conceptos y términos básicos utilizados en Jitterbit, y entenderá lo que Jitterbit significa por proyectos, operaciones, fuentes, destinos, scripting y despliegue.

Este documento es un resumen de las características disponibles a través de Harmony 9.9. A partir de Primavera de 2019, el Integration Studio basado en la web está disponible para usar en lugar de la aplicación de escritorio Design Studio para el diseño de proyectos.

Consulte la sección de Recursos adicionales a continuación para enlaces a videos y otros documentos que amplían las mejores prácticas con Jitterbit.

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 surjan preguntas o problemas técnicos, puede obtener asistencia experta del soporte de Jitterbit. La página de soporte de Jitterbit describe instrucciones especiales para situaciones de producción en las que es necesario escalar problemas sensibles al tiempo.

También 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 para Desarrolladores de Jitterbit) contienen más de 3,600 URL únicas de material técnico.

Actualizaciones del producto Jitterbit

Las actualizaciones de Harmony se lanzan con frecuencia (consulte el Calendario de lanzamientos). Incluso una versión 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 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 del agente 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 los lanzamientos, particularmente aquellos que incluyen actualizaciones de características.

Organización y diseño del proyecto

Reutilización

Reutilización del proyecto

Un escenario típico para reutilizar un proyecto implica el desarrollo de un proyecto "estándar" con el uso extensivo de variables globales y—especialmente—variables del proyecto. Los elementos configurables—como credenciales de punto final, mapeos de campos opcionales, direcciones de correo electrónico, nombres de archivos—pueden ser expuestos como variables del proyecto. El proyecto "estándar" se despliega en múltiples entornos y, utilizando la Consola de Administración, se completan las variables del proyecto para cada entorno.

Reutilización de origen/destino

Aunque las fuentes y destinos de archivos se utilizan frecuentemente en las operaciones, no es necesario construir un nuevo par de origen/destino para cada operación. Dado que las fuentes y destinos de archivos aceptan variables globales para la ruta y los nombres de archivos, se pueden construir fuentes y destinos para operaciones similares una vez y ser controlados a través de variables globales. Por ejemplo, supongamos que se crean objetos "Fuente" y "Destino", y en el campo del nombre de archivo está [filename]. La variable $filename se puede establecer en cualquier lugar antes de que se escriba el destino y se utilizará.

Esto se aplica a fuentes y destinos de base de datos, File Share, FTP Site, Local File y HTTP.

Reutilización de scripts

Los scripts independientes que realizan una función específica, como realizar una búsqueda en la base de datos o proporcionar un resultado a partir de una serie de argumentos, pueden ser candidatos para 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 es una función que se utiliza en toda la integración, entonces se puede construir un script independiente (separado de una operación). Usando la función ArgumentList() o variables globales simples, 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.

Nota

Si almacenas tus proyectos en un recurso compartido de archivos, los cambios que se realicen en un proyecto que son únicamente de la interfaz de usuario (por ejemplo, reorganizas objetos en una vista) no se preservan cuando vuelves a abrir el proyecto.

Como resultado, Jitterbit no recomienda almacenar proyectos en un recurso compartido porque:

  • Los cambios en la interfaz de usuario (disposición de objetos) no se conservan al guardar un archivo
  • El rendimiento se ve afectado: la carga y el guardado de un proyecto pueden ser lentos debido a la falta de almacenamiento en caché
  • Otros usuarios en la red pueden sobrescribir los cambios que se están realizando en un proyecto debido a la falta de bloqueos de archivos

Organizar las operaciones en un proyecto

Design Studio proporciona carpetas de operaciones y ordena las operaciones alfabéticamente al reabrir un proyecto. Al usar un esquema de numeración al nombrar operaciones y carpetas, el flujo de integración es más claro y es más fácil solucionar problemas.

Ejemplo: supongamos que hay dos flujos de integración; uno para Cliente Maestro y un segundo para Artículo Maestro, cada uno con dos operaciones. Se pueden crear dos carpetas, "Cliente Maestro" y "Artículo Maestro," en Design Studio. En la primera carpeta, las operaciones podrían llamarse "CM001 Obtener Cliente" y "CM002 Actualizar Cliente". En la segunda carpeta, las operaciones podrían llamarse "IM001 Obtener Artículos" e "IM002 Actualizar Artículos":

attachment

El registro de operaciones puede mostrar fácilmente los pasos en la cadena de integración y si se omiten pasos. Al hacer clic derecho en una carpeta en Design Studio, la lista de operaciones muestra solo aquellas operaciones de una carpeta. Una estructura de organización y nomenclatura consistente facilita que alguien nuevo en un proyecto comprenda rápidamente el flujo básico de operaciones.

Gestionar condiciones de carrera al usar operaciones asíncronas

Al usar la función RunOperation() en su modo asíncrono, las operaciones se ejecutan sin devolver el control al llamador. El uso de operaciones asíncronas puede llevar a condiciones de carrera.

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

Credenciales del endpoint

Utiliza un ID de sistema con permisos de administración como las credenciales del endpoint, en lugar de un ID a nivel de usuario. Los IDs de usuario suelen expirar o deben ser desactivados cuando el usuario deja la empresa.

Al usar variables de proyecto (cuyos valores pueden ser ocultos) para la gestión de credenciales, el Administrador de Jitterbit no tiene que ingresar credenciales de producción. Esto puede ser realizado por un usuario a través de la Consola de Administración. Este enfoque puede ser utilizado para credenciales de correo electrónico, si es necesario.

Manejo de API

Se debe utilizar el Administrador de API en lugar de endpoints HTTP. Los endpoints HTTP eran una forma de manejar llamadas entrantes de bajo tráfico y requieren que puertos de red específicos estén abiertos, lo que muchas empresas hoy en día consideran un riesgo de seguridad serio.

El Administrador de API y su puerta de enlace de API están diseñados para un rendimiento de alto volumen, realizan un registro detallado, implementan medidas de seguridad comunes y tienen una interfaz de diseño fácil de usar que es parte de la plataforma Harmony. No es necesario configurar puertos de red para manejar el tráfico entrante.

Se debe utilizar una API del Administrador de API para patrones de integración en tiempo real/impulsados por eventos. Por ejemplo: el Endpoint A tiene la capacidad de llamar a una API, como Salesforce, utilizando mensajes salientes. Una API del Administrador de API puede ser implementada rápidamente y vinculada a una cadena de operaciones.

El enfoque preferido para responder a una llamada es hacerlo lo más rápido posible. Si el diseño de la integración es tal que las operaciones posteriores tardan un tiempo significativo en responder, existe el riesgo de que se agote el tiempo de espera, o el riesgo de que otras llamadas entrantes abrumen la capacidad de respuesta del endpoint objetivo.

Si el endpoint de origen está realizando muchas llamadas por minuto, y la puerta de enlace del endpoint objetivo solo puede manejar un cierto número de conexiones, es posible que el endpoint objetivo no pueda escalar para manejar las solicitudes. En este caso, responder de manera asíncrona puede ser el enfoque preferido. Es decir, la respuesta se realiza de inmediato, y el conjunto de datos del endpoint objetivo se envía a través de una llamada a la API del origen.

Persistiendo datos de integración

Hay muchos escenarios en los que poder almacenar datos "en la nube" puede ser útil. Jitterbit proporciona múltiples métodos: variables de proyecto, funciones de caché en la nube y almacenamiento temporal.

Variables de proyecto

Las variables de proyecto son variables estáticas pre-inicializadas (similares a "constantes" del proyecto) que se pueden editar desde Design Studio o la Consola de Administración.

Un ejemplo del uso de variables de proyecto es para las credenciales de los endpoints. Al usar variables de proyecto, se pueden aplicar diferentes entornos de endpoint (que generalmente tienen diferentes credenciales) a diferentes entornos de Jitterbit y editarlas a través de la Consola de Administración. Esto permite un proceso empresarial donde un usuario con derechos en la Consola de Administración puede cambiar credenciales sin requerir acceso a Design Studio.

Un segundo ejemplo es usar variables de proyecto para mantener indicadores utilizados por la lógica de integración que pueden personalizar el comportamiento de la integración. Si se desarrolla un solo proyecto pero se utiliza para diferentes endpoints, entonces una variable de proyecto booleana (como "Send_PO_number") podría ser verificada por la lógica de transformación para el campo del número de PO. Si el valor de la variable de proyecto es falso, entonces se podría usar el comando UnMap() para "desactivar" ese campo.

Funciones de caché en la nube

Las funciones de caché en la nube (ReadCache() y WriteCache()) son espacios de datos asignables que están disponibles a través de proyectos y 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 Harmony, en lugar de depender de almacenes de datos locales o específicos de agentes, los datos pueden compartirse entre operaciones separadas y a través de proyectos.

Usos adicionales de la caché en la nube incluyen:

  • Los datos pueden compartirse entre operaciones asincrónicas dentro de un proyecto.
  • Los errores que se generan en diferentes operaciones pueden almacenarse en una caché común. Al usar esto para acumular resultados de operaciones, se pueden construir alertas más completas.
  • Los tokens de inicio de sesión pueden compartirse entre operaciones.

Administrar Almacenamiento Temporal

El almacenamiento temporal se utiliza con frecuencia en operaciones de integración. Esto es diferente de los Archivos Locales (fuentes o destinos), que solo se pueden usar en agentes privados. Ten en cuenta estas pautas, especialmente al trabajar para utilizar un entorno en clúster:

  • Haz que tu proyecto sea "a prueba de actualizaciones" y utiliza el almacenamiento temporal de tal manera que pasar de un servidor único a un entorno en clúster no requiera refactorización.

  • El almacenamiento temporal se escribe en el directorio temporal predeterminado del sistema operativo en el agente que está realizando el trabajo. En el caso de un único agente privado, entonces es el directorio temporal predeterminado del host del servidor de ese agente privado. Si estás utilizando más de un agente privado, entonces es el directorio temporal predeterminado del host del servidor para el agente que está realizando el trabajo. Si se utiliza un agente en la nube (que están en clúster), entonces es el directorio temporal predeterminado del host del servidor del agente en la nube particular.

  • Por defecto, el almacenamiento temporal se elimina después de 24 horas por un servicio de limpieza de Jitterbit. En el caso de los agentes en la nube, esto puede ser inmediato.

  • Un enfoque simplista es construir un destino, darle un nombre único y luego usar "Copiar a Nueva Fuente" para crear una fuente utilizando el mismo nombre de archivo. El destino y las fuentes son en realidad independientes y dependen del uso del mismo nombre de archivo para sincronizar lecturas y escrituras.

  • En un entorno de agentes en clúster (agentes privados o en la nube), siempre que las operaciones que utilizan el almacenamiento temporal estén vinculadas (encadenadas) entre sí, entonces todas las lecturas y escrituras del almacenamiento temporal ocurrirán en el mismo host del servidor. Pero, si la cadena de operación A escribe en el almacenamiento temporal "myfile", y la cadena de operación B lee el almacenamiento temporal "myfile", la acción de lectura puede ser inconsistente porque puede no leer el mismo host del servidor que la cadena A.

    Nota

    Las operaciones encadenadas siempre se ejecutarán en el mismo agente que la operación principal, independientemente de la sincronización.

  • Para los destinos, el valor predeterminado es sobrescribir el archivo. Esto se puede cambiar con la opción "Agregar al archivo". Generalmente, esto requiere que después de leer la fuente, el archivo sea eliminado o archivado. Una forma sencilla de hacer esto es elegir "Eliminar archivo" o "Renombrar archivo" en la fuente.

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

  • Un archivo en almacenamiento temporal se puede leer rápidamente construyendo un script con la función ReadFile(), como ReadFile("<TAG>Sources/test</TAG>"). Ten en cuenta que esto funciona de manera confiable solo si hay un único agente privado.

Consulta Variable global versus Almacenamiento temporal para una comparación de estos dos tipos y recomendaciones sobre cuándo es apropiado cada uno.

Scripting

Cuándo usar scripting

Aunque Jitterbit proporciona una capacidad de scripting robusta, el scripting debe usarse solo cuando sea necesario. Si hay una opción entre usar scripting o un método estándar, opta por usar el método estándar. Un "método estándar" es un método proporcionado a través de la interfaz de usuario de Jitterbit Design Studio para llevar a cabo una tarea.

Un ejemplo sería la organización de las ejecuciones de operaciones. La interfaz de usuario de Jitterbit Design Studio te permite crear "cadenas de operaciones" vinculadas por rutas de éxito y fracaso. Alternativamente, es posible construir operaciones independientes y luego enlazarlas utilizando scripting y la función RunOperation(). A menos que haya requisitos técnicos que impulsen este enfoque (como el uso de rutas asincrónicas u opcionales), se prefiere confiar en el método de la interfaz de usuario de Jitterbit para vincular diferentes operaciones.

El scripting es generalmente mejor en dos lugares: dentro del Constructor de Fórmulas en transformaciones y en scripts independientes. Si el mismo código se está utilizando en más de una transformación, considera mover ese código a un script independiente y llamarlo desde cada transformación utilizando RunScript().

Convención de nombres para variables

Jitterbit tiene cuatro tipos de variables:

  • variables locales
  • variables globales
  • variables de proyecto
  • variables de Jitterbit

Las variables locales y globales se crean en los scripts de Jitterbit; las variables de proyecto se definen en el Jitterbit Design Studio; las variables de Jitterbit están predefinidas en el sistema de Jitterbit.

Dado que el alcance de una variable local se limita 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".

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

first.second.third[.fourth]

donde:

  • Primer componente: especificador de org
  • Segundo componente: un tipo, como id, error, fecha, archivo, token, marca de tiempo, zona horaria, bandera, correo electrónico, guid, usuario, externalid, val (para un valor misceláneo), arr (para arreglo), o un tipo de endpoint como sfdc
  • Tercer componente: nombre de la variable
  • Cuarto componente: nombre de sub-variable opcional

Combinando estos componentes y asumiendo que el nombre de tu org es example, los nombres de las variables podrían ser:

  • $example.arr.names
  • $example.sfdc.success.message

Dado que las variables de proyecto son visibles a través de la Consola de Administración, y generalmente se utilizan para configurar el comportamiento de integración, se pueden usar nombres más amigables. Como un nombre de variable de proyecto no puede contener espacios, se pueden usar guiones bajos en su lugar. Por ejemplo: "Start_Date" y "Include_Assemblies".

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

Advertencia

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

  • $example_arr_names
  • $example_sfdc_success_message

Entornos y despliegues

Jitterbit permite metodologías del ciclo de vida del desarrollo de software a través del uso de entornos y opciones de despliegue.

Entornos

En Harmony, la función de entorno se puede utilizar para configurar entornos de producción y no producción.

Por ejemplo, supongamos que se han configurado un entorno "Dev" y un entorno "Prod" en la Consola de Administración y ambos están asignados al grupo de agentes A. El Proyecto 1 se desarrolla bajo el entorno "Dev". Jitterbit proporciona una función de "Migración" que copiará ese proyecto al entorno "Prod", después de lo cual las credenciales de los puntos finales se cambian a las credenciales del punto final "Prod". También se cambian otras fuentes y destinos. Después, cualquier migración de "Dev" a "Prod" excluye puntos finales, fuentes y destinos a menos que sean nuevos.

Opciones de gestión de despliegue

Hay varias opciones para desplegar proyectos.

  • Despliegue Completo: Seleccionar Acciones > Desplegar > Todo toma todo el proyecto y sobrescribe el proyecto en la nube.

  • Copia de Seguridad del Proyecto: Al elegir Acciones > Desplegar > Todo, hay una opción para "También almacenar una copia de seguridad en la Nube." Antes de realizar cambios importantes en un proyecto, selecciona esta opción para tener un punto de restauración guardado en Harmony.

  • Todos los Elementos Nuevos y Modificados: Esta opción está disponible en Acciones > Desplegar > Opciones Avanzadas. Debido a que Design Studio realiza un seguimiento de los elementos "sucios", esto desplegará cambios así como todas las dependencias.

  • Una nueva función es deshabilitar el diálogo de progreso durante un despliegue (ver Preferencias > Desplegar) lo que permite que los despliegues de elementos individuales ocurran en segundo plano.

Advertencias de versión

Al desplegar cambios en un proyecto, si se ha desplegado una versión más nueva de un proyecto, se mostrará una advertencia indicando que existe una versión más nueva y identificando quién la desplegó. El Administrador de Jitterbit tiene la opción de sobrescribir el proyecto. En general, en un entorno de múltiples desarrolladores, se prefiere descargar el proyecto actual de la nube antes de realizar cambios.

Pruebas, solución de problemas y registro

Utilizar funciones de prueba para el desarrollo de integración rAPID

Jitterbit puede habilitar el desarrollo rápido de integraciones 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 y examinar la salida. Esto se realiza principalmente a través de la herramienta de Transformaciones, particularmente utilizando las funciones "Probar Transformación" y "Ejecutar Operación".

Si se conocen los objetos a integrar, un desarrollador experimentado puede desarrollar una integración rápidamente utilizando el Asistente de Transformación y su conjunto de herramientas. Por ejemplo, hacer una conexión a una base de datos y, utilizando el Asistente de Transformación, construir la operación y la transformación. Luego, realizar una "Ejecutar Operación" con la transformación abierta. Los datos se mostrarán en la pantalla de transformación y se podrán recorrer los registros. Esto mostrará instantáneamente los datos exactos que Jitterbit recibirá cuando se ejecute la operación.

Si un campo requiere una transformación, haga doble clic en el campo para abrir el Constructor de Fórmulas y construir el script requerido. Al utilizar la función "Probar" en el Constructor de Fórmulas, la salida utilizará los datos de transformación y mostrará la salida exacta que se generará durante el tiempo de ejecución.

Si la fuente no está disponible, pero los datos de origen están disponibles en un archivo (CSV, XML, JSON), el archivo se puede importar a la herramienta de Transformaciones utilizando las funciones "Cargar Datos de Muestra de Origen" y "Probar la Transformación".

Habilitar la solución de problemas de integración

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 aparecen discrepancias en los datos del punto final. La integración puede o no ser la culpable. Es responsabilidad de la 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 endpoint de destino parecen ser incorrectos, generalmente se solicita el apoyo 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, esto se apoya a través de funciones de registro y alerta.

Registro

El registro de operaciones de Jitterbit capturará datos clave por defecto, como los tiempos de ejecución de operaciones y mensajes de éxito, fracaso o cancelación. Si hay fallos y el endpoint devuelve información de fallo, entonces el registro lo capturará.

Al desarrollar una integración, utiliza la función WriteToOperationLog() en los mapeos y scripts para capturar datos clave y pasos en el proceso. Esto generalmente 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 en un archivo temporal. Un script posterior a la operación puede leer el archivo y escribirlo en el registro de operaciones: WriteToOperationLog(ReadFile(<tempfile>)). Luego se puede realizar la operación "real".

Los registros se pueden ver tanto en Design Studio como en la Consola de Administración. La ventaja de la Consola de Administración es que el personal de soporte puede acceder a ella a través del navegador sin necesidad de un cliente de Design Studio en su escritorio.

Los datos en los registros son buscables, lo que permite el escenario en el que la cadena exacta involucrada en la solución de problemas es un valor conocido y está registrada.

Con frecuencia, las API tienen un mensaje de respuesta de éxito o no éxito que es informativo. Da el paso adicional de capturar esta información en el registro.

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

Con frecuencia, los resultados de la integración no solo necesitan ser registrados, sino que también necesitan ser escalados. Jitterbit proporciona integración por correo electrónico, que se puede adjuntar fácilmente a operaciones y rutas de éxito/fracasos o llamar desde scripts.

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

Recursos adicionales

Estas secciones y páginas en la documentación se relacionan con las mejores prácticas y serán de interés.

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:

Documentación

La documentación de Jitterbit incluye las mejores prácticas en nuestras páginas sobre el uso de Jitterbit:

Seguridad

Patrones de diseño y ejemplos

Crear proyectos

Registro

Administrar proyectos

Agentes privados

Usar APIs