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

Introducción

Seamos realistas: los proyectos de integración pueden ser complejos y presentar numerosos obstáculos potenciales. Si la integración implica "datos en movimiento", hay ocasiones en que los datos no están interesados en moverse. Los proyectos de integración dependen en gran medida de los extremos y, por lo tanto, pueden conllevar riesgos que escapan al control del integrador.

En un mundo ideal, los extremos son estables, cuentan con APIs bien documentadas y respuestas claras ante errores. Hay expertos en la materia disponibles y ambientes no productivos tanto para desarrollo como para pruebas. Además, el proyecto cuenta con una buena financiación, es una prioridad absoluta para la gestión y dispone de tiempo suficiente para las pruebas. Si este proyecto le parece adecuado, ¡enhorabuena! Para el resto, siga leyendo.

Acercarse

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

1. Moverse con mucho cuidado y deliberación, inspeccionar todo el terreno hasta el último detalle y construir solo cuando se sepa todo.

2. Ponerse en marcha lo antes posible, identificar las minas con antelación y celebrar las detonaciones... porque descubrir los problemas a tiempo es mucho mejor que descubrirlos después.

Bien, entonces es la segunda opción. Abróchense los cinturones, vamos a movernos rápido.

Audiencia

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

Esto incluye aquellos con roles como un socio de Jitterbit que hace un trabajo de integración general, un proveedor de aplicaciones que también asume la tarea de construir las integraciones desde su producto hasta todos los extremos del cliente, o un PM de cliente, que implementa Jitterbit iPaaS solo o con la ayuda de los Servicios profesionales de Jitterbit.

Enfocar

Este documento no se centra en el uso técnico de Jitterbit (consulte la otra documentación para obtener información técnica), sino que aborda los aspectos clave que un gestor de proyectos de integración debe conocer. Esta guía muestra cómo organizar a su equipo, recopilar y validar requisitos de forma clara y concisa, y aprovechar las ventajas de Jitterbit iPaaS para lograr un proyecto exitoso.

Alcance

La definición del alcance es un proceso de dos partes que implica recopilar información, definir los límites del proyecto y obtener la información básica necesaria para su despliegue:

1. Orden de magnitud aproximado: Estime un orden de magnitud aproximado (ROM) de alto nivel para el trabajo (se puede omitir para ciertos extremos).
2. Alcance del trabajo: Refine la estimación detallando un Alcance del Trabajo (SOW) para la entrega del proyecto.

Este proceso se basa en el concepto GIGO (basura que entra, basura que sale), así que no lo subestime. La hoja de cálculo a continuación se utiliza como punto de partida para el proceso de determinación del alcance. La terminología específica utilizada en esta hoja de cálculo se definirá más adelante en el Orden de magnitud aproximado y Alcance del trabajo subsecciones.

Orden de magnitud aproximada (ROM)

Al comenzar este paso, se presupone que el cliente ha realizado un análisis suficiente para determinar qué interfaces deben construirse. En general, las interfaces son necesarias cuando un proceso de negocio trasciende los límites de la aplicación. Si los procesos de negocio no son firmes, la integración tampoco lo es, y podría ser prematuro estimarlo.

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

• Extremos: Este es el elemento con el que Jitterbit iPaaS interactuará para leer y escribir datos. 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 exponga APIs.
• Escenario de Integración: Esta es la descripción del movimiento de datos necesario para lograr el objetivo de integración. Algunos ejemplos son "Sincronizar Cuentas", "Crear Órdenes de Compra" u "Obtener Información de Envío".
  • Objeto: Puede ser un objeto SFDC (Salesforce) (como una cuenta o un producto), una tabla de base de datos o un objeto comercial virtual, como órdenes de compra en un documento EDI.
  • Método: Esto es lo que se hace 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 extremo, una cantidad baja de transformaciones y una o dos operaciones en el escenario.
    • Medio: Puede o no usar conectores de extremo, utiliza una cantidad de transformaciones y búsquedas externas, y utiliza varias operaciones por escenario.
    • Alto: No hay conectores de extremo, hay numerosos pasos en el escenario y se sabe que el extremo es desafiante.

Se utilizan heurísticas para generar horas. Se emplean fórmulas basadas en el número de escenarios y la complejidad para obtener una estimación, que puede tener un margen de error de hasta un 15-20 %. Considere esto como una cifra presupuestaria que debe utilizarse al principio del proceso.

La estimación de ROM asume que un experto en iPaaS de Jitterbit realiza el trabajo con una gestión de proyecto sencilla. Además, es integral: desde el inicio hasta la puesta en marcha. El tiempo de desarrollo de una integración no se corresponde exactamente con el tiempo transcurrido. El tiempo real dependerá de la dotación de personal, la estabilidad de los extremos del cliente, la disponibilidad de los expertos del cliente, etc. Como medida de 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 y obtener una visión más clara del proyecto, así como para verificar o recálculo de la estimación del ROM. Para ciertos extremos (como SAP) o tipos de proyecto (como acuerdos de Hub), puede omitir el proceso del ROM y pasar directamente al paso del SOW.

Durante este paso, debe organizar una sesión de evaluación para ultimar los detalles y responder preguntas abiertas. Los asistentes ideales incluyen usuarios de negocio (y todos los responsables de los procesos) y expertos en extremo. Incluir a estos últimos es fundamental, ya que de lo contrario puede resultar difícil profundizar en los detalles.

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

• Extremos

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

  • En las instalaciones/fuera de ellas: Si se trata de instalaciones locales, asegúrese de abordar el uso de agentes en la nube frente a agentes privados. Una preocupación frecuente es la seguridad de la red, como la apertura del firewall para agentes privados. Por lo tanto, asegure al cliente y a las partes interesadas que esto no supone un problema de seguridad. Proporcione un enlace al informe técnico sobre seguridad y arquitectura de Jitterbit y los Requisitos del sistema host para agentes privados.

  • Soporte: Cómo se soportan los extremo(interna/externamente).

  • Etapas del ciclo de vida: En desarrollo/preproducción, mantenimiento, en proceso de actualización, finalización.

• Experiencia en Extremo

  • Experiencia interna vs. externa: Si se trata de un extremo complejo, como un ERP o un CRM, suele haber expertos internos en el departamento de TI, un socio de despliegue o un servicio de asistencia. Por supuesto, si se cuenta con expertos internos, mucho mejor.
  • Límites/roles: A veces, los clientes no tienen claro el rol del integrador y suponen que la personalización del extremo la realiza Jitterbit; si surge ese tema, deje claros los límites.
  • Disponibilidad y calidad de la documentación: Con la proliferación de servicios en la nube y APIs, algunos proveedores simplemente listan sus APIs, pero la documentación puede ser escasa. Si este es su caso, debe prever tiempo para el descubrimiento, la viabilidad y las pruebas.

• Escenarios de integración

  • Objetos de método y extremo: Defínalos para cada escenario. Ejemplos:
    • " consultar periódicamente por lotes nuevos clientes en el Extremo X, lote a la cuenta del Extremo Y y actualizar el nuevo número de cuenta a Cliente."
    • "Recibir una solicitud en tiempo real del Extremo X que contiene información del pedido para enviar al Extremo Y crear el método de pedido, responder con el nuevo número de pedido."
    • "Consultar la tabla de base de datos X y actualizar 200 000 valores de saldo de existencias en la API de inventario del Extremo Y."
  • Posibles obstáculos: Los escenarios se utilizan para la estimación del tiempo. Es de esperar que el desarrollo de cada escenario (a menos que sea extremadamente simple) encuentre obstáculos. Estos pueden ir desde técnicos (credenciales incorrectas, extremo inaccesible, API opaca) hasta procedimentales (la empresa necesita definir un nuevo proceso, se requiere personalización, los expertos no están disponibles).

• Periodo de tiempo

  • Fechas importantes: Normalmente el cliente conoce su fecha de entrada en funcionamiento, pero hay otras fechas importantes.

• Fechas de las pruebas de aceptación del usuario (UAT): ¿Cuándo comienzan? (Esto puede requerir una explicación si el cliente no está acostumbrado al desarrollo por fases).

  • Preparación de Extremo: Si se utilizan nuevos extremos, ¿cuándo estarán listos los ambientes para el desarrollo y las pruebas de integración?

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

    Precaución

    Tenga cuidado al intentar acelerar un proyecto de integración. Añadir más desarrolladores no acelera el desarrollo a menos que existan escenarios claros y diferenciados.

• Recursos

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

    • Principalmente externalizado: El cliente proporciona un punto de contacto comercial o experto en la materia, que gestiona los requisitos, el escalamiento, la UAT y la coordinación de recursos externos. Todos los demás recursos (principalmente de desarrollo) son proporcionados por los Servicios Profesionales de Jitterbit o el socio de Jitterbit.

    • Principalmente internalizado: El cliente aprenderá a usar Jitterbit iPaaS y solo desea acceder a un experto en Jitterbit para obtener orientación y mejores prácticas.

    • Internalizado/externalizado: El cliente desea que los Servicios Profesionales de Jitterbit o el Socio de Jitterbit creen varias integraciones y las deleguen 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 podría no percatarse de que, de todas formas, dedicará mucho tiempo al proyecto y de que trasladar el desarrollo de externo a interno no tendrá un gran impacto (ya que la mayor parte se limita a una sola fase), e incluso podría ralentizar el progreso debido a la transferencia de conocimiento (CT).

  • Nivel de participación: Este diagrama ilustra el nivel relativo de participación del director de proyecto (GP), los recursos del cliente y los recursos de desarrollo. Cabe destacar que los recursos de desarrollo participan más activamente durante la fase de desarrollo, y su participación disminuye posteriormente. Los recursos del cliente (generalmente usuarios de negocio) participan activamente durante la fase de UAT (Pruebas de Aceptación del Usuario), algo que a menudo se pasa por alto.

    

Dotación de personal

Estas directrices generales se aplican a la dotación de personal 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 extremo. Según el tamaño del proyecto, se recomiendan los siguientes niveles de dotación de personal:

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

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

• Proyectos grandes: Los proyectos con más de 5 extremos y más de 20 escenarios tienen muchas dependencias a la hora de determinar la dotación de personal.

• El rol de PM puede implicar casi el 100 % de participación a lo largo del proyecto si alguna de estas afirmaciones es verdadera:

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

• Numerosas pymes externas tienen que configurar los extremos del cliente para permitir la integración.

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

• El PM no tiene experiencia o está ausente, y el cliente espera que usted gestione todo el proyecto.

• En estas situaciones, aplique una gestión rigurosa del alcance y los cambios. Deje claro al cliente que el éxito del proyecto depende de que supere cualquier obstáculo y de que todos los recursos del proyecto cumplan con los plazos.

• Al utilizar múltiples recursos de desarrollo, tenga en cuenta 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 PM) ya que es fácil desplegar cambios y sobrescribir el trabajo de otra persona.

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

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

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

Reunión de lanzamiento

El propósito de la reunión inicial es reunir a los participantes clave del proyecto, generalmente los usuarios de negocio clave, los expertos en la materia, los propietarios de extremo y los arquitectos de integración. Este tiempo se aprovecha para que todos se pongan de acuerdo y aclaren las funciones y responsabilidades. Durante la reunión inicial, se deben completar las siguientes tareas:

• Fechas clave: Revise todas las fechas clave (no solo la fecha de entrada en funcionamiento).
• Intercambio de información: Compartir información de contacto y documentos.
• Revisión del escenario de integración: Revise los escenarios de integración desde el punto de vista del alcance.
  • Este es un buen momento para confirmar si algo ha cambiado desde la última sesión de evaluación del alcance.
  • Si es necesario, programe una reunión de revisión detallada del alcance.
