Ir para o conteúdo

Melhores práticas para o Jitterbit Design Studio

Introdução

Este documento tem como objetivo servir como um guia para usar o Harmony com o Design Studio, a aplicação de design de projetos da Jitterbit baseada em desktop. Para melhores práticas usando o Integration Studio, a versão web da aplicação de design de projetos da Jitterbit, consulte as melhores práticas do Harmony.

Este documento não tem a intenção de ser abrangente ou cobrir todos os cenários de integração. Em vez disso, visa fornecer orientações para cenários de integração comuns e recomendar as melhores escolhas ao usar as diversas ferramentas disponíveis para um usuário da Jitterbit.

Esta página é melhor lida após você ter familiaridade com a Jitterbit: você já passou pela página Começar, completou os cursos da Jitterbit University e talvez tenha concluído um projeto de integração por conta própria. Nesse ponto, você conhecerá os conceitos e termos básicos usados na Jitterbit e entenderá o que a Jitterbit significa por projetos, operações, fontes, alvos, script, e implantação.

Este documento é um resumo dos recursos disponíveis através do Harmony 9.9. A partir da Primavera de 2019, o Integration Studio baseado na web está disponível para uso em substituição ao aplicativo de desktop Design Studio para design de projetos.

Consulte a seção Recursos adicionais abaixo para links para vídeos e outros documentos que ampliam as melhores práticas com a Jitterbit.

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 do Harmony. Quando surgirem perguntas 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 produção em que é necessário 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.

Atualizações do produto Jitterbit

As atualizações do Harmony são lançadas com frequência (veja Cronograma de lançamentos). Mesmo uma versão 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.

Organização e design do projeto

Reutilização

Reutilização de projeto

Um cenário típico para reutilizar 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 campos opcionais, endereços de email, nomes de arquivos—podem ser expostos como variáveis de projeto. O projeto "padrão" é implantado em múltiplos ambientes e, usando o Console de Gerenciamento, as variáveis de projeto para cada ambiente são preenchidas.

Reutilização de fonte/alvo

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

Isso se aplica a fontes e alvos de banco de dados, Compartilhamento de Arquivos, Site FTP, Arquivo Local e HTTP.

Reutilização de script

Scripts independentes que realizam uma função específica, como realizar uma consulta em um banco de dados ou fornecer um resultado a partir de uma série de argumentos, podem ser candidatos à reutilização, especialmente 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 é uma função que é utilizada em toda a integração, então um script independente (separado de uma operação) pode ser construído. Usando a função ArgumentList() ou variáveis globais simples, ele 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 múltiplas 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 exclusivamente 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: o carregamento e a salvaguarda de um projeto podem ser lentos devido à falta de cache
  • Outros usuários na rede podem sobrescrever 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ções 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 solucionar problemas.

Exemplo: suponha que existam dois fluxos de integração; um para Cliente Principal e um segundo para Item Principal, cada um com duas operações. Duas pastas, "Cliente Principal" e "Item Principal", podem ser criadas no Design Studio. Na primeira pasta, as operações podem ser chamadas de "CM001 Obter Cliente" e "CM002 Atualizar Cliente". Na segunda pasta, as operações podem ser chamadas de "IM001 Obter Itens" e "IM002 Atualizar Itens":

attachment

O log de operações pode então mostrar facilmente os passos na cadeia de integração e se algum passo foi perdido. Ao clicar com o botão direito em uma pasta no Design Studio, a lista de operações exibe apenas aquelas operações de uma pasta. Uma estrutura de organização e nomenclatura consistente facilita para alguém novo em um projeto entender rapidamente o fluxo básico de operações.

Gerenciar condições de corrida ao usar operações assíncronas

Ao usar a função RunOperation() 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 está encadeada à operação B que lê essa 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 ser executada antes que A seja concluída.

Credenciais do endpoint

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

Ao usar variáveis de projeto (cujos valores podem ser ocultos) para gerenciamento de credenciais, o Administrador do Jitterbit não precisa inserir credenciais de produção. Isso pode ser feito por um usuário através do Console de Gerenciamento. Essa abordagem pode ser utilizada para credenciais de email, se necessário.

Manipulação de API

O Gerenciador de API deve ser utilizado em vez de endpoints HTTP. Endpoints HTTP eram uma forma de lidar com chamadas de entrada de baixo tráfego e exigem que portas de rede específicas estejam abertas, o que muitas empresas hoje consideram um sério risco de segurança.

O Gerenciador de API e seu gateway de API são projetados para desempenho de alto volume, realizam registros detalhados, implementam medidas de segurança comuns e possuem uma interface de design simples de usar que faz parte da plataforma Harmony. Nenhuma porta de rede para lidar com tráfego de entrada precisa ser configurada.

Uma API do Gerenciador de API deve ser utilizada para padrões de integração em tempo real/baseados em eventos. Por exemplo: o Endpoint A tem a capacidade de chamar uma API, como Salesforce, usando mensagens de saída. Uma API do Gerenciador de API 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 da integração for tal que as operações subsequentes levem um tempo significativo para responder, há o risco de expiração do tempo limite, ou o risco de outras chamadas de entrada sobrecarregarem a capacidade do endpoint de destino de responder.

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 à API da origem.

Persistindo dados de integração

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

Variáveis de projeto

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

Um exemplo de uso das 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 do Jitterbit e editados através do Management Console. Isso possibilita um processo de negócios onde um usuário com direitos no Management Console pode alterar credenciais sem precisar de acesso ao Design Studio.

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

Funções de cache em nuvem

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

Usos adicionais do cache em nuvem incluem:

  • Dados podem ser compartilhados entre operações assíncronas dentro de um projeto.
  • Erros gerados em diferentes operações podem ser armazenados em um cache comum. Ao usar isso para acumular resultados de operações, alertas mais abrangentes podem ser construídos.
  • Tokens de login podem ser compartilhados entre operações.

Gerenciar Armazenamento Temporário

O armazenamento temporário é frequentemente utilizado em operações de integração. Isso é diferente de Arquivos Locais (sources ou targets), que podem ser usados apenas em agentes privados. Mantenha estas diretrizes em mente, especialmente ao trabalhar em um ambiente clusterizado:

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

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

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

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

  • Em um ambiente de agente clusterizado (agentes privados ou em nuvem), desde que as operações que utilizam o armazenamento temporário estejam vinculadas (encadeadas), todas as leituras e gravações de armazenamento temporário ocorrerão no mesmo host de servidor. Mas, se a cadeia de operação A grava no armazenamento temporário "meuarquivo" e a cadeia de operação B lê o armazenamento temporário "meuarquivo", a ação de leitura pode ser inconsistente porque pode não ler o mesmo host de servidor que a cadeia A.

    Nota

    Operações encadeadas sempre serão executadas no mesmo agente que a operação pai, independentemente da sincronicidade.

  • Para os destinos, o padrão é sobrescrever o arquivo. Isso pode ser alterado com a opção "Anexar ao Arquivo". Normalmente, isso requer que, após a leitura da fonte, o arquivo seja excluído ou arquivado. Uma maneira simples de fazer isso é escolher "Excluir Arquivo" ou "Renomear Arquivo" na fonte.

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

  • Um arquivo em armazenamento temporário pode ser lido rapidamente construindo um script com a função ReadFile(), como ReadFile("<TAG>Sources/test</TAG>"). Tenha em mente que isso funciona de forma confiável apenas 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.

Scripting

Quando usar scripting

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

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

O scripting é geralmente melhor em dois lugares: dentro do Construtor de Fórmulas em transformações e em scripts independentes. Se o mesmo código estiver sendo usado em mais de uma transformação, considere mover esse código para um script independente e chamá-lo de dentro de cada transformação usando RunScript().

Convenção de nomenclatura para variáveis

Jitterbit possui quatro tipos de variáveis:

  • variáveis locais
  • variáveis globais
  • variáveis de 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 pré-definidas 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 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 em scripts subsequentes dentro de uma cadeia de operações), devem usar uma convenção de nomenclatura consistente para evitar reutilização inadvertida. Por exemplo, usando múltiplos componentes para um nome de variável, separados por pontos, você poderia seguir um padrão como:

first.second.third[.fourth]

onde:

  • Primeiro componente: especificador da organização
  • Segundo componente: um tipo, como id, error, date, file, token, timestamp, timezone, flag, email, guid, user, externalid, val (para um valor diverso), arr (para array), 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, os nomes das variáveis poderiam ser:

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

Como as variáveis de projeto são visíveis através do Management Console e geralmente são usadas para configurar o comportamento de integração, nomes mais amigáveis podem ser utilizados. 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".

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.

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

O 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 ambiente "Prod" estejam configurados no Console de Gerenciamento e ambos sejam atribuídos ao grupo de agentes A. O Projeto 1 é desenvolvido sob o ambiente "Dev". O Jitterbit fornece um recurso de "Migração" que copiará esse projeto para o ambiente "Prod", após o qual as credenciais de endpoint são alteradas para as credenciais de endpoint "Prod". Outras fontes e alvos também são alterados. Depois, quaisquer migrações de "Dev" para "Prod" excluem endpoints, fontes e alvos, 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 leva todo o projeto e sobrescreve 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 alterações significativas 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 acompanha itens "sujos", isso implantará alterações, bem como todas as dependências.

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

