Metodologia do Projeto de Integração do Cloud Studio

Introdução

Vamos encarar: projetos de integração podem ser difíceis, com muitas minas terrestres em potencial. Se a integração for "dados em movimento", há momentos em que os dados não estão interessados em se mover. Projetos de integração são altamente dependentes de endpoints e, portanto, podem ter 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. Há SMEs (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 gerência e há tempo adequado para testes. Se isso parece com seu projeto, parabéns! Para o resto de nós, continue lendo.

Abordagem

Quando você sabe que há um campo cheio de minas terrestres, você tem duas escolhas:

1. Mova-se com muito cuidado e deliberadamente, examine toda a paisagem até o menor detalhe e construa somente quando tudo for conhecido.

2. Comece o mais rápido possível, identifique quaisquer minas terrestres cedo e comemore as detonações... porque descobrir problemas cedo é muito melhor do que descobri-los depois.

Certo, então é o número 2. Apertem os cintos, 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 de API Harmony.

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

Foco

O foco deste documento não é como usar o Jitterbit tecnicamente (confira a outra documentação para os detalhes técnicos), mas, em vez disso, aborda os principais itens 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 alavancar os pontos fortes do Harmony para entregar um projeto bem-sucedido.

Escopo

O escopo é um processo de duas partes que envolve a coleta de informações, o delineamento dos limites do projeto e a obtenção das informações básicas necessárias para implementar o projeto:

1. Ordem aproximada de magnitude: Estime uma Ordem de Magnitude Bruta (ROM) de alto nível para o trabalho (pode ser ignorada para certos endpoints).
2. Âmbito de trabalho: Refine a estimativa detalhando um Escopo de Trabalho (SOW) para entregar o projeto.

Este processo é sensível ao conceito de GIGO — Garbage In, Garbage Out — então não o subestime. A planilha abaixo é usada como ponto de partida para o processo de escopo. A terminologia específica usada nesta planilha será definida mais tarde na Ordem aproximada de magnitude e Âmbito de trabalho subseções.

Ordem Aproximada de Grandeza (rom)

Indo para esta etapa, há uma presunção de que houve análise suficiente pelo cliente para determinar quais interfaces precisam ser construídas. Em um alto nível, as interfaces são necessárias quando um processo de negócios cruza os limites do aplicativo. Se os processos de negócios não forem firmes, então a integração também não será, e pode ser muito cedo para estimar.

A Ordem Bruta de Magnitude (ROM) é projetada para permanecer em alto nível e facilitar o retorno rápido para dar suporte ao planejamento e à tomada de decisões do cliente. As estimativas de ROM dependem destes elementos:

• Endpoints: Esta é a "coisa" com a qual o Harmony irá interagir para ler/escrever dados de/para. Pode ser um aplicativo com um conjunto de métodos remotos, um sistema baseado em arquivo como FTP ou sistemas de arquivo internos, um banco de dados ou um aplicativo web expondo APIs.
• Cenário de Integração: Esta é a descrição da movimentação de dados necessária para atingir a meta de integração. "Sincronizar Contas", "Criar Ordens de Compra" ou "Obter Informações de Envio" são exemplos.
  • Objeto: Pode ser um objeto SFDC (Salesforce) (como conta ou produto), uma tabela de banco de dados ou um objeto comercial virtual, como ordens de compra em um documento EDI.
  • Método: Isso é o que está sendo feito com os dados, como CRUD (criar, ler, atualizar e excluir).
  • Nível de complexidade da Transformação: Este pode ser um destes níveis:
    • Baixo: Usa conectores de endpoint, um baixo número de transformações e uma ou duas operações para o cenário.
    • Médio: Pode ou não usar conectores de endpoint, usa uma série de transformações e pesquisas externas e usa várias operações por cenário.
    • Alto: Nenhum conector de endpoint, inúmeras etapas de cenário e o endpoint é conhecido por ser desafiador.

Heurísticas são usadas para gerar horas. Fórmulas são usadas com base no número de cenários e 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 de ROM pressupõe que um especialista em Harmony esteja fazendo o trabalho com algum gerenciamento de projeto leve. Também é de ponta a ponta: do início até o pós-entrada em operação. O tempo para construir uma integração não corresponde um por um com o tempo decorrido. O tempo real dependerá dos níveis de pessoal, da estabilidade dos endpoints do cliente, da disponibilidade de PMEs do cliente, etc. Errando por excesso de cautela, assumimos uma proporção de 3:1 de duração do calendário para horas estimadas.

Âmbito de Trabalho (sow)

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

Durante esta etapa, você deve organizar uma sessão de escopo para finalizar os detalhes e responder a perguntas abertas. Participantes ideais incluem usuários empresariais (e todos os proprietários de processos) e SMEs de endpoint. Incluir o último é essencial, pois, do contrário, pode ser difícil entrar em detalhes.

Esta é a melhor chance de esclarecer o perfil de risco do projeto, então 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 estiver no local, certifique-se de cobrir o uso da Nuvem versus agentes privados. Uma preocupação comum é a segurança da rede, como abrir o firewall para agentes privados, então 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 do Jitterbit e os Requisitos do sistema host para agentes privados.

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

  • Estágios do ciclo de vida: Em desenvolvimento/pré-produção, manutenção, passando por atualizações, descontinuado.

• Especialização em Endpoint

  • Expertise interna vs. externa: Se for um endpoint complexo, como um ERP ou CRM, geralmente há expertise interna no departamento de TI, ou parceiro de implementação e/ou help desk. Claro, se você tiver expertise 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 pelo Jitterbit; se esse tópico surgir, deixe os limites claros.
  • Disponibilidade e qualidade da documentação: Com a proliferação de serviços de nuvem e APIs, alguns fornecedores estão simplesmente listando suas APIs, mas a documentação pode ser escassa. Se essa for sua situação, você deve criar tempo para descoberta, viabilidade e teste.

• 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 no Endpoint Y em lote e atualize o novo número da conta para Cliente."
    • "Receba uma solicitação em tempo real do Endpoint X que contém informações do pedido para enviar ao Endpoint Y para criar um método de pedido e responder com um novo número de pedido."
    • "Consultar a Tabela X do Banco de Dados e atualizar 200.000 valores de saldo de estoque para a API de Inventário do Endpoint Y."
  • Potenciais bloqueadores: Os cenários são usados 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 ruins, endpoint inacessível, API opaca) a processuais (necessidades comerciais para definir um novo processo, personalização é necessária, PMEs não estão disponíveis).

