Glossário¶

Conectividade¶

Os recursos de conectividade são acessados na paleta de componentes de design. Na aba Conexões da paleta de componentes de design, conectores são configurados primeiro para criar conexões. As atividades associadas a essas conexões podem então ser instanciadas usando os tipos de atividades e configuradas como origens ou destinos em um projeto. Um endpoint refere-se a uma conexão específica e suas atividades.

• Conectores: Os conectores, mostrados na categoria Conectores, fornecem a interface para inserir entradas fornecidas pelo usuário, como credenciais, para criar uma conexão. Você também pode criar conectores personalizados.
• Endpoints: Um endpoint refere-se a uma conexão específica e suas atividades:
  • Conexões: Uma conexão, mostrada na categoria Endpoints, é um componente criado a partir de um conector e fornece acesso a um recurso de dados. As conexões podem ser locais para o projeto ou criadas como conexões globais que pode ser usado em projetos em um ambiente.
  • Atividades: Um tipo de atividade, mostrado quando uma conexão na categoria Endpoints é clicada, é um componente criado a partir de uma conexão e configurado para interagir com um endpoint. Os tipos de atividades são usados para criar uma instância de uma atividade em um projeto. As instâncias de atividade podem atuar como fontes (fornecendo dados) ou alvos (recebendo dados).

Dependências¶

Alguns componentes do projeto podem depender de outros componentes para funcionar corretamente. Duas frases distintas são usadas para discutir dependências: dependente de e dependência de. Nos exemplos a seguir, o Componente A é dependente do Componente B. O Componente B é uma dependência de Componente A:

• Dependente de: Se um componente depende de outro componente, ele precisa desse componente para funcionar corretamente. Um componente que depende de outro componente não pode funcionar sozinho sem esse componente. Quando o Componente A precisa do Componente B para ser executado com sucesso, o Componente A depende do Componente B. Outra maneira de dizer isso é que o Componente A depende do Componente B.
• Dependência de: Se um componente é uma dependência de outro componente, ele é necessário para o primeiro componente para que o primeiro componente funcione corretamente. Um componente que é uma dependência de outro componente é o componente necessário para outro. Quando o Componente A precisa do Componente B para ser executado com sucesso, o Componente B é uma dependência do Componente A.

Receita de Integração¶

Uma receita de integração do Cloud Studio, disponível através do Jitterbit Marketplace, é um projeto de integração único e pré-construído que move dados em uma direção entre objetos em dois aplicativos ou sistemas. As receitas de integração estão disponíveis para todos os assinantes do Harmony.

Operação¶

Uma operação é a menor unidade dentro de um workflow que é executado de forma independente em um agente e registrado pelo Harmony (tempo de início e execução, sucesso, falha, erros, arquivos de log de depurar, etc.). As operações são usadas para definir o que uma integração deve fazer e quando deve ser feita.

Uma operação consiste em pelo menos uma etapa de operação e geralmente contém várias etapas de operação que consistem em atividades, transformações ou scripts. As etapas da operação são os componentes discretos que compõem uma operação e são representados visualmente dentro de uma operação na quadro de design:

As operações devem seguir um padrão de operação válido. Combinações que não são permitidas em uma única operação podem ser funcionalmente possíveis encadeando múltiplas operações usando ações de operação. Depois de criadas, as operações podem ser executadas manualmente, acionadas por uma API ou evento, ou agendadas.

Modelo de Processo¶

Um modelo de processo do Cloud Studio, disponível através do Jitterbit Marketplace, é um grupo de casos de uso de integração pré-construídos que acelera a execução de um processo de negócios específico usando vários objetos em vários aplicativos ou sistemas.

Os modelos de processo são projetados para reduzir o tempo de implantação em 50 a 80 por cento e podem ser autoimplementados, entregues pelos Jitterbit Professional Services ou por um parceiro de implementação.

Um modelo de processo consiste em um ou mais projetos usando vários endpoints, pode incluir arquivos de customização e possui documentação própria em formato PDF. Depois que os projetos forem criados, você deverá inserir valores apropriados nas variáveis do projeto que definem credenciais e outras informações para o projeto em cada projeto individualmente.

Projeto¶

Um projeto é uma coleção de um ou mais workflows que compõem e executam um caso de uso de integração. Um projeto contém operações, bem como outros componentes do projeto que pode fazer parte de uma operação ou ser utilizado para apoiar operações. Um projeto pode ser compartilhado, arquivado ou redistribuído exportando e importando o projeto como um arquivo JSON.

Componente do Projeto¶

