Ir para o conteúdo

Resolva conflitos e erros de mapeamento de transformação no Jitterbit Integration Studio

Introdução

Os mapeamentos de transformação devem ser válidos para que uma transformação seja válida. Esta página descreve como identificar mapeamentos inválidos e visualizar os erros de validação associados a eles. Também explica como resolver erros de validação.

Para evitar problemas de validação, consulte Testar e validar transformações.

Erros de validação

As transformações são tratadas da mesma forma que outros componentes do projeto ao identificar a validade dos componentes em uma escala de projeto. Você pode identificar transformações inválidas no canvas de design e no painel do projeto, conforme descrito em Validade do componente. Erros de validação dentro de um mapeamento estão incluídos na validação das transformações.

Para que uma transformação seja válida, não deve haver erros de validação dentro da própria transformação. Para ser considerada válida, uma transformação deve atender a estas regras:

  • Um mapeamento não pode conter referências a campos ou variáveis inexistentes.
  • Um mapeamento não pode conter conflitos de tipo de dado.
  • Um mapeamento deve usar uma sintaxe de script válida.
  • Um nó de loop de destino não pode ter múltiplas fontes.
  • Um esquema deve ser fornecido para uma atividade de origem ou destino adjacente.

Além disso, certos campos de destino podem exigir um mapeamento ou podem não permitir um mapeamento. Por exemplo, os campos unidos de uma tabela filha não podem ser mapeados. Detalhes adicionais são fornecidos sob Regras de validação mais adiante nesta página.

Para resolver erros de validação, você pode identificar erros dentro da própria transformação e fazer ajustes conforme necessário. Mapeamentos inválidos são exibidos para um bloco de campo de destino inteiro ou para objetos mapeados individuais dentro de um bloco de campo de destino.

Bloco de campo de destino inteiro

Quando um mapeamento de campo de destino inteiro é inválido, uma linha vertical vermelha aparece ao longo da esquerda do bloco do campo de destino. Um ícone de aviso é exibido no canto superior direito do campo de destino. Ao passar o mouse sobre o ícone de aviso, o motivo pelo qual o mapeamento é inválido é listado.

Esse tipo de mapeamento inválido pode resultar do mapeamento de campos que não podem ser mapeados. Por exemplo, esse erro ocorre quando você tenta mapear para um ID de objeto único em uma atividade de Inserção do Salesforce usada como destino.

campo de destino inválido

Quando um mapeamento de campo de destino inteiro é potencialmente inválido, uma linha vertical laranja aparece ao longo da esquerda do bloco do campo de destino. Ao passar o mouse sobre o campo, o motivo pelo qual o mapeamento pode ser inválido é listado.

Esse tipo de mapeamento inválido pode resultar da ausência de um mapeamento que pode ser necessário. Por exemplo, esse erro ocorre quando uma chave primária não está mapeada em uma atividade de Inserção de Banco de Dados usada como destino.

campo de destino potencialmente inválido

Mapeamentos inválidos ou potencialmente inválidos também podem resultar de múltiplos objetos (como mais de um objeto de origem ou variável) sendo mapeados para um campo de destino sem qualquer lógica especificando como processar esses objetos.

Para resolver mapeamentos inválidos, remova o mapeamento ou abra o script do campo para adicionar lógica de processamento. Mapeamentos potencialmente inválidos têm a intenção de sinalizar um problema potencial, mas podem ser deixados como estão se você determinar que o mapeamento é válido.

Para remover um mapeamento, passe o mouse sobre o campo de destino e use o ícone Remover mapeamento.

Para adicionar lógica de processamento a um campo com um mapeamento inválido, passe o mouse sobre o campo de destino e clique no ícone Editar.

Objeto mapeado individual

Quando um objeto mapeado individual dentro de um campo de destino é inválido, o objeto mapeado é destacado em vermelho com um ícone de aviso exibido à direita:

objeto inválido do campo de destino

Os mapeamentos individuais podem ser inválidos se um objeto de origem mapeado não estiver mais presente após a edição de um esquema, se houver uma incompatibilidade de obrigatório/opcional com a cardinalidade de um campo de destino, ou se os campos de origem e destino tiverem tipos de dados incompatíveis.

O mapeamento de campos de origem e destino com tipos de dados potencialmente incompatíveis é sinalizado para todos os esquemas, independentemente de terem tipos de dados definidos, como aqueles definidos a partir de uma atividade do Salesforce ou Banco de Dados. Essa sinalização também ocorre para esquemas que possuem apenas rótulos de tipo de dados, como aqueles definidos a partir de um arquivo de amostra ou que foram definidos manualmente. Para esses tipos de esquemas, todos os campos são tratados como strings, independentemente de terem rótulos de tipo de dados.

Uma incompatibilidade de tipo de dados não indica necessariamente que há um problema com o mapeamento. Por exemplo, se um campo de origem com um tipo de dado inteiro é mapeado para um campo de destino com um tipo de dado string, os dados resultantes são uma string que contém um valor numérico. Campos de origem com qualquer tipo de dado podem ser mapeados para um campo de destino com um tipo de dado string, portanto, esses mapeamentos não são sinalizados.

incompatibilidade de tipo de dados do campo de destino

No entanto, se o contrário for verdadeiro, e um campo de origem com um tipo de dado string ou outro tipo de dado for mapeado para um tipo de dado de destino incompatível, tais mapeamentos podem ser sinalizados como potencialmente incompatíveis. Campos mapeados com tipos de dados que são potencialmente incompatíveis são exibidos com uma borda laranja:

incompatibilidade de tipo de dados do campo de destino

Quando você passa o mouse sobre o campo, o motivo da potencial incompatibilidade é listado. Para remover o mapeamento, clique no ícone Remover mapeamento.

A indicação de um possível conflito de tipo de dado aparece apenas para mapeamentos simples de um objeto de origem para um campo de destino e não é exibida se o campo de destino contém lógica de script.

Para campos de destino que são mapeados usando lógica de script, após o processamento do script e a avaliação do resultado, o valor é convertido para o tipo de dado do campo de destino ao qual está sendo mapeado. Espera-se que você saiba, com base na saída sendo convertida para o tipo de dado do campo de destino, se essa saída final é o resultado desejado.

Como exemplo, considere um campo de destino com um tipo de dado double. Independentemente do tipo de dado no script, após o processamento do script, a saída final para o mapeamento é convertida para um double. Isso é ilustrado com os exemplos de script de transformação abaixo.

Transformation Script 1
<trans>
1 + "string"
</trans>

O script acima avalia para um valor de "1string" com um tipo de dado string. Então, durante o processamento do mapeamento de transformação, essa saída é convertida para um tipo de dado double. Como a saída começa com um dígito, qualquer(s) dígito(s) inicial(is) são mantidos na saída final do mapeamento, já que números são válidos para um double. A saída final para o mapeamento é um valor de 1 com um tipo de dado double.

Transformation Script 2
<trans>
"string" + 1
</trans>

O segundo script, acima, avalia para um valor de "string1" com um tipo de dado string. Durante o processamento do mapeamento de transformação, essa saída é convertida para um tipo de dado double. Neste caso, como um valor não numérico, que não é válido para um double, está no início do valor retornado, nenhum valor é mantido. Em vez disso, o campo de destino assume o valor padrão para um número. A saída final para o mapeamento é um valor de 0 com um tipo de dado double.

Em alguns casos, você pode querer substituir o tipo de dado do campo de destino e realmente manter a saída usando um tipo de dado diferente. Para essas situações, você pode usar as funções Format ou FormatDate dentro do script de mapeamento do campo de destino. Certifique-se de que a função esteja na última instrução do script, pois o valor retornado do script sempre vem da última linha.

Regras de validação

Para que uma transformação seja válida, ela deve ser configurada corretamente. As mensagens de erro descritas abaixo são exibidas ao visualizar os erros de validação associados à transformação como um componente no painel de design ou painel de projeto, conforme descrito em Validade do componente.

Se uma transformação não foi configurada ou está mal configurada, esta mensagem de erro de validação é retornada:

A transformação não está configurada corretamente.

Essa mensagem aparece com mais frequência quando você adicionou uma nova transformação a uma operação e ela ainda não foi configurada. Para resolver esse erro, abra a tela de configuração da transformação e configure-a adequadamente. Não é necessário que uma transformação contenha mapeamentos se seu esquema de destino consistir apenas em nós sem campos. Se o esquema de destino contiver campos, pelo menos um mapeamento deve estar presente para que a transformação seja configurada corretamente.

Além disso, para que uma transformação seja válida, ela não deve ter erros de validação dentro da própria transformação. Para ser considerada válida, uma transformação deve atender a estas regras:

  • Um mapeamento não pode conter referências a campos ou variáveis inexistentes.
  • Um mapeamento não pode conter conflitos de tipo de dado.
  • Um mapeamento deve usar uma sintaxe de script válida.
  • Um nó de loop de destino não pode ter múltiplas fontes.
  • Um esquema deve ser fornecido para uma atividade de fonte ou destino adjacente.

Além disso, certos campos de destino podem exigir um mapeamento ou podem não permitir um mapeamento. Por exemplo, os campos unidos de uma tabela filha não podem ser mapeados. Mapeamentos inválidos são indicados visualmente na tela de configuração da transformação, conforme descrito em Erros de validação anteriormente nesta página.

Dependendo do erro, a variação apropriada dessas possíveis mensagens de erro é retornada se esta regra não for atendida:

O mapeamento refere-se a um campo [source / target / variable] inexistente $[path].

Conflito potencial de tipo de dado no mapeamento.

O campo de destino $[node.name] [deve ser mapeado / não pode ser mapeado].

O campo de destino $[node.name] está vinculado a [database joins] de seu pai. Você não pode mapear um valor para este elemento.

registros: Erro na linha [#]: [Erro de sintaxe de validação de script].

Mapeamentos de um nó de loop de destino dependem de mais de um nó de loop de origem.

O esquema [Source / Target] deve ser fornecido.

Para resolver esses erros, tente estas dicas de solução de problemas:

  • Se você tiver referências a campos inexistentes, conflitos de tipo de dado ou outros mapeamentos inválidos, encontre o mapeamento inválido e desmapeie-o ou verifique o esquema para garantir que todos os campos estejam contabilizados e tenham tipos de dados compatíveis. Se você tiver referências a variáveis inexistentes, verifique se a variável existe.
  • Se você tiver erros de validação de script, verifique o mapeamento e faça ajustes dentro do script. As mensagens de validação também são exibidas abaixo de cada script relatado linha por linha. Após resolver um erro em uma linha, erros de sintaxe adicionais a serem resolvidos podem ser relatados para linhas subsequentes. Continue fazendo alterações até que a mensagem indique que o script é válido.
  • Se você tiver atividades de origem ou destino adjacentes à transformação, certifique-se de fornecer um esquema para cada uma. Você pode fornecer esquemas dentro da atividade durante sua configuração (veja a documentação para cada conector), ou definindo um esquema diretamente dentro da transformação.

Além disso, se uma transformação for inválida por algum outro motivo que não possa ser facilmente determinado, esta mensagem de erro é retornada:

A transformação é inválida.

Para mais informações sobre prevenção e solução de problemas, consulte os seguintes recursos: