Ir para o conteúdo

Padrões de operação válidos e erros de validação

Introdução

As operações devem ser válidas para serem implantadas. Esta página aborda como identificar operações inválidas e visualizar os erros de validação associados a elas, bem como como resolver erros de validação usando um padrão de operação válido. Exemplos de arranjos de operação comuns também são fornecidos.

Erros de validação

Esta seção aborda como identificar operações inválidas e visualizar os erros de validação associados a operações inválidas.

Para novos projetos, os itens inválidos são destacados por padrão na quadro de design, com a seleção padrão de Destacar Itens Inválidos. Para desativar esta opção, limpe esta seleção:

destacar itens inválidos

Quando Destacar itens inválidos é selecionado, todas as operações ou componentes inválidos são delineados na cor vermelha e têm um ícone inválido ao lado do nome na quadro de design:

operação inválida

No painel do projeto, os nomes de workflows e componentes inválidos são listados em itálico vermelho e são mostrados com um ícone inválido:

operação inválida

Clique em ícone inválido ao lado do nome da operação para exibir uma mensagem listando os erros de validação da operação.

Operações com um erro implícito podem ser inválidas por qualquer um dos seguintes motivos:

Erro Informações Adicionais
A operação está vazia. A operação deve ter pelo menos uma etapa de operação.
A operação não está em conformidade com nenhum padrão válido. Regras e padrões de operação podem ser encontrados aqui. A operação deve atender aos padrões de operação estabelecidos que garantem que a operação seja suportada e esperada pelo agente. Esses padrões são abordados a seguir em Padrões de validação.
O esquema de transformação [origem / destino] não corresponde à estrutura do esquema fornecida pela atividade ["Nome da atividade"]. Abra a transformação ["Nome da Transformação "] na operação ["Nome da operação"] e atualize o esquema de destino. Em uma operação que contém uma transformação com um esquema fornecido pela atividade, o esquema fornecido pela atividade deve corresponder à estrutura do esquema fornecida por uma atividade adjacente.
A Transformação ["Nome da Transformação "] tem um esquema de origem, mas nenhuma atividade de origem. Remova o esquema de origem da transformação ou adicione uma atividade de origem antes da transformação. Se a operação contiver uma transformação com uma atividade fornecida ou transformação fornecida esquema de origem, deve haver uma atividade de origem precedendo a transformação.

Atividades de destino HTTP que enviam suas respostas para uma segunda atividade de destino só podem enviar respostas para uma atividade de destino em todo o projeto. A atividade HTTP ["Nome da atividade de destino 1"] nesta operação está enviando sua resposta para várias atividades de destino em todo o projeto.

Nesta operação, seu destino é ["Nome da atividade de destino 2A"]. Na operação ["Operação 2"], seu destino é ["Nome da atividade de destino 2B"].

Substitua a atividade ["Nome da atividade de destino 1"] por uma atividade duplicada em uma das operações. Você pode fazer isso localizando a atividade ["Nome da atividade de destino 1"] na guia Componentes, abra o menu e duplique. Arraste a atividade duplicada para a operação.

Em uma operação que usa o Padrão de arquivamento de dois destinos e contém uma atividade de destino HTTP que grava uma resposta para uma segunda atividade de destino, a atividade de destino HTTP também sendo usada em outro Padrão de arquivamento de dois destinos a operação deve gravar na mesma atividade de destino.

Nota

Esta regra de validação pode ser desabilitada, embora isso não seja recomendado. Para mais informações, veja Erros de regra de validação HTTP no final desta página.
"A operação ["Nome da operação"] não pode ter mais de um ouvinte ou atividade baseada em evento: ["Nomes de atividades"]." Uma operação pode conter apenas uma atividade de escuta por operação.
"A operação ["Nome da operação"] tem ["Nome da atividade"] como uma atividade ouvinte ou baseada em eventos -- tais atividades precisam ser as primeiras na operação. A operação deve atender aos padrões de operação estabelecidos para a atividade de escuta. Os padrões de operação com os quais cada atividade de escuta pode ser usada estão listados na documentação de cada atividade.
"A operação ["Nome da operação"] não pode ter o resultado ["Em caso de sucesso" / "Em caso de falha" / "Em caso de falha de SOAP "] para a operação de destino ["Nome da operação 2"] que tem um ouvinte ou um evento como primeira atividade." Uma operação não pode usar ações da operação para invocar outra operação que contém uma atividade de escuta.
"A operação ["Nome da operação"] começa com um ouvinte ou atividade baseada em evento ["Nome da atividade"] e não pode ter uma programação anexada." Uma operação que contém uma atividade de escuta não pode ser executado em um cronograma.
O script "["Nome do Script "] na operação ["Nome da operação"] não pode usar RunOperation() para invocar a operação ["Nome da operação 2"] que tem um ouvinte ou atividade baseada em eventos. Uma operação não pode usar o RunOperation função para invocar outra operação que contém uma atividade de escuta.

O ícone inválido não é exibido se o motivo da operação ser inválida é que ela contém outros componentes com erros implícitos. Componentes de projeto usados como qualquer parte de uma operação devem ser válidos para que a operação seja válida. Isso inclui componentes usados como etapas de uma operação, bem como outros componentes usados em suporte a uma operação. Por exemplo:

  • Um componente usado diretamente como uma etapa na operação, como uma atividade, transformação ou script.
  • Um endpoint do qual uma atividade usada na operação depende.
  • Um componente chamado por um script na operação.

As regras de validação dependem do tipo de componente e são abordadas coletivamente em Validade do componente.

Padrões de validação

Certos padrões de validação devem ser seguidos para que as operações sejam implantadas na nuvem Harmony e executadas em agentes Jitterbit. Esses padrões garantem que todas as partes de um projeto sejam suportadas e esperadas pelo agente:

O diagrama a seguir resume todos os padrões de operação válidos. Cada padrão também é apresentado individualmente e descrito em texto abaixo do diagrama, onde componentes opcionais aparecem em cinza em negrito e componentes obrigatórios aparecem em vermelho em negrito.

padrões de operação anotados pp

Notas de rodapé para padrões de validação

A Se uma cadeia de operação contiver uma atividade de API, ela deve ser a única atividade de API ou API SOAP Request na cadeia de operação e deve ser a fonte da primeira operação. Ou seja, nenhuma outra operação pode estar chamando esta operação de um script ou uma ação de operação "em caso de sucesso" ou "em caso de falha".

B Se uma consulta do Salesforce, Salesforce Service Cloud ou ServiceMax for usada como atividade de origem, uma atividade de destino será necessária.

C As operações não podem incluir mais de uma atividade NetSuite, Salesforce, Salesforce Service Cloud, SAP, ServiceMax ou SOAP.

D Operações que incluem uma atividade Salesforce, Salesforce Service Cloud ou ServiceMax não podem conter nenhuma outra atividade, exceto aquelas associadas à API, Banco de dados, Compartilhamento de arquivo, FTP, HTTP, Armazenamento local, Armazenamento Temporário, ou Variável conectores.

E Somente atividades não em massa podem ser usadas neste local.

F A atividade HTTP deve receber um corpo de solicitação e produzir um corpo de resposta. Uma atividade HTTP GET retorna uma mensagem indicando sucesso {"success": true}ou falha {"success": false}em vez da resposta real.

Perguntas frequentes (perguntas frequentes)

Ao projetar operações, pode ser útil considerar as respostas a estas perguntas frequentes:

  • Qual é a diferença entre uma fonte e um alvo?
    As atividades são consideradas usadas como fonte se elas fornecem dados dentro de uma operação. As atividades são consideradas usadas como alvo se elas recebem dados dentro de uma operação. Para obter explicações adicionais sobre fontes versus destinos e as partes da operação, consulte Criação e configuração da operação.
  • Quais padrões são válidos com meu endpoint?
    Os padrões que podem ser usados com cada tipo específico de atividade são documentados nas páginas de atividades individuais em Conectores. Em cada página de atividade, os padrões específicos que podem ser usados estão incluídos na seção "Próximos passos", que normalmente é a última seção em cada página de atividade.
  • E se meu caso de uso não se encaixar em um padrão válido?
    Se um determinado arranjo de operação desejado não aderir a um padrão válido, você pode usar uma combinação de operações que sigam cada uma um padrão válido. Para fazer isso, crie cada operação separadamente e, em seguida, encadeie-as usando ações de operação.

  • Como posso lembrar desses padrões?
    Operações que não seguem um padrão válido são sinalizadas como inválidas e não podem ser implantadas. Conforme você se familiariza com os padrões, generalizações como essas podem se tornar aparentes:

    • Conectores genéricos baseados em arquivo, como FTP, HTTP e Armazenamento Temporário, podem ser usados sem uma transformação.
    • Na maioria dos casos, conectores de aplicativos para atividades não em massa, como as da Epicor, ServiceNow e Workday, exigem uma transformação.
    • Os Scripts podem ser adicionados em quase qualquer lugar.

  • Há exemplos de como outros montaram operações?
    Para exemplos comuns usando esses padrões, consulte Exemplos de padrões de operação comuns no final desta página, ou consulte cada página de atividade individual em Conectores.

Padrão de arquivo

arquivo de padrão de operação anotado pp

Script(s) + Atividade de origem + Script(s) + Atividade de destino + Script(s)

Nesse padrão, as atividades de origem e destino podem ser associadas a qualquer um desses tipos de endpoint:

A Se uma cadeia de operação contiver uma atividade de API, ela deve ser a única atividade de API ou API SOAP Request na cadeia de operação e deve ser a fonte da primeira operação. Ou seja, nenhuma outra operação pode estar chamando esta operação de um script ou uma ação de operação "em caso de sucesso" ou "em caso de falha".

E Somente atividades não em massa podem ser usadas neste local.

Padrão de Script

script de padrão de operação anotado pp

Script(s) + Atividade Alvo

Nesse padrão, a atividade de destino pode ser associada a qualquer um desses tipos de endpoint:

Padrão de Transformação

transformação de padrão de operação anotada pp

Script(s) + (Grupo: Atividade de origem + Script[s]) + Transformação + (Grupo: Script(s) + Atividade de destino) + Script[s])

Neste padrão, as atividades de origem e/ou destino podem ser associadas a qualquer tipo de endpoint, desde que pelo menos uma atividade seja incluída. Uma transformação não pode existir por si só em uma operação sem uma atividade.

A Se uma cadeia de operação contiver uma atividade de API, ela deve ser a única atividade de API ou API SOAP Request na cadeia de operação e deve ser a fonte da primeira operação. Ou seja, nenhuma outra operação pode estar chamando esta operação de um script ou uma ação de operação "em caso de sucesso" ou "em caso de falha".

B Se uma consulta do Salesforce, Salesforce Service Cloud ou ServiceMax for usada como atividade de origem, uma atividade de destino será necessária.

C As operações não podem incluir mais de uma atividade NetSuite, Salesforce, Salesforce Service Cloud, SAP, ServiceMax ou SOAP.

D Operações que incluem uma atividade Salesforce, Salesforce Service Cloud ou ServiceMax não podem conter nenhuma outra atividade, exceto aquelas associadas à API, Banco de dados, Compartilhamento de arquivo, FTP, HTTP, Armazenamento local, Armazenamento Temporário, ou Variável conectores.

E Somente atividades não em massa podem ser usadas neste local.

Padrão de arquivamento de dois alvos

padrão de operação dois arquivo de destino anotado pp

Script(s) + (Grupo: Atividade de origem 1 + Script[s]) + Transformação + Atividade de destino 1 / Atividade de origem 2 + Script(s) + Atividade de destino 2 + Script(s)

Nesse padrão, a segunda atividade de destino é usada para arquivar uma resposta da atividade do meio, que funciona tanto como o primeiro destino quanto como a segunda fonte.

A resposta da atividade do meio passa pelos dados de resposta brutos para um segundo alvo sem transformá-lo. Isso pode ser pensado como um arquivo ou como uma passagem de dados (às vezes chamada de passthrough).

As atividades de origem e destino devem ser associadas a determinados tipos de endpoint, dependendo de onde são usadas no padrão:

A Se uma cadeia de operação contiver uma atividade de API, ela deve ser a única atividade de API ou API SOAP Request na cadeia de operação e deve ser a fonte da primeira operação. Ou seja, nenhuma outra operação pode estar chamando esta operação de um script ou uma ação de operação "em caso de sucesso" ou "em caso de falha".

C As operações não podem incluir mais de uma atividade NetSuite, Salesforce, Salesforce Service Cloud, SAP, ServiceMax ou SOAP.

D Operações que incluem uma atividade Salesforce, Salesforce Service Cloud ou ServiceMax não podem conter nenhuma outra atividade, exceto aquelas associadas à API, Banco de dados, Compartilhamento de arquivo, FTP, HTTP, Armazenamento local, Armazenamento Temporário, ou Variável conectores.

E Somente atividades não em massa podem ser usadas neste local.

Padrão de arquivo HTTP de dois alvos

padrão de operação dois arquivo HTTP de destino anotado pp

Script(s) + Atividade de origem 1 + Script(s) + Transformação + Script(s) + Atividade de destino 1 / Atividade de origem 2 + Atividade de destino 2 + Script(s)

Neste padrão, a segunda atividade de destino é usada para arquivar uma resposta da atividade do meio, que funciona tanto como o primeiro destino quanto como a segunda fonte. Este padrão é diferente do Padrão de arquivamento de dois destinos em que a atividade do meio é uma atividade HTTP.

A resposta da atividade HTTP do meio passa pelos dados de resposta brutos para um segundo alvo sem transformá-lo. Isso pode ser pensado como um arquivo ou como uma passagem de dados (às vezes chamada de passthrough).

As atividades de origem e destino devem ser associadas a determinados tipos de endpoint, dependendo de onde são usadas no padrão:

  • Atividade de origem 1 A: Se usada, a primeira atividade de origem pode ser associada a qualquer tipo de endpoint.
  • Atividade de destino 1 / Atividade de origem 2: A primeira atividade de destino (também chamada de segunda atividade de origem) pode ser associada a qualquer um destes tipos de endpoint:
  • Atividade de destino 2: A segunda atividade de destino pode ser associada a qualquer um destes tipos de endpoint:

A Se uma cadeia de operação contiver uma atividade de API, ela deve ser a única atividade de API ou API SOAP Request na cadeia de operação e deve ser a fonte da primeira operação. Ou seja, nenhuma outra operação pode estar chamando esta operação de um script ou uma ação de operação "em caso de sucesso" ou "em caso de falha".

E Somente atividades não em massa podem ser usadas neste local.

F A atividade HTTP deve receber um corpo de solicitação e produzir um corpo de resposta. Uma atividade HTTP GET retorna uma mensagem indicando sucesso {"success": true}ou falha {"success": false}em vez da resposta real.

Padrão de duas transformações

padrão de operação dois transformação anotada pp

Script(s) + (Grupo: Atividade de origem 1 + Script[s]) + Transformação 1 + Atividade de destino 1 / Atividade de origem 2 + Transformação 2 + Script(s) + Atividade de destino 2 + Script(s)

Nesse padrão, a segunda transformação é usada para pegar a resposta da atividade do meio (que funciona tanto como o primeiro destino quanto como a segunda fonte), transformá-la e, então, opcionalmente, gravá-la em um segundo destino.

As atividades de origem e destino devem ser associadas a determinados tipos de endpoint, dependendo de onde são usadas no padrão:

  • Atividade de origem 1 A: Se usada, a primeira atividade de origem pode ser associada a qualquer tipo de endpoint.
  • Atividade de destino 1 / Atividade de origem 2: A primeira atividade de destino (também chamada de segunda atividade de origem) pode ser associada a qualquer tipo de endpoint, exceto para API, Banco de dados, Compartilhamento de arquivo, FTP, HTTP, Armazenamento local, Armazenamento Temporário, ou Variável.
  • Atividade de destino 2 E: Se usada, a segunda atividade de destino pode ser associada a qualquer tipo de endpoint.

A Se uma cadeia de operação contiver uma atividade de API, ela deve ser a única atividade de API ou API SOAP Request na cadeia de operação e deve ser a fonte da primeira operação. Ou seja, nenhuma outra operação pode estar chamando esta operação de um script ou uma ação de operação "em caso de sucesso" ou "em caso de falha".

C As operações não podem incluir mais de uma atividade NetSuite, Salesforce, Salesforce Service Cloud, SAP, ServiceMax ou SOAP.

D Operações que incluem uma atividade Salesforce, Salesforce Service Cloud ou ServiceMax não podem conter nenhuma outra atividade, exceto aquelas associadas à API, Banco de dados, Compartilhamento de arquivo, FTP, HTTP, Armazenamento local, Armazenamento Temporário, ou Variável conectores.

E Somente atividades não em massa podem ser usadas neste local.

Padrão de origem em massa do Salesforce

padrão de operação Salesforce fonte em massa anotada pp

Script(s) + Atividade de origem + Script(s) + Atividade de destino + Script(s)

Neste padrão, a atividade de origem deve ser uma atividade Salesforce Bulk Query, Atividade de consulta em massa do Salesforce Service Cloud, ou Atividade de consulta em massa do ServiceMax. A atividade de destino pode ser associada a qualquer um destes tipos de endpoint:

Padrão de segmentação em massa do Salesforce

padrão de operação Salesforce alvo em massa anotado pp

Script(s) + Atividade de origem + Script(s) + Atividade de destino + Script(s)

Nesse padrão, a atividade de origem pode ser associada a qualquer um destes tipos de endpoint:

A atividade de destino pode ser associada a qualquer um destes tipos de endpoint:

Exemplos comuns de padrões de operação

Esta seção fornece vários exemplos comuns de operações configuradas usando um padrão de operação válido. Esses exemplos são simplificados para demonstrar os blocos de construção básicos de operações comumente construídas e não pretendem cobrir todas as combinações possíveis. Consulte Padrões de validação anteriormente nesta página para todos os arranjos possíveis.

Script

Uma operação pode simplesmente conter um único script. Neste caso, todas as ações na operação são executadas pelo script.

Esse padrão normalmente é usado no início de um workflow para criar um " script de inicialização" que executa uma ou mais operações de ramificação com base em uma variável de sistema ou outro valor de dados.

Os Scripts também podem ser usados em qualquer lugar de uma operação para executar cálculos complexos que exigem lógica personalizada.

script de início de operação

Arquivo

Se tudo o que você precisa fazer é mover arquivos de uma fonte de dados para um destino, você pode usar uma operação sem uma transformação.

A primeira atividade é usada como fonte, fornecendo dados dentro da operação. A segunda atividade é usada como alvo, recebendo dados dentro da operação.

Para arquivar dados, as atividades de origem e destino são limitadas àquelas que interagem com arquivos. Em vez de uma atividade de origem, você também pode usar um script.

operação transferência simples de arquivo

Transformação

Operações que fazem uso de transformações atendem a uma variedade de casos de uso. Por exemplo, você pode criar operações que (1) transformam dados de uma fonte para um destino, (2) transformam dados e, em seguida, escrevem a resposta para outro destino, ou (3) transformam dados de uma chamada de serviço da web convertendo a resposta da chamada do aplicativo e escrevendo para um destino.

A operação transforma dados da origem para o destino

Este exemplo extrai dados de uma atividade de origem que são então transformados e gravados em uma atividade de destino:

operação FTP leitura

A operação transforma os dados e, em seguida, grava a resposta em outro destino

Neste exemplo, quando uma atividade HTTP é usada como o destino da transformação, como HTTP PUT ou HTTP POST, uma atividade de destino adicional pode ser colocada diretamente depois dela, ou depois de outra transformação, para gravar a resposta HTTP em outro destino.

Este arranjo de operação, usado para obter um token REST, mostra a resposta HTTP sendo gravada em uma variável global para uso na próxima operação:

cadeia de operação obter token

A operação chama um serviço web

Este exemplo é para atualizar um aplicativo como Salesforce por meio da API do aplicativo ou chamando um SOAP método de serviço web. A chamada do aplicativo normalmente inclui uma estrutura de dados de solicitação e resposta.

Neste arranjo, a operação tem três partes:

  • A primeira atividade de origem e transformação para construir a estrutura de dados da solicitação.

  • A chamada do aplicativo em si, que funciona como a primeira atividade de destino e a segunda atividade de origem.

  • Uma segunda transformação e destino para converter a resposta da chamada do aplicativo e gravar os dados ou arquivo em um destino.

Chamada de aplicação

operação Salesforce inserir

Chamada SOAP

operação verificar informações do cartão de crédito

Erros de regra de validação HTTP

Uma das regras de validação HTTP se aplica a operações que usam o padrão de arquivamento de dois alvos onde uma atividade HTTP na posição Target 1 grava uma resposta para uma segunda atividade target (Target 2). Neste cenário, a regra de validação requer que uma atividade HTTP Target 1 não seja usada em nenhum outro padrão de arquivamento de dois alvos operações em que a atividade HTTP Target 1 grava em uma segunda atividade de destino diferente.

As operações que violam essa regra de validação são relatadas como inválidas com uma mensagem de erro semelhante a esta:

erros de validação HTTP target activities

Resolver erros de validação HTTP

Recomendamos seguir as instruções fornecidas na mensagem de erro para corrigir as operações para que sejam válidas. Seguindo essas instruções, recomendamos estas etapas:

  1. Duplique a atividade de destino HTTP na posição Target 1 de uma das operações usando o padrão de arquivamento de dois destinos:

    operação atividade duplicada

  2. Substitua a atividade de destino HTTP na posição Destino 1 da(s) operação( ões) identificada(s) pela cópia duplicada:

    resultado da atividade de duplicação da operação

  3. Repita para quaisquer operações inválidas adicionais. Assim que os erros de validação forem resolvidos, reimplante as operações.

Desabilitar a regra de validação HTTP

Em certas situações, pode ser desejável desabilitar esta regra de validação HTTP da seguinte forma:

  1. Abra as configurações do projeto:

    configurações do menu de ações

  2. Na aba Implementar, desabilite Regra de Validação HTTP:

    projeto existente implantar desabilitar anotado

  3. Clique em Salvar.

Após desabilitar e salvar a configuração, os erros de validação de operação relatados devido a esse erro devem ser resolvidos. No entanto, observe que quaisquer atividades HTTP Target 1 usadas em um padrão de arquivamento de dois alvos a operação gravará na atividade Target 2 da última operação implantada. Isso pode fazer com que dados inválidos sejam gravados.

Cuidado

Usar esta configuração para desabilitar a regra de validação HTTP não é recomendado e pode resultar na gravação não intencional de dados inválidos em atividades de destino em operações usando o padrão de arquivamento de dois destinos.

Reative a regra de validação HTTP

Se você desabilitou anteriormente a regra de validação HTTP e está pronto para reabilitá-la, siga estas etapas:

  1. Abra as configurações do projeto.

  2. Na aba Implementar, habilite Regra de Validação HTTP.

  3. Clique em Salvar. Observe que esta é uma alteração em tempo de design e que esta ação não implantar nenhuma alteração na nuvem Harmony.

  4. Resolva quaisquer erros de validação HTTP (consulte Resolver erros de validação HTTP acima).

  5. Reimplante o projeto (veja Implantação do projeto).

    Nota

    Antes da reimplantação, a execução de quaisquer operações agora inválidas é permitida, pois o Harmony executa as operações atualmente implantadas. A reimplantação das operações afetadas é necessária para que as alterações sejam propagadas para o Harmony.