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 utilizando um padrão de operação válido. Exemplos de arranjos comuns de operações também são fornecidos.

Erros de validação

Para novos projetos, itens inválidos são destacados por padrão no canvas de design, com a seleção padrão de Destacar Itens Inválidos. Para desativar essa opção, desmarque essa seleção:

Quando Destacar Itens Inválidos está selecionado, quaisquer operações ou componentes inválidos são contornados na cor vermelha e possuem um ícone inválido ao lado de seu nome no canvas de design:

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

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

Operações com um erro implícito podem ser inválidas por qualquer uma das razões listadas em Erros de operação implícitos no final desta página.

O ícone inválido não é exibido se a razão pela qual a operação é inválida é que ela contém 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 apoio a uma operação. Por exemplo:

• Um componente usado diretamente como um passo 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 sob 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 arquivamento
• Padrão de script
• Padrão de transformação
• Padrão de arquivamento de dois alvos
• Padrão de arquivamento HTTP de dois alvos
• Padrão de duas transformações
• Padrão de fonte em massa do Salesforce
• Padrão de alvo em massa do Salesforce

A seguinte legenda mostra a definição das linhas de fluxo mostradas nas ilustrações dos padrões 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álidos.

Perguntas frequentes (FAQ)

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

• Qual é a diferença entre uma fonte e um destino?
  Atividades são consideradas como uma fonte se fornecem dados dentro de uma operação. Atividades são consideradas como um destino se recebem dados dentro de uma operação. Para uma explicação adicional sobre fontes versus destinos e as partes da operação, veja 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 estão documentados nas páginas individuais de atividades sob 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 é tipicamente 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 uma determinada disposição de operação desejada não seguir um padrão válido, pode ser possível usar uma combinação de operações que cada uma siga 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. À medida que você se familiariza com os padrões, generalizações como estas podem se tornar aparentes:

  • Conectores genéricos baseados em arquivos, 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 os para Epicor, ServiceNow e Workday, requerem uma transformação.
  • Scripts podem ser adicionados quase em qualquer lugar.

• Existem exemplos de como outros configuraram operações?
  Para exemplos comuns usando esses padrões, veja 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 arquivo é destinado 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.

Script(s) ou Controle de Fluxo ferramentas + Atividade de Origem + Script(s) + Atividade de Destino + Script(s)

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

• API ^A
• Compartilhamento de Arquivo
• FTP
• HTTP
• Armazenamento Local
• NetSuite
• Salesforce ^B
• Salesforce Service Cloud ^B
• ServiceMax ^B
• Armazenamento Temporário
• Variável

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

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

Padrão de Script

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

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

• API
• Compartilhamento de Arquivos
• FTP
• HTTP
• Armazenamento Local
• Armazenamento Temporário
• Variável

Padrão de Transformação

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

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

^A Se uma cadeia de operações contém uma atividade de API, ela deve ser a única atividade de API ou de Solicitação API SOAP na cadeia de operações e deve ser a fonte da primeira operação. Ou seja, nenhuma outra operação pode estar chamando esta operação a partir de um script ou de uma ação de operação "em sucesso" ou "em falha".

^B Apenas 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 a atividade de origem, então uma atividade de destino é necessária.

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

^F As operações que incluem uma atividade do Salesforce, Salesforce Service Cloud ou ServiceMax não podem conter também quaisquer outras atividades, exceto aquelas associadas aos conectores de API, Banco de Dados, Compartilhamento de Arquivos, FTP, HTTP, Armazenamento Local, Armazenamento Temporário, ou Variável.

Padrão de Arquivo de Dois Destinos

O padrão de arquivo de dois destinos 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.

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 de Destino 2 + Script(s) ou Controle de Fluxo ferramentas ^{C, D}

Neste padrão, a segunda atividade de destino é usada para arquivar uma resposta da atividade intermediária, que funciona tanto como a primeira fonte quanto como a segunda fonte.

A resposta da atividade intermediária passa pelos dados brutos da resposta para um segundo destino sem transformá-los. Isso pode ser pensado como um arquivo ou como uma passagem de dados (às vezes referida como um passthrough).

As atividades de origem e destino devem estar associadas a certos 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 referida como a segunda atividade de origem) pode ser associada a qualquer um desses tipos de endpoint:

  • NetSuite
  • Salesforce ^{B, D}
  • Salesforce Service Cloud ^{B, D}
  • SAP
  • ServiceMax ^{B, D}
  • SOAP

  Nota

  Uma variação deste padrão usando HTTP como a atividade intermediária é o Padrão de Arquivo HTTP com Dois Destinos.

• Atividade de Destino 2: A segunda atividade de destino pode ser associada a qualquer um desses tipos de endpoint:

  • API
  • Compartilhamento de Arquivo
  • FTP
  • HTTP
  • Armazenamento Local
  • Armazenamento Temporário
  • Variável

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

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

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

^D Operações que incluem uma atividade de Salesforce, Salesforce Service Cloud ou ServiceMax não podem conter também quaisquer outras atividades, exceto aquelas associadas aos conectores de API, Banco de Dados, Compartilhamento de Arquivos, FTP, HTTP, Armazenamento Local, Armazenamento Temporário, ou Variável.

Padrão de arquivo HTTP de dois destinos

O padrão de arquivo HTTP de dois destinos 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.

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 intermediária, que funciona tanto como o primeiro destino quanto como a segunda fonte. Este padrão é diferente do padrão de arquivamento de dois destinos na medida em que a atividade intermediária é 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 como um arquivo ou como uma passagem de dados (às vezes referido como um passthrough).

As atividades de origem e destino devem estar associadas a certos 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 estar associada a qualquer tipo de endpoint.
• Atividade de Destino 1 / Atividade de Origem 2: A primeira atividade de destino (também referida como a segunda atividade de origem) pode estar associada a qualquer um desses tipos de endpoint:
  • HTTP ^C
• Atividade de Destino 2: A segunda atividade de destino pode estar associada a qualquer um desses tipos de endpoint:
  • API
  • Compartilhamento de Arquivos
  • FTP
  • HTTP
  • Armazenamento Local
  • Armazenamento Temporário
  • Variável

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

^B Apenas 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

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 de Destino 2 + Script(s) ou Controle de Fluxo ferramentas

Neste padrão, a segunda transformação é usada para pegar a resposta da atividade intermediária (que funciona tanto como o primeiro destino quanto como a segunda origem), transformá-la e, em seguida, opcionalmente gravá-la em um segundo destino.

As atividades de origem e destino devem estar associadas a certos 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 estar associada a qualquer tipo de endpoint.
• Atividade de Destino 1 / Atividade de Origem 2: A primeira atividade de destino (também referida como a segunda atividade de origem) pode estar associada a qualquer tipo de endpoint, exceto 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 estar associada a qualquer tipo de endpoint.

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

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

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

^D As operações que incluem uma atividade de Salesforce, Salesforce Service Cloud ou ServiceMax não podem conter também quaisquer outras atividades, exceto aquelas associadas aos conectores de API, Banco de Dados, Compartilhamento de Arquivos, FTP, HTTP, Armazenamento Local, Armazenamento Temporário, ou Variável.

Padrão de fonte em massa do Salesforce

Script(s) ou Controle de Fluxo ferramentas + Atividade de Fonte + Script(s) ou Controle de Fluxo ferramentas + Atividade de Destino + Script(s) ou Controle de Fluxo ferramentas

Neste padrão, a atividade de fonte 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 estar associada a qualquer um desses tipos de endpoint:

• Compartilhamento de Arquivos
• FTP
• HTTP
• Armazenamento Local
• Armazenamento Temporário
• Variável

Padrão de destino em massa do Salesforce

Script(s) ou Controle de Fluxo ferramentas + Atividade de Origem + Script(s) ou Controle de Fluxo ferramentas + Atividade de Destino + Script(s) ou Controle de Fluxo ferramentas

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

• Compartilhamento de Arquivos
• FTP
• HTTP
• Armazenamento Local
• Armazenamento Temporário
• Variável

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

• Inserção em massa do Salesforce
• Atualização em massa do Salesforce
• Upsert em massa do Salesforce
• Exclusão em massa do Salesforce
• Exclusão em massa dura do Salesforce
• Inserção, atualização, upsert, exclusão ou exclusão dura em massa do Salesforce Service Cloud
• Inserção em massa do ServiceMax
• Atualização em massa do ServiceMax
• Upsert em massa do ServiceMax
• Exclusão em massa do ServiceMax
• Exclusão em massa dura do ServiceMax

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 têm a intenção de cobrir todas as combinações possíveis. Consulte os padrões de validação mais acima nesta página para todas as disposições possíveis.

Script

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

Esse padrão é tipicamente usado no início de um fluxo de trabalho para criar um "script de lançamento" que executa uma ou mais de várias operações de ramificação com base em uma variável do sistema ou outro valor de dado.

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

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 transformação.

A primeira atividade é usada como a fonte, fornecendo dados dentro da operação. A segunda atividade é usada como o destino, 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 poderia usar um script.

Transformação

Operações que utilizam 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 em outro destino, ou (3) transformam dados de uma chamada de serviço da web convertendo a resposta da chamada da aplicação e escrevendo em um destino.

A operação transforma dados da fonte 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:

A operação transforma 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 após ela, ou após outra transformação, a fim de gravar a resposta HTTP em outro destino.

Esta disposição da operação, usada para obter um token REST, mostra a resposta HTTP sendo gravada em uma variável global para uso na próxima operação:

A operação chama um serviço web

Este exemplo é para atualizar um aplicativo como Salesforce através da API do aplicativo, ou chamar um método de serviço web SOAP. A chamada ao aplicativo geralmente inclui tanto uma estrutura de dados de solicitação quanto de resposta.

Nesta disposição, 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 ao aplicativo em si, que funciona como a primeira atividade de destino e segunda atividade de origem.

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

Chamada ao aplicativo

Chamada SOAP

Erros de operação implícitos

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

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 arquivo de dois alvos, onde uma atividade HTTP na posição Alvo 1 escreve uma resposta para uma segunda atividade alvo (Alvo 2). Nesse cenário, a regra de validação exige que uma atividade HTTP Alvo 1 não deve ser usada em nenhuma outra operação do padrão de arquivo de dois alvos onde a atividade HTTP Alvo 1 escreve para uma atividade alvo secundária diferente.

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

Resolver erros de validação HTTP

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

1. Duplicar a atividade alvo HTTP na posição Alvo 1 de uma das operações que utilizam o padrão de arquivo HTTP de dois alvos.

2. Substituir a atividade alvo HTTP na posição Alvo 1 da(s) operação(ões) identificada(s) pela cópia duplicada:

3. Repetir para quaisquer operações inválidas adicionais. Uma vez que os erros de validação sejam 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:

   

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

   

3. Clique em Salvar.

Uma vez desabilitada e salva 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 de Target 1 HTTP usadas em uma operação de Padrão de arquivo de dois alvos escreverão na atividade Target 2 da última operação implantada. Isso pode causar a gravação de dados inválidos.

Reabilitar 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 Deploy, 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 implanta nenhuma alteração na nuvem Harmony.

4. Resolva quaisquer erros de validação HTTP (veja 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 a Harmony executa as operações atualmente implantadas. A reimplantação das operações afetadas é necessária para que as alterações sejam propagadas para a Harmony.

It seems there is no Markdown content provided for translation. Please provide the text you would like me to translate into Brazilian Portuguese.