Guia de referência de esquema para a Linguagem de Definição de Fluxo de trabalho nos Aplicativos Lógicos do Azure

Quando você cria um aplicativo lógico nos Aplicativos Lógicos do Azure, ele tem uma definição de fluxo de trabalho subjacente que descreve a lógica real que é executada no aplicativo. Essa definição de fluxo de trabalho usa JSON e segue uma estrutura validada pelo esquema de Linguagem de Definição de Fluxo de Trabalho. Esta referência fornece uma visão geral sobre essa estrutura e sobre como o esquema define atributos na definição de fluxo de trabalho.

Estrutura da definição de fluxo de trabalho

Uma definição de fluxo de trabalho sempre inclui um gatilho para instanciar o aplicativo lógico, além de uma ou mais ações executadas depois que o gatilho é acionado.

Esta é a estrutura de alto nível de uma definição de fluxo de trabalho:

"definition": {
  "$schema": "<workflow-definition-language-schema-version>",
  "actions": { "<workflow-action-definitions>" },
  "contentVersion": "<workflow-definition-version-number>",
  "outputs": { "<workflow-output-definitions>" },
  "parameters": { "<workflow-parameter-definitions>" },
  "staticResults": { "<static-results-definitions>" },
  "triggers": { "<workflow-trigger-definitions>" }
}

Gatilhos e ações

Em uma definição de fluxo de trabalho, as seções triggers e actions definem as chamadas que ocorrem durante a execução do fluxo de trabalho. Para conhecer a sintaxe e obter mais informações sobre essas seções, confira Gatilhos e ações de fluxo de trabalho.

Parâmetros

O ciclo de vida da implantação geralmente tem ambientes diferentes para desenvolvimento, teste, preparo e produção. Ao implantar aplicativos lógicos em vários ambientes, provavelmente convém usar valores diferentes, como cadeias de conexão, com base nas suas necessidades de implantação. Ou você pode ter valores que deseja reutilizar em todo o seu aplicativo lógico sem hard-coding ou que mudam com frequência. Na seção parameters de sua definição de fluxo de trabalho, você pode definir ou editar parâmetros para os valores que seu aplicativo lógico usa no runtime. Você deve definir esses parâmetros primeiro para poder referenciá-los em outro ugar na sua definição de fluxo de trabalho.

Esta é a estrutura geral de uma definição de parâmetro:

"parameters": {
   "<parameter-name>": {
      "type": "<parameter-type>",
      "defaultValue": <default-parameter-value>,
      "allowedValues": [ <array-with-permitted-parameter-values> ],
      "metadata": {
         "description": "<parameter-description>"
      }
   }
},

Em seguida, crie um modelo do Azure Resource Manager para sua definição de fluxo de trabalho, defina os parâmetros de modelo que aceitam os valores desejados na implantação, substitua os valores codificados por referências aos parâmetros de definição de modelo ou de fluxo de trabalho, conforme apropriado, e armazene os valores a serem usados na implantação em um arquivo de parâmetroseparado. Dessa forma, você poderá alterar esses valores com mais facilidade, sem precisar atualizar e reimplantar o aplicativo lógico. Para informações confidenciais ou que devem ser protegidas, como nomes de usuários, senhas e segredos, você pode armazenar esses valores no Azure Key Vault e fazer com que o arquivo de parâmetros recupere esses valores do seu cofre de chaves. Para obter mais informações e exemplos sobre como definir parâmetros nos níveis de definição de modelo e de fluxo de trabalho, confira Visão geral: automatizar a implantação para aplicativos lógicos com modelos do Azure Resource Manager.

Resultados estáticos

No atributo staticResults, defina outputs e status fictícios de uma ação, que esta retornará quando a configuração de resultado estático dela for ativada. Na definição da ação, o atributo runtimeConfiguration.staticResult.name faz referência ao nome da definição de resultado estático dentro de staticResults. Saiba como você pode testar fluxos de trabalho de aplicativos lógicos com dados fictícios configurando resultados estáticos.

"definition": {
   "$schema": "<...>",
   "actions": { "<...>" },
   "contentVersion": "<...>",
   "outputs": { "<...>" },
   "parameters": { "<...>" },
   "staticResults": {
      "<static-result-definition-name>": {
         "outputs": {
            <output-attributes-and-values-returned>,
            "headers": { <header-values> },
            "statusCode": "<status-code-returned>"
         },
         "status": "<action-status>"
      }
   },
   "triggers": { "<...>" }
}

Por exemplo, nessa definição de ação HTTP, o atributo runtimeConfiguration.staticResult.name faz referência a HTTP0 dentro do atributo staticResults, onde as saídas fictícias para a ação são definidas. O atributo runtimeConfiguration.staticResult.staticResultOptions especifica que a configuração de resultado estático é Enabled na ação HTTP.

"actions": {
   "HTTP": {
      "inputs": {
         "method": "GET",
         "uri": "https://www.microsoft.com"
      },
      "runAfter": {},
      "runtimeConfiguration": {
         "staticResult": {
            "name": "HTTP0",
            "staticResultOptions": "Enabled"
         }
      },
      "type": "Http"
   }
},

