Considerações de armazenamento entre variáveis, armazenamento temporário, cache em nuvem e Cloud Datastore no Jitterbit Integration Studio

Introdução

O Integration Studio oferece várias abordagens para lidar com dados em suas integrações. Essas abordagens variam desde a passagem de valores simples entre operações até o armazenamento e recuperação de dados. Cada abordagem é projetada para casos de uso e requisitos de desempenho específicos. Esta página descreve as abordagens recomendadas e não é uma lista abrangente de todas as abordagens.

Variáveis para passagem de dados

As variáveis são projetadas para passar valores, configurações e pequenas quantidades de dados entre diferentes componentes em sua integração. As variáveis são úteis quando você precisa compartilhar informações como IDs de sessão, parâmetros de configuração ou valores calculados entre scripts, transformações e operações. Esses tipos de variáveis estão disponíveis para uso:

Para exemplos e informações detalhadas sobre cada tipo de variável, consulte suas páginas de documentação individuais.

Conectores de armazenamento para persistência de dados

Os conectores de armazenamento lidam com o armazenamento e a recuperação de arquivos e dados persistentes dentro de suas integrações. Esses conectores de armazenamento são úteis quando você está trabalhando com arquivos de dados reais, precisa armazenar temporariamente resultados de processamento ou requer dados que persistem além de uma única cadeia de operação:

Variável

Os endpoints de variável (Ler e Escrever atividades, que leem ou escrevem em uma variável global), são fáceis de codificar e reduzem a complexidade. No entanto, eles têm certas limitações.

Recomendamos o uso de um endpoint de variável para cenários em que uma integração trabalha com pequenos conjuntos de dados, como solicitações e respostas de serviços web, ou arquivos pequenos com algumas centenas de registros.

Quando o conjunto de dados atinge a faixa de megabytes, o endpoint de variável se torna mais lento e a degradação começa a ocorrer quando os dados excedem 4 MB de tamanho.

Quando o conjunto de dados está na faixa maior de multi-megabytes, há um risco de truncamento de dados. Recomendamos limitar o uso de endpoints de variável a 50 MB para ser conservador e evitar qualquer risco de truncamento.

Usar endpoints de variável em operações assíncronas requer consideração especial. Há um limite de 7 KB no tamanho de um conjunto de dados usado em um endpoint de variável que é utilizado em uma operação assíncrona. Nesse cenário, exceder esse limite pode resultar em truncamento. Consulte a função RunOperation para uma descrição de como chamar uma operação assíncrona.

Endpoints de variável permitem reutilização e reduzem a complexidade

Usar um endpoint de variável para pequenos conjuntos de dados pode permitir reutilização e reduzir a complexidade. Por exemplo, ao construir cadeias de operações, cada operação pode ter atividades que funcionam como fontes (Ler atividades) e alvos (Escrever atividades). Em vez de construir combinações individuais de fonte ou alvo para cada operação, você pode usar um alvo e uma fonte de variável comuns.

Para aumentar a reutilização e a padronização, você pode criar um script reutilizável que registra o conteúdo da variável. Essa abordagem também pode ser realizada usando armazenamento temporário, mas é necessário um script adicional para inicializar o caminho e o nome do arquivo.

Ao usar um endpoint de Variável, seu escopo é a cadeia de operações. Os valores dos endpoints de Variável são exclusivos para uma determinada cadeia de operações e são limpos quando a cadeia de operações é concluída. Isso não acontece com um endpoint de Armazenamento Temporário (descrito na seção a seguir).

Ao realizar testes de unidade de operação, usar um endpoint de Variável é útil para carregar dados de teste. Você pode adicionar um script no início da cadeia de operações para escrever dados de teste:

  $memory = "a,b,c";

Em contraste, escrever dados em um endpoint de Armazenamento Temporário se parece com isto:

  WriteFile("<TAG>activity:tempstorage/Temporary Storage/tempstorage_write/Write</TAG>", "a,b,c");

  FlushFile("<TAG>activity:tempstorage/Temporary Storage/tempstorage_write/Write</TAG>");

Da mesma forma, ler dados é mais simples com um endpoint de Variável:

  myLocalVar= $memory;

Em contraste, é assim que você lê dados de um endpoint de Armazenamento Temporário:

  myLocalVar = ReadFile("<TAG>activity:tempstorage/Temporary Storage/tempstorage_read/Read</TAG>");

Armazenamento Temporário

Os endpoints de Armazenamento Temporário são frequentemente usados em operações em agentes tanto na nuvem quanto privados. Estes são distintos dos endpoints de Armazenamento Local, que só podem ser usados em agentes privados.

