Ir para o conteúdo

Solução de problemas de operações no Jitterbit Integration Studio

Introdução

Se você encontrar problemas ao executar uma operação, as seguintes ações de solução de problemas são recomendadas.

Testar a conexão

Para qualquer operação que utilize conectores, na conexão, clique no botão Testar para garantir que a conexão seja bem-sucedida.

Para conectores baseados no Connector SDK implantados em operações que estão sendo executadas em agentes privados, clicar no botão Testar garante que a versão mais recente do conector seja baixada para o agente (a menos que esteja usando a política de organização Desativar Atualização Automática do Conector).

Verificar os logs da operação

Verifique os logs da operação para qualquer informação registrada durante a execução da operação.

Dependendo do tipo de agente, você pode fazer o seguinte para recuperar arquivos de log e dados adicionais:

Possíveis erros nos logs da operação

As seções a seguir abordam erros que podem estar presentes em um log de operação e suas resoluções.

Aviso de subelemento extra

Um aviso de subelemento extra nas mensagens de log pode geralmente ser ignorado. Este aviso indica que a carga útil da API de um conector retornou mais nós ou campos de dados do que os definidos no esquema de dados da resposta.

Caracteres não permitidos nos mapeamentos de esquema XML

Dependendo da atividade do conector, esses caracteres são inválidos e resultarão em um erro em tempo de execução:

\x00 (NULL) \x0E (shift out)
\x01 (início do cabeçalho) \x0F (shift in)
\x02 (início do texto) \x1A (caractere de substituição)
\x03 (fim do texto) \x1B (escape)
\x04 (fim da transmissão) \x1C (separador de arquivo, separador de informação quatro)
\x05 (consulta) \x1D (separador de arquivo, separador de informação três)
\x06 (confirmação) \x1E (separador de arquivo, separador de informação dois)
\x07 (sino) \x1F (separador de arquivo, separador de informação um)
\x08 (retrocesso) \xD800 a \xDFFF (caracteres de substituição alta UTF-16)
\x0B (tabulação vertical) \xFFFE
\x0C (alimentação de formulário) \xFFFF

Quando os dados de entrada ou saída fornecidos a ou retornados de uma transformação adjacente a uma atividade de conector baseada em XML contêm um dos caracteres acima, um erro específico referenciando esse caractere é retornado em tempo de execução. Por exemplo, quando o caractere de controle \x1E está presente na transformação de resposta para a atividade Get BAQ do Epicor Kinetic, este erro é retornado em tempo de execução:

A exceção é caractere de espaço em branco inválido (0x1e) no texto a ser enviado

Elementos XML não suportados quando incorporados em JSON

Seções de dados de caractere (CDATA) não são suportadas com XML incorporado em JSON destinado a ser enviado através de uma transformação. Incluir seções CDATA pode causar o seguinte erro a aparecer em um log de operação em tempo de execução:

Transformação falhou. Erro: A operação "Operação" falhou.
Erro: Falha ao converter arquivo XML para JSON.
org.jitterbit.integration.server.engine.EngineSessionException: org.xml.sax.SAXParseException ...

Para contornar isso, use um script Jitterbit para Substituir os caracteres &, <, >, ' e " de toda a seção CDATA, incluindo sua definição (<![CDATA[ ... ]]>), por &amp, &lt, &gt, &apos, &quot respectivamente. Se necessário, a string XML inteira contendo a seção CDATA pode ser substituída se o direcionamento da seção não se encaixar no seu caso de uso.

O seguinte exemplo é considerado inválido sem substituições:

{
  "name": "Jitterbit",
  "data": "<xml><content><![CDATA[<greeting>Hello, world!</greeting>]]></content></xml>"
}

Reprocessamento de esquemas XML espelhados

Devido a mudanças feitas nas versões do Harmony 10.25 e 10.27, você pode observar um comportamento diferente em projetos criados antes dessas versões. Essas mudanças afetam esquemas XML que foram espelhados e provavelmente impactarão mapeamentos que usam funções XML que envolvem namespaces, como a função SelectNodes. Nesse caso, mapeamentos que eram anteriormente válidos podem agora ser inválidos com um erro relacionado à sintaxe da função XML.

Compare as diferenças entre este exemplo de esquema XML espelhado antes de 10.25 com um criado em 10.25 ou posterior:

XML schema annotated

  • Exemplo de Esquema XML Antes da 10.25: Em projetos criados antes da 10.25, esquemas XML espelhados usam o prefixo de namespace padrão para documentos XML: xsi. Como mostrado destacado em vermelho acima, xmlns:xsi declara o namespace e campos não mapeados são exibidos no esquema com o atributo xsi:nil="true".
  • Exemplo de Esquema XML na 10.25 e Posteriores: Em projetos criados na 10.25 e posteriores e destacados em verde acima, esquemas XML espelhados usam o prefixo de namespace ns para declarar um namespace qualificado. Campos não mapeados não são exibidos no esquema.

Nas versões 10.25 e 10.26, se você importou um projeto com um esquema XML espelhado que foi criado antes da 10.25, o esquema foi reprocessado e alterado para usar o prefixo de namespace qualificado.

A partir da versão 10.27, projetos importados cujos esquemas XML espelhados foram criados antes da 10.25 mantêm o prefixo de namespace padrão do esquema XML, de modo que o esquema é idêntico ao que foi criado. Essa mudança significa que quaisquer projetos anteriores à 10.25 que forem importados para a versão atual devem funcionar como originalmente projetados.

Para forçar uma atualização de um esquema XML anterior à 10.25 para usar o prefixo de namespace atualizado, você pode regenerar o esquema atualizando-o ou reconfigurando a atividade que fornece o esquema.

Caracteres especiais em esquemas JSON fornecidos pelo conector

Quando uma transformação usa um esquema JSON herdado de uma atividade de conector adjacente, quaisquer caracteres especiais em um campo ou nome de nó do esquema são substituídos por sublinhados (_).

Ao usar o processamento JSON legado (o padrão para projetos criados antes do lançamento Harmony 11.48), esse comportamento pode causar erros a serem retornados do endpoint.

Por exemplo, se a atividade fornecer um nome de campo location_ids[], ele será convertido para location_ids__, no entanto, o endpoint ainda espera o nome de campo original location_ids[] e retorna o erro, como "error_message": "{location_ids:expected String to be a Array}",}}.

Para resolver esse problema, siga estas etapas:

  1. Confirme que um esquema JSON está sendo usado na atividade afetada. Esses esquemas terão um nó raiz chamado json:

    json schema

  2. Configure o projeto para usar o Processamento de nomes JSON preservados ativando a configuração de Preserve JSON names configuração do projeto (é necessário a versão do agente 11.48 ou posterior).

  3. Reconfigure, implante e execute a operação.

    Importante

    Quando Preserve JSON names está ativado em um projeto onde atualmente está desativado, observe que o Processamento de nomes JSON preservados será usado apenas para operações e esquemas configurados após a ativação da configuração. Ou seja, operações e esquemas existentes continuarão usando o processamento JSON legado. Recomendamos reconfigurar todas as operações e esquemas existentes em tais projetos, pois usar ambos os métodos de processamento de esquemas em um único projeto pode causar inconsistências no projeto.

Ao usar o Processamento de nomes JSON preservados, você pode verificar o nome do campo ou nó que está sendo passado para o endpoint visualizando o jsonPropertyName nos dados de entrada ou saída da atividade quando o registro de depuração está ativado (para agentes em nuvem ou para agentes privados). O valor do jsonPropertyName é o valor que está sendo enviado na solicitação:

jsonPropertyName