Metodología del Proyecto de Integración de Cloud Studio¶

Introducción¶

Seamos realistas: los proyectos de integración pueden ser difíciles, con muchas minas terrestres potenciales. Si la integración son "datos en movimiento", hay momentos en que los datos no están interesados en moverse. Los proyectos de integración dependen en gran medida de los extremos y, por lo tanto, pueden tener riesgos que están fuera del control del integrador.

En el mundo ideal, los extremos son estables, tienen APIs bien documentadas y respuestas de error claras. Hay PYME (expertos en la materia) fácilmente disponibles y ambientes no productivos disponibles tanto para desarrollo como para pruebas. Además, el proyecto está bien financiado, es una prioridad absoluta para la gestión y hay tiempo suficiente para realizar pruebas. Si este suena como tu proyecto, ¡felicidades! Para el resto de nosotros, sigue leyendo.

Acercarse¶

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

1. Muévase con mucho cuidado y deliberación, examine todo el paisaje hasta el más mínimo detalle y construya sólo cuando se sepa todo.

2. Ponerse en marcha lo antes posible, identificar las minas terrestres temprano y celebrar las detonaciones... porque descubrir los problemas temprano es muy superior a descubrirlos más tarde.

Bien, entonces el número 2 es. Abróchate el cinturón, 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 ahora lidera un proyecto de integración utilizando la plataforma de integración API Harmony.

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

Enfocar¶

El objetivo de este documento no es cómo utilizar Jitterbit técnicamente (consulte el otro Success Central documentación para el meollo de la cuestión técnica), sino que aborda los elementos clave que un PM para un proyecto Harmony debe conocer. 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¶

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

1. Orden aproximado de magnitud: Calcule 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 de trabajo (SOW) para ejecutar el proyecto.

Este proceso es sensible al concepto de GIGO - Garbage In, Garbage Out - así que no lo desprecies. La siguiente hoja de cálculo 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 Orden aproximado de magnitud y Alcance del trabajo subsecciones.

Orden Aproximado de Magnitud (rom)¶

Al entrar en este paso, se supone que el cliente ha realizado suficiente análisis para determinar qué interfaces deben construirse. En un nivel alto, las interfaces son necesarias cuando un proceso de negocio cruza los límites de la aplicación. Si los procesos de negocio no son firmes, tampoco lo es la integración, y puede que sea demasiado pronto para hacer estimaciones.

El orden aproximado de magnitud (ROM) está diseñado para mantenerse en un alto nivel 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: Esta es la "cosa" con la 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 necesarios para lograr el objetivo de integración. "Sincronizar cuentas", "Crear órdenes de compra" u "Obtener información de envío" son ejemplos.
  • 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 una orden 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 la 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, usa una serie de transformaciones y búsquedas externas, y usa varias operaciones por escenario.
    • Alta: Sin conectores de extremo, numerosos pasos de 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 fácilmente puede tener un error de hasta un 15-20 %. Piense en esto como una cifra de presupuesto que se 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 para construir una integración no se corresponde uno a uno con el tiempo transcurrido. El tiempo real dependerá de los niveles de personal, la estabilidad de los extremos de los clientes, la disponibilidad de las PYME de los clientes, etc. Pecando por precaución, asumimos una proporción de 3:1 entre la duración del calendario y las horas estimadas.

Alcance del Trabajo (sow)¶

El Alcance del Trabajo (SOW) está diseñado para proporcionar más detalles con el fin de obtener una imagen más clara del proyecto y proporcionar una verificación o un nuevo cálculo de la estimación ROM. Para ciertos extremos (como SAP) o tipos de proyectos (como acuerdos de Hub), puede omitir el proceso de ROM e ir directamente al paso SOW.

Durante este paso, debe organizar una sesión de exploración para ultimar los detalles y responder las preguntas abiertas. Los asistentes ideales incluyen usuarios empresariales (y todos los propietarios de procesos) y PYMES de extremo. Incluir esto último es clave, ya que de lo contrario puede resultar complicado entrar en detalles.

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

• Extremos

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

  • On/off-premise: Si es on-premise, asegúrese de cubrir el uso de la nube frente a los Agentes Privados. Una preocupación común es la seguridad de la red, como abrir el firewall para Agentes Privados, así que garantice al cliente y a las partes interesadas que esto no es un problema de seguridad. Proporcione un enlace al Documento técnico sobre arquitectura y seguridad de Jitterbit y los Requisitos del sistema host para Agentes Privados.

  • Soporte: Cómo se admiten los extremo(interno/externo).

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