• Roles y responsabilidades: Desarrollar la integración con Jitterbit es muy rápido, pero tenga en cuenta que el principal factor que retrasa un proyecto de integración son las dependencias no técnicas. Es un buen momento para enfatizar este punto. Aclare 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, incluyendo las asignaciones a nivel de campo. Estas asignaciones son necesarias tanto para los recursos de desarrollo de Jitterbit como para los expertos en extremo.
    • Organiza la disponibilidad de los SMEs comerciales y de extremo para el proyecto y aborda rápidamente los temas 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 temas abiertos a resolver.
  • Desarrollador de Jitterbit
    • Logra una comprensión de los requisitos para diseñar la arquitectura de integración y trabaja con el cliente en consideraciones de diseño (lote/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.
    • Rápidamente descubre cualquier obstáculo y toma la iniciativa para resolverlo.
    • Idealmente, el desarrollador de Jitterbit se comunica directamente con el cliente. desarrollador de los expertos y clientes es una mala práctica y provoca interrupciones en la comunicación y retrasos. Los recursos del proyecto deben formar un equipo y comunicarse fluidamente.
  • PYME de Extremo
    • Proporciona un profundo conocimiento sobre las interfaces expuestas.
    • Comprende los requisitos de integración y, si hay posibles problemas (como la necesidad de un cambio en un extremo o si un requisito no es viable), alerta de manera proactiva al equipo.
    • Está altamente disponible para asistir con las pruebas unitarias. Esto puede incluir proporcionar datos de prueba, brindar retroalimentación rápida sobre los resultados de las pruebas de integración e interpretar las respuestas a errores.
• Licencias y derechos: Revise las licencias y derechos de Jitterbit y el proceso para solicitar derechos.
• Arquitectura de Harmony: Considere estos puntos con 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 extremos, principalmente para el desarrollo.
  • Si se trabaja con sistemas locales, hay muchos pasos que pueden tardar en completarse, como la adquisición de hardware, la instalación del agente privado, la conectividad de red, las credenciales de usuario de integración y el ciclo de pruebas. Dado que esto puede involucrar a varios grupos, comience con esto lo antes posible para el ambiente de desarrollo.
  • Espere que las lecciones aprendidas en la configuración del ambiente de desarrollo aceleren la configuración del ambiente no desarrollado, así que realice este paso lo antes posible.
• Membresías de Harmony: Asegúrese de que los recursos de desarrollo se agreguen a la organización Harmony con un permiso de administrador (consulte Organizaciones de Jitterbit).
• APIs de API Manager: Si se utilizan APIs, revise las dependencias. Compruebe la URL predeterminada de la API. Si el cliente empezó a usar una versión de prueba, es posible que la URL predeterminada aún incluya la palabra "prueba". Coordine con el departamento de licencias de Jitterbit para que la eliminen antes de crear cualquier APIs.
• Reuniones futuras: Establezca la cadencia de las reuniones futuras.
  • Si la integración es parte de la despliegue de un extremo, únase a esas reuniones.
  • De lo contrario, se prefieren reuniones breves y frecuentes (a diario no es raro). 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 suelen ser de dos tipos:

• Parte de la despliegue de un nuevo extremo, como un ERP.
• Independiente, donde los extremos son relativamente estables.

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

En el segundo caso (autónomo), se puede configurar un plan de proyecto exclusivo para construir la integración.

Independientemente de si las tareas de integración forman parte de otro plan o son independientes, son las mismas. A continuación, se muestra un ejemplo de un plan de proyecto independiente:

Tenga en cuenta que el plan del proyecto comienza con los componentes básicos y luego itera a través de cada escenario. La sección de UAT (Pruebas de Aceptación del Usuario) puede posponerse hasta que todos los escenarios estén listos.

Recopilación y desarrollo de requisitos

Esta sección comienza explicando el enfoque general para la recopilación y el desarrollo de requisitos, y luego profundiza en los detalles del mapeo, el desarrollo, la gestión del proceso de desarrollo, la reutilización, el registro y la gestión de errores.

Enfoque general

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

• Comience con los escenarios de datos maestros. Dado que el enfoque consiste en iterar rápidamente a través de un ciclo de definición-compilación-prueba, necesitamos que los extremos se llenen con datos maestros antes de trabajar con datos transaccionales.

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

  • SOR (Sistemas de registro): La fuente autorizada de datos maestros, generalmente un ERP.
  • SOE (Sistemas de compromiso): El sistema que mira al cliente o al vendedor, como por ejemplo un sistema para comprar un producto.

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

  • Normalmente, las claves de datos maestros del SOR se almacenan en el SOE para facilitar las actualizaciones en el SOR. Por ejemplo, si SAP es el SOR y SFDC es el SOE, los números de cliente de SAP se almacenan como identificadores externos en SFDC.
  • Dado que las claves compartidas pueden requerir personalización (lo que puede convertirse en un obstáculo), es importante abordar esta área desde el principio.

Este diagrama muestra un ejemplo que utiliza Salesforce como SOE (sistema de interacción) y SAP como SOR (sistema de registro), en un flujo de datos maestros unidireccional con reescritura.

Si se trata de actualizaciones de datos maestros bidireccionales, tenga en cuenta que puede ser una integración complicada:

• Puede encontrar condiciones de carrera, lógica para excluir actualizaciones del usuario de integración separadas de los usuarios comerciales y claves compartidas mutuas. Con frecuencia, las reglas de negocio para los datos maestros no son las mismas en los extremos, y la capa de integración debe adaptarlas o los extremos deben personalizarse. Esto puede ser un obstáculo, por lo que conviene analizar los escenarios en detalle para este tipo de integraciones.

Mapeo

El gerente de proyecto debe indicar al cliente que comience a trabajar en las asignaciones detalladas a nivel de campo. Estas son necesarias tanto para los recursos de desarrollo de Jitterbit como para los expertos en extremo.

El cliente podría estar acostumbrado a ver los sistemas desde la perspectiva de la interfaz de usuario y no ser capaz de generar mapeos basados en los esquemas. En ese caso, incorpore los esquemas a la hoja de cálculo de mapeo, si es posible. Esto podría requerir la ayuda del experto en la materia, documentación en línea o el uso de Jitterbit iPaaS para conectarse al extremo y extraer los esquemas.

Si el mapeo es sencillo, puede realizarlo "en vivo" utilizando Jitterbit iPaaS para incorporar los esquemas de extremo en una transformación durante una reunión con el cliente.

Esta hoja de cálculo muestra un ejemplo de asignaciones a nivel de campo:

Cuando haya suficiente definición del escenario para comenzar, intente construir la integración en Jitterbit iPaaS y pruebe lo antes posible para identificar cualquier bloqueador.

A medida que el cliente trabaja con la hoja de cálculo de mapeo, preste mucha atención a qué mapeos serán más difíciles. La transformación es donde se pone en práctica la teoría, es decir, aquí es donde mapeamos los métodos de integración expuestos entre sistemas. Es importante determinar qué escenarios serán más difíciles que otros, ya que existe un alto multiplicador de tiempo para estos. Los mapeos sencillos pueden tomar solo minutos, mientras que los complejos pueden tomar días, así que busque estas situaciones y priorícelas:

• Búsquedas externas del sistema: En algunos sistemas, es posible que necesite buscar valores mediante consultas. El riesgo radica en el impacto en el rendimiento: tenga en cuenta que la transformación se ejecuta por registro. Si se procesan 200 registros y la transformación realiza una búsqueda en cada uno, se generan 200 consultas. Esto no es un gran problema si el destino es una base de datos, pero si el destino es una API, también pueden generarse 200 inicios y cierres de sesión. Considere usar un diccionario para consultar los datos en un secuencia de comandos previo a la operación, realizando así una sola consultar.

• Esquemas complejos: La transformación se basa en iteraciones. Por ejemplo, si los esquemas de origen y destino son planos (como el nombre y la dirección del cliente), la transformación se iterará una vez por registro, como se muestra a continuación:

  

  En el siguiente ejemplo (abajo), tanto el esquema de origen como el de destino son complejos, y la transformación debe procesar repetidamente las secciones secundarias. Para complicar aún más las cosas, podría ser necesario procesar las secciones secundarias condicionalmente:

  

Con frecuencia, para avanzar rápidamente en mapeos complejos, es necesario reunir a los expertos en extremo para definir los requisitos, lo que puede incluso requerir la participación del negocio y llevar a la personalización de extremo, lo que puede retrasar el proyecto en su conjunto. Es fundamental identificar los requisitos de integración complejos lo antes posible y resolver las dependencias rápidamente para que el proyecto siga avanzando.

Desarrollo

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

• Conectar los extremos.
• Identificar e desplegar escenarios fáciles, especialmente si se trata de datos maestros.
• Para integraciones complejas, incluso si no están completamente mapeadas, tome medidas para convertir los métodos de integración expuestos en una transformación.
  • Los esquemas (generalmente) se aplican solo cuando se trata con bases de datos y servicios web.
  • Al trabajar con archivos, estos pueden tener un formato jerárquico, que debe generarse manualmente en Jitterbit. Esto puede ser laborioso, así que comience pronto.
  • Para los extremos de la base de datos, será más eficiente crear vistas que permitir que el proyecto de integración una tablas. Un procedimiento almacenado puede ser una mejor estrategia que realizar actualizaciones complejas.
  • Al trabajar con conectores de extremo, utilice los asistentes de Jitterbit iPaaS y asegúrese de que todos los objetos en el ámbito estén disponibles. Esta es una buena manera de validar que el usuario de integración tenga todos los permisos necesarios para funcionar.
• El desarrollador debe revisar los esquemas de origen y destino para formular preguntas de mapeo "inteligentes", como estas:
  • "¿Tenemos todos los campos obligatorios?"
  • "Si pasamos un ID de registro, ¿el extremo actualizará automáticamente un registro o intentará crearlo?"
  • "¿Cuántos registros se pueden pasar en una llamada?"
  • "Este esquema IDoc de SAP utiliza abreviaturas alemanas. ¿Alguien Sprechen Sie Deutsch?" No olvide revisar el esquema de respuesta (si se trata de un servicio web), especialmente la gestión de errores. Algunos esquemas indican éxito o fracaso 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 consiste en tomar los escenarios capturados durante la definición del alcance y realizar un seguimiento de los hitos relacionados con cada uno. Este es un ejemplo de hoja de cálculo utilizada para realizar un seguimiento de los hitos clave en el desarrollo de una integración:

Considere cada escenario como una mini iteración de desarrollo, comenzando con las dependencias de datos (como los datos maestros). Luego, cree operaciones y transformaciones, obtenga datos de prueba, envíelos a un extremo y gestione la respuesta. No busque la perfección. Intente mover datos de prueba simples del punto A al punto B y luego pase al siguiente escenario. A continuación, itere el desarrollo del escenario de integración, identificando los obstáculos hasta que se hayan desarrollado y probado unitariamente el escenario principal de éxito y los escenarios de error.

El primer conjunto de integraciones será el que presente más problemas, como conectividad, permisos, campos faltantes, etc. Por lo tanto, cuanto más rápido lleguemos a este punto y eliminemos los obstáculos, mejor. No buscamos la perfección de entrada.

Comience con un pequeño conjunto de datos de prueba. Puede codificarlo en secuencias de comandos o usar una consultar limitada a unos pocos registros.

Si hay un obstáculo menor, documéntelo, asigne la solución a la persona adecuada y pase a otro escenario. Nuevamente, el objetivo es encontrar rápidamente las minas terrestres para que puedan eliminarse, y esa responsabilidad suele recaer en el cliente o la PYME.

A continuación se muestra un ejemplo de una hoja de cálculo de seguimiento de problemas:

Reutilizar

Como cualquier otra plataforma de desarrollo de software, el desarrollo puede acelerarse si no se reinventa la rueda. Jitterbit iPaaS ofrece varias maneras de facilitarlo:

• Secuencias de comandos
  • Se pueden crear y llamar funciones personalizadas completas desde varias operaciones. La regla general es que, si tiene que escribir el mismo secuencia de comandos dos veces, conviértalo en un secuencia de comandos invocable.
• Fuente y objetivos
  • Pase variables globales y/o de proyecto en lugar de codificar cosas como rutas de archivos o hosts FTP.
  • Utilice una variable global como espacio de trabajo intermedio en lugar de fuentes y destinos específicos de la operación.
• Operaciones
  • Las operaciones de tarea única se pueden crear una vez y usar muchas veces, en particular las que tratan con el manejo y registro de errores.
  • Las operaciones de un proyecto pueden ser invocadas desde otro. Tenga en cuenta que los registros aparecerán en los proyectos nativos (invocados). Sin embargo, dado que el alcance de las variables globales es la cadena de operación (que puede ser invocada desde más de un proyecto), es posible obtener los resultados de la operación remota y registrarlos en el proyecto que la invoca.

Registro y manejo de errores

Un conjunto de requisitos que a menudo se pasa por alto está relacionado con el registro y la gestión de errores. Es posible que el cliente no tenga requisitos específicos, especialmente si se trata de su primer proyecto de integración, por lo que necesitará ayuda con las mejores prácticas en este ámbito. Los puntos clave son los siguientes:

• Jitterbit iPaaS realiza el registro de operación de manera inmediata.
• Es fácil registrar datos adicionales, lo que resulta muy útil para solucionar problemas.
  • Aquí es donde el cliente puede darse cuenta de que sus escenarios de integración requerirán soporte interno.
  • Cuando se identifica un problema en un extremo, si la integración es una posible causa raíz, será necesario que un recurso inspeccione los registros. Cuanto más claros e informativos sean los registros, más rápido será el proceso de resolución de problemas. Existen dos tipos generales de alertas: alertas relacionadas con datos y alertas de fallos técnicos, que pueden o no estar en el mismo grupo. Los fallos técnicos son fáciles de configurar, pero el registro relacionado con datos es totalmente personalizado y es más fácil incluirlo durante el desarrollo de la integración que añadirlo posteriormente.
• Integration Studio puede usar el correo con bastante facilidad, donde el servicio de correo se trata como un extremo para el servicio de correo del cliente, mediante el uso de Integration Studio notificaciones correo. Si bien esto generalmente es fácil de configurar, este paso no debe dejarse para el final.
• La Management Console Jitterbit se puede utilizar para configurar notificaciones adicionales relacionadas con la organización.

Para obtener información detallada, consulte la charla técnica Mejores prácticas de manejo de errores y las Notificaciones página.

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 presentan requisitos exactamente opuestos!

La arquitectura ideal de middleware establece que la capa de integración debe ser lo más eficiente posible, centrándose en sus fortalezas: transformación de datos, procesamiento y orquestación de escenarios, conexión de extremo, y registro y alertas. Añadir reglas de negocio complejas solo perjudicará la perfección de esta arquitectura al extender el soporte de reglas de negocio entre los extremo. Es decir, si una regla de negocio cambia, no solo cambia en la aplicación, sino también en el middleware. Además, dado que el middleware es confuso, turbio y misterioso, el mantenimiento de las reglas resulta tedioso.

La realidad se entromete bruscamente, ya que Jitterbit iPaaS tiene que trabajar con lo que las aplicaciones exponen:

• Los datos se presentan de forma deficiente y la única forma de procesarlos es aplicar reglas de negocio ("si 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 abril-marzo")
• El escenario de integración está basado en datos ("si la orden de trabajo contiene líneas que utilizan un tercero, procesar esa línea como una entrada de AP, de lo contrario actualizar como una orden de servicio")

Sí, todo lo anterior podría gestionarse mediante el extremo. Sin embargo, esto supone que el cliente dispone de los recursos y el tiempo necesarios para personalizar el extremo o modificar una API. Si todo esto está disponible, sin duda debería hacerse. Sin embargo, lo habitual es que los extremos sean más difíciles de modificar y mantener que el proyecto de integración.

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

Externalizar siempre que sea posible. Por ejemplo, guardar los datos en una tabla donde el usuario pueda mantenerlos. - Usar variables de proyecto. Estas se encuentran en la Management Console de Jitterbit, junto con la documentación específica. El principal caso de uso son las credenciales de extremo específicas del ambiente, pero también pueden utilizarse para controlar la lógica de orquestación y las condiciones de consultar. - Agregue registro personalizado detallado y manejo de errores de datos, de modo que si las reglas comerciales cambian, el efecto en la integración sea obvio.

Agentes y ambientes

El agente Jitterbit es la herramienta fundamental para la integración. Integration Studio no ejecuta ningún proceso operación. Todo se realiza en un agente Jitterbit. Una decisión clave al principio es qué tipo de agente usar: privado o en la nube (consulte Agentes Jitterbit/agent)).

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

Un extremo se encuentra detrás del firewall del cliente. 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 solo está disponible en agentes privados. - Los requisitos de seguridad del cliente, por lo que no se permite que ningún dato salga de su firewall.

De lo contrario, los agentes en la nube son una opción. Desde la perspectiva del cronograma del proyecto, esto es ideal, ya que evita todos los pasos relacionados con la adquisición de hardware de servidor y la instalación del software del agente Jitterbit por parte del cliente. Sin embargo, independientemente de si utiliza agentes en la nube o privados, aún debe configurar miembros y ambientes.

Según el nivel de licencia, un cliente tendrá dos o más licencias de agente privado. Además, tendrá derecho a varios ambientes, que suelen configurarse según las categorías estándar del ciclo de vida del desarrollo de software (desarrollo, calidad, pruebas, producción, soporte, etc.). La herramienta de migración de Jitterbit funciona con los ambientes para facilitar la promoción de proyectos de integración.

Respecto a los agentes y ambientes, tenga en cuenta estos puntos importantes:

Identificar un ambiente como "de producción" no le confiere ninguna ventaja especial. No se ejecuta más rápido ni es más resiliente. Un ambiente es prácticamente igual a cualquier otro.

Un ambiente Harmony puede utilizarse de diversas maneras. Si el cliente proporciona integración para terceros, un ambiente puede utilizarse como contenedor para proyectos específicos de la empresa.

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

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