• Prazo

  • Datas importantes: Normalmente, o cliente sabe quando será lançado, 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.)

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

  • Disponibilidade para PMEs: Há alguma restrição quanto à disponibilidade para PMEs?

    Cuidado

    Tenha cuidado ao tentar acelerar um projeto de integração. Adicionar mais desenvolvedores não faz o desenvolvimento acontecer 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:

    • Principalmente terceirizado: O cliente fornece um ponto de contato comercial ou SME e lida com requisitos, escalonamento, UAT e coordenação de recursos externos. Todos os outros recursos (principalmente desenvolvimento) são fornecidos pela Jitterbit Professional Services e/ou pelo Jitterbit Partner.

    • Principalmente internamente: O cliente aprenderá a usar o Harmony e só quer ter acesso a um Jitterbit SME para orientação e melhores práticas.

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

      Nota

      O cliente pode não perceber que gastará muito tempo no projeto de qualquer maneira, e que mudar o desenvolvimento de externo para interno não terá um grande impacto (já que a maior parte dele é limitada a uma única fase), e pode até mesmo retardar o progresso por causa da transferência de conhecimento (KT).

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

    

Pessoal

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

• Projetos pequenos: Projetos com 2 endpoints e menos de 12 cenários podem ser gerenciados por um único recurso técnico especializado em Jitterbit em meio período e um gerente de projeto em meio período.

• 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.

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

A papel de PM pode envolver quase 100% do curso 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).

• Várias PMEs externas precisam configurar os endpoints do cliente para permitir a integração.

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

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

Exercite escopo rigoroso e gerenciamento de mudanças nessas situações! Deixe claro para o cliente que o sucesso do projeto depende do cliente remover quaisquer bloqueadores e de todos os recursos do projeto cumprirem os prazos.

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

• Ter mais de um desenvolvedor em um único projeto Jitterbit exige um alto grau de coordenação (mais trabalho para o PM), pois é fácil implantar alterações e substituir 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 depois diminua durante as fases de UAT e entrada em operação.

Reunião de Início

O objetivo da reunião de kickoff é reunir os principais participantes do projeto, normalmente os principais usuários de negócios, PMEs, proprietários de endpoint e arquitetos de integração. Esse tempo é usado para que todos cheguem a um acordo e esclareçam as funções e responsabilidades. Durante a reunião de kickoff, essas tarefas devem ser concluídas:

• Datas importantes: Revise todas as datas importantes (não apenas a data de lançamento).
• 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 do escopo.
  • Este é um bom momento para confirmar se algo mudou desde a última sessão de escopo.
  • Se necessário, marque uma reunião detalhada de revisão do escopo.
• Funções e responsabilidades: Construir integração com Jitterbit é muito rápido, mas tenha em mente 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 para 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. Mapeamentos em nível de campo são necessários tanto para os recursos de desenvolvimento do Jitterbit quanto para os SMEs de endpoint.
    • Organiza a disponibilidade de PMEs de negócios e endpoint para o projeto e aborda prontamente itens em aberto para integração, como quem é quem, seu nível de comprometimento com o projeto, calendários, etc.
    • Comunica ao cliente e à equipe técnica o progresso do desenvolvimento da integração e os itens em aberto a serem resolvidos.
  • Desenvolvedor Jitterbit
    • Obtém uma compreensão dos requisitos para projetar a arquitetura de integração e trabalha com o cliente em considerações de design (lote/tempo real, APIs, gerenciamento de dados mestres, requisitos de segurança, etc.).
    • Pega os requisitos detalhados e usa a ferramenta para desenvolver os cenários de operação, seguindo as melhores práticas do Jitterbit.
    • Rapidamente revela quaisquer obstáculos e toma a iniciativa de resolvê-los.
    • Idealmente, o desenvolvedor Jitterbit está em comunicação direta com o cliente. Isolar o desenvolvedor Jitterbit de PMEs e clientes é uma prática ruim e leva a falhas de comunicação e atrasos. Os recursos do projeto devem ser uma equipe e devem se comunicar de forma fluida.
  • Endpoint PME
    • Fornece profundo conhecimento sobre as interfaces expostas.
    • Entende os requisitos de integração e, se houver problemas potenciais — como a necessidade de uma alteração em um endpoint ou se um requisito for inviável — alerta a equipe proativamente.
    • Está altamente disponível para auxiliar com testes unitários. Isso pode incluir fornecer dados de teste, fornecer feedback rápido sobre os resultados dos testes de integração e interpretar respostas de erro.
• Licenciamento e direitos: Revise o licenciamento e os direitos do Jitterbit e o processo para solicitar direitos.
• Arquitetura Harmony: Considere estes pontos sobre a arquitetura Harmony:
  • Se forem utilizados agentes privados, priorize a instalação da arquitetura técnica e a conectividade com os endpoints, principalmente para desenvolvimento.
  • Se estiver trabalhando com sistemas locais, há muitas etapas que podem levar 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 o 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, então conclua essa etapa o mais rápido possível.
• Associações Harmony: Certifique-se de que os recursos de desenvolvimento sejam adicionados à organização Harmony com uma permissão de administrador (consulte Organizações Jitterbit).
• Harmony APIs: Se APIs forem usadas, revise as dependências. Verifique a URL padrão da API Jitterbit. Se o cliente começou a usar uma versão de teste, é provável que a URL padrão ainda inclua a palavra "teste". Encaminhe para o licenciamento Jitterbit para que isso seja removido antes de construir qualquer APIs.
• 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

Como mencionado antes, a integração tem muitas dependências. Os planos de projeto tendem a vir em 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 geral. Por exemplo, o desenvolvimento da integração terá que esperar os objetos de endpoint serem configurados.

No segundo caso (independente), um plano de projeto apenas para construir a integração pode ser configurado.

Independentemente das tarefas de integração serem parte de outro plano ou autônomas, as tarefas são as mesmas. Aqui está um exemplo de um plano de projeto autônomo:

Observe que o plano do projeto começa com os blocos de construção básicos e, em seguida, itera por cada cenário. A seção UAT (User Acceptance Testing) pode ser adiada até que todos os cenários tenham atingido um ponto de prontidão.

Coleta e Desenvolvimento de Requisitos

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

Abordagem Geral

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

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

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

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

• Entender os principais campos de dados e quais são compartilhados (chaves externas ou estrangeiras).

  • Normalmente, as chaves de dados mestre do SOR são armazenadas no SOE para facilitar as atualizações de volta para o SOR. Por exemplo, se SAP for o SOR e SFDC for o 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 cuidar dessa área desde o início.

