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 Design Studio, o aplicativo de design de projetos baseado em desktop da Jitterbit. Para práticas recomendadas usando Cloud Studio, a versão baseada na web do aplicativo de design de projeto da Jitterbit, consulte Práticas recomendadas do Harmony.

Este documento não pretende ser abrangente ou cobrir todos os cenários de integração. Em vez disso, serve para fornecer orientação para cenários de integração comuns e recomendar as melhores opções no uso das diversas ferramentas disponíveis para um usuário Jitterbit.

Esta página é melhor lida depois que você estiver familiarizado com o Jitterbit: você passou pelos Primeiros passos, concluiu a Universidade Jitterbit cursos 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 no Jitterbit e entenderá o que Jitterbit significa por projetos, operações, fontes, destinos, scripting e implantação.

Este documento é um resumo dos recursos disponíveis através do Harmony 9.9. Em primavera de 2019, o Cloud Studio baseado na web está disponível para uso no lugar da área de trabalho Design Studio pedido de concepção de projeto. As principais diferenças são descritas em Visão geral do Cloud Studio para usuários do Design Studio.

Consulte os Recursos Adicionais abaixo para obter links para vídeos e outros documentos que expandem as práticas recomendadas com o Jitterbit.

Use 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 da Jitterbit usando o Portal de suporte da Jitterbit ou por email. O Suporte Jitterbit descreve instruções especiais para situações de interrupção da produção, a fim de escalar problemas urgentes.

Você também pode entrar em contato com seu Gerente de sucesso do cliente (CSM) com questões relacionadas ao licenciamento ou outros tópicos.

Este site de documentação (Central de Sucesso da Jitterbit) e nosso site de documentação do desenvolvedor (Portal do desenvolvedor da Jitterbit) contêm mais de 1.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çamento). Mesmo uma versão menor contém novos recursos e melhorias, juntamente com 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 de API em Nuvem e Grupo de Agentes em Nuvem as atualizações são aplicadas automaticamente. Para os Grupos de Agentes em Nuvem, existem dois conjuntos: Produção e Sandbox. O último conjunto é usado para testar a compatibilidade com pré-lançamentos de software de 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 os lançamentos que incluem atualizações de recursos.

Organização e Design do Projeto

Reutilização

Reutilização do Projeto

Um cenário típico para a reutilização de um projeto envolve o desenvolvimento de um projeto "padrão" com o uso extensivo de variáveis globais e — especialmente — de variáveis de projeto. Itens configuráveis — como credenciais de endpoint, mapeamentos de campos opcionais, endereços email, nomes de arquivos — 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 do projeto para cada ambiente são preenchidas.

Reutilização de Origem/destino

Embora as origens e os destinos dos arquivos sejam frequentemente usados nas operações, um novo par origem/destino não precisa necessariamente ser criado para cada operação. Como as origens e os destinos dos arquivos aceitam variáveis globais para caminhos e nomes de arquivos, as origens e os destinos para operações semelhantes podem ser criados uma vez e controlados por variáveis globais. Por exemplo, suponha que os objetos "Origem" e "Destino" sejam criados e no campo nome do arquivo esteja [filename]. O $filename a variável pode ser definida em qualquer lugar antes do destino ser escrito e usado.

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

Reutilização de Script

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

Por exemplo, se um script usa o DBLookup() função em uma tabela de banco de dados, e esta é uma função usada em toda a integração, então um script independente (separado de uma operação) pode ser construído. Usando o ArgumentList() função ou variáveis globais simples, ele pode aceitar argumentos e retornar um resultado. Como cada cadeia de operação tem um escopo diferente, o mesmo script pode ser chamado com segurança a partir 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 sejam exclusivamente da interface do usuário (por exemplo, você reorganiza objetos em uma visualização) não serão preservadas quando você reabrir o projeto.

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

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

Organize 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 existam 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 poderiam ser denominadas “CM001 Obter Cliente” e “CM002 Atualizar Cliente”. Na segunda pasta, as operações poderiam então ser chamadas de "IM001 Get Items" e "IM002 Update Items":