Un grupo de agentes es un componente esencial de la arquitectura de agentes. Además de ser el contenedor virtual que alberga los agentes privados, desempeña otra rol importante. A diferencia de las herramientas tradicionales de administración de servidores, que requieren aplicaciones adicionales como balanceadores de carga, Harmony facilita la resiliencia del servidor mediante el balanceo de carga y la conmutación por error. Con solo añadir un agente a un grupo, este se integra automáticamente en un clúster de servidores.

Para ser claros, al ejecutar una operación en un grupo de agentes con varios, solo un agente la ejecuta. La operación no se divide ni se ejecuta en todos los agentes del grupo. Añadir agentes a un grupo no suele acelerar las operaciones. La excepción es un diseño que requiere que un grupo de agentes atienda APIs entrantes con alto tráfico; en ese caso, distribuir la carga entre varios agentes es recomendable.

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

Si obtener incluso un solo agente resulta problemático, se puede ejecutar un agente privado de Jitterbit en una estación de trabajo. La mejor manera de hacerlo es usar el agente de Docker para evitar conflictos en el escritorio.

Procesamiento por lotes y basado en eventos (en tiempo real)

Para cada escenario de integración, hay una decisión importante: ¿Cómo se activará la integración?

Básicamente, hay dos formas: un enfoque lote, como por ejemplo mediante una programación, o un enfoque activado por un evento, como por ejemplo mediante una API.

