Ir para o conteúdo

Melhores Práticas para Design Studio

Introdução

Este documento tem como objetivo servir como um guia para usar o Harmony com o Design Studio, o aplicativo de design de projeto baseado em desktop da Jitterbit. Para melhores práticas usando o Cloud Studio, a versão baseada na web do aplicativo de design de projeto do Jitterbit, consulte Melhores práticas do Harmony.

Este documento não pretende ser abrangente ou cobrir todos os cenários de integração. Em vez disso, ele fornece orientação para cenários de integração comuns e recomenda as melhores escolhas no uso das muitas ferramentas disponíveis para um usuário Jitterbit.

Esta página é melhor lida depois que você estiver familiarizado com o Jitterbit: você passou pelo Comece página, concluiu a Jitterbit University cursos, e talvez tenha concluído um projeto de integração por conta própria. Nesse ponto, você saberá os conceitos e termos básicos usados no Jitterbit, e entenderá o que o Jitterbit quer dizer com projetos, operações, fontes, alvos, scripts e implantação.

Este documento é um resumo dos recursos disponíveis através do Harmony 9.9. A partir de Primavera de 2019, o Cloud Studio está disponível para uso no lugar do desktop Design Studio aplicativo para design de projeto. As principais diferenças são descritas em Visão geral do Cloud Studio para usuários do Design Studio.

Veja os Recursos adicionais abaixo para links para vídeos e outros documentos que expandem as melhores práticas com Jitterbit.

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

O acesso ao suporte 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 Jitterbit. O suporte Jitterbit descreve instruções especiais para situações de queda de produção a fim de escalar problemas sensíveis ao tempo.

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

Este site de documentação (Jitterbit Documentation) e nosso site de documentação para desenvolvedor (Jitterbit Developer Portal) contém mais de 3.600 URLs exclusivos de material técnico.

Atualizações de Produtos Jitterbit

As atualizações do Harmony são lançadas com frequência (consulte Cronograma de lançamentos). Mesmo uma versão menor contém novos recursos e melhorias, além de correções de bugs.

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

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

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

Organização e Design do Projeto

Reutilização

Reutilização do Projeto

Um cenário típico para reutilização de um projeto envolve o desenvolvimento de um projeto "padrão" com o uso extensivo de variáveis globais e — especialmente — variáveis de projeto. Itens configuráveis — como credenciais de endpoint, mapeamentos de campo opcionais, endereços email, nomes de arquivo — podem ser expostos como variáveis de projeto. O projeto "padrão" é implantado em vários ambientes e, usando o Management Console, as variáveis de projeto para cada ambiente são preenchidas.

Reutilização de Origem/destino

Embora fontes e destinos de arquivo sejam frequentemente usados em operações, um novo par fonte/destino não precisa necessariamente ser construído para cada operação. Como fontes e destinos de arquivo aceitam variáveis globais para caminho e nomes de arquivo, fontes e destinos para operações semelhantes podem ser construídos uma vez e conduzidos por meio de variáveis globais. Por exemplo, suponha que os objetos "Fonte" e "Destino" sejam criados e no campo de nome de arquivo esteja [filename]. O $filename a variável pode ser definida em qualquer lugar antes que o alvo seja escrito e será usada.

Isso se aplica a bancos de dados, compartilhamento de arquivos, site FTP, arquivo local e fontes e destinos HTTP.

Reutilização de Script

scripts independentes que executam uma função específica, como executar uma pesquisa em um banco de dados ou fornecer um resultado de uma série de argumentos, podem ser candidatos à reutilização, principalmente se usados em várias operações.

Por exemplo, se um script usa o DBLookup() função em relação a uma tabela de banco de dados, e esta é uma função que é usada em toda a integração, então um script autônomo (separado de uma operação) pode ser construído. Usando o ArgumentList() função ou variáveis globais simples, ela pode aceitar argumentos e retornar um resultado. Como cada cadeia de operação é um escopo diferente, o mesmo script pode ser chamado com segurança de várias operações simultâneas.