Ao usar um endpoint de Armazenamento Temporário, arquivos temporários são escritos e lidos do 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 de armazenamento temporário é o diretório temporário padrão do servidor desse agente privado.
• Se você estiver usando mais de um agente privado em um grupo de agentes privados, o diretório de armazenamento temporário é o diretório temporário padrão do servidor do agente privado específico que está realizando o trabalho.
• Como os agentes na nuvem são agrupados em um grupo de agentes na nuvem, o diretório de armazenamento temporário é o diretório temporário padrão do servidor do agente na nuvem específico que está realizando o trabalho.

Ao usar um grupo de agentes privados com múltiplos agentes ou um grupo de agentes em nuvem, as operações de armazenamento temporário permanecerão no mesmo servidor enquanto fizerem parte de uma cadeia de operações. No entanto, se você tiver duas cadeias separadas onde a Cadeia A grava no arquivo de armazenamento temporário myfile e a Cadeia B lê posteriormente de myfile, a Cadeia B pode não acessar o mesmo servidor de agente que a Cadeia A usou para gravação.

Ao usar armazenamento temporário, mantenha estas diretrizes em mente:

• Ao usar agentes privados, para tornar seu projeto à prova de atualizações, utilize o armazenamento temporário de forma que a transição de um único agente privado para um grupo de agentes múltiplos não exija refatoração.

• Para garantir que as leituras e gravações de armazenamento temporário ocorram no mesmo servidor de agente, mantenha todas as atividades de Leitura e Gravação que referenciam o mesmo armazenamento temporário dentro de uma única cadeia de operações. Isso se aplica tanto se você estiver usando um grupo de agentes privados com múltiplos agentes quanto um grupo de agentes em nuvem.

• O armazenamento temporário em agentes privados é excluído após 24 horas por padrão pelo serviço de limpeza de arquivos Jitterbit. A frequência do serviço de limpeza pode ser configurada através do arquivo de configuração do agente privado na seção [FileCleanup]. No entanto, em agentes em nuvem, arquivos temporários podem ser excluídos imediatamente.

• Agentes em nuvem têm um limite de tamanho de arquivo de armazenamento temporário de 50 GB por arquivo. Arquivos temporários maiores que 50 GB são possíveis apenas ao usar agentes privados.

• Ao gravar no armazenamento temporário, o padrão é sobrescrever arquivos. Isso pode ser alterado com a caixa de seleção Anexar ao Arquivo em uma atividade de Gravação de Armazenamento Temporário. Normalmente, isso requer que, após a leitura da fonte, o arquivo seja excluído ou arquivado. Uma maneira simples de fazer isso é usar as opções de pós-processamento Excluir Arquivo ou Renomear Arquivo em uma atividade de Leitura de Armazenamento Temporário.

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

  Exemplo

  Você pode usar a [unique] palavra-chave de nome de arquivo em uma atividade de gravação em armazenamento temporário para gerar nomes de arquivos únicos automaticamente e evitar sobrescritas de arquivos. Por exemplo, nomear seu arquivo como processing_[unique].csv cria arquivos como processing_20240820143052123.csv.

• Um arquivo no armazenamento temporário pode ser lido construindo um script com a função ReadFile. Por exemplo: ReadFile("<TAG>activity:tempstorage/Temporary Storage/tempstorage_read/Read</TAG>"). Tenha em mente que isso funciona de forma confiável apenas se houver um único agente privado.

Cloud Datastore (Beta)

Cloud Datastore (Beta) fornece uma solução de armazenamento persistente onde a persistência de dados varia de acordo com o tipo de armazenamento, ao contrário das soluções de armazenamento temporário que limpam os dados após a conclusão de uma operação.

Cloud Datastore (Beta) aborda dois principais casos de uso:

• Soluções de pares chave-valor: Armazena dados de consulta, como US > Estados Unidos, que podem ser referenciados em várias operações e projetos.
• Processamento de dados com base em fluxos de trabalho de status: Gerencia dados que passam por diferentes estados de processamento, com limpeza automatizada para registros processados.

Cloud Datastore (Beta) suporta dois tipos de armazenamento com diferentes características de persistência:

• Consulta por Chave: Os dados persistem até serem explicitamente excluídos, ideal para dados de referência e tabelas de consulta.
• Consulta por Valor: Dados com fluxos de trabalho de status onde os registros são retidos por um máximo de 90 dias. No entanto, uma vez que os dados atingem o Status Processado, eles são automaticamente excluídos após 60 dias.

Funções de cache em nuvem

Além das variáveis principais e conectores de armazenamento, o Integration Studio oferece funções de cache em nuvem para melhorar o desempenho e a funcionalidade da sua integração.

As funções de cache em nuvem ReadCache e WriteCache são usadas para atribuir espaços de dados 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, como Armazenamento Temporário ou conectores Variável, os dados podem ser compartilhados entre operações separadas e entre projetos.

Esses são usos adicionais do cache em nuvem:

• 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 acumular resultados de operações dessa maneira, alertas mais abrangentes podem ser construídos.
• Tokens de login podem ser compartilhados entre operações.