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

Introdução

Cada operação pode ser configurada com opções como quando a operação irá expirar, o que registrar e o período para registro de depurar da operação. A presença de certos componentes como etapas da operação torna visíveis opções adicionais para se uma operação subsequente será executada e se deve usar fragmentação de dados.

Opções de operação de acesso

A opção Configurações para operações pode ser acessada nestes locais:

• A aba Workflows do painel do projeto (consulte menu de ações do componente na aba Workflows do painel Projeto).
• A aba Componentes do painel do projeto (consulte menu de ações do componente na aba Componentes do painel Projeto).
• A quadro de design (veja menu de ações do componente em Tela de design).

Depois que a tela de configurações da operação estiver aberta, selecione a aba Opções:

Configurar opções de operação

Cada opção disponível na aba Opções das configurações de operação é descrita abaixo.

• Tempo limite da operação: Especifique o tempo máximo que a operação será executada antes de ser cancelada. No primeiro campo, insira um número e no segundo campo use o menu suspenso para selecionar as unidades em Segundos, Minutos ou Horas. O padrão é 2 horas.

  Os motivos comuns para ajustar o valor do Tempo limite de operação incluem estes:

  • Aumente o valor do tempo limite se a operação tiver grandes conjuntos de dados que estão demorando muito para serem executados.

  • Diminua o valor do tempo limite se a operação for sensível ao tempo; ou seja, você não quer que a operação seja bem-sucedida se não puder ser concluída dentro de um determinado período.

  Nota

  Operações que são acionadas por APIs do API Manager não estão sujeitos à configuração Operation Time Out ao usar agentes de nuvem. Em agentes privados, use o EnableAPITimeout configuração no arquivo de configuração do agente privado para que a configuração Tempo limite de operação seja aplicada a operações acionadas por APIs.

• O que registrar: Use o menu suspenso para selecionar o que registrar nos registros de operação, um de Tudo (padrão) ou Somente erros:

  • Tudo: Operações com qualquer status da operação são registrados.

  • Somente erros: Somente operações com um status de tipo de erro (como Erro, Falha SOAP ou Sucesso com erro filho) são registradas. Operações filho bem-sucedidas não são registradas. Operações pai (nível raiz) são sempre registradas, pois exigem registro para funcionar corretamente.

    Um motivo comum para limitar os logs a Somente Erros é se você estiver tendo problemas de latência de operação. Dessa forma, se você não estava planejando usar as outras mensagens que não são de erro normalmente filtradas nos logs de operação, você pode evitar que elas sejam geradas em primeiro lugar.