• Experiencia en Extremo

  • Experiencia interna versus externa: Si se trata de un extremo complejo, como un ERP o CRM, generalmente existe experiencia interna en el departamento de TI, o un socio de despliegue y/o servicio de asistencia. Por supuesto, si tienes experiencia interna, mucho mejor.
  • Límites/roles: A veces los clientes no tienen claro el rol del integrador y asumen 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 actualice el nuevo número de cuenta al Cliente."
    • "Recibir una solicitud en tiempo real del Extremo X que contiene información del pedido para enviar al Extremo Y crear un método de pedido, responder con un nuevo número de pedido."
    • "Consultar la tabla X de la base de datos y actualizar 200.000 valores de saldo de existencias en la API de inventario del Extremo Y".
  • Posibles bloqueadores: Los escenarios se utilizan para la estimación de tiempo. Espere que el desarrollo de cada escenario (a menos que sea extremadamente simple) encuentre obstáculos. Estos pueden variar desde técnicos (credenciales incorrectas, extremo inaccesible, API opaca) hasta de procedimiento (la empresa necesita definir un nuevo proceso, se requiere personalización, las PYME no están disponibles).

• Periodo de tiempo

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

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

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

  • Disponibilidad de las PYME: ¿Existe alguna limitación en la disponibilidad de las PYME?

    Precaución

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

• Recursos

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

    • Principalmente subcontratado: El cliente proporciona un punto de contacto comercial o PYME y maneja los requisitos, la escalación, la UAT y la coordinación de recursos externos. Todos los demás recursos (principalmente desarrollo) son proporcionados por Jitterbit Professional Services y/o el Jitterbit Partner.

    • Principalmente interno: El cliente aprenderá a utilizar Harmony y solo quiere acceder a una PYME de Jitterbit para obtener orientación y mejores prácticas.

    • Interior/externalizado: El cliente quiere que Jitterbit Professional Services o el Jitterbit Partner 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 todos modos, dedicará una gran cantidad de tiempo al proyecto y que cambiar el desarrollo de externo a interno no tendrá un gran impacto. impacto (ya que la mayor parte del mismo se limita a una sola fase), e incluso puede ralentizar el progreso debido a la transferencia de conocimiento (KT).

  • Nivel de participación: Este diagrama ilustra el nivel relativo de participación del director del 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 posteriormente. Los recursos de los clientes (normalmente usuarios empresariales) están muy involucrados durante la fase UAT (Prueba de aceptación del usuario), algo que comúnmente se pasa por alto.

    

Dotación de Personal¶

Estas pautas generales son para la dotación de personal con habilidades técnicas y de gestión de proyectos de Jitterbit. Excluyen recursos como las PYME de procesos comerciales de clientes y los propietarios de extremo. Según el tamaño del proyecto, se recomiendan estos niveles de personal:

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

• Proyectos medianos: Los proyectos con 2-4 extremos y 12-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 tener una participación cercana al 100% durante el transcurso del proyecto si alguna de estas afirmaciones es cierta:

• El cliente requiere informes de estado detallados (como 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.

¡Ejerza una gestión estricta del alcance y del cambio en estas situaciones! Deje claro al cliente que el éxito del proyecto depende de que el cliente elimine cualquier obstáculo y de que todos los recursos del proyecto cumplan los plazos.

Cuando utilice varios recursos de desarrollo, tenga en cuenta estas consideraciones:

• Tener más de un desarrollador en un único proyecto 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, aumentar los recursos durante la fase de desarrollo y luego reducirlos durante las fases UAT y de puesta en marcha.

Reunión Inicial¶

El propósito de la reunión inicial es reunir a los participantes clave en el proyecto, generalmente los usuarios comerciales clave, las pymes, los propietarios de extremo y los arquitectos de integración. Este tiempo se utiliza para que todos estén en sintonía y aclaren las funciones y responsabilidades. Durante la reunión inicial, se deben completar estas tareas:

• Fechas clave: Revise todas las fechas clave (no solo la fecha de lanzamiento).
• Compartir información: Comparta información de contacto y documentos.
• Revisión de escenarios de integración: Revisar 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 del alcance.
  • Si es necesario, programe una reunión de revisión detallada del alcance.
• Roles y responsabilidades: Construir la integración con Jitterbit es muy rápido, 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:
  • PM
    • Trabaja con el cliente y el equipo técnico para obtener y organizar requisitos de integración detallados, incluidas asignaciones a nivel de campo. Tanto los recursos de desarrollo de Jitterbit como las PYME de extremo necesitan asignaciones a nivel de campo.
    • Organiza la disponibilidad de las PYME empresariales y extremo para el proyecto y aborda con prontitud los elementos abiertos para la integración, como quién es quién, su nivel de compromiso con el proyecto, calendarios, etc.
    • Comunica al cliente y al equipo técnico el progreso del desarrollo de la integración y los elementos abiertos por resolver.
  • Desarrollador 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.).
    • Toma los requisitos detallados y utiliza la herramienta para desarrollar los escenarios de operación, siguiendo las Mejores prácticas de Jitterbit.
    • Descubre rápidamente cualquier obstáculo y toma la iniciativa para resolverlo.
    • Idealmente, el desarrollador de Jitterbit está en comunicación directa con el cliente. Aislar al desarrollador de Jitterbit de las pymes y los clientes es una mala práctica y provoca interrupciones y retrasos en la comunicación. Los recursos del proyecto deben ser un equipo y deben comunicarse con fluidez.
  • Pyme de Extremo
    • Proporciona una experiencia profunda 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 factible, alerta proactivamente al equipo.
    • Está altamente disponible para ayudar con las pruebas unitarias. Esto puede incluir proporcionar datos de prueba, proporcionar comentarios rápidos sobre los resultados de las pruebas de integración e interpretar respuestas de error.
• 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 desarrollo.
  • Si se trabaja con sistemas locales, hay muchos pasos que pueden tardar en finalizar, 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 prueba. Dado que esto puede involucrar a varios grupos, comience lo antes posible para el ambiente de desarrollo.
  • Espere que las lecciones aprendidas al configurar el ambiente de desarrollo aceleren la configuración del ambiente que no es de desarrollo, así que elimine este paso tan pronto como sea razonable.
  • Para obtener más información, consulte Agentes y grupos de Agente, Requisitos del sistema para Agentes Privados, Harmony Ambientes, y Informe técnico sobre arquitectura y seguridad de Jitterbit.
• Membresías de Harmony: Asegúrese de que los recursos de desarrollo se agreguen a la organización de Harmony con un permiso de administrador (consulte Organizaciones 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 utilizar una versión de prueba, es probable que la URL predeterminada todavía incluya la palabra "prueba". Escale a la licencia de Jitterbit para eliminarla antes de crear cualquier APIs (consulte Jitterbit API Manager).
• 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 (diarias no son infrecuentes). También se puede configurar una plataforma de mensajería instantánea, como Slack.

Plan de Proyecto de Integración¶

Como se mencionó anteriormente, la integración tiene muchas dependencias. Los planes de proyecto tienden a 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 ser) intercaladas 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 (independiente), se puede configurar un plan de proyecto solo 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 recorre 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 front-end de desarrollo gráfico y de bajo código de Harmony (Harmony Studio) se presta a un modelo iterativo. Este enfoque es no 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, construcción y prueba, necesitamos tener los extremos poblados con datos maestros antes de trabajar con datos transaccionales.

• Comprender qué sistemas son SOR (Systems of Record) y cuáles son SOE (Systems of Engagement):

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

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

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

Este diagrama muestra un ejemplo utilizando Salesforce como SOE (System of Engagement) y SAP como SOR (System of Record), en un flujo de datos maestros unidireccional con reescritura.

Si se trata de actualizaciones de datos maestros bidireccionales, reconozca 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 tiene que acomodarlas o los extremos deben personalizarse. Esto puede ser un obstáculo, así que analice los escenarios en detalle para este tipo de integraciones.

Cartografía¶

El PM debe hacer que el cliente comience a trabajar en las asignaciones detalladas a nivel de campo. Estos son necesarios tanto para los recursos de desarrollo de Jitterbit como para las PYME de extremo.

El cliente puede estar acostumbrado a mirar los sistemas desde el punto de vista de la interfaz de usuario y es posible que no pueda producir asignaciones basadas en el punto de vista de los esquemas. En ese caso, incluya los esquemas en la hoja de cálculo de mapeo, si es posible. Esto puede requerir la ayuda de SME, documentación en línea o el uso de Harmony para conectarse al extremo y extraer los esquemas.

Si la asignación es sencilla, puede realizarla "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 de escenario para comenzar, intente desarrollar la integración en Harmony y realizar pruebas lo antes posible para identificar cualquier obstáculo.

Mientras el cliente trabaja en 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 el caucho se encuentra con el camino, lo que significa que 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 alto multiplicador de tiempo para ellos. Los mapeos sencillos pueden tardar sólo unos minutos, mientras que los complejos pueden tardar días, así que busque estas situaciones y priorice:

• Búsquedas de sistemas externos: Para algunos sistemas, es posible que necesite 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 procesa 200 registros y la transformación realiza una búsqueda en cada registro, son 200 consultas. Esto no es gran cosa si el objetivo es una base de datos, pero si el objetivo es una API, también pueden ser 200 inicios/cierres de sesión. Considere 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 de Harmony está "basada en iteraciones". Por ejemplo, si los esquemas de origen y de destino son planos (como el nombre de un cliente y la dirección particular), la transformación se repetirá una vez por registro, de esta manera:

  

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

  

Con frecuencia, para avanzar rápidamente en asignaciones complejas, las PYME de extremo deben reunirse para definir los requisitos, lo que puede incluso requerir información empresarial y puede conducir a la personalización de extremo, todo lo cual puede retrasar el proyecto general. Es de vital importancia identificar requisitos de integración complejos lo antes posible y aclarar 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 asignadas, tome medidas para convertir los métodos de integración expuestos en una transformación.
  • Los esquemas (generalmente) se aplican solo cuando se trata de bases de datos y servicios web.
  • Cuando se trata de archivos, estos pueden tener un formato jerárquico, que debe crearse manualmente en Jitterbit. Esto puede ser laborioso, así que comience a hacerlo lo antes posible.
  • Para los extremos de la base de datos, será más eficiente crear vistas que unir tablas de Harmony. Un procedimiento almacenado puede ser un mejor enfoque que hacer que Harmony realice actualizaciones complejas.
  • Cuando trabaje con conectores de extremo, utilice los asistentes de Harmony y asegúrese de que todos los objetos dentro del alcance estén disponibles. Esta es una buena manera de validar que el usuario de la integración tiene todos los permisos que necesita para funcionar.
• El desarrollador debe revisar los esquemas de origen y de destino para poder 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 olvides revisar el esquema de respuesta (si es un servicio web), particularmente en cuanto a cómo se manejan los errores. Algunos esquemas indican éxito o fracaso en general, mientras que otros proporcionan códigos que deben evaluarse.

Gestionar el Proceso de Desarrollo¶

Un buen enfoque para gestionar el proceso de desarrollo es tomar los escenarios capturados durante la determinación del alcance y realizar un seguimiento de los hitos relacionados con cada escenario. Esta es una hoja de cálculo de ejemplo utilizada para realizar un seguimiento de los hitos clave en un desarrollo de integración:

Trate cada escenario como una mini iteración de desarrollo, comenzando con las dependencias de datos (como los datos maestros). Luego cree operaciones, cree transformaciones, obtenga algunos datos de prueba, envíelos a un extremo y maneje la respuesta. No busques la perfección. Intente mover datos de prueba simples del punto A al punto B y luego pase al siguiente escenario. Luego, repita el desarrollo del escenario de integración, sacando a la luz los obstáculos 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án las que tendrán más problemas, como conectividad, permisos, campos faltantes, etc. Así que cuanto más rápido lleguemos a este punto y eliminemos los bloqueadores, mejor. No buscamos la perfección desde el principio.

Comience con un pequeño conjunto de datos de prueba. Esto puede estar codificado en secuencias de comandos o utilizar una consultar limitada a unos pocos registros.

Si hay un obstáculo menor, documentarlo, asignar la resolución a la persona adecuada y pasar a otro escenario. Una vez más, la cuestión es encontrar rápidamente las minas terrestres para poder eliminarlas, y esa responsabilidad suele ser responsabilidad del cliente y/o de 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 permitir esto:

• Secuencias de Comandos
  • Se pueden crear y llamar funciones personalizadas completas desde muchas 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 destinos
  • 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 objetivos específicos de la operación.
• Operaciones
  • Las operaciones de tarea única se pueden crear una vez y usarse muchas veces, en particular las que se ocupan del manejo y registro de errores.
  • Las operaciones de un proyecto se pueden llamar desde otro. Tenga en cuenta que los registros aparecerán en los proyectos nativos (llamados). Pero dado que el alcance de las variables globales es la cadena de operación (que se puede llamar 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 Manejo de Errores¶

Un conjunto de requisitos que con frecuencia se pasa 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 este es su primer proyecto de integración, por lo que necesitará ayuda con las mejores prácticas en esta área. Los puntos clave son estos:

• Harmony realiza la operación de inicio de sesión de forma inmediata.
• Es fácil registrar datos adicionales, lo cual 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 solución de problemas.
• Hay dos clases amplias de alertas: alertas relacionadas con datos y alertas de fallas técnicas, que pueden necesitar o no ir al mismo grupo. La falla técnica es una configuración fácil, pero el registro relacionado con los datos es totalmente personalizado y es más fácil de incluir 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 para el servicio de correo del cliente, utilizando Cloud Studio notificaciones correo. Si bien esto generalmente es fácil de configurar, este paso no debe dejarse para el final.
• La Management Console Harmony se puede utilizar para configurar notificaciones adicionales relacionadas con la organización.

Para obtener información detallada, consulte la Charla técnica sobre prácticas recomendadas para el manejo de errores y Harmony Notificaciones página.

Manejo de Reglas Comerciales¶

El gran debate: incluir (o no incluir) reglas comerciales.

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

La arquitectura de middleware ideal exige que la capa de integración sea lo más sencilla posible, centrándose en sus puntos fuertes: transformación de datos, procesamiento y orquestación de escenarios, conexión de extremo y registro y alertas. Agregar reglas comerciales engorrosas solo arruinará la perfección de esta arquitectura al extender el soporte de reglas comerciales a través de los límites de los extremo. Es decir, si una regla de negocio cambia, no sólo cambia en la aplicación; también cambia en el middleware. Además, como el middleware es confuso, turbio y místico, el mantenimiento de reglas resulta abrumador.

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

• Los datos se presentan mal 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 país = EE. UU., el año fiscal es calendario, si país = Reino Unido, el año fiscal es abril - marzo")
• El escenario de integración se basa en datos ("si la orden de trabajo contiene líneas que utilizan un tercero, procese esa línea como una entrada AP; de lo contrario, actualícela 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 hazlo por todos los medios. Sin embargo, lo habitual es que los extremos sean más difíciles de cambiar y mantener que el proyecto de integración Harmony.

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

• Exteriorizar cuando sea posible. Por ejemplo, tenga datos en una tabla donde un usuario pueda mantenerlos.
• Utilizar variables del proyecto. Estos 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 usar 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 será obvio.

Agentes y Ambientes¶

Harmony Agente 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 de Harmony. Una decisión temprana clave es qué tipo de agente usar: Privado o en la Nube (consulte Agentes Jitterbit).

Si alguno de estos es cierto, entonces el proyecto debe ejecutarse en un Agente Privado:

• Un extremo está 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 Nube. Por ejemplo, el controlador de Excel solo está disponible en Agentes Privados.
• Los requisitos de seguridad del cliente como tal que no se permiten datos fuera de su firewall.

De lo contrario, los Agentes en Nube son una opción. Desde la perspectiva del cronograma del proyecto, esto es ideal, ya que evita todos los pasos relacionados con que un cliente tenga que adquirir hardware de servidor e instalar el software Harmony Agente. Sin embargo, independientemente de si utiliza la nube o Agentes 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 de desarrollo de software (desarrollo, calidad, puesta en escena, producción, soporte, etc.). La herramienta de migración de Jitterbit trabaja con ambientes para permitir la promoción de proyectos de integración.

En cuanto a agentes y ambientes, tenga en cuenta estos puntos importantes:

• Identificar un ambiente como “de producción” no le confiere nada especial. No corre 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, se puede utilizar un ambiente como contenedor para proyectos empresariales dedicados.

• Un único 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 y/o puertos. Toda la comunicación de Harmony a Agente es saliente del Agente a Harmony.

Un Grupo de Agentes es una parte obligatoria de la arquitectura del agente. Además de ser el contenedor virtual que alberga a los Agentes Privados, juega otro rol importante. A diferencia de las herramientas tradicionales de administración de servidores que requieren aplicaciones adicionales, como balanceadores de carga, Harmony facilita lograr la resiliencia del servidor mediante el equilibrio de carga y la conmutación por error. Simplemente agregando un agente a un grupo, el agente automáticamente pasa a formar 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 y se ejecuta entre todos los agentes del grupo. Agregar agentes a un grupo (normalmente) no hará que las operaciones se ejecuten más rápido. 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 distribuir la carga entre varios agentes es una buena idea.

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 resulta problemático conseguir incluso un solo agente, se puede ejecutar un Agente Privado de Jitterbit en una estación de trabajo. La mejor manera de hacerlo es utilizar Docker Agente para evitar conflictos en el escritorio.

Procesamiento Basado en Lotes y Eventos (en Tiempo Real)¶

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

Básicamente, hay dos formas: un enfoque lote, como mediante una programación, o activado por un evento, como 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 por lote. ¿Porqué es eso?

• 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 secuencias de comandos personalizadas 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. A lo largo del camino, tendrá que lidiar con zonas horarias de extremo, horarios de verano y formatos de fecha potencialmente diferentes. No lo olvide: solo consultar los datos modificados por todos los usuarios excepto el usuario de integración. Y, al migrar a otros ambientes, debe encargarse de activar y desactivar los cronogramas siguiendo el plan del proyecto. Ninguno de estos son grandes desafíos, pero claramente se está colocando una carga de responsabilidad de desarrollo y gestión en la capa de integración.

• Comparar lote con 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 utilizar una API si el lote es una opción.

Luego está esa extraña quimera, la opción de "lote rápido", donde el requisito comercial es llevar los datos a un objetivo lo más rápido posible, pero el cliente no quiere desplegar una API. La conversación es algo como esto:

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

Cliente: Lo antes posible.

Jitterbit: Entonces queremos APIs en tiempo real y de uso.

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

Jitterbit: ¿Te refieres a comprobar cada 10 minutos si hay algún pedido nuevo?

Cliente: No, más rápido que eso. ¿Cuál es el tiempo mínimo para un horario?

Jitterbit: Um… un minuto.

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

Jitterbit: Espera. Te das cuenta de que estarás golpeando el sistema de pedidos, donde la mayoría de las veces no hay datos para procesar. Tendrás muchos ciclos desperdiciados y revisar los registros de Harmony será una molestia. Si su requisito comercial es realmente mover datos lo antes posible, entonces necesita utilizar una API. Además, hay alojar otros beneficios...

Y aquí el cliente, envalentonado con esta información, hace lo correcto y aprueba el uso de una API. Pero si no es lo suficientemente convincente, comuníquese con nuestro personal de marketing; tienen esto cubierto.

Tome nota de estas consideraciones para el uso de APIs:

• Asegúrese de comprender los requisitos máximos de procesamiento de API.
  • Comprende que se llama a la API cuando un usuario cambia un registro. ¡Fácil! El diseño es que la operación se llame directamente y luego actualice inmediatamente el objetivo.
  • Pero lo que el cliente olvidó decirte (y tú olvidaste preguntar) es que cuando hay una actualización masiva de registros, en lugar de obtener un registro cada 10 minutos, obtienes 10.000. Jitterbit hará su trabajo y activará tantos subprocesos como el servidor pueda manejar, pondrá en cola el resto del tráfico entrante y comenzará a actualizar el objetivo. Esto podría abrumar al sistema objetivo.
• Verifique la salida máxima y considere agregar una cola JMS, una base de datos o incluso un archivo temporal para contener los datos API entrantes antes de procesarlos en el destino.
• Las APIs tienen licencia independientemente de los ambientes. Entonces, si se utiliza una API para cada uno de los ambientes de desarrollo, control de calidad y producción, son 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 se deberán realizar pruebas en un ambiente de desarrollo y luego el proyecto se migrará a un ambiente de producción.

• Si es posible, no migre al siguiente ambiente superior hasta que el proyecto esté casi completo. Una vez que se produce una 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 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 de vista los cambios.

Prueba de Aceptación del Usuario (uat)¶

Todos los escenarios están creados, todas las pruebas unitarias son exitosas y los usuarios están alineados para probar la integración. Es hora de dejar que los usuarios se suelten a la integración, ¡y ahora descubrirás cuáles son los requisitos reales!

Esta fase puede ser un proceso suave o muy intenso. Realmente depende de la calidad de los pasos anteriores. Ten en cuenta estos consejos durante la fase 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. Así que asegúrese de que las PYME de extremo estén disponibles para clasificar los problemas.

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

• Siga de cerca los problemas que surgen durante la UAT y cómo se resuelven. Una situación frecuente es que los problemas afectan los datos de los extremo y, aunque el problema de integración se soluciona, los datos no y se convierten en un problema recurrente durante las pruebas.

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

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

• Desarrolla tu plan de transición.

• 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 hecho! ¡Cierre de sesión del usuario finalizado! ¡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 puede ser responsabilidad del cliente activar los horarios.

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

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