Desenvolvimento de modelos de processo para Jitterbit Studio
Introdução
Os modelos de processo do Studio, disponíveis através do Jitterbit Marketplace, são casos de uso de integração pré-construídos que executam um processo de negócios específico usando objetos em múltiplas aplicações ou sistemas.
Um modelo de processo consiste em um ou mais projetos utilizando múltiplos endpoints. Pode incluir arquivos de personalização e vem com sua própria documentação em formato PDF.

Preparação do Projeto
Antes de exportar um projeto do Studio, revise o projeto cuidadosamente e assegure-se de que não há informações nele que não deveriam estar lá. Inspecione todos os campos de senha quanto aos seus valores. Verifique quaisquer esquemas usados nos mapeamentos de transformação para a presença de informações confidenciais ou pessoalmente identificáveis (PII) ou informações de saúde protegidas (PHI).
Uma vez que um projeto tenha sido exportado, busque no arquivo JSON exportado para confirmar que não há informações que você não gostaria que fossem divulgadas, como endereços de email. Metadados extras podem estar presentes em projetos que foram criados e exportados de versões anteriores do Studio.
Requisitos de submissão
Para cada modelo de processo, os seguintes itens são necessários para a submissão:
-
Um ou mais projetos exportados do Harmony Studio necessários para o modelo de processo.
-
Um arquivo de manifesto de metadados em formato YAML descrevendo o modelo de processo e fornecendo os detalhes que são usados no Jitterbit Marketplace quando o modelo é exibido. O nome do arquivo de manifesto deve ser o mesmo nome do modelo de processo com a extensão
yaml. -
Um arquivo PDF documentando o modelo de processo, sua configuração, seu funcionamento e informações necessárias para usar o modelo de processo. Este arquivo será listado na entrada
DOCUMENTAÇÃOno manifesto. -
Quaisquer arquivos de personalização que são necessários para a configuração do modelo de processo. Embora vários arquivos de personalização sejam suportados no Marketplace, recomendamos, para facilitar o uso por todos (para você como desenvolvedor, para a Jitterbit como provedora de serviços e, mais importante, para o usuário do modelo de processo) que as personalizações necessárias sejam combinadas em um único arquivo ZIP. Um arquivo README apropriado com quaisquer instruções deve ser colocado no arquivo compactado com as personalizações necessárias.
Ao ter um único arquivo ZIP na etapa Baixar Personalizações da inicialização de um modelo de processo, um usuário tem apenas um item de download para lidar. Ele pode então passar isso (com o PDF de documentação, descrito acima) para a parte encarregada de configurar o endpoint.
Este pacote será listado na entrada
PACKAGESno manifesto.
Arquivo de manifesto
Um arquivo de manifesto de metadados, no formato YAML, é necessário para fornecer detalhes sobre o modelo de processo e seus constituintes. Este exemplo mostra os campos que precisam ser preenchidos:
```
Arquivo de Manifesto do Modelo de Processo
NAME: Modelo de Processo Salesforce-NetSuite CPQ-to-Billing
TYPE: template
A descrição pode ser de várias linhas ou vários parágrafos
Indente cada linha ou parágrafo subsequente
DESCRIPTION: Este modelo de processo processa automaticamente seus pedidos e faturas no Salesforce CPQ e Billing e no NetSuite. Sincroniza contatos, produtos, tabelas de preços, pedidos e faturas entre os sistemas.
AUTHOR: Jitterbit, Inc.
Uma lista dos projetos incluídos no modelo de processo
PROJECTS: - Salesforce_NetSuite_Contacts_Accounts_Bidirectional.json - Sync_NetSuite_Inventory-Items_to_Salesforce_Price-Book-Entry.json - Sync_NetSuite_Inventory-Items_to_Salesforce_Products.json - Sync_Salesforce_Invoices_to_NetSuite_Invoices.json - Sync_Salesforce_Orders_to_NetSuite_Sales-Orders.json
Uma lista de todos os documentos no modelo de processo
Atualmente, um único PDF é suportado
DOCUMENTATION: - Jitterbit Salesforce-NetSuite CPQ-to-Billing Process Template.pdf
Uma lista de todos os pacotes de personalização no modelo de processo
PACKAGES: - Salesforce-NetSuite CPQ-to-Billing Process Template Package.zip
Endpoints
Os endpoints especificados em uma receita de integração ou um modelo de processo são usados para filtrar os ativos mostrados no Marketplace. A lista de endpoints exibida no Marketplace não é fixa, mas é construída a partir daqueles usados pelos ativos no Marketplace. Incentivamos você a usar os endpoints existentes sempre que possível, embora você esteja livre para adicionar endpoints adicionais conforme necessário ou apropriado.
Se você adicionar novos endpoints, tenha em mente que nomes semelhantes ou derivados não são agregados. Para que uma coleção de ativos distintos apareça sob o mesmo endpoint, todos devem usar um nome de endpoint idêntico. Os endpoints são listados em ordem do número de ativos em cada endpoint específico. Como os cinco principais endpoints (conforme determinado pelo número de ativos com esse endpoint) são o que aparece quando o Marketplace é carregado, endpoints adicionais não são visíveis até que o usuário clique no botão Mostrar Mais.
Categorias
As categorias anexadas a uma receita de integração ou um modelo de processo são usadas para filtrar os ativos mostrados no Marketplace. A lista de categorias exibida no Marketplace não é fixa, mas é construída a partir daquelas usadas pelos ativos no Marketplace. Incentivamos você a usar as categorias existentes sempre que possível, embora você esteja livre para adicionar categorias adicionais conforme necessário ou apropriado.
As categorias são listadas em ordem do número de ativos em cada categoria específica. Como as cinco principais categorias (conforme determinado pelo número de ativos em uma categoria) são o que aparece quando o Marketplace é carregado, categorias adicionais não são visíveis até que o usuário clique no botão Mostrar Mais.
Ícones
Muitos ícones de endpoint padrão estão disponíveis no Marketplace da Jitterbit e são correspondidos usando os nomes no
campo ENDPOINTS do arquivo YAML do manifesto. Para determinar se um ícone está disponível, use os
filtros de endpoint do Marketplace
para ver os nomes disponíveis.
O ícone deve ser legível e reconhecível em um tamanho pequeno, como 40 por 40 pixels.
Se um ícone de endpoint não estiver atualmente disponível, envie o ícone como uma imagem SVG quadrada. Todos os ícones são um logotipo branco em um fundo de gradiente colorido que vai da cor da marca principal na parte superior para um tom mais escuro da mesma cor na parte inferior. Se a cor da marca principal for tal que um gradiente não funcionaria ou não for permitido, use um sólido da cor da marca principal em vez de um gradiente.
Uma alternativa de envio é uma imagem SVG quadrada branca com a cor especificada como uma única cor ou como um par de cores (superior e inferior) para o gradiente de fundo.
O ícone enviado, uma vez verificado como aceitável e instalado em uma versão do Marketplace, ficará disponível para uso. Até lá, substituiremos por um ícone em branco em seu lugar.