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

Introdução

As operações devem ser válidas antes que você possa 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, o canvas de design destaca itens inválidos por padrão quando Destacar Itens Inválidos está selecionado. Para desativar essa opção, desmarque essa seleção:

destacar itens inválidos

Quando você seleciona Destacar Itens Inválidos, operações ou componentes inválidos são exibidos com um contorno vermelho e um ícone inválido ao lado de seu nome no canvas de design:

operação inválida

No painel do projeto, os nomes de fluxos de trabalho 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 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 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 seguintes exemplos 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, veja Validade do componente.

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

Padrões de validação

As operações devem seguir certos padrões de validação antes que você possa 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 seguinte legenda 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 Controle de Fluxo ferramentas 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 fonte e um destino?
As atividades funcionam como uma fonte se fornecerem dados dentro de uma operação. As atividades funcionam como um destino se receberem dados dentro de uma operação. Para informações adicionais sobre fontes 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óximos Passos", que geralmente é 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 aderir a um padrão válido, você pode ser capaz de 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.
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 necessárias e incompatibilidades de esquema. Para uma lista completa de erros de validação e como resolvê-los, consulte Solução de problemas de design de operações.

Dica

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

Conectores baseados em arquivos como FTP, HTTP e Armazenamento Temporário podem ser usados sem transformações.
Conectores de aplicativos como Salesforce, NetSuite e Workday geralmente requerem transformações.
Scripts podem ser adicionados quase em qualquer lugar em uma operação.
Operações em massa como Salesforce Bulk 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 esse 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 Controle de Fluxo ferramentas + Atividade de Origem + Script(s) + Atividade de Destino + Script(s)

Exemplo

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

transferência simples de arquivo

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

Neste padrão, as atividades de origem e destino podem estar 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 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 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 Apenas atividades não em massa podem ser usadas neste local.

Padrão de script

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

Exemplo

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

operation generate timestamp

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

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

Padrão de transformação

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 de Destino) + Script[s] ^{E, F}

Exemplo

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

operação FTP ler

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 estar associadas a qualquer tipo de endpoint, desde que você inclua pelo menos uma atividade. Uma transformação não pode existir sozinha 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 de Solicitação API SOAP 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 "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 sozinha.

^D Se uma Consulta do Salesforce, Salesforce Service Cloud ou ServiceMax for usada como 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 API, Banco de Dados, Compartilhamento de Arquivos, FTP, HTTP, Armazenamento Local, Armazenamento Temporário, ou Variável.

Padrão de Arquivo de Dois Alvos

Você pode usar o padrão de arquivo de dois alvos 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}

Exemplo

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

operação criar caso

Esta operação recupera dados de tickets de suporte de uma API, transforma-os para criar um Caso no Salesforce e, em seguida, arquiva a resposta do Salesforce em uma variável global. A resposta do Salesforce passa sem alterações para o segundo alvo sem transformação adicional.

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

A resposta da atividade intermediária passa pelos dados brutos da resposta para um segundo alvo sem transformá-los. Você pode pensar nisso 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 você as utiliza no padrão:

Atividade de Origem 1 ^A: Se utilizada, 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 dos seguintes 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 de dois alvos.
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 de Solicitação SOAP de API na cadeia de operações, e deve ser a fonte 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 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 API, Banco de Dados, Compartilhamento de Arquivo, FTP, HTTP, Armazenamento Local, Armazenamento Temporário ou Variável.

Padrão de Arquivo HTTP de Dois Alvos

Você pode usar o padrão de arquivo HTTP de dois alvos 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.

processamento de pagamento da operação

Esta operação consulta registros de pagamento pendentes de 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 em um armazenamento temporário para fins de auditoria.

Neste padrão, a segunda atividade de destino arquiva uma resposta da atividade intermediária, que funciona tanto como o primeiro alvo quanto como a segunda origem. Este padrão difere do Padrão de Arquivo de Dois Alvos porque a atividade intermediária é uma atividade HTTP.

A resposta da atividade HTTP intermediária passa pelos dados brutos da resposta para um segundo alvo sem transformá-los. Você pode pensar nisso 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 você as utiliza no padrão:

Atividade de Origem 1 ^A: Se utilizado, 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 dos seguintes tipos de endpoint:
- HTTP ^C
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 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 chamar 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

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 no NetSuite, em seguida, transforma a resposta do NetSuite e atualiza o banco de dados local com o ID do 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 fonte), transforma-a e, em seguida, opcionalmente a grava em um segundo destino.

As atividades de origem e destino devem estar associadas a certos tipos de endpoint, dependendo de onde você as utiliza no padrão:

Atividade de Origem 1 ^A: Se utilizada, 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 utilizada, 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 chamar 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 do NetSuite, Salesforce, Salesforce Service Cloud, SAP, ServiceMax ou SOAP.

^D As operações que incluem uma atividade do Salesforce, Salesforce Service Cloud ou ServiceMax não podem conter outras atividades, exceto aquelas associadas aos conectores API, Database, File Share, FTP, HTTP, Local Storage, Temporary Storage, ou Variable.

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

Exemplo

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

operação consulta em massa do salesforce

Esta operação utiliza uma atividade de Consulta em Massa do Salesforce para extrair todas as contas criadas este ano e, em seguida, grava os dados em um servidor FTP para importação no data warehouse. Use este padrão para extrair grandes conjuntos de dados (tipicamente 50.000 ou mais registros) de forma eficiente, sem transformação.

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 estar associada a qualquer um dos seguintes tipos de endpoint:

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

Exemplo

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

operação 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, realiza um upsert em massa para objetos de Contato do Salesforce. Utilize este padrão para carregar grandes conjuntos de dados (tipicamente 50.000 ou mais registros) de forma eficiente, 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 estar associada a qualquer um dos seguintes tipos de endpoint: