Metodología de proyectos de integración para Jitterbit Integration Studio

Introducción

Enfrentémoslo: los proyectos de integración pueden ser complicados, con muchas posibles trampas. Si la integración es "datos en movimiento", hay momentos en que los datos no están interesados en moverse. Los proyectos de integración dependen en gran medida de los puntos finales y, por lo tanto, pueden tener riesgos que están fuera del control del integrador.

En un mundo ideal, los puntos finales son estables, tienen APIs bien documentadas y respuestas de error claras. Hay expertos en la materia (SMEs) fácilmente disponibles, y hay entornos no productivos disponibles tanto para desarrollo como para pruebas. Además, el proyecto está bien financiado, es una prioridad absoluta para la dirección y hay tiempo adecuado para las pruebas. Si esto suena como tu proyecto, ¡felicitaciones! Para el resto de nosotros, sigamos leyendo.

Enfoque

Cuando sabes que hay un campo lleno de trampas, tienes dos opciones:

1. Moverte con mucho cuidado y deliberación, inspeccionar todo el paisaje hasta el más mínimo detalle y construir solo cuando todo esté claro.

2. Ponerte en marcha lo antes posible, identificar cualquier trampa temprano y celebrar las detonaciones… porque descubrir problemas temprano es muy superior a descubrirlos más tarde.

Bien, entonces la opción 2 es. Abróchate el cinturón, vamos a movernos rápido.

Público objetivo

El público objetivo es un gerente de proyecto (PM) o líder técnico que tiene experiencia general en TI y ahora está liderando un proyecto de integración utilizando Jitterbit iPaaS.

Esto incluye a aquellos con roles como un socio de Jitterbit que realiza trabajos de integración general, un proveedor de aplicaciones que también asume la tarea de construir las integraciones de tu producto a todos los puntos finales del cliente, o un PM del cliente, implementando Jitterbit iPaaS solo o con ayuda de los Servicios Profesionales de Jitterbit.

Enfoque

El enfoque de este documento no es cómo usar Jitterbit técnicamente (consulta la otra documentación para los detalles técnicos) sino que aborda los elementos clave que un PM para un proyecto de integración debe conocer. Esta guía muestra cómo organizar tu equipo, recopilar y validar requisitos de manera clara y concisa, y aprovechar las fortalezas de Jitterbit iPaaS para entregar un proyecto exitoso.

Delimitación

La delimitación es un proceso de dos partes que implica recopilar información, delinear los límites del proyecto y obtener la información básica necesaria para implementar el proyecto:

1. Orden de magnitud aproximado: Estimar un Orden de Magnitud Aproximado (ROM) de alto nivel para el trabajo (se puede omitir para ciertos puntos finales).
2. Alcance del trabajo: Refinar la estimación detallando un Alcance del Trabajo (SOW) para la entrega del proyecto.

Este proceso es sensible al concepto de GIGO — Basura entra, basura sale — así que no lo subestimes. La hoja de cálculo a continuación se utiliza como punto de partida para el proceso de delimitación. La terminología específica utilizada en esta hoja de cálculo se definirá más adelante en las subsecciones de Orden de magnitud aproximado y Alcance del trabajo.

Orden de magnitud aproximado (ROM)

Al entrar en este paso, se presume que ha habido suficiente análisis por parte del cliente para determinar qué interfaces necesitan ser construidas. A un alto nivel, se necesitan interfaces cuando un proceso de negocio cruza los límites de las aplicaciones. Si los procesos de negocio no son firmes, entonces tampoco lo es la integración, y puede ser demasiado pronto para estimar.

El Orden de Magnitud Aproximado (ROM) está diseñado para mantenerse a un alto nivel y facilitar una rápida respuesta para apoyar la planificación y la toma de decisiones del cliente. Las estimaciones de ROM se basan en estos elementos:

• Puntos finales: Este es el "objeto" con el que Jitterbit iPaaS interactuará para leer/escribir datos. Esto puede ser una aplicación con un conjunto de métodos remotos, un sistema basado en archivos como FTP o sistemas de archivos internos, una base de datos o una aplicación web que expone APIs.
• Escenario de integración: Esta es la descripción del movimiento de datos necesario para lograr el objetivo de integración. "Sincronizar cuentas", "Crear órdenes de compra" o "Obtener información de envío" son ejemplos.
  • Objeto: Este puede ser un objeto SFDC (Salesforce) (como cuenta o producto), una tabla de base de datos o un objeto de negocio virtual, como órdenes de compra en un documento EDI.
  • Método: Esto es lo que se está haciendo con los datos, como CRUD (crear, leer, actualizar y eliminar).
  • Nivel de complejidad de transformación: Este puede ser uno de estos niveles:
    • Bajo: Utiliza conectores de puntos finales, un bajo número de transformaciones y una o dos operaciones en el escenario.
    • Medio: Puede o no utilizar conectores de puntos finales, utiliza un número de transformaciones y búsquedas externas, y utiliza varias operaciones por escenario.
    • Alto: Sin conectores de puntos finales, numerosos pasos en el escenario, y se sabe que el punto final es desafiante.

Las heurísticas se utilizan para generar horas. Se emplean fórmulas basadas en el número de escenarios y la complejidad para llegar a una estimación, que puede estar fácilmente desviada hasta en un 15–20%. Piensa en esto como un número de presupuesto que se utilizará al principio del proceso.

