Descrever um fluxo de trabalho de Aplicativos Lógicos do Azure usando a Linguagem de Definição de Fluxo de Trabalho
Você define a estrutura e o fluxo de trabalho para um fluxo de trabalho do Aplicativo Lógico do Azure usando um documento JSON. Este documento contém uma descrição JSON dos elementos que compõem o fluxo de trabalho do aplicativo lógico e o esquema da Linguagem de Definição de Fluxo de Trabalho o valida. A maneira mais fácil de explicar o esquema é examinar um fluxo de trabalho existente criado usando o designer de fluxo de trabalho no portal do Azure e, em seguida, exibir a descrição JSON desse aplicativo lógico.
No cenário de exemplo, você deseja fornecer aos consultores fluxos de trabalho comuns que eles possam adaptar às necessidades específicas das universidades com as quais trabalham. Quer que seja o mais fácil possível personalizar e implementar cada fluxo de trabalho, portanto, decide ver o código associado ao fluxo de trabalho, ou seja, a definição do fluxo de trabalho do JSON.
Estruturador de fluxos de trabalho
O designer de fluxo de trabalho permite criar e depurar graficamente o fluxo de trabalho para um fluxo de trabalho de aplicativo lógico. O designer também permite que os desenvolvedores olhem sob o capô de um fluxo de trabalho para ver como ele é implementado. A imagem a seguir mostra um exemplo de um fluxo de trabalho simples, que é acionado pelo envio de uma solicitação HTTP GET para uma URL especificada. O resultado é devolvido na resposta HTTP. Neste exemplo, o fluxo de trabalho está enviando de volta uma mensagem simples Hello Logic Apps Template! .
Agora, vamos examinar a linguagem de definição de fluxo de trabalho usada pelo modelo JSON.
Vista de código
A janela Visualização de código mostra o documento JSON que descreve o fluxo de trabalho. No aplicativo de exemplo, o JSON tem esta aparência:
{
"definition": {
"$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
"actions": {
"Response": {
"inputs": {
"body": "Hello Azure Logic Apps Template!",
"statusCode": 200
},
"kind": "Http",
"runAfter": {},
"type": "Response"
}
},
"contentVersion": "1.0.0.0",
"outputs": {},
"parameters": {},
"triggers": {
"manual": {
"inputs": {
"method": "GET",
"schema": {}
},
"kind": "Http",
"type": "Request"
}
}
}
}
Observe as definition seções no escopo que se relacionam com as ações e gatilhos mostrados no designer. Você pode editar o código JSON neste documento para refletir quaisquer alterações necessárias na funcionalidade do fluxo de trabalho do aplicativo lógico. Você também pode adicionar outras ações e especificar como a lógica no fluxo de trabalho é executada de uma ação para outra.
Secção Triggers (Acionadores)
A secção triggers (acionadores) contém a descrição do tipo de acionador e como este pode ser invocado. Neste exemplo, o acionador é um acionador HTTP simples que é executado em resposta a um pedido HTTP GET.
"triggers": {
"manual": {
"inputs": {
"method": "GET",
"schema": {}
},
"kind": "Http",
"type": "Request"
}
}
Um acionador tem de incluir os seguintes elementos:
Um nome exclusivo dentro do fluxo de trabalho. No exemplo anterior, o nome padrão do gatilho é manual, mas você pode substituir o nome padrão por um identificador mais significativo.
O tipo de acionador. O tipo indica o evento que faz com que o acionador seja executado. Um acionador Request é executado em resposta a um pedido HTTP. Outros tipos de acionadores disponíveis incluem:
Recurrence para criar um acionador que é executado de acordo com uma agenda periódica.
HttpWebhook para escutar eventos num ponto final.
ApiConnection para responder a eventos acionados por outros serviços do Azure, como uma mensagem que chega em uma fila de mensagens, uma mensagem de email e assim por diante. O tipo de acionador ApiConnection é generalizado e o utilizador especifica detalhes adicionais, indicando o tipo de serviço e quaisquer informações de ligação necessárias.
A secção inputs. Esta seção especifica os dados que definem o comportamento do gatilho. Para um acionador Request, method indica o tipo de pedido HTTP que faz com que o acionador seja executado. Para um acionador ApiConnection, a secção inputs contém informações sobre como ligar ao recurso que aciona o evento (uma cadeia de ligação na fila de mensagens, por exemplo). Se o acionador é um acionador Request, a secção schema da definição de entrada especifica o esquema ao qual o payload do corpo do pedido deve obedecer. Os pedidos HTTP GET não têm um corpo de pedido, pelo que schema está vazio no exemplo anterior.
O exemplo a seguir mostra a definição de outro gatilho Request que inicia um fluxo de trabalho e recebe solicitações HTTP POST. Geralmente, um pedido POST fornece um corpo do pedido, com os dados a publicar. O corpo do pedido neste exemplo contém um nome do cliente e o endereço, que é composto pela rua e cidade.
"mypostrequest": {
"type": "Request",
"kind": "Http",
"inputs": {
"method": "POST",
"schema": {
"type": "object",
"properties": {
"customerName": {
"type": "String"
},
"customerAddress": {
"type": "Object",
"properties": {
"streetAddress": {
"type": "string"
},
"city": {
"type": "string"
}
}
}
}
}
}
}
Um acionador também pode especificar condições. O acionador será acionado apenas se estas condições forem cumpridas. O utilizador define as condições numa secção opcional, conditions. Por exemplo, poderá querer executar o acionador mypostrequest (mostrado no exemplo anterior) apenas se o corpo do pedido especificar uma cidade de Nova Iorque:
"mypostrequest": {
"type": "Request",
"kind": "Http",
"inputs": {
...
}
"conditions": [
{
"expression": "@equals(triggerOutputs()['body']['customerAddress']['city'], 'New York')"
}
]
}
Secção Actions (Ações)
A secção actions (ações) de uma Aplicação Lógica define a lógica e a estrutura do fluxo de trabalho. Contém uma série de itens de ação. Um item de ação é um bloco modular básico para a construção de fluxos de trabalho. Os itens de ação recebem entradas e produzem resultados, que são transmitidos para o próximo item de ação no fluxo de trabalho. A tabela a seguir lista diferentes tipos de ação disponíveis:
| Item de ação | Description |
|---|---|
| ApiConnection | Envia uma solicitação HTTP para um serviço específico. Esse tipo de ação permite integrar um fluxo de trabalho de aplicativo lógico com recursos do Azure, como o Barramento de Serviço do Azure, a Grade de Eventos do Azure e outros. A ação necessita de entradas que incluem uma cadeia de ligação para aceder ao serviço, bem como quaisquer informações adicionais e parâmetros necessários para invocar o serviço. |
| Compose | Combina várias entradas e expressões num único resultado. |
| Função | Permite-lhe chamar uma Função do Azure. |
| HTTP | Envia uma solicitação HTTP para um ponto de extremidade HTTP, em vez de um serviço do Azure. |
| Join | Utiliza uma matriz de itens de dados como entrada e gera uma cadeia com estes itens separados por um delimitador especificado. |
| Parse | Analisa um documento JSON num conjunto de tokens ao utilizar um esquema especificado. |
| Consulta | Filtra os itens numa matriz de entrada com uma condição especificada. |
| Response | Cria uma resposta para um pedido HTTP. |
| Tabela | Gera uma tabela HTML de uma matriz de objetos JSON. |
| Terminate | Cancela um fluxo de trabalho imediatamente. |
| Wait | Coloca em pausa o fluxo de trabalho durante um intervalo especificado ou até que seja atingido um tempo limite. |
| Workflow | Executa outro fluxo de trabalho de aplicativo lógico. |
| Condition | Um conjunto de tipos de ação (Foreach, If, Switch e Until) que lhe permitem implementar um fluxo programático de controlo num fluxo de trabalho. Pode iterar itens numa coleção, tomar decisões com base nos valores dos parâmetros de entrada e efetuar ciclos até que uma condição seja cumprida. |
| InitializeVariable, IncrementVariable, DecrementVariable |
Define, inicializa, atribui e modifica variáveis que pode transmitir entre itens de ação num fluxo de trabalho. |
Tal como um acionador, cada ação tem de ter um nome exclusivo no fluxo de trabalho. No exemplo a seguir, o nome da ação padrão é Response, mas você pode usar um identificador válido e mais significativo. Uma ação tem de ter uma secção inputs que especifica os dados em que a ação atua. Na ação Resposta, você pode especificar os dados para uma expressão a ser retornada na mensagem de resposta, juntamente com um código de status HTTP.
Em nossa definição básica de fluxo de trabalho, a ação gera uma resposta HTTP onde o corpo é uma mensagem curta.
"actions": {
"Response": {
"inputs": {
"body": "Hello Azure Logic Apps Template!",
"statusCode": 200
},
"kind": "Http",
"runAfter": {},
"type": "Response"
}
}
A secção runAfter indica onde a ação é executada na sequência de fluxo de trabalho. No exemplo anterior, existe apenas uma ação, pelo que é sempre executada quando o acionador é acionado. Se o fluxo de trabalho tiver várias ações, você poderá especificar o nome de uma ação e um status para essa ação nesta seção. A ação será executada se a ação executarDepois for concluída com o status especificado. O código seguinte mostra um exemplo. A ação mySecondAction é executada após myFirstAction, mas apenas se myFirstAction concluir com um estado de "Succeeded" (Êxito):
"actions": {
"mySecondAction": {
"inputs": {
...
},
"runAfter": {
"myFirstAction": [
"Succeeded"
]
},
"type": ...
},
"myFirstAction": {
"inputs": {
...
},
"runAfter": {},
"type": ...
}
}
Secção Outputs (Resultados)
Utilize a secção outputs (resultados) para definir os dados que o fluxo de trabalho pode devolver quando tiver concluído a execução. Poderia monitorizar um estado ou dados específicos para cada execução do fluxo de trabalho. Você pode examinar a saída de cada execução de um fluxo de trabalho usando o histórico de execução dos Aplicativos Lógicos do Azure, que está disponível no portal do Azure ou na API REST do Fluxo de Trabalho.
O formato da secção outputs terá este aspeto:
"outputs": {
"<key-name>": {
"type": "<key-type>",
"value": "<key-value>"
}
}
Expressões de fluxo de trabalho
Você pode usar uma expressão de fluxo de trabalho no lugar de qualquer valor fixo, variável ou constante. Também pode colocar uma expressão em qualquer lugar num valor de cadeia JSON, colocando como prefixo da expressão o sinal de arroba (@). Por exemplo, você pode usar a função @parameters em uma expressão para recuperar o valor de um parâmetro nomeado (os parâmetros são descritos na próxima seção).
"customerFullName": "Bill Frost",
"accountName": "@parameters('customerName')"
Os Aplicativos Lógicos do Azure fornecem funções internas que você pode usar para criar expressões complexas:
- Funções de cadeia de caracteres: Para concatenar ou dividir cadeias de caracteres, converter caracteres entre maiúsculas e minúsculas e procurar substrings.
- Funções de coleção: para detetar se uma coleção contém itens que correspondem a um padrão específico, recuperar itens de uma coleção e combinar coleções.
- Funções de comparação lógica: Para detetar se os operandos são iguais, diferentes, numericamente maiores ou numericamente menores do que os outros.
- Funções de conversão: Para alterar o tipo ou formato de dados.
- Funções matemáticas: Como adicionar, sub, div e mul, além de várias outras.
- Funções de data e hora: Para analisar e processar datas e horas.
- Funções de fluxo de trabalho: para recuperar informações sobre os dados passados para uma ação de fluxo de trabalho. Por exemplo, a função parameter (mostrada anteriormente) obtém o valor de um parâmetro com nome e a função body (mostrada anteriormente) devolve os dados que estão a ser gerados por uma ação.
- Funções de manipulação JSON e XML: Para analisar e processar documentos JSON e XML.
Pode definir variáveis na secção de inputs de uma ação InitializeVariable, e pode manipular essas variáveis através de expressões. Leia o valor de uma variável usando a função variáveis . O exemplo seguinte utiliza uma ação InitializeVariable para criar uma variável de número inteiro chamada myIntegerVariable e inicializá-la a 99. Este exemplo também mostra uma ação Condition com o tipo If. A condição usa uma expressão para testar o valor davariável myIntegerVariable e, se corresponder ao valor 100, a condição usa uma ação HTTP para executar uma solicitação GET.
"actions": {
"Condition": {
"actions": {
"HTTP": {
"inputs": {
"method": "GET",
"uri": "http://dummyurl.com"
},
"runAfter": {},
"type": "Http"
}
},
"expression": {
"equals": [
"@variables('myIntegerVariable')",
100
]
} ,
"runAfter": {
"Initialize": [
"Succeeded"
]
},
"type": "If"
},
"Initialize": {
"inputs": {
"variables": [
{
"name": "myIntegerVariable",
"type": "Integer",
"value": 99
}
]
},
"runAfter": {},
"type": "InitializeVariable"
}
}
Secção Parâmetros
A secção parameters (parâmetros) permite-lhe parametrizar um fluxo de trabalho. No runtime, pode fornecer valores para cada um destes parâmetros. Você pode fazer referência aos parâmetros em qualquer lugar do fluxo de trabalho onde possa usar uma constante ou expressão.
Pode adicionar uma definição de parâmetros com um valor predefinido. Se não fornecer um valor para o parâmetro no runtime, é utilizado o valor predefinido. O exemplo seguinte mostra como definir um parâmetro denominado cityParam. O parâmetro é utilizado dentro da condição para a ação mypostrequest. Executa a ação apenas se o documento do pedido contiver uma cidade que corresponda ao valor do parâmetro. O valor de parâmetro predefinido é Nova Iorque:
"definition": {
"$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
"actions": {
...
},
"contentVersion": "1.0.0.0",
"outputs": {},
"parameters": {
"cityParam": {
"defaultValue": "New York",
"type": "String"
}
},
"triggers": {
"mypostrequest": {
"conditions": [
{
"expression": "@equals(triggerOutputs()['body']['customerAddress']['city'], parameters('cityParam'))"
}
],
"inputs": {
...
},
"kind": "Http",
"type": "Request"
}
}
}
}