Nota

Se você armazenar seus projetos em um compartilhamento de arquivos, as alterações feitas em um projeto que são somente da interface do usuário (por exemplo, você reorganiza objetos em uma visualização) não são preservadas quando você reabre o projeto.

Como resultado, o Jitterbit não recomenda armazenar projetos em um compartilhamento de arquivos porque:

  • As alterações na interface do usuário (arranjo de objetos) não são preservadas ao salvar um arquivo
  • O desempenho sofre: carregar e salvar um projeto pode ser lento devido à falta de cache
  • Outros usuários na rede podem substituir as alterações que estão sendo feitas em um projeto devido à falta de bloqueios de arquivo

Organizar as Operações em um Projeto

O Design Studio fornece pastas de operação e classifica as operações em ordem alfabética ao reabrir um projeto. Ao usar um esquema de numeração ao nomear operações e pastas, o fluxo de integração fica mais claro e é mais fácil diagnosticar e resolver problemas.

Exemplo: suponha que há dois fluxos de integração; um para Customer Master e um segundo para Item Master, cada um com duas operações. Duas pastas, "Customer Master" e "Item Master", podem ser criadas no Design Studio. Na primeira pasta, as operações podem ser chamadas de "CM001 Get Customer" e "CM002 Update Customer". Na segunda pasta, as operações podem ser chamadas de "IM001 Get Items" e "IM002 Update Items":

anexo

O log de operação pode então mostrar facilmente as etapas na cadeia de integração e se alguma etapa foi perdida. Ao clicar com o botão direito do mouse em uma pasta no Design Studio, a lista de operações exibe apenas as operações de uma pasta. Uma estrutura de organização e nomenclatura consistentes facilitam para alguém novo em um projeto entender rapidamente o fluxo básico de operação.

Gerenciar Condições de Corrida ao Usar Operações Assíncronas

Ao usar o RunOperation() função em seu modo assíncrono, as operações são executadas sem retornar o controle ao chamador. 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 é encadeada à operação B que lê a mesma tabela (ambas são síncronas), nenhuma condição de corrida é encontrada. Mas se a operação A for chamada de forma assíncrona seguida imediatamente pela operação B, B pode executar antes que A seja concluída.

Credenciais de Endpoint

Use um ID de sistema com permissões de administração como credenciais de endpoint, em vez de um ID de nível de usuário. IDs de usuário normalmente expiram ou precisam ser desabilitadas quando o usuário sai da empresa.

Ao usar variáveis de projeto (cujos valores podem ser ocultados) para gerenciamento de credenciais, o Jitterbit Admin não precisa inserir credenciais de produção. Isso pode ser feito por um usuário por meio do Management Console. Essa abordagem pode ser usada para credenciais email, se necessário.

Manipulação de API

A plataforma Harmony API deve ser usada no lugar de endpoints HTTP. Os endpoints HTTP eram uma maneira de lidar com chamadas de entrada de baixo tráfego e exigiam que portas de rede específicas fossem abertas, o que muitas empresas hoje consideram um sério risco de segurança.

A plataforma Harmony API é projetada para desempenho de alto volume, realiza registro detalhado, implementa medidas de segurança comuns e tem uma interface de design simples de usar que faz parte do portal Harmony. Nenhuma porta de rede para lidar com tráfego de entrada precisa ser configurada.

A API Harmony deve ser usada para padrões de integração em tempo real/orientados por eventos. Por exemplo: o Endpoint A tem a capacidade de chamar uma API, como Salesforce, usando mensagens de saída. A API Harmony pode ser rapidamente implementada e vinculada a uma cadeia de operações.

A abordagem preferida para responder a uma chamada é fazê-lo o mais rápido possível. Se o design de integração for tal que as operações subsequentes levem um tempo significativo para responder, há um risco de timeout, ou o risco de outras chamadas de entrada sobrecarregarem a capacidade de resposta do endpoint de destino.

Se o endpoint de origem estiver fazendo muitas chamadas por minuto, e o gateway do endpoint de destino puder lidar apenas com um certo número de conexões, é possível que o endpoint de destino não consiga escalar para lidar com as solicitações. Nesse caso, responder de forma assíncrona pode ser a abordagem preferida. Ou seja, a resposta é feita imediatamente, e o conjunto de dados do endpoint de destino é enviado por meio de uma chamada para a API da origem.

Dados de Integração Persistentes

Há muitos cenários em que ser capaz de armazenar dados "na nuvem" pode ser útil. O Jitterbit fornece vários métodos: variáveis de projeto, funções de cache na nuvem e armazenamento temporário.

Variáveis do Projeto

Variáveis de projeto são variáveis estáticas pré-inicializadas (semelhantes às "constantes" do projeto) que podem ser editadas no Design Studio ou no Management Console.

Um exemplo de uso de variáveis de projeto é para credenciais de endpoint. Ao usar variáveis de projeto, diferentes ambientes de endpoint (que geralmente têm credenciais diferentes) podem ser aplicados a diferentes ambientes Jitterbit e editados por meio do Management Console. Isso permite um processo de negócios em que um usuário com direitos do Management Console pode alterar credenciais sem precisar de acesso ao Design Studio.

Um segundo exemplo é usar variáveis de projeto para manter sinalizadores usados pela lógica de integração que podem personalizar o comportamento da integração. Se um único projeto for desenvolvido, mas usado para diferentes endpoints, uma variável de projeto booleana (como "Send_PO_number") pode ser verificada pela lógica da transformação para o campo do número do PO. Se o valor da variável do projeto for falso, então o UnMap() comando poderia ser usado para "desligar" esse campo.

Funções de Cache em Nuvem

Funções de cache em nuvem (ReadCache() e WriteCache()) são espaços de dados atribuíveis que estão disponíveis em todos os projetos e ambientes. Um valor armazenado em cache é visível para todas as operações em execução no mesmo escopo até que ele expire, independentemente de como essa operação foi iniciada ou em qual agente ela é executada. Ao armazenar dados em cache no Harmony, em vez de depender de armazenamentos de dados locais ou específicos do agente, os dados podem ser compartilhados entre operações separadas e entre projetos.

Usos adicionais do cache em nuvem incluem:

  • Os dados podem ser compartilhados entre operações assíncronas dentro de um projeto.
  • Erros que são gerados em diferentes operações podem ser armazenados em um cache comum. Ao usar isso para acumular resultados de operação, alertas mais abrangentes podem ser criados.
  • Os tokens de login podem ser compartilhados entre operações.

Gerenciar Armazenamento Temporário