Desde la perspectiva de un proyecto de integración, desplegar el procesamiento basado en eventos requiere mucho menos esfuerzo que el lote. ¿A qué se debe esto?

Aunque Jitterbit admite una función de programación, la mayoría de los procesos lote requieren la obtención de datos según la fecha de última modificación, lo que requiere scripts personalizados para recuperar la última vez que se ejecutó la operación, determinar si se operación correctamente y actualizar el repositorio de marcas de tiempo. Durante el proceso, se trabaja con zonas horarias, horarios de verano y formatos de fecha de los extremo que pueden variar. Recuerde: solo consultar los datos modificados por todos los usuarios, excepto el usuario de integración. Además, al migrar a otros ambientes, debe gestionar la activación y desactivación de las programaciones según el plan del proyecto. Ninguno de estos desafíos supone un gran reto, pero claramente se está imponiendo una carga de responsabilidad de desarrollo y gestión a la capa de integración.

Comparar el lote con el procesamiento por eventos: la operación solo se ejecuta cuando la llama el extremo. Sin programaciones, marcas de tiempo ni zonas horarias. La responsabilidad recae claramente en el extremo.

El principal mecanismo de procesamiento basado en eventos de Jitterbit iPaaS se basa en las APIs de API Manager. Si bien el costo de la licencia es mayor, vale la pena.

Obviamente, si el extremo no admite la llamada a una API, la única opción es el lote. Además, el cliente podría negarse a usar una API si el lote es una opción.