Este diagrama mostra um exemplo usando o Salesforce como SOE (Sistema de Engajamento) e o SAP como SOR (Sistema de Registro), em um fluxo de dados mestre unidirecional com write-back.

Ao lidar com atualizações bidirecionais de dados mestres, reconheça que essa 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 separadamente dos usuários comerciais e chaves compartilhadas mútuas.
• Frequentemente, as regras de negócios para dados mestres não são as mesmas nos endpoints, e ou a camada de integração tem que acomodá-las, ou os endpoints precisam ser personalizados. Isso pode ser um bloqueador, então trabalhe nos cenários em detalhes para esses tipos de integrações.

Mapeamento

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

O cliente pode estar acostumado a olhar para os sistemas do ponto de vista da interface do usuário e pode não ser capaz de produzir mapeamentos com base 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ê pode fazê-lo "ao vivo" usando o Harmony para extrair 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 testar o mais rápido possível para identificar quaisquer bloqueadores.

À medida que o cliente trabalha na planilha de mapeamento, preste bastante atenção em quais mapeamentos serão mais difíceis. A transformação é onde a teoria encontra a prática, ou seja, é aqui que mapeamos os métodos de integração expostos entre sistemas. É importante descobrir quais cenários serão mais difíceis do que outros, pois há um alto multiplicador de tempo para eles. Mapeamentos fáceis podem levar apenas minutos, enquanto mapeamentos complexos podem levar dias, então procure por essas situações e priorize:

• Pesquisas de sistema externo: Para alguns sistemas, pode ser necessário pesquisar 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, isso significa 200 consultas. Isso não é um grande problema se o destino for um banco de dados, mas se o destino for uma API, isso também pode significar 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 destino forem simples (como o nome do cliente e o endereço residencial), a transformação iterará uma vez por registro, assim:

  

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

  

Frequentemente, para fazer progresso rápido em mapeamentos complexos, os SMEs de endpoint precisam ser reunidos para elaborar os requisitos, o que pode até exigir contribuição empresarial e pode levar à personalização do endpoint, tudo isso pode atrasar o projeto geral. É de vital importância identificar requisitos de integração complexos o mais rápido possível e limpar dependências rapidamente para manter o projeto avançando.

Desenvolvimento

Como mencionado anteriormente, o trabalho de desenvolvimento pode começar logo após o pontapé inicial:

• Conecte os endpoints.
• Identificar e implementar cenários fáceis, principalmente se forem dados mestres.
• Para integrações complexas, mesmo que não completamente mapeadas, tome medidas para obter os métodos de integração expostos em uma transformação.
  • Os esquemas (geralmente) se aplicam somente ao lidar com bancos de dados e serviços web.
  • Ao lidar com arquivos, eles podem ter um formato hierárquico, que precisa ser construído 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 ter o Harmony juntando tabelas. Um procedimento armazenado pode ser uma abordagem melhor do que ter o Harmony fazendo 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 trabalhar.
• O desenvolvedor deve analisar os esquemas de origem e 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 web), particularmente quanto a como os erros são manipulados. Alguns esquemas indicam sucesso ou falha 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 o escopo e rastrear marcos relacionados a cada cenário. Esta é uma planilha de exemplo usada para rastrear marcos importantes em um desenvolvimento de integração:

Trate cada cenário como uma mini iteração de desenvolvimento, começando com dependências de dados (como dados mestres). Em seguida, construa operações, construa transformações, busque alguns dados de teste, envie para um endpoint, manipule a resposta. Não busque a perfeição. Procure mover dados de teste simples do ponto A para o ponto B e, em seguida, 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 de sucesso principal, bem como os cenários de erro, tenham sido desenvolvidos e testados em unidade.

O primeiro conjunto de integrações será o que apresentará mais problemas, como conectividade, permissões, campos ausentes, etc. Então, quanto mais rápido chegarmos a esse ponto e limparmos os bloqueadores, melhor. Não estamos buscando 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 pequeno bloqueador, documente-o, atribua a resolução à pessoa certa e passe para outro cenário. Novamente, o ponto é encontrar rapidamente as minas terrestres para que elas possam ser removidas, e essa responsabilidade geralmente é do cliente e/ou da PME.

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

Reutilizar

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 habilitar isso:

• Scripts
  • Funções personalizadas inteiras podem ser construídas e chamadas 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 Alvos
  • Passe variáveis globais e/ou de projeto em vez de codificar coisas 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.
  • 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á-la no projeto de chamada.