La estimación ROM asume que un experto en Jitterbit iPaaS está realizando el trabajo con una ligera gestión de proyectos. También es de extremo a extremo: desde la iniciación hasta el post-lanzamiento. El tiempo para construir una integración no corresponde uno a uno con el tiempo transcurrido. El tiempo real dependerá de los niveles de personal, la estabilidad de los puntos finales del cliente, la disponibilidad de los expertos en la materia del cliente, etc. Errando por el lado de la precaución, asumimos una relación de 3:1 entre la duración del calendario y las horas estimadas.

Alcance del trabajo (SOW)

El Alcance del Trabajo (SOW) está diseñado para proporcionar más detalles con el fin de obtener una imagen más clara del proyecto y para proporcionar un chequeo o recálculo de la estimación ROM. Para ciertos puntos finales (como SAP) o tipos de proyectos (como acuerdos de Hub), puedes omitir el proceso ROM y pasar directamente al paso SOW.

Durante este paso, debes organizar una sesión de alcance para finalizar detalles y responder preguntas abiertas. Los asistentes ideales incluyen usuarios de negocio (y todos los propietarios de procesos) y expertos en la materia de los puntos finales. Incluir a estos últimos es clave, ya que de lo contrario puede ser difícil entrar en los detalles.

Esta es la mejor oportunidad para aclarar el perfil de riesgo del proyecto, así que escucha atentamente y haz preguntas. Cubre estos temas:

• Puntos finales

  • Versiones: Versiones que se utilizarán o encontrarán.

  • En/on-premises: Si es en las instalaciones, asegúrate de cubrir el uso de agentes en la nube versus agentes privados. Una preocupación común es la seguridad de la red, como abrir el firewall para los agentes privados, así que asegura al cliente y a las partes interesadas que esto no es una preocupación de seguridad. Proporciona un enlace al documento técnico de seguridad y arquitectura de Jitterbit y a los requisitos del sistema del host para agentes privados.

  • Soporte: Cómo se soportan los endpoint(s) (internamente/externamente).

  • Etapas del ciclo de vida: En desarrollo/pre-producción, mantenimiento, en proceso de actualizaciones, descontinuación.

• Experiencia en Endpoint

  • Experiencia interna vs. externa: Si se trata de un endpoint complejo, como un ERP o CRM, generalmente hay experiencia interna en el departamento de TI, o un socio de implementación y/o mesa de ayuda. Por supuesto, si se cuenta con experiencia interna, mejor aún.
  • Límites/roles: A veces los clientes no tienen claro el rol del integrador y asumen que la personalización del endpoint la realiza Jitterbit; si surge ese tema, aclara los límites.
  • Disponibilidad y calidad de la documentación: Con la proliferación de servicios en la nube y APIs, algunos proveedores simplemente están listando sus APIs, pero la documentación puede ser escasa. Si esta es tu situación, debes incluir tiempo para descubrimiento, viabilidad y pruebas.

• Escenarios de Integración

  • Método y objetos de endpoint: Define estos para cada escenario. Ejemplos:
    • "Consultar periódicamente nuevos clientes en el Endpoint X para la cuenta en el Endpoint Y de manera por lotes, y actualizar el nuevo número de cuenta al Cliente."
    • "Recibir una solicitud en tiempo real del Endpoint X que contiene información del pedido para enviar al método de creación de pedido del Endpoint Y, responder con el nuevo número de pedido."
    • "Consultar la Tabla de Base de Datos X y actualizar 200,000 valores de saldo de inventario al API de Inventario del Endpoint Y."
  • Posibles bloqueadores: Los escenarios se utilizan para la estimación de tiempo. Espera que el desarrollo de cada escenario (a menos que sea extremadamente simple) encuentre bloqueadores. Estos pueden variar desde técnicos (credenciales incorrectas, endpoint inaccesible, API opaca) hasta procedimentales (la empresa necesita definir un nuevo proceso, se requiere personalización, los expertos en la materia no están disponibles).

• Plazo

  • Fechas importantes: Típicamente un cliente conoce su fecha de lanzamiento, pero hay otras fechas importantes.

• Fechas de Pruebas de Aceptación del Usuario (UAT): ¿Cuándo comienza la UAT? (Esto puede requerir explicación si el cliente no está acostumbrado al desarrollo por fases.)

  • Preparación del endpoint: Si se utilizan nuevos endpoints, ¿cuándo estarán listos los entornos para el desarrollo y prueba de integración?

  • Disponibilidad de SME: ¿Existen restricciones en la disponibilidad de SME?

    Precaución

    Tenga cuidado al intentar acelerar un proyecto de integración. Agregar más desarrolladores no hace que el desarrollo ocurra más rápido a menos que haya escenarios muy claros y separados.

