Metodología del Proyecto de Integración de Design Studio

Introducción

Seamos realistas: los proyectos de integración pueden ser difíciles y tener muchos obstáculos potenciales. Si la integración es "datos en movimiento", hay ocasiones en las 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 tener riesgos que están fuera del control del integrador.

En un mundo ideal, los extremos son estables, tienen APIs bien documentadas y respuestas claras a los errores. Hay expertos en la materia disponibles y hay ambientes que no son de producción tanto para el desarrollo como para las pruebas. Además, el proyecto está bien financiado, es una prioridad absoluta para la administración y hay tiempo suficiente para las pruebas. Si este proyecto le parece adecuado, ¡felicitaciones! Para el resto de nosotros, siga leyendo.

Acercarse

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

1. Moviéndote con mucho cuidado y deliberadamente, examinando todo el paisaje hasta el más mínimo detalle y construyendo solo cuando sepas todo.

2. Empezar lo antes posible, identificar las minas terrestres pronto y celebrar las detonaciones... porque descubrir los problemas pronto es mucho mejor que descubrirlos más tarde.

Bien, entonces es la opción número 2. 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 la plataforma de integración de API Harmony.

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

Enfocar

El objetivo de este documento no es cómo utilizar Jitterbit técnicamente (consulte la otra documentación para conocer los detalles técnicos), sino que aborda los elementos clave que debe conocer un gerente de proyecto de Harmony. Esta guía muestra cómo organizar su equipo, recopilar y validar requisitos de forma clara y concisa, y aprovechar las fortalezas de Harmony para entregar un proyecto exitoso.

Alcance

La determinación del alcance es un proceso de dos partes que implica la recopilación de información, la definición de los límites del proyecto y la obtención de la información básica necesaria para desplegar el proyecto:

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: Refina la estimación detallando un Alcance del trabajo (SOW) para la entrega del proyecto.

Este proceso es sensible al concepto de GIGO (basura que entra, basura que sale), así que no lo subestimes. La hoja de cálculo que aparece 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 entrar en este paso, se presupone que el cliente ha realizado suficientes análisis para determinar qué interfaces se deben crear. En un nivel alto, las interfaces son necesarias cuando un proceso empresarial cruza los límites de la aplicación. Si los procesos empresariales no son firmes, tampoco lo es la integración y puede ser demasiado pronto para hacer una estimación.

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

• Extremos: Este es el "objeto" con el que Harmony interactuará para leer/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 utilizan fórmulas basadas en la cantidad de escenarios y la complejidad para llegar a una estimación, que puede tener un margen de error de hasta un 15-20 %. Piense en esto como un número de presupuesto que se debe utilizar al principio del proceso.

