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:

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:

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

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:

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, uma transformação ou um 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 destino 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¶

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:

• API ^A
• Compartilhamento de arquivo
• FTP
• HTTP
• Armazenamento local
• NetSuite
• Salesforce ^E
• Salesforce Service Cloud ^E
• ServiceMax. ^E
• Armazenamento temporário
• Variável

^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(s) + Atividade Alvo

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

• API
• Compartilhamento de arquivo
• FTP
• HTTP
• Armazenamento local
• Armazenamento temporário
• Variável

Padrão de Transformação¶

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¶

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:

  • API
  • Compartilhamento de arquivo
  • FTP
  • HTTP
  • Armazenamento local
  • Armazenamento temporário
  • Variável

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

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 alvos 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:
  • API
  • Compartilhamento de arquivo
  • FTP
  • HTTP
  • Armazenamento local
  • Armazenamento temporário
  • Variável

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

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¶

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:

• Compartilhamento de arquivo
• FTP
• HTTP
• Armazenamento local
• Armazenamento temporário
• Variável

Padrão de Destino em Massa do Salesforce¶

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:

• Compartilhamento de arquivo
• FTP
• HTTP
• Armazenamento local
• Armazenamento temporário
• Variável

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

• Inserção em massa do Salesforce
• Atualização em massa do Salesforce
• Inserção em massa do Salesforce
• Exclusão em massa do Salesforce
• Exclusão forçada em massa do Salesforce
• Inserção, atualização, upsert, exclusão ou exclusão permanente em massa do Salesforce Service Cloud
• Inserção em massa ServiceMax
• Atualização em massa do ServiceMax
• Inserção em massa do ServiceMax
• Exclusão em massa do ServiceMax
• Exclusão forçada em massa do ServiceMax

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 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 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.

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.

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:

A Operação Transforma Dados e Grava a Resposta em Outro Alvo¶

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:

A Operação Chama um Serviço da 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¶

Chamada SOAP¶

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:

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 arquivo de dois destinos:

   

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

   

3. 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:

1. Abra as configurações do projeto:

   

2. Na aba Implantar, desative Regra de validação HTTP:

   

3. 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.

Reative a Regra de Validação HTTP¶

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

1. Abra as configurações do projeto.

2. Na aba Implantar, 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 (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.