Considerações Sobre Conectores Baseados em REST

Introdução

Vários conectores do Cloud Studio podem ser usados para conectar-se a serviços Web RESTful, também conhecidos como APIs REST. Esta página fornece considerações para escolher qual conector usar, selecionando entre dois conectores HTTP genéricos ou vários conectores específicos do aplicativo. Conectores personalizados baseados em REST também podem ser criados.

Considerações de Alto Nível e Depreciação Futura

Conectores de aplicativos geralmente incluem recursos específicos de endpoint que são mais fáceis de configurar usando o conector específico em vez dos conectores genéricos. Contudo, os conectores genéricos geralmente permitem mais flexibilidade na configuração. Conectores personalizados oferecem opções adicionais que exigem trabalho inicial para serem criadas, mas facilitam aos usuários o uso do conector de sua marca com configurações que, de outra forma, poderiam não estar disponíveis.

Conectores Genéricos

Jitterbit fornece dois conectores genéricos para conexão com APIs REST:

HTTP: O conector HTTP é o conector HTTP original da Jitterbit cujo código subjacente está em uso há mais de uma década. Este conector é comprovado e confiável, mas é difícil de estender e manter. Portanto, o desenvolvimento futuro não se concentrará neste conector.
HTTP v2: O conector HTTP v2 é a próxima versão do conector HTTP da Jitterbit. Ele foi reconstruído usando o Connector SDK extensível do Jitterbit, o que permite que novos recursos sejam disponibilizados mais rapidamente. O conector HTTP v2 tem suporte para tipos de autenticação adicionais, conexões keep-alive e parâmetros de URL em esquemas de solicitação/resposta. O desenvolvimento futuro se concentrará neste conector.

Jitterbit oferece suporte aos conectores HTTP e HTTP v2.

A intenção de longo prazo da Jitterbit é descontinuar o conector HTTP, que será anunciado de acordo com a Política de Fim de Vida da Jitterbit. No momento, não há cronograma para descontinuação e o conector HTTP permanece totalmente compatível. Recomendamos que você converta conexões e atividades HTTP existentes para HTTP v2 quando possivel.

Conectores de Aplicativos

Numerosos conectores de aplicativos estão disponíveis e continuam a ser desenvolvidos.

Na maioria dos casos, se um conector de aplicativo estiver disponível para seu endpoint, recomendamos usá-lo em um dos conectores HTTP genéricos. Os conectores de aplicativos geralmente incluem recursos específicos de endpoint que são mais fáceis de configurar usando o conector específico em vez dos conectores genéricos. Porém, caso você tenha uma necessidade específica que não esteja disponível no endpoint da aplicação, usar um conector genérico é uma alternativa lógica.

Considerando a intenção da Jitterbit de eventualmente descontinuar o conector HTTP, recomendamos o uso de conectores de aplicativo ou o conector HTTP v2 em novos projetos sempre que possível.

Conectores Personalizados

Para maior flexibilidade, você pode criar conectores personalizados usando o Connector Builder ou o Connector SDK:

Construtor de Conectores
Os conectores do Custom Connector Builder podem ser projetados para usar autenticação básica ou nenhuma autenticação. Durante a criação do conector, você seleciona entre os métodos HTTP suportados GET, POST, PUT, DELETE, PATCH ou MERGE para criar as atividades correspondentes para os usuários configurarem.
SDK do conector
Conector personalizado Os conectores SDK podem ser projetados para usar qualquer tipo de autenticação e o suporte para qualquer método pode ser integrado ao conector. Esse tipo de conector personalizado oferece maior flexibilidade, pois um desenvolvedor pode adicionar melhorias de acordo com as necessidades da sua organização.

Matriz de Capacidade para Conectores Jitterbit

Capacidade do conector	Conector HTTP v2	Conector HTTP	Conector específico do aplicativo
Suporte para autorização	Uma conexão HTTP v2 suporta estes tipos de autorização: Chave de API Assinatura AWS Autorização Básica Token do portador Autorização Digest Sem autorização OAuth 2.0	Uma conexão HTTP suporta estes tipos de autorização: Autorização Básica Autorização Digest	O suporte varia de acordo com o conector.
Suporte ao método HTTP	O conector HTTP v2 suporta estes métodos com estas atividades de mesmo nome: GET POST PUT DELETAR PATCH CABEÇA OPÇÕES	O conector HTTP suporta estes métodos com estas atividades de mesmo nome: GET POST PUT DELETAR Personalizado (qualquer verbo especificado pelo usuário)	O suporte varia de acordo com o conector.
Suporte ao padrão de operação para atividades usadas como fontes	As atividades HTTP v2 usadas como fonte podem ser usadas com estes padrões: Padrão de Transformação Padrão de arquivo de dois alvos (apenas como a primeira fonte) Padrão de arquivo HTTP de dois destinos (apenas como a primeira fonte) Padrão de duas transformações (como a primeira ou segunda fonte)	As atividades HTTP usadas como fonte podem ser usadas com estes padrões: Archive Pattern Padrão de transformação Padrão de arquivo de dois alvos (apenas como a primeira fonte) Padrão de arquivo HTTP de dois destinos (como a primeira ou segunda fonte) (Consulte Nota para atividades HTTP GET abaixo desta tabela.) Padrão de duas transformações (apenas como a primeira fonte) Padrão de destino em massa do Salesforce	O suporte varia de acordo com o conector. A maioria das atividades de conector específicas do aplicativo usadas como origem podem ser usadas com estes padrões: Padrão de Transformação Padrão de arquivo de dois alvos (apenas como a primeira fonte) Padrão de arquivo HTTP de dois destinos (apenas como a primeira fonte) Padrão de duas transformações (como a primeira ou segunda fonte)
Suporte ao padrão de operação para atividades usadas como destinos	As atividades HTTP v2 usadas como destino podem ser usadas com estes padrões: Padrão de Transformação Padrão de duas transformações (como primeiro ou segundo alvo)	As atividades HTTP usadas como destino podem ser usadas com estes padrões: Archive Pattern Padrão de script Padrão de transformação Padrão de arquivo de dois alvos (apenas como segundo destino) Padrão de arquivo HTTP de dois destinos (como o primeiro ou segundo destino) (Consulte Nota para atividades HTTP GET abaixo desta tabela.) Padrão de duas transformações (apenas como segundo destino) Padrão de origem em massa do Salesforce	O suporte varia de acordo com o conector. A maioria das atividades de conector específicas de aplicativos usadas como destino podem ser usadas com estes padrões: Padrão de Transformação Padrão de duas transformações (como primeiro ou segundo alvo)
Suporte a esquema	Os esquemas personalizados de solicitação e resposta são opcionais e podem ser fornecidos pelo usuário durante a configuração da atividade HTTP v2. Se os esquemas personalizados não forem fornecidos na configuração da atividade, esquemas padrão que suportam um design geral da API REST será usado.	Os esquemas personalizados de solicitação e resposta são opcionais e podem ser fornecidos pelo usuário durante a configuração da atividade HTTP.	O suporte varia de acordo com o conector. Os esquemas de solicitação e resposta podem ser gerados diretamente do endpoint ou o suporte a esquemas personalizados pode estar disponível.
Funções Jitterbit e JavaScript baseadas em arquivo	Grave os dados em um arquivo temporário e, em seguida, use o caminho de referência da string para essa atividade do arquivo temporário como o `sourceId` ou `targetId` parâmetro de função.	Use o caminho de referência da string para a atividade como o `sourceId` ou `targetId` parâmetro de função.	Grave os dados em um arquivo temporário e use o caminho de referência da string para essa atividade do arquivo temporário como o `sourceId` ou `targetId` parâmetro de função. Alguns conectores podem ter suporte adicional.
Número de novas tentativas	Máximo de 5 tentativas enviadas em intervalos de até 5 segundos. Compatível apenas com Agentes Privados.	Máximo mais alto (recomendado não mais que 5 tentativas) em intervalos de até 5 segundos. Compatível apenas com Agentes Privados.	O suporte varia de acordo com o conector.
Tempo limite de transferência	30 segundos por padrão. O `connection-timeout` na área Configurações adicionais da configuração da atividade HTTP v2 pode ser usada para alterar o tempo limite de transferência.	3.600 segundos por padrão. As variáveis de origem Jitterbit e variáveis de destino cujos nomes terminam com `http.transfer.timeout` pode ser usado para alterar o tempo limite de transferência.	O suporte varia de acordo com o conector.
Suporte para redirecionamentos	50 redirecionamentos por padrão. O `max-redirect` na área Configurações adicionais da configuração da atividade HTTP v2 pode ser usada para alterar o número de redirecionamentos a seguir.	Os redirecionamentos não são seguidos por padrão. As variáveis de origem Jitterbit e variáveis de destino cujos nomes terminam com `http.max_redirs` pode ser usado para permitir que redirecionamentos sejam seguidos.	O suporte varia de acordo com o conector.
Suporte para dados de formulário	A configuração Multipart do HTTP v2 POST, COLOCAR e PATCH pode ser usada para suportar uploads de formulários RFC 1687 ao usar esquemas padrão. Não compatível com esquemas personalizados.	As variáveis de destino Jitterbit cujos nomes incluem `http.form_data` pode ser usado com uploads de formulário RFC 1687.	O suporte varia de acordo com o conector.
Suporte para remoção de espaços em branco e quebras de linha	Os espaços em branco e as quebras de linha da solicitação permanecem inalterados por padrão. O `trailing-linebreaks` na área Configurações adicionais da configuração da atividade HTTP v2 pode ser definida como verdadeira para remover espaços em branco iniciais e finais e quebras de linha.	O `http.remove_trailing_linebreaks` variável de destino Jitterbit pode ser usado para remover espaços em branco iniciais e finais e quebras de linha.	O suporte varia de acordo com o conector.
Configuração Keep Alive	A configuração Keep Alive em uma conexão HTTP v2 pode ser usado para manter uma única conexão TCP aberta para múltiplas solicitações e respostas HTTP.	Não suportado.	O suporte varia de acordo com o conector.
Suporte para cookies	Não suportado.	Suportado apenas se estiver usando um Agente Privado e a `jitterbit.http.enable_cookies` contexto está configurado para `true` no arquivo de configuração do agente (`jitterbit.conf`).	O suporte varia de acordo com o conector.
Suporte para certificados personalizados	Não suportado.	Um certificado para autenticação com o servidor HTTP pode ser especificado usando o campo Certificado de uma conexão HTTP.	O suporte varia de acordo com o conector.
Suporte para Expect: 100-continue	Não suportado.	O cabeçalho Expect: 100 continue é enviado quando Send `Expect 100-continue` está selecionado em uma conexão HTTP.	O suporte varia de acordo com o conector.
Suporte para cifras fracas	Não suportado.	Servidores HTTP que usam cifras fracas (DES/3DES e RC4) podem ser usados quando Permitir cifras fracas estiver selecionado em uma conexão HTTP.	O suporte varia de acordo com o conector.
Suporte para plug-ins Jitterbit	Não suportado.	Os plug-ins Jitterbit estão disponíveis para configuração durante a última etapa da configuração da atividade HTTP (consulte Plugins adicionados a uma atividade).	Não suportado.
Suporte para login em Agentes Privados	O conector HTTP v2 suporta registro detalhado do conector.	O conector HTTP suporta registro de depurar Curl.	O suporte varia de acordo com o conector.

Nota para Atividades HTTP GET

Quando uma atividade HTTP GET é usada como Target Activity 1 / Source Activity 2 no Padrão de arquivo HTTP de dois destinos, a atividade retorna uma mensagem indicando sucesso {"success": true} ou fracasso {"success": false} em vez da resposta real.

Funções Jitterbit e JavaScript Baseadas em Arquivo

As funções Jitterbit e JavaScript baseadas em arquivo estão listadas abaixo. As atividades do conector HTTP podem ser usadas diretamente como um parâmetro de função. Para uso com conectores HTTP v2 e de aplicativo, grave os dados em um arquivo temporário e, em seguida, use esse arquivo temporário na função de script.

Funções Jitterbit

Funções JavaScript Jitterbit