Validade da Operaçã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

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 Realçar itens inválidos. Para desativar esta opção, desmarque esta seleção:

destacar itens inválidos

Quando Realçar itens inválidos é selecionado, os nomes das operações inválidas aparecem em itálico e na cor vermelha na quadro de design e no painel do projeto. Além disso, na quadro de design, os ícones das etapas de operação inválidas são contornados com uma borda vermelha:

operação inválida

No painel do projeto, operações inválidas que possuem um erro implícito são mostradas com um ícone de erro :

operação inválida

Clique no ícone de erro próximo ao nome da operação para exibir uma mensagem listando os erros de validação da operação. As 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 garantam 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 deverá 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 um actividade fornecida ou fornecido por transformação esquema de origem, deve haver uma atividade de origem precedendo a transformação.
As atividades de destino HTTP que enviam suas respostas para uma segunda atividade de destino só podem enviar respostas para uma atividade de destino durante todo o projeto. A atividade HTTP ["Target 1 Activity Name"] nesta operação está enviando sua resposta para diversas atividades de destino em todo o projeto. Nesta operação seu alvo é ["Target 2A Activity Name"]. Na operação ["Operação 2"] seu alvo é ["Target 2B Activity Name"]. Substitua a atividade ["Target 1 Activity Name"] por uma atividade duplicada em uma das operações. Você pode fazer isso encontrando a atividade ["Target 1 Activity Name"] na guia Componentes, abrindo o menu e duplicando. Arraste a atividade duplicada para a operação.	Em uma operação que usa o padrão de arquivo 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 arquivo de dois destinos a operação deve gravar na mesma atividade de destino. Nota Esta regra de validação pode ser desativada, embora isso não seja recomendado. Para obter mais informações, consulte Erros de regras de validação de 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 eventos: ["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 ouvinte ou atividade baseada em eventos - essas atividades precisam ser as primeiras na operação.	A operação deve atender aos padrões de operação estabelecidos para o atividade de escutar. 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 ["On Success" / "On Fail" / "On SOAP Fault"] para a operação de destino ["Nome da Operação 2"] que tem um ouvinte ou baseado em eventos como primeira atividade."	Uma operação não pode usar ações de 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 agendamento.
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 uma atividade baseada em evento.	Uma operação não é possível usar o `RunOperation` função para invocar outra operação que contém uma atividade de escuta.

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

Um componente usado diretamente como uma etapa da operação, como uma atividade, transformação ou script.
Um endpoint do qual depende uma atividade utilizada na operação.
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 Harmony. Esses padrões garantem que todas as partes de um projeto sejam apoiadas 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 destinos
Padrão de duas transformações
Padrão de origem em massa do Salesforce
Padrão de segmentação em massa do Salesforce

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

Notas de Rodapé para Padrões de Validação

^A Se uma cadeia de operação contiver uma atividade de API, ela deverá ser a única atividade de API ou solicitação SOAP de API na cadeia de operação e deverá ser a origem da primeira operação. Ou seja, nenhuma outra operação pode 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 Se um Salesforce, Salesforce Service Cloud ou ServiceMax Query for usado como atividade de origem, será necessária uma atividade de destino.

^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 também não podem conter quaisquer outras atividades, exceto aquelas associadas à API, Base de dados, Compartilhamento de arquivo, FTP, HTTP, Armazenamento local, Armazenamento temporário ou Variável conectores.

^E Somente atividades que não sejam 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 origem e um destino?
As atividades são consideradas usadas como fonte se fornecerem dados dentro de uma operação. As atividades são consideradas usadas como alvo 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çã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 estã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óximas etapas”, que normalmente é a última seção de cada página de atividade.
E se meu caso de uso não se enquadrar em um padrão válido?
Se um determinado arranjo de operação desejado não aderir a um padrão válido, você poderá usar uma combinação de operações em que cada uma siga um padrão válido. Para fazer isso, crie cada operação separadamente e depois encadeie-as usando ações de operação.
Como posso lembrar desses padrões?
As operações que não seguem um padrão válido são sinalizadas como inválidas e não podem ser implementadas. À medida que você se familiariza com os padrões, generalizações como estas 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 que não sejam em massa, como Epicor, ServiceNow e Workday, exigem uma transformação.
- Os Scripts podem ser adicionados em praticamente qualquer lugar.
Existem exemplos de como outras pessoas configuraram 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)

Neste padrão, as atividades de origem e de 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 SOAP de API na cadeia de operação e deverá ser a origem da primeira operação. Ou seja, nenhuma outra operação pode 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”.

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

Padrão de Script

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

Script(s) + Atividade Alvo

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

Padrão de Transformação

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

Script(s) + (Grupo: Atividade Fonte + Script[s]) + Transformação + (Grupo: Script(s) + Atividade alvo) + 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 esteja incluída. Uma transformação não pode existir por si só numa 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 SOAP de API na cadeia de operação e deverá ser a origem da primeira operação. Ou seja, nenhuma outra operação pode 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 Se um Salesforce, Salesforce Service Cloud ou ServiceMax Query for usado como atividade de origem, será necessária uma atividade de destino.

^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 também não podem conter quaisquer outras atividades, exceto aquelas associadas à API, Base de dados, Compartilhamento de arquivo, FTP, HTTP, Armazenamento local, Armazenamento temporário ou Variável conectores.

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

Padrão de Arquivo de Dois Destinos

padrão de operação dois arquivos de destino anotados pp

Script(s) + (Grupo: Atividade Fonte 1 + Script[s]) + Transformação + Atividade Destino 1 / Atividade Fonte 2 + Script(s) + Atividade Alvo 2 + Script(s)

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

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

As atividades de origem e de 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 ^{D, E}
- Salesforce Service Cloud ^{D, E}
- SAP
- ServiceMax ^{D, E}
- SOAP
Nota

Uma variação desse padrão usando 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 SOAP de API na cadeia de operação e deverá ser a origem da primeira operação. Ou seja, nenhuma outra operação pode 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”.

^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 também não podem conter quaisquer outras atividades, exceto aquelas associadas à API, Base de dados, Compartilhamento de arquivo, FTP, HTTP, Armazenamento local, Armazenamento temporário ou Variável conectores.

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

Padrão de Arquivo HTTP de Dois Destinos

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

Script(s) + Atividade Fonte 1 + Script(s) + Transformação + Script(s) + Atividade Destino 1 / Atividade Fonte 2 + Atividade alvo 2 + Script(s)

Neste padrão, a segunda atividade alvo é usada para arquivar uma resposta da atividade intermediária, que funciona tanto como primeiro alvo quanto como segunda fonte. Este padrão é diferente do padrão de arquivo de dois destinos em que a atividade intermediária é uma atividade HTTP.

A resposta da atividade HTTP intermediária passa pelos dados brutos de resposta para um segundo destino sem transformá-lo. Isso pode ser considerado um arquivo ou uma passagem de dados (às vezes chamada de passagem).

As atividades de origem e de 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 ^F
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 SOAP de API na cadeia de operação e deverá ser a origem da primeira operação. Ou seja, nenhuma outra operação pode 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”.

^E Somente atividades que não sejam 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 duas transformação anotadas pp

Script(s) + (Grupo: Atividade Fonte 1 + Script[s]) + Transformação 1 + Atividade Destino 1 / Fonte Atividade 2 + Transformação 2 + Script(s) + Atividade Alvo 2 + Script(s)

Nesse padrão, a segunda transformação é usada para obter a resposta da atividade intermediária (que funciona tanto como primeiro alvo quanto como segunda fonte), transformá-la e, opcionalmente, gravá-la em um segundo alvo.

As atividades de origem e de 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 API, Base 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 deverá ser a única atividade de API ou solicitação SOAP de API na cadeia de operação e deverá ser a origem da primeira operação. Ou seja, nenhuma outra operação pode 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”.

^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 também não podem conter quaisquer outras atividades, exceto aquelas associadas à API, Base de dados, Compartilhamento de arquivo, FTP, HTTP, Armazenamento local, Armazenamento temporário ou Variável conectores.

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

Padrão de Origem em Massa do Salesforce

padrão de operação pp anotado de fonte em massa do Salesforce

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

Nesse 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

padrão de operação Alvo em massa do Salesforce pp anotado

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

Neste 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 de Padrões de Operação Comuns

Esta seção fornece vários exemplos comuns de operações configuradas usando um padrão de operação válido. Estes exemplos são simplificados para demonstrar os blocos básicos de operações comumente construídas e não se destinam a cobrir todas as combinações possíveis. Consulte Padrões de validação anteriormente nesta página para todas as providências 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 de sistema ou outro valor de dados.

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

script inicial 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 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 os arquivos. Em vez de uma atividade de origem, você também pode usar um script.

operação de transferência simples de arquivos

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) transformem dados de uma origem em um destino, (2) transformem dados e, em seguida, gravem a resposta em outro destino ou (3) transformem dados de uma chamada de serviço da Web convertendo a chamada do aplicativo resposta e escrita para um alvo.

Operação Transforma Dados da Origem para o Destino

Este exemplo extrai dados de uma atividade de origem que é então transformada e gravada em uma atividade de destino:

operação FTP lida

A Operação Transforma os Dados e Depois Grava a Resposta em Outro Destino

Neste exemplo, quando uma atividade HTTP é usada como 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, para gravar a resposta HTTP em outra alvo.

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 obtém token

A Operação Chama um Serviço Web

Este exemplo é para atualizar um aplicativo como Salesforce através da API da aplicação ou chamando um SOAP método de serviço da 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 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 de Inscrição

operação inserção do Salesforce

Chamada SOAP

operação verifica 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 usando o padrão de arquivo de dois destinos 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 arquivo de dois destinos operações em que a atividade HTTP Target 1 grava em uma segunda atividade de destino diferente.

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

erros de validação 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 para que sejam válidas. Seguindo essas instruções, recomendamos estas etapas:

Duplique a atividade de destino HTTP na posição Target 1 de uma das operações usando o padrão de arquivo de dois destinos:
Substitua a atividade de destino HTTP na posição Target 1 da(s) operação(ões) identificada(s) pela cópia duplicada:
Repita para quaisquer operações inválidas adicionais. Depois que os erros de validação forem resolvidos, reimplante as operações.

Desative a Regra de Validação HTTP

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

Abra as configurações do projeto:
Na aba Implantar, desative Regra de validação HTTP:
Clique em Salvar.

Depois de desabilitar e salvar a configuração, os erros de validação da operação relatados devido a este erro deverão ser resolvidos. No entanto, observe que quaisquer atividades HTTP Target 1 usadas em um padrão de arquivo de dois destinos 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 involuntária de dados inválidos em atividades de destino em operações usando o padrão de arquivo de dois destinos.

Reative a Regra de Validação HTTP

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

Abra as configurações do projeto.
Na aba Implantar, habilite 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 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.