Padrões de operação válidos no Jitterbit Studio

Introdução

As operações devem ser válidas antes de implantá-las. Esta página aborda como identificar operações inválidas, os padrões de validação que as operações devem seguir e exemplos de cada padrão.

Operações inválidas

Para novos projetos, a tela de design destaca itens inválidos por padrão quando Highlight Invalid Items está selecionado. Para desativar essa opção, desmarque a seleção:

highlight invalid items

Quando você seleciona Highlight Invalid Items, operações ou componentes inválidos aparecem com um contorno vermelho e um ícone inválido ao lado do nome na tela de design:

operation invalid

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

invalid operation

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

O ícone inválido não é exibido se a operação for inválida porque 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. Esse requisito inclui componentes usados como etapas de uma operação, bem como outros componentes usados em suporte a uma operação. Os exemplos a seguir ilustram esse requisito:

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 que um script na operação chama.

As regras de validação dependem do tipo de componente. Para mais informações, consulte Validade do componente.

Para uma referência completa de mensagens de erro de validação e suas resoluções, consulte Solução de problemas de operação.

Padrões de validação

As operações devem seguir certos padrões de validação antes de implantá-las na nuvem Harmony e executá-las em agentes Jitterbit. Esses padrões garantem que os agentes suportem e esperem todas as partes de um projeto.

A legenda a seguir mostra a definição das linhas de fluxo usadas nos diagramas de padrão:

Linha de fluxo	Definição
	Um componente obrigatório.
	Um componente opcional.
	Zero ou mais scripts ou ferramentas de Flow Control são válidos.

Perguntas frequentes (FAQ)

À medida que você projeta operações, as seguintes perguntas frequentes podem ser úteis:

Qual é a diferença entre uma origem e um destino?
As atividades funcionam como uma origem se fornecerem dados dentro de uma operação. As atividades funcionam como um destino se receberem dados dentro de uma operação. Para obter informaçõ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?
As páginas de atividades individuais em Conectores documentam os padrões que você pode usar com cada tipo específico de atividade. Em cada página de atividade, os padrões específicos que você pode usar aparecem na seção "Próximas etapas", que geralmente é a última seção em cada página de atividade.
Posso combinar uma atividade do Salesforce com qualquer outro conector?
Quando uma atividade do Salesforce, Salesforce Service Cloud ou ServiceMax recebe dados como destino, a atividade de origem pode estar associada a qualquer tipo de endpoint. Quando uma dessas atividades fornece dados como origem, a atividade de destino deve estar associada ao conector API, Banco de dados, Compartilhamento de arquivos, FTP, HTTP, Armazenamento local, Armazenamento temporário ou Variável. Uma operação também pode incluir apenas uma atividade do NetSuite, Salesforce, Salesforce Service Cloud, SAP, ServiceMax ou SOAP.
E se meu caso de uso não se encaixar em um padrão válido?
Se um arranjo de operação desejado não aderir a um padrão válido, você pode usar uma combinação de operações que cada uma segue um padrão válido. Para fazer isso, crie cada operação separadamente e depois encadeie-as usando ações de operação.
Quais são os erros de validação comuns?
Os problemas mais comuns incluem operações que não correspondem a nenhum padrão válido, transformações sem atividades obrigatórias e incompatibilidades de esquema. Para obter uma lista completa de erros de validação e como resolvê-los, consulte Solução de problemas de operação.

Dica

À medida que você se familiariza com os padrões, essas generalizações podem ajudar:

Conectores baseados em arquivo como FTP, HTTP e Armazenamento temporário podem ser usados sem transformações.
Conectores de aplicação como Salesforce, NetSuite e Workday geralmente exigem transformações.
Scripts podem ser adicionados em quase qualquer lugar em uma operação.
Operações em massa, como aquelas que usam atividades em massa do Salesforce, têm padrões específicos e não podem usar transformações.

Padrão de arquivo

O padrão de arquivo é destinado ao uso com atividades de origem e destino que interagem com arquivos. Você pode usar este padrão 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 ferramentas de Controle de fluxo tools + Atividade de origem + Script(s) + Atividade de destino + Script(s)

Exemplo

Caso de uso: Fazer backup de arquivos de pedidos de clientes do FTP para armazenamento em nuvem.

operation simple file transfer

Esta operação arquiva arquivos movendo-os de um servidor FTP para armazenamento temporário sem nenhuma transformação.

Neste padrão, as atividades de origem e destino podem ser associadas a qualquer um dos seguintes tipos de endpoint:

^A Se uma cadeia de operações contiver uma atividade de API, ela deve ser a única atividade de API ou API SOAP Request na cadeia de operações, e deve 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 "on success" ou "on failure".

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

Padrão de script

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

Exemplo

Caso de uso: Gerar e salvar um timestamp de relatório diário.

operation generate timestamp

Esta operação usa um script para gerar um timestamp formatado e nome de relatório, depois escreve em uma variável global para uso em operações subsequentes.

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

Padrão de transformação

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

Exemplo

Caso de uso: Sincronizar contatos do Salesforce para um banco de dados.

operation FTP read

Esta operação consulta contatos recentes do Salesforce, transforma os dados para corresponder ao esquema do banco de dados e insere os registros em uma tabela de banco de dados de clientes.

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

^A Se uma cadeia de operações contiver uma atividade de API, ela deve ser a única atividade de API ou API SOAP Request na cadeia de operações, e deve 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 "on success" ou "on failure".

^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 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 Em uma operação que inclui uma atividade do Salesforce, Salesforce Service Cloud ou ServiceMax, os conectores permitidos para as outras atividades dependem da direção dos dados. Quando a atividade do Salesforce, Salesforce Service Cloud ou ServiceMax recebe dados como destino, a atividade de origem pode estar associada a qualquer tipo de endpoint. Quando fornece dados como origem, a atividade de destino deve estar associada ao conector API, Banco de Dados, Compartilhamento de Arquivos, FTP, HTTP, Armazenamento Local, Armazenamento Temporário ou Variável.

Padrão de arquivo com dois destinos

Você pode usar o padrão de arquivo com dois destinos para armazenar dados inativos (em seu formato original) de um sistema de produção em 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}

Exemplo

Caso de uso: Criar um caso do Salesforce e arquivar a resposta.

operation create case

Esta operação recupera dados de tíquete de suporte de uma API, os transforma para criar um Caso do Salesforce e, em seguida, arquiva a resposta do Salesforce em uma variável global. A resposta do Salesforce passa inalterada para o segundo destino sem transformação adicional.

Neste padrão, a segunda atividade de destino arquiva uma resposta da atividade intermediária, que funciona tanto como o primeiro destino quanto como a segunda origem.

A resposta da atividade intermediária passa os dados de resposta bruta para um segundo destino sem transformá-los. Você pode pensar nisso como um arquivo ou como uma passagem de dados (às vezes chamada de passthrough).

As atividades de origem e destino devem estar associadas a certos tipos de endpoint dependendo de onde você as usa 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 chamada de segunda atividade de origem) pode estar associada a qualquer um dos seguintes tipos de endpoint:
- NetSuite
- Salesforce ^{B, D}
- Salesforce Service Cloud ^{B, D}
- SAP
- ServiceMax ^{B, D}
- SOAP

Nota

Uma variação desse padrão usando HTTP como 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 dos seguintes tipos de endpoint:

^A Se uma cadeia de operações contiver uma atividade de API, ela deve ser a única atividade de API ou Solicitação SOAP de API na cadeia de operações, e deve ser a origem da primeira operação. Ou seja, nenhuma outra operação pode chamar essa operação a partir de um script ou de uma ação de operação "on success" ou "on failure".

^B Apenas 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 Em uma operação que inclui uma atividade Salesforce, Salesforce Service Cloud ou ServiceMax, os conectores permitidos para as outras atividades dependem da direção dos dados. Quando a atividade Salesforce, Salesforce Service Cloud ou ServiceMax recebe dados como destino, a atividade de origem pode ser associada a qualquer tipo de endpoint. Quando fornece dados como origem, a atividade de destino deve ser associada ao conector API, Banco de Dados, Compartilhamento de Arquivos, FTP, HTTP, Armazenamento Local, Armazenamento Temporário ou Variável.

Padrão de arquivo HTTP com dois destinos

Você pode usar o padrão de arquivo HTTP com dois destinos para armazenar dados inativos (em seu formato original) de um sistema de produção em 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

Exemplo

Caso de uso: Processar um pagamento e registrar a resposta.

operation payment processing

Esta operação consulta registros de pagamento pendentes em um banco de dados, transforma os dados para corresponder ao formato de solicitação da API de pagamento, adiciona cabeçalhos de autenticação por meio de um script, envia para a API do gateway de pagamento e arquiva a resposta HTTP no armazenamento temporário para fins de auditoria.

Nesse padrão, a segunda atividade de destino arquiva uma resposta da atividade intermediária, que funciona tanto como o primeiro destino quanto como a segunda origem. Este padrão difere do Padrão de arquivo com dois destinos porque a atividade intermediária é uma atividade HTTP.

A resposta da atividade HTTP intermediária passa os dados de resposta bruta para um segundo destino sem transformá-los. Você pode pensar nisso como um arquivo ou como uma passagem de dados (às vezes chamada de passthrough).

As atividades de origem e destino devem estar associadas a certos tipos de endpoint dependendo de onde você as usa 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 chamada de segunda atividade de origem) pode estar associada a qualquer um dos seguintes tipos de endpoint:
- HTTP ^C
Atividade de Destino 2: A segunda atividade de destino pode estar associada a qualquer um dos seguintes tipos de endpoint:

^A Se uma cadeia de operações contiver uma atividade de API, ela deve ser a única atividade de API ou Solicitação SOAP de API na cadeia de operações, e deve ser a origem da primeira operação. Ou seja, nenhuma outra operação pode chamar essa operação a partir de um script ou de uma ação de operação "on success" ou "on failure".

^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 ferramentas de Controle de Fluxo tools + (Grupo: Atividade de Origem 1 + Script[s] ou ferramentas de Controle de Fluxo tools) + Transformação 1 + Atividade de Destino 1 / Atividade de Origem 2 + Transformação 2 + Script(s) ou ferramentas de Controle de Fluxo tools + Atividade de Destino 2 + Script(s) ou ferramentas de Controle de Fluxo tools ^C

Exemplo

Caso de uso: Criar um cliente NetSuite e processar a resposta.

operation netsuite customer

Esta operação recupera dados de clientes pendentes de uma API de CRM, transforma-os para criar um registro de cliente NetSuite, depois transforma a resposta NetSuite e atualiza o banco de dados local com o ID NetSuite para referência futura.

Neste padrão, a segunda transformação pega a resposta da atividade intermediária (que funciona tanto como o primeiro destino quanto como a segunda origem), transforma-a e, opcionalmente, escreve-a em um segundo destino.

As atividades de origem e destino devem estar associadas a certos tipos de endpoint dependendo de onde você as usa 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 chamada de 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 Solicitação SOAP de API na cadeia de operações, e deve ser a origem da primeira operação. Ou seja, nenhuma outra operação pode chamar essa operação a partir de um script ou de uma ação de operação "on success" ou "on failure".

^B Apenas atividades não em lote 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.

Padrão de origem em lote 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

Exemplo

Caso de uso: Extrair um grande conjunto de dados do Salesforce para análise.

operation salesforce bulk query

Esta operação usa uma atividade Bulk Query do Salesforce para extrair todas as contas criadas este ano e, em seguida, escreve os dados em um servidor FTP para importação do data warehouse. Use este padrão para extrair grandes conjuntos de dados (normalmente 50.000 ou mais registros) com eficiência sem uma transformação.

Neste padrão, a atividade de origem deve ser uma atividade Salesforce Bulk Query, atividade Salesforce Service Cloud Bulk Query ou atividade ServiceMax Bulk Query. A atividade de destino pode estar associada a qualquer um dos seguintes tipos de endpoint:

Padrão de destino em lote 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

Exemplo

Caso de uso: Carregar dados de clientes em lote no Salesforce.

operation salesforce bulk upsert

Esta operação lê um arquivo CSV de dados de clientes de um servidor FTP, valida os dados com um script e, em seguida, executa um upsert em lote para objetos Salesforce Contact. Use este padrão para carregar grandes conjuntos de dados (normalmente 50.000 ou mais registros) com eficiência sem uma transformação.

Neste padrão, a atividade de origem pode estar associada a qualquer um dos seguintes tipos de endpoint:

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