Metodologia de Projeto de Integração do Design Studio¶

Introdução¶

Sejamos realistas: os projectos de integração podem ser difíceis, com muitas minas terrestres potenciais. Se a integração for “dados em movimento”, há momentos em que os dados não estão interessados em serem movidos. Os projetos de integração são altamente dependentes de endpoints e, portanto, podem apresentar riscos que estão fora do controle do integrador.

No mundo ideal, os endpoints são estáveis, têm APIs bem documentadas e têm respostas de erro claras. Existem PMEs (especialistas no assunto) prontamente disponíveis e ambientes de não produção estão disponíveis para desenvolvimento e teste. Além disso, o projeto é bem financiado, é uma prioridade absoluta para a gestão e há tempo adequado para testes. Se isso soa como o seu projeto, parabéns! Para o resto de nós, continue lendo.

Abordagem¶

Quando você sabe que existe um campo cheio de minas terrestres, você tem duas opções:

1. Mova-se com muito cuidado e deliberação, observe toda a paisagem nos mínimos detalhes e construa somente quando tudo for conhecido.

2. Comece o mais rápido possível, identifique antecipadamente quaisquer minas terrestres e comemore as detonações…porque descobrir problemas cedo é muito superior a descobri-los mais tarde.

Certo, então número 2 é. Aperte o cinto, vamos nos mover rápido.

Público¶

O público-alvo é um gerente de projeto (PM) ou líder técnico com experiência geral em TI e que agora está liderando um projeto de integração usando a plataforma de integração Harmony API.

Isso inclui aqueles com funções como parceiro da Jitterbit fazendo trabalho de integração geral, um fornecedor de aplicativos que também assume a tarefa de construir as integrações do seu produto para todos os endpoints do cliente ou um PM do cliente, implementando o Harmony sozinho ou com a ajuda do Jitterbit Professional Serviços.

Foco¶

O foco deste documento não é como usar o Jitterbit tecnicamente (confira a outra Success Central documentação para os detalhes técnicos), mas em vez disso aborda os itens principais que um PM para um projeto Harmony deve saber. Este guia mostra como organizar sua equipe, reunir e validar requisitos de forma clara e concisa e aproveitar os pontos fortes do Harmony para entregar um projeto de sucesso.

Escopo¶

A definição do escopo é um processo de duas partes que envolve a coleta de informações, delineando os limites do projeto e obtendo as informações básicas necessárias para implementar o projeto:

1. Ordem aproximada de magnitude: Estime uma ordem aproximada de magnitude (ROM) de alto nível para o trabalho (pode ser ignorada para determinados endpoints).
2. Escopo do Trabalho: Refine a estimativa detalhando um Escopo de Trabalho (SOW) para entrega do projeto.

Este processo é sensível ao conceito de GIGO – Garbage In, Garbage Out – então não o estrague. A planilha abaixo é usada como ponto de partida para o processo de definição do escopo. A terminologia específica usada nesta planilha será definida posteriormente na Ordem aproximada de magnitude e Escopo do Trabalho subseções.

Ordem Aproximada de Magnitude (rom)¶

Indo para esta etapa, presume-se que houve análise suficiente por parte do cliente para determinar quais interfaces precisam ser construídas. Em alto nível, as interfaces são necessárias quando um processo de negócios ultrapassa os limites do aplicativo. Se os processos de negócios não forem firmes, a integração também não será, e pode ser muito cedo para fazer estimativas.

A ordem aproximada de magnitude (ROM) foi projetada para permanecer de alto nível e facilitar o retorno rápido para apoiar o planejamento e a tomada de decisões do cliente. As estimativas de ROM baseiam-se nestes elementos:

• Endpoints: Esta é a "coisa" com a qual o Harmony irá interagir para ler/gravar dados de/para. Pode ser um aplicativo com um conjunto de métodos remotos, um sistema baseado em arquivos, como FTP ou sistemas de arquivos internos, um banco de dados ou um aplicativo da Web que expõe APIs.
• Cenário de integração: Esta é a descrição da movimentação de dados necessária para atingir o objetivo de integração. “Sincronizar contas”, “Criar pedidos de compra” ou “Obter informações de remessa” são exemplos.
  • Objeto: Pode ser um objeto SFDC (Salesforce) (como conta ou produto), uma tabela de banco de dados ou um objeto de negócios virtual, como pedidos de compra em um documento EDI.
  • Método: É o que está sendo feito com os dados, como CRUD (criar, ler, atualizar e excluir).
  • Nível de complexidade de Transformação: Este pode ser um destes níveis:
    • Baixo: Usa conectores de endpoint, um número baixo de transformações e uma ou duas operações para o cenário.
    • Médio: Pode ou não usar conectores de endpoint, usa diversas transformações e pesquisas externas e usa diversas operações por cenário.
    • Alto: Sem conectores de endpoint, inúmeras etapas de cenário e o endpoint é conhecido por ser desafiador.

Heurísticas são usadas para gerar horas. As fórmulas são usadas com base no número de cenários e na complexidade para chegar a uma estimativa, que pode facilmente estar errada em até 15–20%. Pense nisso como um número de orçamento a ser usado no início do processo.

A estimativa ROM pressupõe que um especialista em Harmony esteja fazendo o trabalho com algum gerenciamento de projeto leve. Também é de ponta a ponta: desde o início até o pós-entrada em operação. O tempo para construir uma integração não corresponde individualmente ao tempo decorrido. O tempo real dependerá dos níveis de pessoal, da estabilidade dos endpoints do cliente, da disponibilidade das PMEs dos clientes, etc. Pecando por excesso de cautela, assumimos uma proporção de 3:1 entre a duração do calendário e as horas estimadas.

Escopo do Trabalho (sow)¶

O Escopo do Trabalho (SOW) foi projetado para fornecer mais detalhes, a fim de obter uma imagem mais clara do projeto e fornecer uma verificação ou recálculo da estimativa de ROM. Para determinados endpoints (como SAP) ou tipos de projeto (como negócios Hub), você pode pular o processo ROM e ir direto para a etapa SOW.

Durante esta etapa, você deve organizar uma sessão de definição do escopo para finalizar os detalhes e responder às perguntas abertas. Os participantes ideais incluem usuários empresariais (e todos os proprietários de processos) e PMEs de endpoint. Incluir este último é fundamental, caso contrário pode ser difícil entrar em detalhes.

Esta é a melhor oportunidade para esclarecer o perfil de risco do projeto, por isso ouça com atenção e faça perguntas. Cubra estes tópicos:

• Endpoints

  • Versões: Versões a serem usadas ou encontradas.

  • No local/fora do local: Se for no local, certifique-se de cobrir o uso da nuvem versus Agentes Privados. Uma preocupação comum é a segurança da rede, como a abertura do firewall para Agentes Privados, portanto, garanta ao cliente e às partes interessadas que isso não é uma preocupação de segurança. Forneça um link para o White Paper de Segurança e Arquitetura da Jitterbit e os Requisitos do sistema host para Agentes Privados.

  • Suporte: Como o(s) endpoint(s) são suportados (internamente/externamente).

  • Estágios do ciclo de vida: Em desenvolvimento/pré-produção, manutenção, atualização, encerramento.

• Experiência em Endpoint

  • Especialização interna versus externa: Se for um endpoint complexo, como um ERP ou CRM, geralmente há experiência interna no departamento de TI ou parceiro de implementação e/ou suporte técnico. Claro, se você tiver experiência interna, melhor ainda.
  • Limites/funções: Às vezes, os clientes não têm clareza sobre a papel do integrador e presumem que a personalização do endpoint é feita pela Jitterbit; se esse tópico surgir, deixe os limites claros.
  • Disponibilidade e qualidade da documentação: Com a proliferação de serviços em nuvem e APIs, alguns fornecedores estão simplesmente listando suas APIs, mas a documentação pode ser escassa. Se esta for a sua situação, você deve reservar tempo para descoberta, viabilidade e testes.

• Cenários de integração

  • Objetos de método e endpoint: Defina-os para cada cenário. Exemplos:
    • " consultar periodicamente novos clientes no Endpoint X na conta do Endpoint Y em lote e atualize o novo número da conta para o Cliente."
    • "Receba uma solicitação em tempo real do Endpoint X que contém informações do pedido para enviar ao Endpoint Y, crie o método de pedido e responda com o novo número do pedido."
    • "Consulte a tabela X do banco de dados e atualize 200.000 valores de saldo de estoque para a API de inventário do Endpoint Y."
  • Potenciais bloqueadores: Os cenários são utilizados para a estimativa de tempo. Espere que o desenvolvimento de cada cenário (a menos que seja extremamente simples) encontre bloqueadores. Eles podem variar de técnicos (credenciais incorretas, endpoint inacessível, API opaca) a procedimentais (a empresa precisa definir um novo processo, a personalização é necessária, as PMEs não estão disponíveis).

• Prazo

  • Datas importantes: Normalmente, um cliente sabe sua entrada em operação, mas há outras datas importantes.

• Datas do teste de aceitação do usuário (UAT): Quando o UAT começa? (Isso pode exigir explicação se o cliente não estiver acostumado com o desenvolvimento em fases.)

  • Preparação do Endpoint: Se estiver usando novos endpoints, quando os ambientes estarão prontos para desenvolvimento e teste de integração?

  • Disponibilidade para PME: Há alguma restrição na disponibilidade para PME?

    Cuidado

    Tenha cuidado ao tentar acelerar um projeto de integração. Adicionar mais desenvolvedores não torna o desenvolvimento mais rápido, a menos que haja cenários muito claros e separados.

• Recursos

  • Abordagens: Os clientes têm abordagens variadas para os recursos do projeto:

    • Terceirizar principalmente: O cliente fornece um ponto de contato comercial ou PME e lida com requisitos, escalonamento, UAT e coordenação de recursos externos. Todos os outros recursos (principalmente desenvolvimento) são fornecidos pelos Serviços Profissionais da Jitterbit e/ou pelo Parceiro Jitterbit.

    • Principalmente insource: O cliente aprenderá a usar o Harmony e deseja apenas acesso a um Jitterbit SME para orientação e práticas recomendadas.

    • In/terceirizar: O cliente deseja que o Jitterbit Professional Services ou o Jitterbit Partner criem uma série de integrações e gradualmente as entreguem aos recursos do cliente. Esta parte é difícil de estimar. A abordagem recomendada é estimar todo o trabalho e depois subtrair uma porcentagem de horas.

      Nota

      O cliente pode não perceber que, independentemente disso, gastará muito tempo no projeto e que mudar o desenvolvimento de externo para interno não terá grande impacto. impacto (uma vez que a maior parte está limitada a uma única fase) e pode até retardar o progresso devido à transferência de conhecimento (TC).

  • Nível de envolvimento: Este diagrama ilustra o nível relativo de envolvimento do gerente de projeto (PM), dos recursos do cliente e dos recursos de desenvolvimento. Note-se que os recursos de desenvolvimento são mais envolvidos durante a fase de desenvolvimento, diminuindo posteriormente o seu envolvimento. Os recursos do cliente (geralmente usuários empresariais) estão muito envolvidos durante a fase UAT (Teste de Aceitação do Usuário), algo que geralmente é esquecido.

    

Pessoal¶

Estas diretrizes gerais são para a contratação de recursos com habilidades técnicas e de PM da Jitterbit. Eles excluem recursos como PMEs de processos de negócios de clientes e proprietários de endpoint. Com base no tamanho do projeto, estes níveis de pessoal são recomendados:

• Projetos pequenos: Projetos com 2 endpoints e menos de 12 cenários podem ser gerenciados por um único recurso técnico qualificado em Jitterbit em tempo parcial e um gerente de projeto em tempo parcial.

• Projetos médios: Projetos com 2 a 4 endpoints e 12 a 20 cenários podem ter o mesmo nível de equipe que projetos pequenos, com uma equipe mais envolvida.

• Projetos grandes: Projetos com mais de 5 endpoints e mais de 20 cenários têm muitas dependências ao determinar a equipe.

A papel do PM pode ter quase 100% de envolvimento ao longo do projeto se alguma destas afirmações for verdadeira:

• O cliente exige relatórios de status detalhados (como relatórios para um escritório de gerenciamento de projetos).

• Numerosas PME externas têm de configurar os endpoints do cliente para permitir a integração.

• É provável que o cliente tenha dificuldade em obter requisitos de integração detalhados.

• O PM é inexperiente ou ausente e o cliente espera que você gerencie todo o projeto.

Exerça escopo estrito e gerenciamento de mudanças nessas situações! Deixe claro ao cliente que o sucesso do projeto depende da eliminação de quaisquer bloqueios pelo cliente e do cumprimento dos prazos por todos os recursos do projeto.

Ao usar vários recursos de desenvolvimento, faça estas considerações:

• Ter mais de um desenvolvedor em um único projeto Jitterbit requer um alto grau de coordenação (mais trabalho para o PM), pois é fácil implantar alterações e sobrescrever o trabalho de outra pessoa.

• Esforce-se para atribuir os desenvolvedores a diferentes cenários de integração ou divida o trabalho em diferentes projetos Jitterbit.

• Use revisões de código e design entre desenvolvedores.

• Se possível, aumente os recursos durante a fase de desenvolvimento e, em seguida, reduza-os durante as fases UAT e de entrada em operação.

Reunião Inicial¶

O objetivo da reunião inicial é reunir os principais participantes do projeto, normalmente os principais usuários de negócios, PMEs, proprietários de endpoint e arquitetos de integração. Este tempo é usado para que todos estejam na mesma página e esclareçam as funções e responsabilidades. Durante a reunião inicial, estas tarefas devem ser concluídas:

• Datas importantes: Revise todas as datas importantes (não apenas a data de entrada em operação).
• Compartilhamento de informações: Compartilhe informações de contato e documentos.
• Revisão do cenário de integração: Revise os cenários de integração da definição do escopo.
  • Este é um bom momento para confirmar se algo mudou desde a última sessão de definição do escopo.
  • Se necessário, marque uma reunião detalhada de revisão do escopo.
• Funções e responsabilidades: Criar integração com o Jitterbit é muito rápido, mas lembre-se de que o maior fator que atrasa um projeto de integração são as dependências não técnicas. Este é um bom momento para enfatizar esse ponto. Esclareça as responsabilidades de cada papel:
  • PM
    • Trabalha com o cliente e a equipe técnica para obter e organizar requisitos de integração detalhados, incluindo mapeamentos em nível de campo. Os mapeamentos em nível de campo são necessários tanto para os recursos de desenvolvimento Jitterbit quanto para as PMEs endpoint.
    • Organiza a disponibilidade de negócios e PMEs endpoint para o projeto e aborda prontamente itens em aberto para a integração, como quem é quem, seu nível de comprometimento com o projeto, calendários, etc.
    • Comunica ao cliente e equipe técnica o andamento do desenvolvimento da integração e as pendências a serem resolvidas.
  • Desenvolvedor Jitterbit
    • Alcança uma compreensão dos requisitos para projetar a arquitetura de integração e trabalha com o cliente nas considerações de design (lote/tempo real, APIs, gerenciamento de dados mestres, requisitos de segurança, etc.). O desenvolvedor deve estar familiarizado com o Harmony Design Studio How-Tutoriais documentação.
    • Toma os requisitos detalhados e utiliza a ferramenta para desenvolver os cenários de operação, seguindo Jitterbit Best Practices.
    • Descobre rapidamente quaisquer bloqueadores e toma a iniciativa de resolvê-los.
    • Idealmente, o desenvolvedor Jitterbit está em comunicação direta com o cliente. Isolar o desenvolvedor Jitterbit das PMEs e clientes é uma má prática e leva a falhas e atrasos na comunicação. Os recursos do projeto devem ser uma equipe e comunicar-se com fluidez.
  • Endpoint PME
    • Fornece profundo conhecimento sobre as interfaces expostas.
    • Entende os requisitos de integração e, se houver possíveis problemas — como a necessidade de uma mudança em um endpoint ou se um requisito for inviável — alerta proativamente a equipe.
    • Está altamente disponível para auxiliar nos testes unitários. Isso pode incluir o fornecimento de dados de teste, o fornecimento de feedback imediato sobre os resultados dos testes de integração e a interpretação de respostas de erro.
• Licenciamento e direitos: Revise o licenciamento e os direitos do Jitterbit e o processo de solicitação de direitos.
• Arquitetura Harmony: Considere estes pontos em relação à arquitetura Harmony:
  • Caso sejam utilizados Agentes Privados, priorize a instalação da arquitetura técnica e conectividade aos endpoints, principalmente para desenvolvimento.
  • Se estiver trabalhando com sistemas locais, há muitas etapas que podem levar algum tempo para serem concluídas, como aquisição de hardware, instalação de Agente Privado, conectividade de rede, credenciais de usuário de integração e ciclo de testes. Como isso pode envolver vários grupos, comece o mais rápido possível para o ambiente de desenvolvimento.
  • Espere que as lições aprendidas na configuração do ambiente de desenvolvimento acelerem a configuração do ambiente de não desenvolvimento, portanto, elimine esta etapa o mais rápido possível.
  • Para obter mais informações, consulte Agentes e grupos de Agente, Requisitos de sistema para Agentes Privados, Harmony Ambientes e Documento técnico sobre segurança e arquitetura da Jitterbit.
• Assinaturas Harmony: Certifique-se de que os recursos de desenvolvimento sejam adicionados à organização Harmony com permissão de administrador (consulte Organizações Jitterbit).
• APIs Harmony: Se APIs forem usadas, revise as dependências. Verifique o URL padrão da API Jitterbit. Se o cliente começou a usar uma avaliação, é provável que o URL padrão ainda inclua a palavra "avaliação". Escale para o licenciamento Jitterbit para removê-lo antes de criar qualquer APIs (consulte Jitterbit API Manager).
• Reuniões futuras: Defina a cadência das reuniões futuras.
  • Se a integração fizer parte de uma implementação de endpoint, participe dessas reuniões.
  • Caso contrário, reuniões curtas e frequentes (diárias não são incomuns) são preferidas. Uma plataforma de mensagens instantâneas, como o Slack, também pode ser configurada.

Plano de Projeto de Integração¶

Conforme mencionado antes, a integração tem muitas dependências. Os planos de projeto tendem a ser de dois tipos:

• Parte da implementação de um novo endpoint, como um ERP.
• Autônomo, onde os endpoints são relativamente estáveis.

No primeiro caso, as tarefas do projeto de integração podem (e precisarão) ser intercaladas com o projeto global. Por exemplo, o desenvolvimento da integração terá que aguardar a configuração dos objetos de endpoint.

No segundo caso (autônomo), pode ser elaborado um plano de projeto apenas para construir a integração.

Independentemente de as tarefas de integração fazerem parte de outro plano ou serem independentes, as tarefas são as mesmas. Aqui está um exemplo de um plano de projeto independente:

Observe que o plano do projeto começa com os blocos de construção básicos e depois percorre cada cenário. A seção UAT (Teste de Aceitação do Usuário) pode ser adiada até que todos os cenários tenham atingido um ponto de prontidão.

Levantamento e Desenvolvimento de Requisitos¶

Esta seção começa cobrindo a abordagem geral para coleta e desenvolvimento de requisitos e, em seguida, se aprofunda nos detalhes de mapeamento, desenvolvimento, gerenciamento do processo de desenvolvimento, reutilização e registro em log e tratamento de erros.

Abordagem Geral¶

O front-end de desenvolvimento gráfico e de baixo código do Harmony (Harmony Studio) se presta a um modelo iterativo. Esta abordagem é não em cascata, onde todos os requisitos são documentados antes do início do desenvolvimento. Estas etapas principais descrevem o modelo iterativo geral:

• Comece com os cenários de dados mestre. Como a abordagem é iterar rapidamente por meio de um ciclo de definição-construção-teste, precisamos preencher os endpoints com dados mestres antes de trabalhar com dados transacionais.

• Entender quais sistemas são SOR (Systems of Record) e quais são SOE (Systems of Engagement):

  • SOR (Sistemas de Registro): A fonte oficial de dados mestre, geralmente um ERP.
• • SOE (Sistemas de Engajamento): O sistema voltado para o cliente ou vendedor, como um sistema para compra de um produto.

• Compreender os campos de dados chave e quais são partilhados (chaves externas ou estrangeiras).

  • Normalmente, as chaves de dados mestre do SOR são armazenadas no SOE para facilitar as atualizações de volta ao SOR. Por exemplo, se SAP for SOR e SFDC for SOE, os números de clientes SAP serão armazenados como IDs externos no SFDC.
  • Como as chaves compartilhadas podem exigir personalização (o que pode se tornar um bloqueador de tempo), é importante tratar essa área com antecedência.

Este diagrama mostra um exemplo usando Salesforce como SOE (System of Engagement) e SAP como SOR (System of Record), em um fluxo de dados mestre unidirecional com write-back.

Se estiver lidando com atualizações bidirecionais de dados mestres, reconheça que esta pode ser uma integração complicada:

• Você pode encontrar condições de corrida, lógica para excluir atualizações do usuário de integração separado dos usuários corporativos e chaves compartilhadas mútuas.
• Frequentemente, as regras de negócios para dados mestres não são as mesmas nos endpoints e a camada de integração precisa acomodá-las ou os endpoints precisam ser customizados. Isso pode ser um bloqueador, portanto, analise detalhadamente os cenários para esses tipos de integrações.

Mapeamento¶

O PM deve fazer com que o cliente comece a trabalhar nos mapeamentos detalhados em nível de campo. Eles são necessários tanto para os recursos de desenvolvimento da Jitterbit quanto para as PMEs endpoint.

O cliente pode estar acostumado a observar os sistemas do ponto de vista da interface do usuário e pode não ser capaz de produzir mapeamentos baseados no ponto de vista dos esquemas. Nesse caso, coloque os esquemas na planilha de mapeamento, se possível. Isso pode exigir a ajuda do SME, documentação on-line ou o uso do Harmony para conectar-se ao endpoint e extrair os esquemas.

Se o mapeamento for simples, você poderá fazer o mapeamento "ao vivo" usando o Harmony para inserir os esquemas de endpoint em uma transformação durante uma reunião com o cliente.

Esta planilha demonstra um exemplo de mapeamentos em nível de campo:

Quando houver definição de cenário suficiente para começar, tente construir a integração no Harmony e teste o mais rápido possível para identificar quaisquer bloqueadores.

À medida que o cliente trabalha na planilha de mapeamento, preste muita atenção em quais mapeamentos serão mais difíceis. A transformação é onde a borracha encontra a estrada, o que significa que é aqui que mapeamos os métodos de integração expostos entre os sistemas. É importante descobrir quais cenários serão mais difíceis do que outros, pois existe um grande multiplicador de tempo para eles. Mapeamentos fáceis podem levar apenas alguns minutos, enquanto mapeamentos complexos podem levar dias, então procure estas situações e priorize:

• Pesquisas externas do sistema: Para alguns sistemas, pode ser necessário procurar valores executando consultas. O perigo aqui é o impacto no desempenho: esteja ciente de que a transformação Harmony é executada por registro. Se estiver processando 200 registros e a transformação estiver fazendo uma pesquisa em cada registro, serão 200 consultas. Isso não é grande coisa se o destino for um banco de dados, mas se o destino for uma API, também pode ser 200 logins/logouts. Considere usar um dicionário para consultar os dados em um script de pré-operação, fazendo assim uma única consultar.

• Esquemas complexos: A transformação Harmony é "baseada em iteração". Por exemplo, se os esquemas de origem e de destino forem simples (como nome de cliente e endereço residencial), a transformação irá iterar uma vez por registro, assim:

  

  No próximo exemplo (abaixo), os esquemas de origem e de destino são complexos e a transformação precisa processar repetidamente as seções filhas. Para tornar as coisas mais complicadas, pode ser necessário processar as seções filhas condicionalmente:

  

Frequentemente, para obter progressos rápidos em mapeamentos complexos, as PME dos endpoint têm de ser reunidas para definir os requisitos, o que pode até exigir informações empresariais e pode levar à personalização dos endpoint, o que pode atrasar o projeto global. É de vital importância identificar requisitos de integração complexos o mais rápido possível e eliminar dependências rapidamente para manter o projeto em andamento.

Desenvolvimento¶

Conforme mencionado anteriormente, o trabalho de desenvolvimento pode começar logo após o início:

• Conecte os endpoints.
• Identificar e implementar cenários fáceis, especialmente se forem dados mestres.
• Para integrações complexas, mesmo que não completamente mapeadas, tome medidas para transformar os métodos de integração expostos em uma transformação.
  • Esquemas (geralmente) se aplicam apenas ao lidar com bancos de dados e serviços web.
  • Ao tratar de arquivos, eles podem ter formato hierárquico, que devem ser construídos manualmente no Jitterbit. Isso pode ser trabalhoso, então comece logo.
  • Para endpoints de banco de dados, será mais eficiente construir visualizações do que fazer com que o Harmony junte tabelas. Um procedimento armazenado pode ser uma abordagem melhor do que fazer com que o Harmony faça atualizações complexas.
  • Ao trabalhar com conectores de endpoint, use os assistentes do Harmony e certifique-se de que todos os objetos no escopo estejam disponíveis. Esta é uma boa maneira de validar se o usuário de integração tem todas as permissões necessárias para funcionar.
• O desenvolvedor deve examinar os esquemas de origem e de destino para fazer perguntas de mapeamento "inteligentes", como estas:
  • "Temos todos os campos obrigatórios?"
  • "Se passarmos um ID de registro, o endpoint atualizará automaticamente um registro ou tentará criá-lo?"
  • "Quantos registros podem ser passados em uma chamada?"
  • "Este esquema SAP IDoc usa abreviações alemãs. Alguém Sprechen Sie Deutsch?"
• Não deixe de revisar o esquema de resposta (se for um serviço da Web), principalmente quanto à forma como os erros são tratados. Alguns esquemas indicam sucesso ou fracasso geral, enquanto outros fornecem códigos que precisam ser avaliados.

Gerenciando o Processo de Desenvolvimento¶

Uma boa abordagem para gerenciar o processo de desenvolvimento é pegar os cenários capturados durante a definição do escopo e acompanhar os marcos relacionados a cada cenário. Este é um exemplo de planilha usada para rastrear os principais marcos no desenvolvimento de uma integração:

Trate cada cenário como uma mini iteração de desenvolvimento, começando com dependências de dados (como dados mestre). Em seguida, crie operações, crie transformações, busque alguns dados de teste, envie para um endpoint e lide com a resposta. Não busque a perfeição. Procure mover dados de teste simples do ponto A para o ponto B e depois passe para o próximo cenário. Em seguida, itere o desenvolvimento do cenário de integração, revelando bloqueadores até que o cenário principal de sucesso, bem como os cenários de erro, tenham sido desenvolvidos e testados em unidade.

O primeiro conjunto de integrações serão aquelas que apresentarem mais problemas, como conectividade, permissões, campos ausentes, etc. Portanto, quanto mais rápido chegarmos a esse ponto e eliminarmos os bloqueadores, melhor. Não procuramos a perfeição logo de cara.

Comece com um pequeno conjunto de dados de teste. Isso pode ser codificado em scripts ou usar uma consultar limitada a apenas alguns registros.

Se houver um bloqueador menor, documente-o, atribua a resolução à pessoa certa e passe para outro cenário. Mais uma vez, o objectivo é encontrar rapidamente as minas terrestres para que possam ser eliminadas, e essa responsabilidade é geralmente do cliente e/ou da PME.

Aqui está um exemplo de planilha de rastreamento de problemas:

Reusos¶

Como qualquer outra plataforma de desenvolvimento de software, o desenvolvimento pode ser acelerado se você não reinventar a roda. O Harmony tem várias maneiras de permitir isso:

• Scripts
  • Funções personalizadas inteiras podem ser criadas e chamadas a partir de muitas operações. A regra geral é que se você tiver que escrever o mesmo script duas vezes, torne-o um script chamável.
• Fonte e Destinos
  • Passe variáveis globais e/ou de projeto em vez de coisas codificadas, como caminhos de arquivo ou hosts FTP.
  • Use uma variável global como um espaço de trabalho intermediário em vez de fontes e destinos específicos da operação.
• Operações
  • Operações de tarefa única podem ser criadas uma vez e usadas muitas vezes, especialmente aquelas que lidam com tratamento de erros e registro.
  • As operações em um projeto podem ser chamadas de outro. Esteja ciente de que os logs aparecerão nos projetos nativos (chamados). Mas como o escopo das variáveis globais é a cadeia de operação (que pode ser chamada de mais de um projeto), é possível obter os resultados da operação remota e registrá-los no projeto chamador.

Registro e Tratamento de Erros¶

Um conjunto de requisitos frequentemente esquecido tem a ver com registro e tratamento de erros. O cliente pode não ter requisitos específicos, especialmente se este for o seu primeiro projeto de integração, pelo que o cliente necessitará de ajuda com as melhores práticas nesta área. Os pontos principais são estes:

• O Harmony faz o registro de operação pronto para uso.
• É fácil registrar dados adicionais, o que é muito útil para solução de problemas.
  • É aqui que o cliente pode perceber que seus cenários de integração exigirão suporte interno.
  • Quando um problema é identificado em um endpoint, se uma possível causa raiz for a integração, então um recurso precisará inspecionar os logs do Harmony. Quanto mais claros e informativos forem os logs, mais rápido será o processo de solução de problemas.
• Existem duas grandes classes de alertas: alertas relacionados a dados e alertas de falhas técnicas, que podem ou não precisar ir para o mesmo grupo. A falha técnica é uma configuração fácil, mas o registro relacionado a dados é totalmente personalizado e é mais fácil de incluir durante o desenvolvimento da integração, em vez de ser adicionado posteriormente.
• O Harmony Studio pode usar email com bastante facilidade, onde o serviço email é tratado como um endpoint para o serviço email do cliente, usando um Design Studio alvo email. Embora geralmente seja fácil de configurar, esta etapa não deve ser deixada para o final.
• O Harmony Management Console pode ser usado para configurar notificações adicionais relacionadas à organização.

Para obter informações detalhadas, consulte Configurar alertas, registros e tratamento de erros e o Harmony Notificações página.

Tratamento de Regras de Negócios¶

O grande debate: incluir — ou não incluir — regras de negócio.

Muitos clientes começam pensando “Não quero incluir regras de negócios no middleware; quero manter as coisas simples”, mas depois fornecem requisitos exatamente opostos!

A arquitetura de middleware ideal pressupõe que a camada de integração seja o mais enxuta possível, concentrando-se em seus pontos fortes: transformação de dados, processamento e orquestração de cenários, conexão de endpoint e registro e alertas. Adicionar regras de negócios complicadas apenas prejudicará a perfeição dessa arquitetura, espalhando o suporte às regras de negócios através dos limites do endpoint. Ou seja, se uma regra de negócio muda, ela não muda apenas na aplicação; isso também muda no middleware. Além disso, como o middleware é confuso, obscuro e místico, a manutenção de regras é entorpecente.

A realidade se intromete rudemente, já que o Harmony tem que trabalhar com o que os aplicativos expõem:

• Os dados são apresentados de forma deficiente e a única forma de processá-los é aplicando regras de negócio ("se valor = a, departamento = vendas, se b, departamento = operações, se c, departamento = suporte").
• Os dados de origem estão incompletos ("se o país = EUA, o ano fiscal é o calendário, se o país = Reino Unido, o ano fiscal é abril - março")
• O cenário de integração é orientado por dados ("se a ordem de serviço contiver linhas usando terceiros, processe essa linha como uma entrada de AP, caso contrário, atualize como uma ordem de serviço")

Sim, todos os itens acima podem ser tratados pelo endpoint. Mas isso pressupõe que o cliente tenha recursos e tempo para personalizar o endpoint ou alterar uma API. Se tudo isso estiver disponível, então faça isso. No entanto, o caso habitual é que os endpoints sejam mais difíceis de alterar e manter do que o projecto de integração Harmony.

Quando as regras de negócios devem ser tratadas, as melhores práticas são estas:

• Exteriorize sempre que possível. Por exemplo, tenha dados em uma tabela onde possam ser mantidos por um usuário.
• Use variáveis de projeto. Eles estão expostos no Harmony Management Console junto com documentação específica. O principal caso de uso é para credenciais de endpoint específicas do ambiente, mas elas também podem ser usadas para conduzir lógica de orquestração e condições de consultar.
• Adicione registro personalizado detalhado e tratamento de erros de dados, para que, se e quando as regras de negócios mudarem, o efeito na integração seja óbvio.

Agentes e Ambientes¶

O Harmony Agente é o carro-chefe da integração. Na verdade, o Harmony Studio não executa nenhum processo operação. Tudo acontece em um Harmony Agente. Uma decisão inicial importante é que tipo de agente usar: Privado ou Nuvem (consulte Agentes Jitterbit).

Se alguma destas afirmações for verdadeira, o projeto deverá ser executado em um Agente Privado:

• Um endpoint está atrás do firewall do cliente. Pode ser um aplicativo ou um compartilhamento de rede.
• É necessário um conector ou driver que não está disponível nos Agentes em Nuvem. Por exemplo, o driver Excel está disponível apenas em Agentes Privados.
• Os requisitos de segurança do cliente, tais como que nenhum dado seja permitido fora do seu firewall.

Caso contrário, os Agentes em Nuvem são uma opção. Do ponto de vista do cronograma do projeto, isso é ideal, pois evita todas as etapas relacionadas à necessidade de um cliente adquirir hardware de servidor e instalar o software Harmony Agente. No entanto, independentemente de você usar Nuvem ou Agentes Privados, ainda será necessário configurar membros e ambientes.

Dependendo do nível de licença, um cliente terá duas ou mais licenças de Agente Privado. Além disso, o cliente terá direito a vários ambientes, que normalmente são configurados seguindo as categorias padrão do ciclo de vida de desenvolvimento de software (desenvolvimento, qualidade, preparação, produção, suporte, etc.). A ferramenta de migração da Jitterbit funciona com ambientes para permitir a promoção de projetos de integração.

Em relação a agentes e ambientes, observe estes pontos importantes:

• Identificar um ambiente como “produção” não confere nada de especial. Ele não funciona mais rápido ou é mais resiliente. Um ambiente é muito parecido com qualquer outro.

• Um ambiente Harmony pode ser usado de várias maneiras. Caso o cliente forneça integração para terceiros, um ambiente pode ser utilizado como contêiner para projetos dedicados da empresa.

• Um único Agente Privado pode rodar mais de um ambiente.

• Uma dúvida frequente é se alguma regra de firewall de rede precisa ser alterada. Geralmente a resposta é “não”, a menos que o cliente esteja restringindo o tráfego HTTP de saída de servidores e/ou portas. A comunicação do Harmony para o Agente é toda enviada do Agente para o Harmony.

Um Grupo de Agentes é uma parte obrigatória da arquitetura do agente. Além de ser o contêiner virtual que abriga os Agentes Privados, desempenha outro papel importante. Ao contrário das ferramentas tradicionais de gerenciamento de servidores que exigem aplicativos adicionais, como balanceadores de carga, o Harmony facilita a obtenção de resiliência do servidor por meio de balanceamento de carga e failover. Simplesmente adicionando um agente a um grupo, o agente automaticamente se torna parte de um cluster de servidores.

Para ser claro, ao executar uma operação em um Grupo de Agentes com vários agentes, apenas um agente está executando essa operação. A operação não é dividida e executada por todos os agentes do grupo. Adicionar agentes a um grupo (normalmente) não tornará as operações mais rápidas. A exceção é um design que exige um grupo de agentes para atender APIs de entrada de alto tráfego; nesse caso, distribuir a carga entre vários agentes é uma boa ideia.

Para iniciar o desenvolvimento, basta um único Agente Privado e um único ambiente. Agentes adicionais podem ser adicionados aos grupos e novos ambientes podem ser adicionados à medida que o projeto avança (tudo dentro dos limites da licença, é claro).

Se a aquisição de um único agente for problemática, um Jitterbit Agente Privado pode ser executado em uma estação de trabalho. A melhor maneira de fazer isso é usar o Docker Agente para evitar conflitos na área de trabalho.

Processamento em Lote e Orientado a Eventos (em Tempo Real)¶

Para cada cenário de integração, há uma grande decisão: como será desencadeada a integração?

Existem basicamente duas formas: uma abordagem em lote, como por um agendamento, ou acionada por um evento, como por uma API.

Do ponto de vista do projeto de integração, implementar o processamento orientado a eventos exige muito menos esforço do que em lote. Por que é que?

• Embora o Jitterbit suporte uma função de agendamento, a maioria dos processos em lote exige um processo de busca de dados com base em uma "data da última modificação", o que requer scripts personalizados para recuperar a última vez que a operação foi executada, decidir se a operação foi executada com êxito e, em seguida, atualizar o repositório de carimbo de data/hora. Ao longo do caminho, você lida com fusos horários de endpoint, horário de verão e formatos de data potencialmente diferentes. Não se esqueça: consultar apenas os dados alterados por todos os usuários exceto pelo usuário de integração. E, ao migrar para outros ambientes, você deve ativar e desativar cronogramas seguindo o plano do projeto. Nenhum destes desafios representa enormes desafios, mas é evidente que um fardo de responsabilidade de desenvolvimento e gestão está a ser colocado sobre a camada de integração.

• Compare lote com orientado a eventos: a operação é executada somente quando chamada pelo endpoint. Sem horários, sem carimbos de data e hora, sem fusos horários. A responsabilidade está claramente no endpoint.

• O principal mecanismo de processamento orientado a eventos do Harmony é a plataforma Harmony API. Embora haja um custo de licenciamento mais alto, vale a pena.

• Obviamente, se o endpoint não suportar a chamada de uma API, o lote será sua única opção. Além disso, o cliente pode hesitar em usar uma API se o lote for uma opção.

Depois, há aquela quimera estranha, a opção de "lote rápido", em que o requisito do negócio é colocar os dados em um destino o mais rápido possível, mas o cliente não deseja implementar uma API. A conversa é mais ou menos assim:

Jitterbit: Para o cenário de pedidos, quando você deseja que os pedidos apareçam no ERP?

Cliente: Assim que possível.

Jitterbit: Então queremos tempo real e usamos APIs.

Cliente: Não, não quero fazer isso. Não podemos fazer um lote realmente rápido?

Jitterbit: Você quer dizer verificar a cada 10 minutos se há algum novo pedido?

Cliente: Não, mais rápido que isso. Qual o tempo mínimo para um agendamento?

Jitterbit: Hum… um minuto.

Cliente: Ótimo! Consulte o sistema de pedidos a cada minuto! Feito!

Jitterbit: Espere. Você percebe que estará prejudicando o sistema de pedidos, onde na maioria das vezes não há dados para processar. Você terá muitos ciclos desperdiçados e vasculhar os registros do Harmony será uma dor. Se o seu requisito de negócios for realmente mover dados o mais rápido possível, você precisará usar uma API. Além disso, há uma hospedar de outros benefícios…

E aqui o cliente, encorajado com essas informações, faz a coisa certa e aprova o uso de uma API. Mas se você não for convincente o suficiente, entre em contato com nosso pessoal de marketing; eles têm isso coberto.

Observe estas considerações para usar APIs:

• Certifique-se de compreender os requisitos máximos de processamento da API.
  • Você entende que a API é chamada quando um usuário altera um registro. Fácil! O design é que a operação seja chamada diretamente e, em seguida, atualize imediatamente o destino.
  • Mas o que o cliente esqueceu de te contar (e você esqueceu de perguntar) é que quando há uma atualização em massa de registros, em vez de obter um registro a cada 10 minutos, você ganha 10.000. O Jitterbit fará seu trabalho e ativará tantos threads quanto o servidor puder manipular e enfileirará o restante do tráfego de entrada e começará a atualizar o destino. Isso pode sobrecarregar o sistema de destino.
• Verifique a saída máxima e considere adicionar uma fila JMS, um banco de dados ou até mesmo um arquivo temporário para armazenar os dados de API recebidos antes de processar no destino.
• As APIs são licenciadas independentemente dos ambientes. Portanto, se uma API for usada para cada um dos ambientes de desenvolvimento, controle de qualidade e produção, serão três licenças de API, não uma.

Migração¶

Dependendo do processo do cliente, o projeto precisará ser migrado para um ambiente de controle de qualidade antes do UAT, ou os testes serão feitos em um ambiente de desenvolvimento e o projeto será então migrado para um ambiente de produção.

• Se possível, não migre para o próximo ambiente superior até que o projeto esteja quase concluído. Depois que uma migração ocorrer, você precisará se lembrar de migrá-los para outros ambientes.

• Evite fazer alterações em um ambiente “superior” para resolver um problema rapidamente, pensando que irá sincronizar os ambientes posteriormente. Em vez disso, faça a correção no ambiente “inferior” e migre-o. Não existe uma maneira infalível de identificar diferenças granulares entre projetos, por isso é fácil perder o controle das alterações.

Teste de Aceitação do Usuário (uat)¶

Todos os cenários são construídos, todos os testes de unidade são bem-sucedidos e os usuários fazem fila para testar a integração. É hora de liberar os usuários na integração e agora você descobrirá quais são os reais requisitos!

Esta fase pode ser um processo suave ou muito intenso. Realmente depende da qualidade das etapas anteriores. Lembre-se destas dicas durante a fase UAT:

• Esteja preparado para reagir rapidamente à medida que surgirem problemas. Se você fez bem o seu trabalho, a maioria dos problemas estará relacionada aos dados, não técnicos. Portanto, certifique-se de que as PMEs endpoint estejam disponíveis para fazer a triagem de problemas.

• Sempre que possível, faça com que o usuário assuma a liderança na solução de problemas: reagindo a alertas, lendo logs, rastreando a lógica de integração. Idealmente, a pessoa que fará esse trabalho na produção o fará durante esta fase.

• Acompanhe de perto os problemas que surgem durante o UAT e como eles são resolvidos. Uma situação frequente é que os problemas afetam os dados do endpoint e, embora o problema de integração seja corrigido, os dados não o são e se tornam um problema recorrente nos testes.

• Planeje reuniões frequentes com todos os envolvidos para resolver quaisquer bloqueadores.

• Conforme o tempo permitir, inicie a documentação.

• Desenvolva seu plano de transição.

• No ambiente de produção, realize testes de conexão e quaisquer outros testes que você possa realizar ou que sejam permitidos.

Pós-Produção e Acompanhamento¶

UAT concluído! A assinatura do usuário foi concluída! É hora de acender este foguete!

Nesta etapa, a migração final para produção deverá ser concluída. Se você estiver utilizando cronogramas, saiba que é possível migrá-los para produção e desativá-los no Harmony Management Console. Pode então caber ao cliente ativar as programações.

Espere encontrar-se periodicamente com o cliente para ter certeza de que tudo está indo bem, antecipando algumas perguntas.

Planeje uma reunião de “conclusão” para entregar a documentação do projeto e realizar qualquer transferência final de conhecimento.