Luego está esa extraña quimera, la opción de "lotes rápidos", donde el requisito empresarial es obtener datos en un objetivo lo más rápido posible, pero el cliente no quiere desplegar una API. La conversación es algo así:

Jitterbit: Para el escenario de pedidos, ¿cuándo desea que aparezcan los pedidos en el ERP?

Cliente: Lo antes posible.

Jitterbit: Entonces queremos tiempo real y usar APIs.

Cliente: No, no quiero hacer eso. ¿No podemos hacer un lote muy rápido?

Jitterbit: ¿Te refieres a comprobar cada 10 minutos si hay nuevos pedidos?

Cliente: No, más rápido. ¿Cuál es el tiempo mínimo para programar una cita?

Jitterbit: Um… un minuto.

Cliente: ¡Genial! ¡Consulta el sistema de pedidos cada minuto! ¡Listo!

Jitterbit: Un momento. Te das cuenta de que estarás sobrecargando el sistema de pedidos, donde la mayoría del tiempo no hay datos que procesar. Tendrás muchos ciclos desperdiciados y revisar los registros de operación será un fastidio. Si tu necesidad empresarial es realmente transferir datos lo antes posible, entonces necesitas usar una API. Además, hay alojar otras ventajas…

Y aquí el cliente, animado con esta información, hace lo correcto y aprueba el uso de una API. Pero si no le convence lo suficiente, contacte con nuestro equipo de marketing; ellos se encargan de todo.

Tenga en cuenta estas consideraciones para utilizar las APIs:

• Asegúrese de comprender los requisitos máximos de procesamiento de API.
  • Entiendes que la API se llama cuando un usuario cambia un registro. ¡Fácil! El diseño permite que la operación se llame directamente y luego actualice el objetivo inmediatamente.
  • Pero lo que el cliente olvidó decirle (y usted olvidó preguntar) es que, cuando hay una actualización masiva de registros, en lugar de obtener un registro cada 10 minutos, se obtienen 10 000. Jitterbit hará su trabajo: generará tantos subprocesos como el servidor pueda gestionar, pondrá en cola el resto del tráfico entrante y comenzará a actualizar el objetivo. Esto podría saturar el sistema objetivo.
• Verifique la salida máxima y considere agregar una cola JMS, una base de datos o incluso un archivo temporal para almacenar los datos de la API entrantes antes de procesarlos en el destino. Las APIs se licencian independientemente del ambiente. Por lo tanto, si se utiliza una API para cada ambiente de desarrollo, control de calidad y producción, se requieren tres licencias de API, no una.

Migración

Dependiendo del proceso del cliente, será necesario migrar el proyecto a un ambiente de control de calidad antes de la UAT, o realizar pruebas en un ambiente de desarrollo y luego migrar el proyecto a un ambiente de producción.

Si es posible, no migre al ambiente superior hasta que el proyecto esté casi terminado. Una vez realizada la migración, recuerde migrar a otros ambientes.

Evite realizar cambios en un ambiente superior para resolver un problema rápidamente, pensando que sincronizará los ambientes más adelante. En su lugar, realice la corrección en el ambiente inferior y migrelo. No existe 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 se involucren en la integración, ¡y ahora descubrirás cuáles son los requisitos reales!

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

Prepárese para reaccionar rápidamente ante cualquier problema. Si ha hecho bien su trabajo, la mayoría de los problemas estarán relacionados con los datos, no con los técnicos. Por lo tanto, asegúrese de que los expertos en extremo estén disponibles para evaluar los problemas.

Siempre que sea posible, permita que el usuario lidere la resolución de problemas: reaccionar ante alertas, leer registros y rastrear la lógica de integración. Idealmente, la persona encargada de esta tarea en producción la realizará durante esta fase.

• Monitorear de cerca los problemas que surgen durante la UAT y cómo se resuelven. Es frecuente que los problemas afecten a los datos de los extremo, y aunque el problema de integración se soluciona, los datos no, convirtiéndose en un problema recurrente durante las pruebas.

• Planificar reuniones frecuentes con todos los interesados para resolver cualquier obstáculo.

• Según el tiempo lo permita, iniciar la documentación.

• Desarrolla tu plan de corte.

• En el ambiente de producción, realice pruebas de conexión y cualquier otra prueba que pueda realizar o que esté permitida.

Postproducción y seguimiento

¡UAT listo! ¡Aprobación del usuario lista! ¡Es hora de encender el cohete!

En esta etapa, debería completarse la migración final a producción. Si utiliza programaciones, tenga en cuenta que puede migrarlas a producción y desactivarlas en la Management Console de Jitterbit. Posteriormente, el cliente podrá activarlas.

Espere reunirse con el cliente periódicamente para asegurarse de que todo vaya bien, anticipando algunas preguntas.

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