• Habilitar Modo de Depuração Até: Selecione para habilitar o registro de depurar da operação e especifique uma data em que o modo de depurar será desabilitado automaticamente, limitado a duas semanas a partir da data atual. O registro de depurar da operação será desativado no início dessa data (ou seja, 12:00 am) usando o fuso horário do agente.

  Ao selecionar Enable Debug Mode Until, uma caixa de diálogo fornece uma caixa de seleção Also Apply to Child Operations que irá cascatear as configurações para quaisquer operações filhas. Esta opção também é fornecida ao limpar a configuração do modo de depurar da operação.

  

  Quando o registro de depurar da operação está habilitado, esses tipos de registros são gerados, dependendo do tipo de agente:

  • Agente privado: Arquivos de log de depuração para uma operação. Esta opção é usada principalmente para depurar problemas durante os testes e não deve ser ativada na produção, pois pode criar arquivos muito grandes. O log de depuração também pode ser habilitado para todo o projeto a partir do próprio agente privado (consulte Log de depurar da operação). Os arquivos de log de depurar são acessíveis diretamente em agentes privados e podem ser baixados por meio do Management Console Agentes e Operações de tempo de execução páginas.

  • Agente privado ou agente de nuvem: Dois tipos de logs podem ser gerados:

    • Dados de entrada e saída do componente: Dados gravados em an Integration Studio registro de operação para uma operação em execução na versão do agente 10.48 ou posterior. Os dados são retidos por 30 dias pelo Harmony.

    • Logs de operação da API: Logs de operação para operações de API bem-sucedidas (configuradas 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.

  Para obter detalhes adicionais, consulte Registro de depurar de operação para agentes de nuvem ou Registro de depurar de operação para agentes privados.

  Cuidado

  A geração de dados de entrada e saída do componente não é afetada pela configuração do grupo de agentes Cloud logging enabled. Os dados de entrada e saída do componente serão registrados na nuvem Harmony mesmo se o registro na nuvem estiver desativado.

  Para desabilitar a geração de dados de entrada e saída de componentes em um grupo de agentes privados, no arquivo de configuração do agente privado sob o [VerboseLogging] seção, conjunto verbose.logging.enable=false.

  Aviso

  Quando os dados de entrada e saída do componente são gerados, todos os dados de solicitação e resposta para essa operação são registrados na nuvem Harmony e permanecem lá por 30 dias. Esteja ciente de que informações de identificação pessoal (PII) e dados confidenciais, como credenciais fornecidas em uma payload de solicitação, serão visíveis em texto não criptografado nos dados de entrada e saída dentro dos logs da nuvem Harmony.

• Executar Operação de Sucesso Mesmo Se Não Há Arquivos de Origem Correspondentes: Selecione para forçar uma operação acima na cadeia a ser bem-sucedida. Isso efetivamente permite que você inicie uma operação com uma condição Em Sucesso (configurada com uma ação de operação) mesmo que o gatilho tenha falhado.

  Esta opção é aplicável somente se a operação contiver uma API, Compartilhamento de arquivo, FTP, HTTP, Armazenamento local, SOAP, Armazenamento Temporário, ou Atividade variável que é usado como uma fonte na operação e se aplica somente quando a operação tem uma condição On Success configurada. Por padrão, qualquer operação On Success é executada somente se tiver um arquivo de fonte 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 [OperationEngine] seção do arquivo de configuração do agente privado substitui a configuração Executar operação com sucesso mesmo se não houver arquivos de origem correspondentes.

• Habilitar chunking: Selecione para habilitar o fragmentação de dados usando os parâmetros especificados:

  • Tamanho do bloco: Insira um número de registros de origem (nós) para processar para cada thread. Quando o fragmentação de dados é habilitado para operações que não contêm nenhuma atividade baseada no Salesforce, o tamanho do bloco padrão é 1. Quando uma atividade baseada no Salesforce é adicionada a uma operação que não tem o fragmentação de dados habilitado, o fragmentação de dados é habilitado automaticamente com um tamanho de chunk padrão de 200. Se estiver usando uma atividade em massa baseada no Salesforce, você deve alterar esse padrão para um número muito maior, como 10.000.

  • Número de registros por arquivo: Insira um número solicitado de registros a serem colocados no arquivo de destino. O padrão é 0, o que significa que não há limite para o número de registros por arquivo.

  • Número máximo de threads: Insira o número de threads simultâneos a serem processados. Quando o fragmentação de dados é habilitado para operações que não contêm nenhuma atividade baseada no Salesforce, o número padrão de threads é 1. Quando uma atividade baseada no Salesforce é adicionada a uma operação que não tem o fragmentação de dados habilitado, o fragmentação de dados é habilitado automaticamente com um número padrão de threads de 2.

  Esta opção está presente somente se a operação contiver uma transformação ou um banco de dados, NetSuite, Salesforce, Salesforce Service Cloud, ServiceMax, ou atividade SOAP, e é usado para processar dados para o sistema de destino em blocos. Isso permite um processamento mais rápido de grandes conjuntos de dados e também é usado para lidar com limites de registro impostos por vários sistemas baseados em serviços da web ao fazer uma solicitação.

  Observe que se você estiver usando um endpoint baseado em Salesforce ( Salesforce, Salesforce Service Cloud ou ServiceMax ):

  • Se uma atividade baseada no Salesforce for adicionada a uma operação que não tenha o fragmentação de dados habilitado, o fragmentação de dados será habilitado com configurações padrão especificamente para atividades baseadas no Salesforce, conforme descrito acima.

  • Se uma atividade baseada no Salesforce for adicionada a uma operação que já tenha o fragmentação de dados habilitado, as configurações de fragmentação de dados não serão alteradas. Da mesma forma, se uma atividade baseada no Salesforce for removida de uma operação, as configurações de fragmentação de dados não serão alteradas.

  Informações adicionais e práticas recomendadas para fragmentação de dados são fornecidas na próxima seção, Chunking.

• Salvar alterações: Clique para salvar e fechar as configurações da operação.

• Descartar alterações: Após fazer alterações nas configurações da operação, clique para fechar as configurações sem salvar.

Fragmentação

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

O chunking pode ser usado somente se os registros forem independentes e de uma fonte não LDAP. Recomendamos usar um tamanho de chunk tão grande quanto possível, certificando-se de que os dados de um chunk se encaixem na memória disponível. Para métodos adicionais para limitar a quantidade de memória que uma transformação usa, consulte Processamento de Transformação.

Limitações da API

Muitas APIs de serviços da Web (SOAP/REST) têm limitações de tamanho. Por exemplo, um upsert baseado no Salesforce aceita apenas 200 registros para cada chamada. Com memória suficiente, você pode configurar uma operação para usar um tamanho de bloco de 200. A origem seria dividida em blocos de 200 registros cada, e cada transformação chamaria o serviço da Web uma vez com um bloco de 200 registros. Isso seria repetido até que todos os registros fossem processados. Os arquivos de destino resultantes seriam então combinados. (Observe que você também pode usar atividades em massa baseadas no Salesforce para evitar o uso de fragmentação de dados.)

Processamento paralelo

Se você tiver uma fonte grande e um computador com várias CPUs, o fragmentação de dados pode ser usado para dividir a fonte para processamento paralelo. Como cada chunk é processado isoladamente, vários chunks podem ser processados em paralelo. Isso se aplica somente se os registros de origem forem independentes uns dos outros no nível do nó do chunk. Os serviços da Web podem ser chamados em paralelo usando fragmentação de dados, melhorando o desempenho.

Ao usar fragmentação de dados em uma operação onde o alvo é um banco de dados, observe que os dados alvo são primeiro gravados em vários arquivos temporários (um para cada chunk). Esses arquivos são então combinados em um arquivo alvo, que é enviado ao banco de dados para inserção/atualização. Se você definir a variável Jitterbit jitterbit.target.db.commit_chunks para 1 ou true quando o fragmentação de dados está habilitado, cada chunk é, em vez disso, confirmado no banco de dados conforme se torna disponível. Isso pode melhorar o desempenho significativamente, pois as inserções/atualizações do banco de dados são realizadas em paralelo.

Use variáveis com fragmentação de dados

Como o fragmentação de dados pode invocar multithreading, seu uso pode afetar o comportamento de variáveis que não são compartilhadas entre os threads.

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

Por exemplo, se uma operação — com fragmentação de dados e vários threads — tiver uma transformação que altere uma variável global, o valor da variável global após o término da operação será aquele do primeiro thread. Quaisquer alterações na variável em outros threads são independentes e são descartadas quando a operação é concluída.

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