Avisos de versão

Ao implantar alterações em um projeto, se uma versão mais recente de um projeto foi implantada, um aviso será exibido indicando que uma versão mais nova existe e identificando quem a implantou. O Administrador do Jitterbit tem a opção de sobrescrever o projeto. Em geral, em um ambiente com múltiplos desenvolvedores, é preferível baixar o projeto atual da nuvem antes de fazer alterações.

Testando, solucionando problemas e registrando

Use recursos de teste para desenvolvimento de integração rAPID

O Jitterbit pode permitir o desenvolvimento rápido de integrações e testes unitários ao tornar visíveis os dados reais da integração durante o tempo de design. A vantagem óbvia é possibilitar um processo de desenvolvimento iterativo ao mostrar 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. Isso é feito principalmente através da ferramenta de Transformações, particularmente usando os recursos "Testar Transformação" e "Executar Operação".

Se os objetos a serem integrados forem conhecidos, um desenvolvedor experiente pode desenvolver uma integração rapidamente usando o Assistente de Transformação e seu kit de ferramentas. Por exemplo, faça uma conexão com um banco de dados e, usando o Assistente de Transformação, construa a operação e a transformação. Em seguida, execute uma "Executar Operação" com a transformação aberta. Os dados serão exibidos na tela de transformação e os registros podem ser percorridos. 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 Construtor de Fórmulas e construir o script necessário. Ao usar o recurso "Testar" no Construtor de Fórmulas, a saída usará os dados da transformação e mostrará a saída exata que será gerada durante o tempo de execução.

Se a fonte não estiver disponível, mas os dados da fonte estiverem disponíveis em um arquivo (CSV, XML, JSON), o arquivo pode ser importado para a ferramenta de Transformações usando os recursos "Carregar Dados de Fonte de Exemplo" 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á 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. É 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 parecerem incorretos, normalmente o suporte à integração é acionado 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, isso é suportado por meio de recursos de registro e alerta.

Registro

O log de operações do Jitterbit capturará dados-chave por padrão, como horários de execução de operações 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 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 for desejado capturar toda a saída de uma transformação, isso pode ser feito construindo uma operação que lê a fonte, realiza a transformação e grava em um arquivo temporário. Um script pós-operação pode ler o arquivo e gravar o arquivo no log de operações: WriteToOperationLog(ReadFile(<tempfile>)). Então, a operação "real" pode ser realizada.

Os logs podem ser visualizados tanto no Design Studio quanto no Management Console. A vantagem do Management Console é que o pessoal de suporte pode acessá-lo através do navegador sem precisar de um cliente do Design Studio em sua área de trabalho.

Os dados nos logs são pesquisáveis, permitindo o cenário em que a string exata envolvida na solução de problemas é um valor conhecido e está registrada.

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 logs de operações, incluindo mensagens de log detalhadas de agentes em nuvem e agentes privados, são retidos por 30 dias pelo Harmony.

Alerta

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

Para 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 técnicas

As Palestras Técnicas da Jitterbit são apresentações em vídeo que cobrem áreas de interesse para usuários de todos os níveis:

Documentação

A documentação do Jitterbit inclui as melhores práticas em nossas páginas sobre como usar o Jitterbit:

Segurança

Padrões de design e exemplos

  • Melhores práticas para SAP
    Questões e considerações que podem surgir ao integrar com instâncias SAP, particularmente ao criar uma integração bidirecional.
  • Como fazer no Design Studio
    Problemas comuns de integração enfrentados por nossos clientes que podem ser resolvidos usando nosso software.
  • Biblioteca Jitterpak
    Projetos de exemplo para ajudar você a começar.

Criar projetos

Logging

Manage projects

  • Criando Novas Receitas
    Melhores práticas a serem seguidas ao criar Jitterpaks para uso com receitas do Citizen Integrator no Design Studio.
  • Metodologia de projeto de integração
    Itens-chave que um Gerente de Projeto para um projeto do Design Studio deve conhecer, incluindo como organizar sua equipe, reunir e validar requisitos de forma clara e concisa, e aproveitar as forças do Harmony para entregar um projeto de integração bem-sucedido.
  • Restaurar de backup na nuvem
    Melhores práticas em torno de backup e restauração de projetos.
  • Configurar um projeto de colaboração em equipe
    Melhores práticas para apoiar múltiplos desenvolvedores trabalhando no mesmo projeto.

Private agents

Use APIs