A ação HTTP retorna as saídas na definição HTTP0 dentro de staticResults. Neste exemplo, para o código de status, a saída fictícia é OK. Para valores de cabeçalho, a saída fictícia é "Content-Type": "application/JSON". Para o status da ação, a saída fictícia é Succeeded.

"definition": {
   "$schema": "<...>",
   "actions": { "<...>" },
   "contentVersion": "<...>",
   "outputs": { "<...>" },
   "parameters": { "<...>" },
   "staticResults": {
      "HTTP0": {
         "outputs": {
            "headers": {
               "Content-Type": "application/JSON"
            },
            "statusCode": "OK"
         },
         "status": "Succeeded"
      }
   },
   "triggers": { "<...>" }
},

Expressões

Com JSON, é possível ter valores literais existentes no tempo de design, por exemplo:

"customerName": "Sophia Owen",
"rainbowColors": ["red", "orange", "yellow", "green", "blue", "indigo", "violet"],
"rainbowColorsCount": 7

Também é possível ter valores que não existem até o tempo de execução. Para representar esses valores, é possível usar expressões, que são avaliadas em tempo de execução. Uma expressão é uma sequência que pode conter uma ou mais funções, operadores, variáveis, valores explícitos ou constantes. Em sua definição de fluxo de trabalho, você pode usar uma expressão em qualquer lugar de um valor de cadeia de caracteres JSON prefixando a expressão com uma arroba (@). Quando uma expressão que representa um valor JSON é avaliada, o corpo da expressão é extraído removendo o caractere @ e ela sempre resulta em outro valor JSON.

Por exemplo, para a propriedade customerName definida anteriormente, você pode obter o valor da propriedade usando a função parameters() em uma expressão de função e pode atribuir esse valor à propriedade accountName:

"customerName": "Sophia Owen",
"accountName": "@parameters('customerName')"

A interpolação de cadeias de caracteres também permite usar várias expressões dentro de cadeias de caracteres que são encapsuladas pelo caractere @ e por chaves ({}). Esta é a sintaxe:

@{ "<expression1>", "<expression2>" }

O resultado sempre é uma cadeia de caracteres, tornando essa funcionalidade semelhante à função concat(), por exemplo:

"customerName": "First name: @{parameters('firstName')} Last name: @{parameters('lastName')}"

Se você tiver uma cadeia de caracteres literal iniciada pelo caractere @, prefixe esse caractere com outro @, que funcionará como caractere de escape: @@

Estes exemplos mostram como as expressões são avaliadas:

Para esses exemplos, suponha que você defina "myBirthMonth" como "January" e "myAge" igual ao número 42:

"myBirthMonth": "January",
"myAge": 42

Estes exemplos mostram como as expressões a seguir são avaliadas:

Quando você estiver trabalhando visualmente no designer de fluxo de trabalho, poderá criar expressões usando o editor de expressões, por exemplo:

Quando você terminar, a expressão será exibida para a propriedade correspondente em sua definição de fluxo de trabalho, por exemplo, a propriedade searchQuery aqui:

"Search_tweets": {
  "inputs": {
    "host": {
      "connection": {
        "name": "@parameters('$connections')['twitter']['connectionId']"
      }
    }
  },
  "method": "get",
  "path": "/searchtweets",
  "queries": {
    "maxResults": 20,
    "searchQuery": "Azure @{concat('firstName','', 'LastName')}"
  }
},

Saídas

Na seção outputs, defina os dados que o fluxo de trabalho pode retornar quando terminar sua execução. Por exemplo, para rastrear um valor ou status específico em cada execução, especifique que a saída do fluxo de trabalho retorne esses dados.

Esta é a estrutura geral de uma definição de saída:

"outputs": {
  "<key-name>": {
    "type": "<key-type>",
    "value": "<key-value>"
  }
}

Para obter a saída da execução de um fluxo de trabalho, examine os detalhes e o histórico de execuções do seu aplicativo lógico no portal do Azure ou use a API REST de fluxo de trabalho. Você também pode passar a saída para sistemas externos, por exemplo, o Power BI para que você possa criar painéis.

Operadores

No caso de expressões e funções, os operadores desempenham tarefas específicas, como referenciar uma propriedade ou um valor em uma matriz.

Funções

Algumas expressões obtêm seus valores de ações de runtime que podem ainda não existir quando sua definição de fluxo de trabalho começa a ser executada. Para referenciar ou trabalhar com esses valores em expressões, você pode usar as funções fornecidas pela linguagem de definição de fluxo de trabalho.

Próximas etapas

• Saiba mais sobre Workflow Definition Language actions and triggers (Ações e gatilhos da Linguagem de Definição de Fluxo de Trabalho)
• Saiba mais sobre como criar e gerenciar Aplicativos Lógicos de forma programática com a API REST de fluxo de trabalho