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 resolver erros de validação usando um padrão de operação válido. Exemplos de arranjos operação comuns também são fornecidos.

Erros de validação

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, desmarque esta seleção:

destacar itens inválidos

Quando Destacar Itens Inválidos estiver selecionado, quaisquer operações ou componentes inválidos serão destacados na cor vermelha e terão 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 motivos listados em Erros de operação implícitos no final desta página.

O O ícone inválido não será exibido se o motivo da operação ser inválida for a presença de outros componentes com erros implícitos. Os componentes do projeto usados como 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:

Padrão de arquivo
Padrão de Script
Padrão de Transformação
Padrão de arquivo de dois alvos
Padrão de arquivo HTTP de dois alvos
Padrão de duas transformações
Padrão de origem em massa do Salesforce
Padrão de segmentação em massa do Salesforce

A legenda a seguir mostra a definição das linhas de fluxo mostradas nas ilustrações do padrão de validação:

Linha de fluxo	Definição
	Um componente obrigatório.
	Um componente opcional.
	Zero ou mais script(s) ou Controle de Fluxo ferramentas são válidas.

Perguntas frequentes (perguntas frequentes)

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

Qual é a diferença entre uma origem e um destino?
As atividades são consideradas usadas como origem se fornecerem dados dentro de uma operação. As atividades são consideradas usadas como destino se receberem dados dentro de uma operação. Para obter explicações adicionais sobre origens versus destinos e as partes da operação, consulte Criação e configuração de operações.
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 de 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 seguir um padrão válido, você poderá usar uma combinação de operações que sigam um padrão válido. Para isso, crie cada operação separadamente e, em seguida, encadeie-as usando ações de operação.
Como posso me 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. À medida que você se familiariza com os padrões, generalizações como estas podem se tornar aparentes:
- Baseados em arquivo conectores genéricos, como FTP, HTTP e Armazenamento Temporário, podem ser usados sem uma transformação.
- Na maioria dos casos, conectores de aplicação para atividades não em massa, como as da Epicor, ServiceNow e Workday, exigem uma transformação.
- 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

O padrão de arquivamento destina-se ao uso com atividades de origem e destino que interagem com arquivos. Ele pode ser usado para armazenar dados inativos (em seu formato de arquivo original) de um sistema de produção para um sistema de armazenamento seguro para recuperação posterior.

400.

Script(s) ou Controle de Fluxo ferramentas + 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 destes tipos de endpoint:

^A Se uma cadeia de operação contiver uma atividade de API, ela deverá ser a única atividade de API ou solicitação de API SOAP na cadeia de operação e deverá ser a origem da primeira operação. Ou seja, nenhuma outra operação poderá chamar esta operação a partir de um script ou de uma ação de operação "em caso de sucesso" ou "em caso de falha".

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

Padrão de Script

400.

Script(s) ou Controle de Fluxo ferramentas + Atividade alvo

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

Padrão de Transformação

400.

Script(s) ou Controle de Fluxo ferramentas + (Grupo: Atividade de origem + Script[s] ou Controle de fluxo ferramentas) + Transformação + (Grupo: Script[s] ou Controle de Fluxo ferramentas + Atividade alvo) + Script[s] ^{E, F}

Nesse 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 deverá ser a única atividade de API ou solicitação de API SOAP na cadeia de operação e deverá ser a origem da primeira operação. Ou seja, nenhuma outra operação poderá chamar esta operação a partir de um script ou de uma ação de operação "em caso de sucesso" ou "em caso de falha".

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

^C Pelo menos uma atividade deve ser incluída; uma transformação não pode existir por si só.

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

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

^F 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 arquivos, FTP, HTTP, Armazenamento local, Armazenamento Temporário, ou Variável conectores.

Padrão de arquivamento de dois alvos

O padrão de arquivamento de dois alvos pode ser usado para armazenar dados inativos (em seu formato original) de um sistema de produção para um sistema de armazenamento seguro para recuperação posterior.

400.

Script(s) ou Controle de Fluxo ferramentas + (Grupo: Atividade de origem 1 + Script[s]) ou Controle de fluxo ferramentas + Transformação + Atividade de destino 1 / Atividade de origem 2 + Script(s) ou Controle de fluxo ferramentas + Atividade alvo 2 + Script(s) ou Controle de fluxo ferramentas ^{C, D}

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

A resposta da atividade intermediária passa pelos dados brutos de resposta para um segundo alvo sem transformá-los. Isso pode ser considerado um arquivo ou 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:
- NetSuite
- Salesforce ^{B, D}
- Salesforce Service Cloud ^{B, D}
- SAP
- ServiceMax ^{B, D}
- SOAP
Nota

Uma variação deste padrão que utiliza HTTP como atividade intermediária é o Padrão de arquivo HTTP de dois alvos.
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 deverá ser a única atividade de API ou solicitação de API SOAP na cadeia de operação e deverá ser a origem da primeira operação. Ou seja, nenhuma outra operação poderá chamar esta operação a partir de um script ou de uma ação de operação "em caso de sucesso" ou "em caso de falha".

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

^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 do Salesforce, Salesforce Service Cloud ou ServiceMax não podem conter nenhuma outra atividade, exceto aquelas associadas à API, Banco de dados, Compartilhamento de arquivos, FTP, HTTP, Armazenamento local, Armazenamento Temporário, ou Variável conectores.

