Metodologia de projeto de integração para o Jitterbit Integration Studio

Introdução

Vamos encarar a realidade: projetos de integração podem ser desafiadores, com muitas armadilhas potenciais. Se a integração é "dados em movimento", há momentos em que os dados não estão interessados em se mover. Projetos de integração dependem fortemente de endpoints e, portanto, podem ter riscos que estão fora do controle do integrador.

No mundo ideal, os endpoints são estáveis, possuem APIs bem documentadas e têm respostas de erro claras. Existem especialistas no assunto (SMEs) prontamente disponíveis, e ambientes não produtivos estão disponíveis tanto para desenvolvimento quanto para testes. 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 há um campo cheio de armadilhas, você tem duas opções:

1. Mover-se com muito cuidado e deliberadamente, inspecionar toda a paisagem até o menor detalhe e construir apenas quando tudo estiver conhecido.

2. Começar o mais rápido possível, identificar quaisquer armadilhas cedo e celebrar as detonações… porque descobrir problemas cedo é muito superior a descobri-los mais tarde.

Certo, então número 2 é a escolha. Prepare-se, vamos nos mover rápido.

Público-alvo

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

Isso inclui aqueles com funções como um parceiro Jitterbit realizando 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 PM do cliente, implementando o Jitterbit iPaaS sozinho ou com a ajuda dos Serviços Profissionais da Jitterbit.

Foco

O foco deste documento não é como usar o Jitterbit tecnicamente (consulte a outra documentação para os detalhes técnicos) mas sim abordar os itens-chave que um PM para um projeto de integração deve conhecer. Este guia mostra como organizar sua equipe, reunir e validar requisitos de forma clara e concisa, e aproveitar os pontos fortes do Jitterbit iPaaS para entregar um projeto bem-sucedido.

Escopo

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

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

Esse 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 adiante nas subseções Ordem de magnitude aproximada e Escopo do trabalho.

Ordem de magnitude aproximada (ROM)

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

A Ordem de Magnitude Aproximada (ROM) é projetada para permanecer em um nível alto e facilitar uma rápida resposta para apoiar o planejamento e a tomada de decisões do cliente. As estimativas de ROM dependem desses elementos:

• Endpoints: Este é o "objeto" com o qual o Jitterbit iPaaS interagirá para ler/escrever dados de/para. Isso 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 uma aplicação web que expõe APIs.
• Cenário de Integração: Esta é a descrição do movimento de dados necessário para alcançar o objetivo de integração. "Sincronizar Contas", "Criar Pedidos de Compra" ou "Obter Informações de Envio" são exemplos.
  • Objeto: Isso 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: Isso é o que está sendo feito com os dados, como CRUD (criar, ler, atualizar e excluir).
  • Nível de Complexidade da Transformação: Isso pode ser um desses 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 um número de transformações e buscas externas, e utiliza várias operações por cenário.
    • Alto: Sem conectores de endpoint, numerosos passos de cenário, e o endpoint é conhecido por ser desafiador.

Heurísticas são usadas para gerar horas. Fórmulas são utilizadas 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 orçamentário a ser usado no início do processo.

A estimativa ROM assume que um especialista em Jitterbit iPaaS está realizando o trabalho com um leve gerenciamento de projeto. Ela também é de ponta a ponta: desde a iniciação até o pós-implementação. O tempo para construir uma integração não corresponde um a um ao tempo decorrido. O tempo real dependerá dos níveis de pessoal, da estabilidade dos pontos finais do cliente, da disponibilidade de SMEs do cliente, etc. Errando pelo lado da cautela, assumimos uma proporção de 3:1 de duração do calendário para horas estimadas.

Escopo do trabalho (SOW)