Registro e Tratamento de Erros

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

• O Harmony faz o registro de operação imediatamente.
• É 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 os logs, mais rápido será o processo de solução de problemas.
• Há duas classes amplas de alertas: alertas relacionados a dados e alertas de falha técnica, que podem ou não precisar ir para o mesmo grupo. Falha técnica é uma configuração fácil, mas o registro relacionado a dados é todo 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 o Cloud Studio notificações email. Embora isso 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 a palestra técnica sobre as melhores práticas de 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ócios.

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 tem que a camada de integração deve ser a mais enxuta possível, focando em seus pontos fortes: transformação de dados, processamento e orquestração de cenários, conexão de endpoint e registro e alerta. Adicionar regras de negócios complicadas só vai estragar a perfeição dessa arquitetura ao espalhar o suporte a regras de negócios pelos limites do endpoint. Ou seja, se uma regra de negócios muda, ela não muda apenas no aplicativo; ela muda no middleware também. Além disso, como o middleware é turvo, obscuro e místico, a manutenção de regras é entorpecente.

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

• Os dados são apresentados de forma inadequada, e a única maneira de processá-los é aplicar regras de negócios ("se valor = a, departamento = vendas, se b, departamento = operações, se c, departamento = suporte").
• Os dados de origem estão incompletos ("se país = EUA, o ano fiscal é calendário, se 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 que usam terceiros, processe essa linha como uma entrada AP, caso contrário, atualize como uma ordem de serviço")

Sim, tudo isso acima pode ser manipulado pelo endpoint. Mas isso pressupõe que o cliente tenha os recursos e o tempo para personalizar o endpoint ou alterar uma API. Se tudo isso estiver disponível, então, por todos os meios, faça isso. No entanto, o caso usual é que os endpoints são mais difíceis de alterar e manter do que o projeto de integração Harmony.

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

• Externalize onde possível. Por exemplo, tenha dados em uma tabela onde eles podem ser mantidos por um usuário.
• Use variáveis de projeto. Elas são expostas 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 agente Harmony é o cavalo de batalha da integração. O Harmony Studio não executa nenhum processo de operação. Tudo acontece em um agente Harmony. Uma decisão inicial importante é que tipo de agente usar: privado ou na nuvem (veja Agentes Jitterbit).

Se qualquer uma dessas opçõ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 esteja disponível nos agentes de nuvem. Por exemplo, o driver do Excel está disponível somente em agentes privados.
• Os requisitos de segurança do cliente, de modo que nenhum dado seja permitido fora do firewall.

Caso contrário, os agentes de nuvem são uma opção. De uma perspectiva de cronograma de projeto, isso é ideal, pois evita todas as etapas relacionadas a um cliente ter que adquirir hardware de servidor e instalar o software do agente Harmony. No entanto, independentemente de você usar agentes de nuvem ou privados, você ainda precisa configurar membros e ambientes.

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

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

• Identificar um ambiente como "produção" não confere nada de especial. Ele não roda mais rápido nem é mais resiliente. Um ambiente é praticamente igual a qualquer outro.

• Um ambiente Harmony pode ser usado de muitas maneiras. Se o cliente estiver fornecendo integração para terceiros, um ambiente pode ser usado como um contêiner para projetos dedicados da empresa.

• Um único agente privado pode executar mais de um ambiente.

• Uma pergunta frequente é se alguma regra de firewall de rede precisa ser alterada. Normalmente 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 Harmony-para-agente é toda de saída 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 contém os agentes privados, ele desempenha outra papel importante. Ao contrário das ferramentas tradicionais de gerenciamento de servidor que exigem aplicativos adicionais, como balanceadores de carga, o Harmony facilita a obtenção de resiliência do servidor por meio do balanceamento de carga e failover. Simplesmente adicionando um agente a um grupo, o agente automaticamente se torna parte de um cluster de servidores.

Para esclarecer, 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 em todos os agentes do grupo. Adicionar agentes a um grupo não fará (geralmente) as operações serem executadas mais rapidamente. A exceção é um design que exige um grupo de agentes para atender APIs de entrada de alto tráfego, caso em que distribuir a carga entre vários agentes é uma boa ideia.

Para começar o desenvolvimento, tudo o que é necessário é um único agente privado e um único ambiente. Agentes adicionais podem ser adicionados a grupos, e novos ambientes podem ser adicionados conforme o projeto progride (tudo dentro dos limites da licença, é claro).

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

Processamento em Lote e Orientado a Eventos (tempo Real)

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

Existem basicamente duas maneiras: uma abordagem em lote, como por meio de uma programação, ou acionada por um evento, como por uma API.

Da perspectiva de um projeto de integração, implementar processamento orientado a eventos é muito menos trabalhoso do que lote. Por que isso?

• 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 script personalizado para recuperar a última vez que a operação foi executada, decidir se a operação foi executada com sucesso e, em seguida, atualizar o repositório de carimbo de data/hora. Ao longo do caminho, você lida com fusos horários de endpoint potencialmente diferentes, horário de verão e formatos de data. 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 lidar com a ativação e desativação de agendamentos seguindo o plano do projeto. Nenhum desses são grandes desafios, mas claramente um fardo de responsabilidade de desenvolvimento e gerenciamento está sendo colocado na camada de integração.

• Compare lote com event-driven: a operação é executada somente quando chamada pelo endpoint. Sem agendamentos, sem timestamps, sem fusos horários. A responsabilidade está claramente no endpoint.

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

• Obviamente, se o endpoint não suporta chamar uma API, então lote é sua única opção. Além disso, o cliente pode se recusar a usar uma API se lote for uma opção.

Então há aquela quimera estranha, a opção "fast-batch", onde o requisito de negócio é obter dados em um alvo o mais rápido possível, mas o cliente não quer implementar uma API. A conversa é mais ou menos assim:

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

Cliente: O mais breve possível.

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

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

Jitterbit: Você quer dizer verificar a cada 10 minutos se há novos pedidos?

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

Jitterbit: Hum… um minuto.

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

Jitterbit: Espere aí. Você percebe que estará martelando o sistema de pedidos, onde na maioria das vezes não há dados para processar. Você terá muitos ciclos desperdiçados, e vasculhar os logs do Harmony será uma dor. Se a sua necessidade comercial é realmente mover dados o mais rápido possível, então você precisa usar uma API. Além disso, há uma hospedar de outros benefícios…

E aqui o cliente, encorajado com essa informação, 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.

Tome nota destas considerações para usar APIs:

• Certifique-se de entender 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 é para que a operação seja chamada diretamente e então atualize imediatamente o alvo.
  • Mas o que o cliente esqueceu de lhe dizer (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ê obtém 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 alvo. 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 da API recebidos antes do processamento no destino.
• APIs são licenciadas independentemente dos ambientes. Então, se uma API for usada para cada um dos ambientes de desenvolvimento, QA e produção, isso significa 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 completo. Uma vez que uma migração aconteça, você precisa se lembrar de migrá-los para outros ambientes.

• Evite fazer alterações em um ambiente "superior" para resolver um problema rapidamente, pensando que você sincronizará os ambientes mais tarde. Em vez disso, faça a correção no ambiente "inferior" e migre-a. Não há uma maneira infalível de identificar diferenças granulares entre projetos, então é 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 unitários são bem-sucedidos e os usuários são alinhados para testar a integração. É hora de deixar os usuários livres na integração, e agora você descobrirá quais são os requisitos reais!

Esta fase pode ser um processo suave ou muito intenso. Depende realmente da qualidade dos passos anteriores. Tenha estas dicas em mente durante a fase UAT:

• Esteja preparado para reagir rapidamente quando os problemas surgirem. Se você fez bem o seu trabalho, a maioria dos problemas será relacionada a dados, não técnica. Então, certifique-se de que os SMEs de endpoint estejam disponíveis para triar problemas.

• Sempre que possível, deixe o usuário assumir a liderança na solução de problemas: reagir a alertas, ler logs, rastrear a lógica de integração. Idealmente, a pessoa que fará esse trabalho na produção o fará durante essa 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 são e se tornam um problema recorrente com os testes.

• Planeje reuniões frequentes com todos os envolvidos para resolver quaisquer obstáculos.

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

• Desenvolva seu plano de transição.

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

Pós-produção e Monitoramento

UAT concluído! Assinatura do usuário concluída! É hora de acender este foguete!

Nesta etapa, a migração final para a produção deve ser concluída. Se você estiver usando programações, esteja ciente de que você pode migrá-las para a produção e desativá-las no Harmony Management Console. Pode então ficar a critério do cliente ativar as programações.

Espere se reunir com o cliente periodicamente para garantir que tudo esteja indo bem, antecipando algumas perguntas.

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