Ir para o conteúdo

Melhores práticas do Jitterbit iPaaS

Introdução

Este documento serve como um guia geral para o uso da plataforma de integração como serviço (iPaaS) do Jitterbit. Ele fornece orientações sobre melhores práticas para cenários comuns de integração e recomendações sobre o uso das ferramentas disponíveis. Este documento não é abrangente e não cobre todos os cenários.

Este documento é destinado a usuários do Integration Studio, a versão baseada na web do aplicativo de design de projetos do Jitterbit. Para melhores práticas usando o Design Studio, o aplicativo de design de projetos baseado em desktop do Jitterbit, consulte Melhores práticas com o Design Studio.

As melhores práticas para o App Builder, o aplicativo do Jitterbit para criar aplicativos web e móveis, são cobridas separadamente.

Você já deve estar familiarizado com o Jitterbit iPaaS e o Integration Studio a partir dos seguintes recursos:

Nesse ponto, você deve conhecer os conceitos e termos básicos usados no Jitterbit iPaaS e entender o que queremos dizer com projetos, operações, endpoints, programação, transferência e implantação.

Consulte a seção Recursos adicionais no final desta página para links para vídeos e outros documentos que expandem essas melhores práticas.

Suporte, Gerentes de Sucesso do Cliente e documentação

O acesso ao suporte da Jitterbit está incluído como parte de uma licença de cliente Harmony. Quando surgirem dúvidas ou problemas técnicos, você pode obter assistência especializada do suporte da Jitterbit. A página de suporte da Jitterbit descreve instruções especiais para situações de interrupção de produção, a fim de escalar questões sensíveis ao tempo.

Você também pode entrar em contato com seu Gerente de Sucesso do Cliente (CSM) para perguntas relacionadas a licenciamento ou outros tópicos.

Este site de documentação (Documentação Jitterbit) e nosso site de documentação para desenvolvedores (Portal do Desenvolvedor Jitterbit) contêm mais de 3.600 URLs únicas de material técnico.

Para ajudá-lo a localizar material relevante, a caixa de pesquisa é pré-filtrada para limitar os resultados da pesquisa à seção da documentação que está sendo acessada no momento. Você pode pesquisar toda a documentação limpando o filtro de pesquisa. Para pesquisar frases específicas, coloque-as entre aspas duplas.

Receitas e modelos

O Marketplace fornece mais de 400 receitas e modelos prontos do Integration Studio para usar como base para designs de integração:

  • Uma receita de integração move dados em uma direção entre objetos em dois aplicativos ou sistemas.

  • Um modelo de processo acelera a execução de um processo de negócios específico usando numerosos objetos em múltiplos aplicativos ou sistemas. Os modelos de processo são projetados para reduzir o tempo de implantação em 50 a 80 por cento.

Atualizações de produtos Jitterbit

As atualizações de produtos Jitterbit são lançadas com frequência (veja o Cronograma de lançamentos). Mesmo um lançamento menor contém novos recursos e melhorias, além de correções de bugs.

Aplicativos da web acessados através do portal Harmony são atualizados automaticamente e sempre executam a versão mais recente lançada.

Atualizações do gateway de API em nuvem e do grupo de agentes em nuvem são aplicadas automaticamente. Para os grupos de agentes em nuvem, existem dois conjuntos: Produção e Sandbox. Este último conjunto é usado para testar a compatibilidade com pré-lançamentos do software do agente e não é um ambiente de desenvolvimento.

Aplicativos instalados localmente são atualizados baixando e executando um instalador:

É aconselhável manter-se atualizado com os lançamentos, especialmente aqueles que incluem atualizações de recursos.

Simplicidade no design de projetos e preferência por recursos

Durante o processo de design de um projeto de integração, você pode encontrar múltiplos métodos de implementação que podem resultar na mesma funcionalidade.

Embora frequentemente haja vantagens ou desvantagens em um método em relação a outro, dependendo do caso de uso da integração (conforme documentado), recomendamos sempre manter em mente o princípio orientador da simplicidade. Projetos que são projetados da forma mais simples possível geralmente têm maior longevidade e são muito mais fáceis para um externo se familiarizar caso uma mudança precise ser feita. Por outro lado, projetos excessivamente complexos podem ser mais difíceis de manter e transferir para outros durante uma transição de responsabilidades.