O Escopo do Trabalho (SOW) é projetado para fornecer mais detalhes a fim de obter uma imagem mais clara do projeto e para fornecer uma verificação ou recálculo da estimativa ROM. Para certos pontos finais (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 escopo para finalizar detalhes e responder a perguntas em aberto. Os participantes ideais incluem usuários de negócios (e todos os proprietários de processos) e SMEs de pontos finais. Incluir estes últimos é fundamental, pois, caso contrário, pode ser difícil entrar nos detalhes.

Esta é a melhor oportunidade para esclarecer o perfil de risco do projeto, então ouça atentamente e faça perguntas. Aborde os seguintes tópicos:

• Pontos finais

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

  • On/off-premises: Se for on-premises, certifique-se de cobrir o uso de agentes em nuvem versus agentes privados. Uma preocupação comum é a segurança da rede, como abrir o firewall para agentes privados, então assegure ao cliente e às partes interessadas que isso não é uma preocupação de segurança. Forneça um link para o documento técnico de segurança e arquitetura do Jitterbit e os requisitos do sistema do host para agentes privados.

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

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

• Especialização em Endpoint

  • Especialização interna vs. externa: Se um endpoint é complexo, como um ERP ou CRM, geralmente há especialização interna no departamento de TI, ou um parceiro de implementação e/ou suporte técnico. Claro, se você tiver especialização interna, melhor ainda.
  • Limites/papéis: Às vezes, os clientes não têm clareza sobre o papel do integrador e assumem que a personalização do endpoint é feita pela Jitterbit; se esse assunto 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 essa for a sua situação, você deve reservar tempo para descoberta, viabilidade e testes.

• Cenários de Integração

  • Método e objetos de endpoint: Defina esses para cada cenário. Exemplos:
    • "Consultar periodicamente novos clientes no Endpoint X para a conta no Endpoint Y em uma base de lote, e atualizar o novo número da conta para o Cliente."
    • "Receber uma solicitação em tempo real do Endpoint X que contém informações do pedido para enviar ao método de criação de pedido do Endpoint Y, responder com o novo número do pedido."
    • "Consultar a Tabela do Banco de Dados X e atualizar 200.000 valores de saldo de estoque para a API de Inventário do Endpoint Y."
  • Bloqueadores potenciais: 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. Estes podem variar de técnicos (credenciais inválidas, endpoint inacessível, API opaca) a procedimentais (a empresa precisa definir um novo processo, personalização é necessária, especialistas não estão disponíveis).

• Cronograma

  • Datas importantes: Normalmente, um cliente sabe sua data de lançamento, mas há outras datas importantes.

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

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

  • Disponibilidade do SME: Existem restrições na disponibilidade do SME?

    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 em relação aos 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 pelos Serviços Profissionais da Jitterbit e/ou pelo Parceiro Jitterbit.

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

    • Híbrido: O cliente deseja que os Serviços Profissionais da Jitterbit ou o Parceiro Jitterbit construam um número de integrações e gradualmente as transfiram para os 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 estará gastando uma grande quantidade de tempo no projeto de qualquer forma, e que transferir o desenvolvimento de externo para interno não terá um grande impacto (já que a maior parte está limitada a uma única fase) e pode até desacelerar o progresso devido à 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 estão mais envolvidos durante a fase de desenvolvimento, com seu envolvimento diminuindo posteriormente. Os recursos do cliente (geralmente usuários de negócios) estão muito envolvidos durante a fase de UAT (Teste de Aceitação do Usuário), algo que é comumente negligenciado.

    

Alocação de Recursos

Estas diretrizes gerais são para a alocação de recursos com habilidades técnicas e de gerenciamento de projetos da Jitterbit. Elas excluem recursos como especialistas em processos de negócios do cliente e proprietários de endpoints. Com base no tamanho do projeto, os níveis de alocação recomendados são:

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

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

• Projetos grandes: Projetos com 5+ endpoints e 20+ cenários têm muitas dependências ao determinar a alocação de recursos.

O papel do gerente de projeto pode ter quase 100% de envolvimento ao longo do projeto se alguma dessas afirmações for verdadeira:

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

• Vários especialistas externos precisam configurar os endpoints do cliente para permitir a integração.

• O cliente provavelmente terá dificuldades para obter requisitos de integração detalhados.

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

Exerça uma gestão rigorosa de escopo e mudanças nessas situações! Deixe claro para o cliente que o sucesso do projeto depende de o cliente eliminar quaisquer bloqueios e de todos os recursos do projeto cumprirem os prazos.

Ao usar múltiplos recursos de desenvolvimento, considere o seguinte:

• Ter mais de um desenvolvedor em um único projeto Jitterbit requer um alto grau de coordenação (mais trabalho para o gerente de projeto), uma vez que é fácil implantar mudanças e sobrescrever o trabalho de outra pessoa.

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

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

• Se possível, aumente os recursos durante a fase de desenvolvimento e, em seguida, diminua durante as fases de UAT e go-live.

Reunião de início

O objetivo da reunião de início é reunir os principais participantes do projeto, tipicamente os principais usuários de negócios, especialistas no assunto (SMEs), proprietários de endpoints e arquitetos de integração. Este tempo é utilizado para que todos estejam na mesma página e para esclarecer os papéis e responsabilidades. Durante a reunião de início, as seguintes tarefas devem ser concluídas:

• Datas-chave: Revisar todas as datas-chave (não apenas a data de lançamento).
• Compartilhamento de informações: Compartilhar informações de contato e documentos.
• Revisão do cenário de integração: Revisar os cenários de integração a partir da definição de escopo.
  • Este é um bom momento para confirmar se algo mudou desde a última sessão de definição de escopo.
  • Se necessário, agendar uma reunião detalhada de revisão de escopo.
• Papéis e responsabilidades: Construir integrações 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 de cada papel:
  • PM
    • Trabalha com o cliente e a equipe técnica para obter e organizar requisitos detalhados de integração, incluindo mapeamentos de nível de campo. Mapeamentos de nível de campo são necessários tanto pelos recursos de desenvolvimento do Jitterbit quanto pelos SMEs de endpoint.
    • Organiza a disponibilidade de SMEs de negócios e de endpoint para o projeto e aborda prontamente itens pendentes 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 progresso do desenvolvimento da integração e os itens pendentes a serem resolvidos.
  • Desenvolvedor Jitterbit
    • Compreende os 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.).
    • Toma os requisitos detalhados e usa a ferramenta para desenvolver os cenários de operação, seguindo as melhores práticas do Jitterbit.
    • Identifica rapidamente quaisquer bloqueios e toma a iniciativa para resolvê-los.
    • Idealmente, o desenvolvedor Jitterbit está em comunicação direta com o cliente. Isolar o desenvolvedor Jitterbit de SMEs e clientes é uma má prática e leva a falhas de comunicação e atrasos. Os recursos do projeto devem ser uma equipe e devem se comunicar de forma fluida.
  • SME de Endpoint
    • Fornece profunda expertise sobre as interfaces expostas.
    • Compreende os requisitos de integração e, se houver problemas potenciais — como a necessidade de uma mudança em um endpoint ou se um requisito é inviável — alerta proativamente a equipe.
    • 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: Revisar o licenciamento e os direitos do Jitterbit e o processo para solicitar direitos.