Padrão de arquivo HTTP de dois alvos

O padrão de arquivamento HTTP de dois alvos pode ser usado para armazenar dados inativos (em seu formato original) de um sistema de produção para um sistema de armazenamento seguro para recuperação posterior usando protocolos e serviços HTTP.

400.

Script(s) ou Controle de Fluxo ferramentas + Atividade de origem 1 + Script(s) ou Controle de fluxo ferramentas + Transformação + Script(s) ou Controle de Fluxo ferramentas + Atividade de destino 1 / Atividade de origem 2 + Atividade de destino 2 + Script(s) ou Controle de fluxo ferramentas

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 intermediária passa pelos dados brutos da resposta para um segundo destino sem transformá-los. Isso pode ser considerado um arquivo ou 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:
- HTTP ^C
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 deverá ser a única atividade de API ou solicitação de API SOAP na cadeia de operação e deverá ser a origem da primeira operação. Ou seja, nenhuma outra operação poderá chamar esta operação a partir de um script ou de uma ação de operação "em caso de sucesso" ou "em caso de falha".

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

^C 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

400.

Script(s) ou Controle de Fluxo ferramentas + (Grupo: Atividade de origem 1 + Script[s] ou Controle de fluxo ferramentas) + Transformação 1 + Atividade de destino 1 / Atividade de origem 2 + Transformação 2 + Script(s) ou Controle de fluxo ferramentas + Atividade alvo 2 + Script(s) ou Controle de fluxo ferramentas

Neste 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 origem), 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 arquivos, FTP, HTTP, Armazenamento local, Armazenamento Temporário, ou Variável.
Atividade de destino 2 ^B: 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 deverá ser a única atividade de API ou solicitação de API SOAP na cadeia de operação e deverá ser a origem da primeira operação. Ou seja, nenhuma outra operação poderá chamar esta operação a partir de um script ou de uma ação de operação "em caso de sucesso" ou "em caso de falha".

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

^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 do Salesforce, Salesforce Service Cloud ou ServiceMax não podem conter nenhuma outra atividade, exceto aquelas associadas à API, Banco de dados, Compartilhamento de arquivos, FTP, HTTP, Armazenamento local, Armazenamento Temporário, ou Variável conectores.

Padrão de origem em massa do Salesforce

400.

Script(s) ou Controle de Fluxo ferramentas + Atividade de origem + Script(s) ou Controle de fluxo ferramentas + Atividade alvo + Script(s) ou Controle de fluxo ferramentas

Neste padrão, a atividade de origem deve ser uma atividade de consulta em massa do Salesforce, 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

400.

Script(s) ou Controle de Fluxo ferramentas + Atividade de origem + Script(s) ou Controle de fluxo ferramentas + Atividade alvo + Script(s) ou Controle de fluxo ferramentas

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 abranger 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 da 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 do 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 da 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 destino, recebendo dados dentro da operação.

Para arquivar dados, as atividades de origem e destino limitam-se àquelas que interagem com os 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 origem para um destino, (2) transformam dados e, em seguida, gravam a resposta em outro destino, ou (3) transformam dados de uma chamada de serviço web, convertendo a resposta da chamada do aplicativo e gravando em 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 o Salesforce através 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.

Nesse 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 própria chamada do aplicativo, 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 para inscrição

operação Salesforce inserir

Chamada SOAP

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

Erros operação implícitos

Operações com 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 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 de 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 "] possui 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 fornecido pela transformação esquema de origem, deve haver uma atividade de origem precedendo a transformação. | |

Atividades de destino HTTP que enviam suas respostas a uma segunda atividade de destino só podem enviar respostas a uma atividade de destino em todo o projeto. A atividade HTTP ["Nome da Atividade de Destino 1"] nesta operação está enviando suas respostas a 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, abrindo o menu e duplicando-a. 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 a 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, consulte 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 ouvinte. 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 como resultado ["Em Caso de Sucesso" / "Em Caso de Falha" / "Em Caso de Falha de SOAP "] 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 conforme 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 possui 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. |

Erros de regra de validação HTTP

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

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

erros de validação de atividades de destino HTTP

Resolver erros de validação HTTP

Recomendamos seguir as instruções fornecidas na mensagem de erro para corrigir as operações e torná-las válidas. Seguindo essas instruções, recomendamos os seguintes passos:

Duplicar a atividade de destino HTTP na posição Destino 1 de uma das operações usando o padrão de arquivo HTTP de dois alvos.
Substitua a atividade de destino HTTP na posição Destino 1 da(s) operação(ões) identificada(s) pela cópia duplicada:
Repita o processo 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:

Abra as configurações do projeto:
Na aba Implementar, desabilite Regra de Validação HTTP:
Clique em Salvar.

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

Cuidado

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

Reative a regra de validação HTTP

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

Abra as configurações do projeto.
Na aba Implementar, ative Regra de Validação HTTP.
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.
Resolva quaisquer erros de validação HTTP (consulte Resolver erros de validação HTTP acima).
Reimplante o projeto (consulte Implantação do projeto).

Nota

Antes da reimplantação, a execução de quaisquer operações atualmente 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.