Para projetar projetos mais simples, recomendamos a seguinte ordem de preferência por recursos:

  1. Utilize recursos sem código sempre que possível, como projetar visualmente operações no canvas de design, agrupando componentes para ajudar a organizá-los, adicionando tags e comentários ao implantar, e publicando operações como APIs.
  2. Aproveite recursos de baixo código, como usar variáveis nas telas de configuração de componentes baseadas em assistente ou manipulando dados em nível de campo em um mapeamento de transformação usando uma função de script.
  3. Conforme necessário, implemente lógica mais complexa usando scripts escritos na linguagem Jitterbit Script.
  4. Somente quando um equivalente em Jitterbit Script não estiver disponível, implemente scripts em JavaScript.

Design de projeto e reutilização

Um cenário típico para reutilizar um projeto envolve o desenvolvimento de um projeto inicial com o uso extensivo de variáveis globais e, especialmente, variáveis de projeto. Itens configuráveis — como credenciais de endpoint, mapeamentos de campos opcionais, consultas parametrizadas, endereços de email e nomes de arquivos — podem ser expostos como variáveis de projeto. O projeto inicial também pode conter funções comuns, como tratamento de erros ou o uso de caches em todo o ambiente. O projeto inicial é exportado e, em seguida, importado em novos projetos para formar uma base consistente para o desenvolvimento.

Reutilização de endpoint

Endpoints, criados configurando uma conexão e atividades associadas usando conectores, são frequentemente utilizados em operações. No entanto, um endpoint único não precisa necessariamente ser construído para cada operação. Como as configurações de atividade aceitam variáveis para caminhos e nomes de arquivos, endpoints genéricos podem ser construídos uma vez e, em seguida, configurados dinamicamente usando variáveis globais e de projeto.

Por exemplo, suponha que uma conexão HTTP e uma atividade associada sejam criadas, e a configuração da atividade especifique um caminho definido por uma variável global, como $gv_http_path. Um script controlador pode ser usado para preencher o $gv_http_path conforme necessário.

Outro exemplo é uma atividade de Consulta de Banco de Dados com uma condição. Sua condição WHERE pode ser atribuída a uma variável global, como $gv_database_condition.

A maioria dos endpoints tem a capacidade de ser configurada usando variáveis.

Reutilização de script

Scripts autônomos scripts que realizam uma função específica, como retornar uma consulta de banco de dados ou calcular um resultado a partir de uma série de argumentos, podem ser candidatos à reutilização, particularmente se usados em múltiplas operações.

Por exemplo, se um script usa a função DBLookup contra uma tabela de banco de dados, e essa função é utilizada em todo o projeto, então um script independente (separado de uma operação) pode ser construído. Usando a função ArgumentList ou variáveis globais simples, o script pode aceitar argumentos e retornar um resultado. Como cada cadeia de operações é um escopo diferente, o mesmo script pode ser chamado com segurança de várias operações simultâneas.

Organização do projeto

Workflows são usados como um meio de organização do projeto. Um workflow normalmente contém operações relacionadas que processam dados do início ao fim: Criar Pedidos, Sincronizar Cadastro de Clientes, Processar Confirmações, etc. Processos que são comuns em diferentes workflows, como consultar um endpoint ou lidar com uma condição de erro de operação, podem ser mantidos em seu próprio workflow e referenciados por outras operações de workflow.

Você também pode criar grupos personalizados onde os componentes do projeto podem ser coletados para facilitar a referência.

As configurações do Designer de um projeto contêm a opção Numeração automática de operações na tela de design, que atribuirá automaticamente números às operações com base na posição de exibição da operação no designer do projeto. Esses números não são exibidos nos logs de operação. Se um esquema de numeração de operações for necessário, ele pode ser implementado incorporando a numeração ao nome da operação.

Gerenciar operações assíncronas

Ao usar a ferramenta Invocar Operação (Beta) ou a função RunOperation em seu modo assíncrono, as operações são executadas sem retornar o controle à função chamadora. O uso de operações assíncronas pode levar a condições de corrida.

Por exemplo, se a Operação A atualiza uma tabela de banco de dados e está encadeada com a Operação B, que lê essa mesma tabela (ambas são síncronas), não ocorrem condições de corrida. Mas se a Operação A for chamada de forma assíncrona, seguida imediatamente pela Operação B, então B pode ser executada antes que A termine.