• Arquitetura Harmony: Considere estes pontos sobre a arquitetura Harmony:
  • Se agentes privados forem usados, priorize a instalação da arquitetura técnica e a conectividade com os endpoints, principalmente para desenvolvimento.
  • Se estiver trabalhando com sistemas locais, há muitos passos que podem levar tempo para serem concluídos, como aquisição de hardware, instalação de agentes privados, conectividade de rede, credenciais de usuário de integração e o ciclo de testes. Como isso pode envolver múltiplos grupos, inicie isso 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 não-desenvolvimento, então conclua essa etapa assim que for razoável.
• Membros do Harmony: Certifique-se de que os recursos de desenvolvimento sejam adicionados à organização Harmony com permissão de Admin (veja organizações Jitterbit).
• APIs do Gerenciador de API: Se APIs forem usadas, revise as dependências. Verifique a URL padrão da API. Se o cliente começou a usar um teste, é possível que a URL padrão ainda inclua a palavra "teste". Escale para o licenciamento do Jitterbit para que isso seja removido antes de construir quaisquer 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 anteriormente, a integração possui 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 aguardar a configuração dos objetos do endpoint.

No segundo caso (autônomo), 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 de projeto começa com os blocos de construção básicos e, em seguida, itera por cada cenário. A seção de UAT (Teste de Aceitação do Usuário) pode ser adiada até que todos os cenários tenham alcançado um ponto de prontidão.

Coleta de requisitos e desenvolvimento

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

Abordagem geral

A interface de desenvolvimento de baixo código e gráfica da Jitterbit (Integration Studio) se presta a um modelo iterativo. Essa abordagem não é em cascata, onde todos os requisitos são documentados antes do início do desenvolvimento. Esses passos-chave descrevem o modelo iterativo geral:

• Comece com os cenários de dados mestres. Como a abordagem é iterar rapidamente por um ciclo de definir-construir-testar, precisamos ter os endpoints preenchidos com dados mestres antes de trabalhar com dados transacionais.

• Entenda quais sistemas são SOR (Sistemas de Registro) e quais são SOE (Sistemas de Engajamento):

  • SOR (Sistemas de Registro): A fonte autoritativa 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.

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

  • Normalmente, as chaves de dados mestres do SOR são armazenadas no SOE para facilitar as atualizações de volta ao SOR. Por exemplo, se o SAP é o SOR e o SFDC é o SOE, então os números de clientes do SAP sã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 lidar com essa área desde o início.

