Criar e publicar modelos de fluxo de trabalho para Aplicativos Lógicos do Azure

Artigo
11/13/2024

Aplica-se a: Aplicativos Lógicos do Azure (Standard)

Os Aplicativos Lógicos do Azure fornecem modelos de fluxo de trabalho de integração predefinidos que você pode usar para acelerar o processo de criação de aplicativos de integração. Esses modelos seguem padrões comumente usados e ajudam você a simplificar o desenvolvimento ao oferecerem um ponto de partida ou linha de base com configurações e lógicas de negócios predefinidas.

Além de iniciar o desenvolvimento com modelos de fluxo de trabalho, você pode criar modelos de fluxo de trabalho para seu próprio uso ou compartilhá-los com outras pessoas. Seu modelo pode incluir artefatos como esquemas, mapas e assemblies personalizados. Para adicionar seu modelo à galeria de modelos no portal do Azure, crie um pacote de modelo usando este guia de instruções. Quando terminar, visite o repositório de modelos de fluxo de trabalho no GitHub para Aplicativos Lógicos do Azure em que você pode criar uma pull request para o pacote de modelos e fazer com que a equipe de Aplicativos Lógicos do Azure examine seu modelo.

Limitações

Atualmente, os modelos de fluxo de trabalho atualmente aceitam apenas aplicativos lógicos Standard e fluxos de trabalho únicos.

O que um pacote de modelo inclui?

A tabela a seguir descreve os arquivos opcionais em um pacote de modelo:

Nome do arquivo	Obrigatório	Descrição
workflow.json	Sim	Um arquivo JSON com sua definição de fluxo de trabalho.
manifest.json	Sim	Um arquivo JSON com informações sobre seu fluxo de trabalho e componentes relacionados.
*<image-name>-dark.png*	Sim	Um arquivo de imagem com o fluxo de trabalho como uma captura de tela somente leitura no formato .png e funciona com o tema escuro de um navegador.
*<image-name>-light.png*	Sim	Um arquivo de imagem com o fluxo de trabalho como uma captura de tela somente leitura no formato .png e funciona com o tema claro de um navegador.
*<map-name>.json, .xml, or .xslt*	Não	Quaisquer artefatos, como mapas e esquemas que dão suporte ao modelo de fluxo de trabalho.
*<custom-assembly>.dll*	Não	Todos os assemblies personalizados que dão suporte ao modelo de fluxo de trabalho.
readme.md	Não	Um arquivo Markdown com instruções, procedimentos ou outras informações para o modelo de fluxo de trabalho.

Você também pode incluir outros arquivos para manter e dar suporte ao modelo, por exemplo, arquivos com dados de teste ou de exemplo.

Criar uma pasta de pacote de modelo

Antes de criar a pasta do pacote de modelo, familiarize-se com Convenções de nomes e estilos.
Para manter o repositório de modelos mais fácil de procurar, organizar e manter, use a seguinte sintaxe para o nome da pasta e o menor número de palavras para evitar exceder o limite de caracteres para caminhos de arquivo:

<workflow-task>-<product>-<pattern-or-protocol, se houver>

Para obter exemplos, consulte o repositório de modelos de fluxo de trabalho para Aplicativos Lógicos do Azure no GitHub.
Para registrar corretamente a pasta do pacote de modelo, você deve adicionar o nome da pasta ao arquivo manifest.json de nível raiz do repositório.

Criar um arquivo workflow.json

O arquivo workflow.json contém a definição subjacente para um fluxo de trabalho no formato JSON. Para criar o arquivo workflow.json, você precisa copiar e salvar sua definição de fluxo de trabalho como um arquivo chamado workflow.json.

Para obter a definição de fluxo de trabalho mais fácil e melhor, crie seu fluxo de trabalho usando o designer. Examine as Práticas recomendadas do fluxo de trabalho juntamente com Nomes e convenções de estilo. Ou, como ponto de partida, você pode usar os modelos de fluxo de trabalho predefinidos da galeria de modelos no portal do Azure.

À medida que você cria seu fluxo de trabalho, o designer inclui automaticamente referências a quaisquer conexões internas, de provedor de serviços, conexões de API gerenciadas ou bibliotecas na definição de fluxo de trabalho subjacente.

Depois de terminar, copie a definição de fluxo de trabalho subjacente para um arquivo de workflow.json vazio.

Práticas recomendadas do fluxo de trabalho

Use as operações internas o máximo possível. Por exemplo, o conector do Armazenamento de Blobs do Azure tem as seguintes versões disponíveis para fluxos de trabalho Standard:
- Uma versão interna do provedor de serviços, que aparece na galeria de conectores com o rótulo No aplicativo. Essa versão é hospedada e executada com o runtime de Aplicativos Lógicos do Azure de locatário único, oferecendo melhor desempenho, taxa de transferência e outros benefícios.
- Uma versão da API gerenciada pela Microsoft, que aparece na galeria de conectores com o rótulo Compartilhado. Essa versão é hospedada e executada no Azure multilocatário usando recursos globais compartilhados.
Não use propriedades codificadas e seus valores em definições de gatilho e ação.
Forneça mais contexto sobre definições de gatilho e ação adicionando comentários descritivos e úteis.

Copiar a definição de fluxo de trabalho subjacente

No portal do Azure, no menu fluxo de trabalho, em Desenvolvedor, selecione Código.
Na janela de exibição de código, copie toda a definição de fluxo de trabalho, por exemplo:
Em um arquivo vazio chamado workflow.json, salve a definição do fluxo de trabalho.

Referências de parâmetro no workflow.json

Ao referenciar parâmetros no arquivo workflow.json, você deve refletir os nomes de parâmetro que usam o sufixo _#workflowname# da seguinte maneira:

"name": "@parameters('<parameter-name>_#workflowname#')"

Por exemplo:

"name": "@parameters('sharepoint-folder-path_#workflowname#')"

Referências de conexão no workflow.json

Ao referenciar conexões no arquivo workflow.json, você deve refletir os nomes de conexão que usam o sufixo _#workflowname# da seguinte maneira:

"referenceName": "<connector-ID>_#workflowname#",
"connectionName": "<connector-ID>_#workflowname#"

Por exemplo:

"referenceName": "azureaisearch_#workflowname#",
"connectionName": "azureaisearch_#workflowname#"

Para obter mais informações sobre a ID do conector SAP, confira Localizar a ID do conector.

Criar uma imagem do modelo de fluxo de trabalho

No portal do Azure, cada modelo de fluxo de trabalho tem um painel de visão geral na galeria de modelos de fluxo de trabalho. Esse painel inclui uma imagem de visualização somente leitura para o fluxo de trabalho que o modelo cria, além de outras informações de modelo.

Para criar esta imagem de visualização, siga estas etapas:

No designer, configure seu fluxo de trabalho para criar duas capturas de tela.

Você precisa criar uma versão para o tema claro do navegador e o tema escuro.
Crie as capturas de tela do fluxo de trabalho usando sua ferramenta de captura de tela preferida. Não inclua muito espaço em branco ao redor do fluxo de trabalho.
Salve cada imagem usando a extensão de nome de arquivo .png e qualquer nome desejado, seguindo as convenções de Nomes e estilo.
No arquivo manifest.json para o pacote de modelo de fluxo de trabalho, adicione os mesmos nomes de imagem à seção images sem a extensão de nome do arquivo .png, por exemplo:
```
"images": {
    "dark": "workflow-dark",
    "light": "workflow-light"
}
```

Criar um arquivo manifest.json