• Recursos

  • Enfoques: Los clientes tienen diferentes enfoques respecto a los recursos del proyecto:

    • Mayormente externalizar: El cliente proporciona un punto de contacto comercial o SME, y maneja requisitos, escalamiento, UAT y coordinación de recursos externos. Todos los demás recursos (principalmente desarrollo) son proporcionados por Jitterbit Professional Services y/o el socio de Jitterbit.

    • Mayormente internalizar: El cliente aprenderá a usar Jitterbit iPaaS y solo quiere acceso a un SME de Jitterbit para orientación y mejores prácticas.

    • Internalizar/externalizar: El cliente desea que Jitterbit Professional Services o el socio de Jitterbit construyan una serie de integraciones y las transfieran gradualmente a los recursos del cliente. Esta parte es difícil de estimar. El enfoque recomendado es estimar todo el trabajo y luego restar un porcentaje de horas.

      Nota

      El cliente puede no darse cuenta de que gastará una gran cantidad de tiempo en el proyecto de todos modos, y que trasladar el desarrollo de externo a interno no tendrá un gran impacto (ya que la mayor parte está limitada a una sola fase), e incluso puede ralentizar el progreso debido a la transferencia de conocimiento (KT).

  • Nivel de participación: Este diagrama ilustra el nivel relativo de participación del gerente de proyecto (PM), los recursos del cliente y los recursos de desarrollo. Tenga en cuenta que los recursos de desarrollo están más involucrados durante la fase de desarrollo, con su participación disminuyendo después. Los recursos del cliente (generalmente usuarios comerciales) están muy involucrados durante la fase de UAT (Pruebas de Aceptación del Usuario), algo que comúnmente se pasa por alto.

    

Personal

Estas pautas generales son para la asignación de recursos con habilidades técnicas y de gestión de proyectos de Jitterbit. Excluyen recursos como expertos en procesos de negocio del cliente y propietarios de puntos finales. Según el tamaño del proyecto, se recomiendan los siguientes niveles de personal:

• Proyectos pequeños: Proyectos con 2 puntos finales y menos de 12 escenarios pueden ser manejados por un solo recurso técnico con habilidades en Jitterbit a tiempo parcial y un gerente de proyecto a tiempo parcial.

• Proyectos medianos: Proyectos con 2-4 puntos finales y 12-20 escenarios pueden tener el mismo nivel de personal que los proyectos pequeños, con un personal más involucrado.

• Proyectos grandes: Proyectos con 5 o más puntos finales y 20 o más escenarios tienen muchas dependencias al determinar el personal.

El rol del gerente de proyecto puede requerir una participación cercana al 100% a lo largo del proyecto si alguna de estas afirmaciones es verdadera:

• El cliente requiere informes de estado detallados (como informes a una oficina de gestión de proyectos).

• Numerosos expertos externos deben configurar los puntos finales del cliente para habilitar la integración.

• Es probable que el cliente tenga dificultades para obtener requisitos de integración detallados.

• El gerente de proyecto es inexperto o está ausente, y el cliente espera que usted gestione todo el proyecto.

¡Ejercite una gestión estricta del alcance y los cambios en estas situaciones! Deje claro al cliente que el éxito del proyecto depende de que el cliente elimine cualquier bloqueo y de que todos los recursos del proyecto cumplan con los plazos.

Al utilizar múltiples recursos de desarrollo, considere lo siguiente:

• Tener más de un desarrollador en un solo proyecto de Jitterbit requiere un alto grado de coordinación (más trabajo para el gerente de proyecto) ya que es fácil implementar cambios y sobrescribir el trabajo de otra persona.

• Esfuércese por asignar a los desarrolladores a diferentes escenarios de integración, o divida el trabajo en diferentes proyectos de Jitterbit.

• Utilice revisiones de diseño y código entre desarrolladores.

• Si es posible, aumente los recursos durante la fase de desarrollo y luego reduzca durante las fases de UAT y puesta en marcha.

Reunión de inicio

El propósito de la reunión de inicio es reunir a los participantes clave del proyecto, típicamente los usuarios comerciales clave, expertos en la materia (SMEs), propietarios de puntos finales y arquitectos de integración. Este tiempo se utiliza para que todos estén en la misma página y para aclarar los roles y responsabilidades. Durante la reunión de inicio, se deben completar las siguientes tareas:

• Fechas clave: Revisar todas las fechas clave (no solo la fecha de lanzamiento).
• Compartir información: Compartir información de contacto y documentos.
• Revisión de escenarios de integración: Revisar los escenarios de integración desde la definición del alcance.
  • Este es un buen momento para confirmar si ha cambiado algo desde la última sesión de definición del alcance.
  • Si es necesario, programar una reunión de revisión detallada del alcance.
• Roles y responsabilidades: Construir integraciones con Jitterbit es muy rápido, pero ten en cuenta que el factor más grande que retrasa un proyecto de integración son las dependencias no técnicas. Este es un buen momento para enfatizar ese punto. Aclara las responsabilidades de cada rol:
  • PM
    • Trabaja con el cliente y el equipo técnico para obtener y organizar los requisitos de integración detallados, incluidos los mapeos a nivel de campo. Los mapeos a nivel de campo son necesarios tanto para los recursos de desarrollo de Jitterbit como para los SMEs de los puntos finales.
    • Organiza la disponibilidad de los SMEs comerciales y de puntos finales para el proyecto y aborda rápidamente los elementos abiertos para la integración, como quién es quién, su nivel de compromiso con el proyecto, calendarios, etc.
    • Comunica al cliente y al equipo técnico el progreso del desarrollo de la integración y los elementos abiertos que deben resolverse.
  • Desarrollador de Jitterbit
    • Logra entender los requisitos para diseñar la arquitectura de integración y trabaja con el cliente en consideraciones de diseño (por lotes/en tiempo real, APIs, gestión de datos maestros, requisitos de seguridad, etc.).
    • Toma los requisitos detallados y utiliza la herramienta para desarrollar los escenarios de operación, siguiendo las mejores prácticas de Jitterbit.
    • Supera rápidamente cualquier bloqueo y toma la iniciativa para resolverlos.
    • Idealmente, el desarrollador de Jitterbit está en comunicación directa con el cliente. Aislar al desarrollador de Jitterbit de los SMEs y clientes es una mala práctica y conduce a fallos en la comunicación y retrasos. Los recursos del proyecto deben ser un equipo y deben comunicarse fluidamente.
  • SME de punto final
    • Proporciona una profunda experiencia sobre las interfaces expuestas.
    • Comprende los requisitos de integración y, si hay problemas potenciales —como necesitar un cambio en un punto final o si un requisito es inviable— alerta proactivamente al equipo.
    • Está altamente disponible para ayudar con las pruebas unitarias. Esto puede incluir proporcionar datos de prueba, ofrecer retroalimentación rápida sobre los resultados de las pruebas de integración e interpretar las respuestas de error.
• Licencias y derechos: Revisar las licencias y derechos de Jitterbit y el proceso para solicitar derechos.
• Arquitectura de Harmony: Considerar estos puntos respecto a la arquitectura de Harmony:
  • Si se utilizan agentes privados, priorizar la instalación de la arquitectura técnica y la conectividad a los puntos finales, principalmente para el desarrollo.
  • Si se trabaja con sistemas locales, hay muchos pasos que pueden tardar en finalizar, como la adquisición de hardware, instalación de agentes privados, conectividad de red, credenciales de usuario de integración y el ciclo de pruebas. Dado que esto puede involucrar a múltiples grupos, comienza esto lo antes posible para el entorno de desarrollo.
  • Espera que las lecciones aprendidas al configurar el entorno de desarrollo aceleren la configuración del entorno no de desarrollo, así que realiza este paso tan pronto como sea razonable.
• Membresías de Harmony: Asegúrate de que los recursos de desarrollo estén añadidos a la organización de Harmony con permisos de Admin (ver organizaciones de Jitterbit).
• APIs del API Manager: Si se utilizan APIs, revisar las dependencias. Verificar la URL predeterminada de la API. Si el cliente comenzó a usar una prueba, es posible que la URL predeterminada aún incluya la palabra "prueba". Escalar a la licencia de Jitterbit para que se elimine antes de construir cualquier API.
• Reuniones futuras: Establecer la cadencia de reuniones futuras.
  • Si la integración es parte de una implementación de punto final, entonces unirse a esas reuniones.
  • De lo contrario, se prefieren reuniones cortas y frecuentes (diarias no son infrecuentes). También se puede configurar una plataforma de mensajería instantánea, como Slack.

Plan de proyecto de integración

Como se mencionó anteriormente, la integración tiene muchas dependencias. Los planes de proyecto tienden a venir en dos tipos:

• Parte de la implementación de un nuevo endpoint, como un ERP.
• Independiente, donde los endpoints son relativamente estables.

En el primer caso, las tareas del proyecto de integración pueden (y necesitarán) entrelazarse con el proyecto general. Por ejemplo, el desarrollo de la integración tendrá que esperar a que se configuren los objetos del endpoint.

En el segundo caso (independiente), se puede establecer un plan de proyecto solo para construir la integración.

Independientemente de si las tareas de integración son parte de otro plan o son independientes, las tareas son las mismas. Aquí hay un ejemplo de un plan de proyecto independiente:

Tenga en cuenta que el plan de proyecto comienza con los bloques de construcción básicos, luego itera a través de cada escenario. La sección de UAT (Pruebas de Aceptación del Usuario) se puede posponer hasta que todos los escenarios hayan alcanzado un punto de preparación.

Recopilación de requisitos y desarrollo

Esta sección comienza cubriendo el enfoque general para la recopilación de requisitos y el desarrollo, y luego se adentra en los detalles de mapeo, desarrollo, gestión del proceso de desarrollo, reutilización y manejo de errores y registros.

Enfoque general

El front-end de desarrollo de bajo código y gráfico de Jitterbit (Integration Studio) se presta a un modelo iterativo. Este enfoque no es en cascada, donde todos los requisitos se documentan antes de que comience el desarrollo. Estos pasos clave describen el modelo iterativo general:

• Comience con los escenarios de datos maestros. Dado que el enfoque es iterar rápidamente a través de un ciclo de definir-construir-probar, necesitamos tener los endpoints poblados con datos maestros antes de trabajar con datos transaccionales.

• Comprenda qué sistemas son SOR (Sistemas de Registro) y cuáles son SOE (Sistemas de Compromiso):

  • SOR (Sistemas de Registro): La fuente autorizada para datos maestros, generalmente un ERP.
  • SOE (Sistemas de Compromiso): El sistema orientado al cliente o vendedor, como un sistema para comprar un producto.

• Comprender los campos de datos clave y cuáles son compartidos (claves externas o foráneas).

  • Típicamente, las claves de datos maestros del SOR se almacenan en el SOE para facilitar las actualizaciones de regreso al SOR. Por ejemplo, si SAP es el SOR y SFDC es el SOE, entonces los números de cliente de SAP se almacenan como IDs externas en SFDC.
  • Dado que las claves compartidas pueden requerir personalización (lo que puede convertirse en un obstáculo de tiempo), es importante manejar esta área desde el principio.

Este diagrama muestra un ejemplo utilizando Salesforce como el SOE (Sistema de Compromiso) y SAP como el SOR (Sistema de Registro), en un flujo de datos maestros unidireccional con una escritura de regreso.

Si se trata de actualizaciones de datos maestros bidireccionales, reconozca que esto puede ser una integración complicada:

• Puede encontrar condiciones de carrera, lógica para excluir actualizaciones del usuario de integración separado de los usuarios de negocio, y claves compartidas mutuas.
• Frecuentemente, las reglas de negocio para los datos maestros no son las mismas en los puntos finales, y ya sea que la capa de integración tenga que acomodarlas, o que los puntos finales necesiten ser personalizados. Esto puede ser un obstáculo, así que trabaje a fondo en los escenarios para estos tipos de integraciones.

Mapeo

El PM debe hacer que el cliente comience a trabajar en los mapeos detallados a nivel de campo. Estos son necesarios tanto para los recursos de desarrollo de Jitterbit como para los SMEs de los puntos finales.

El cliente puede estar acostumbrado a ver los sistemas desde el punto de vista de la interfaz de usuario y puede no ser capaz de producir mapeos basados en el punto de vista de los esquemas. En ese caso, obtenga los esquemas en la hoja de cálculo de mapeo, si es posible. Esto puede requerir la ayuda del SME, documentación en línea, o el uso de Jitterbit iPaaS para conectarse al punto final y extraer los esquemas.

Si el mapeo es sencillo, puede realizar el mapeo "en vivo" utilizando Jitterbit iPaaS para incorporar los esquemas del punto final en una transformación durante una reunión con el cliente.

Esta hoja de cálculo demuestra un ejemplo de mapeos a nivel de campo:

Cuando hay suficiente definición del escenario para comenzar, se debe construir la integración en Jitterbit iPaaS y probar lo antes posible para identificar cualquier obstáculo.

A medida que el cliente trabaja en la hoja de cálculo de mapeo, preste especial atención a qué mapeos serán más difíciles. La transformación es donde se encuentra la esencia del proceso, lo que significa que aquí es donde mapeamos los métodos de integración expuestos entre sistemas. Es importante averiguar qué escenarios serán más difíciles que otros, ya que hay un alto multiplicador de tiempo para esos. Los mapeos fáciles pueden tardar solo minutos, mientras que los mapeos complejos pueden tardar días, así que busque estas situaciones y priorice:

• Búsquedas en sistemas externos: Para algunos sistemas, puede ser necesario buscar valores ejecutando consultas. El peligro aquí es el impacto en el rendimiento: tenga en cuenta que la transformación se ejecuta de manera individual por registro. Si se procesan 200 registros y la transformación está realizando una búsqueda en cada registro, eso son 200 consultas. Esto no es un gran problema si el destino es una base de datos, pero si el destino es una API, eso también puede ser 200 inicios/cierres de sesión. Considere usar un diccionario para consultar los datos en un script de preoperación, realizando así una única consulta.

• Esquemas complejos: La transformación es "basada en iteraciones". Por ejemplo, si los esquemas de origen y destino son planos (como un nombre de cliente y una dirección de casa), entonces la transformación iterará una vez por registro, así:

  

  En el siguiente ejemplo (abajo), tanto los esquemas de origen como de destino son complejos, y la transformación tiene que procesar repetidamente las secciones secundarias. Para complicar aún más las cosas, puede que tenga que procesar las secciones secundarias de manera condicional:

  

Frecuentemente, para avanzar rápidamente en mapeos complejos, es necesario reunir a los expertos en la materia (SMEs) de los puntos finales para definir los requisitos, lo que puede incluso requerir la entrada del negocio y puede llevar a la personalización del punto final, todo lo cual puede retrasar el proyecto en general. Es vital identificar los requisitos de integración complejos lo antes posible y aclarar las dependencias rápidamente para mantener el proyecto en marcha.

Desarrollo

Como se mencionó anteriormente, el trabajo de desarrollo puede comenzar poco después del inicio:

• Conectar los endpoints.
• Identificar e implementar escenarios sencillos, particularmente si son datos maestros.
• Para integraciones complejas, incluso si no están completamente mapeadas, tomar medidas para llevar los métodos de integración expuestos a una transformación.
  • Los esquemas (por lo general) solo se aplican al tratar con bases de datos y servicios web.
  • Al tratar con archivos, pueden tener un formato jerárquico, que debe construirse manualmente en Jitterbit. Esto puede ser laborioso, así que comience con eso temprano.
  • Para endpoints de bases de datos, será más eficiente construir vistas que hacer que el proyecto de integración una tablas. Un procedimiento almacenado puede ser un mejor enfoque que realizar actualizaciones complejas.
  • Al trabajar con conectores de endpoints, use los asistentes de Jitterbit iPaaS y asegúrese de que todos los objetos en alcance estén disponibles. Esta es una buena manera de validar que el usuario de integración tiene todos los permisos necesarios para trabajar.
• El desarrollador debe revisar los esquemas de origen y destino para hacer preguntas de mapeo "inteligentes", como estas:
  • "¿Tenemos todos los campos obligatorios?"
  • "Si pasamos un ID de registro, ¿actualizará automáticamente un registro el endpoint o intentará crearlo?"
  • "¿Cuántos registros se pueden pasar en una llamada?"
  • "Este esquema de IDoc de SAP utiliza abreviaturas en alemán. ¿Alguien Sprechen Sie Deutsch?"
• No pase por alto la revisión del esquema de respuesta (si es un servicio web), particularmente en cómo se manejan los errores. Algunos esquemas indican éxito o fracaso en general, mientras que otros proporcionan códigos que deben evaluarse.

Gestión del proceso de desarrollo

Un buen enfoque para gestionar el proceso de desarrollo es tomar los escenarios capturados durante la definición y rastrear hitos relacionados con cada escenario. Este es un ejemplo de hoja de cálculo utilizada para rastrear hitos clave en un desarrollo de integración:

Trate cada escenario como una mini-iteración de desarrollo, comenzando con las dependencias de datos (como los datos maestros). Luego construya operaciones, construya transformaciones, obtenga algunos datos de prueba, envíe a un endpoint, maneje la respuesta. No busque la perfección. Apunte a mover datos de prueba simples del punto A al punto B y luego pase al siguiente escenario. Luego, itere el desarrollo del escenario de integración, identificando bloqueos hasta que se hayan desarrollado y probado unitariamente tanto el escenario de éxito principal como los escenarios de error.

El primer conjunto de integraciones será el que enfrente más problemas, como conectividad, permisos, campos faltantes, etc. Así que cuanto más rápido lleguemos a este punto y despejemos los bloqueadores, mejor. No estamos buscando la perfección desde el principio.

Comienza con un pequeño conjunto de datos de prueba. Esto puede estar codificado en los scripts o usar una consulta que esté limitada a solo unos pocos registros.

Si hay un bloqueador menor, documentalo, asigna la resolución a la persona adecuada y pasa a otro escenario. Nuevamente, el objetivo es encontrar rápidamente las minas terrestres para que puedan ser despejadas, y esa responsabilidad suele ser del cliente y/o del SME.

Aquí hay un ejemplo de una hoja de cálculo para el seguimiento de problemas:

Reutilización

Como cualquier otra plataforma de desarrollo de software, el desarrollo puede acelerarse si no se reinventa la rueda. Jitterbit iPaaS tiene varias formas de habilitar esto:

• Scripts
  • Se pueden construir funciones personalizadas completas y llamarlas desde muchas operaciones. La regla general es que si tienes que escribir el mismo script dos veces, conviértelo en un script llamable.
• Fuentes y Destinos
  • Pasa variables globales y/o del proyecto en lugar de codificar cosas como rutas de archivos o hosts FTP.
  • Usa una variable global como un espacio de trabajo intermedio en lugar de fuentes y destinos específicos de la operación.
• Operaciones
  • Las operaciones de tarea única se pueden construir una vez y usar muchas veces, particularmente aquellas que manejan el manejo de errores y el registro.
  • Las operaciones en un proyecto pueden ser llamadas desde otro. Ten en cuenta que los registros aparecerán en los proyectos nativos (llamados). Pero dado que el alcance de las variables globales es la cadena de operaciones (que puede ser llamada desde más de un proyecto), es posible obtener los resultados de la operación remota y registrarlo en el proyecto que llama.

Registro y manejo de errores

Un conjunto de requisitos que a menudo se pasa por alto tiene que ver con el registro y el manejo de errores. El cliente puede no tener requisitos específicos, especialmente si este es su primer proyecto de integración, por lo que el cliente necesitará ayuda con las mejores prácticas en esta área. Los puntos clave son los siguientes:

• Jitterbit iPaaS realiza el registro de operaciones de forma predeterminada.
• Es fácil registrar datos adicionales, lo cual es muy útil para la resolución de problemas.
  • Aquí es donde puede darse cuenta el cliente de que sus escenarios de integración requerirán soporte interno.
  • Cuando se identifica un problema en un endpoint, si una posible causa raíz es la integración, entonces un recurso necesitará inspeccionar los registros. Cuanto más claros e informativos sean los registros, más rápido será el proceso de resolución de problemas.
• Hay dos clases amplias de alertas: alertas relacionadas con datos y alertas de fallos técnicos, que pueden o no necesitar ir al mismo grupo. La configuración de fallos técnicos es fácil, pero el registro relacionado con datos es completamente personalizado y es más fácil incluirlo durante el desarrollo de la integración en lugar de agregarlo después.
• Integration Studio puede usar correo electrónico con bastante facilidad, donde el servicio de correo se trata como un endpoint al servicio de correo del cliente, utilizando las notificaciones por correo electrónico de Integration Studio. Si bien esto es generalmente fácil de configurar, este paso no debe dejarse para el final.
• La Consola de Administración de Jitterbit se puede utilizar para configurar notificaciones adicionales relacionadas con la organización.

Para información detallada, consulte la charla técnica sobre las mejores prácticas de manejo de errores y la página de Alertas.

Manejo de reglas de negocio

El gran debate: incluir — o no incluir — reglas de negocio.

Muchos clientes comienzan pensando "no quiero incluir reglas de negocio en el middleware; quiero mantener las cosas simples", ¡pero luego proporcionan los requisitos exactamente opuestos!

La arquitectura ideal del middleware establece que la capa de integración debe ser lo más ligera posible, enfocándose en sus fortalezas: transformación de datos, procesamiento de escenarios y orquestación, conexión de endpoints, y registro y alertas. Agregar reglas de negocio engorrosas solo empañará la perfección de esta arquitectura al dispersar el soporte de reglas de negocio a través de los límites de los endpoints. Es decir, si una regla de negocio cambia, no solo cambia en la aplicación; también cambia en el middleware. Además, debido a que el middleware es confuso, turbio y místico, el mantenimiento de reglas es agotador.

La realidad irrumpe de manera brusca, ya que Jitterbit iPaaS tiene que trabajar con lo que las aplicaciones exponen:

• Los datos se presentan de manera deficiente, y la única forma de procesarlos es aplicar reglas de negocio ("si el valor = a, departamento = ventas, si b, departamento = operaciones, si c, departamento = soporte").
• Los datos de origen están incompletos ("si el país = EE. UU., el año fiscal es calendario, si el país = Reino Unido, el año fiscal es de abril a marzo")
• El escenario de integración está impulsado por datos ("si la orden de trabajo contiene líneas que utilizan un tercero, procesa esa línea como una entrada de cuentas por pagar, de lo contrario actualiza como una orden de servicio")

Sí, todo lo anterior podría ser manejado por el endpoint. Pero esto asume que el cliente tiene los recursos y el tiempo para personalizar el endpoint o cambiar una API. Si todo eso está disponible, entonces, por supuesto, hazlo. Sin embargo, el caso habitual es que los endpoints son más difíciles de cambiar y mantener que el proyecto de integración.

Cuando se deben manejar reglas de negocio, las mejores prácticas son las siguientes:

• Externalizar donde sea posible. Por ejemplo, tener datos en una tabla donde puedan ser mantenidos por un usuario.
• Usar variables de proyecto. Estas se exponen en la Consola de Administración de Jitterbit junto con documentación específica. El caso de uso principal es para credenciales de endpoint específicas del entorno, pero también se pueden usar para impulsar la lógica de orquestación y las condiciones de consulta.
• Agregar registro detallado personalizado y manejo de errores de datos, para que si y cuando cambien las reglas de negocio, el efecto en la integración sea obvio.

Agentes y entornos

El agente de Jitterbit es el caballo de batalla de la integración. Integration Studio no ejecuta realmente ningún proceso de operación. Todo sucede en un agente de Jitterbit. Una decisión clave temprana es qué tipo de agente utilizar: privado o en la nube (ver agentes de Jitterbit).

Si alguna de estas afirmaciones es verdadera, entonces el proyecto debe ejecutarse en un agente privado:

• Un endpoint está detrás del firewall del cliente. Esto puede ser una aplicación o un recurso compartido de red.
• Se requiere un conector o controlador que no está disponible en los agentes en la nube. Por ejemplo, el controlador de Excel está disponible solo en agentes privados.
• Los requisitos de seguridad del cliente son tales que no se permite que los datos salgan de su firewall.

De lo contrario, los agentes en la nube son una opción. Desde la perspectiva de la línea de tiempo del proyecto, esto es ideal, ya que evita todos los pasos relacionados con que un cliente tenga que adquirir hardware de servidor e instalar el software del agente de Jitterbit. Sin embargo, independientemente de si se utilizan agentes en la nube o privados, aún se deben configurar miembros y entornos.

Dependiendo del nivel de licencia, un cliente tendrá dos o más licencias de agente privado. Además, el cliente tendrá derecho a un número de entornos, que generalmente se configuran siguiendo las categorías estándar del ciclo de vida del desarrollo de software (desarrollo, calidad, preproducción, producción, soporte, etc.). La herramienta de migración de Jitterbit trabaja con entornos para permitir la promoción de proyectos de integración.

Con respecto a los agentes y entornos, tenga en cuenta estos puntos importantes:

• Identificar un entorno como "producción" no confiere nada especial. No se ejecuta más rápido ni es más resistente. Un entorno es prácticamente igual a cualquier otro.

• Un entorno de Harmony se puede utilizar de muchas maneras. Si el cliente está proporcionando integración para terceros, un entorno se puede utilizar como un contenedor para proyectos dedicados de la empresa.

• Un solo agente privado puede ejecutar más de un entorno.

• Una pregunta frecuente es si es necesario cambiar alguna regla de firewall de red. Por lo general, la respuesta es "no", a menos que el cliente esté restringiendo el tráfico HTTP saliente desde servidores y/o puertos. La comunicación de Harmony a agente es completamente saliente desde el agente hacia Harmony.

Un grupo de agentes es una parte obligatoria de la arquitectura de agentes. Aparte de ser el contenedor virtual que alberga a los agentes privados, desempeña otro papel importante. A diferencia de las herramientas de gestión de servidores tradicionales que requieren aplicaciones adicionales como equilibradores de carga, Harmony facilita lograr la resiliencia del servidor a través del equilibrio de carga y la conmutación por error. Simplemente al agregar un agente a un grupo, el agente se convierte automáticamente en parte de un clúster de servidores.

Para ser claros, al ejecutar una operación en un grupo de agentes con múltiples agentes, solo un agente está ejecutando esa operación. La operación no se divide y se ejecuta en todos los agentes del grupo. Agregar agentes a un grupo no hará que las operaciones se ejecuten más rápido (generalmente). La excepción es un diseño que requiere un grupo de agentes para atender APIs de entrada de alto tráfico, en cuyo caso distribuir la carga entre múltiples agentes es una buena idea.

Para comenzar el desarrollo, solo se necesita un agente privado y un entorno. Se pueden agregar agentes adicionales a grupos, y se pueden añadir nuevos entornos a medida que avanza el proyecto (todo dentro de los límites de la licencia, por supuesto).

Si la obtención de incluso un solo agente es problemática, se puede ejecutar un agente privado de Jitterbit en una estación de trabajo. La mejor manera de hacer esto es utilizar el agente de Docker para evitar conflictos en el escritorio.

Procesamiento por lotes y basado en eventos

Para cada escenario de integración, se determina el desencadenador de la operación: procesamiento por lotes (programado) o procesamiento basado en eventos (en tiempo real).

Procesamiento por lotes