Além disso, o número de chamadas assíncronas simultâneas deve ser gerenciado, pois o número de operações simultâneas em execução em um agente é limitado (veja a seção [OperationEngine] do arquivo de configuração do agente privado).

Credenciais de endpoint

Recomendamos usar um ID de sistema com permissões de administração para credenciais de endpoint, em vez de um ID de nível de usuário. IDs de usuário normalmente expiram ou precisam ser desativados quando um usuário deixa a empresa.

Ao usar variáveis de projeto (cujos valores podem ser ocultos) para gerenciamento de credenciais, um administrador da organização Harmony não precisa inserir credenciais de produção. Ao configurar as permissões de usuário apropriadas, um usuário pode aplicar as credenciais de produção através da página Projetos do Console de Gerenciamento.

Se estiver usando agentes privados, como alternativa ao uso do Console de Gerenciamento, variáveis globais podem ser gerenciadas usando a seção [PredefinedGlobalVariables] do arquivo de configuração do agente privado.

Persistir dados de integração

Ao construir integrações no Integration Studio, escolha uma abordagem de armazenamento de dados com base no tamanho dos seus dados e nos requisitos de persistência. Você pode usar variáveis, conectores de armazenamento e funções de cache.

Para uma explicação mais detalhada das abordagens, veja Considerações sobre armazenamento.

Variáveis

Use variáveis para passar valores, configurações e pequenas quantidades de dados entre componentes de integração. Escolha um tipo de variável com base no escopo:

Conectores de armazenamento

Esses conectores de armazenamento são projetados para armazenar e recuperar arquivos e grandes conjuntos de dados que precisam persistir além de uma única cadeia de operação:

Conector Persistência Limites de tamanho Melhor para
Variável Cadeia de operação 50 MB Arquivos pequenos e testes
Armazenamento Temporário Cadeia de operação 50 GB (nuvem) Arquivos grandes e processamento
Cloud Datastore (Beta) Até ser excluído TBD Tabelas de consulta e dados entre operações

Ao usar esses conectores, observe as seguintes considerações:

  • Variável: Desempenha melhor para pequenos conjuntos de dados. O desempenho degrada com arquivos maiores que 4 MB. Há risco de truncamento de dados acima de 50 MB. Variáveis são úteis para testes unitários e aumentam a reutilização ao criar um alvo e uma fonte comuns para operações encadeadas.

  • Armazenamento Temporário: Esses arquivos são gravados no diretório temporário padrão do agente. Ao usar um grupo de agentes privados com múltiplos agentes ou um grupo de agentes na nuvem, as operações que utilizam armazenamento temporário devem estar na mesma cadeia de operação para garantir que sejam executadas no mesmo agente. Em agentes na nuvem, os arquivos podem ser excluídos imediatamente. Em agentes privados, os arquivos são tipicamente excluídos após 24 horas.

  • Cloud Datastore (Beta): Este conector fornece uma solução persistente para pares chave-valor ou dados estruturados. É ideal para compartilhar tabelas de consulta ou dados de referência entre operações e projetos.

Cloud caching

Use as funções ReadCache e WriteCache quando precisar compartilhar dados entre projetos, ambientes ou operações assíncronas. O cache em nuvem é ideal para tokens de login, acumulação de erros e dados temporários que várias operações precisam acessar.

Scripting

Scripts escritos na linguagem Jitterbit Script ou JavaScript podem ser usados em quase qualquer lugar nas operações e dentro dos mapeamentos de transformação.

When to use scripting

As operações podem ser organizadas em cadeias de operações de duas maneiras: (1) vinculando operações usando condições On Success e On Fail com ações de operação, ou (2) usando um script controlador.

Em vez de usar ações de operação, um script controlador utiliza a função RunOperation para vincular operações usando um script.

Para capturar uma operação falhada, a função If pode ser usada em conjunto com RunOperation. Por exemplo: If(!RunOperation(<operation tag>),<condition>), onde a condição pode usar GetLastError para capturar o erro e pode optar por interromper todo o processo usando RaiseError, e/ou executar outro processo para acumular o texto do erro.

Um script controlador pode ser benéfico em situações como estas:

  • Para executar uma operação que depende de fatores externos, como variáveis de projeto ou dados.
  • Para chamar sub-operações de dentro de um loop, onde os dados são passados para a operação a partir de uma lista.
  • Para rastrear atividades da cadeia de operações. Por exemplo: (WriteToOperationLog("contagem de registros a processar: " + cnt), WriteToOperationLog("Iniciando operação de atualização em: " + Now()), WriteToOperationLog("Consulta ao banco de dados: " + sql), etc.)

Outras áreas onde a script é frequentemente utilizada são nos campos mapeados em transformações e em outros scripts independentes. Se o mesmo script estiver sendo usado em mais de uma transformação, considere configurar esse script como um script independente e chamá-lo de dentro de cada transformação usando RunScript.

Convenção de nomenclatura para variáveis

O Jitterbit iPaaS possui quatro tipos de variáveis:

Como o escopo de uma variável local é limitado a um único script, uma convenção de nomenclatura para elas pode ser muito simples, como letras todas em minúsculas ou uma palavra inicial, como return ou myVariable. Pontos não são permitidos em variáveis locais.

Variáveis globais, como seu escopo é maior (uma variável global está disponível para ser referenciada nas mesmas operações ou em operações subsequentes dentro de uma cadeia de operações), devem usar uma convenção de nomenclatura consistente para evitar confusão. Por exemplo, usando múltiplos componentes para um nome de variável, separados por pontos, você poderia seguir um padrão como este:

type.category.subcategory
Componente Descrição
type Uma abreviação curta identificando o tipo da variável, como pv (variável de projeto), gv (variável global), io (nome da fonte/alvo do endpoint), dict (dicionário), etc.
category Uma categoria lógica para a variável, como sfdc, shipearly, confirm, order, etc.
subcategory Uma subcategoria lógica para a variável, como purchase_orders, categories, ids, etc.

Combinando esses componentes, esses são os possíveis nomes de variáveis:

  • $pv_shopify_base_url
  • $dict_staples_po_line_items
  • $io_request
  • $gv_sfdc_workorder_id

Como as variáveis são organizadas em ordem alfabética em vários lugares da interface do usuário, organizá-las hierarquicamente ajudará na gestão e uso das variáveis.

Qualquer que seja a convenção que você escolher usar, recomendamos codificá-la e documentá-la para que todos os membros da equipe possam utilizá-la de forma consistente em todos os projetos.

Nota

Se você planeja usar variáveis globais do Jitterbit Script em um script de JavaScript, é importante usar sublinhados em vez de pontos:

  • $example_arr_names
  • $example_sfdc_success_message

Ambientes

O Jitterbit permite metodologias de ciclo de vida de desenvolvimento de software por meio do uso de ambientes. Você pode configurar ambientes de produção e não produção.

Por exemplo, suponha que um ambiente de Desenvolvimento e um ambiente de Produção estejam configurados no Console de Gerenciamento e ambos estejam associados ao mesmo grupo de agentes. Suponha que um projeto seja primeiro desenvolvido no ambiente de Desenvolvimento.

O Integration Studio possui um recurso de transferência que copiará esse projeto para o ambiente de Produção, após o qual as credenciais do endpoint são alteradas para as credenciais do endpoint de Produção usando variáveis de projeto. Outros endpoints de origem e destino também são alterados. Após a transferência inicial, quaisquer transferências adicionais do mesmo projeto de Desenvolvimento para Produção excluem a migração dos valores das variáveis de projeto, a menos que sejam novas variáveis de projeto.

Testes

O Jitterbit permite o desenvolvimento rápido de integrações e testes unitários ao tornar visíveis os dados reais de integração durante o tempo de design. A vantagem óbvia é permitir um processo de desenvolvimento iterativo, mostrando os dados antes e depois das transformações de campo, em vez de construir toda a operação, executá-la e inspecionar a saída. Os dados são tornados visíveis usando o recurso de visualização em uma transformação.

Após os dados de origem de exemplo serem importados ou gerados, a transformação mostrará a saída de quaisquer mapeamentos e scripts incorporados.

Solução de Problemas

Um conceito chave para uma arquitetura de integração saudável é reconhecer que haverá perguntas levantadas pela empresa sobre a precisão do trabalho de integração, particularmente quando discrepâncias aparecem nos dados do endpoint. A integração pode ou não ser a culpada. Cabe ao projeto de integração fornecer um alto grau de transparência para ajudar a resolver questões sobre a precisão dos dados.