O arquivo manifest.json descreve a relação entre um fluxo de trabalho e componentes relacionados. No momento, você precisa criar manualmente esse arquivo ou recompilar o arquivo manifest.json de um modelo predefinido existente no repositório de modelos de fluxo de trabalho de Aplicativos Lógicos do Azure no GitHub. Ao criar o arquivo manifest.json, examine os nomes e as convenções de estilo.

A tabela a seguir descreve os atributos no arquivo manifest.json:

Nome do atributo	Obrigatório	Valor	Descrição
`title`	Sim	<template-title>	O título que aparece na galeria de modelos, que é aberta quando você adiciona um fluxo de trabalho de um modelo no portal do Azure.
`description`	Sim	<template-description>	A descrição do modelo, que aparece no painel de visão geral do modelo na galeria de modelos.
`prerequisites`	Não	<template-prerequisites>	Todos os pré-requisitos a serem atendidos para usar o modelo. Aparece no painel de visão geral do modelo. Você pode vincular a outros documentos desta seção.
`tags`	Não	<template-tags-array>	As marcas de modelo a serem usadas para pesquisar ou filtrar modelos.
`skus`	Sim	`standard`, `consumption`	O tipo de fluxo de trabalho do aplicativo lógico compatível com o modelo. Se você não tiver certeza, use `standard`.
`kinds`	Não	`stateful`, `stateless`	O modo de fluxo de trabalho, que determina se o histórico de execução e os estados de operação são armazenados. Por padrão, todos os fluxos de trabalho estão disponíveis no modo com estado e sem estado. Se o fluxo de trabalho for executado apenas no modo com estado, use esse atributo para tornar esse requisito explícito.
`detailsDescription`	Não	Consulte a descrição.	Qualquer outra informação de descrição detalhada para o modelo.
`details`	Não	Consulte a descrição.	Informações de modelo a serem usadas para filtrar a galeria de modelos. - `By`: o editor de modelos, por exemplo, `Microsoft`. - `Type`: `Workflow` - `Trigger`: o tipo de gatilho, por exemplo, `Recurrence`, `Event`ou `Request`.
`artifacts`	Sim	<artifacts-array>	Todos os arquivos relevantes no pacote de modelo e inclui os seguintes atributos: - `type`: o tipo de arquivo, que determina o local apropriado para onde copiar o arquivo, por exemplo, `workflow`. - `file`: o nome do arquivo e a extensão, por exemplo, workflow.json.
`images`	Sim	Consulte a descrição.	Os nomes de arquivo de imagem de fluxo de trabalho para temas claros e escuros do navegador: - `light`: nome da imagem para tema claro, por exemplo, workflow-light - `dark`: Nome da imagem para tema escuro, por exemplo, workflow-dark.
`parameters`	Sim, mas pode estar vazio se nenhum existir	<workflow-parameters-array>	Os parâmetros para as ações no modelo de fluxo de trabalho. Para cada parâmetro, você precisa especificar as seguintes propriedades: - `name`: o nome do parâmetro deve ter o sufixo, `_#workflowname#`. Use apenas caracteres alfanuméricos, hifens ou sublinhados e siga este format: `<parameter-name>_#workflowname#` - `displayName`: o nome de exibição amigável do parâmetro. Consulte Convenções de nomes e estilos. - `type`: os tipos de dados do parâmetro, por exemplo, `String` ou `Int`. - `default`: o valor do parâmetro padrão, se houver. Se não houver, deixe esse valor como uma cadeia de caracteres vazia. - `description` Os detalhes do parâmetro e outras informações importantes ou úteis. - `required`: `true` ou `false`
`connections`	Sim, mas pode estar vazio se nenhum existir.	<connections-array>	As conexões a serem criadas usando o modelo de fluxo de trabalho. Cada conexão tem as seguintes propriedades: -`connectorId`: a ID do conector deve ter o sufixo, `_#workflowname#`. Use apenas caracteres alfanuméricos, hifens ou sublinhados e siga este format: `<connector-ID>_#workflowname#` Para localizar a ID do conector SAP, confira Localizar a ID do conector. - `kind`: o tipo de host de runtime do conector, que é `inapp` para operações internas e conectores do provedor de serviços ou `shared` para conectores gerenciados hospedados no Azure. Na galeria de conectores, as operações internas e os conectores do provedor de serviços são rotulados como No App, enquanto os conectores gerenciados são rotulados como Compartilhados.
`featuredConnections`	Não	<featured-connections-array>	Por padrão, a galeria de modelos mostra ícones para as operações predefinidas e conectores nos Aplicativos Lógicos do Azure usados por cada modelo. Para incluir ícones para qualquer outra operação, você pode usar o atributo `featuredConnections`. Cada operação deve ter os seguintes atributos: - `kind`: o tipo de operação - `type`: o tipo de operação Para localizar esses valores, consulte Localizar o tipo de operação e o tipo da seção featuredConnections.