Este diagrama mostra um exemplo usando o Salesforce como o SOE (Sistema de Engajamento) e o SAP como o SOR (Sistema de Registro), em um fluxo de dados mestres unidirecional com uma gravação de volta.

Ao lidar com atualizações de dados mestres bidirecionais, reconheça que isso 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 separadas dos usuários de negócios e chaves compartilhadas mútuas.
• Frequentemente, as regras de negócios para dados mestres não são as mesmas nos pontos finais, e ou a camada de integração precisa acomodá-las, ou os pontos finais 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 em nível de campo. Esses mapeamentos são necessários tanto pelos recursos de desenvolvimento do Jitterbit quanto pelos SMEs dos pontos finais.

O cliente pode estar acostumado a olhar os sistemas do ponto de vista da interface do usuário e pode não conseguir produzir mapeamentos com base no ponto de vista dos esquemas. Nesse caso, obtenha os esquemas na planilha de mapeamento, se possível. Isso pode exigir a ajuda do SME, documentação online ou o uso do Jitterbit iPaaS para se conectar ao ponto final e extrair os esquemas.

Se o mapeamento for direto, você pode fazer o mapeamento "ao vivo" usando o Jitterbit iPaaS para puxar os esquemas do ponto final para 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, busque construir a integração no Jitterbit iPaaS e testar o mais rápido possível para identificar quaisquer bloqueios.

À medida que o cliente trabalha na planilha de mapeamento, preste atenção especial a quais mapeamentos serão mais difíceis. A transformação é onde a coisa acontece, ou seja, é 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, uma vez que há um alto multiplicador de tempo para esses. Mapeamentos fáceis podem levar apenas minutos, enquanto mapeamentos complexos podem levar dias, então procure por essas situações e priorize:

• Consultas a sistemas externos: Para alguns sistemas, pode ser necessário buscar valores executando consultas. O perigo aqui é o impacto no desempenho: esteja ciente de que a transformação é executada em uma base por registro. Se estiver processando 200 registros, e a transformação estiver fazendo uma consulta 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, realizando assim uma única consulta.

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

  

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

  

Frequentemente, para fazer progressos rápidos em mapeamentos complexos, os SMEs dos endpoints precisam ser reunidos para discutir os requisitos, o que pode até exigir a contribuição dos negócios e pode levar à personalização do endpoint, tudo isso pode atrasar o projeto como um todo. É de vital importância identificar requisitos de integração complexos o mais rápido possível e esclarecer dependências rapidamente para manter o projeto avançando.

Desenvolvimento

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

• Conectar os endpoints.
• Identificar e implementar cenários simples, particularmente se forem dados mestres.
• Para integrações complexas, mesmo que não estejam completamente mapeadas, tomar medidas para expor os métodos de integração em uma transformação.
  • Esquemas (geralmente) se aplicam apenas ao lidar com bancos de dados e serviços web.
  • Ao lidar com arquivos, eles podem ter um formato hierárquico, que deve ser construído manualmente no Jitterbit. Isso pode ser trabalhoso, então comece isso cedo.
  • Para endpoints de banco de dados, será mais eficiente construir visões do que fazer o projeto de integração juntar tabelas. Uma procedure armazenada pode ser uma abordagem melhor do que realizar atualizações complexas.
  • Ao trabalhar com conectores de endpoint, use os assistentes do Jitterbit iPaaS e certifique-se de que todos os objetos em escopo estão 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 revisar 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 de IDoc SAP usa abreviações em alemão. Alguém Sprechen Sie Deutsch?"
• Não negligencie revisar o esquema de resposta (se for um serviço web), particularmente em relação a como os erros são tratados. 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 acompanhar os marcos relacionados a cada cenário. Este é um exemplo de planilha usada para acompanhar marcos-chave 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, trate a resposta. Não busque a perfeição. O objetivo é mover dados de teste simples do ponto A para o ponto B e, em seguida, passar para o próximo cenário. Depois, itere o desenvolvimento do cenário de integração, levantando bloqueios até que o cenário principal de sucesso, bem como os cenários de erro, tenham sido desenvolvidos e testados unitariamente.

O primeiro conjunto de integrações será aquele que enfrentará mais problemas, como conectividade, permissões, campos ausentes, etc. Portanto, quanto mais rápido chegarmos a esse ponto e resolvermos os bloqueios, melhor. Não estamos buscando a perfeição logo de cara.

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