Por exemplo, se os dados em um endpoint de destino parecem estar incorretos, então normalmente o suporte de integração é chamado para fornecer detalhes sobre quaisquer ações de integração, como horários, fontes, lógica de transformação, mensagens de sucesso ou falha, etc. O processo de solução de problemas se beneficiará ao tornar essas informações disponíveis como parte padrão da arquitetura de integração. No Jitterbit iPaaS, isso é suportado através de registro e alertas.

Registro

Registros de operação capturam dados chave por padrão, como tempos de execução da operação e mensagens de sucesso, falha ou cancelamento. Se houver falhas e o endpoint retornar informações de falha, então o log capturará essas informações.

Com relação às falhas, a resposta é usada para determinar o status. Por exemplo, se um código de status HTTP 400 ou mais for recebido em uma resposta, isso é considerado uma falha. Se a solicitação tiver um status de 200, mas a resposta contiver erros de dados, isso é tratado como um sucesso.

Ao desenvolver um projeto de integração, use a função WriteToOperationLog nos mapeamentos e scripts para capturar dados e etapas chave no processo. Isso geralmente é tão simples quanto: WriteToOperationLog("O id é: "+sourcefieldid).

Se capturar toda a saída de uma transformação for desejado, isso pode ser feito construindo uma operação que lê a origem, realiza a transformação e escreve a saída em um Variável ou Armazenamento Temporário em vez do endpoint de destino. Um script pós-operação pode ler a saída e registrá-la. Então a operação "real" pode ser realizada.

Os logs podem ser visualizados tanto na tela de log de operações do Integration Studio quanto na página de Operações em Tempo de Execução do Management Console. A página de Operações em Tempo de Execução do Management Console pode ser acessada pela equipe de suporte sem a necessidade de navegar até o projeto.

Os dados nos logs são pesquisáveis. Para filtrar apenas os logs que você precisa, você pode usar a sintaxe de pesquisa message=%\<seu texto>% tanto nos logs de operações do Integration Studio quanto do Management Console.

Frequentemente, as APIs têm uma mensagem de resposta informativa de sucesso ou não sucesso. Se o registro de depuração estiver habilitado para a API, o corpo da solicitação será capturado nos logs da API (que são distintos dos logs de operações).

Os logs de operações, incluindo mensagens de log detalhadas de agentes em nuvem e agentes privados, são retidos por 30 dias pelo Harmony.

Alerting

Frequentemente, os resultados da integração não apenas precisam ser registrados, mas também precisam ser escalados. As notificações por email podem ser facilmente anexadas a operações e caminhos de sucesso/falha ou chamadas a partir de scripts. Você pode, alternativamente, usar o conector Email para configurar uma atividade de envio de email como o alvo de uma operação.

Para informações adicionais, consulte Configurar alertas, registros e tratamento de erros.

Additional resources

Estas seções e páginas na documentação fornecem práticas recomendadas adicionais.

Tech talks

As tech talks do Jitterbit são apresentações em vídeo que cobrem áreas de interesse para usuários de todos os níveis:

Tech Talk Duração Data de Lançamento
API proxy 39:53 2019.01.09
APIs 49:22 2018.08.07
Integration Studio 43:53 2019.05.14
Complex project orchestration best practices 50:46 2018.10.16
Connector Builder 50:19 2019.07.16
Environments 1:04:22 2018.04.04
External credentials storage and management 46:58 2020.10.09
Error handling best practices 27:22 2018.03.13
Jitterbit best practices 1:04:38 2020.03.16
Logging best practices 1:03:02 2019.02.12
Open API Portal Manager 57:21 2019.11.05
Pass-through sources and global variables best practices 42:44 2018.12.05
Private agents best practices 42:43 2018.07.05
Process templates 43:27 2020.07.08
Project organization best practices 1:08:39 2018.06.08

Documentação

A documentação do Jitterbit inclui melhores práticas em nossas páginas sobre o uso dos produtos Jitterbit:

Segurança

Metodologia de projeto de integração

  • Metodologia de projeto de integração
    Itens-chave que um Gerente de Projeto para um projeto do Integration Studio deve conhecer, incluindo 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 de integração bem-sucedido.

Como fazer

Registro

Agentes