Localizar a ID do conector

Para localizar a ID do conector a ser usada para uma conexão no arquivo manifest.json ou uma referência de conexão no arquivo workflow.json, siga estas etapas:

Abra o recurso de aplicativo lógico no portal do Azure.
No menu do aplicativo lógico, em Fluxos de trabalho, selecione Conexões.
Escolha a guia Exibição do JSON.
Para testar a conexão, siga estas etapas:
- Para uma conexão de API gerenciada e "compartilhada" hospedada e executada no Azure:
  1. Localize a seção managedApiConnections.
  2. No atributo connection, copie e salve o valor id, mas substitua quaisquer dados pessoais ou confidenciais, como a ID da assinatura, o nome do grupo de recursos e assim por diante, por #<item>#:
    
    /subscriptions/#subscription#/providers/Microsoft.Web/locations/#location#/managedApis/<connection-name>
    
    Por exemplo, o texto a seguir mostra a ID do conector para o conector do SharePoint:
    
    /subscriptions/#subscription#/providers/Microsoft.Web/locations/#location#/managedApis/sharepointonline
- Para uma conexão de provedor de serviços hospedada no runtime de Aplicativos Lógicos do Azure de locatário único:
  1. Localize a seção serviceProviderConnections.
  2. Para cada conexão, localize o atributo id no atributo serviceProvider.
  3. Copie e salve os seguintes valores a seguir:
    
    /serviceProviders/<connection-name>
    
    Por exemplo, o texto a seguir mostra a ID do conector para o conector de Pesquisa de IA do Azure:
    
    /serviceProviders/azureaisearch.

Localizar as propriedades 'kind' e 'type' da operação para featuredConnections

No arquivo manifest.json, a seção featuredConnections pode incluir ícones para quaisquer outras operações que você deseja incluir com a galeria de modelos no portal do Azure. Para esta seção, que é uma matriz, você precisa fornecer os atributos kind e type para cada operação.

Para obter esses valores de atributo, siga estas etapas no portal do Azure com o fluxo de trabalho aberto:

No menu fluxo de trabalho, em Desenvolvedor, selecione Monitor.
Na janela exibição de código, na seção actions, localize a operação desejada e localize os valores kind e type.

Adicionar pacote de modelo ao repositório GitHub

Para publicar seu modelo na galeria de modelos no portal do Azure, configure o GitHub e crie uma pull request com seu pacote de modelo para validação e revisão:

Criar uma conta gratuita no GitHub, caso ainda não tenha uma.

Para obter mais informações, confira Introdução à conta GitHub.
Vá para o repositório de modelos de fluxo de trabalho chamado LogicAppsTemplates para Aplicativos Lógicos do Azure no GitHub.
Crie sua própria bifurcação, que é uma cópia remota do repositório LogicAppsTemplates no GitHub.