Se houver um bloqueio menor, documente-o, atribua a resolução à pessoa certa e passe para outro cenário. Novamente, o objetivo é encontrar rapidamente as armadilhas para que possam ser resolvidas, e essa responsabilidade geralmente é do cliente e/ou do SME.

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

Reutilização

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

• Scripts
  • Funções personalizadas inteiras podem ser construídas e chamadas a partir de muitas operações. A regra geral é que, se você tiver que escrever o mesmo script duas vezes, transforme-o em um script chamável.
• Fontes e Alvos
  • Passe variáveis globais e/ou do projeto em vez de codificar diretamente coisas como caminhos de arquivos ou hosts FTP.
  • Use uma variável global como um espaço de trabalho intermediário em vez de fontes e alvos específicos da operação.
• Operações
  • Operações de tarefa única podem ser construídas uma vez e usadas muitas vezes, particularmente 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ções (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 negligenciado diz respeito ao registro e ao 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 Jitterbit iPaaS faz registro de operações de forma nativa.
• É fácil registrar dados adicionais, o que é muito útil para solução de problemas.
  • Aqui é onde o cliente pode perceber que seus cenários de integração precisarão de 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. 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 falha técnica, 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 depois.
• O Integration Studio pode usar email com bastante facilidade, onde o serviço de email é tratado como um endpoint para o serviço de email do cliente, usando as notificações por email do Integration Studio. Embora isso geralmente seja fácil de configurar, essa etapa não deve ser deixada para o final.
• O Jitterbit Management Console pode ser usado para configurar notificações adicionais relacionadas à organização.

Para informações detalhadas, consulte o tech talk sobre melhores práticas de tratamento de erros e a página de Alertas.

Tratamento de regras de negócios

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

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

A arquitetura ideal de middleware tem como premissa que a camada de integração deve ser o mais enxuta possível, focando em suas forças: transformação de dados, processamento de cenários e orquestração, conexão de endpoints e registro e alerta. Adicionar regras de negócios complicadas apenas prejudicará a perfeição dessa arquitetura, espalhando o suporte às regras de negócios pelas fronteiras dos endpoints. Ou seja, se uma regra de negócios mudar, ela não muda apenas na aplicação; muda também no middleware. Além disso, como o middleware é confuso, turvo e místico, a manutenção das regras é exaustiva.

A realidade se impõe de forma rude, já que o Jitterbit iPaaS precisa trabalhar com o que as aplicações 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, ano fiscal é calendário, se país = Reino Unido, ano fiscal é abril - março")
• O cenário de integração é orientado a dados ("se a ordem de trabalho contém linhas usando terceiros, processe essa linha como uma entrada de AP, caso contrário, atualize como uma ordem de serviço")

Sim, tudo isso poderia ser tratado 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 mudar e manter do que o projeto de integração.

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

• Externalizar sempre que possível. Por exemplo, ter dados em uma tabela onde possam ser mantidos por um usuário.
• Usar variáveis de projeto. Estas são expostas no Jitterbit Management Console junto com documentação específica. O principal caso de uso é para credenciais de endpoint específicas do ambiente, mas também podem ser usadas para direcionar a lógica de orquestração e condições de consulta.
• Adicionar registro detalhado personalizado 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 Jitterbit é o cavalo de batalha da integração. O Integration Studio não executa realmente nenhum processo de operação. Tudo acontece em um agente Jitterbit. Uma decisão chave inicial é que tipo de agente usar: privado ou em nuvem (veja agentes Jitterbit).

Se alguma dessas condições for verdadeira, então o projeto deve ser executado em um agente privado:

• Um endpoint está atrás do firewall do cliente. Isso pode ser uma aplicação ou um compartilhamento de rede.
• Um conector ou driver é necessário e não está disponível nos agentes em nuvem. Por exemplo, o driver do Excel está disponível apenas em agentes privados.
• Os requisitos de segurança do cliente são tais que nenhum dado é 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 do cliente de adquirir hardware de servidor e instalar o software do agente Jitterbit. No entanto, independentemente de você usar agentes em nuvem ou privados, ainda é 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 um número de ambientes, que geralmente são configurados seguindo as categorias padrão do ciclo de vida do desenvolvimento de software (desenvolvimento, qualidade, homologação, produção, suporte, etc.). A ferramenta de migração do 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 nem é mais resiliente. Um ambiente é praticamente igual a qualquer outro.

• Um ambiente Harmony pode ser usado de várias 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 de Harmony para o 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 abriga os agentes privados, ele 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 fail-over. Basta adicionar um agente a um grupo, e o agente automaticamente se torna parte de um cluster de servidores.

Para deixar claro, ao executar uma operação em um grupo de agentes com múltiplos agentes, apenas um agente está executando essa operação. A operação não é dividida e executada entre todos os agentes do grupo. Adicionar agentes a um grupo não fará (geralmente) com que as operações sejam 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 espalhar a carga entre múltiplos agentes é uma boa ideia.

Para iniciar 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 à medida que o projeto avança (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 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 a integração será acionada?

Basicamente, existem duas maneiras: uma abordagem em lote, como por meio de um cronograma, ou acionada por um evento, como por meio de uma API.

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

• Embora o Jitterbit suporte uma função de agendamento, a maioria dos processos em lote requer um processo de busca de dados com base em uma "data de última modificação", o que exige scripting personalizado para recuperar a última vez que a operação foi executada, decidir se a operação foi bem-sucedida e, em seguida, atualizar o repositório de timestamps. Ao longo do caminho, você lida com fusos horários de endpoints potencialmente diferentes, horário de verão e formatos de data. Não se esqueça: consulte 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 cronogramas de acordo com o plano do projeto. Nenhum desses desafios é enorme, mas claramente um ônus de responsabilidade de desenvolvimento e gerenciamento está sendo colocado na camada de integração.

• Compare em lote com orientado a eventos: a operação é executada apenas quando chamada pelo endpoint. Sem cronogramas, sem timestamps, sem fusos horários. A responsabilidade está claramente no endpoint.

• O principal mecanismo de processamento orientado a eventos do Jitterbit iPaaS é por meio das APIs do API Manager. Embora haja um custo de licença mais alto, vale muito a pena.

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

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

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

Cliente: O mais rápido possível.

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

Cliente: Não, eu 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á novos pedidos?

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á sobrecarregando o sistema de pedidos, onde a maior parte do tempo não há dados para processar. Você terá muitos ciclos desperdiçados, e vasculhar os logs de operação será um problema. Se sua necessidade de negócio é realmente mover dados o mais rápido possível, então você precisa usar uma API. Além disso, há uma série 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 sob controle.

Observe estas considerações para o uso de 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, em seguida, atualize imediatamente o destino.
  • 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ê recebe 10.000. O Jitterbit fará seu trabalho e iniciará quantas threads o servidor puder suportar e enfileirará o restante do tráfego de entrada, começando 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 da API recebidos antes de processá-los no destino.
• As APIs são licenciadas independentemente dos ambientes. Portanto, 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 transferido para um ambiente de QA antes do UAT, ou os testes são realizados em um ambiente de desenvolvimento e o projeto é então transferido para um ambiente de produção.

• Se possível, não transfira para o próximo ambiente superior até que o projeto esteja quase completo. Uma vez que a migração acontece, você precisa lembrar de transferi-los para outros ambientes.

• Evite fazer alterações em um ambiente "superior" para resolver rapidamente um problema, pensando que você sincronizará os ambientes mais tarde. Em vez disso, faça a correção no ambiente "inferior" e transfira-a. Não há uma maneira infalível de identificar diferenças granulares entre projetos, então é fácil perder o controle das mudanças.

Teste de aceitação do usuário (UAT)

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

Esta fase pode ser um processo tranquilo ou muito intenso. Isso realmente depende da qualidade das etapas anteriores. Mantenha estas dicas em mente durante a fase de UAT:

• Esteja preparado para reagir rapidamente à medida que surgem problemas. Se você fez seu trabalho bem, a maioria dos problemas será relacionada a dados, não técnica. Portanto, certifique-se de que os SMEs do endpoint estejam disponíveis para 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 em produção fará isso 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 enquanto o problema de integração é corrigido, os dados não são e se tornam uma questão recorrente nos testes.

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

• À medida que o tempo permitir, comece 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ê puder realizar ou que sejam permitidos.

Pós-produção e monitoramento

UAT concluído! Aprovação do usuário feita! É hora de acionar este foguete!

Nesta fase, a migração final para a produção deve estar completa. Se você estiver usando agendamentos, esteja ciente de que pode transferi-los para a produção e desativá-los no Jitterbit Management Console. A partir daí, pode caber ao cliente ativar os agendamentos.

Espere se reunir com o cliente periodicamente para garantir que tudo esteja correndo 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.