Melhores práticas para o desenvolvimento de modelos de processo do Integration Studio

Introdução

Esta página fornece orientações e recomendações de melhores práticas para projetar modelos de processo do Integration Studio que serão carregados no Marketplace da Jitterbit. Este documento não é abrangente e não cobre todos os cenários.

Para melhores práticas gerais, consulte melhores práticas do Jitterbit iPaaS.

Melhores práticas

As seções a seguir fornecem uma visão geral das melhores práticas para modelos de processo:

Projetos
Operações
Scripts
Nomeação de Projetos e Componentes
Estrutura do Modelo de Processo

Projetos

Estas são diretrizes gerais para projetos:

Use variáveis de projeto para valores que mudam de usuário para usuário, como nomes de usuário e senhas. Além disso, ao criar variáveis de projeto, é uma boa prática prefixar as variáveis de projeto para que sejam fáceis de localizar. Por exemplo, uma variável de projeto org_netsuite_auth_username é primeiro prefixada com org, depois netsuite, etc., para organizá-la efetivamente em uma lista entre outras variáveis de projeto.
Exclua componentes não utilizados do projeto.
Remova quaisquer sufixos -Copy gerados automaticamente dos componentes do projeto e renomeie-os de forma lógica.

Operações

Estas são diretrizes gerais para operações:

Use um conector de aplicativo em vez dos conectores HTTP ou HTTP v2 sempre que possível.
Configure todas as operações para manipulação de erros. Para as melhores práticas de manipulação de erros, veja o Tech Talk sobre Melhores Práticas de Manipulação de Erros.

Scripts

Estas são diretrizes gerais para scripts:

Use recursos prontos para uso em vez de scripts sempre que possível.
Evite chamar operações dentro de scripts.
Evite chamar operações ou incluir lógica de script dentro de transformações.

Nomeação de projetos e componentes

Estas são as recomendações sobre a nomeação de projetos e seus componentes:

Componente	Padrão	Exemplo
Projeto	`<ação>` + `<endpoint>` + `<objeto>` para `<endpoint>` + `<objeto>`	`Sincronizar Contatos do Salesforce para Contatos do SAP`
Operação	`<ação>` + `<endpoint>` + `<objeto>`	`Obter Contatos do Salesforce`
Endpoint	`<endpoint>`	`Salesforce`
Atividade de Endpoint	`<ação>` + `<objeto>`	`Upsert Contatos`
Transformação	`<ação>` + `<objeto>` + `Requisição/Resposta`	`Upsert Requisição de Contatos do Salesforce`
Script	`<ação>` + `<objeto>`	`Enviar Email de Erro`
Variáveis do Projeto	`<endpoint>_<elemento>`	`Salesforce_Token_de_Segurança`
Variáveis Globais	Use camel case	`mensagemDeErro`

Além disso, o nome do projeto, a descrição e o fluxo de trabalho devem ter nomes correspondentes.

Nota

Certifique-se de que não há erros de ortografia ao nomear projetos e seus componentes.

Estrutura do modelo de processo

A seguinte estrutura descreve como cada operação deve funcionar dentro da cadeia de operações de um fluxo de trabalho:

Operação 1: A primeira operação é usada para configurar variáveis comuns para o registro de informações, como contagem de sucessos, contagem de falhas, resumo de sucessos e nomes de arquivos. Usando variáveis comuns, é possível gravar os arquivos de sucesso e falha e imprimir um log de resumo contendo os valores que as variáveis estão definidas. Uma vez configuradas, você pode configurar uma notificação por email que entrega essas informações ao destinatário que você definir.
Operação 2: A segunda operação recupera dados do endpoint de origem.
Operação 3: Quando um conector não suporta paginação, a terceira operação é usada para paginar os dados para endpoints de destino que suportam apenas um número limitado de registros.
Operação 4: A quarta operação implementa a lógica restante necessária para realizar uma ação no endpoint de destino.
Operação 5: A operação final é configurada para enviar uma única notificação por email que entrega uma compilação de mensagens de erro (de qualquer uma das operações) ao destinatário que você definir.