Para obter mais informações, consulte o Bifurcação de um repositório.
Para trabalhar localmente, clone sua bifurcação em seu computador.
1. Siga estas etapas para baixar, instalar e configurar o Git.
2. Vá para a bifurcação, que tem a seguinte URL:
  
  https://github.com/<your-username>/LogicAppsTemplates
3. No computador local, crie uma pasta chamada GitHub, caso ainda não tenha uma. Não clone em uma pasta sincronizada do OneDrive.
4. Siga estas etapas para clonar sua bifurcação, não o repositório de produção.
5. No repositório local, siga estas etapas para criar uma ramificação de trabalho.
6. Depois de fazer check-out da ramificação de trabalho, vá para o nível raiz no repositório local e crie a pasta do pacote de modelo.
7. Adicione seus arquivos de modelo à pasta do pacote de modelo e atualize o arquivo de manifest.json no nível raiz com o nome da pasta.
8. Quando estiver tudo pronto para confirmar as alterações no repositório local, que é como salvar um instantâneo, execute os seguintes comandos usando a ferramenta de linha de comando do Git ou outras ferramentas:
  
  git add .
  
  git commit -m "<commit-short-description>"
9. Para carregar o instantâneo na bifurcação remota, execute o seguinte comando:
  
  git push origin <your-working-branch>
No GitHub, crie uma pull request para comparar <your-working-branch> com a ramificação maindo repositório LogicAppsTemplates.
1. Vá para a página Pull request do repositório e selecione Nova pull request.
2. Em Comparar alterações, selecione Comparar entre bifurcações.
3. Verifique se a pull request tem as seguintes configurações e selecione Criar pull request.
  
  Repositório de base Base Repositório de cabeçalho Comparar
  
  Azure/LogicAppsTemplates main <user-name>/LogicAppsTemplates <your-working-branch>
4. Insira um título e uma descrição para sua solicitação de pull. Na próxima página, selecione Criar pull request.
5. Aguarde até que a equipe de Aplicativos Lógicos do Azure examine sua solicitação de pull.
Para obter mais informações, consulte Criação de pull requests em uma bifurcação.

Repositório de base	Base	Repositório de cabeçalho	Comparar
Azure/LogicAppsTemplates	main	*<user-name>/LogicAppsTemplates*	*<your-working-branch>*

Convenções de nomes e estilos

Área	Convenção
Dados Confidenciais	Não inclua ou carregue dados pessoais e confidenciais em arquivos de modelo, capturas de tela, descrições ou dados de teste. Por exemplo, esses dados incluem IDs de assinatura, nomes de usuário, senhas e assim por diante.
Nomes de pastas	Para facilitar a legibilidade, use maiúsculas minúsculas e hifens quando possível. Consulte Capitalização – Guia de Estilo da Microsoft.
Nomes de arquivos de imagem	Use o .png como a extensão de nome de arquivo, letras minúsculas e hifens, por exemplo, workflow-light.png.
Nomes de produto, serviço, tecnologia e marcas	Siga a ortografia e a capitalização oficiais. Por exemplo: – Quando você se referir ao nome do serviço ou plataforma, use "Aplicativos Lógicos do Azure", não "Aplicativos Lógicos". – Quando você se referir ao recurso ou à instância, use "aplicativos lógicos" ou "aplicativo lógico", não "Aplicativo Lógico" ou "Aplicativos Lógicos". – Quando você se referir à sequência de gatilhos e ações, use "fluxo de trabalho do aplicativo lógico" ou "fluxo de trabalho".
Abreviações e acrônimos	Use o nome expandido para produto, serviço, tecnologia, nomes de marca e termos técnicos incomuns, não abreviações ou acrônimos. Acrônimos comuns, como "HTTP" e "URL", são aceitáveis. Por exemplo, use "Visual Studio Code", não "VS Code". Consulte Acrônimos – Guia de Estilo da Microsoft.
Outro texto	– Use maiúsculas e minúsculas para títulos, cabeçalhos e conteúdo do corpo, o que significa que você capitaliza apenas a primeira letra, a menos que tenha produto, serviço, tecnologia ou marca. – Não capitalize substantivos e artigos comuns, como "um", "e", "ou", "a", e assim por diante.
Voz	– Use a voz de segunda pessoa (você e sua), em vez de terceira pessoa (usuários, desenvolvedores, clientes), a menos que você precise se referir a funções específicas. Consulte Pessoa – Guia de Estilo da Microsoft. – Use um tom ativo, direto, mas amigável quando possível. A voz ativa se concentra no assunto e no verbo no texto, enquanto a voz passiva se concentra no objeto no texto.
Vocabulário	– Use palavras simples, comuns e cotidianas, como "usar", em vez de "utilizar" ou "aproveitar". – Não use palavras, frases, jargões, coloquialismos, idiomas ou gírias que não se traduzam bem entre idiomas. – Use "por favor" apenas em situações específicas. Consulte por favor – Guia de Estilo da Microsoft. - Use "por exemplo" ou "tal como", não "por exemplo" ou "ou seja". – Não use termos direcionais como "aqui", "acima", "abaixo", "direita" e "esquerda", que não são acessíveis amigáveis.
Pontuação	– Para uma série de itens, inclua a última vírgula antes da conjunção, como "e". Por exemplo, "maçãs, laranjas e bananas". Consulte Vírgulas – Guia de Estilo da Microsoft. – Encerre frases completas com pontuação apropriada. Não use pontos de exclamação. Consulte Pontuação – Guia de Estilo da Microsoft.
Formatação	– Para o código, siga a convenção de estilo para o idioma desse código. - Não use links codificados, que são interrompidos se as URLs forem alteradas. Em sua solicitação de PR, solicite um link de redirecionamento para usar em vez disso. - Para links, use o seguinte formato: "`For more information, see [descriptive-link-text](URL)]`.". - Use texto de link descritivo, não texto de link genérico ou vago, como "`See [here](URL)`". – Use números apenas para etapas em um procedimento, não para listas que não têm nenhuma ordem específica. Consulte Listas – Guia de Estilo da Microsoft. – Use apenas um espaço após a pontuação, a menos que você esteja recuando o código.

Para obter mais diretrizes, consulte Guia de Estilo da Microsoft e Dicas de redação globais.

Criar um fluxo de trabalho de aplicativo lógico Standard com base em um modelo predefinido

Compartilhar via

Criar e publicar modelos de fluxo de trabalho para Aplicativos Lógicos do Azure

Limitações

O que um pacote de modelo inclui?

Criar uma pasta de pacote de modelo

Criar um arquivo workflow.json

Práticas recomendadas do fluxo de trabalho

Copiar a definição de fluxo de trabalho subjacente

Referências de parâmetro no workflow.json

Referências de conexão no workflow.json

Criar uma imagem do modelo de fluxo de trabalho

Criar um arquivo manifest.json

Localizar a ID do conector

Localizar as propriedades 'kind' e 'type' da operação para featuredConnections

Adicionar pacote de modelo ao repositório GitHub

Convenções de nomes e estilos

Comentários

Recursos adicionais

Compartilhar via

Criar e publicar modelos de fluxo de trabalho para Aplicativos Lógicos do Azure

Limitações

O que um pacote de modelo inclui?

Criar uma pasta de pacote de modelo

Criar um arquivo workflow.json

Práticas recomendadas do fluxo de trabalho

Copiar a definição de fluxo de trabalho subjacente

Referências de parâmetro no workflow.json

Referências de conexão no workflow.json

Criar uma imagem do modelo de fluxo de trabalho

Criar um arquivo manifest.json

Localizar a ID do conector

Localizar as propriedades 'kind' e 'type' da operação para featuredConnections

Adicionar pacote de modelo ao repositório GitHub

Convenções de nomes e estilos

Conteúdo relacionado

Comentários

Recursos adicionais