El procesamiento por lotes recopila y procesa datos en intervalos programados (cada hora, diariamente, etc.). Para implementar este enfoque, se pueden configurar los siguientes elementos:

• Configuración del horario: Defina cuándo se ejecutan las operaciones utilizando horarios de operación. Para obtener información sobre cómo configurar y desplegar operaciones programadas, consulte Horarios de operación y Desplegar y ejecutar una operación.

  Nota

  Para proyectos transferidos, debe gestionar la activación y desactivación de horarios (ya sea a nivel de operación o a nivel de horario) a través de los entornos.

• Seguimiento de cambios: Implemente lógica de scripting para identificar registros modificados desde la última ejecución. Por ejemplo, puede implementar consultas basadas en marcas de tiempo (utilizando campos como last_modified_date).

  Consejo

  Al consultar registros cambiados, excluya los registros modificados por la cuenta de usuario de integración para evitar actualizaciones circulares.

El procesamiento por lotes es beneficioso cuando los sistemas de origen no admiten desencadenadores en tiempo real, o cuando necesita procesar grandes volúmenes de datos durante períodos de baja actividad.

Para operaciones que procesan grandes volúmenes de datos, considere usar fragmentación para dividir conjuntos de datos en lotes más pequeños. Para obtener información sobre los detalles de configuración, consulte Habilitar fragmentación.

Procesamiento basado en eventos

El procesamiento basado en eventos activa operaciones inmediatamente cuando ocurren eventos en los sistemas de origen. Esto generalmente sucede a través de llamadas a API o webhooks. Este enfoque proporciona los siguientes beneficios:

• Elimina la gestión de horarios y el seguimiento de marcas de tiempo.
• Procesa datos a medida que están disponibles.
• Reduce la complejidad operativa.
• Coloca la responsabilidad del disparador en el sistema de origen.

El procesamiento basado en eventos se puede implementar utilizando uno de estos métodos:

• APIs del Administrador de API: Los sistemas de origen llaman a APIs del Administrador de API cuando ocurren eventos, lo que activa el procesamiento inmediato. Para obtener información sobre cómo implementar y ejecutar operaciones activadas por API, consulte Usar un disparador de API.

• Servicio de escucha: El servicio de escucha se ejecuta en agentes privados y puede activar operaciones cuando ocurren eventos en puntos finales específicos. Este servicio admite ciertos conectores y actividades, y proporciona balanceo de carga entre clústeres de agentes. Para obtener más información sobre cómo implementar operaciones activadas por oyentes, consulte Usar un oyente.

Transferencia de proyecto

Dependiendo del proceso del cliente, el proyecto deberá ser transferido a un entorno de QA antes de UAT, o las pruebas se realizan en un entorno de desarrollo y luego el proyecto se transfiere a un entorno de producción.

• Si es posible, no transfieras al siguiente entorno superior hasta que el proyecto esté casi completo. Una vez que se realice una migración, debes recordar transferirlos a otros entornos.

• Evita hacer cambios en un entorno "superior" para resolver rápidamente un problema, pensando que sincronizarás los entornos más tarde. En su lugar, realiza la corrección en el entorno "inferior" y transfórmala. No hay una forma infalible de identificar diferencias granulares entre proyectos, por lo que es fácil perder el rastro de los cambios.

Pruebas de aceptación del usuario (UAT)

Todos los escenarios están construidos, todas las pruebas unitarias son exitosas y los usuarios están listos para probar la integración. ¡Es hora de dejar que los usuarios interactúen con la integración, y ahora descubrirás cuáles son los requisitos reales!

Esta fase puede ser un proceso fluido o muy intenso. Realmente depende de la calidad de los pasos anteriores. Ten en cuenta estos consejos durante la fase de UAT:

• Prepárate para reaccionar rápidamente a medida que surjan problemas. Si has hecho bien tu trabajo, la mayoría de los problemas estarán relacionados con los datos, no con la parte técnica. Así que asegúrate de que los SMEs del endpoint estén disponibles para clasificar los problemas.

• Siempre que sea posible, haz que el usuario tome la iniciativa en la solución de problemas: reaccionando a alertas, leyendo registros, rastreando la lógica de integración. Idealmente, la persona que hará este trabajo en producción lo hará durante esta fase.

• Lleva un seguimiento cercano de los problemas que surjan durante la UAT y cómo se resuelven. Una situación frecuente es que los problemas afectan los datos del endpoint, y mientras se soluciona el problema de integración, los datos no lo están y se convierten en un problema recurrente con las pruebas.

• Planea reuniones frecuentes con todos los involucrados para resolver cualquier bloqueo.

• A medida que el tiempo lo permita, comienza la documentación.

• Desarrolla tu plan de transición.

• En el entorno de producción, realiza pruebas de conexión y cualquier otra prueba que puedas realizar o que esté permitida.

Post-producción y monitoreo

¡UAT completado! ¡Firma del usuario completada! ¡Es hora de encender este cohete!

En esta etapa, la migración final a producción debería estar completa. Si estás utilizando horarios, ten en cuenta que puedes transferirlos a producción y desactivarlos en la Consola de Gestión de Jitterbit. Luego, puede corresponder al cliente activar los horarios.

Se espera reunirse con el cliente periódicamente para asegurarse de que todo esté yendo bien, anticipando algunas preguntas.

Planifique una reunión de "cierre" para entregar la documentación del proyecto y realizar cualquier transferencia final de conocimiento.