Componentes do projeto são os blocos de construção discretos de um projeto. Alguns componentes, incluindo atividades, transformações e scripts, pode ser adicionado a operações e executado como uma sequência de etapas. Outros componentes podem ser usados para dar suporte a essas operações, como variables, horários, esquemas, notificações e plug-ins. As próprias operações também são componentes do projeto.

Scripts¶

Scripts, escritos em Jitterbit Script ou JavaScript, fornecem flexibilidade e poder para transformar dados, realizar cálculos ou realizar validação lógica além do simples mapeamento de campo.

Os Scripts podem ser usados em vários locais, tanto na quadro de design como etapas de uma operação, bem como em transformações para aplicar lógica ou condições especificadas aos dados.

Transformação¶

Uma transformação é um componente do projeto usado como uma etapa em uma operação para mapear ou transformar entradas em uma saída resultante, movendo dados, limpando dados ou aplicando lógica de negócios.

Uma transformação consiste em esquemas de origem e de destino que foram definidos na transformação e no mapeamento de transformação que gera a saída. Um esquema de origem é necessário somente quando uma atividade de origem adjacente fornece dados de entrada que precisam ser transformados. Um esquema de destino é sempre necessário.

Os esquemas de origem e de destino podem ser fornecidos por uma atividade adjacente ou definidos em uma transformação, com esquemas fornecidos por uma atividade adjacente tendo precedência. Os esquemas fornecidos pelas atividades adjacentes não fazem parte da transformação. Além disso, uma transformação não inclui os próprios dados de entrada ou saída.

A configuração de uma transformação pode ocorrer no modo de mapeamento ou no modo de script.

Além disso, ao configurar uma transformação, você também deve estar familiarizado com estes termos:

• Mapeamento: Um mapeamento de transformação consiste em campos ou nós de destino e seus scripts correspondentes. Esses scripts podem conter referências a campos ou nós de origem ou a componentes do projeto, usar funções ou conter outra lógica de script válida. Um mapeamento não inclui campos de destino que não estejam mapeados.

• Condição: Uma condição, conforme usada em uma transformação, é um script aplicado no destino para determinar se o registro de origem que está sendo processado deve ser enviado para o destino. Se o script for avaliado como verdadeiro, o registro será gerado. Se o resultado do script for avaliado como falso, o registro será ignorado.

  

• Nó de loop: Um nó de loop é um nó de origem ou de destino com valores de dados repetidos, como itens de linha em uma fatura ou um conjunto de registros de clientes. Quando os campos do nó de loop são mapeados, uma linha iteradora preta sólida aparece automaticamente, indicando que o processo de transformação percorrerá o conjunto de dados de origem. Uma transformação pode ter zero ou mais linhas iteradoras.

  

Variáveis¶

Variáveis são usados ao longo de um projeto para tornar as integrações mais flexíveis e dinâmicas. Eles permitem a configuração dinâmica de endpoints, suportam a passagem de dados entre operações e são usados em scripts de transformação para conduzir uma lógica de integração detalhada.

O Harmony oferece suporte a vários tipos de variáveis com escopos variados:

• Variáveis Locais: Limitado ao script atual.
• Variáveis Globais: Disponível para scripts atuais e abaixo.
• Variáveis do projeto: Disponíveis em todos os workflows do projeto e acessíveis fora do Cloud Studio por meio do Management Console e do Citizen Integrator.
• Variáveis Jitterbit: Predefinidas pelo Harmony e disponíveis para scripts atuais e abaixo.

Além disso, palavras-chave filename podem ser usadas para gerar nomes de arquivos exclusivos para campos configuráveis que usam nomes de arquivos como entrada.

As melhores práticas de integração sugerem que você use a variável com escopo mais limitado, para minimizar o risco de alteração de valores de variáveis em vários componentes do projeto.

Workflow¶

Um workflow é uma coleção de operações usado como ferramenta para ajudar a segregar diferentes partes do projeto para conveniência do usuário.

Os Workflows são criados na parte superior da quadro de design:

Quando você cria um novo workflow, uma tela em branco é aberta, pronta para você projetar o workflow criando operações.

Os Workflows não podem ser executados; apenas as operações dentro deles podem ser executadas. Se o workflow estiver configurado de forma que uma operação leve à execução em cadeia de todas as outras operações em um workflow, você poderá executar efetivamente todas as operações no workflow.

Você também pode executar operações individuais em workflows, o que pode levar à execução de operações no mesmo ou em outros workflows. Ou seja, se alguma operação estiver a acima na cadeia de outras operações em uma cadeia de operação, dentro ou fora do workflow, as operações a abaixo serão iniciadas de acordo. Dessa forma, você pode executar com eficácia todas as operações de um projeto.