Ir para o conteúdo

Opções de operação no Jitterbit Integration Studio

Introdução

Configure as opções de operação para controlar timeouts, registro e processamento de dados. A maioria das operações funciona bem com as configurações padrão, mas você pode personalizá-las para necessidades específicas.

Acessar opções de operação

Você pode acessar a opção Configurações para operações a partir destes locais:

Após abrir a tela de configurações da operação, selecione a aba Opções:

opções da aba

Configurar opções de operação

As seções a seguir descrevem cada opção de operação:

diálogo de opções

Timeout da operação

Defina quanto tempo a operação deve ser executada antes de ser cancelada. O padrão é 2 horas, o que funciona para a maioria das operações.

Você pode querer ajustar esta configuração por estas razões:

  • Aumentar o tempo limite para conjuntos de dados grandes que levam mais tempo para processar.

  • Diminuir o tempo limite para operações sensíveis ao tempo que devem ser concluídas rapidamente.

Digite um número e selecione Segundos, Minutos ou Horas no menu suspenso.

Nota

Operações acionadas por APIs do API Manager ignoram esta configuração em agentes na nuvem. Para agentes privados, ative EnableAPITimeout no arquivo de configuração do agente privado para que a configuração de Tempo Limite da Operação se aplique a operações acionadas por APIs.

O que registrar

Escolha quais informações aparecem nos logs de operação:

  • Tudo: Registra toda a atividade da operação (recomendado).
  • Apenas Erros: Registra apenas operações com um status do tipo erro (como Erro, Falha SOAP ou Sucesso com Erro de Filho). Use esta configuração se você tiver problemas de desempenho e não precisar de logs detalhados. Operações de filho bem-sucedidas não são registradas. Operações pai (de nível raiz) são sempre registradas, pois requerem registro para funcionar corretamente.

Ativar Modo de Depuração Até

Ative o registro detalhado para solução de problemas. Selecione uma data até duas semanas a partir de hoje. O modo de depuração desativa automaticamente nesta data.

Aviso

Em grupos de agentes na nuvem, a duração desta configuração é pouco confiável. Os logs podem parar de ser gerados antes do final do período de tempo selecionado.

Quando você ativa o modo de depuração para operações com operações de filho, pode aplicar a mesma configuração a todas as operações de filho usando a caixa de seleção Também Aplicar a Operações de Filho.

O registro de depuração gera diferentes tipos de logs com base no tipo de agente:

Tipo de log
Descrição do log Tipo de agente
Arquivos de log de depuração Arquivos de log de depuração para solução de problemas detalhada. Você pode acessar esses arquivos diretamente no agente ou baixá-los através do Console de Gerenciamento. O registro de depuração também pode ser ativado para todo o projeto a partir do próprio agente privado (veja Registro de depuração de operação). Os arquivos de log de depuração são acessíveis diretamente em agentes privados e podem ser baixados através das páginas do Console de Gerenciamento Agentes e Operações em Tempo de Execução.

Aviso

O modo de depuração cria arquivos de log grandes. Use apenas durante os testes, não em produção.

 Apenas agentes privados
Entrada e saída de componentes Dados de solicitação e resposta (mantidos por 30 dias). Acessados através da página de Operações em Tempo de Execução do Console de Gerenciamento.

Cuidado

Os dados de entrada e saída do componente sempre são registrados na nuvem Harmony, mesmo que o registro na nuvem esteja desativado. Para parar isso em agentes privados, defina verbose.logging.enable=false no arquivo de configuração sob [VerboseLogging].

Os logs de depuração contêm todos os dados de solicitação e resposta, incluindo informações sensíveis como senhas e informações pessoalmente identificáveis (PII). Esses dados aparecem em texto claro nos logs da nuvem Harmony por 30 dias.

 Agentes em nuvem e privados
Logs de operação da API Logs para operações de API bem-sucedidas (configurados para APIs personalizadas ou serviços OData). Por padrão, apenas operações de API com erros são registradas nos logs de operação.
 Agentes em nuvem e privados

Executar operação de sucesso mesmo que não haja arquivos de origem correspondentes

Esta opção força uma operação a ter sucesso mesmo quando seu gatilho falha. Isso permite que outras operações acionadas para serem executadas Em Caso de Sucesso desta operação sejam executadas independentemente do resultado da operação inicial. Aplica-se apenas quando a operação inicial contém uma atividade de origem para um desses conectores:

Por padrão, qualquer operação Em Caso de Sucesso é executada apenas se houver um arquivo de origem correspondente para processar. Esta opção pode ser útil para configurar partes posteriores de um projeto sem exigir o sucesso de uma operação dependente.

Nota

A configuração AlwaysRunSuccessOperation no arquivo de configuração do agente privado substitui esta opção.

Habilitar Chunking

Chunking divide grandes conjuntos de dados em partes menores. Isso torna o processamento mais rápido e ajuda a atender aos limites de registros da API. Para habilitar o chunking, sua operação deve conter uma transformação ou uma atividade de um desses conectores:

Use chunking nessas situações:

  • Você processa grandes conjuntos de dados com milhares de registros.
  • Você usa serviços web com limites de registro. Por exemplo, o Salesforce permite apenas 200 registros por chamada.
  • Você deseja usar múltiplos núcleos de CPU para processamento paralelo.

Quando uma atividade de Salesforce, Salesforce Service Cloud ou ServiceMax está na operação, o chunking é habilitado automaticamente.

Quando essa configuração está habilitada, configure estes campos:

  • Tamanho do Chunk: O número de registros em cada chunk. O padrão é 1 para a maioria das operações e 200 para operações do Salesforce.

    Nota

    Quando você usa uma atividade em massa de (Salesforce, Salesforce Service Cloud ou ServiceMax), altere esse padrão para um número muito maior, como 10.000.

  • Número de Registros por Arquivo: O número de registros em cada arquivo de destino. O padrão é 0, o que significa sem limite.

  • Número Máximo de Threads: O número de threads de processamento que são executadas ao mesmo tempo. O padrão é 1 para a maioria das operações e 2 para operações do Salesforce.

Aviso

O chunking afeta como as variáveis globais e de projeto funcionam. Apenas as alterações da primeira thread são preservadas. Veja informações detalhadas sobre chunking abaixo.

Opções de operação em massa do Salesforce

As seguintes opções aparecem apenas para operações em massa de Salesforce, Salesforce Service Cloud e ServiceMax (exceto operações de Bulk Query):

falha e sucesso na gravação do salesforce

Nota

As atividades baseadas em arquivo e as notificações por email selecionadas nessas opções não precisam fazer parte de uma operação implantada existente. O Integration Studio implantará e gerenciará automaticamente esses componentes quando selecionados.

Informações detalhadas sobre chunking

Chunking é utilizado para dividir os dados de origem em múltiplos pedaços com base no tamanho de chunk configurado. O tamanho do chunk é o número de registros de origem (nós) para cada pedaço. A transformação é então realizada em cada pedaço separadamente, com cada pedaço de origem produzindo um pedaço de destino. Os pedaços de destino resultantes se combinam para produzir o destino final.

Chunking pode ser utilizado apenas se os registros forem independentes e de uma fonte não-LDAP. Recomendamos usar um tamanho de chunk o maior possível, garantindo que os dados de um pedaço caibam na memória disponível. Para métodos adicionais de limitar a quantidade de memória que uma transformação utiliza, veja Processamento de transformação.

Aviso

O uso de chunking afeta o comportamento de variáveis globais e de projeto. Veja Usar variáveis com chunking abaixo.

Limitações da API

Muitas APIs de serviços web (SOAP/REST) têm limitações de tamanho. Por exemplo, um upsert baseado em Salesforce aceita apenas 200 registros para cada chamada. Com memória suficiente, você poderia configurar uma operação para usar um tamanho de chunk de 200. A fonte seria dividida em pedaços de 200 registros cada, e cada transformação chamaria o serviço web uma vez com um pedaço de 200 registros. Isso seria repetido até que todos os registros tenham sido processados. Os arquivos de destino resultantes seriam então combinados. (Note que você também poderia usar atividades em massa baseadas em Salesforce para evitar o uso de chunking.)

Processamento paralelo

Se você tem uma fonte grande e um computador com múltiplos CPUs, o chunking pode ser utilizado para dividir a fonte para processamento paralelo. Como cada pedaço é processado isoladamente, vários pedaços podem ser processados em paralelo. Isso se aplica apenas se os registros de origem forem independentes entre si no nível do nó do chunk. Serviços web podem ser chamados em paralelo usando chunking, melhorando o desempenho.

Ao usar chunking em uma operação onde o destino é um banco de dados, note que os dados de destino são primeiro escritos em numerosos arquivos temporários (um para cada pedaço). Esses arquivos são então combinados em um único arquivo de destino, que é enviado ao banco de dados para inserção/atualização. Se você definir a variável Jitterbit jitterbit.target.db.commit_chunks como 1 ou true quando o chunking estiver habilitado, cada pedaço será em vez disso confirmado no banco de dados à medida que se torna disponível. Isso pode melhorar significativamente o desempenho, pois as inserções/atualizações no banco de dados são realizadas em paralelo.

Use variables with chunking

Como o chunking pode invocar multi-threading, seu uso pode afetar o comportamento de variáveis que não são compartilhadas entre as threads.

Global e project variables são segregadas entre as instâncias de chunking, e embora os dados sejam combinados, as alterações nessas variáveis não são. Apenas as alterações feitas na thread inicial são preservadas ao final da transformação.

Por exemplo, se uma operação — com chunking e múltiplas threads — tem uma transformação que altera uma variável global, o valor da variável global após o término da operação é aquele da primeira thread. Quaisquer alterações na variável em outras threads são independentes e são descartadas quando a operação é concluída.

Essas variáveis globais são passadas para as outras threads por valor em vez de por referência, garantindo que quaisquer alterações nas variáveis não sejam refletidas em outras threads ou operações. Isso é semelhante à função RunOperation quando em modo assíncrono.