O armazenamento temporário é frequentemente usado em operações de integração. Isso é diferente de Arquivos Locais (fontes ou alvos), que só pode ser usado em agentes privados. Tenha essas diretrizes em mente, particularmente ao trabalhar para usar um ambiente clusterizado:

  • Torne seu projeto "à prova de atualização" e use armazenamento temporário de tal forma que mover de um único servidor para um ambiente em cluster não exija refatoração.

  • O armazenamento temporário é gravado no diretório temporário do sistema operacional padrão no agente que está executando o trabalho. No caso de um único agente privado, então é o diretório temporário padrão do host do servidor desse agente privado. Se você estiver usando mais de um agente privado, então é o diretório temporário padrão do hospedar do servidor para qualquer agente que esteja fazendo o trabalho. Se estiver usando um agente de nuvem (que são agrupados), então é o diretório temporário padrão do hospedar do servidor do agente de nuvem específico.

  • Por padrão, o armazenamento temporário é excluído após 24 horas por um serviço de limpeza Jitterbit. No caso de agentes de nuvem, isso pode ser imediatamente.

  • Uma abordagem simplista é construir um alvo, dar a ele um nome exclusivo e então usar "Copiar para Nova Fonte" para criar uma fonte usando o mesmo nome de arquivo. O alvo e as fontes são realmente independentes e dependem do uso do mesmo nome de arquivo para sincronizar leituras e gravações.

  • Em um ambiente de agente em cluster (agentes privados ou em nuvem), desde que as operações que usam o armazenamento temporário sejam vinculadas (encadeadas), todas as leituras e gravações de armazenamento temporário ocorrerão no mesmo hospedar do servidor. Mas, se a cadeia de operação A gravar no armazenamento temporário "myfile" e a cadeia de operação B ler o armazenamento temporário "myfile", a ação de leitura pode ser inconsistente porque pode não ler o mesmo hospedar do servidor que a cadeia A.

  • Para alvos, o padrão é sobrescrever o arquivo. Isso pode ser alterado com a opção "Append to File". Normalmente, isso requer que, após a fonte ser lida, o arquivo seja excluído ou arquivado. Uma maneira simples de fazer isso é escolher "Delete File" ou "Rename File" na fonte.

  • Palavras-chave de nome de arquivo estão disponíveis que pode ser usado ao criar um nome de arquivo.

  • Um arquivo em armazenamento temporário pode ser lido rapidamente construindo um script com o ReadFile() função, como ReadFile("<TAG>Sources/test</TAG>"). Tenha em mente que isso funciona de forma confiável somente se houver um único agente privado.

Veja Variável global versus Armazenamento temporário para uma comparação desses dois tipos e recomendações sobre quando cada um é apropriado.

Roteiro

Quando Usar Script

Embora o Jitterbit forneça uma capacidade de script robusta, o script deve ser usado somente quando necessário. Se houver uma escolha entre usar script ou um método padrão, opte por usar o método padrão. Um "método padrão" é um método fornecido pela interface do usuário do Jitterbit Design Studio para realizar uma tarefa.

Um exemplo seria a organização de execuções de operação. A interface de usuário do Design Studio do Jitterbit permite que você crie "cadeias de operação " vinculadas por caminhos de sucesso e falha. Como alternativa, é possível construir operações autônomas e, em seguida, vinculá-las usando scripts e o RunOperation() função. A menos que haja requisitos técnicos que impulsionem essa abordagem (como o uso de caminhos assíncronos ou opcionais), é preferível confiar no método de interface de usuário do Jitterbit para vincular diferentes operações.

O script é geralmente melhor em dois lugares: dentro do Formula Builder em transformações e em scripts autônomos. Se o mesmo código estiver sendo usado em mais de uma transformação, considere mover esse código para um script autônomo e chamá-lo de dentro de cada transformação usando RunScript().

Convenção de Nomenclatura para Variáveis

O Jitterbit tem quatro tipos de variáveis:

  • variáveis locais
  • variáveis globais
  • variáveis do projeto
  • Variáveis Jitterbit

Variáveis locais e globais são criadas em scripts Jitterbit; variáveis de projeto são definidas no Jitterbit Design Studio; variáveis Jitterbit são predefinidas no sistema Jitterbit.

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 todas as letras minúsculas ou uma palavra inicial, como "return" ou "myVariable".

Variáveis globais, como seu escopo é maior (uma variável global está disponível para ser referenciada nas mesmas operações ou scripts abaixo dentro de uma cadeia de operação ), devem usar uma convenção de nomenclatura consistente para evitar reutilização inadvertida. Por exemplo, usando vários componentes para um nome de variável, separados por pontos, você pode seguir um padrão como:

first.second.third[.fourth]

onde:

  • Primeiro componente: Especificador org
  • Segundo componente: Um tipo, como id, erro, data, arquivo, token, carimbo de data/hora, fuso horário, sinalizador, email, guid, usuário, externalid, val (para um valor diverso), arr (para matriz) ou um tipo de endpoint, como sfdc
  • Terceiro componente: Nome da variável
  • Quarto componente: Nome de subvariável opcional

Combinando esses componentes e assumindo que o nome da sua organização é example, nomes de variáveis podem ser:

  • $example.arr.names
  • $example.sfdc.success.message

Como as variáveis de projeto são visíveis por meio do Management Console e são geralmente usadas para configurar o comportamento de integração, nomes mais amigáveis podem ser usados. Como um nome de variável de projeto não pode conter espaços, sublinhados podem ser usados em vez disso. Por exemplo: "Start_Date" e "Include_Assemblies".

Seja qual for a convenção que você escolher usar, recomendamos codificá-la e documentá-la para que todos os membros da equipe possam usá-la consistentemente em todos os projetos.

Aviso

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

  • $example_arr_names
  • $example_sfdc_success_message

Ambientes e Implantações

Jitterbit permite metodologias de ciclo de vida de desenvolvimento de software por meio do uso de ambientes e opções de implantação.

Ambientes

No Harmony, o recurso de ambiente pode ser usado para configurar ambientes de produção e não produção.

Por exemplo, suponha que um ambiente "Dev" e um "Prod" sejam configurados no Management Console e ambos sejam atribuídos ao grupo de agentes A. O Projeto 1 é desenvolvido no ambiente"Dev". O Jitterbit fornece um recurso de "Migração" que copiará esse projeto para o ambiente"Prod", após o qual as credenciais do endpoint são alteradas para as credenciais do endpoint "Prod". Outras origens e destinos também são alterados. Depois disso, todas as migrações de "Dev" para "Prod" excluem endpoints, origens e destinos, a menos que sejam novos.

Opções de Gerenciamento de Implantação

Existem várias opções para implantar projetos.

  • Implantação completa: Selecionar Ações > Implantar > Tudo pega o projeto inteiro e substitui o projeto na nuvem.

  • Backup do projeto: Ao escolher Ações > Implantar > Tudo, há uma opção para "Também armazenar um backup na nuvem". Antes de fazer grandes alterações em um projeto, selecione esta opção para ter um ponto de restauração salvo no Harmony.

  • Todos os itens novos e modificados: Esta opção está disponível em Ações > Implantar > Opções avançadas. Como o Design Studio mantém o controle de itens "sujos", isso implantar as alterações, bem como todas as dependências.

  • Um novo recurso é desabilitar a caixa de diálogo de progresso durante uma implantar (veja Preferências > Implantar), o que permite que implantações de itens individuais aconteçam em segundo plano.

Avisos de Versão

Ao implementar alterações em um projeto, se uma versão mais recente de um projeto tiver sido implementada, um aviso será exibido indicando que uma versão mais recente existe e identificando quem a implementou. O Jitterbit Admin tem a opção de sobrescrever o projeto. Em geral, em um ambiente multi-desenvolvedor, é preferível baixar o projeto atual da nuvem antes de fazer alterações.

Teste, Solução de Problemas e Registro

Use Recursos de Teste para Desenvolvimento de Integração Rapid

O Jitterbit pode habilitar o desenvolvimento rápido de integração e teste de unidade ao tornar visíveis os dados de integração reais durante o tempo de design. A vantagem óbvia é habilitar um processo de desenvolvimento iterativo ao mostrar os dados antes e depois das transformações de campo, em vez de construir a operação inteira, executá-la e inspecionar a saída. Isso é feito principalmente por meio da ferramenta Transformações, particularmente usando os recursos "Test Transformação" e "Run Operation".

Se os objetos a serem integrados forem conhecidos, um desenvolvedor experiente pode desenvolver uma integração rapidamente usando o Transformação Wizard e seu kit de ferramentas. Por exemplo, faça uma conexão com um banco de dados e, usando o Transformação Wizard, crie a operação e a transformação. Em seguida, execute uma "Run Operation" com a transformação aberta. Os dados serão exibidos na tela de transformação e os registros podem ser alternados. Isso mostrará instantaneamente os dados exatos que o Jitterbit receberá quando a operação for executada.

Se um campo exigir uma transformação, clique duas vezes no campo para abrir o Formula Builder e construir o script necessário. Ao usar o recurso "Test" no Formula Builder, a saída usará os dados de transformação e mostrará a saída exata que será gerada durante o tempo de execução.

Se a origem não estiver disponível, mas os dados de origem estiverem disponíveis em um arquivo (CSV, XML, JSON), o arquivo poderá ser importado para a ferramenta Transformações usando os recursos "Carregar dados de origem de amostra" e "Testar a Transformação".

Habilitar Solução de Problemas de Integração

Um conceito-chave para uma arquitetura de integração saudável é reconhecer que haverá questões levantadas pelo negócio 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 estar com defeito. É responsabilidade da 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, 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 será beneficiado ao disponibilizar essas informações como uma parte padrão da arquitetura de integração.

No Jitterbit, isso é suportado por recursos de registro e alerta.

Registro

O log de operação do Jitterbit capturará dados-chave por padrão, como tempos de execução de operação e mensagens de sucesso, falha ou cancelamento. Se houver falhas e o endpoint retornar informações de falha, o log as capturará.

Ao desenvolver uma integração, use o WriteToOperationLog() função nos mapeamentos e scripts para capturar dados-chave e etapas no processo. Isso normalmente é tão simples quanto: WriteToOperationLog("The id is: "+sourcefieldid).

Se capturar a saída inteira de uma transformação for desejado, isso pode ser feito construindo uma operação que leia a fonte, execute a transformação e grave em um arquivo temporário. Um script pós-operação pode ler o arquivo e gravá-lo no log de operação : WriteToOperationLog(ReadFile(<tempfile>)). Então a operação "real" pode ser realizada.

Os logs podem ser visualizados no Design Studio ou no Management Console. A vantagem do Management Console é que a equipe de suporte pode acessá-lo pelo navegador sem precisar de um cliente do Design Studio em seu desktop.

Os dados nos logs podem ser pesquisados, o que permite o cenário em que a sequência exata envolvida na solução de problemas é um valor conhecido e é registrado.

Frequentemente, as APIs têm uma mensagem de resposta de sucesso ou não sucesso que é informativa. Dê o passo extra de capturar essas informações no log.

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

Alerta

Frequentemente, os resultados da integração não só precisam ser registrados, mas também precisam ser escalados. O Jitterbit fornece integração email, que pode ser facilmente anexada a operações e caminhos de sucesso/falha ou chamada de scripts.

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

Recursos Adicionais

Estas seções e páginas na documentação estão relacionadas às melhores práticas e serão de interesse.

Palestras Sobre Tecnologia

Jitterbit Tech Talks são apresentações em vídeo que abrangem áreas de interesse para usuários de todos os níveis:

Documentação

A documentação do Jitterbit tem as melhores práticas incluídas em nossas páginas sobre o uso do Jitterbit:

Segurança

Padrões de Design e Exemplos

Criar Projetos

Registro

Gerenciar Projetos

  • Criando Novas Receitas
    Melhores práticas a serem seguidas ao criar Jitterpaks para uso com receitas do Citizen Integrator para Design Studio.
  • Metodologia de projeto de integração
    Itens essenciais que um gerente de projeto de um projeto de Design Studio deve saber, incluindo como organizar sua equipe, reunir e validar requisitos de forma clara e concisa e aproveitar os pontos fortes do Harmony para entregar um projeto de integração bem-sucedido.
  • Restaurar do backup na nuvem
    Melhores práticas sobre backup e restauração de projetos.
  • Configure um projeto de colaboração de equipe
    Melhores práticas para dar suporte a vários desenvolvedores trabalhando no mesmo projeto.

Agentes Privados

Usar APIs