Processamento de esquema e conversão de dados no Jitterbit Integration Studio

Introdução

Durante o processamento, os dados em esquemas podem ser convertidos. Esta página descreve quando e como os dados são convertidos dependendo do tipo de esquema:

• Todos os tipos de esquema
• CSV
• JSON
• XML

Todos os tipos de esquema

Na maioria dos casos (exceções são observadas abaixo), certos dados são convertidos da mesma forma, independentemente do tipo de esquema:

• Tipos de dados
• Nomes de campos e nós
• Valores nulos

Tipos de dados

Estas seções descrevem o suporte do Integration Studio a certos tipos de dados por tipo de esquema. Para todos os tipos de dados suportados em Jitterbit Scripts, veja Tipos de dados em Jitterbit Script.

Tipos de dados de precisão ilimitada

Para a maioria dos tipos de esquema, tipos de dados de precisão ilimitada, como decimal XML, são convertidos para tipos de dados double. Isso impõe um limite de precisão que pode truncar dados.

O limite de precisão está dentro da faixa dos valores mínimo e máximo de um inteiro com sinal de 32 bits, que é –2.147.483.648 a 2.147.483.647. Se estiver fora dessa faixa, considere usar um tipo de dado string em vez disso para evitar truncar dados.

Tipos de dados não primitivos

Os tipos de dados primitivos boolean, date, double, float, integer, long e string, e o tipo de dado não primitivo decimal são suportados em todos os tipos de esquema. Ao criar ou editar um esquema plano ou hierárquico personalizado ou editar qualquer esquema carregado em uma transformação, esses tipos de dados estão disponíveis para escolha no dropdown Tipo. Para novos esquemas personalizados, outros tipos de dados não primitivos, como datetime, não são suportados.

No entanto, outros tipos de dados não primitivos são suportados para esquemas que são gerados automaticamente a partir de um esquema gerado por conector ou foram espelhados a partir de tal esquema. Após serem gerados, esses esquemas também podem ser editados manualmente no editor de esquemas personalizados. Se o esquema contiver algum tipo de dado não primitivo, esses também são listados no dropdown Tipo ao editar tal esquema.

Nomes de campos e nós

Nomes de campos e nós são convertidos em namespaces válidos seguindo o padrão XML. Para referência, consulte NCNameChar para os caracteres permitidos conforme definido pelo W3C.

Ao usar um esquema fornecido por conector, quaisquer caracteres especiais em um nome de campo ou nó de esquema são substituídos por sublinhados (_) conforme necessário para criar um esquema XML válido.

Valores nulos

Campos com valores nulos são incluídos no esquema de dados resultante, apesar de não conter dados. Como também não têm um tipo de dado definido, esses campos são tratados como tendo um tipo de dado string.

Esquemas CSV

Ao usar um esquema CSV, essas regras se aplicam aos seguintes dados:

• Arquivos CSV com cabeçalhos
• Caracteres especiais

Arquivos CSV com cabeçalhos

Ao fornecer um arquivo CSV com uma linha de cabeçalho como um arquivo de esquema de exemplo, essas regras são aplicadas para gerar nomes de colunas:

• Caracteres especiais são substituídos por um ponto de interrogação (?).
• Espaços são substituídos por um sublinhado (_).
• Nomes de colunas em branco são substituídos por f1, f2, f3, e assim por diante.
• Nomes de colunas que começam com um número são prefixados com um sublinhado (_).
• Nomes de colunas repetidos são acrescidos de 2, 3, 4, e assim por diante.

Caracteres especiais

Os caracteres especiais (. _ - $ # @ ?) em esquemas CSV são convertidos nas seguintes circunstâncias:

• Caracteres especiais presentes no lado de origem ou destino de uma transformação são substituídos por um ponto de interrogação (?).
• Caracteres especiais em um script em um campo de destino em uma transformação são substituídos por um ponto de interrogação (?). Esta regra também se aplica a qualquer esquema plano personalizado ou hierárquico personalizado criado em formato CSV.

Esquemas JSON

Ao usar um esquema JSON, a conversão de dados depende da configuração do projeto Preservar nomes JSON:

• Processamento de preservação de nomes JSON: O método padrão usado quando Preservar nomes JSON está habilitado. Isso se aplica a projetos criados após o [lançamento 11.48 Harmony] e executando na versão do agente 11.48 ou posterior.

• Processamento JSON legado: O método padrão usado quando Preservar nomes JSON está desabilitado. Isso se aplica a projetos criados antes do [lançamento 11.48 Harmony] ou executando na versão do agente 11.47 ou anterior. Após a atualização para a versão do agente 11.48 ou posterior, você pode habilitar o processamento de preservação de nomes JSON ativando a configuração do projeto Preservar nomes JSON. No entanto, isso não é recomendado para projetos existentes.

  Não recomendado para projetos existentes

  Para projetos criados antes do [lançamento 11.48 Harmony], habilitar Preservar nomes JSON afeta apenas operações e esquemas configurados após a ativação. Isso cria inconsistências quando misturado com o processamento JSON legado existente.

  Recomendação: Continue usando o processamento JSON legado para projetos existentes ou regenerar todas as operações e esquemas após habilitar este recurso para evitar inconsistências.

A tabela a seguir resume as principais diferenças entre os dois métodos de processamento de JSON:

Processamento de preservação de nomes JSON

Ao usar o Processamento de preservação de nomes JSON (quando Preservação de nomes JSON está habilitada), essas regras se aplicam:

• Tipos de dados (conforme descrito acima)
• Nomes de campos e nós
• Valores nulos

Nomes de campos e nós

Quando se utiliza o processamento de nomes JSON preservados, os nomes de campos e nós são convertidos nas seguintes circunstâncias:

• O processamento de nomes de campos e nós descrito em Todos os tipos de esquema se aplica apenas durante o tempo de design. Em tempo de execução, o nome original do campo ou nó com caracteres especiais é utilizado. Por exemplo, o nome do campo location_ids[] aparece como location_ids__ na transformação durante o tempo de design, mas em tempo de execução, o original location_ids[] é utilizado.

  Para verificar esse comportamento enquanto faz a solução de problemas, consulte Caracteres especiais em esquemas JSON fornecidos pelo conector em Solução de problemas de operação.

• Quando o nome de um campo ou nó de um esquema JSON começa com um número, um sublinhado _ é adicionado antes. Por exemplo, 1text se torna _1text.

Valores nulos

Campos ou nós com valores nulos não são incluídos no esquema de dados resultante.

Processamento JSON legado

Quando o processamento JSON legado é utilizado (quando Preservar nomes JSON está desativado), essas regras se aplicam:

• Tipos de dados (conforme descrito acima)

• Nomes de campos e nós (conforme descrito acima)

  Atenção

  Além do processamento de nomes de campos e nós descrito em Todos os tipos de esquema, ao usar processamento JSON legado, o nome de um campo ou nó de um esquema JSON que começa com um número é substituído por um sublinhado _. Por exemplo, 12345 se torna _2345. Esse problema não ocorre com o processamento de nomes JSON preservados.

• Valores nulos (conforme descrito acima)

Esquemas XML

Ao usar um esquema XML, essas regras se aplicam:

• Namespaces
• Tags de fechamento automático
• Caracteres especiais

Para informações sobre como solucionar erros de esquema XML e transformação, consulte Solução de problemas de operação.

Namespaces

Namespaces em esquemas XML são suportados. Se mais de um namespace for usado em um esquema XML, o agente Jitterbit converte o esquema XML em vários arquivos XSD durante o processamento.

Tags de fechamento automático

Tags de fechamento automático em elementos de esquemas XML são suportadas com alguma manipulação do XML de exemplo usado para gerar o esquema. Para enviar o elemento XML na carga útil sem um valor mapeado, você pode usar uma função Jitterbit e uma variável Jitterbit, conforme descrito abaixo.

Manipular o XML de exemplo

A manipulação é necessária quando um arquivo XML de exemplo usa notação abreviada para uma tag de abertura e fechamento em um elemento como este:

<tag/>

Se tal abreviação for usada em um esquema XML diretamente, o nó não poderá ser mapeado quando usado como o esquema de destino de uma transformação.

Para resolver, manipule o XML de exemplo que está sendo usado para gerar o esquema para expandir as tags de abertura e fechamento que cercam o elemento e forneça um valor de exemplo para que um tipo de dado seja atribuído ao elemento:

<tag>exemplo</tag>

O elemento aparecerá então como um campo no esquema XML e, quando usado como o esquema de destino em uma transformação, você poderá mapear para esse campo.

Mapear para o campo XML

Se você não tiver um objeto ou variável de origem para mapear para o campo de destino, pode colocar a função Jitterbit Null no script de transformação para usar como o valor mapeado:

<trans>
Null()
</trans>

Acima da transformação usando o esquema XML, defina uma dessas variáveis Jitterbit (dependendo de qual for apropriada para seu caso de uso) para controlar o que é enviado:

• XML vazio: Para enviar um nó XML vazio na carga útil, use jitterbit.target.xml.include_empty_xml:

$jitterbit.target.xml.include_empty_xml=true;

• XML Nulo: Para enviar um valor nulo na carga XML, use jitterbit.target.xml.include_null_xml:

$jitterbit.target.xml.include_null_xml=true;

• Excluir XML Vazio: Para excluir um nó XML vazio com um tipo de dado booleano, use jitterbit.target.xml.exclude_empty_data:

$jitterbit.target.xml.exclude_empty_data=true;

Caracteres especiais

Os caracteres especiais em esquemas XML são convertidos nessas circunstâncias:

• Caracteres especiais em um script em um campo de destino em uma transformação são substituídos por um ponto de interrogação (?).

• Esses caracteres especiais em um campo ou nome de nó de esquema XML não são suportados (já que o XML não os suporta):

  $ # @ ?

Solucionar problemas de processamento de esquema

Problemas conhecidos

Campos mapeados em branco com esquemas de origem planos

Ao usar um esquema de origem plano, os campos de destino podem não ser mapeados corretamente e aparecer em branco em certas circunstâncias. Esse problema não ocorre com esquemas espelhados ou esquemas JSON.

Solução alternativa: Adicione um script no início da operação para desativar as transformações de streaming:

$jitterbit.transformation.auto_streaming = false;

Otimizar o uso de memória

Para transformações que processam arquivos grandes e não podem usar streaming, você pode configurar o particionamento para reduzir o uso de memória.

Configurar particionamento

O particionamento divide grandes conjuntos de dados em pedaços menores para processamento. Configure o particionamento no nível da operação:

1. Abra as configurações da operação a partir de uma destas localizações:

2. Aba Workflows do painel do projeto

3. Aba Components do painel do projeto

4. Tela de design (clique duas vezes na operação)

5. Selecione a aba Options.

6. Defina o tamanho do bloco o maior possível, garantindo que cada bloco caiba na memória disponível.

Para fontes e destinos XML muito grandes, a fragmentação pode ser sua única opção se o streaming não for aplicável.

Prevenir transferências de arquivos duplicados

O Harmony rastreia arquivos processados para evitar transferências duplicadas. Antes de transferir um arquivo, o sistema verifica estes três critérios:

• Nome do arquivo
• Data de modificação
• ID da operação

Se todos os três critérios corresponderem a um arquivo processado anteriormente, o sistema ignora a transferência.

Essa deduplicação automática garante que a reexecução de operações não reprocesse arquivos inalterados.