La estimación de ROM supone que un experto de Harmony está haciendo el trabajo con una gestión de proyecto ligera. También es de principio a fin: desde el inicio hasta la fase posterior a la puesta en marcha. El tiempo necesario para crear una integración no se corresponde exactamente con el tiempo transcurrido. El tiempo real dependerá de los niveles de personal, la estabilidad de los extremos del cliente, la disponibilidad de los expertos del cliente, etc. Para ser más cautelosos, suponemos 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 brindar más detalles a fin de obtener una imagen más clara del proyecto y proporcionar una verificación o recálculo de la estimación del ROM. Para ciertos extremos (como SAP) o tipos de proyectos (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 comerciales (y todos los propietarios de procesos) y expertos en extremo. Incluir a estos últimos es clave, ya que de lo contrario puede resultar difícil entrar en detalles.

Esta es la mejor oportunidad para aclarar el perfil de riesgo del proyecto, por lo que debe escuchar atentamente y hacer preguntas. Trate estos temas:

• Extremos

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

  • En las instalaciones o fuera de ellas: Si se trata de instalaciones en las instalaciones, asegúrese de cubrir el uso de agentes privados en comparación con los de la nube. Una preocupación común es la seguridad de la red, como abrir el firewall para los agentes privados, así que asegure al cliente y a las partes interesadas que esto no es un problema de seguridad. Proporcione un enlace al documento técnico sobre seguridad y arquitectura de Jitterbit y los Requisitos del sistema host para agentes privados.

  • Soporte: Cómo se soportan los extremo (internamente/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 CRM, normalmente hay una experiencia interna en el departamento de TI, un socio de despliegue o un servicio de asistencia técnica. Por supuesto, si se cuenta con experiencia interna, 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 enumeran sus APIs, pero la documentación puede ser escasa. Si esta es su situación, debe reservar 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 nuevos clientes en el Extremo X en la cuenta del Extremo Y por lote y actualizar el nuevo número de cuenta a Cliente".
    • "Recibir una solicitud en tiempo real desde el Extremo X que contiene información del pedido para enviar al Extremo Y, crear el método de pedido 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 existencias en la API de inventario del Extremo Y".
  • Bloqueadores potenciales: 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 bloqueadores. 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 las UAT? (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 para PYMES: ¿Existen restricciones en la disponibilidad para PYMES?

    Precaución

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

• Recursos

  • Enfoques: Los clientes tienen distintos enfoques respecto de los recursos del proyecto:

    • Principalmente subcontratación: El cliente proporciona un punto de contacto comercial o un experto en la materia, y se encarga de los requisitos, la escalada, la evaluación de aceptación del cliente 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.

    • Mayormente interno: El cliente aprenderá a usar Harmony y solo quiere tener acceso a un experto en Jitterbit para obtener orientación y mejores prácticas.

    • Subcontratación interna/externa: El cliente desea que Jitterbit Professional Services o el socio de Jitterbit creen 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

      Es posible que el cliente no se dé cuenta de que, de todas formas, dedicará una gran cantidad de tiempo al proyecto y que trasladar el desarrollo de un proceso externo a uno interno no tendrá un gran impacto (ya que la mayor parte se limita a una sola fase) e incluso puede ralentizar el progreso debido a la transferencia de conocimientos (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 participan más durante la fase de desarrollo y su participación disminuye después. Los recursos del cliente (normalmente, los usuarios empresariales) participan mucho durante la fase de UAT (prueba de aceptación del usuario), algo que suele pasarse por alto.

    

Dotación de Personal

Estas pautas 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 empresariales del cliente y propietarios de extremo. Según el tamaño del proyecto, se recomiendan estos 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 del 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, se debe aplicar una gestión estricta del alcance y de los cambios. Deje en claro al cliente que el éxito del proyecto depende de que el cliente supere los obstáculos 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 reduzcalos durante las fases de UAT y puesta en marcha.

Reunión de Lanzamiento

El objetivo de la reunión inicial es reunir a los participantes clave del proyecto, generalmente los usuarios comerciales clave, los expertos en la materia, los propietarios de los extremo y los arquitectos de integración. Este tiempo se utiliza para que todos se pongan de acuerdo y aclaren los roles y las responsabilidades. Durante la reunión inicial, se deben completar estas 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 alcance.
  • Este es un buen momento para confirmar si algo ha cambiado desde la última sesión de evaluación.
  • Si es necesario, programe una reunión de revisión detallada del alcance.
• Roles y responsabilidades: La integración con Jitterbit se lleva a cabo con mucha rapidez, pero tenga en cuenta que el factor más importante que retrasa un proyecto de integración son las dependencias no técnicas. Este es un buen momento para enfatizar ese punto. Aclare las responsabilidades de cada rol:
  • Mensaje privado
    • Trabaja con el cliente y el equipo técnico para obtener y organizar requisitos de integración detallados, incluidas las asignaciones a nivel de campo. Las asignaciones a nivel de campo son necesarias tanto para los recursos de desarrollo de Jitterbit como para los expertos en la extremo.
    • Organiza la disponibilidad de los SMEs de negocios y 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 por 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 las consideraciones de diseño (lote/tiempo real, APIs, gestión de datos maestros, requisitos de seguridad, etc.). El desarrollador debe estar familiarizado con Harmony tutoriales de Design Studio documentación.
    • Toma los requisitos detallados y utiliza la herramienta para desarrollar los escenarios de operación, siguiendo las mejores prácticas de Jitterbit.
    • Encuentra rápidamente cualquier bloqueador y toma la iniciativa para resolverlo.
    • Lo ideal es que el desarrollador de Jitterbit esté en comunicación directa con el cliente. Aislar al desarrollador de Jitterbit de los SMEs y los clientes es una mala práctica y conduce a fallas de comunicación y demoras. Los recursos del proyecto deben ser un equipo y deben comunicarse de manera fluida.
  • SME de Extremo
    • Proporciona un profundo conocimiento sobre las interfaces expuestas.
    • Comprende los requisitos de integración y, si hay problemas potenciales (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 ayudar con las pruebas unitarias. Esto puede incluir proporcionar datos de prueba, brindar comentarios rápidos sobre los resultados de las pruebas de integración e interpretar las respuestas a los errores.
• Licencias y derechos: Revise las licencias y derechos de Jitterbit y el proceso para solicitar derechos.
• Arquitectura Harmony: Considere estos puntos con respecto a la arquitectura 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 trabaja con sistemas locales, hay muchos pasos que pueden llevar tiempo, como la adquisición de hardware, la instalación de agentes privados, la conectividad de red, las credenciales de usuario de integración y el ciclo de prueba. Dado que esto puede involucrar a varios grupos, comience 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 que no es de desarrollo, 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 Harmony: Si se utilizan APIs, revise las dependencias. Verifique la URL predeterminada de la API de Jitterbit. Si el cliente comenzó a usar una versión de prueba, es probable que la URL predeterminada aún incluya la palabra "prueba". Escale el problema al departamento de licencias de Jitterbit para que lo eliminen antes de crear cualquier APIs (consulte API Manager de Jitterbit).
• 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 (no es raro que sean diarias). 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 por ejemplo 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 tendrá que 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 que las tareas de integración formen parte de otro plan o sean independientes, las tareas 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 UAT (prueba de aceptación del usuario) se puede posponer hasta que todos los escenarios hayan alcanzado un punto de preparación.

Recopilación y Desarrollo de Requisitos

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

Enfoque General

El frontend de desarrollo gráfico y de código reducido de Harmony (Harmony Studio) se presta a un modelo iterativo. Este enfoque no es una 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 consiste en iterar rápidamente a través de un ciclo de definición-compilación-prueba, necesitamos que los extremos estén llenos de datos maestros antes de trabajar con datos transaccionales.

• Comprender qué sistemas son SOR (sistemas de registro) y cuáles son SOE (sistemas de participación):

  • 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 un sistema para comprar un producto.

• Comprender los campos de datos claves 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 tratarse de 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 adaptarse a ellas 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 hacer que el cliente 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 la extremo.

Es posible que el cliente esté acostumbrado a ver los sistemas desde el punto de vista de la interfaz de usuario y no pueda generar asignaciones basadas en el punto de vista de los esquemas. En ese caso, si es posible, incluya los esquemas en la hoja de cálculo de asignaciones. Esto puede requerir la ayuda del experto en la materia, documentación en línea o el uso de Harmony para conectarse al extremo y extraer los esquemas.

Si el mapeo es sencillo, puede realizarlo "en vivo" utilizando Harmony 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 crear la integración en Harmony y realizar pruebas 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 la teoría se pone en práctica, es decir, aquí es donde mapeamos los métodos de integración expuestos entre sistemas. Es importante descubrir qué escenarios serán más difíciles que otros, ya que existe un gran multiplicador de tiempo para ellos. Los mapeos fáciles pueden llevar solo minutos, mientras que los mapeos complejos pueden llevar días, así que busque estas situaciones y priorice:

• Búsquedas externas del sistema: En algunos sistemas, es posible que deba buscar valores mediante la ejecución de consultas. El peligro aquí es el impacto en el rendimiento: tenga en cuenta que la transformación de Harmony se ejecuta por registro. Si se procesan 200 registros y la transformación realiza una búsqueda en cada registro, se trata de 200 consultas. Esto no es un gran problema si el objetivo es una base de datos, pero si el objetivo es una API, también pueden ser 200 inicios y cierres de sesión. Considere la posibilidad de utilizar un diccionario para consultar los datos en un secuencia de comandos previo a la operación, realizando así una única consultar.

• Esquemas complejos: La transformación Harmony está "basada 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, de la siguiente manera:

  

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

  

Con frecuencia, para avanzar rápidamente en mapeos complejos, los expertos en extremo deben reunirse para definir los requisitos, lo que puede incluso requerir la participación del negocio y puede llevar a la personalización de los extremo, todo lo cual puede retrasar el proyecto general. Es de vital importancia identificar los requisitos de integración complejos lo antes posible y eliminar 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 sencillos, 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 (normalmente) solo se aplican cuando se trata de bases de datos y servicios web.
  • Al trabajar con archivos, estos pueden tener un formato jerárquico, que debe crearse manualmente en Jitterbit. Esto puede resultar laborioso, por lo que conviene empezar con ello cuanto antes.
  • Para los extremos de la base de datos, será más eficiente crear vistas que hacer que Harmony una las tablas. Un procedimiento almacenado puede ser un mejor enfoque que hacer que Harmony realice actualizaciones complejas.
  • Al trabajar con conectores de extremo, utilice los asistentes de Harmony y asegúrese de que todos los objetos en el ámbito estén disponibles. Esta es una buena forma de validar que el usuario de integración tenga todos los permisos que necesita para trabajar.
• 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 pase por alto la revisión del esquema de respuesta (si se trata de un servicio web), en particular en lo que respecta a cómo se gestionan 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 determinación del alcance y hacer un seguimiento de los hitos relacionados con cada escenario. Esta es una hoja de cálculo de ejemplo que se utiliza para hacer un seguimiento de los hitos clave en el desarrollo de una integración:

Trate cada escenario como una mini iteración de desarrollo, comenzando con las dependencias de datos (como los datos maestros). Luego, cree operaciones, cree transformaciones, obtenga algunos datos de prueba, envíelos a un extremo y gestione 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, sacando a la luz los bloqueadores hasta que se hayan desarrollado y probado unitariamente el escenario de éxito principal, así como 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. Esto puede estar codificado en secuencias de comandos o utilizar una consultar que se limite a solo unos pocos registros.

Si hay un obstáculo menor, documéntelo, asigne la solución a la persona adecuada y pase a otro escenario. Una vez más, el objetivo es encontrar rápidamente las minas terrestres para poder eliminarlas, y esa responsabilidad suele recaer en el cliente o en 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 se puede acelerar si no se reinventa la rueda. Harmony tiene varias formas de hacerlo posible:

• Secuencias de Comandos
  • Se pueden crear y llamar funciones personalizadas completas desde muchas operaciones. La regla general es que si tienes que escribir el mismo secuencia de comandos dos veces, haz que sea 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 una sola tarea se pueden crear una vez y usar muchas veces, en particular aquellas 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). Pero como 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 realiza la llamada.

Registro y Gestión de Errores

Un conjunto de requisitos que a menudo se pasan por alto tiene que ver con el registro y el manejo 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 esta área. Los puntos clave son los siguientes:

• Harmony 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 una posible causa raíz es la integración, entonces un recurso deberá inspeccionar los registros de Harmony. Cuanto más claros e informativos sean los registros, más rápido será el proceso de resolución de problemas.
• Existen dos grandes clases de alertas: alertas relacionadas con datos y alertas de fallas técnicas, que pueden o no tener que ir al mismo grupo. Las fallas técnicas son una configuración sencilla, pero el registro relacionado con datos es totalmente personalizado y es más fácil incluirlo durante el desarrollo de la integración en lugar de agregarlo más adelante.
• Harmony Studio puede utilizar el correo con bastante facilidad, donde el servicio de correo se trata como un extremo del servicio de correo del cliente, utilizando un Design Studio destino de correo. Si bien esto generalmente es fácil de configurar, este paso no debe dejarse para el final.
• La Management Console de Harmony se puede utilizar para configurar notificaciones adicionales relacionadas con la organización.

Para obtener información detallada, consulte Configurar alertas, registros y manejo de errores y la Harmony 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 sencilla posible y centrarse en sus puntos fuertes: transformación de datos, procesamiento y orquestación de escenarios, conexión de extremo, y registro y alertas. Añadir reglas de negocio engorrosas solo estropeará la perfección de esta arquitectura al extender el soporte de reglas de negocio a través de los límites de 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, como el middleware es confuso, turbio y místico, el mantenimiento de reglas es una tarea tediosa.

La realidad se entromete bruscamente, pues Harmony 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 ser manejado por el extremo. Pero esto supone que el cliente tiene los recursos y el tiempo para personalizar el extremo o cambiar una API. Si todo eso está disponible, entonces, por supuesto, hágalo. Sin embargo, lo habitual es que los extremos sean más difíciles de cambiar y mantener que el proyecto de integración de Harmony.

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

• Externalizar siempre que sea posible. Por ejemplo, tener los datos en una tabla donde el usuario pueda mantenerlos.
• Utilizar variables de proyecto. Estas se exponen en Harmony Management Console junto con documentación específica. El caso de uso principal es para credenciales de extremo específicas del ambiente, pero también se pueden utilizar para impulsar 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 Harmony es el caballo de batalla de la integración. Harmony Studio en realidad no ejecuta ningún proceso operación. Todo sucede en un agente Harmony. Una decisión inicial clave es qué tipo de agente usar: privado o en la nube (consulte Agentes Jitterbit).

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 los agentes privados.
• Los requisitos de seguridad del cliente, tales como que no se permite que ningún dato esté fuera de su firewall.

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

Dependiendo del nivel de licencia, un cliente tendrá dos o más licencias de agente privado. Además, el cliente tendrá derecho a una serie de ambientes, que normalmente se configuran siguiendo las categorías estándar del ciclo de vida del desarrollo de software (desarrollo, calidad, preparación, producción, soporte, etc.). La herramienta de migración de Jitterbit funciona con ambientes para permitir 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 nada especial. No funciona más rápido ni es más resistente. Un ambiente es prácticamente igual a cualquier otro.

• Un ambiente Harmony se puede utilizar de muchas maneras. Si el cliente proporciona integración para terceros, un ambiente se puede utilizar 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 de Harmony al agente es toda saliente desde el agente a Harmony.

Un grupo de agentes es una parte obligatoria de la arquitectura de agentes. Además de ser el contenedor virtual que contiene los agentes privados, cumple otra rol importante. A diferencia de las herramientas de administración de servidores tradicionales que requieren aplicaciones adicionales, como balanceadores de carga, Harmony facilita la consecución de la resiliencia del servidor mediante el equilibrio de carga y la conmutación por error. Con solo agregar un agente a un grupo, el agente se convierte automáticamente en parte de un clúster de servidores.

Para ser claros, cuando se ejecuta una operación en un grupo de agentes con varios agentes, solo un agente ejecuta esa operación. La operación no se divide ni se ejecuta en todos los agentes del grupo. Agregar agentes a un grupo no hará que las operaciones se ejecuten más rápido (por lo general). La excepción es un diseño que requiere un grupo de agentes para dar servicio a APIs entrantes de alto tráfico, en cuyo caso es una buena idea distribuir la carga entre varios agentes.

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

Si la adquisición de un solo agente resulta problemática, se puede ejecutar un agente privado Jitterbit en una estación de trabajo. La mejor manera de hacerlo es usar el agente 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 gran decisión: ¿Cómo se activará la integración?

Básicamente, hay dos formas: un enfoque lote, como por ejemplo mediante una programación, o 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 procesamiento lote. ¿Por qué?

• Si bien Jitterbit admite una función de programación, la mayoría de los procesos lote requieren un proceso de obtención de datos basado en una "fecha de última modificación", lo que requiere una secuencia de comandos personalizada para recuperar la última vez que se ejecutó la operación, decidir si la operación se ejecutó correctamente y luego actualizar el repositorio de marcas de tiempo. En el proceso, debe lidiar con zonas horarias de extremo potencialmente diferentes, horario de verano y formatos de fecha. No olvide: solo consultar los datos modificados por todos los usuarios excepto por el usuario de integración. Y, al migrar a otros ambientes, debe manejar la activación y desactivación de programaciones siguiendo el plan del proyecto. Ninguno de estos son grandes desafíos, pero claramente se está colocando una carga de responsabilidad de desarrollo y administración sobre la capa de integración.

• Comparar el lote con el procesamiento por eventos: la operación se ejecuta solo cuando la llama el extremo. Sin horarios, sin marcas de tiempo, sin zonas horarias. La responsabilidad está claramente en el extremo.

• El principal mecanismo de procesamiento basado en eventos de Harmony es la plataforma API de Harmony. Si bien el costo de la licencia es mayor, vale la pena.

• Obviamente, si el extremo no admite la llamada a una API, entonces el lote es su única opción. Además, el cliente puede 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 comercial es obtener datos en un destino 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 que eso. ¿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: Espera un momento. Te das cuenta de que estarás sobrecargando el sistema de pedidos, donde la mayor parte del tiempo no hay datos para procesar. Tendrás muchos ciclos desperdiciados y revisar los registros de Harmony será un fastidio. Si tu requisito comercial es realmente mover datos lo antes posible, entonces necesitas usar una API. Además, hay una alojar de otros beneficios...

Y aquí el cliente, envalentonado con esta información, hace lo correcto y aprueba el uso de una API. Pero si no estás lo suficientemente convencido, contacta con nuestro personal de marketing; ellos se encargan de esto.

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 es que la operación se llame directamente y luego se actualice inmediatamente el objetivo.
  • 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, obtiene 10 000. Jitterbit hará su trabajo y pondrá en marcha tantos subprocesos como el servidor pueda manejar y pondrá en cola el resto del tráfico entrante y comenzará a actualizar el objetivo. Esto podría sobrecargar el sistema de destino.
• 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 de los ambientes. Por lo tanto, si se utiliza una API para cada uno de los ambientes de desarrollo, control de calidad y producción, se trata de tres licencias de API, no de una.

Migración

Dependiendo del proceso del cliente, será necesario migrar el proyecto a un ambiente de control de calidad antes de la prueba 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 inmediatamente superior hasta que el proyecto esté casi terminado. Una vez que se realiza la migración, debe recordar migrarla a otros ambientes.

• Evite realizar cambios en un ambiente "superior" para resolver rápidamente un problema, pensando que sincronizará los ambientes más adelante. En lugar de eso, 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)

Se han creado todos los escenarios, todas las pruebas unitarias han resultado exitosas y los usuarios están listos para probar la integración. Es hora de dejar que los usuarios trabajen en la integración y ahora descubrirá cuáles son los requisitos reales.

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

• Esté preparado para reaccionar rápidamente cuando surjan problemas. 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 clasificar los problemas.

• Siempre que sea posible, que el usuario tome la iniciativa en la resolución de problemas: reaccionar ante las alertas, leer los registros, rastrear la lógica de integración. Lo ideal es que la persona que realizará esta tarea en producción lo haga durante esta fase.

• Realice un seguimiento minucioso de los problemas que surgen durante la prueba de aceptación de usuario y cómo se resuelven. Una situación frecuente es que los problemas afecten a los datos de los extremo y, si bien el problema de integración se soluciona, los datos no y se convierten 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 completada! ¡Aprobación del usuario completada! ¡Es hora de encender este cohete!

En esta etapa, la migración final a producción debería estar completa. Si utiliza programaciones, tenga en cuenta que puede migrarlas a producción y desactivarlas en Harmony Management Console. Luego, el cliente puede decidir si activa las programaciones.

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.