anexo

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

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 atualizar uma tabela de banco de dados e for encadeada à operação B que lê a mesma tabela (ambas são síncronas), nenhuma condição de corrida será encontrada. Mas se a operação A for chamada de forma assíncrona seguida imediatamente pela operação B, B poderá ser executada antes que A seja concluída.

Credenciais de Endpoint

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

Ao usar variáveis de projeto (cujos valores podem ser ocultados) para gerenciamento de credenciais, o administrador do Jitterbit 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.

Tratamento de API

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

A plataforma Harmony API foi projetada para desempenho de alto volume, realiza registros detalhados, implementa medidas de segurança comuns e possui uma interface de design simples de usar que faz parte do Portal Harmony. Nenhuma porta de rede para lidar com o 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 implementada rapidamente 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 projeto de integração for tal que as operações subsequentes levem um tempo significativo para responder, há o risco de o tempo limite ser esgotado ou o risco de outras chamadas de entrada sobrecarregarem a capacidade de resposta do endpoint alvo.

Se o endpoint de origem estiver fazendo muitas chamadas por minuto e o gateway do endpoint de destino puder lidar apenas com um determinado número de conexões, é possível que o endpoint de destino não consiga escalar verticalmente para lidar com as solicitações. Neste 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 de origem.

Dados de Integração Persistentes

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

Variáveis do Projeto

Variáveis de projeto são variáveis estáticas pré-inicializadas (semelhantes às "constantes" de 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 possuem credenciais diferentes) podem ser aplicados a diferentes ambientes Jitterbit e editados por meio do Management Console. Isso permite um processo de negócios onde 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 armazenar 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 endpoints diferentes, uma variável booleana do projeto (como "Send_PO_number") poderá ser verificada pela lógica da transformação para o campo Número do pedido. Se o valor da variável do projeto for falso, então o UnMap() O comando pode 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 projetos e ambientes. Um valor armazenado em cache fica visível para todas as operações em execução no mesmo escopo até expirar, independentemente de como a 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.

Os usos adicionais do cache em nuvem incluem:

  • Os 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çã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. Lembre-se destas diretrizes, principalmente ao trabalhar no uso de um ambiente em cluster:

  • Torne seu projeto "à prova de atualização" e use armazenamento temporário de forma que a mudança 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 do Agente Privado. Se você estiver usando mais de um Agente Privado, esse será o diretório temporário padrão do hospedar do servidor para qualquer agente que esteja fazendo o trabalho. Se estiver usando um Agente em Nuvem (que está em cluster), então é o diretório temporário padrão do hospedar 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 Jitterbit. No caso dos Agentes em Nuvem, isso pode ser imediato.

  • Uma abordagem simplista é construir um destino, atribuir-lhe 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 em Nuvem), desde que as operações que usam o armazenamento temporário estejam vinculadas (encadeadas), todas as leituras e gravações do armazenamento temporário acontecerão no mesmo hospedar do servidor. Mas, se a cadeia de operação A gravar no armazenamento temporário "meuarquivo" e a cadeia de operação B ler o armazenamento temporário "meuarquivo", a ação de leitura poderá ser inconsistente porque pode não ler o mesmo hospedar do servidor que a cadeia A.

  • Para destinos, o padrão é substituir o arquivo. Isso pode ser alterado com a opção “Anexar ao arquivo”. Normalmente, isso exige 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 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 só funciona de forma confiável se houver um único Agente Privado.

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

Scripts

Quando Usar Scripts

Embora o Jitterbit forneça um recurso robusto de script, o script deve ser usado apenas quando necessário. Se houver uma escolha entre usar scripts 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 Design Studio da Jitterbit para realizar uma tarefa.

Um exemplo seria a organização de execuções operação. A interface de usuário do Design Studio do Jitterbit permite criar "cadeias de operação " vinculadas por caminhos de sucesso e fracasso. Alternativamente, é possível construir operações independentes e depois vinculá-las usando scripts e o RunOperation() função. A menos que existam requisitos técnicos que conduzam esta 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.

Geralmente, os scripts são melhores em dois locais: no Formula Builder, 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 do projeto
  • Variáveis de 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".

As variáveis globais, como seu escopo é maior (uma variável global está disponível para ser referenciada nas mesmas operações e scripts ou em operações abaixo dentro de uma cadeia de operação ), devem usar uma convenção de nomenclatura consistente para evitar a reutilização inadvertida. Por exemplo, usando vários 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 organizacional
  • 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 da 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 do projeto são visíveis por meio do Management Console e geralmente são usadas para configurar o comportamento de integração, nomes mais amigáveis podem ser usados. Como o nome de uma variável de projeto não pode conter espaços, sublinhados podem ser usados. 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 usá-la de forma consistente em todos os projetos.

Aviso

Se você planeja usar suas variáveis globais do 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 "Prod" estejam 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 serão alteradas para as credenciais do endpoint "Prod". Outras fontes e alvos também são alterados. Posteriormente, quaisquer migrações de "Dev" para "Prod" excluem endpoints, fontes e destinos, a menos que sejam novos.

Opções de Gerenciamento de Implantação

Existem diversas opções para implantação de projetos.

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

  • Backup do Projeto: Ao escolher Ações > Implantar > Tudo, há uma opção para "Armazenar também um backup na nuvem". Antes de fazer grandes alterações em um projeto, selecione esta opção para salvar um ponto de restauração 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 controla os itens "sujos", isso implantar as alterações, bem como todas as dependências.

  • Um novo recurso é desativar a caixa de diálogo de progresso durante uma implantar (consulte Preferências > Implantação), o 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 tiver sido implantada, um aviso será exibido indicando que existe uma versão mais recente e identificando quem a implantou. O administrador do Jitterbit tem a opção de substituir o projeto. Em geral, em um ambiente multidesenvolvedor, é 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 Rápido de Integração

O Jitterbit pode permitir o rápido desenvolvimento de integração e testes unitários, tornando 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 a operação inteira, executá-la e inspecionar a saída. Isto é feito principalmente através da ferramenta Transformações, particularmente utilizando os recursos “Test Transformação” e “Run Operation”.

Se os objetos a serem integrados forem conhecidos, um desenvolvedor experiente poderá 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 Assistente de Transformação, construa a operação e a transformação. Em seguida, execute uma “Operação Executar” com a transformação aberta. Os dados serão exibidos na tela de transformação e os registros poderão 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 criar o script necessário. Ao utilizar o recurso "Teste" no Formula Builder, a saída utilizará os dados de 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 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 pela empresa em relação à precisão do trabalho de integração, especialmente quando aparecerem discrepâncias nos dados do endpoint. A integração pode ou não ser culpada. É responsabilidade da integração fornecer um alto grau de transparência, a fim de 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. disponibilizando essas informações como parte padrão da arquitetura de integração.

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

Exploração Madeireira

O log de operação do Jitterbit capturará dados importantes 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, o log irá capturá-las.

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

Se for desejado capturar toda a saída de uma transformação, isso pode ser feito construindo uma operação que lê a origem, executa a transformação e grava 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 executada.

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 através do navegador sem precisar de um cliente do Design Studio em seu desktop.

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

Freqüentemente, as APIs têm uma mensagem de resposta de sucesso ou insucesso que é informativa. Dê um passo extra para capturar essas informações no log.

Os logs de operação, 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 só precisam ser registrados, mas também escalonados. O Jitterbit fornece integração email, que pode ser facilmente anexado a operações e caminhos de sucesso/falha ou chamado a partir de scripts.

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

Recursos Adicionais

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

Palestras Técnicas

Jitterbit Tech Talks 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 práticas recomendadas em nossas páginas sobre o uso do Jitterbit:

Segurança

Padrões de Design e Exemplos

  • Melhores Práticas para SAP
    Problemas e considerações que podem surgir durante a integração de e para instâncias SAP, especialmente ao criar uma integração bidirecional.
  • Tutoriais do Design Studio
    Problemas comuns de integração encontrados por nossos clientes que podem ser resolvidos usando nosso software.
  • Biblioteca Jitterpak
    Exemplos de projetos para ajudá-lo a começar.

Criar Projetos

Exploração Madeireira

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 Projetos de Integração
    Itens principais que um gerente de projetos de um projeto do 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
    Práticas recomendadas para backup e restauração de projetos.
  • Configurar um projeto de colaboração em equipe
    Melhores práticas para oferecer suporte a vários desenvolvedores trabalhando no mesmo projeto.

Agentes Privados

Use APIs